Cloudwatchと自動スケーリングの設定に関する質問。ウェブサイトをホストしているec2インスタンス（インスタンス1）があり、そのAMI（画像1）も作成しました。インスタンス1が完全に劣化したときに、イメージ1から新しいインスタンス（インスタンス2）を開始するようにシステムを構成したいと思います。したがって、ロードバランサーは必要ありません。
質問 。これらは私が使用する予定のステップです-最小サイズ0、最大サイズ1で自動スケーリングを設定し、クラウドウォッチメトリクスを使用してステータスチェックの失敗を監視し、インスタンス1を終了してインスタンス2を使用します
スケールアップおよびスケールダウンポリシーを構成する必要がありますか？systemCheckは、インスタンスの障害を監視するための適切なメトリックに失敗しましたか？シナリオでCloudwatchと組み合わせて自動スケーリングを使用する必要がありますか？感謝します。
ありがとう
この質問は、ロードバランサーの背後にあるサービスをスケーリングして、サービスの低下を回避するという、スケーリングの一般的な使用目的とは正反対のようです。
通常、minsize / maxsizeを使用する方法は、minsizeとmaxsizeの両方を1にすることです。自動スケーリンググループで新しいインスタンスを生成するには、既存のインスタンスを終了するだけです。 。インスタンス数が0になるため、自動スケールが開始されて新しいインスタンスが開始されます。もちろん、2番目のインスタンスがトラフィックを受け入れる準備をしている間、ある程度のダウンタイムが発生します。しかし、とにかく最初のインスタンスが応答しない場合、これはあなたにとって重要ではないかもしれません。
個人的には、テスト目的以外でロードバランサーの背後にインスタンスが1つしかないというユースケースを本当に理解することはできません。ロードバランサーの背後で少なくとも2つの本番インスタンスを実行しているので、2つのインスタンスのいずれかでヘルスチェックが失敗した場合、ロードバランサーのトラフィックは短い順序でもう一方にシフトされます（開始にかかる時間よりもはるかに短い時間）新しいインスタンスを作成し、トラフィックを受け入れる準備をします）。
そうは言っても、自動スケーリングルールは非常に柔軟であり、理論的には必要なことを実行できます。自動スレーシングポリシーの設定とCloudwatchメトリクスへの関連付けに関するAWSのドキュメントについては、以下のリンクを参照してください。達成するのはかなり簡単です。