私は4つのEC2（APIサーバー）インスタンスをAWB上でELBで実行しています。私は自動スケーリンググループを適用したいと思います。私が理解してから、まず実行中の4つのEC2インスタンスのうちの1つのAMIを作成する必要があります。このインスタンスは、構成に基づいて作成したAMIから自動拡張されます。この時点で、新しいコードをプッシュするたびにAMIを再作成して最新のバージョンから拡張する必要がありますか？AWS自動スケーリンググループAMI
はい、更新されたコードは新しいAMIに焼き付けられ、コードを変更するときはいつでもEC2（展開）にプッシュされます。
もう1つの方法は、同じAMIを使用して代わりにドッカー画像を更新できるように、docker imageを使用することです。
あなたは基本がダウンしています。
自動スケーリンググループ（ASG）を使用する場合、EC2インスタンスはステートレスでなければなりません。つまり、インスタンスにデータを保持せず、RDSやS3などの他の場所にデータを格納します。 ASGが新しいインスタンスを起動するとき、EC2インスタンスには、新しいインスタンスに必要なデータをダウンロードまたはコピーするためのスクリプト（EC2 Userdataなど）が必要です。
すでにEC2インスタンスの設定とセットアップが済んだら、ASGの新しいAMIとしてEC2インスタンスの1つからAMIを作成します。
永続的な情報（新しいWindowsまたはLinuxのパッチ、ソフトウェアまたはアプリケーションの更新など）を使用してインスタンスを変更すると、新しいAMIが作成され、以前のAMIが置き換えられます。
あなたはAMIあなたがコードの変更を行うたびに再作成する必要はありません。実際には、新しいEC2インスタンスが作成されるたびに、オートスケーリンググループを使用してAWS CodeDeployを使用して最新のコードをデプロイすることができます。
それは、ここで説明しています：https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorials-auto-scaling-group.html
起動するためのあなたのAMIを管理するための複数のオプションがあります。フルベークされたAMIから、起動時に構成された基本OS AMIへと移行します。それぞれに長所と短所があります。
完全に焼いたAMIを長年にわたって管理してきた私たちは、AMIプロビジョニングをより「継続的な統合」の仕方で管理する、AMIビルドパイプラインのアプローチに向かっています。
あなたの質問にお答えするには、はいあなたはオートスケーリンググループで使用するためにプリベーク済みのAMIを使用することができます。しかし、このアプローチは柔軟性を制限し、特に複数のアカウントや環境を運用している場合、メンテナンスの困難を引き起こす可能性があります。
AMIの設計オプションは、展開の柔軟性に 関係で展開シンプルさのスペクトルに沿って落ちます。最も簡単なAMIは、完全に焼き付けられた であり、必要なすべてのソフトウェアのインストールと構成を含む を含む、完全に実行されているインスタンスを展開するために専用に構築されています。ただし、完全にベークされたAMIは、単一インスタンスまたは同一インスタンスのファームを にデプロイするためにのみ使用できるため、この アプローチは柔軟性を制限します。最も多くの の柔軟なAMIには、最初の起動時に必要なパッケージを動的にインストールする前に、最小構成とソフトウェアのみが含まれています（ ）。この アプローチは、それぞれのインスタンスが適切にブートストラップされてから意図したとおりに機能する必要があるため、柔軟性のためにシンプルさを実現します。
正しいアプローチでは、スキルセット、AWSエクスペリエンス、および開発運用インフラストラクチャが考慮されます。