回答:
これを行うには「AWS-HA-Release」をお勧めします-AWS-HA-Releaseの仕組み：
この場合、ダウンタイムなしで新しいコードまたは新しいAMIバージョンを出荷でき、完全に新しいインスタンスの利点があります。AWS-HA-Releaseツールはhttps://github.com/colinbjohnson/aws-missing-toolsで入手できます。
より簡単な方法は、Auto-Scaling Group（ASG）の最小インスタンスの数を現在の数の2倍に増やし、すべてが開始されるのを待ってから、その最小インスタンス数を元の値に変更することです。ELBは古いインスタンスを強制終了し、新しいインスタンスにコードを残します。終了ポリシーを達成するには、意図したとおりに動作するように「OldestInstance」に設定する必要があります。デフォルトの終了ポリシーには、望ましくない副作用がある場合があります。
ここでAWS CLIのパラメーターと例を見ることができます：http : //docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html
このシナリオを管理する方法は、クラウド形成でAWS :: AutoScaling :: AutoScalingGroupオブジェクトのUpdatePolicy機能を使用することです。クラウド形成スタックが更新されると、インスタンスの循環を管理します。
いくつかの参照。 http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy .html
また、現在オープンソースとなっているNetflix Asgardツールもご覧ください。Auto Scaling Groupをセットアップできるだけでなく、インスタンスのグループに対して新しいAMIイメージのローリングリリースを実行することもできます。
正直に言うと、実際には本当に良い方法はありません。私が見つけた最善の方法は、ASG名にバージョンを入れることです。AMIを更新するたびに、新しいバージョンで新しいASG + Launch Configを作成して、他のグループと競合しないようにします。次に、古いグループのすべてのインスタンスを終了します。
よりフォールトトレラントな展開が必要な場合は、新しいロードバランサーの作成も含めて別の手順を追加することをお勧めします。これにより、両方のASGを相互に分離できます。また、更新の前に最後に変更をテストするための「ステージング」領域を持つことができます。次に、切り替える準備ができたら、DNSレコードを更新し、古いグループのすべてのインスタンスを終了します。
ここに投稿したように（Terraformでの同様の質問）、cloudformationを使用する場合を除いて、ASGには組み込まれていません。私もそれに苦労したので、複数のASGを監視し、その状態と更新をチェックする「ローラー」を書くことになりました。フィードバックをお寄せください。http://github.com/deitch/aws-asg-roller
as-set-instance-health）異常としてマークすると、自動スケーリングが単に新しいインスタンスで置き換えられるようになると、おそらくより効率的です。