高可用性Bastion主机 – 最佳实践，ELB，EIP？

我目前正试图找出一个好的configuration，使堡垒主机高度可用。我想要达到以下目标：

堡垒主机需要能够承受可用区域故障和EC2实例故障。一个小的停机时间（几分钟）可能是可以接受的。
堡垒主机需要通过永久性的DNS入口访问。
不需要手动干预

我目前的设置如下：两个可用区域中的Auto Scaling Group中的堡垒主机，Auto Scaling Group前面的ELB。

这个设置有一些优点：

易于使用CloudFormation进行设置
可以使用两个AZ上的Auto Scaling组来保证可用性
不计入账户EIP限制

它也有一些缺点：

在ELB后面有两个或更多堡垒主机，SSH主机关键警告是常见的，我不希望我们的用户习惯忽略SSH警告。
ELB花钱，而不是EIP。实际上和堡垒主人差不多。这不是一个真正的问题，我只是为了完整性而添加了这一点。

另一个明显的解决scheme是使用ElasticIP，它具有 – 我所见 – 有一些缺点：

我可以（可以）不直接将EIP附加到Auto Scaling组
当不使用Auto Scaling组时，如果旧的EC2堡垒主机发生故障（例如使用AWS Lambda），则必须安装一些新的EC2堡垒主机。这增加了复杂性。
当EIP手动连接到Auto Scaling组时，在可用区故障时，EIP将被取消连接，不会重新连接到新实例。再次，可以通过运行将EIP重新附加到实例的程序（在实例或AWS Lambda上）来解决此问题。这又增加了额外的复杂性。

什么是高可用性SSH实例的最佳实践，即堡垒主机？

看起来像要求是以最低的合理成本提供堡垒function，例如5分钟的RTO。没有RPO适用，因为它实际上是一个可以轻松重build的无状态代理。

我有一个堡垒主机，定义为AMI或CloudFormation脚本（AMI更快），在最小/最大/目标设置为1的自动调整组内。我不会有一个负载平衡器，因为没有必要据我所知。这个实例将使用公有域名向Route53注册，因此即使实例发生更改，您也可以访问该实例，并且可以消除SSH警告。我可能从每个子网中的一个实例开始，但是如果它们足够可靠，我可能会closures它们 – 它们应该是。

Amazon 在这里描述了堡垒主机的CloudFormation部署。亚马逊在这里有一个最佳实践指南。你不应该使用他们的弹性IP来处理内部资源，因为它们是公共IP地址，并且对它们的stream量是收费的，而私有IPstream量是不收费的。域名更便宜。这可能涉及到一些CloudFormation脚本的调整。