高可用性要塞ホスト-ベストプラクティス、ELB、EIP？
私は現在、要塞ホストを高可用性にするための適切な構成を理解しようとしています。次の目標を達成したい：
- 要塞ホストは、アベイラビリティーゾーンの障害とec2インスタンスの障害に耐えることができる必要があります。わずかなダウンタイム（数分）は許容できる場合があります。
- 要塞ホストは、永続的なDNSエントリを介して到達可能である必要があります。
- 手操作による介入は不要
現在の設定は次のとおりです。AutoScalingグループの前のELBの2つのアベイラビリティーゾーンにあるAuto Scalingグループの要塞ホスト。
このセットアップにはいくつかの利点があります。
- CloudFormationを使用して簡単にセットアップ
- 2つのAZ上のAuto Scalingグループを使用して可用性を保証できます
- はアカウントのEIP制限にカウントされません
また、いくつかの欠点もあります。
- ELBの背後に2つ以上の要塞ホストが存在する場合、SSHホストキーの警告は一般的であり、ユーザーがSSH警告を無視することに慣れるのは望ましくありません。
- ELBはEIPとは対照的に費用がかかります。要塞ホストとほぼ同じくらいです。これはあまり問題ではありませんが、完全を期すためにこの点を追加しました。
他の明らかな解決策は、ElasticIPを使用することです。
- （当然のことながら）EIPをAuto Scalingグループに直接アタッチできない
- Auto Scalingグループを使用していない場合、古いEC2要塞ホストが失敗した場合に新しいEC2要塞ホストを開始するものを配置する必要があります。 AWS Lambdaを使用します。これにより、さらに複雑になります。
- EIPがAuto Scalingグループに手動で接続されている場合、アベイラビリティーゾーンに障害が発生すると、EIPは接続解除され、新しいインスタンスに再接続されません。この場合も、EIPをインスタンスに再接続するプログラムを（インスタンスまたはAWS Lambdaで）実行することで解決できます。この場合も、複雑さが増します。
高可用性SSHインスタンス、つまり要塞ホストのベストプラクティスは何ですか？
要件は、最低5分のRTOで妥当なコストで要塞機能を提供することのようです。 RPOは効果的にステートレスプロキシであり、簡単に再構築できるため、適用できません。
Min/max/targetを1に設定した自動スケーリンググループ内に、踏み台インスタンスをAMIまたはCloudFormationスクリプト（AMIの方が高速です）のいずれかとして定義します。そのため、ロードバランサーは必要ないので、使用しません。私の見る限り。このインスタンスはパブリックドメイン名を使用してRoute53に登録されるため、インスタンスが変更されてもアクセスでき、SSH警告が表示されなくなります。私は各サブネットで1つのインスタンスから始めるかもしれませんが、それらが十分に信頼できる場合はおそらく1つをオフにするでしょう-それらはそうであるはずです。
要塞ホストのCloudFormationデプロイメントは、Amazonによって記述されています こちら 。 Amazonにはベストプラクティスガイドがあります こちら 。 Elastic IPはパブリックIPであり、 それらへのトラフィックは課金されるため 、内部IPリソースは課金されないため、内部リソースに対処しないでください。 。ドメイン名は安価です。これには、CloudFormationスクリプトの微調整が含まれる場合があります。