AWS Elastic Beanstalkとは？仕組み・対応プラットフォームと料金・採用判断を実装者目線で解説

AWS Elastic Beanstalkは、書いたコードをアップロードするだけで、サーバー・ロードバランサー・オートスケーリングまでをAWSが用意してくれるPaaS（Platform as a Service）です。この記事では、構成要素と裏で起動するAWSリソース、2026年9月時点の対応プラットフォーム版数、EB CLIでのデプロイ手順、.ebextensionsによる設定のコード化、デプロイポリシーの選定、Worker環境の設定値、料金と退役ポリシーを一次情報で整理します。

まとめ：Elastic Beanstalkの仕組み・料金と採用判断の要点

Elastic Beanstalkは、コードを渡すと実行に必要なEC2インスタンス、ELB（ロードバランサー）、Auto Scaling、ヘルス監視までを自動で構成するマネージドサービスです。生成されるのは標準的なAWSリソースそのもので、必要になれば個々のEC2やセキュリティグループへ踏み込む余地も残されています。

料金はBeanstalkの機能に対しては発生せず、起動したEC2・ELB・RDSといった基盤リソースの分だけを支払う形です。実務で効くのはEB CLIによる環境作成とデプロイの型、.ebextensionsで設定をGit管理下に置く運用、デプロイポリシーの選定の3点。定型的なWebアプリを素早く立ち上げる場面には向く一方、コンテナを束ねたいならECS／EKS、イベント駆動ならLambdaのほうが噛み合います。

Elastic Beanstalkの仕組みと構成要素・裏で起動するAWSリソース

Beanstalkを設計へ落とすには、抽象化された概念モデルと、裏で起動するAWSリソースの二層を対応づけて押さえます。ここが曖昧だと何が生成されたのかを見失います。

Application・Environment・Platformの3概念と保存設定

最上位の入れ物がApplicationで、その中に実際に動く単位であるEnvironmentを複数持たせます。デプロイするコードのまとまりはApplication versionとして管理され、環境がどの言語・ランタイムで動くかを決めるのがPlatformです。AWS公式の概念解説もこの3階層を中心に置いています。設定一式はSaved configurationとして保存でき、EB CLIからは.elasticbeanstalk/saved_configs/配下のファイルを--cfgで指定して再利用します。

裏で起動するEC2・ELB・Auto Scalingと生成リソースの確認

「自動で構成する」と言うとき、実体として生成されるのは通常のAWSリソースです。WebアプリならAmazon EC2の仕組みを解説した記事で扱うEC2が起動し、複数台をELBで振り分け、Auto Scalingが台数を伸縮させます。データベースはAmazon RDSの仕組みを解説した記事のマネージドDBを紐付けられますが、公式のDB構成ガイドのとおり環境と同じライフサイクルで作るとDBが環境削除とともに消えます。本番では独立したRDSを別管理にしてください。

Beanstalkの対応プラットフォームと2026年9月時点の現行版数

Beanstalkをどのアプリに使えるかは、対応プラットフォームの現行版数で決まります。版数は定期的に入れ替わるため、採用検討の時点で公式一覧を引き直します。

AL2023で提供される言語プラットフォームと現行版数の対応一覧

公式に用意されるのは、Go、Java SE、Tomcat、.NET Core on Linux、.NET on Windows Server、Node.js、PHP、Python、Ruby、そして任意のイメージを動かせるDockerです。Windows Server版を除きAmazon Linux 2023系で提供され、AWS公式のサポート対象プラットフォーム一覧で確認した現行版数は次のとおりです。

目立つのはNode.jsです。AL2023では1つのプラットフォーム版につき1系統だけになり、現行は24系と22系の2本。20系以前を前提にしたアプリは、更新の前にpackage.jsonのバージョン指定を外します。

DockerとECSプラットフォームの守備範囲とWindows版の制約

独自のミドルウェア構成が要るなら、Dockerプラットフォームでコンテナ化して持ち込みます。Docker 25.0.16とDocker Compose 5.5.1を同梱し、nginxを前段に置く構成です。別枠の「ECS AL2023」はECS Agent 1.106.1を載せ、複数コンテナを1環境で動かす用途に向きます。単一イメージならDocker、複数コンテナの協調が要るならECSプラットフォームの順で見ると迷いません。一方、.NET on Windows Serverは公式ドキュメントがworker環境をサポートしないと明記しており、非同期処理はLinux側の別環境へ逃がす設計が要ります。

EB CLIで環境を作成しアプリをデプロイするまでの実作業手順

Beanstalkの評価は、コンソールを眺めるよりEB CLIで一度環境を作るほうが早く固まります。初期化から本番相当の環境作成、反映と確認までをコマンドで示します。

