AWS Elastic Beanstalkとは ― コードを渡して動かす
AWS Elastic Beanstalkとは、
AWS Elastic Beanstalkとは、コードを渡すとWebアプリを動かす環境を用意するサービス
AWS Elastic Beanstalkは、実行に必要なサーバ一式をまとめて用意するAWSのサービスです。利用者はWebアプリのコードを渡します。EC2インスタンスの起動・ロードバランサの設定・負荷に合わせた台数の調整を、Beanstalkが行います。
EC2だけでWebアプリを公開するときは、インスタンスとロードバランサとAuto Scalingを自分で組み合わせます。Beanstalkを使えば、その構築を任せて、コードを書くことに集中できます。Beanstalk自体に料金はかからず、作られたEC2などの料金だけを払います。
PaaSとしての位置づけは、OSから下の構築を任せること
クラウドのサービスは、利用者が管理する範囲でIaaS・PaaS・SaaSに分けられます。この分類では、Beanstalkは、アプリを配置すれば動く環境を借りるPaaSに近いサービスです。利用者が主に扱うのは、自分のアプリと、それを動かす環境の設定です。
ただし、Beanstalkが作るEC2インスタンスなどは、利用者のAWSアカウントの中に置かれます。AWSのFAQは、ほかのPaaSと比べたBeanstalkの違いとして、利用者がリソースを制御できる点を挙げています。作られたリソースは確認でき、あとから自分で調整できます。
OSや言語のランタイムの更新版は、Beanstalkが定期的に出します。コンソールで作った環境では、マイナー版とパッチ版の更新を自動で適用する設定が最初から有効です。適用は週に1回の時間帯に行います。AWSと利用者の担当の分け方は、責任共有モデルの記事で説明しています。
裏で作られるのは、EC2・ELB・Auto Scalingなどの見えるリソース
Beanstalkを使うときは、まずアプリケーションを作り、コードをまとめたファイルを渡します。すると、Beanstalkはコードの実行に必要なリソースを作成して設定します。そのリソースの集まりを、環境と呼びます。
Webアプリ向けの環境では、ロードバランサ・Auto Scalingグループ・1台以上のEC2インスタンスが作られます。ロードバランサはインスタンスの手前に置かれ、届いた通信を振り分けます。負荷が増えるとAuto Scalingがインスタンスを追加し、負荷が減ると停止します。ただし、最低1台は動かし続けます。
環境ごとに、Beanstalkが用意したURLが1つ付きます。このURLは、Route 53のCNAMEレコードでロードバランサを指しています。各インスタンスでは、ホストマネージャというBeanstalkのソフトウェアが動きます。ホストマネージャは、アプリの配置や、ログをS3に保存する作業を受け持ちます。
| 用語 | 意味 |
|---|---|
| アプリケーション | 環境や |
| アプリケーションバージョン | デプロイできる |
| 環境 | 1つの |
| プラットフォーム | OS・言語の |
インスタンスタイプや台数の下限と上限は、環境の設定で変更できます。オンデマンドのほかに、リザーブドインスタンスやスポットインスタンスも使えます。インスタンスを1台だけ動かす環境も作れます。その場合は、ロードバランサを置きません。
データベースが必要なときは、Amazon RDSのDBインスタンスを環境に追加できます。選べるエンジンは、MySQL・PostgreSQL・Oracle・SQL Serverです。Beanstalkは、接続先のホスト名やパスワードなどを環境変数にしてアプリに渡します。
環境に追加したデータベースは、その環境と一体で管理されます。本番に移行するときは、データベースを環境から切り離せます。Beanstalkの外のRDSとして使う方法を、開発者ガイドが示しています。切り離すと、複数の環境から同じデータベースに接続できます。切り離すときや環境を削除するときに、データベースを残すか、スナップショットを取って削除するかなどを選べます。
Beanstalkには、この記事で扱うStandardのほかに、Clusterという動かし方もあります。Clusterでは、BeanstalkがAmazon EKSのクラスターを作って運用します。アプリはコンテナとして動きます。EKSとECSの違いは、Amazon ECSの記事を読むと分かります。
Webサーバ環境とワーカー環境の違いは、処理の受け取り方
Beanstalkの環境を作るときは、最初に環境の種類を選びます。HTTPの要求に応答するアプリは、Webサーバ環境で動かします。キューからタスクを取り出して処理するアプリは、ワーカー環境で動かします。前の節で説明した構成は、Webサーバ環境のものです。
ワーカー環境は、時間のかかる処理をWebのアプリから切り離すために使います。画像や動画の加工・メールの送信・ZIPファイルの作成などが、その例です。WebのアプリはタスクをAmazon SQSのキューに入れ、すぐに利用者へ応答を返します。
ワーカー環境の各インスタンスでは、Beanstalkのデーモンが動きます。デーモンはキューからタスクを取り出します。その内容を、HTTPのPOSTで同じインスタンスのアプリに送ります。アプリが200 OKを返すと、デーモンはキューからそのタスクを削除します。
200 OK以外が返ったときは、設定した時間がたってから、タスクがキューに戻ります。そのため、処理に失敗したタスクは、あとで再び取り出されます。ワーカー環境では、cronの書式で指定した日時にタスクをキューへ入れる、定期的なタスクも実行できます。
対応する言語と、新しい版を配置するデプロイの方法
Beanstalkが対応する言語は、Go・Java・.NET・Node.js・PHP・Python・Rubyです。Dockerのコンテナにも対応していて、その場合は言語やライブラリを自分で選べます。言語ごとに、OSとランタイムとWebサーバを組み合わせたプラットフォームが用意されています。
コードは、ZIPかWARの1つのファイルにまとめて渡します。このファイルをソースバンドルと呼びます。大きさは500MBまでです。渡したソースバンドルはS3に置かれ、アプリケーションバージョンとして記録されます。
操作には、Beanstalkのコンソールのほか、AWS CLIや専用のEB CLIを使えます。環境の構成をテンプレートに書いて、CloudFormationで作ることもできます。
動いている環境に新しい版を配置することを、デプロイと呼びます。デプロイの方式は、新しい版を既存のインスタンスに配置するか、新しいインスタンスに配置するかで分かれます。既定の方式は、すべてのインスタンスに一度に配置する方式です。EB CLIで作った、台数を増やせる環境では、既定がローリングになります。
| 方式 | 新しい | 動作 |
|---|---|---|
| 一度に | 今の | 最も |
| ローリング | 今の | 数台ずつ |
| 追加バッチ | 新しい | 先に |
| イミュータブル | 新しい | 別の |
| トラフィック分割 | 新しい | 指定した |
| ブルー/グリーン | 別の | 新しい |
一度にすべて配置する方式は速い代わりに、入れ替えの間はアプリが止まることがあります。止めたくなければ、ローリングかイミュータブルを選びます。トラフィック分割を使えるのは、ロードバランサにApplication Load Balancerを使う環境です。
ブルー/グリーンは、Beanstalkの設定項目ではなく、環境を2つ使うやり方です。新しい版を別の環境で動かして確認します。そのあと2つの環境のURLを入れ替えて、通信を新しい版に移します。DNSのキャッシュが古い情報を返す期間があるので、古い環境はすぐに削除せずに残しておきます。
料金は、Beanstalk自体は無料で、作られたリソースの料金を払う
Elastic Beanstalkそのものには、追加料金がかかりません。かかるのは、環境のために作られたEC2インスタンスやロードバランサ、S3のバケットなどの料金です。最低料金や前払いはなく、使った分だけを払います。
そのため、同じ構成をEC2で構築した場合と、リソースの料金の決まり方は変わりません。たとえば、インスタンス2台とロードバランサ1つの環境なら、その2台と1つの料金がかかります。インスタンスの基本的なメトリクスは無料です。詳細な監視やログの保存には、CloudWatchの料金がかかります。
インスタンスを安く使う購入方法は、AWSの料金の記事にまとめています。単価は、Elastic Beanstalkの料金ページと、各リソースの料金ページで確認してください。
EC2・ECS・Lambdaとの使い分けは、管理したい範囲で決まる
AWSでアプリを動かす方法は、利用者が自分で管理する範囲の広さで並べられます。EC2は、OSから利用者が管理します。Lambdaは、関数のコードだけを管理します。Beanstalkは、その間でWebアプリのコードと環境の設定を管理する方法です。
次の図で自分で管理したい範囲を選ぶと、向いている選択肢と担当の分かれ方が表示されます。
- 物理サーバと
仮想化の 基盤
- OSの
設定と 更新 - ロードバランサと
Auto Scalingの 組み合わせ - アプリの
配置
- EC2・ロードバランサ・Auto Scalingの
作成と 設定 - アプリの
配置と 健康状態の 監視 - プラットフォームの
更新版を 出す こと
- アプリの
コード - 言語などの
プラットフォームの 選択 - インスタンスタイプや
台数の 範囲
- サーバの
用意と OSの 保守 - サーバの
台数の 見積もりと 調整
- コンテナの
イメージ - タスク定義での
CPU・メモリなどの 指定 - 動かすタスクの
数
- サーバと
OSの 保守 - 容量の
確保と 台数の 調整
- 関数の
コード - メモリの
量と タイムアウトの 設定 - トリガーの
設定
| 項目 | EC2 | Elastic Beanstalk | ECS | Lambda |
|---|---|---|---|---|
| 利用者が | OSの | ZIPなどに | コンテナの | 関数の |
| ロードバランサと | 自分で | 環境を | サービスに | AWSが |
| 向く | OSから | 一般的な | コンテナに | イベントの |
| 料金が | インスタンスを | 作られた | 要求した | リクエストの |
アプリをコンテナにまとめているなら、ECSも候補になります。イベントのたびに短く動く処理なら、Lambdaが向きます。月額の料金が決まっているAmazon Lightsailも選択肢です。AWSの決定ガイドは、Beanstalk・EC2と並べて挙げています。
参考にした資料
- AWS「What is AWS Elastic Beanstalk?」(Beanstalkの定義、StandardとCluster、対応する言語、操作の方法、料金)
- AWS「Understanding concepts in Elastic Beanstalk」(アプリケーション・バージョン・環境・環境の種類・プラットフォーム)
- AWS「Elastic Beanstalk web server environments」(作られるリソース、環境のURL、ホストマネージャ)
- AWS「Elastic Beanstalk worker environments」(ワーカー環境のデーモン、POSTでの受け渡し、定期的なタスク)
- AWS「Adding a database to your Elastic Beanstalk environment」(環境に加えるRDSと、切り離して使う方法)
- AWS「Create an Elastic Beanstalk application source bundle」(ソースバンドルの形式と大きさ)
- AWS「Deploying applications to Elastic Beanstalk environments」・「Deployment policies and settings」(デプロイの方式の違い)
- AWS「Blue/Green deployments with Elastic Beanstalk」(URLの入れ替え)
- AWS「Managed platform updates」(プラットフォームの更新版と、自動で当てる設定)
- AWS「The Amazon EC2 instances for your Elastic Beanstalk environment」・「Auto Scaling your Elastic Beanstalk environment instances」(インスタンスの設定と買い方、台数の範囲)
- AWS「Elastic Beanstalk cluster environments」(Clusterの動かし方)
- AWS「AWS Elastic Beanstalk FAQs」(ほかのPaaSとの違い)
- AWS「AWS Elastic Beanstalk Pricing」(料金の決まり方。2026-10-30確認)
- AWS「Amazon Lightsail, AWS Elastic Beanstalk, or Amazon EC2?」(3つのサービスの選び方)
練習問題(全5問)
正解:コードを
Elastic Beanstalkは、
正解:Beanstalk自体の
Beanstalk自体に
正解:EC2上の
ワーカー環境では、
正解:イミュータブル
イミュータブルでは、
正解:利用者の
Beanstalkは、
選んでから「採点する」を押すと、解説つきで答え合わせができます。