Amazon Elastic Beanstalk入門｜アプリデプロイをサーバー管理なしで実現するAWS実践ガイド

Webアプリを本番環境に出すとき、EC2のAMI選定、セキュリティグループ設定、ALBのターゲットグループ登録……インフラ側の作業が多すぎて、本来の開発に集中できない、と感じたことはないでしょうか。

オンプレの現場では、アプリのデプロイといえばサーバーOSのセットアップ、ミドルウェアのインストール、ロードバランサーの設定まで含むのが当たり前でした。AWS移行後もその感覚が残り、EC2をゼロから構築しようとしてしまうエンジニアは少なくありません。

この記事では、Amazon Elastic Beanstalk について、オンプレ経験者にもわかりやすく解説します。「インフラを意識せずにWebアプリをデプロイする」とはどういうことか、コンソール操作・料金・実務のコツ・よくあるトラブルまで一通りカバーします。

なぜElastic Beanstalkなのか？（オンプレとの違い）

オンプレでWebアプリをデプロイするまでには、次のような作業が必要でした。

・サーバーOSをインストール・初期設定する
・Apache / nginx / Tomcat などのミドルウェアをセットアップする
・ロードバランサーを設定し、バックエンドサーバーを登録する
・オートスケールが必要なら別途スクリプトや HAProxy で制御する

Amazon Elastic Beanstalk（以下、Elastic Beanstalk）を使うと、こうしたインフラ設定の大半を自動化できます。具体的には、以下のリソースを自動でプロビジョニングします。

・Amazon EC2: アプリの実行環境となるインスタンス
・Elastic Load Balancing（ALB）: 複数インスタンスへの負荷分散
・Amazon EC2 Auto Scaling: トラフィックに応じた自動スケーリング
・Amazon CloudWatch: メトリクス収集・ログ管理
・Amazon S3: デプロイパッケージの一時保管

デプロイはZIPファイルをアップロードするか、EB CLI で1コマンド実行するだけです。EC2やALBの細かい設定を意識しなくて済む分、アプリ開発に集中できます。

対応しているプラットフォームは幅広く、代表的なものは以下のとおりです。

・Python（3.11 on Amazon Linux 2023 など）
・Node.js
・Java（Corretto）
・Ruby
・PHP
・.NET on Linux / Windows Server
・Docker（カスタムプラットフォームも可）

オンプレのAPサーバーで動かしていたアプリをそのまま持ち込めるケースも多く、クラウド移行の第一歩として選ばれやすいサービスです。

基本的な使い方（コンソール操作）

1. アプリケーションの作成

AWSマネジメントコンソールにログインし、「Elastic Beanstalk」を検索して開きます。「アプリケーションを作成」ボタンをクリックし、次の項目を入力します。

・アプリケーション名: 任意の名前（例: my-web-app）
・説明: 省略可

「作成」をクリックするとアプリケーションが作成されます。この段階ではEC2などのリソースはまだ起動しません。

2. 環境の作成とプラットフォームの選択

アプリケーション内に「環境」を作成します。環境がEC2やALBを実際にプロビジョニングする単位です。

「環境を作成」をクリックし、以下を設定します。

・環境タイプ: 「ウェブサーバー環境」（Webアプリ向け）または「ワーカー環境」（非同期バッチ処理向け）
・プラットフォーム: アプリの実行環境（例: Python 3.11 on Amazon Linux 2023）
・アプリケーションコード: サンプルアプリ、またはZIPファイルをアップロード
・プリセット: 「シングルインスタンス」（開発用・無料枠対応）または「高可用性」（ALB + Auto Scaling）

本番環境では「高可用性」プリセットを選択し、東京リージョン（ap-northeast-1）の複数アベイラビリティゾーンに分散起動することを推奨します。

3. アプリケーションのデプロイ

環境が作成されると、EC2・ALB・Auto Scaling が自動でプロビジョニングされます（通常5～10分）。

アプリを更新してデプロイするには、コンソールから「新しいバージョンをアップロードしてデプロイ」を選ぶか、EB CLI を使います。

# EB CLIのインストール
pip install awsebcli

# プロジェクトのルートディレクトリで初期化（リージョン: 東京）
eb init -r ap-northeast-1

# 環境の作成（初回のみ）
eb create my-production-env

# アプリの更新をデプロイ
eb deploy

EB CLI を使うと、Git との連携や CI/CD パイプラインへの組み込みがしやすくなります。

料金の仕組み（コスト感覚）

