我目前正在尝试找出一种良好的配置，以使 Bastion 主机具有高可用性。我希望实现以下目标：
- 堡垒主机需要能够承受可用区故障和 EC2 实例故障。短暂的停机时间（几分钟）可能是可以接受的。
- 堡垒主机需要通过永久 DNS 条目来访问。
- 无需人工干预
我当前的设置如下：两个可用区域的 Auto Scaling 组中的 Bastion 主机，Auto Scaling 组前面的 ELB。
这种设置有几个优点：
- 使用 CloudFormation 轻松设置
- 可以使用跨两个可用区的 Auto Scaling 组来保证可用性
- 不计入账户 EIP 限制
但它也有一些缺点：
- 当 ELB 后面有两个或更多堡垒主机时，SSH 主机密钥警告很常见，我不希望我们的用户习惯忽略 SSH 警告。
- 与 EIP 相比，ELB 需要花钱。实际上，它与堡垒主机差不多。这其实并不是什么大问题，我添加这一点只是为了完整性。
显而易见的另一种解决方案是使用 ElasticIP，但在我看来，它有一些缺点：
- 我（显然）不能直接将 EIP 附加到 Auto Scaling 组
- 当不使用 Auto Scaling Groups 时，我必须采取一些措施，在旧 EC2 堡垒主机发生故障时启动新的 EC2 堡垒主机，例如使用 AWS Lambda。这增加了额外的复杂性。
- 当 EIP 手动附加到 Auto Scaling 组时，如果可用区发生故障，EIP 将断开连接，并且不会重新附加到新实例。同样，可以通过运行将 EIP 重新附加到实例的程序（在实例或 AWS Lambda 上）来解决此问题。这又增加了额外的复杂性。
高可用性 SSH 实例（即堡垒主机）的最佳实践是什么？
答案1
看起来要求是以最低的合理成本提供堡垒功能，RTO 为 5 分钟。不适用 RPO，因为它实际上是一个可以轻松重建的无状态代理。
我会有一个堡垒主机，定义为 AMI 或 CloudFormation 脚本（AMI 更快），位于自动缩放组中，最小值/最大值/目标设置为 1。我不会使用负载均衡器，因为据我所知，没有必要。此实例将使用公共域名在 Route53 上注册，因此即使实例发生变化，您也能够访问它，这应该可以消除 SSH 警告。我可能会从每个子网中的一个实例开始，但如果它们足够可靠，我可能会关闭一个实例 - 它们应该是可靠的。
亚马逊描述了堡垒主机的 CloudFormation 部署这里亚马逊有最佳实践指南这里。您不应该使用其弹性 IP 来处理内部资源，因为它们是公共 IP，并且到他们的流量是收费的，而私有 IP 流量不收费。域名更便宜。这可能涉及一些 CloudFormation 脚本调整。
答案2
基本上，我认为解决这个问题的方法是使用循环 DNS，这样 DNS 服务器就会将流量分发到你的堡垒主机，但你不会收到 ssh 密钥警告