EB CLIの導入とeb initでアプリを初期化するまでのコマンド

EB CLIはPython製のコマンドラインツールで、AWSはaws-elastic-beanstalk-cli-setupのセットアップスクリプト経由での導入を案内しています。仮想環境を分離する作りのため、既存のPython環境と依存が衝突しにくい点が利点です。

git clone https://github.com/aws/aws-elastic-beanstalk-cli-setup.git
python ./aws-elastic-beanstalk-cli-setup/scripts/bundled_installer

eb --version
eb init sample-web -p "Python 3.13" --region ap-northeast-1
eb platform list

指定するプラットフォーム名は前章のブランチ名に対応します。版数まで固定するなら"64bit Amazon Linux 2023 v4.13.8 running Python 3.13"のようにソリューションスタック名を渡せます。

eb createで環境を作りeb deployで反映するまでのコマンド

環境の作成はeb createです。引数なしなら対話モードに入りますが、再現性を確保するならオプションで指定し切ります。公式のeb createリファレンスによれば、ロードバランサー種別の既定値はapplication、インスタンス数の既定は最小1・最大4、環境名は4〜40文字という制約。公式は単一インスタンス環境が本番向けではないとも明記しています。

eb create prod-web --elb-type application --min-instances 2 --max-instances 6 --instance_type t3.small --envvars APP_ENV=production --tags Env=prod --timeout 20
eb create prod-worker --tier worker --min-instances 1 --max-instances 4

eb deploy prod-web --timeout 20
eb status prod-web
eb health prod-web --refresh
eb logs prod-web --all
eb events prod-web -f

デプロイごとにデプロイIDが1から連番で振られ、拡張ヘルスレポートを有効にしていればコンソールとEB CLIの双方に表示されます。ローリング更新が失敗したとき、どのIDまで進んだかで状態を切り分けられる仕組み。失敗時にまず見るのはeb eventsの出力です。

.ebextensionsとProcfileで環境設定をコード化する書き方

環境の細かな設定は、ソースコードに設定ファイルを同梱して宣言的に反映します。コンソールで手作業した設定は再現できないため、Git管理下のファイルへ寄せます。

.ebextensions配下のconfigファイルの命名規則と記述ルール

設定ファイルは.ebextensionsという名前のフォルダに置き、拡張子を.configにします。公式の設定ファイル解説はYAMLを推奨し、同一ファイル内で同じキーを2回使うとどちらかのセクションが捨てられると警告しています。ドット始まりのフォルダがzipから除外されないかも確認してください。

files:
  "/etc/nginx/conf.d/client_max.conf":
    mode: "000644"
    owner: root
    content: |
      client_max_body_size 20M;

option_settings:
  aws:elasticbeanstalk:environment:
    LoadBalancerType: application
  aws:elasticbeanstalk:command:
    DeploymentPolicy: Immutable
    Timeout: "1800"
  aws:autoscaling:asg:
    MinSize: "2"
    MaxSize: "6"

container_commands:
  01_migrate:
    command: "python manage.py migrate --noinput"
    leader_only: true

新しい設定ファイルは、本番ではなく空の検証環境へ先に流します。書式を誤った設定ファイルは環境の新規作成を回復不能な形で失敗させる、と公式が明示しているためです。

ProcfileとBuildfile・platform hooksの役割分担と権限設計

プロセスの起動コマンドはProcfile、ビルド手順の指定はBuildfileが担います。デプロイの各段階に割り込むなら、Amazon Linux 2以降で使えるplatform hooks（.platform/hooks/prebuildなどに置く実行可能スクリプト）を使う形。権限は環境のインスタンスプロファイルとサービスロールで制御されるため、AWS IAMのロールとポリシーを解説した記事で最小権限の考え方を押さえておくと安全です。本番では自動生成に任せず、必要なアクションだけを明示したロールを先に用意します。

デプロイポリシー5種の挙動・失敗時の影響と安全な切り戻し手順

新しいバージョンをどう反映するかは、デプロイポリシーで選べます。可用性要件と切り戻しやすさのトレードオフで決まり、既定のまま本番へ出すと事故になります。

All at onceからImmutableまでの挙動と所要時間・失敗時の影響

全台を一度に入れ替えるAll at onceは最速ですが、Webプロキシやアプリケーションサーバーの再起動を伴うため短時間のダウンタイムが出ます。Rollingは数台ずつ更新して完全停止を避け、Rolling with additional batchは一時的に台数を増やして帯域を保つ方式。Immutableは第2のAuto Scalingグループを立てて新旧を並走させるので、失敗しても新インスタンスを終了させるだけで戻せます。公式のデプロイ方式比較表を実務で見る順に並べ直したのが次の表です。

