一人プロジェクトでレガシーな環境ですがBeanstalkでこんな運用していますという一例です。

前提

プラットフォームのバージョンアップ時にアプリ側もなんやかんや変えて少し不安があるなという状態の時
１-既存の環境を立ち上げたまま
２-新しい環境を立ち上げ
3-RDSのセキュリティグループに新しいEC2のセキュリティグループをアタッチ
4-Cloudfrontのオリジンを切り替える
という流れで作業していますがうまくいくとほぼダウンタイムなしで切り替えができ
ロールバックもCloudfrontの反映時間（最近5分くらい何年か前までは20分くらいかかった）で完了できます。
今回はCloudfrontで切り替えるのであまり関係ありませんが、Beanstalk自体にもアプリケーションのロールバックが簡単にできる機能が標準であるのでこちらも安心材料にはなっています。

環境

ローカル
vagrant+virtualbox(centos7内でebコマンドで管理、gitもローカルのみ)
2020年くらいからDockerに移行しましたが同じ手順で問題なく行えています。

本番
Route53 → Cloudfront → Beanstalk(ALB+EC2) → RDS
　　　　　　∟S3

手順

ローカルでの作業

1.erasticbeanstalk/config.yml編集
　∟環境とアプリケーションの名前を変更する
　∟プラットフォームバージョンを変更する

※プラットフォームバージョンは公式のマニュアルに一覧があります。

がページ通りのバージョンを指定しても、たまに情報が最新に追いついていなくてエラーが出ることがあります。

以下はeb createコマンドの際に表示されたエラーです。


ERROR: NotFoundError - Elastic Beanstalk can't find a platform version that matches "64bit Amazon Linux 2023 v4.4.0 running PHP 8.3".

そんな時は以下のコマンドで最新バージョンを確認できます。


aws elasticbeanstalk list-platform-versions --filters 'Type="PlatformName",Operator="contains",Values="Php"'

また以下のようなエラーが出ることもあります。


ERROR: InvalidParameterValueError - Platform ARN is invalid: Not an IAM ARN: 64bit Amazon Linux 2023 v4.4.2 running PHP 8.3.

これはコマンドで指定してるプラットフォームがarnではない時に表示されます。自分の環境では以下のように修正しました。

config.yml


-  default_platform: 64bit Amazon Linux 2023 v4.4.2 running PHP 8.3
-  platform_name: 64bit Amazon Linux 2023 v4.4.2 running PHP 8.3
-  platform_version: 64bit Amazon Linux 2023 v4.4.2 running PHP 8.3

+  default_platform: arn:aws:elasticbeanstalk:ap-northeast-1::platform/PHP 8.3 running on 64bit Amazon Linux 2023/4.4.2
+  platform_name: arn:aws:elasticbeanstalk:ap-northeast-1::platform/PHP 8.3 running on 64bit Amazon Linux 2023/4.4.2
+  platform_version: arn:aws:elasticbeanstalk:ap-northeast-1::platform/PHP 8.3 running on 64bit Amazon Linux 2023/4.4.2

2.eb create

AWSコンソールでの作業(新環境)

1.Beanstalkコンソール　→　設定　→　ロードバランサで
　∟ポート443追加
　∟プロセスに301設定

2.EC2にアタッチされているセキュリティグループのSSHを削除

3.RDSのセキュリティグループ設定を変更
新環境のEC2のセキュリティグループを追加。

※ここまでは事前準備可能
以下のCloudFront手順を実施するといよいよBeanstalk環境が旧から新に切り替わるので
設定が合っていないとダウンタイムが発生する可能性がでてきます。
ので一通り最終確認（セキュリティグループの設定、ロードバランサのリスナなど）

ミスりやすいのはセキュリティグループの違うものがアタッチされたていたり
ロードバランサのセキュリティポリシーがアプリケーションで使えないものだったり

セキュリティポリシーが違っているとBeanstalkコンソール画面に以下のようなエラーが出ます。

Creating Load Balancer listener failed Reason: Resource handler returned message: "SSL policy 'ELBSecurityPolicy-TLS13-1-3-2021-06' is not supported on load balancers of type 'application' (Service: ElasticLoadBalancingV2, Status Code: 400

AWSコンソールでの作業(もとからある環境)

1.ClouudFrontの設定変更
ClouudFrontコンソール画面 → オリジンタブ → ロードバランサが設定されているオリジンを選び編集ボタンを押します。そしてオリジンドメインを変更します。この時プロトコルなど他の設定が自動で変わっていないか念の為チェックした方が安心です。

2.RDSのセキュリティグループ設定からもとからある環境のEC2のセキュリティグループを削除します。

3.最終的なアプリの動作確認をします。表示できるか、投稿などのプログラムは動くか、ログインできるかなど。

4.もとからあったBeanstalk環境を終了します。

後書き

作業自体は慣れてしまえば長く見積もっても30分もかからずダウンタイムもほぼなく移行できる＆ロールバックも簡単にできるので新しく環境整えるコストを考えると腰が重くなるのも事実です。ただ予算が取れてFagateに移行できればこの作業自体無くせる（新たな技術と今以上のランニングコストが必要にはなる←ここがネック）と思うので来たるときに備えて粛々と学習だけは進めています。Fagateだいぶ安くなったけどもうちょっと安くなればな〜。
↓便利な計算機能ができてました。