AWS Elastic Beanstalk がクラスタモードを開始
AWS Elastic Beanstalk がフルマネージドの Cluster Mode を発表、Amazon EKS を基盤に複数のアプリでインフラを共有し、アプリ構成が大きいほどアプリ単位のコストが下がる。
日本語
コピー

2011 年に AWS Elastic Beanstalk が初めてリリースされて以来、顧客はこれを使って Java、.NET、Python、Node.js、PHP、Ruby、Go のフルスタックアプリケーションをデプロイし、デプロイとインフラ運用を Elastic Beanstalk に任せてビジネスロジックに集中してきた。15 年が経った今、その信頼は増すことはあっても減ることはなく、サービス自体もその信頼に応える形で作り直された。現在の AWS Elastic Beanstalk は AWS 上のアプリケーション管理サービスであり、本番環境の運用責任をすべて引き受ける。アプリケーションはそのままの形で持ち込める。ソースコード、Dockerfile、あるいはコンテナイメージだ。Elastic Beanstalk がその下で本番環境を作成し、管理する。アプリケーションはあなたが管理し、それ以外はすべて AWS が担う。継続的デプロイ、スケーリング、パッチ適用、監視、メンテナンスだ。この運用責任はアプリケーションのライフサイクル全体を通じて AWS が持ち続ける。 私たちは基盤となる運用エンジンを作り直し、これまでに一連の機能を順次提供してきた。おかげで以前よりはるかに強力になっている。Elastic Beanstalk は現在、AI による環境分析を使ってヘルス問題を自動診断し、修正案を提示する。新しい公式 GitHub Action を使えば、チームは YAML 設定 1 つで既存の CI/CD ワークフローから直接デプロイできる。インフラの土台も作り直し、OpenTelemetry ベースの可観測性、自動ロールバック付きのトラフィック分割デプロイ、イベント駆動の自動スケーリング、AWS Secrets Manager によるシークレット管理、AWS Certificate Manager による HTTPS のデフォルト有効化を実現した。 本日、AWS Elastic Beanstalk の次の章を発表する。新しいフルマネージドの Cluster Mode は、負荷のライフサイクル全体にわたってアプリケーションを継続的にデプロイし、スケーリングし、パッチを適用し、監視し、アップグレードする。アプリケーションを持ち込めば、あとは AWS が動かす。 新しい Cluster Mode は、アプリケーション群を運用するチームに向けたものだ。各アプリケーションを個別に運用するのではなく、Amazon Elastic Kubernetes Service (Amazon EKS) を基盤とした複数のアプリケーションを共有インフラ上で動かし、すべてマネージドで、運用基準を統一する。複数のアプリケーションがリソースを共有するため、アプリケーション群が大きくなるほどアプリケーションあたりのコストは下がり、運用の複雑さは増えない。10 個でも 100 個でも、同じ体験で管理でき、どのスタックも同じ運用保証を受ける。 Elastic Beanstalk Cluster Mode が負荷にもたらす利点:
- ソースコードから本番環境まで、あらゆるランタイムに対応。Java、.NET、Python、Node.js、PHP、Ruby、Go のソースコードをアップロードする。必要に応じて Elastic Beanstalk が Cloud Native Buildpacks を使って自動でコンテナ化する。Dockerfile もアーキテクチャの作り直しも不要だ。オンプレミスのレガシーアプリケーションを移行してもいいし、対応言語で新しいサービスをデプロイしてもいい。
- エンタープライズ向けコンプライアンスをすぐに利用可能。Elastic Beanstalk は HIPAA 適格で、PCI DSS のコンプライアンス要件を満たし、SOC 1/2/3 にも準拠している。追加設定は不要で、規制産業のチームは既存のコンプライアンス要件を満たしたまま本番ワークロードをデプロイできる。
- 本番グレードのデプロイ戦略。一括、ローリング、イミュータブル、トラフィック分割の各デプロイに対応し、失敗時は自動でロールバックする。イベント駆動の自動スケーリング。AWS Secrets Manager と統合。OpenTelemetry をネイティブサポートし、Amazon CloudWatch をはじめほとんどの可観測性バックエンドに容易に接続できる。
- AI によるトラブルシューティング。問題が起きたときは、Elastic Beanstalk がサーバー側のログを収集し、AI が生成した提案を提示するので、インフラの細部を追うことなく、より速く原因を特定して解決できる。
Elastic Beanstalk Cluster Mode を使ってみる
まず Elastic Beanstalk コンソールを開き、新しい環境を作成します。Deployment type で Cluster を選択してください。

Elastic Beanstalk は、ソースコード、Dockerfile、コンテナイメージのいずれかを渡すだけでアプリケーションをデプロイできます。たとえば Local file を選んでアプリケーションコードを指定し、コンテナイメージのビルドオプションを設定する、といった具合です。残りの設定はデフォルトのままで、ほとんどの用途には十分です。

Create をクリックするとデプロイが始まります。注意点として、新しいサブネット群への初回デプロイでは EKS クラスターの作成が走るため、10 分強かかります。以降のデプロイは既存の EKS クラスターを再利用するため、より速く完了します。 デプロイ成功後の画面は次のとおりです。

