本記事の内容は筆者個人の見解であり、所属組織・企業の公式見解ではありません。また、本記事の原案は AI を用いて作成していますが、ここで整理した概念や考え方については筆者自身が確認しています。導入設計や正式な手順、要件確認については必ず各製品のベンダーへ直接お問い合わせください。
AWS上で「Dockerコンテナを常時稼働させる」場合、代表的な選択肢は次の3つ。
- ECS on Fargate（サーバレス実行）
- ECS on EC2（EC2上でECSがオーケストレーション）
- EC2に直接（docker compose / systemd などで自前運用）
結論
-
一般的なコンテナ用途（OS/カーネル要件が強くない） → まずは ECS on Fargate
-
OS/カーネル要件が絡む機能（例：RBI）を使う → 基本は EC2ベース（ECS on EC2 か EC2直）
- HAもやりたい／運用を仕組み化したい → ECS on EC2
- とにかく単純に動かしたい（PoC/単体） → EC2直
導入メモ（KeeperPAMで検証した起動パラメータ例）
ECSでタスクを作成する際に、以下のように指定されました。
- イメージ：
keeper/gateway:latest - 環境変数：
ACCEPT_EULA、GATEWAY_CONFIG
また、RBI（リモートブラウザ分離）のようにブラウザエンジン（Chromium系）を扱う機能では、実行時に OS/カーネル機能・権限（namespace等） に依存する場面がある。Fargateのようなマネージド実行環境より、EC2ベース（ECS on EC2 / EC2直）の方が要件に合わせる。
| AWS | Azure | Azure |
|---|---|---|
 |
 |
 |
HA（冗長化）の考え方
-
ECSの「タスクを2」にしただけでは、EC2が2台になるとは限らない
- EC2が1台しか無ければ、2タスクが同一ホストに載ることもある
本当のHAに必要なのは：
-
EC2インスタンスを2台以上（できれば別AZ）用意する
-
タスクが同一ホストに偏らないよう 分散配置する
- 例：ECSの
distinctInstance（別インスタンスへ配置）など
- 例：ECSの
アプリ側のスケーリング（同一構成で複数稼働）
製品によっては、同一の設定（同一ID/同一設定ファイル）で複数インスタンスを稼働させ、ワークロードを分散できる「アプリ側スケーリング」を提供している。
- ECSで複数タスクを稼働させる場合は、アプリ側のスケーリング設定（最大インスタンス数など）と整合するように設計する
- 逆に、アプリが単一インスタンス前提の場合は、同一設定の複製が競合を生むことがあるため注意
参考：Keeperゲートウェイは「スケーリングと高可用性」の考え方がドキュメント化されている。同一ゲートウェイを複数インスタンスとして扱う（最大インスタンス数の設定など）前提があるため、ECS側のタスク増減・配置設計と整合させるのがポイント。
まとめ
- 一般的な用途：ECS on Fargateが最小運用で速い
- OS/カーネル要件がある用途（例：RBI）：EC2ベースが無難
- EC2ベース＋HA/運用効率：ECS on EC2がバランス良い
- EC2直：最も単純だが、HAや更新運用は自前設計が必要
参考資料：