AWS自動スケーリングでEBSボリュームを再利用する

Question

EC2インスタンスの自動修復をセットアップしようとしています。そのため、インスタンスがダウンしたり到達不能になったりした場合は、自動再起動するか、同じAWSリージョンの別のAZで新しいインスタンスを起動することが望ましいです。

Cloudwatchアラームを設定し、障害が発生した場合にインスタンスを再起動するアクションを追加することを検討しました。これは、障害が発生した場合にEC2インスタンスを再起動するだけで十分です。

ただし、AZ自体に到達できない場合は対象外です。そのため、最小/最大インスタンス番号を1としてAWS自動スケーリンググループを設定しようとしています。失敗した場合は、終了したインスタンスのEBSボリュームで新しいインスタンスを起動します。どうすればこれを進めることができますか？

または、私が望むことを達成するための別の方法があれば、それもありがたいです。

Mike · Answer

そのため、自動修復のためにASGで多数の単一サーバーを実行しています。

私がしたことは、EBSボリュームにセットタグを付けることでした。

起動時に、awsメタデータAPIとCLIを使用し、APIを介して独自のインスタンスIDを取得し、独自のAZにセットタグを持つEBSボリュームを検索するcloud-initスクリプトがあります。ボリュームIDを取得すると、デタッチが安全側に強制されます。次に、それをそれ自体に取り付けます。

これまでのところ、それはかなりうまく機能しました。

Daryl Metzler · Answer

これはできることですが、簡単ではないと思います。

インスタンスの再起動後も保持したいデータには、セカンダリボリュームを使用する必要があります。既存のボリュームをルートパーティションとしてインスタンスを作成できるとは思いません。少なくとも正気で簡単な方法ではありません。

EBSの「終了時に削除」をfalseに設定し、起動時に起動構成/起動スクリプトで未接続のボリュームをスキャンします。「KeepMeAlive：true」などのタグが付いたボリュームを見つけた場合は、そのボリュームを自動的にボリューム自体にアタッチします。

dsmsk80 · Answer

EFSまたはAmazonElastic File Systemについて知っていますか？これはEC2インスタンス用のファイルストレージサービスであり、説明したとおりに実行できます。ブロックデバイス（EBSボリューム）が必要ない場合は、試してみてください。