Compute Platformを選択する

既存ワークロードのターゲット条件を整理したら、次にそのアプリケーションをどのコンピューティングプラットフォームで実行するかを判断します。

ここでは主に、Amazon EC2とAWS Elastic Beanstalkを比較します。

重要なのは、

運用負荷が小さい方

だけで選ぶことでも、

制御できる項目が多い方

だけで選ぶことでもありません。

アプリケーション要件と必要な制御範囲が、どのプラットフォームに適合するかを判断します。

1. Amazon EC2はゲストOSを含めて直接制御する

Amazon EC2では、EC2インスタンスという仮想サーバーを利用します。

利用者は、

OS

インスタンスタイプ

インストールするソフトウェア

アプリケーション

エージェント

OS設定

更新方法

などを広く制御できます。

例えば、独自の常駐プロセスをインストールする、特定のOSパッケージを利用する、アプリケーション固有のミドルウェアを構成する、OS更新のタイミングを自社で管理する、といった要件へ対応しやすい構成です。

一方、その自由度と引き換えに、ゲストOSの更新やアプリケーションソフトウェアの管理など、利用者側で直接持つ責任も増えます。

したがってAmazon EC2は、OSやソフトウェアスタックへの直接的な制御がアプリケーション要件として必要な場合に有力な候補になります。

2. AWS Elastic Beanstalkはアプリケーション中心で環境を管理する

AWS Elastic Beanstalkでは、アプリケーションコードをElastic Beanstalk環境へデプロイします。

Elastic Beanstalkは環境に必要なAWSリソースをプロビジョニングし、

Amazon EC2

Amazon EC2 Auto Scaling

Elastic Load Balancing

などを組み合わせてアプリケーション環境を構成できます。

さらに、容量のプロビジョニング、ロードバランシング、スケーリング、アプリケーションヘルス監視などの環境管理を簡素化します。

例えば、AWS Elastic BeanstalkがサポートしているJava / TomcatのWebアプリケーションで、

アプリケーションコードをデプロイしたい

OS自体を細かく設計する必要はない

Webサーバー環境の構成作業を減らしたい

負荷に応じてインスタンス数を変更したい

という要件なら、Elastic Beanstalkが有力です。

3. Elastic Beanstalkは「EC2を使用しないサービス」ではない

Elastic Beanstalkを選んだからといって、Amazon EC2がアーキテクチャから消えるわけではありません。

例えば、負荷分散されたWeb環境では、

Elastic Load Balancing
↓
Auto Scaling group
↓
Amazon EC2
↓
Application

というようなAWSリソースがElastic Beanstalk環境として構成されます。

つまりElastic Beanstalkは、Amazon EC2などを利用する環境の構築・デプロイ・管理をアプリケーション中心にまとめるサービスです。

したがって、

EC2
vs
Elastic Beanstalk

を、

仮想サーバー
vs
サーバーレス

と考えてはいけません。

比較すべきなのは、インスタンスと環境をどこまで自分で直接管理する必要があるかです。

4. マネージドプラットフォームとの互換性を確認する

Elastic Beanstalkでは、マネージドプラットフォームを利用できます。

プラットフォームには、

OS

プログラミング言語のランタイム

Webサーバー

アプリケーションサーバー

Elastic Beanstalkコンポーネント

などが含まれます。

例えば、

Python
Node.js
PHP
Ruby
Go
Corretto
Tomcat
.NET

などに対応するプラットフォームブランチがあります。

Elastic Beanstalkを候補にするときは、現在のアプリケーションがサポート対象のプラットフォームへ適合できるかを確認します。

アプリケーションが、サポートされるランタイム、サポートされるOS、サポートされるWebサーバー / アプリケーションサーバーで動作できるなら、Elastic Beanstalkの管理機能を利用しやすくなります。

一方、ベンダー独自のソフトウェアスタックなどが必須で、マネージドプラットフォームへ適合できない場合は、Amazon EC2など別のコンピューティングプラットフォームを評価します。

5. Elastic Beanstalkのカスタムプラットフォームを前提にしない

かつてElastic Beanstalkにはカスタムプラットフォーム機能がありました。

しかし現在、この機能はサポートされていません。

したがって、

マネージドプラットフォームに必要なランタイムがない
↓
Elastic Beanstalkのカスタムプラットフォームを新しく作ればよい

という設計は現在の選択肢として扱いません。

アプリケーションをサポート対象のマネージドプラットフォームへ適合させられない場合は、Amazon EC2で必要なソフトウェアスタックを管理する、アプリケーション側を変更できるか確認する、別の適切な実行基盤を評価する、といった判断が必要です。

6. Elastic Beanstalkでも一定のカスタマイズはできる

Elastic Beanstalkを選んだからといって、

インスタンス設定を一切変更できない

わけではありません。

Linuxのサポート対象プラットフォームでは、.ebextensionsや.platform/hooksなどを利用して、環境の設定やプロビジョニング時の処理を追加できます。

例えば、追加パッケージの導入、設定ファイルの配置、アプリケーションデプロイ前後のスクリプト実行などを組み込める場合があります。

そのため、

カスタマイズが1つ必要
=
必ずAmazon EC2

とは判断しません。

