概要
Web アプリケーションを AWS で公開しようとすると、EC2 インスタンスの起動、Web サーバーのインストール、セキュリティグループの設定、台数を保つ仕組みづくりなど、アプリケーションのコード以外の準備がたくさん必要になります。
AWS Elastic Beanstalk は、アプリケーションのコードをアップロードするだけで、それを動かすための EC2 インスタンスや Auto Scaling グループ、必要に応じてロードバランサーまでを自動で用意してくれるサービスです。インフラの細かい準備を任せて、アプリケーションの開発とデプロイに集中できます。Elastic Beanstalk 自体に追加料金はかからず、作成された EC2 インスタンスなどのリソースに対してだけ料金が発生します。
この記事では、PaaS という考え方と、Elastic Beanstalk が裏で作るリソース、環境タイプ、プラットフォーム、デプロイポリシーの基本を押さえます。そのうえで、記事内の小さな PHP ファイルを zip にしてアップロードし、低コストな単一インスタンス環境で公開します。続けてアプリケーションの新しいバージョンをデプロイし、環境のイベントとヘルスを確認します。EC2 インスタンスの基本は Amazon EC2 でインスタンスを起動しSSH接続する、Elastic Beanstalk が内部で使う CloudFormation は AWS CloudFormation でテンプレートからリソースを作成する で扱っています。
クラウドおさる今日は「コードを渡すだけでサーバーが立つ」という話を確かめるのでござる。猿山でいえば、バナナの苗を長老会に預けるだけで、畑の開墾から水やり当番の手配までやってもらえるようなものでござるな！
この記事のメリット
- PaaS とは何か、Elastic Beanstalk が EC2 や IaaS とどう違うかを理解できる
- アプリケーション・アプリケーションバージョン・環境・プラットフォームの関係を把握できる
- Elastic Beanstalk が裏で作るリソース（EC2・Auto Scaling・ELB・CloudFormation など）を理解できる
- 単一インスタンス環境と負荷分散環境の違い、デプロイポリシー（All at once・Rolling・Immutable・Blue/Green）の使い分けを把握できる
- zip をアップロードしてアプリを公開し、新しいバージョンをデプロイする流れを体験できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
PaaS と Elastic Beanstalk
クラウドおさるとひさん、Elastic Beanstalk は「PaaS」だと聞いたでござる。PaaS とは何でござるか？
土肥PaaS は Platform as a Service の略だよ。ハードウェアや OS みたいな下回りのインフラを自分で管理しなくてよくて、アプリケーションのデプロイと管理に集中できるクラウドの使い方なんだ。AWS の資料でも、PaaS の例として Elastic Beanstalk が挙げられているよ。
クラウドおさるEC2 とは何が違うのでござる？ EC2 でもサーバーは借りられるでござるよ。
土肥いい質問だね！ EC2 は IaaS っていって、仮想サーバーやネットワーク、ストレージみたいな「部品」を借りる使い方なんだ。自由度は一番高いけど、OS の設定や Web サーバーのインストール、台数の管理は自分でやる必要がある。比べるとこんな感じだよ。
| 区分 | 代表例 | 自分で管理するもの |
|---|---|---|
| IaaS | Amazon EC2 | OS・ミドルウェア・アプリケーション・台数やネットワークの構成 |
| PaaS | AWS Elastic Beanstalk | アプリケーションのコードと環境の設定（インフラの用意・デプロイ・監視は Elastic Beanstalk が受け持つ） |
クラウドおさるEC2 は畑を借りて自分で耕す、Elastic Beanstalk は苗を渡せば畑ごと整えてもらえる、ということでござるな！
土肥そうそう！ しかも Elastic Beanstalk が作ったリソースは自分のアカウントの中にあって、必要ならカスタマイズもできるんだ。「全部お任せで中身が見えない」わけじゃないのがポイントだよ。それから、Elastic Beanstalk そのものには追加料金がかからなくて、動いている EC2 インスタンスなどのリソースの分だけ料金がかかるんだ。
クラウドおさるお任せできるのに、畑の中にも入れるのでござるな。それは安心でござる。
アプリケーション・バージョン・環境・プラットフォーム
クラウドおさるElastic Beanstalk の画面には、アプリケーションや環境など、いろいろな言葉が出てくるでござる。どういう関係でござるか？
土肥最初に押さえておきたい用語は 4 つだよ。
| 用語 | 意味 |
|---|---|
| アプリケーション | 環境・バージョン・環境設定をまとめる入れ物（論理的なグループ） |
| アプリケーションバージョン | デプロイできるコードにラベルを付けたもの。アップロードした zip などのソースバンドルは Amazon S3 に保存される |
| 環境 | アプリケーションバージョンを実行する AWS リソースのまとまり。1 つの環境で同時に動くバージョンは 1 つだけ |
| プラットフォーム | OS・言語ランタイム・Web サーバー・アプリケーションサーバーなどの組み合わせ |
クラウドおさるプラットフォームは何を選べるのでござるか？
土肥Go、Java、.NET、Node.js、PHP、Python、Ruby に加えて、Docker にも対応しているよ。たとえば今回使う PHP のプラットフォームなら、Amazon Linux 2023 の上で PHP と Web サーバー（デフォルトは nginx）が動く構成を Elastic Beanstalk が用意してくれるんだ。だから自分で用意するのは PHP のファイルだけで済むんだよ。
クラウドおさる苗（コード）の種類に合わせて、土や肥料（プラットフォーム）を選ぶわけでござるな。
土肥うまいね！ 1 つ注意があって、言語固有のプラットフォームで動かしている環境のプログラミング言語を変えたいときは、別のプラットフォームで新しい環境を作って切り替える必要があるんだ。
土肥もう 1 つ補足すると、環境には HTTP リクエストを受ける「ウェブサーバー環境」と、Amazon SQS のキューからタスクを取り出して処理する「ワーカー環境」があって、これは作成後に変えられないよ。今回はウェブサーバー環境を使うね。
Elastic Beanstalk が裏で作るもの
クラウドおさるコードをアップロードしたら、実際にはどんなリソースが作られるのでござるか？
土肥今回のような単一インスタンスのウェブサーバー環境だと、主にこんなものが自動で作られるよ。
| リソース | 役割 |
|---|---|
| EC2 インスタンス | 選んだプラットフォームでアプリケーションを動かす仮想サーバー |
| Auto Scaling グループ | インスタンスを管理する。単一インスタンス環境では常に 1 台が動いている状態を保つ |
| インスタンスのセキュリティグループ | インターネットからポート 80（HTTP）へのアクセスを許可する |
| Elastic IP アドレス | 単一インスタンス環境のインスタンスに割り当てられ、環境のドメイン名はこの IP アドレスに解決される |
| Amazon S3 バケット | アップロードしたソースコードやログなどの保存場所 |
| CloudWatch アラーム | 負荷分散環境で、Auto Scaling のスケーリングのきっかけにする 2 つのアラーム（今回の単一インスタンス環境では作られない） |
| CloudFormation スタック | 上のリソースをまとめて作成し、設定変更を反映する |
| ドメイン名 | サブドメイン.リージョン.elasticbeanstalk.com 形式の URL |
クラウドおさるCloudFormation まで出てきたでござる。Elastic Beanstalk が CloudFormation を使っているのでござるか？
土肥そうなんだ。Elastic Beanstalk は CloudFormation を使って環境のリソースをデプロイしたり設定を変えたりしているよ。だから CloudFormation のコンソールを見ると、Elastic Beanstalk が作ったスタックとそのリソースの一覧を確認できるんだ。実践でも中を覗いてみよう。
クラウドおさる長老会に苗を預けると、裏で開墾係・見張り係・水路係に指示書（テンプレート）が回っているようなものでござるな。
土肥ははは、その通り！ ちなみに、ロードバランサーを使う環境だと、ここに Elastic Load Balancing のロードバランサーが加わって、環境のドメイン名はロードバランサーを指すようになるよ。
環境タイプ（単一インスタンスと負荷分散）
クラウドおさる「単一インスタンス」と「ロードバランサーを使う環境」の 2 種類があるのでござるか？
土肥そうだよ。環境タイプは 2 つあるんだ。
| 環境タイプ | 構成 | 向いている用途 |
|---|---|---|
| 単一インスタンス環境 | Elastic IP アドレスを持つ EC2 インスタンス 1 台。ロードバランサーなし。Auto Scaling グループは使うが、最小・最大・希望はすべて 1 | 開発・テスト・ステージング。コストを抑えたいとき |
| 負荷分散環境（ロードバランシング） | Elastic Load Balancing と Amazon EC2 Auto Scaling を使い、負荷に応じて台数を増減。複数 AZ で動かせる | 本番環境 |
クラウドおさる単一インスタンスでも Auto Scaling グループを使うのに、台数は増えないのでござるか？
土肥そうなんだ。最小・最大・希望がすべて 1 だから、負荷が増えても台数は増えない。ただし 1 台が動いている状態は保ってくれるよ。AWS のドキュメントでも、単一インスタンス環境は本番向きではないとされているんだ。デプロイ中や設定の更新中にインスタンスが再起動されると、しばらくアプリケーションが使えなくなることがあるからね。
クラウドおさる試しに植えるのは小さな畑で、収穫祭に出すなら広い畑で、ということでござるな。
土肥そういうこと！ 環境タイプはあとから設定で変えられるから、まず単一インスタンスで作って、本番前に負荷分散に切り替える使い方もできるよ。コンソールの環境作成画面では、「インフラストラクチャ」のセクションで単一インスタンスか負荷分散かを選べるんだ。
デプロイポリシー
クラウドおさる新しいバージョンのコードを出すときは、どうやって入れ替えるのでござるか？
土肥そこで選ぶのがデプロイポリシーだよ。デフォルトは「一度にすべて（All at once）」なんだ。主なものを比べるとこうなるよ。
| ポリシー | 動き方 | ダウンタイム | 単一インスタンス環境 |
|---|---|---|---|
| All at once（一度にすべて） | すべてのインスタンスに同時に新しいバージョンをデプロイ。最も速い | 短時間停止する | 使える |
| Rolling（ローリング） | インスタンスをバッチに分けて順番にデプロイ。デプロイ中のバッチはサービスから外れる | なし（ただし処理能力は一時的に下がる） | 使えない |
| Rolling with additional batch（追加バッチによるローリング） | 先に追加のバッチを起動してからローリング。処理能力を保つ | なし | 使えない |
| Immutable（イミュータブル） | 別の Auto Scaling グループに新しいインスタンスを一式起動してデプロイ。失敗したら新しいインスタンスを終了するだけで戻せる | なし | 使える |
| Traffic splitting（トラフィック分割） | 新しいインスタンスを一式起動し、一部のトラフィックだけ新バージョンに流して確かめる（カナリアテスト） | なし | 使えない（Application Load Balancer が必要） |
クラウドおさる一度にすべては「全員一斉に畑を植え替える」、ローリングは「列ごとに順番に植え替える」、イミュータブルは「隣に新しい畑を作ってから乗り換える」でござるな！
土肥いい例えだね！ もう 1 つ、Blue/Green デプロイっていう考え方も覚えておこう。これはデプロイポリシーの 1 つというより、環境ごと別に用意するやり方なんだ。
クラウドおさる環境ごと別に、でござるか？
土肥そう。今の環境（Blue）とは別に新しい環境（Green）を作って新しいバージョンをデプロイし、テストが済んだら「環境 URL のスワップ」で 2 つの環境の CNAME を入れ替えるんだ。トラフィックがすぐ新しいバージョンに切り替わって、問題があれば URL を入れ替え直せば戻せるよ。ただし DNS の切り替えなので、古い DNS レコードの有効期限が切れるまでは古い環境を消さないことが大事なんだ。
クラウドおさるImmutable は「同じ環境の中で新しいインスタンス群を作る」、Blue/Green は「環境ごと別に作って URL を入れ替える」でござるか。名前は違えど似ているので、取り違えないよう気をつけるでござる。
ほかのサービスとの使い分け
クラウドおさる「手軽に Web アプリを公開する」サービスは、ほかにもある気がするでござる。どう使い分ければよいでござるか？
土肥よく比べられるのはこのあたりだね。
| サービス | 特徴 | 向いている場面 |
|---|---|---|
| AWS Elastic Beanstalk | コード（zip など）をアップロードすると、EC2・Auto Scaling・ロードバランサーなどを自動で用意する PaaS。作られたリソースは自分のアカウントにあり、カスタマイズできる | 対応言語の Web アプリを、インフラの準備をせずに公開・運用したいとき |
| Amazon Lightsail | 仮想サーバー・コンテナ・データベース・ロードバランサー・静的 IP などを、月単位の予測しやすい低価格で提供する | 個人のプロジェクトや学習で、シンプルにサーバーやサイトを立てたいとき |
| Amazon ECS | フルマネージドのコンテナオーケストレーションサービス | アプリケーションをコンテナとして動かし、デプロイや台数を細かく管理したいとき |
土肥ソースコードやコンテナイメージから Web アプリを直接デプロイできる AWS App Runner っていうサービスもあるけど、今は新規のお客さんには公開されていないから、名前だけ知っておけば大丈夫だよ。
クラウドおさる小さな庵を月極めで借りるなら Lightsail、苗を渡して畑を任せるなら Elastic Beanstalk、鉢植え（コンテナ）を並べて管理するなら ECS、という感じでござるな！
実践
ここでは、PHP ファイルを 1 つだけ入れた zip を用意し、Elastic Beanstalk の単一インスタンス環境を作成して公開します。Elastic Beanstalk が作ったリソースを確認したあと、内容を変えた新しいバージョンをデプロイし、環境のイベントとヘルスを確認します。
前提条件
- リージョン:
ap-northeast-1（東京） - AWS マネジメントコンソールにログイン済み（IAM ロールを作成できる権限があること）
- 手元のパソコンでテキストファイルを作成し、zip ファイルに圧縮できること
- 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| VPC | eb-lab-vpc | 検証用 VPC（CIDR: 10.0.0.0/16） |
| パブリックサブネット | eb-lab-public-subnet-1a | ap-northeast-1a のパブリックサブネット（CIDR: 10.0.1.0/24） |
| インターネットゲートウェイ | eb-lab-igw | インターネット接続用 |
| ルートテーブル | eb-lab-public-rt | 0.0.0.0/0 をインターネットゲートウェイへ向けるルート。eb-lab-public-subnet-1a に関連付け済み |
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| ソースバンドル（手元） | eb-lab-v1.zip / eb-lab-v2.zip | アップロードするアプリケーションのコード |
| IAM ロール | aws-elasticbeanstalk-service-role | Elastic Beanstalk のサービスロール（環境の作成時に自動で作られる。既にある場合はそれを選択） |
| IAM ロール（インスタンスプロファイル） | aws-elasticbeanstalk-ec2-role | 環境の EC2 インスタンスが使うインスタンスプロファイル（環境の作成時に自動で作られる。既にある場合はそれを選択） |
| Elastic Beanstalk アプリケーション | eb-lab-app | 環境とバージョンをまとめる入れ物 |
| Elastic Beanstalk 環境 | eb-lab-env | PHP プラットフォームの単一インスタンスのウェブサーバー環境 |
| アプリケーションバージョン | v1 / v2 | アップロードしたコードのバージョン |
環境の EC2 インスタンス、セキュリティグループ、Elastic IP アドレス、Auto Scaling グループ、CloudFormation スタックは Elastic Beanstalk が自動で作成します。
アプリケーションのコードを zip にする
手元のパソコンで任意のフォルダを作り、以下の内容で index.php という名前のファイルを保存します。アクセスすると、バージョン名と、応答したサーバーのホスト名を表示するだけのページです。
<?php
$version = 'v1';
?>
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8">
<title>eb-lab</title>
</head>
<body style="font-family: sans-serif; background: #e8f4ff;">
<h1>Hello from Elastic Beanstalk (<?php echo $version; ?>)</h1>
<p>Host: <?php echo htmlspecialchars(gethostname()); ?></p>
</body>
</html>index.php を zip に圧縮し、ファイル名を eb-lab-v1.zip にします。ソースバンドルには親フォルダを含めてはいけないため、フォルダごとではなく index.php ファイルそのものを圧縮します。macOS や Linux のターミナルなら、index.php があるフォルダで次のコマンドを実行します。
zip eb-lab-v1.zip index.php続けて、次のバージョン用のファイルも作っておきます。index.php の $version = 'v1'; を $version = 'v2'; に、background: #e8f4ff; を background: #fff4d6; に書き換えて保存し、同じように eb-lab-v2.zip という名前で圧縮します。
zip eb-lab-v2.zip index.php環境を作成する
環境の作成は 1 枚のフォームで行います。上から「基本詳細」「プラットフォームの詳細」「アプリケーションコード」を入力し、そのあと折りたたまれた「サービスアクセス」「ネットワーク」のセクションを開いて設定します。
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
- 上部の検索バーに
Elastic Beanstalkと入力し、表示された「Elastic Beanstalk」を選択します - 「環境を作成」をクリックします（アプリケーションは、環境の作成と同時に作られます）
- 「基本詳細」と「プラットフォームの詳細」「アプリケーションコード」で以下を設定します
- アプリケーション名:
eb-lab-app（「新しいアプリケーションが作成されます」と表示されます） - 環境名:
eb-lab-env - ドメイン名プレフィックス: 空欄のまま（Elastic Beanstalk が自動で決めます）
- プラットフォーム:
PHP - プラットフォームブランチ・プラットフォームのバージョン: 表示された推奨のまま
- アプリケーションコード:
ローカルファイルを選び、「ファイルを選択」でeb-lab-v1.zipを選択 - バージョンラベル:
v1
環境のタイプ（ウェブサーバー環境・単一インスタンス）は、既定で選ばれているものをそのまま使います。
Elastic Beanstalk には 2 つの IAM ロールが必要です。サービスロールは Elastic Beanstalk が EC2 インスタンスを監視したり、プラットフォームを更新したりするために使い、EC2 インスタンスプロファイルはインスタンスがログの書き込みなどを行うために使います。
- 「サービスアクセス – 任意」のセクションを開きます
- 「サービスロール」と「EC2 インスタンスプロファイル」が、どちらも
デフォルトロールを作成になっていることを確認します。aws-elasticbeanstalk-service-roleとaws-elasticbeanstalk-ec2-roleという名前のロールが、環境の作成時に自動で作られます（既にこのロールがあるアカウントでは、別のロールを使用を選んで既存のロールを選びます） - 「EC2 キーペア」は空欄のままにします（このハンズオンではインスタンスにログインしません）
VPC を指定しないとデフォルト VPC が使われるため、ここで前提条件の VPC を選びます。
- 「ネットワーク – 任意」のセクションを開き、以下を設定します
- VPC:
eb-lab-vpc - インスタンスサブネット:
eb-lab-public-subnet-1aが選ばれていることを確認します（VPC を選ぶと自動で入ります。入らない場合はドロップダウンから選びます） - EC2 セキュリティグループ: 選択しない（Elastic Beanstalk が作成します）
- その他のセクションはデフォルトのままにし、ページ下部の「作成」をクリックします
単一インスタンス環境では、インスタンスに Elastic IP アドレスが自動で割り当てられるため、パブリック IP アドレスの設定は不要です。
環境の作成を待ってアクセスする
環境の概要画面に切り替わり、Elastic Beanstalk が環境の作成を始めます。作成中は下部の「イベント」タブに、リソースの作成状況が順に追加されていきます。初回の作成には数分かかります。
- 「環境の概要」のヘルスが
Ok（緑色）になるまで待ちます - 「実行中のバージョン」が
v1、プラットフォームが PHP になっていることを確認します
クラウドおさる環境ができた瞬間から、EC2 インスタンスと Elastic IP アドレス（パブリック IPv4 アドレス）の料金がかかり始めるでござる。Elastic Beanstalk 自体は無料でも、環境を終了するまで中のリソースは動き続けるので、ハンズオンが終わったら放置しないことでござるぞ。
「環境の概要」の「ドメイン」に表示されている URL（eb-lab-env.〜.ap-northeast-1.elasticbeanstalk.com のような形式）をクリックするか、左側ナビゲーションの「環境に移動」をクリックします。HTTP での接続のため、ブラウザに警告が表示されることがあります。
Hello from Elastic Beanstalk (v1) と、応答したサーバーのホスト名が表示されることを確認します。サーバーを自分で用意しなくても、zip をアップロードしただけでアプリが公開されたことが確認できます。
Elastic Beanstalk が作ったリソースを確認する
Elastic Beanstalk が裏で作ったリソースを CloudFormation から確認します。
- 上部の検索バーに
CloudFormationと入力し、表示された「CloudFormation」を選択します - 「スタック」の一覧で、Elastic Beanstalk が作成したスタックを選択します（スタック名は
awseb-<環境 ID>-stackの形式で、環境 ID は Elastic Beanstalk の環境の概要に表示されるe-で始まる ID です。「タグ」タブのelasticbeanstalk:environment-nameがeb-lab-envになっているものが今回の環境のスタックです） - 「リソース」タブを選択します
Auto Scaling グループ（AWS::AutoScaling::AutoScalingGroup）、起動テンプレート（AWS::EC2::LaunchTemplate）、セキュリティグループ（AWS::EC2::SecurityGroup）、Elastic IP（AWS::EC2::EIP）などが、このスタックで作られていることが確認できます。負荷分散環境の場合は、ロードバランサーや CloudWatch アラームもこのスタックに含まれます。
EC2 コンソールの「インスタンス」を開くと、名前が eb-lab-env のインスタンスが 1 台起動していることも確認できます。Elastic Beanstalk は、環境の名前を Name タグとしてリソースに付けます。
新しいバージョンをデプロイする
Elastic Beanstalk のコンソールに戻り、eb-lab-v2.zip をデプロイします。
- 上部の検索バーに
Elastic Beanstalkと入力し、表示された「Elastic Beanstalk」を選択します - 左側ナビゲーションの「環境」を選択し、
eb-lab-envを選択します - 環境の概要画面で「アップロードとデプロイ」をクリックします
- 表示されたダイアログで以下を設定します
- 「ファイルを選択」で
eb-lab-v2.zipを選択 - バージョンラベル:
v2
- 「デプロイ」をクリックします
デプロイの進み具合は、環境の概要の「イベント」タブに順に記録されます。ヘルスは一時的に灰色（Info）になることがありますが、デプロイが終わってアプリケーションがヘルスチェックに応答すると緑色の Ok に戻ります。この環境のデプロイポリシーはデフォルトの「一度にすべて（All at once）」で、インスタンスが 1 台だけなので、デプロイの間はアプリケーションが一時的に応答しなくなることがあります。
環境のイベントとヘルスを確認する
- 環境の概要画面の下部で「イベント」タブを選択します
新しいバージョンのデプロイが始まったこと、インスタンスへのデプロイが完了したこと、環境の更新が正常に完了したことなどが、時刻つきで記録されていることが確認できます。デプロイがうまくいかないときは、まずこの「イベント」を見て、どの段階で止まったかを確かめます。
- 環境の概要画面の「健全性とモニタリング」タブを選択します
「拡張インスタンスの状態」にインスタンスごとのヘルスステータスが表示されます。インスタンスのステータスが Ok になっていることを確認します。環境の概要に戻ると、「実行中のバージョン」が v2 に変わっていることも確認できます。
ブラウザで環境のドメインに再度アクセスし、Hello from Elastic Beanstalk (v2) が表示され、背景の色が変わっていることを確認します。
左側ナビゲーションの eb-lab-app の下にある「アプリケーションバージョン」を選択すると、v1 と v2 の 2 つのバージョンが並んでいることも確認できます。古いバージョンを選んでデプロイし直せば、前のバージョンに戻すこともできます。
クラウドおさるサーバーには一度も触らずに、zip を渡すだけで v1 から v2 へ植え替えられたでござる。苗の履歴（アプリケーションバージョン）が残っているから、いざとなれば前の苗に戻せるのも心強いでござるな。
まとめ
- AWS Elastic Beanstalk は、アプリケーションのコードをアップロードするだけで、実行に必要な AWS リソースを用意してデプロイ・監視・スケーリングまで受け持つ PaaS である。サービス自体に追加料金はなく、作られたリソースの分だけ料金がかかる
- アプリケーションは環境・バージョン・設定をまとめる入れ物で、アップロードしたコードはアプリケーションバージョンとして S3 に保存される。環境はバージョンを実行するリソースのまとまりで、プラットフォームで言語や Web サーバーの組み合わせを選ぶ
- Elastic Beanstalk は CloudFormation を使って、EC2 インスタンス・Auto Scaling グループ・セキュリティグループ・（環境タイプに応じて）Elastic IP やロードバランサーを作成する。作られたリソースは自分のアカウントにあり、確認・カスタマイズできる
- 環境タイプは、Elastic IP を持つ 1 台で動く低コストな単一インスタンス環境（開発・テスト向け）と、ELB と Auto Scaling で台数を増減する負荷分散環境（本番向け）がある
- デプロイポリシーは、速いが短時間止まる All at once、バッチごとに入れ替える Rolling、新しいインスタンス群で入れ替える Immutable などがある。Blue/Green は別の環境を作って環境 URL をスワップするやり方である
- 手軽にサーバーを立てるなら Lightsail、コンテナを細かく管理するなら ECS と、目的に応じて使い分ける
参照先
- AWS Elastic Beanstalk とは – AWS Elastic Beanstalk
- Elastic Beanstalk の使用を開始する方法について説明します – AWS Elastic Beanstalk
- Elastic Beanstalk の概念を理解する – AWS Elastic Beanstalk
- Elastic Beanstalk ウェブサーバー環境 – AWS Elastic Beanstalk
- 環境タイプ – AWS Elastic Beanstalk
- Elastic Beanstalk 環境の作成 – AWS Elastic Beanstalk
- 新しい環境の作成ウィザード – AWS Elastic Beanstalk
- Elastic Beanstalk でサポートされているプラットフォーム – AWS Elastic Beanstalk
- Elastic Beanstalk アプリケーションソースバンドルを作成する – AWS Elastic Beanstalk
- アプリケーションバージョンの管理 – AWS Elastic Beanstalk
- Amazon VPC で Elastic Beanstalk を使用する – AWS Elastic Beanstalk
- Beanstalk Standard 環境での Amazon Virtual Private Cloud (Amazon VPC) の設定 – AWS Elastic Beanstalk
- Elastic Beanstalk 環境インスタンスの Auto Scaling – AWS Elastic Beanstalk
- Amazon S3 で Elastic Beanstalk を使用する – AWS Elastic Beanstalk
- Elastic Beanstalk 環境でのリソースのタグ付け – AWS Elastic Beanstalk
- Elastic Beanstalk 環境へのアプリケーションのデプロイ – AWS Elastic Beanstalk
- デプロイポリシーと設定 – AWS Elastic Beanstalk
- Elastic Beanstalk を使用したブルー/グリーンデプロイ – AWS Elastic Beanstalk
- Elastic Beanstalk の拡張ヘルスレポートおよびモニタリング – AWS Elastic Beanstalk
- 状態の色とステータス – AWS Elastic Beanstalk
- AWS Elastic Beanstalk – AWS でのデプロイオプションの概要
- Infrastructure Description and Controls – GxP Systems on AWS
- Elastic IP アドレス – Amazon Elastic Compute Cloud
- Amazon Lightsail とは? – Amazon Lightsail
- Amazon Elastic Container Service とは – Amazon Elastic Container Service
- AWS App Runner とは – AWS App Runner
- Elastic Beanstalk 環境の Auto Scaling トリガー – AWS Elastic Beanstalk
