高可用性基础主机-最佳实践，ELB，EIP？

Question

我目前正在努力找出一个好的配置，使一个Bastion主机高度可用。我希望达到以下目标：

1. 堡垒主机(S)需要能够承受可用性区域故障和ec2实例故障。一小段停机时间(几分钟)是可以接受的。
2. 堡垒主机(S)需要通过一个永久DNS条目到达。
3. 不需要人工干预

我现在的设置如下:自动缩放组中的堡垒主机在两个可用区域，ELB在自动缩放组前面。

此设置有以下几个优点：

• 使用CloudFormation易于安装
• 两个AZs上的自动缩放组可以用来保证可用性。
• 不计入帐户的EIP限制。

它也有一些缺点：

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

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

• 我可以(明显地)不直接将EIP附加到自动缩放组
• 当不使用自动缩放组时，我必须在旧的EC2堡垒主机失败时启动新的堡垒主机，例如使用AWS。这增加了额外的复杂性。
• 当EIP手动连接到自动缩放组时，在可用性区域失败时，EIP将被断开，而不会重新连接到一个新实例。同样，可以通过运行将EIP重新连接到实例的程序(在实例或AWS Lambda上)来解决这一问题。这又增加了额外的复杂性。

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

Answer 1

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

在自动标度组中，我将有一个堡垒主机，定义为AMI或CloudFormation脚本(AMI更快)，将min/max/目标值设置为1。我不会有负载均衡器，因为据我所见，不需要这样做。此实例将以公共域名在Route53中注册，因此即使实例发生更改，您也可以访问它，这将消除SSH警告。我可能从每个子网中的一个实例开始，但如果它们足够可靠，我可能会关闭一个实例--它们应该是这样的。

bastion主机的CloudFormation部署由这里描述。亚马逊有一个最佳实践指南这里。您不应该使用它们的弹性IP来处理内部资源，因为它们是公共IP和向他们收取交通费。，而私有IP流量是不收费的。域名更便宜。这可能涉及到一些CloudFormation脚本的调整。

Answer 2

基本上，我认为您的方法是使用循环DNS，这样DNS服务器就可以将流量分配给您的堡垒主机，但是您不会得到ssh键警告。