単一インスタンス環境ではRolling系を選べません。All at onceかImmutableの二択になる点を設計時に押さえます。

Traffic splittingとCNAMEスワップの使い分けと副作用の注意

Traffic splittingはApplication Load Balancerを使うロードバランス環境でのみ選べるカナリア方式で、一部のトラフィックだけ新バージョンへ流して健全性を見ます。評価時間の設定次第で所要時間が伸びるため、緊急のホットフィックスには向きません。リソース構成そのものを変える更新では、環境を複製してCNAMEスワップによるBlue/Greenデプロイへ切り替えます。副作用も1つ。Immutable更新、Traffic splitting、インスタンス置換を伴うマネージド更新では、蓄積したEC2のバーストバランスが失われます。T系でCPUクレジットに依存した構成なら、性能低下を見込んでください。

Worker環境でSQSの非同期処理と定期タスクを組むための設定値

環境には2種類あります。Web server environmentはELB経由でHTTPリクエストへ即時応答する構成、Worker environmentはSQSキューのメッセージをsqsdデーモンが取り出してアプリへ渡す構成です。画像変換やメール送信はWorker側へ逃がします。

sqsdがPOSTする宛先ポートとHTTPヘッダ・タイムアウト既定値

sqsdはメッセージを取り出すと、本文をボディに入れてhttp://localhost/のポート80へHTTP POSTを送ります。公式のWorker環境ガイドは、POST先のパスやMIMEタイプは変更できるがポート番号は変更できないと明記。アプリが200 OKを返すとsqsdがSQSへDeleteMessageを発行し、それ以外の応答ならErrorVisibilityTimeoutの経過後にメッセージがキューへ戻ります。X-Aws-Sqsd-Receive-Countヘッダの受信回数は冪等性の判定に使えます。

処理に3分以上かかるジョブなら、Inactivity timeoutの既定180秒では応答前に打ち切られます。実測時間より長い値へ引き上げてください。自動生成キューを選んだWorker環境にはデッドレターキューが既定で付き、無効化はできません。

cron.yamlで定期タスクを定義する書き方とリーダー選出の仕組み

定期実行はソースバンドルにcron.yamlを置いて宣言します。タスクごとにPOST先のパスとcron式を書くと、sqsdがスケジュールどおりにキューへメッセージを積む流れ。キューイング役はDynamoDBへの書き込みによるリーダー選出で決まり、リーダーが落ちれば別のインスタンスが引き継ぎます。

version: 1
cron:
 - name: "backup-job"
   url: "/backup"
   schedule: "0 */12 * * *"
 - name: "audit"
   url: "/audit"
   schedule: "0 23 * * *"

注意点は2つ。タスク名は一意にすること、そしてWorker環境に既存のSQS FIFOキューを割り当てた場合は定期タスクがサポートされないことです。

Elastic Beanstalkの料金の考え方とコスト圧縮・退役への備え

Beanstalkのコストは、サービス機能そのものではなく生成される基盤リソースで決まります。ここを取り違えると「PaaSだから割高では」という誤解につながります。

Beanstalk自体は追加料金なし・課金対象とコスト圧縮の手順

AWS公式の料金ページは「There is no additional charge for AWS Elastic Beanstalk.」と明記し、支払うのはアプリの保存と実行のために作成したAWSリソース分だけだとしています。内訳はEC2インスタンス、Elastic Load Balancing、帯域、データベースやストレージで、最低料金も前払いもなし。EB CLIの--enable-spotと--on-demand-base-capacityを使えば、ベースだけオンデマンドで確保して超過分をスポットへ寄せられます。使わない検証環境はeb terminateで終了させ、Saved configurationから再作成する運用にすると常時課金を避けられるでしょう。

プラットフォーム退役の90日猶予期間とマネージド更新の設定手順

見落とされやすいのがプラットフォームの寿命です。公式のプラットフォームサポートポリシーによれば、OS・ランタイム・アプリケーションサーバー・Webサーバーのいずれかが提供元からEOL扱いになると、そのプラットフォームブランチは退役になります。退役後はセキュリティ更新とテクニカルサポートが止まり、新規環境への提供も終了。既存環境には公開退役日から90日の猶予期間が設けられますが、更新の止まった状態で動き続ける点が実務上のリスクです。対策は2つで、マネージドプラットフォーム更新を有効にすること、四半期ごとに公式の退役予定一覧と自社環境の版数を突き合わせることです。

Beanstalkを採用すべき条件と他のAWSサービスとの使い分け

ここでは判断を言い切ります。Beanstalkは対応プラットフォームの枠内で使うほど恩恵が大きく、枠を外れるほど別サービスが素直です。

Beanstalkの採用が効くワークロードの条件と設計上の勘所