Elastic Beanstalk 自体の利用料金は無料です。課金されるのは、Elastic Beanstalk が作成する各AWSリソースの利用料金のみです。

主な費用の内訳（2026年3月時点・東京リージョン）：

・Amazon EC2: インスタンスタイプと稼働時間に応じた料金（例: t3.micro は約$0.0134/時間）
・Elastic Load Balancing（ALB）: 約$0.008/LCU/時間 + 固定費用（本番環境では月額$15前後）
・Amazon S3: デプロイパッケージの保管料金（通常数円/月）
・Amazon CloudWatch: ログ保存量に応じた料金

開発環境では「シングルインスタンス」プリセットで運用すれば ALB 料金を省けます。t3.micro 1台ならAWS無料枠（新規アカウント12か月）の範囲内で試せます。

本番環境の最低構成（t3.small × 2台 + ALB）では月額$60前後が目安です。EC2インスタンスをリザーブドインスタンスに切り替えると、最大40～60%のコスト削減が見込めます。

応用・実務Tips

【Tips 1】.ebextensionsでカスタム設定をコード化する

Elastic Beanstalk では `.ebextensions/` ディレクトリに YAML ファイルを置くことで、OSレベルのパッケージインストールや環境変数をコードで管理できます。

# .ebextensions/packages.config の例
packages:
  yum:
    git: []
    jq: []

option_settings:
  aws:elasticbeanstalk:application:environment:
    APP_ENV: "production"
    LOG_LEVEL: "warn"

オンプレで Ansible や Salt Stack を使っていたような役割を担います。設定ファイルをアプリのコードと一緒にバージョン管理できるため、環境の再現性が高まります。

【Tips 2】本番・ステージング環境を分離する

1つのアプリケーション内に複数の環境を作成できます。「production」と「staging」を別環境として持てば、デプロイ前の動作確認がしやすくなります。

環境ごとにEC2インスタンスタイプ・Auto Scaling の設定・環境変数を個別に変えられるため、コストを抑えながら本番に近い構成でテストできます。

【Tips 3】デプロイポリシーを使い分ける

本番環境へのデプロイ方法は4種類から選択できます。

・All at once: 全インスタンスを同時更新（一時ダウンタイムあり、開発向け）
・Rolling: バッチ単位で順次更新（ダウンタイムなし）
・Rolling with additional batch: バッチを追加しながら更新（キャパシティを維持）
・Immutable: 新インスタンスに更新後、旧インスタンスを削除（最も安全）

オンプレのリリース作業では「全台止めて入れ替え」が多かったと思いますが、クラウドでは Rolling 以上のポリシーを選ぶことでダウンタイムゼロのデプロイが実現できます。

よくあるトラブルと対処法

環境のHealthが「Degraded」になった

デプロイ後にHealthステータスが黄色（Warning）や赤（Degraded/Severe）に変わった場合は、まずElastic BeanstalkコンソールのログとAmazon CloudWatch Logsを確認します。

アプリ側の起動エラー（ポート番号の不一致、必要な環境変数の未設定など）が原因のことがほとんどです。Elastic Beanstalk はデフォルトで以下のポートにアクセスします。

・Python / Node.js / Ruby: ポート5000
・Java（Tomcat）: ポート8080
・Docker: ポート80（EXPOSE の設定による）

アプリ側のリッスンポートと一致しているかを最初に確認してください。

デプロイが途中で止まる、または遅い

ZIPファイルのサイズが大きすぎると、デプロイが遅延することがあります。`node_modules/` や `.git/` を `.ebignore` に記載してアップロード対象から除外することを推奨します。

# .ebignore の例（.gitignore と同じ書式）
.git
node_modules
tests
*.log
__pycache__
.env

環境変数の変更が反映されない

コンソール上で環境変数を変更した後、「適用」ボタンを押すと環境の再起動が走ります。設定変更は即時ではなく、再起動完了まで数分かかります。緊急時は「環境の再起動」を手動で実行して強制反映することもできます。

本記事のまとめ

Elastic Beanstalk の特徴と操作の要点を整理します。

「インフラを全部自分で設定したい」というオンプレ経験者にとって、最初は物足りなく感じるかもしれません。ただ、デプロイとスケーリングを自動化することで本来の開発に集中できる環境が手に入ります。インフラの細かい制御が必要になったときは、.ebextensions やカスタムAMI、EC2 Auto Scaling の Launch Template で補っていくのがバランスのいいアプローチです。

Linuxサーバーとしての基本設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。