AWS Command Line Interface (AWS CLI)、EB CLI、AWS SDK を使うこともできます。たとえば、複数のマイクロサービスからなるアプリケーションを Kubernetes にデプロイするとします。まずアプリケーションを作成します。
aws elasticbeanstalk create-application \
--application-name "my-microservice" \
--description "Multi-services demo" \
各マイクロサービスには、すでに Amazon Elastic Container Registry (Amazon ECR) にビルド済みのイメージがあるかもしれません。それをアプリケーションバージョンとして登録します。
IMAGES=(
"frontend-v1|public.ecr.aws/my-microservices/frontend:v1"
"cartservice-v1|public.ecr.aws/my-microservices/cart:v1"
"paymentservice-v1|public.ecr.aws/my-microservices/payment:v1"
"shippingservice-v1|public.ecr.aws/my-microservices/shipping:v1"
)
for entry in "${IMAGES[@]}"; do
IFS='|' read -r label uri <<< "$entry"
aws elasticbeanstalk create-application-version \
--application-name $APP_NAME \
--version-label "$label" \
--image-configuration Source="{Uri=$uri}" \
--region "us-west-2
echo "Registered: $label"
done
サービスごとに対応するオプションを設定してデプロイできます。たとえば frontend サービスは、公衆インターフェイス(Application Load Balancer など)を必要とする唯一のサービスであり、HTTP サービスである以上、ヘルスチェックパスも設定する必要があります。
[
{"Namespace": "aws:elasticbeanstalk:eks", "OptionName": "cluster-role", "Value": "arn:aws:iam::0123456789012:rol<...>"},
{"Namespace": "aws:elasticbeanstalk:eks", "OptionName": "node-role", "Value": "arn:aws:iam::0123456789012:role/E<...>"},
{"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "observability-role", "Value": "arn:aws:iam::0123456<...>"},
{"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "subnets", "Value": "subnet-1,subnet-2,subnet-3,<...>"},
{"Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling", "OptionName": "min-replica", "Value": "1"},
{"Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling", "OptionName": "max-replica", "Value": "2"},
{"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "cpu", "Value": "0.5"},
{"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "memory", "Value": "256Mi"},
{"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "memory-limit", "Value": "512Mi"},
{"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "service-port", "Value": "8080"},
{"Namespace": "aws:elasticbeanstalk:eks:alb", "OptionName": "scheme", "Value": "internet-facing"},
{"Namespace": "aws:elasticbeanstalk:eks:alb", "OptionName": "healthcheck-path", "Value": "/_healthz"}
] #frontend-options.json namespaces
次に、これらのオプションを使って frontend サービスの環境を作成します。残りのサービス環境も同じ要領で順にデプロイしていきます。
aws elasticbeanstalk create-environment \
--application-name my-microservice \
--environment-name frontend \
--version-label frontend-v1 \
--tier Name=Cluster,Type=EKS \
--option-settings file:///tmp/frontend-options.json \
すべてのサービスをデプロイし終えると、コンソールはおおよそ次のようになります。

Amazon Elastic Compute Cloud (EC2) 上で動く Elastic Beanstalk Standard は引き続き完全にサポートされます。Standard と Cluster Mode の環境は同じ Elastic Beanstalk アプリケーション内で共存できるため、チームは自分のペースで環境を一つずつ移行できます。移行前には検証チェックで互換性を確認します。強制的に移行される環境はありません。 Elastic Beanstalk Standard Mode が依然として最適なのは、次のようなケースです。
- 単一アプリケーションまたは単一環境のユースケース
- IIS 上の Windows/.NET Framework ワークロード
- コンテナ化できないアプリケーション
- 月額 500 ドル未満のワークロード — EKS コントロールプレーンの費用と EKS Auto Mode の割増分が上乗せされるうえ、単一アプリケーションではビンパッキングでその分を相殺できない
Cluster Mode でのアプリケーションのデプロイと管理については、Elastic Beanstalk Cluster Mode のドキュメントを参照してください。 提供開始
AWS Elastic Beanstalk Cluster Mode は、Elastic Beanstalk を提供しているすべての AWS リージョンで本日から利用可能です。リージョンごとの可用性と今後のロードマップは AWS Capabilities by Region で確認できます。API を呼び出したり、ドキュメントを参照したり、リージョンごとの可用性を確認したり、この新機能のトラブルシューティングをしたりする場合は、いつも使っている AI ツールと AWS MCP Server およびプラグインを組み合わせて使えます。 Elastic Beanstalk Cluster Mode に追加料金はかかりません。料金が発生するのは、アプリケーションが実際に消費した基盤の AWS リソース(EKS コントロールプレーン、EKS Auto Mode のコンピューティング、Amazon ECR、Amazon CloudWatch)のみです。なお、Elastic Beanstalk Cluster Mode は AWS Free Tier の対象外です。詳しくは AWS Elastic Beanstalk の料金ページをご覧ください。 Elastic Beanstalk コンソールでぜひ試してみてください。フィードバックは AWS re:Post for AWS Elastic Beanstalk または普段お使いの AWS Support チャネルからお寄せください。 — Channy