AWS Elastic Beanstalk

AWS Elastic Beanstalk は、アプリケーションのコードをアップロードするだけで、その実行に必要なインフラ一式を自動的に構成・管理してくれるデプロイサービスです。開発者はインフラの細部を意識せずにデプロイに集中できる一方で、生成されたリソースはすべて通常の AWS サービスとして可視化され、後から細かく調整できる点が特徴です。

解決する課題

Web アプリケーションを本番運用するには、サーバー（EC2）の用意、負荷分散（ロードバランサー）、台数の自動増減（Auto Scaling）、デプロイ手順、ログ収集やメトリクス監視など、多くの構成要素を組み合わせる必要があります。これらを手作業やゼロからの IaC で整えるのは、小規模チームや開発初期には負担が大きく、本質的なアプリ開発以外に時間を取られがちです。

Elastic Beanstalk は、これらの定型的なインフラ構築と運用をマネージドに肩代わりします。対応する言語・プラットフォーム（一般的な Web 言語のランタイムやコンテナ、Docker など）のコードを渡すと、適切な実行環境をプロビジョニングし、デプロイ・スケーリング・ヘルス監視まで一通り面倒を見てくれます。これにより「まず動くものを素早く本番に出す」ことが容易になります。

主要概念と用語

• アプリケーション: 論理的な入れ物。1 つのアプリケーションは複数の環境やアプリケーションバージョンを束ねる。
• アプリケーションバージョン: デプロイ対象となるコードの特定のリビジョン。アップロードされたソースバンドルを指し、環境にデプロイする単位になる。
• 環境（Environment）: アプリケーションバージョンを実際に動かすリソースの集合。EC2 インスタンスやロードバランサーなどが環境ごとに生成される。
• 環境ティア: トラフィックを受ける Web サーバー環境と、キューからジョブを処理するワーカー環境の 2 種類があり、用途で使い分ける。
• プラットフォーム: 言語ランタイムや OS、ミドルウェアの組み合わせ。AWS が用意した管理対象プラットフォーム上でアプリが動く。
• 環境設定（Configuration）: インスタンスタイプ、スケーリング条件、環境変数などの設定値。コンソール、CLI、または設定ファイルで指定する。
• 設定ファイル（.ebextensions）: ソースバンドルに含めることで、追加リソースや細かな構成をコードとして宣言的に指定できる仕組み。
• ヘルス: 環境やインスタンスの健全性を示す状態。拡張ヘルスレポートを使うとより詳細な指標が得られる。

仕様・制限・クォータ

• 下位リソースは EC2、Elastic Load Balancing、Auto Scaling、Amazon CloudWatch、Amazon S3 など、既存の標準サービスとして生成される。Elastic Beanstalk はそれらをオーケストレーションするレイヤーに位置づけられる。
• 1 つのアプリケーションに紐づく環境数やアプリケーションバージョン数などには上限（クォータ）が設定されている。具体的な数値はリージョンや時期で変わり得るため、最新値はサービスクォータの管理画面で確認するのが確実。
• 古いアプリケーションバージョンは S3 に蓄積され続けるため、ライフサイクルポリシーで自動的に古いバージョンを削除しておくと、上限到達やストレージ増加を防げる。
• ソースバンドルのサイズや、利用できるプラットフォームのバージョンには制約がある。プラットフォームには更新やサポート期限の概念があり、古いプラットフォームは段階的に非推奨化される点に留意する。
• サービス自体に追加料金はかからず、課金は生成された EC2 やロードバランサーなどの実リソースに対して発生する。

内部の仕組み

Elastic Beanstalk にアプリケーションバージョンをデプロイすると、サービスは指定された設定とプラットフォームに基づいて環境を構築します。具体的には、AWS CloudFormation を内部的に用いて、EC2 インスタンス、ロードバランサー、Auto Scaling グループ、セキュリティグループ、CloudWatch アラームなどをまとめてプロビジョニングします。生成されたスタックはユーザーのアカウント内に作られるため、各リソースを直接参照・確認できます。

各 EC2 インスタンス上ではホストマネージャー的なエージェントが動作し、アプリのデプロイ、ログの送信、メトリクスの収集、ヘルス情報の報告を担います。Auto Scaling グループとロードバランサーが連携することで、負荷に応じたインスタンスの増減と、健全なインスタンスへのトラフィック振り分けが行われます。

デプロイ時の挙動は選択するデプロイポリシーによって変わります。たとえば、稼働中のインスタンスを順に更新していく方式や、新しいインスタンス群を別途立ち上げてから切り替える方式などがあり、ダウンタイムや切り戻しのしやすさ、コストのバランスを選べます。環境設定を .ebextensions として置けば、これらの構成をコードとしてバージョン管理できます。

設計パターン / ベストプラクティス

