AWSは2026年9月17日、AWS Elastic BeanstalkサービスでCluster Modeを一般提供すると発表した。この新しいモードでは、チームがソースコード、Dockerファイル、またはコンテナイメージを提供すると、Elastic Beanstalkが実行環境の作成と管理を担う。これには、アプリケーションの実行期間全体にわたるデプロイ、スケーリング、デバッグ、監視、アップグレードが含まれる。
Cluster Modeは、各アプリケーションを完全に分離された環境で実行するのではなく、複数のアプリケーション群を管理するチームを対象としている。この新しい基盤はAmazon Elastic Kubernetes Service（Amazon EKS）を基盤とし、Elastic Beanstalkが管理する単一の運用ベースラインを備える。AWSによれば、アプリケーションはリソースを共有できるため、ポートフォリオの拡大に伴い、同程度の運用負担を追加することなく、アプリケーション単位のコストを削減できる可能性がある。
新しいモードが提供するもの
Java、.NET、Python、Node.js、PHP、Ruby、Goのアプリケーションは、ソースコードから直接デプロイできる。Elastic Beanstalkは必要に応じてCloud Native Buildpacksを使用してコンテナを作成するため、チームがDockerfileを作成したり、アプリケーションを再設計したりする必要はない。また、このモードは既存のコンテナイメージにも対応しており、デプロイはコンソール、AWS CLI、EB CLI、またはAWS SDKsから管理できる。
- 一括デプロイ、段階的デプロイ、イミュータブルデプロイ、障害発生時の自動ロールバックを伴うトラフィック分割などのデプロイ戦略。
- イベントベースの自動スケーリング、およびシークレット管理のためのAWS Secrets Managerとの統合。
- OpenTelemetryを基盤とした監視。Amazon CloudWatchを含む監視ツールとの統合も可能。
- 環境の健全性に関する問題をAIで分析し、サービス側でログを収集して障害対応の推奨事項を提示。
- AWS Certificate ManagerによるデフォルトのHTTPS対応。AWSの発表によれば、HIPAA適格性、PCI DSSへの準拠、SOC 1/2/3との整合性を含むコンプライアンスモードにも対応。
チームにとって実務上何が変わるのか
Cluster Modeは、従来型のアプリケーションのデプロイと、共有コンテナ環境での管理との間の距離を縮める。特定のサブネットグループに最初の環境を作成すると、サービスはEKSクラスターを作成し、この処理には約10分かかる場合がある。その後のデプロイでは、AWSによれば、既存のクラスターを利用できる。同じアプリケーション内で複数のマイクロサービスを実行することもでき、各サービスのレプリカ数、CPUユニット、メモリ、ポート、ヘルスチェックパスなどのリソースを設定できる。
重要なのは、チームが現在のモードから強制的に移行させられるわけではない点である。Amazon EC2を基盤とするElastic Beanstalk Standard環境は引き続き動作し、同じElastic Beanstalkアプリケーション内でStandard環境とCluster Mode環境を併用できる。また、サービスは変更前に互換性チェックを実行するため、段階的な移行が可能である。
Cluster Modeが最適な選択肢ではないのはどのような場合か
AWSによれば、Standard Modeは、単一のアプリケーションまたは単一の環境、IIS上で動作するWindows/.NET Frameworkワークロード、コンテナ化できないアプリケーションに引き続き適している。また、月額500ドル未満のワークロードでは、EKSコントロールプレーン料金とEKS Auto Modeに関連する割増料金によって、単一アプリケーションでのリソース共有によるメリットが相殺される可能性があるため、Standard Modeの方が適している場合がある。
提供状況とコスト
Cluster Modeは、Elastic Beanstalkが利用可能なすべてのAWSリージョンで一般提供されるようになった。AWSはCluster Mode自体に追加料金を課していないが、顧客はアプリケーションが消費する基盤リソースに対して料金を支払う。これには、EKSコントロールプレーン料金、EKS Auto Modeのコンピューティング、Amazon ECR、Amazon CloudWatchの料金などが含まれる。このサービスはAWS Free Tierの対象外である。
certi.newsの見解：実際の変更は単なる新しいデプロイオプションではなく、EKSを裏側で活用しながら、コンテナアプリケーション群の運用責任をElastic Beanstalkのレイヤーに移すことである。これは、運用を統一し、手作業を減らしたいチームには有用だろう。しかし、サービス自体に追加料金がないことだけで判断すべきではない。EKSと補助リソースのコストに加え、アプリケーションがコンテナに対応しているかどうかも、依然として重要な要素である。また、この記事の情報源は、両モード間の性能数値や実際のコスト比較を示していない。そのため、大規模な本番アプリケーション群を移行する前に、負荷とコストをテストする必要がある。