Beanstalkでデプロイした場合、デプロイ作業時にELB（ターゲットグループ）がどのような挙動をしているのか確認してみました。
目的は、
- デプロイ中のEC2にユーザーがアクセスしてしまう可能性があるか？
- デプロイ中にELB（ターゲットグループ）のアクセス制御（トラフィックコントロール）が入っているか
を確認しました。
レジュメ
環境・前提条件
Beanstalkでの「ローリンング更新とデプロイ」の設定は以下のように設定されています。
- デプロイメントポリシーは「ローリング」
- ローリング更新のタイプは「ヘルスに基づくローリング」
他にも、デプロイ時間を考慮した「時間にもとづくローリング」も設定可能でした。
結論、ローリングデプロイはELB(ターゲットグループ)連携してデプロイ中のユーザーアクセスが来ないような制御をしている
以下、デプロイ中に確認したターゲットグループのEC2ステータス遷移
では、上記デプロイメントポリシーで「アプロードとデプロイ」を実施してみます。
デプロイが実行されたことを確認し、beanstalkのターゲットグループのターゲット画面を確認します。
１、デプロイ対象の一台目EC2がdrainingされる。ターゲットグループからデプロイ対象が外される。
「ローリンング更新とデプロイ」 の設定どおり、EC2一台ずつデプロイが実施されていることがわかります。
デプロイ対象のEC2はターゲットグループ上、unhealthyになるわけではなくdraining（外される）操作がされていることがわかります。
２、デプロイ中も AutoScalingのもう一台のEC2はhealthyのまま
デプロイ中のEC2はターゲットグループから外され（制御が入らないとターゲットから外れずにunused等のステータスになる）ますが、
別のもう一台のhealthyのEC2がありますのでユーザーはアクセスできます。
AutoScalingの最低台数は今回2台なのですが、EC2が無くなったターミネートされたわけでは無いので、ターゲットグループからは見えませんがEC2の台数自体は変わっていません。
３、デプロイが終わるとまたターゲットグループに追加される
デプロイが完了すると、先ほどターゲットグループから外されたEC2が再びターゲットグループに追加され、intialステータスになっていることがわかります。
４、ターゲットグループでステータスがhealthyになると次のEC2がデプロイ対象となる。これの繰り返し（ローリング）
Beanstalkで作成した場合は、デプロイ時にターゲットグループにデプロイ制御が入ることがわかりました。
なかなかここまで作りこむのは大変なので、便利ではありますね！
違いを知るためにBeanstalkのAutoScalingグループを違うターゲットグループに追加してデプロイ時の挙動を見てみると
結果、ずっとステータスはhealthyのままでした。
つまり、デプロイ中のEC2にユーザーがアクセスしに行ってしまいます。
デプロイ中にユーザーアクセスがあると、もちろんケースによってはエラー（レスポンスコード500番台）が帰ることになります。
BeanstalkのAutoScalingグループのターゲットグループは変更しない方がデプロイを考えると良いですね（逆に、ターゲットグループに紐づくALBを変えるのは問題はなさそうでした。Beanstalkの「環境の再構築」等をしなければですけど）
参考：