高可用性堡垒主机 - 最佳实践、ELB、EIP？

Question

我目前正在尝试找出一个好的配置来使堡垒主机高度可用。我想达到以下目标：

1. 堡垒主机需要能够承受可用区故障和 ec2 实例故障。短暂的停机时间（几分钟）可能是可以接受的。
2. 堡垒主机需要可通过永久 DNS 条目访问。
3. 无需人工干预

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

这种设置有几个优点：

• 使用 CloudFormation 轻松设置
• 可以使用两个 AZ 上的 Auto Scaling 组来保证可用性
• 不计入账户 EIP 限制

它也有一些缺点：

• 在 ELB 后面有两个或更多堡垒主机时，SSH 主机密钥警告很常见，我不希望我们的用户习惯于忽略 SSH 警告。
• ELB 需要花钱，而不是 EIP。实际上和堡垒主机差不多。这并不是什么大问题，我添加这一点只是为了完整起见。

另一个明显的解决方案是使用 ElasticIP，在我看来，它有一些缺点：

• 我可以（显然）不直接将 EIP 附加到 Auto Scaling 组
• 当不使用 Auto Scaling Groups 时，如果旧的主机失败，我必须放置一些东西来启动新的 EC2 堡垒主机，例如使用 AWS Lambda。这增加了额外的复杂性。
• 当 EIP 手动附加到 Auto Scaling 组时，在可用区失败时，EIP 将被取消附加并且不会重新附加到新实例。同样，这可以通过运行将 EIP 重新附加到实例的程序（在实例或 AWS Lambda 上）来解决。这再次增加了额外的复杂性。

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

Answer 1

看起来要求是以最低合理成本提供堡垒功能，RTO 为 5 分钟。RPO 不适用，因为它实际上是一个可以轻松重建的无状态代理。

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

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