採用が効くのは、標準的な言語・フレームワークで書いたWebアプリを、インフラ専任を置かずに素早く本番へ載せたいという条件が重なるときです。社内向けの業務Webアプリ、スタートアップのMVP、PoCから小規模本番までの立ち上げが当てはまります。分岐点は、対応プラットフォームの現行版数に自社のランタイムが収まるかどうか。こうしたAWS上のインフラ構築を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で、Beanstalkと素のEC2・コンテナ基盤のどれが自社の運用体制に噛み合うかを相談すると、構成とコストの見通しを立てやすくなります。Beanstalkはクラウドネイティブの構成技術を整理した記事で言うところの、まずマネージドに寄せて運用負荷を下げるための入口です。

ECS/EKS・Lambda・App Runnerへ寄せるべき場面の判断基準

要件が枠を外れるなら、無理にBeanstalkで抱えないほうが素直です。コンテナを複数サービスで束ねたいならAmazon EKSの仕組みとECSとの使い分けを解説した記事のコンテナ基盤、断続的なイベント処理で常時課金を避けたいならAWS Lambdaの仕組みと採用判断を解説した記事のサーバーレスが向きます。コンテナ化済みのWebアプリを薄く載せたいだけならAWS App Runner、他クラウドまで視野に入れるならCloud Run（GCPのサーバーレスコンテナ）を解説した記事との比較が有効です。

Beanstalkを見送るべき場面とはまりやすい失敗パターン2つ

見送るべきなのは、細かなインフラ制御をコードで完全に握りたいケース、多数のマイクロサービスをコンテナで束ねて運用したいケース、完全なサーバーレスでインスタンスの存在自体を意識したくないケースです。抽象化がかえって足かせになります。はまりやすい失敗は2つ。1つ目は本番DBを環境と同じライフサイクルで作り込み、環境の作り直しでデータを失う構成。2つ目は生成されたEC2やセキュリティグループを把握せず、コストやセキュリティのブラックボックス化を招くことです。この2点を守れば手軽さを安全に引き出せます。

よくある質問

導入検討で実装者から多く挙がる質問を、一次情報に基づいて整理します。

Elastic BeanstalkとECS/EKSはどちらを選ぶべきですか？

標準的なWebアプリを手早く載せたいならBeanstalk、コンテナを複数サービスで本格的にオーケストレーションしたいならECSやEKSが基本の分岐です。BeanstalkにもDockerプラットフォームとECSプラットフォームがありますが、サービス間連携やきめ細かなスケジューリングを詰めるならコンテナ基盤のほうが表現力で勝ります。

Elastic Beanstalkの利用に追加料金はかかりますか？

かかりません。公式の料金ページは追加料金が無いと明記しており、課金対象は環境が起動したEC2・ELB・帯域・データベースやストレージの使用料だけです。同じ構成を手作業で組んだ場合と基盤側のコストは同じで、EC2のSavings Plansやスポットといった割引もそのまま適用できます。

本番稼働で無停止デプロイはできますか？

できます。RollingやRolling with additional batchで数台ずつ更新すれば完全停止を避けられ、Immutableなら新旧を並走させて失敗時は新インスタンスを終了させるだけで戻せます。ただし単一インスタンス環境ではRolling系を選べず、All at onceかImmutableの二択。DNS切替を許容できるならBlue/Greenも選択肢です。

バックグラウンドの重い処理はどう組めばよいですか？

Worker environmentを使います。SQSキューにメッセージを積むと、環境内のsqsdデーモンが取り出してポート80へHTTP POSTし、アプリが200を返した時点でキューから削除される流れです。既定のInactivity timeoutは180秒なので、それより長いジョブは値を引き上げてください。定期実行はcron.yamlで宣言できます。

使っているプラットフォームが退役したらどうなりますか？

環境は動き続けますが、セキュリティ更新とテクニカルサポートが止まります。公開退役日から90日の猶予期間が設けられますが、脆弱性の修正が届かない状態が続く点に注意してください。マネージドプラットフォーム更新を有効にして先回りするのが基本で、動かせない場合はDockerイメージ化して載せ替える方法が公式に案内されています。

関連記事

• クラウドネイティブとは？CNCFの定義・構成技術と導入判断を解説：Beanstalkが入口となる全体像
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を解説：裏で起動する仮想サーバーの料金モデル
• Amazon EKSとは？仕組み・ノード提供形態とECSとの使い分けを解説：コンテナを本格的に束ねる場合の寄せ先
• AWS Lambdaとは？仕組み・料金体系と採用判断を解説：常時課金を避けるサーバーレスへの分岐
• Cloud Runとは？GCPのサーバーレスコンテナの仕組みと違いを解説：他クラウドの基盤との比較軸