確認すべきなのは、必要なカスタマイズがElastic Beanstalkのサポート対象プラットフォーム内で維持できるかです。

7. 制御要件の強さで境界を判断する

Amazon EC2とElastic Beanstalkの比較では、「カスタマイズの有無」より、どのレイヤーを自分で継続管理する必要があるかを見ることが重要です。

Elastic Beanstalkにもカスタマイズ手段はあるため、軽微な初期化スクリプトと独自プラットフォームそのものを維持する要件を区別します。

8. 運用負荷の違いは「誰が環境を組み立てるか」で見る

Amazon EC2でも、Auto Scaling、Elastic Load Balancing、Amazon CloudWatchなどを組み合わせれば、スケーラブルで可用性のあるWeb環境を構築できます。

したがって、

Auto Scalingが必要
=
Elastic Beanstalk

ではありません。

違いは、その環境を誰が組み立てて管理するかです。

Amazon EC2を中心に設計する場合は、

EC2
+
Auto Scaling
+
ロードバランサー
+
デプロイ
+
監視

などをアーキテクチャとして直接設計・管理します。

Elastic Beanstalkでは、これらをアプリケーション環境という単位で扱います。

そのため、同じAWSリソースを利用できる場合でも、環境管理の抽象度が異なると考えます。

9. Elastic Beanstalkの環境タイプをアプリケーション要件へ合わせる

Elastic BeanstalkのWebサーバー環境には、代表的に、シングルインスタンス環境と負荷分散されたスケーラブルな環境があります。

シングルインスタンス環境

1台のEC2インスタンスを中心に構成します。

ロードバランサーを持たないため、例えば開発・検証など、単一インスタンスで十分な環境に利用できます。

負荷分散されたスケーラブルな環境

Elastic Load BalancingとAuto Scalingを利用して、複数のEC2インスタンスを実行できます。

負荷に応じてインスタンス数を変更でき、複数Availability Zoneを利用する構成も可能です。

したがって本番Webアプリケーションで、

複数インスタンス

負荷分散

需要に応じたスケーリング

複数Availability Zone

が必要なら、負荷分散されたスケーラブルな環境を評価します。

10. マネージドプラットフォームにもライフサイクルがある

Elastic Beanstalkのマネージドプラットフォームは、永続的に同じバージョンを使用できるわけではありません。

プラットフォームブランチには、

Supported

Beta

Deprecated

Retired

などの状態があります。

本番環境では、サポート対象のプラットフォームブランチを利用することが基本です。

退役したプラットフォームブランチは、Elastic Beanstalkによる保守更新、セキュリティ更新、技術サポートを受けられません。

したがってElastic Beanstalkを選ぶ場合でも、アプリケーションランタイムの更新を継続できることが重要なアプリケーション要件になります。

11. 現在のサポート状態を確認してプラットフォームを選ぶ

Elastic Beanstalkのプラットフォームブランチは、時間とともにサポート状態が変わります。

例えば、Amazon Linux 2ベースのElastic Beanstalkプラットフォームブランチは2026年8月6日にすべて退役しました。

したがって、過去にElastic Beanstalkで利用できたOSやランタイムだからといって、

現在もサポート対象

とは限りません。

コンピューティングプラットフォームを選択するときは、現在利用できるサポート対象プラットフォームブランチへアプリケーションを適合できるかを確認します。

特定ランタイムのサポート状態は変化するため、サービス選択時には現行のサポート対象プラットフォームを確認することが重要です。

12. マネージドプラットフォーム更新の範囲を理解する

Elastic Beanstalkでは、マネージドプラットフォーム更新を利用できます。

設定によって、パッチバージョン、マイナーバージョンの更新を、設定したメンテナンスウィンドウで自動適用できます。

ただし、OS、ランタイム、Webサーバー、アプリケーションサーバーなどのメジャーバージョンが異なる別のプラットフォームブランチへ、自動的に移行する機能ではありません。

例えば、

現在のプラットフォームブランチ
↓
同一ブランチのパッチ / マイナー更新

と、

現在のプラットフォームブランチ
↓
別のメジャーランタイム / OSブランチ

は別の変更です。

後者では、互換性確認を行い、必要に応じて別環境を利用した更新を計画します。

13. Amazon EC2とElastic Beanstalkの選択軸

重要なのは、

EC2 = 古い
Elastic Beanstalk = 新しい

でも、

EC2 = 悪い
Elastic Beanstalk = 良い

でもありません。

アプリケーション要件に対して、必要な制御を維持しながら、不要な環境管理を減らせるプラットフォームを選択することが目的です。

14. 判断フロー

アプリケーション要件を確認
↓
Elastic Beanstalkのサポート対象プラットフォームへ適合できるか
↓
必要なOS / ランタイム / ソフトウェア制御を確認
↓
Elastic Beanstalk内のカスタマイズで成立するか
↓
環境管理をどこまで委譲したいか
↓
プラットフォームライフサイクルを継続管理できるか
↓
Amazon EC2 / AWS Elastic Beanstalkを選択

コンテナを主要な実行単位として扱う必要がある場合は、Amazon ECS、Amazon EKS、AWS Fargateなどのコンテナホスティングプラットフォームを別途比較します。