4.3デプロイ戦略と Elastic Beanstalk

新バージョンの公開方法には速度と安全性のトレードオフがあります。ダウンタイムやロールバックのしやすさを踏まえて戦略を選びます。

4.3.1デプロイ戦略

• オールアットワンス：一括で置き換える。最速だがダウンタイムのリスク。
• ローリング：バッチで順次更新。全停止は避けられるが、一時的に新旧が混在。
• Blue/Green：新環境を作りトラフィックを切替。ロールバックが容易。カナリアは少量から段階的に。
• Elastic Beanstalk：コードをアップロードするだけで環境を構築・デプロイする PaaS（戦略も選べる）。

戦略選びの基準は「許容できるダウンタイム」と「ロールバックの速さ・コスト」です。オールアットワンス は最速・最安ですが切替時に停止が生じ、失敗時は再デプロイが必要です。ローリング は一部ずつ更新して全停止を避けますが、更新中は新旧が混在し容量も一時的に減ります（ローリング＋追加バッチなら容量を保てます）。Blue/Green は新環境（グリーン）を丸ごと用意してトラフィックを切り替え、問題があれば旧環境（ブルー）へ戻すだけなのでロールバックが瞬時です（その分コストは高め）。カナリア は新バージョンへ最初に少量だけ流し、問題なければ段階的に増やします。サーバーレスでは Lambda のエイリアス＋加重（traffic shifting） と CodeDeploy 連携で、Canary（例：10%→全量）や Linear（一定間隔で増加）といった段階デプロイが宣言的に書けます。CodeDeploy の DeploymentConfig で割合と間隔を指定し、CloudWatch アラームで自動ロールバックも設定できます。Elastic Beanstalk はこれらの戦略を選べる PaaS で、コードを上げるだけでプロビジョニングからデプロイまで自動化します。

Elastic Beanstalk のデプロイ方式も DVA で問われます。All-at-once は全インスタンスを同時更新（停止あり）、Rolling はバッチ単位、Rolling with additional batch は新バッチを足して容量を保ちつつ更新、Immutable は新インスタンス群を別途立ち上げてから入れ替える（安全・ロールバック容易）、Traffic splitting はカナリア的に一部トラフィックで検証します。環境設定は .ebextensions や設定ファイルでコード化でき、環境にはWeb サーバー型と非同期処理向けのワーカー型があります。コンテナでは ECS のローリング更新 や CodeDeploy 連携の Blue/Green（新タスクセットへ切替）が使えます。どの方式でも判断軸は同じで、「停止を許容できるか」「問題時にどれだけ速く戻せるか」「追加容量のコストを払えるか」を要件に照らして選びます。

4.3.2フルスタックWebの公開：AWS Amplify

フロントエンド中心の Web/モバイルアプリを素早く公開したいときは AWS Amplify が向きます。Amplify は フロントエンドのホスティングと CI/CD を一体化したサービスで、Git リポジトリに接続すると、push を契機にビルドからデプロイ、グローバル配信（CDN）まで自動化し、プルリクエストごとのプレビュー環境やブランチ単位のデプロイも提供します。認証（Cognito）・データ（AppSync/DynamoDB）・ストレージ（S3）といったバックエンドもまとめて構成でき、SPA や SSG の配信に適します。判断の勘所は「フロントエンド主体のアプリをホスティング込みで素早く公開＝Amplify」「任意の構成を細かく IaC で組む＝CloudFormation/SAM/CDK＋自前パイプライン」「サーバー込みのアプリ環境を PaaS で管理＝Elastic Beanstalk」です。Amplify は CodePipeline/CodeBuild を自前で組むより少ない設定でフロント配信を立ち上げられるのが利点です。

4.3.3この節のまとめ

• 戦略＝速度 vs 安全。Blue/Green・カナリアはロールバック容易
• Elastic Beanstalk はコードを上げるだけの PaaS