AWS ECS Deep Dive ドキュメント
Amazon Elastic Container Service の包括的なガイド — アーキテクチャ、コンポーネント、ネットワーキング、スケジューリング、スケーリング、運用上のベストプラクティス。 出典: Joud W. Awad — AWS ECS Deep Dive (Medium, Jan 2025)、現在の AWS ドキュメントで補足。
目次
-
Amazon ECS とは
-
ECS の 3 つのレイヤー
-
ECS アプリケーションライフサイクル
-
キャパシティオプション
-
ネットワーキング
-
インターネットからのインバウンドトラフィック受信
-
VPC 内から AWS サービスへの ECS 接続
-
サービス間通信
-
モニタリング
-
ECS クラスター
-
コンテナインスタンスの状態：ドレーニングと登録解除
-
ECS コンテナエージェント
-
タスク定義
-
ECS の IAM ロール
-
タスクネットワーキングモード（EC2 ローンチタイプ）
-
ストレージオプション
-
タスクスケジューリングとプレースメント
-
ECS タスクライフサイクル
-
スタンドアロンタスク
-
ECS サービス
-
ロードバランシング
-
オートスケーリング
-
タスクスケールイン保護
-
クイックリファレンスチートシート
-
最近の更新（2025 年）
Amazon ECS とは
Amazon Elastic Container Service（Amazon ECS）は、完全マネージドコンテナオーケストレーションサービスであり、コンテナ化されたアプリケーションの デプロイ、管理、スケーリングを支援します。完全マネージドサービスとして、AWS の設定と運用上のベストプラクティスが組み込まれています。
主な統合:
-
AWS ネイティブツール：Amazon ECR、IAM、CloudWatch、ALB/NLB、Auto Scaling、EventBridge
-
サードパーティツール：Docker、GitHub Actions、Terraform
AWS リージョンのクラウド内およびオンプレミスで、コントロールプレーンを管理することなく、コンテナワークロードを実行およびスケーリングできます。
ECS の 3 つのレイヤー
ECS アーキテクチャは 3 つの論理レイヤーに分割されています。
| レイヤー | 説明 |
| キャパシティ | コンテナが実行されるインフラストラクチャ（EC2、Fargate、オンプレミス）。 |
| コントローラー | コンテナ上で実行されるアプリケーションをデプロイおよび管理するソフトウェア。 |
| プロビジョニング | スケジューラーとインターフェースしてアプリケーションをデプロイおよび管理するために使用するツール。 |
ECS アプリケーションライフサイクル
アプリケーションを ECS に移動させる高度なライフサイクル：
-
コンテナ用のアーキテクト — コンテナは、アプリケーションを実行するために必要なすべてを保持する標準化されたソフトウェアユニットです：コード、ランタイム、システムツール、ライブラリ。
-
イメージをビルド — コンテナは、イメージと呼ばれる読み取り専用テンプレートから作成されます。イメージは通常
Dockerfileからビルドされます。 -
レジストリにイメージを格納 — 例：Amazon ECR。
-
タスク定義を作成 — アプリケーションを説明する JSON ブループリント：イメージ、ポート、ボリューム、環境変数、CPU/メモリなど。
-
クラスターにタスクまたはサービスとしてデプロイ。
-
モニタリング — CloudWatch、Container Insights、または Runtime Monitoring を使用。
コア用語
-
クラスター — 登録されたキャパシティインフラストラクチャ上で実行されるタスク/サービスの論理的グループ。
-
タスク定義 — アプリケーションを形成する 1 つ以上のコンテナの JSON ブループリント。
-
タスク — クラスター内のタスク定義の実体化。スタンドアロンで実行することもサービスの一部として実行することもできます。
-
サービス — 複数のタスクを同時に実行および維持します。タスクが失敗した場合、サービススケジューラーが置き換えを起動します。
-
コンテナエージェント — 各コンテナインスタンスで実行されます。実行中のタスクとリソース使用率を ECS に報告し、リクエストに応じてタスクを開始/停止します。
キャパシティオプション
キャパシティはコンテナが実行されるインフラストラクチャです。クラスター作成時にクラスターデフォルトレベルで設定し、タスク定義/ローンチタイプレベルでオーバーライドできます。
🆕 2025 年の更新 — Capacity Provider が推奨インターフェースになりました。 AWS は、ローンチタイプを直接指定する代わりにcapacity providerを使用してタスクを起動することを推奨しています。タスク定義の
requiresCompatibilitiesでのみ互換性検証のためにローンチタイプを使用してください。Capacity Provider は、より優れたリソースコントロール、コンピュートタイプ間の円滑な移行、および以下の新しい ECS Managed Instances オプションに必要です。
Fargate（サーバーレス）
サーバーレスの従量課金制コンピュートエンジン。サーバーを管理したり、キャパシティを計画したり、ワークロードを分離したりする必要はなく、正確な CPU とメモリを選択するだけです。
最適な用途:
-
運用オーバーヘッドが少なく必要な大規模ワークロード
-
時々バースト機能が必要な小規模ワークロード
-
ティニーワークロード
-
バッチワークロード
Capacity Provider:
-
FARGATE— オンデマンド -
FARGATE_SPOT— 割引されたスペアキャパシティ、中断耐性のみ（AWS がキャパシティを取り戻すときに 2 分間の警告）
EC2（自己管理）
Auto Scaling Groups を通じて、クラスターをバックアップする EC2 インスタンスを管理します。大規模ワークロードでコスト最適化が必須の場合、またはホスト（カスタム AMI、カーネルレベルツールなど）を完全に制御する必要がある場合に最適です。
EC2 でサービスを設計するときは、コンテナを目的でグループ化してください — 例えば、フロントエンドサービスとそのログストリーミングサイドカーは同じタスク定義に属します。バックエンド API とデータストアは別のタスク定義に属します。
ECS Managed Instances （2025 年 9 月に起動）
Fargate の手間のかからない操作とEC2 の柔軟性を組み合わせた、完全マネージド EC2 コンピュートオプション。タスク要件（vCPU、メモリ、CPU アーキテクチャ）を定義し、ECS は AWS が制御するアクセスを使用して、アカウント内で最適な EC2 インスタンスを自動的にプロビジョニング、構成、操作します。
主な機能:
-
属性ベースのインスタンス選択 — 範囲（例：8～16 vCPU）、CPU メーカー、アクセラレータータイプ、GPU サポート、ネットワーク最適化またはバーストファミリーを指定します
-
継続的なタスクプレースメント最適化 — ECS はインスタンス全体にタスクをビンパックし、過度に利用されていないインスタンスを自動的にドレーニングします
-
自動 AZ スプレッド — タスクは最初に AZ 全体に分散され、その後ビンパック
-
自動セキュリティパッチ（14 日ごと、EC2 イベントウィンドウ経由で週次メンテナンスウィンドウに設定可能）
-
Spot サポート （2025 年 12 月追加） — 障害耐性ワークロード向けに最大 90% 割引の
capacityOptionType: spotを設定 -
タグ伝播 — タグは capacity provider からインスタンス、ENI、ボリュームなどに流れます
最適な用途: GPU/ML 推論、高ネットワークワークロード、キャパシティ予約ニーズ、特権ホストアクセスが必要な eBPF ベースの可観測性ツール — Fargate より多くの機能が必要だが ASG を自分で実行したくない場合。
管理オーバーヘッドと基盤となる EC2 コストで請求されます。
External（ECS Anywhere）
EXTERNAL ローンチタイプを使用して、オンプレミスサーバーまたは VM を ECS クラスターに登録します。アウトバウンドまたはデータ処理ワークロードに最適です — 外部インスタンスに対する Elastic Load Balancing サポートがないため、インバウンド集約的なワークロードの効率が低下します。オンプレミスサーバーは ECS エージェントと SSM エージェントの両方を実行します。
キャパシティオプション比較
| オプション | 管理対象 | AWS が管理 | 最適な用途 |
| Fargate | タスク定義のみ | その他すべて | デフォルト；運用オーバーヘッド少 |
| Fargate Spot | タスク定義 + 中断処理 | その他すべて | 割引で障害耐性ワークロード |
| ECS Managed Instances | タスク要件 | インスタンスライフサイクル、パッチ適用、最適化 | ASG 管理なしの EC2 柔軟性 |
| EC2（自己管理） | ASG、AMI、スケーリング、パッチ適用 | ECS スケジューリング | 最大制御、カスタム AMI |
| ECS Anywhere | オンプレミスハードウェア + エージェント | ECS スケジューリング | ハイブリッド/オンプレミスワークロード |
ネットワーキング
AWS リソースはサブネットに存在します。ECS タスクは、ローンチタイプに応じて、クラスター、サービス、またはタスクレベルで指定したサブネット内で実行されます。
サブネットタイプ
| 接続性オプション | 使用時期 |
| パブリックサブネット + インターネットゲートウェイ | 高帯域幅または低レイテンシーが必要な公開アプリケーション — ビデオストリーミング、ゲーミング。 |
| プライベートサブネット + NAT ゲートウェイ | 直接外部アクセスから保護する必要があるアプリケーション — 支払い処理、ユーザーデータストア。 |
| AWS PrivateLink | VPC、AWS サービス、オンプレミスネットワーク間のパブリックインターネットにトラフィックを公開しないプライベート接続。 |
ヒント: NAT ゲートウェイコスト注: NAT ゲートウェイは時間ごとおよび処理データの GB ごとに課金されます。HA の場合、Availability Zone ごとに 1 つの NAT ゲートウェイを実行する必要があります — 小規模ワークロードには高額になる可能性があります。
インターネットからのインバウンドトラフィック受信
パブリックサービスの場合、インターネットとアプリケーション間にスケーラブルな入力レイヤーを配置します。3 つの主なオプション：
Application Load Balancer（ALB）— OSI レイヤー 7
HTTP/HTTPS サービスと REST API に最適です。
強み:
-
SSL/TLS 終端 — 証明書を管理し、SSL をアプリからオフロード
-
高度なルーティング — マイクロサービス向けホストおよびパスベースのルーティング
-
gRPC、WebSocket、HTTP/2 サポート
-
セキュリティ — HTTP デシンク緩和、AWS WAF 統合（SQLi、XSS 保護）
Network Load Balancer（NLB）— OSI レイヤー 4
非 HTTP プロトコルまたはエンドツーエンド暗号化が必要な場合に最適です。
強み:
-
エンドツーエンド暗号化 — パケット内容を読まずにレイヤー 4 で動作
-
TLS 終端 — オプションで TLS をオフロード
-
UDP サポート — その他の非 TCP プロトコル
Amazon API Gateway（HTTP API）
突然のバーストまたは低全体トラフィック量を持つ HTTP アプリに最適です。
価格設定モデルが異なります: ALB/NLB は LB の可用性を保つための時間単位の料金を請求します；API Gateway はリクエストごトに請求します。
-
低トラフィック/スパイキートラフィック → API Gateway はより安い
-
高持続トラフィック → ALB/NLB はリクエストごとに安い
API Gateway はVPC リンク経由でプライベート VPC サブネットに接続し、ECS Service Discovery が管理するAWS Cloud Mapレコード経由でプライベート IP を発見します。また、クライアント認可、使用層、リクエスト/レスポンス変換、エッジ/リージョナル/プライベートエンドポイント、およびレスポンスキャッシングなどの機能も追加します。
VPC 内から AWS サービスへの ECS 接続
ECS コンテナエージェントは ECS コントロールプレーンと通信する必要があります。ECR を使用する場合、ホストは ECR エンドポイントと S3（イメージレイヤーが存在する場所）に到達する必要があります。
オプション 1：NAT ゲートウェイ
最も簡単なパスですが、欠点があります：
-
細粒度の宛先制御がない — すべての VPC アウトバウンドトラフィックを中断することなく、NAT ゲートウェイバウンドトラフィックを特定の AWS サービスに制限することはできません。
-
GB あたりの課金 — 大規模 S3 オブジェクトの取得、大量の DynamoDB 読み取り、または ECR イメージプルはすべてお金がかかります。
-
帯域幅は 5 Gbps で上限です（自動スケーリングで最大 45 Gbps に）；非常に高帯域幅アプリの場合は、独自の NAT ゲートウェイを持つサブネット全体にワークロードを分割します。
オプション 2：AWS PrivateLink（VPC エンドポイント）
パブリックインターネットを横断することなく VPC とサポートされている AWS サービス間にプライベート接続を提供します。PrivateLink はサブネット内に ENI をプロビジョニングし、VPC ルーティングはサービスホスト名のトラフィックを ENI 経由で AWS サービスに直接送信します。
利点: IGW、NAT、パブリック IP 不要。トラフィックは AWS ネットワークを離れません。
サービス間通信
VPC で複数の ECS サービスを実行している場合、それらは相互に検出および通信する必要があります。3 つの主なアプローチがあります：
1. ECS Service Connect （推奨）
Service Connect は、サービス検出、接続、トラフィック監視向けの ECS マネージド構成を提供します。アプリは短い名前と標準ポートを使用して、同じクラスター、クラスター間、さらには同じリージョン内の VPC 間でサービスに接続できます。
ECS はサービス検出のすべての部分を処理します — 名前登録、タスクあたりの動的エントリ、および各タスク内のサイドカーエージェント。アプリは標準 DNS 検索を使用するため、既に実行している場合はコード変更は不要です。
プレーンサービス検出より推奨される理由:
-
高速フェイルオーバー — DNS TTL キャッシュに依存しない
-
組み込みの復元性 — 自動ロードバランシング、自動再試行（例：503）、接続ドレーニング、ネットワークレベルのヘルスチェック
-
標準化されたメトリクスとログ — 可観測性が組み込まれている
-
デプロイ中にのみ変更が発生 — 構成はサービス/タスク定義の一部です；更新はデプロイメントライフサイクルに関連付けられ、DNS 伝播遅延が回避されます
2. ECS Service Discovery（AWS Cloud Map）
DNS を使用したダイレクトサービス間通信。ECS は実行中のタスクのリストを Cloud Map に同期し、Cloud Map は内部タスク IP に解決する DNS ホスト名を維持します。
利点:
-
最低レイテンシー — トラフィックはコンテナ→コンテナに直接移動
-
シンプルなアーキテクチャ、追加コンポーネント不要
欠点:
-
アプリは再試行ロジックを実装し、スタール DNS レコード（TTL キャッシング は存在しなくなったコンテナのIP を返すことができる）をグレースフルに処理する必要があります
-
Service Connect ほど復元性または可観測性がない
📝 Service Discovery がまだ勝つ場合: CodeDeploy を使用したブルー/グリーンデプロイメントを使用している場合、Service Connect は履歴的に互換性がありませんでした（CodeDeploy
DeploymentControllerタイプがサポートされていなかった）。ネイティブ ECS ブルー/グリーンは現在 Service Connect でサポートされていますが、選択する前に デプロイメントコントローラーの互換性を確認してください。
3. 内部ロードバランサー
VPC 内部に完全にデプロイされた ALB または NLB。ServiceA は LB への接続を開きます；LB は ServiceB タスクへの接続を開きます。
利点:
-
接続の一元管理
-
自動ヘルスチェックが悪いターゲットを削除
-
アプリはダウンストリームコンテナ数を追跡する必要がない
欠点:
-
コスト — ロードバランサーは AZ ごとに冗長リソースが必要
-
緩和: 複数のサービスで 1 つの ALB を共有します（例：
/api/user/*→ ユーザーサービス、/api/order/*→ 注文サービス）
4. Amazon VPC Lattice （モダンオプション）
マネージドアプリケーションネットワーキングサービス。ECS サービスを VPC Lattice ターゲットグループに関連付けることで、ECS はタスクを IP ターゲットとして自動登録します。コード変更なしに、コンピュートサービス、VPC、アカウント全体でアプリケーションを接続、監視、セキュアにするのに役立ちます。
モニタリング
クラスターを設定する前に、以下を回答するモニタリング計画を構築します：
-
モニタリング目標は何ですか？
-
どのリソースを監視しますか？
-
どのくらいの頻度で？
-
どのツール？
-
誰がモニタリングを実行しますか？
-
何か壊れたときに誰がページされますか？
最小ベースラインメトリクス
-
CPU とメモリ予約 + 使用率クラスターレベル
-
CPU とメモリ使用率サービスレベル
使用可能なメトリクスはローンチタイプに応じて異なります：
-
Fargate: CPU とメモリ使用率メトリクスはサービスごとに自動的に提供されます
-
EC2: EC2 インスタンス自体も監視する必要があります；クラスター/サービス/タスクレベルの予約と使用率メトリクスも利用できます
ツーリングオプション
-
CloudWatch アラーム — しきい値ベースのアラート；Fargate サービスの Auto Scaling を駆動することもできます
-
CloudWatch ログ — タスク定義で
awslogsログドライバーを設定してコンテナ stdout/stderr をキャプチャ -
CloudWatch Events / EventBridge — イベントと照合してターゲットにルーティング、自動応答
-
Container Insights — 構造化 JSON パフォーマンスログイベントを使用してコンテナ化されたワークロードのパフォーマンスメトリクスとログを収集、集約、要約；CloudWatch はクラスター/サービス/タスクレベルで集約メトリクスを作成します（Enhanced Observability モードはコンテナレベルの詳細を追加）
-
CloudTrail — API アクションをログ；リアルタイムモニタリング用に CloudWatch ログに送信
-
Runtime Monitoring — GuardDuty セキュリティエージェントを使用したランタイム可視性（ファイルアクセス、プロセス実行、ネットワーク接続）
警告: Container Insights メトリクスは、時間範囲内に実行中のタスクを持つリソースのみを反映します。
desiredCount > 0だが実行中のタスクRUNNINGがないサービスは*メトリクスを出力しません。
EventBridge で応答を自動化
ECS はこれらのイベントタイプをほぼリアルタイムで EventBridge に出力します：
-
コンテナインスタンス状態変化
-
タスク状態変化
-
サービスアクション
-
サービスデプロイメント状態変化
関心のあるイベントと照合するルールを作成し、自動応答（Lambda、SNS、Step Functions など）をトリガーします。
コンテナヘルスチェック
タスク定義で定義され、コンテナ内で実行され、終了コードを評価します：
| パラメーター | 意味 |
command | コンテナ内で実行されるコマンド（例：curl localhost:80） |
interval | チェック間の秒数 |
timeout | チェックが失敗とマークされるまでの秒数 |
retries | コンテナが不正常とマークされるまでの失敗したチェック数 |
startPeriod | ブートストラップ中のオプションの猶予期間 |
health_check = {
command = ["CMD-SHELL", "curl -f -m 1.00 http://localhost:80 || exit 1"]
timeout = 2
retries = 3
interval = 10
startPeriod = 10
}
可能なステータス: HEALTHY、UNHEALTHY、UNKNOWN。
タスクヘルスロールアップルール（順序で評価）：
-
任意の必須コンテナが
UNHEALTHY→ タスクUNHEALTHY -
任意の必須コンテナが
UNKNOWN→ タスクUNKNOWN -
すべての必須コンテナが
HEALTHY→ タスクHEALTHY
ヒント: ECS はイメージ内に埋め込まれた Docker
HEALTHCHECKディレクティブを監視しません。コンテナ定義で宣言されていない限り、コンテナ定義ヘルスチェックはイメージ埋め込みをオーバーライドします。
ECS Exec
SSH やオープンポートなしで実行中のコンテナに接続：
-
ダイレクトコンテナアクセス — EC2 ベースまたは Fargate ベースのタスクでコマンドを実行またはシェルを開く
-
強化されたセキュリティ — SSH キーなし、追加のインバウンドポートなし
-
監査 — ECS Exec セッションは CloudWatch ログまたは S3 にログでき、CloudTrail は接続者とタイミングを記録します
ECS Exec は接続に AWS Systems Manager Session Manager を使用し、認可に IAM ポリシーを使用します。SSM エージェントバイナリはコンテナにバインドマウントされ、ECS/Fargate エージェントはアプリケーションの横で SSM コアエージェントを開始します。
ECS クラスター
クラスターはタスクとサービスの論理的グループです。以下を含みます：
-
インフラストラクチャキャパシティプロバイダー
-
ネットワーク（VPC とサブネット）
-
オプションの名前空間 — Service Connect に使用
-
監視オプション（例：Container Insights）
Capacity Provider — Fargate
Fargate を使用する場合、キャパシティを作成または管理する必要はありません。クラスターに以下の事前定義プロバイダーのいずれかまたは両方を関連付けます：
-
FARGATE -
FARGATE_SPOT
Spot タスクが回収されると、ECS は中断を説明する停止理由と共に task state change イベントを EventBridge に送信します。
Capacity Provider — EC2
Auto Scaling Group（ASG） を使用して、クラスターに登録された EC2 インスタンスを管理します。ECS はマネージドスケーリング経由でスケールイン/スケールアウトを管理することも、自分で管理することもできます。
🔹 ベストプラクティス: Capacity Provider 用に新しい、空の ASG を作成します。既に登録済みインスタンスを持つ既存 ASG を再利用すると、Capacity Provider との登録の不一致が発生する可能性があります。
🔹 スケールイン中に EC2 を正常に終了するためにマネージドインスタンスドレーニングを有効化します（デフォルトでオン）。
Capacity Provider 戦略
2 つのパラメーターを使用してプロバイダー全体にタスクを分散します：
-
base— 特定のプロバイダーで実行する必要がある最小タスク数。戦略内の 1 つのプロバイダーのみがベースを定義できます。 -
weight— 相対パーセンテージ分割。capacityProviderA=1とcapacityProviderB=4で、A の 1 つのタスクごとに B の 4 つのタスクが一致します。
例：75% Fargate / 25% Fargate Spot → FARGATE で weight 3、FARGATE_SPOT で weight 1。
コンテナインスタンス状態：ドレーニングと登録解除
これら 2 つの操作はよく混同されます。
ドレーニング
インスタンスを DRAINING に移行すると、新しいタスクがスケジュールされなくなり、実行中のタスクが安全に削除されます。システム更新、スケールイン、メンテナンス中に使用されます。
サービスの場合:
-
保留中のタスク は即座に停止されます。クラスターキャパシティで許可された場合、スケジューラーは置き換えを起動します。
-
実行中のタスク は
STOPPEDに移行されます。スケジューラーはデプロイメント構成に基づいてそれらを置き換えます：-
minimumHealthyPercent— 正常なタスク数の下限。desiredCount=4とminimumHealthyPercent=50%で、少なくとも 2 つのタスクが正常なままである必要があります。スケジューラーは置き換えを起動する前に最大 2 つのタスクを停止できます。 -
maximumPercent— 上限。desiredCount=4とmaximumPercent=200%で、置き換え中に最大 8 つのタスクが実行でき、より高速なブルー/グリーン形式の置き換えが可能になります。
-
スタンドアロンタスクの場合: 保留中および実行中のタスクは影響を受けません。それらを手動で完了または停止するまで待つ必要があります。インスタンスは完了または再アクティブ化まで DRAINING のままです。
ドレーニングインスタンスは、その状態を ACTIVE に戻すとき戻ります。それまでは DRAINING のままです。
登録解除 （EC2 のみ）
EC2 インスタンスをクラスターから削除します。新しいタスクでは利用できなくなります。
主な落とし穴:
-
実行中のタスクは孤立 — ECS は管理しなくなりますが、実行が継続します。サービスタスクは他のインスタンスのスケジューラーによって置き換えられます。
-
EC2 インスタンスは終了されません — 手動で終了して課金を停止する必要があります。
-
ASG / CloudFormation: インスタンスを削除するように ASG またはスタックを更新します — そうしないと ASG は新しいインスタンスで置き換えます。
比較
| 側面 | ドレーニング | 登録解除 |
| 目的 | 一時的に新しいタスクのスケジューリングを停止；実行中のものを正常に削除 | クラスターからインスタンスを永久に削除 |
| 可逆 | はい（ACTIVE に戻る） | いいえ |
| 実行中のタスクへの影響 | 停止/置き換え（サービス）；未処理（スタンドアロン） | 孤立（実行継続、管理されない） |
| EC2 インスタンスの運命 | 存在し続ける | 存在し続ける（別途終了する必要あり） |
| 適用対象 | EC2 と Fargate の両方 | EC2 のみ |
ECS コンテナエージェント
すべてのコンテナインスタンス上で実行されるプロセス。インスタンスと ECS 間の通信を容易にします。
状態遷移:
-
登録成功 → インスタンスステータス
ACTIVE、エージェント接続TRUE→ run-task リクエストを受け入れることができます。 -
インスタンスを停止（終了ではなく）→ ステータスは
ACTIVEのままですが、エージェント接続は数分以内にFALSEにドロップ；実行中のタスクが停止します。 -
インスタンスを再起動 → エージェント再接続、インスタンスはタスクを実行できます。
-
状態を
DRAININGに設定 → 新しいタスク配置なし；可能な場合はサービスタスク削除。 -
登録解除または終了 → ステータスは即座に
INACTIVEに；インスタンスは終了後1 時間は説明可能、その後は消えます。
ヒント: 可能な限り最新の ECS エージェントバージョンを常に実行 — 各バージョンは機能とバグ修正を追加します。
タスク定義
タスク定義はアプリケーションの JSON ブループリント — コンテナ、ポート、環境変数、ボリューム、IAM ロール、ネットワーキングモード、ログ、リソースサイズを定義します。
タスク定義状態
| 状態 | 意味 |
ACTIVE | 登録済みで、タスク実行またはサービス作成に使用可能。 |
INACTIVE | 登録解除。既存のタスク/サービスは影響を受けませんが、新しいタスク/サービスは作成できません。依然 DescribeTaskDefinition 経由で取得可能。 |
DELETE_IN_PROGRESS | 削除を申請。ECS が削除を永久削除する前に、アクティブなタスク/デプロイメントで参照されていないことを確認します。 |
コンテナイメージのベストプラクティス
-
イメージを自己完結型にする — 静的ファイルとしてすべての依存関係をイメージにバンドル。
-
コンテナごと 1 プロセス — 「ファットコンテナ」アンチパターンを回避。
-
SIGTERMをグレースフルに処理 — ECS がタスクを停止すると、SIGTERMを送信し、停止タイムアウト後にSIGKILLを送信。SIGTERMを無視するアプリはウェイトを強制します。SIGTERMハンドラーは以下を行う必要があります：- 新しい作業を受け入れるのをやめる
- 進行中の作業を完了、または
- 完了できない場合は、無完成作業を外部ストレージに永続化
-
stdout/stderrにログ — ログ処理をアプリコードから分離；インフラはレデプロイなしでログルーティングを調整できます。 -
イメージをタグ付けしてバージョン管理 — コミットごとにビルドしない、リリースごと。イメージタグを不変リリースマーカーとして扱う。
タスクサイズ（CPU/メモリ）
CPU は 1024 ユニット = 1 フル vCPU で測定。メモリは MB。
-
予約 — 保証される最小値。スケジューラーは予約を満たせないインスタンスにタスクを配置しません。
-
制限 — ハード上限。CPU 超過 → スロットル。メモリ超過 → コンテナ停止。
-
バースト — 予約より多く使用（制限まで）キャパシティでは許可されます。
ステートレスアプリ（LB の背後）：
-
ps、top、または Container Insights を通じてメモリ消費を実験的に決定。 -
CPU：小さい予約（例：256 ユニット/¼ vCPU）→ 細粒度、安い、スパイクでスケールが遅い。大きい予約 → スパイク応答が高速、高額。
シングルトン/非水平アプリ（ワーカー、DB サーバー）：
- SLO のロードテスト に基づいて CPU/メモリを選択。ECS は十分なキャパシティを持つホストへの配置を保証します。
📚 完全なタスク定義パラメーター参照については、公式 AWS ドキュメントを参照 — パラメーターは頻繁に変更されます。
ECS の IAM ロール
ECS は、ローンチタイプと機能に応じて複数の異なる IAM ロールを使用します。
| ロール | 目的 |
| タスク実行ロール | ECS エージェントと Fargate エージェントが ECR からイメージをプル、CloudWatch にログを送信、Secrets Manager/SSM Parameter Store からシークレットをフェッチするために使用。 |
| タスクロール | コンテナ内のアプリケーションコードが AWS API を呼び出すために使用（例：S3、DynamoDB）。 |
| ECS のサービスリンクロール | ECS が自分に代わって他の AWS サービスを呼び出すことを許可（自動作成）。 |
| コンテナインスタンス IAM ロール（EC2 のみ） | EC2 ホストがクラスターに登録し、テレメトリーを送信し、イメージをプルできるようにします。EC2 インスタンスプロファイルにアタッチされます。 |
| EventBridge/Auto Scaling ロール | スケジュール済みタスクと Application Auto Scaling に必要。 |
タスクネットワーキングモード（EC2 ローンチタイプ）
タスク定義で定義。各モードにはトレードオフがあります。
awsvpc （推奨）
各タスクに EC2 インスタンスと同じネットワーキング機能を提供 — 独自の ENI でプライベート IP（デュアルスタックの場合は IPv6）。
-
細粒度セキュリティ — タスクごとのセキュリティグループ、VPC Flow ログなど。
-
シンプルなネットワーキング — ポート衝突なし；同じタスク内のコンテナが
localhostを共有。 -
各タスクは 1 つの ENI のみを持つことができます。
host
コンテナネットワーキングは EC2 ホストに直接関連付けられます。コンテナはホストの IP とポートで監視します。
-
大きな欠点: ホストごと 1 つのタスクインスタンスのみ（ポート衝突）；ポート リマッピングなし。
-
推奨されない。
bridge
ホストとコンテナ間の仮想ネットワークブリッジ、ポートマッピング付き（静的または動的）。
-
静的マッピング — ホストポート → コンテナポートを明示的にマップ。
hostと同じようにホストごと 1 つのインスタンスの制限。 -
動的マッピング — Docker はホスト上のランダムエフェメラルポートを割り当て。複数のインスタンスがホストごとに可能。
-
欠点: 動的ポートは、サービス間セキュリティグループをロックダウンするのが難しくしています（広いポート範囲を開く必要があります）。
| モード | ホストごと複数タスク？ | タスクごと SG？ | 最適な用途 |
awsvpc | ✅ | ✅ | デフォルト選択 |
host | ❌ | ❌ | ホストレベルネットワーキングが必要なレアケース |
bridge（静的） | ❌ | ❌ | レガシーまたは特定のポート要件 |
bridge（動的） | ✅ | ❌ | 複数インスタンス awsvpc が使用できない場合 |
ストレージオプション
ECS はタスク向けの複数のボリュームタイプをサポート。正しい選択は永続化、共有、パフォーマンスニーズに依存します：
-
バインドマウント — ホストファイルシステムマウント；エフェメラル
-
Docker ボリューム — ホスト上の Docker で管理
-
Amazon EFS — 共有、永続、マルチ AZ；共有状態と Fargate に最適
-
Amazon FSx for Windows File Server — Windows コンテナで SMB
-
Amazon EBS — ブロックストレージ、EC2 ローンチタイプ
-
エフェメラルストレージ — 一時、タスク寿命にスコープ
完全パラメーター参照については、AWS タスク定義ドキュメントを参照。
タスクスケジューリングとプレースメント
ECS は、長時間実行されるアプリ用のサービススケジューラーと、バッチ/シングルラン ジョブ用のスタンドアロンまたはスケジュール済みタスクを提供します。
プレースメントコンポーネント
-
タスクプレースメント戦略 — インスタンス（およびターミネーション対象のタスク）を選ぶアルゴリズム。例：ランダム、スプレッド、ビンパック。
-
タスクグループ — 関連タスクの論理グループ（例：すべての DB タスク）。
-
タスクプレースメント制約 — タスクをホストするインスタンスは満たさなければならないルール。未出の制約はタスクを
PENDINGのままにします。
EC2 ローンチタイプ — プレースメントアルゴリズム
タスクを配置する場合、ECS：
-
CPU/GPU/メモリ/ポート要件を満たすインスタンスを識別
-
プレースメント制約でフィルター
-
プレースメント戦略でフィルター
-
ベストインスタンスを選択
デフォルト:
-
サービスの一部として実行されるタスク：
attribute:ecs.availability-zoneでspread -
スタンドアロンタスク：デフォルト制約なし
Fargate ローンチタイプ
警告: プレースメント戦略と制約は Fargate でサポートされていません。 Fargate は AZ 全体に最善の努力スプレッドを行います。戦略内に Fargate と Fargate Spot の両方がある場合、スプレッドはプロバイダーごとに独立しています。
戦略タイプ
| 戦略 | 実行内容 | 共通フィールド |
random | タスクをランダムにインスタンスに配置 | — |
spread | ディメンション全体にタスクを均等に分散 | instanceId、attribute:ecs.availability-zone |
binpack | 最も利用可能な CPU またはメモリに基づいて最も少ないインスタンスにタスクをパック | cpu、memory |
戦略を構成
複数の戦略をチェーンすることができます — AZ 全体にスプレッド、各 AZ 内のインスタンス全体にスプレッド：
"placementStrategy": [
{ "field": "attribute:ecs.availability-zone", "type": "spread" },
{ "field": "instanceId", "type": "spread" }
]
タスクグループ
同じタスクグループ名を持つすべてのタスク はspread を適用するときにセットと見なされます。タスクグループは memberOf を通じてプレースメント制約としても機能できます。
デフォルト:
-
スタンドアロンタスク → タスク定義ファミリー名（例：
family:my-task-definition） -
サービスタスク → サービス名（変更不可）
制約タイプ
| タイプ | 説明 |
distinctInstance | タスクは異なるインスタンスで実行する必要があります |
memberOf | タスクは、クラスタークエリー言語式と照合するインスタンスのみに配置 |
ECS タスクライフサイクル
タスクはローンチから終了までこれらの状態を通ります：
| 状態 | 説明 |
PROVISIONING | ECS が前提条件をセットアップ — 例：awsvpc モード用の ENI 作成。 |
PENDING | コンテナエージェントを待機中 — 通常はキャパシティを待機中。 |
ACTIVATING | イメージをプル、コンテナ作成、ネットワーク構成、ターゲットグループ登録、サービス検出構成。 |
RUNNING | タスクは稼働中。 |
DEACTIVATING | テアダウン準備を実行 — 例：LB ターゲットグループから登録解除。 |
STOPPING | エージェント SIGTERM を送信、StopTimeout を待機、その後 SIGKILL。 |
DEPROVISIONING | ENI をデタッチ/削除など。 |
STOPPED | タスク完全停止。 |
DELETED | 内部遷移；describe-tasks 経由のみで表示、コンソールではない。 |
ECS はすべてのタスクの両方の lastStatus（現在）と desiredStatus（ターゲット）を追跡します。
スタンドアロンタスク
アプリがいくつかの作業を行って停止するときに使用 — 例：バッチジョブ。コンソール、AWS CLI、API/SDK、または EventBridge Scheduler 経由でトリガーされます。
起動時、タスクは PROVISIONING で開始し、ECS はキャパシティを検出（ローンチタイプまたは capacity provider 戦略を使用）、その後ライフサイクルを通ります。マネージドスケーリング capacity provider では、キャパシティ不足タスクは即座に失敗するのではなく PROVISIONING のままです。
タスク起動時間を最適化
-
キャッシュイメージ + ビンパック — ECS エージェントのイメージプル動作を
prefer-cached（EC2 のみ）に設定し、binpack戦略を使用してタスクを少ないインスタンスに統合。Windows ワークロードに大規模イメージのヘルプ。複数の同時awsvpcタスク用にENI トランキングを有効化。 -
正しいネットワークモードを選ぶ —
awsvpcは ENI プロビジョニングレイテンシーを追加；bridgeは タスクごとのセキュリティグループが必要ない場合より高速。 -
起動ライフサイクルを監視 — Task メタデータエンドポイントを使用して
ContainerStartTime→ 準備を取得、その後イメージサイズとブートストラップオーバーヘッドを削減。 -
インスタンスを右サイズ化 — CPU/メモリを実際の予約と照合（例：実際の予約 2 GB の 4 タスクを清潔にホストする
m5.large2 vCPU/8 GB）。
EventBridge Scheduler
サーバーレススケジューラー — EventBridge バス/ルールとは独立に動作、より広いな API ターゲット。サポート：
-
レート基準スケジュール（例：5 分ごと）
-
Cron ベーススケジュール
-
ワンタイムスケジュール
ECS サービス
サービスは複数のタスクインスタンスを同時に実行および維持します。タスクが失敗した場合、サービススケジューラーは置き換えを起動します。
スケジューリング戦略
| 戦略 | 動作 | Fargate？ |
REPLICA | クラスター全体で望ましいタスク数を維持（デフォルト：AZ 全体にスプレッド）。 | ✅ |
DAEMON | プレースメント制約を満たすアクティブなコンテナインスタンスごと正確に 1 つのタスクを実行。 | ❌ サポートされていない |
REPLICA 戦略
-
desiredCountを定義 -
タスクはロードバランサーの背後に座ることができます
-
戦略/制約を使用したプレースメントをカスタマイズ
-
コンテナヘルスチェックまたは LB ターゲットグループヘルスチェック経由のヘルスモニタリング
-
失敗スロットル — タスクが反復的に
RUNNINGに入動くことができない場合、スケジューラーは起動試行をスローダウンし、リソース浪費を防ぐためにサービスイベントを出力
ヒント: REPLICA で AZ Rebalancing を使用 — タスクを AZ 全体に均等に分散を維持。
不正常なタスク置き換えフロー:
-
サービス はタスクを不正常とマーク
-
スケジューラーは置き換えを開始
-
置き換えが
HEALTHY→ 元の不正常タスク停止 -
置き換えが
UNHEALTHY→ スケジューラーは総数をdesiredCount近くに保つため、不正常なタスクの 1 つをランダムに停止 -
maximumPercentが最初から ブロック → スケジューラーは不正常なタスク 1 つを停止してキャパシティを解放、その後置き換えを起動 -
すべての不正常なタスクが置き換えられるまで繰り返し；過剰がある場合、健全なタスクは
desiredCountにランダムに停止
DAEMON 戦略
-
アクティブなコンテナインスタンスごと正確に 1 つのタスク
-
ECS は daemon タスク用に CPU、メモリ、ネットワークインターフェースを予約
-
Daemon タスクに優先度あり — daemon + replica サービスを混ぜるクラスターでは最初に起動し最後に停止
-
ログ/監視エージェントに最適 — すべてのホストで実行される必要があります
Availability Zone Rebalancing
サービスが定常状態に到達した後、ECS は継続的にタスク数を AZ ごとに監視。不均衡の場合：
-
ECS は利用不足の AZ で新しいタスクを起動
-
新しいタスク確認
HEALTHYになると、ECS は利用過多の AZ でタスクを停止
サポート:
-
Fargate と EC2 両方のローンチタイプ（Fargate 自動再分散；EC2 は既存インスタンス全体でプレースメント戦略に基づいて再均衡、新しいインスタンスはプロビジョニングなし）
-
REPLICA スケジューリング戦略で AZ スプレッドまたはプレースメント戦略なし
サポートされていない場合:
-
DAEMON 戦略
-
EXTERNALローンチタイプ（ECS Anywhere） -
maximumPercent = 100% -
Classic Load Balancer
-
attribute:ecs.availability-zoneをプレースメント制約として
ロードバランシング
Fargate の ECS サービスは ALB、NLB、Gateway Load Balancer をサポート。NLB または GWLB 機能が特に必要でない限り ALB を使用します。
ヘルスチェックパラメーターを最適化
2 つの主なパラメーターがデプロイメント速度を制御：
-
HealthCheckIntervalSeconds— チェック間の時間（デフォルト 30 秒） -
HealthyThresholdCount— 健全とマークするための連続パス（デフォルト 5）
デフォルトでは、コンテナは健全とマークされるまで最大2m30sがかかります。
🔧 サービスが 10 秒以下で起動する場合、interval を5 秒に、threshold を2に設定 — 合計～10 秒。メジャーデプロイメント高速化。
接続ドレーニング最適化
クライアントは再利用用に接続を生きているままにします；LB は クライアントが接続を閉じたかをチェックしてからターゲットを停止します。
-
deregistration_delay.timeout_seconds— LB がターゲットをUNUSEDに強制するまで待機する期間。デフォルト：300 秒。 -
sub-1 秒レスポンスタイムのサービスの場合、これを5 秒に設定。
SIGTERM 応答性
-
ECS_CONTAINER_STOP_TIMEOUT—SIGTERMとSIGKILL間の時間。デフォルト：30 秒。 -
高速シャットダウンアプリの場合、2 秒に低下し、コードで
SIGTERMをトラップ：
process.on('SIGTERM', function() {
server.close();
});
これは新しいリクエストを受け入れるのを停止、進行中のものを完了、クリーンに終了 — 多くの場合ストップタイムアウト内で、SIGKILL を回避。
🆕 2025 年 12 月 — Fargate でカスタムストップシグナル。 Fargate は現在、OCI 準拠のコンテナイメージから
STOPSIGNALを読み取り、タスク終了中に適切なシグナル（SIGQUIT、SIGINTなど）を送信します。SIGTERMのデフォルト ではなくSIGQUIT（例：Nginx グレースフルシャットダウン）またはSIGINTを使用するアプリに役立ちます。すべてのリージョンで追加コストなしで利用可能。
オートスケーリング
ECS は Application Auto Scaling を活用し、望ましいタスク数を動的に調整。
4 つのスケーリングタイプ
| タイプ | 動作方法 | 使用時期 |
| ターゲットトラッキング （推奨デフォルト） | メトリクスの目標値を維持（例：CPU 50%）— サーモスタットのような。 | ほとんどのワークロード；キャパシティで線形にスケールするメトリクス。 |
| ステップスケーリング | CloudWatch アラームブレーチ大きさに基づいてステップ調整。 | 異なるアラーム重大度に対して異なるスケーリング大きさが必要。 |
| スケジュール済みスケーリング | 特定の時間にスケールアップ/ダウン。 | 予測可能な日次/週次トラフィックパターン。 |
| 予測スケーリング | ML はパターン検出と事前スケーリングのため過去負荷を分析。 | 強い日次/週次季節性を持つワークロード。 |
ヒント: デフォルトでターゲットトラッキング を CPU 平均使用率またはリクエスト数ターゲット当たり — キャパシティが増加すると低下し、ECS は需要を清潔に追うことができます。
タスクスケールイン保護
自動スケーリングまたはデプロイメントからのスケールイン イベント中のタスク終了から、ミッションクリティカルなタスクを保護。
ユースケース
-
非同期ジョブ処理 — ビデオトランスコーディング、数時間実行されるデータジョブ
-
ゲームサーバー — アクティブなセッションをホストする ECS タスク；再起動レイテンシーは高額
-
デプロイ中 — 高額な作業を行うタスクを保護
構成
-
protectionEnabledをtrueに設定 -
デフォルト保護：2 時間
-
expiresInMinutesを通じてカスタマイズ：最小1 分、最大2880 分（48 時間） -
作業終了後、
protectionEnabled = falseを設定して正常な終了を許可
保護設定 — 2 つのメカニズム
1. ECS コンテナエージェントエンドポイント （自己決定タスク）
キューベース またはジョブ処理ワークロード用。コンテナ内から、ヒット：
$ECS_AGENT_URI/task-protection/v1/state
SQS メッセージを消費するときに ProtectionEnabled を設定、作業が終了したときにクリア。タスク自身が忙しいときを知るワークロードに推奨。
2. ECS API （外部追跡タスク）
UpdateTaskProtection を使用してタスクを保護とマーク、GetTaskProtection で状態をクエリー。タスクライフサイクルを追跡する外部サービスがある場合に 良い — 例：ユーザーがログインしたときにタスクをマーク、ログアウト時にクリアするゲームサーバーコントローラー。
両方を組み合わせることができます — エージェントエンドポイントで内部から保護を設定、API で外部コントローラーからクリア。
クイックリファレンスチートシート
ローンチタイプの決定
-
最も低い運用オーバーヘッドが必要？ → Fargate
-
スケール時にコスト敏感？ → EC2
-
バースト/バッチ/ティニー？ → Fargate（または中断耐性向けの Fargate Spot）
-
オンプレミス要件？ → ECS Anywhere
ネットワーキング決定（EC2 モード）
-
デフォルト選択 →
awsvpc -
タスクごと SG なしでホストごと複数タスク → 動的ポート付き
bridge -
回避 →
host
インバウンドエントリポイント
-
HTTP/REST API → ALB
-
TCP/UDP/エンドツーエンド TLS → NLB
-
スパイキング/低ボリューム HTTP → API Gateway
サービス間
-
デフォルト → Service Connect
-
最低レイテンシー、シンプルセットアップ → Service Discovery（アプリで再試行ロジック付き）
-
多くのサービス向けに一元的ルーティングが必要 → パスベースのルーティング付き内部 ALB
オートスケーリング
-
デフォルト → CPU/メモリまたは RPS でターゲットトラッキング
-
予測可能なスケジュール → スケジュール済みスケーリング
-
季節パターン → 予測スケーリング
ヘルスチェック調整（高速起動サービス）
-
HealthCheckIntervalSeconds：5 -
HealthyThresholdCount：2 -
deregistration_delay.timeout_seconds：5 -
ECS_CONTAINER_STOP_TIMEOUT：2 -
アプリは
SIGTERMをトラップ する必要があります
最近の更新（2025 年）
ECS は 2025 年にオリジナル記事を超える複数の重要な更新を出荷。ハイライト：
ECS Express モード （2025 年 11 月、re:Invent）
コンテナ化された Web アプリケーション API を迅速に起動する新機能。3 つの入力を提供 — コンテナイメージ、タスク実行ロール、インフラストラクチャロール — そして ECS は自動的にプロビジョニングします：
-
Fargate ベースの ECS サービス
-
ポート 443 の HTTPS と SSL/TLS 終端付きの ALB
-
オートスケーリングポリシー
-
CloudWatch モニタリングとアラーム
-
最小権限ルール付きセキュリティグループ
-
.ecs.<region>.on.awsでユニーク URL
主な詳細:
-
Fargate のみ；Blue/Green デプロイメントサポートなし
-
最大25 個の Express Mode サービスは単一の ALB を共有できます（インテリジェントルールベースのルーティング）
-
更新はデフォルトでカナリアデプロイメントを使用
-
リソースはアカウントに留まります — 完全にアクセスおよび変更可能
-
追加料金はなし；基盤となる AWS リソースのみを支払う
-
ECS と Fargate がサポートされているすべての AWS リージョンで利用可能
-
Console、CLI、SDK、CloudFormation、CDK、Terraform で管理可能
ECS Managed Instances （2025 年 9 月起動、2025 年 10 月 GA、2025 年 12 月 Spot サポート）
上記のキャパシティオプションセクションでカバー。TL;DR：14 日ごとのパッチ適用と継続的なタスク配置最適化を処理する完全マネージド EC2 capacity provider — Fargate の手間のかかる操作を EC2 の柔軟性（GPU、カスタムインスタンスタイプなど）と組み合わせる。
Fargate のカスタムコンテナストップシグナル （2025 年 12 月）
Fargate はここで OCI 準拠のコンテナイメージから STOPSIGNAL を読み取り、タスク終了中に適切なシグナル（SIGQUIT、SIGINT など）を送信します。SIGTERM ではなく、グレースフルシャットダウン（例：Nginx）に非デフォルトシグナルを使用するアプリに役立ちます。すべてのリージョンで追加コストなしで利用可能。
IPv6 のみワークロード （re:Invent 2025）
ECS は IPv4 依存を持たずにIPv6 のみ環境でコンテナ化されたアプリケーションを実行できるようになり、既存アプリと AWS サービスとの互換性を維持。IPv4 枯渇に対応し、ネットワークアーキテクチャを簡素化し、IPv6 コンプライアンス要件を満たすのに役立ちます。
SOCI Parallel Pull Mode （re:Invent 2025）
ダウンロードとアンパック フェーズの構成可能並列化によるコンテナ起動速度の向上の新しいイメージプル戦略。AWS は 10 GB Deep Learning Container イメージで**～60% 高速プルを測定** — 特に大規模イメージを持つ AI/ML ワークロードに有価値。
VPC Lattice 統合
ECS サービスを VPC Lattice ターゲットグループに IP ターゲットとして関連付けることができるようになりました。ECS はタスク起動時にターゲットグループに自動登録、VPC、アカウント全体でのクロスアプリケーションネットワーキングを可能に — コード変更なしで組み込み可観測性とセキュリティ。
Service Connect でのネイティブブルー/グリーン
2025 年前半、ECS ネイティブ Blue/Green デプロイメントは ロードバランサーとともに Service Connect のサポートを追加、Service Connect ではなく Service Discovery を選択する 1 つの履歴的理由を削除（CodeDeploy DeploymentController 互換性）。
ローンチタイプ上の Capacity Provider が優先
AWS は、capacity provider を新しいワークロード用のプライマリメカニズムとして明示的に推奨するようになりました。互換性検証用のタスク定義の requiresCompatibilities フィールドでのみローンチタイプを使用してください。Capacity Provider はより優れたリソースコントロール、コンピュートタイプ間のシームレスな移行、ECS Managed Instances に必須を提供します。
Copilot CLI 日没
AWS Copilot CLI は 2026 年 6 月 12 日に共有が終了します。 これは引き続き オープンソース GitHub プロジェクトとして利用可能ですが、AWS からは新しい機能またはセキュリティ更新を受け取りません。ECS Express Mode は簡素化ストーリーの一部として位置付けられています。
結論
ECS はクラスター、タスク定義、タスク、サービスが構成してスケーラブル、復元性、可観測性のあるコンテナワークロードを提供する、AWS でコンテナを実行する深く統合された方法を提供します。大きなレバレッジポイント：
-
ローンチタイプではなく capacity provider を直接使用、新しいワークロード用
-
正しいキャパシティオプションを選ぶ — Fargate で低運用オーバーヘッド、ECS Managed Instances で EC2 柔軟性なし ASG 管理、自己管理 EC2 で完全制御
-
シンプルな Web アプリと API 用 ECS Express Mode を試す — 3 つの入力、本番準備スタック
-
ネットワーキングモード
awsvpcを使用、具体的な理由がない限り -
サービス間通信に Service Connect を優先
-
高速デプロイメント用のヘルスチェック、ドレーニング遅延、
SIGTERM処理を調整 -
キャパシティに線形に応答するメトリクス上のターゲットトラッキングオートスケーリングを使用
-
復元力のためのプレースメント戦略と AZ Rebalancing で AZ 全体にスプレッド
-
スケールインからの長時間実行タスク保護 タスクスケールイン保護で
参照
-
Joud W. Awad — AWS ECS Deep Dive (Medium, Jan 2025): https://joudwawad.medium.com/aws-ecs-deep-dive-c8f773af0bf6
-
AWS — ECS Developer Guide
-
AWS — Service Connect