• デプロイ方式を要件に合わせて選ぶ。無停止を重視するなら新環境を立ち上げて URL を入れ替える「Blue/Green」方式や、追加インスタンスを用意してから入れ替える方式を選び、コスト優先なら既存インスタンスを順次更新する方式を選ぶ。
• 環境を用途ごとに分ける。開発・検証・本番をそれぞれ別環境とし、本番に近い構成で検証してから昇格させると事故を減らせる。
• 構成は .ebextensions などでコード化し、手作業のコンソール変更に依存しない。再現性と監査性が高まる。
• 非同期処理はワーカー環境に分離する。時間のかかるジョブを Web リクエストから切り離し、キュー経由で処理させることで応答性と安定性が向上する。
• アプリケーションバージョンのライフサイクルポリシーを設定し、古いバージョンを自動削除してクォータ超過とストレージ肥大を防ぐ。

運用・監視

Elastic Beanstalk は環境のヘルスをダッシュボードに集約し、インスタンスの状態やリクエストの成否を色（緑・黄・赤など）で示します。標準のヘルスレポートに加えて拡張ヘルスレポートを有効にすると、レイテンシやエラー率といったより詳細な指標に基づいて健全性を判定できます。

ログは各インスタンスから取得でき、必要に応じて S3 への保存や CloudWatch Logs へのストリーミングを設定できます。メトリクスは CloudWatch に送られるため、CloudWatch アラームと組み合わせて閾値超過の通知やスケーリングのトリガーに利用できます。プラットフォームの更新は管理対象プラットフォームのバージョン更新として提供され、計画的に適用してセキュリティパッチを取り込むことが重要です。

コスト

Elastic Beanstalk のサービス利用そのものに追加料金はありません。費用は、環境として生成された EC2 インスタンス、ロードバランサー、データ転送、ストレージ（アプリケーションバージョンを保管する S3 など）といった実リソースに対して発生します。つまり、料金体系は各下位サービスの通常料金がそのまま適用されると考えるのが基本です。

コストを抑えるには、開発・検証環境を使わないときに停止または終了する、適切なインスタンスタイプを選ぶ、スケーリング条件を見直して過剰なインスタンス数を避ける、といった一般的な最適化が有効です。負荷分散が不要な小規模環境では単一インスタンス構成を選ぶことでロードバランサー分のコストを節約できます。具体的な料金はリージョンや構成で変動するため、見積もりは料金計算ツールで確認してください。

セキュリティ

Elastic Beanstalk の権限は IAM で制御します。サービスがリソースを操作するためのサービスロールと、EC2 インスタンスに付与されるインスタンスプロファイルの 2 系統があり、いずれも最小権限の原則に従って必要な権限だけを与えるのが基本です。アプリが他の AWS サービスへアクセスする場合は、インスタンスプロファイルに該当ポリシーを付与します。

ネットワーク面では、環境を VPC 内に配置し、アプリ層をプライベートサブネットに置いてロードバランサー経由で公開する構成が推奨されます。通信の暗号化はロードバランサーでの HTTPS 終端などで実現し、機密情報は環境変数に平文で置くのではなく、パラメータストアやシークレット管理サービスから取得する設計が望ましいです。

Well-Architected の観点

運用上の優秀性の観点では、デプロイとインフラ構成が自動化・標準化され、設定をコードとして管理できる点が強みです。ヘルスレポートと CloudWatch によって状態の可視化と通知が容易になり、運用負荷を下げられます。一方で、生成されるリソースはユーザー管理下にあるため、過度なブラックボックス化を避けつつ責任範囲を理解しておくことが重要です。

信頼性の面では、複数アベイラビリティーゾーンへの分散や Auto Scaling、ロードバランサーによる耐障害性を比較的容易に得られます。コスト最適化では使った分だけ課金される一方、不要な環境の停止やスケーリング調整が運用者の責任になります。セキュリティはIAM とネットワーク設計で担保し、パフォーマンス効率は適切なインスタンス選択とスケーリング条件で確保します。

試験で問われるポイント

関連サービス・比較

最も比較されやすいのは、コンテナイメージや実行ファイルを渡すだけで動かせるシンプルな実行サービスとの違いです。ここでは AWS App Runner と比較します。Elastic Beanstalk は EC2 ベースで制御性が高く幅広い構成に対応する一方、App Runner はより抽象度が高く運用がほぼ不要なフルマネージド寄りのサービスです。

ハンズオン / CLI例

EB CLI（eb コマンド）を使うと、対話的にアプリケーションと環境を作成してデプロイできます。以下は、プロジェクトディレクトリで初期化し、環境を作成してコードをデプロイする基本的な流れの例です。

# プロジェクトディレクトリで EB CLI を初期化（リージョンとプラットフォームを指定）
eb init my-app --region ap-northeast-1 --platform "Docker"

# ロードバランサー付きの環境を新規作成（初回デプロイも実行される）
eb create my-app-prod

# コードを更新したら現在の環境へデプロイ
eb deploy

# 環境のヘルスとイベントを確認
eb status
eb health

# 動作中のアプリをブラウザで開く
eb open

# 検証が終わったら環境を削除してリソースを片付ける
eb terminate my-app-prod