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 クラスター
-
コンテナインスタンスの状態: Draining と Deregistering
-
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 更新 — キャパシティプロバイダーが推奨インターフェースになりました。 AWS は起動タイプを直接指定するのではなくキャパシティプロバイダーを使用してタスクを起動することを推奨するようになりました。起動タイプは互換性検証用に、タスク定義の
requiresCompatibilitiesでのみ使用してください。キャパシティプロバイダーは、より優れたリソース制御、コンピュートタイプ間のよりスムーズな移行を提供し、新しい ECS Managed Instances オプションに必要です。
Fargate (サーバーレス)
サーバーレス、従量課金制のコンピュートエンジン。サーバーを管理したり、キャパシティを計画したり、ワークロードを分離したりする必要はなく、正確な CPU とメモリを選択するだけです。
最適な用途:
-
低い運用オーバーヘッドが必要な大規模ワークロード
-
時々バースト現象が発生する小規模ワークロード
-
小規模なワークロード
-
バッチワークロード
キャパシティプロバイダー:
-
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 イベントウィンドウ経由で週 1 回のメンテナンスウィンドウに設定可能)
-
Spot サポート (2025 年 12 月追加) — フォールトトレランスワークロードで最大 90% の割引について
capacityOptionType: spotを設定 -
タグ伝播 — タグはキャパシティプロバイダーからインスタンス、ENI、ボリュームなどに流れます
最適な用途: GPU/ML 推論、高ネットワークワークロード、キャパシティ予約ニーズ、特権ホストアクセスが必要な eBPF ベースの可観測性ツール — Fargate 以上が必要だが、Auto Scaling Group 自体を実行したくない何か。
管理オーバーヘッドプラス基盤となる 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 Gateway コスト注: NAT ゲートウェイは 1 時間ごとおよび処理されたデータの GB ごとに課金されます。HA の場合、利用可能性ゾーンごとに 1 つの NAT ゲートウェイを実行する必要があります — 小規模なワークロードでは高くなる可能性があります。
インターネットからのインバウンドトラフィック受信
パブリックサービスの場合、インターネットとアプリケーション間にスケーラブルな入力レイヤーを配置します。3 つの主なオプション:
Application Load Balancer (ALB) — OSI レイヤー 7
HTTP/HTTPS サービスと REST API に最適。
強み:
-
SSL/TLS ターミネーション — 証明書を管理し、SSL をアプリからオフロード
-
高度なルーティング — マイクロサービス用のホストベースおよびパスベースのルーティング
-
gRPC、WebSockets、HTTP/2 サポート
-
セキュリティ — HTTP デシンク軽減、AWS WAF 統合 (SQLi、XSS 保護)
Network Load Balancer (NLB) — OSI レイヤー 4
非 HTTP プロトコルまたはエンドツーエンド暗号化が必要な場合に最適。
強み:
-
エンドツーエンド暗号化 — パケット内容を読まずに L4 で動作
-
TLS ターミネーション — 必要に応じて TLS をオフロード
-
UDP サポート — およびその他の非 TCP プロトコル
Amazon API Gateway (HTTP API)
突然のバーストまたは低全体的トラフィック量を持つ HTTP アプリに最適。
料金モデル異なる: ALB/NLB はロードバランサーを利用可能に保つために毎時間料金が発生; API Gateway はリクエストごとに課金されます。
-
低トラフィック / スパイキートラフィック → API Gateway がより安い
-
高持続トラフィック → ALB/NLB はリクエストごとに安い
API Gateway はVPC リンクを介してプライベート VPC サブネットに接続し、AWS Cloud Map レコード経由で ECS Service Discovery で管理されているプライベート IP を発見します。クライアント認可、使用階層、リクエスト/レスポンス変換、エッジ/リージョン/プライベートエンドポイント、レスポンスキャッシングなどの機能も追加します。
VPC 内部から AWS サービスに ECS を接続する
ECS コンテナエージェントは ECS コントロールプレーンと通信する必要があります。ECR を使用している場合、ホストは ECR エンドポイントと S3 (イメージレイヤーが存在する場所) に到達する必要があります。
オプション 1: NAT Gateway
最も簡単なパス — ただし欠点があります:
-
きめ細かな宛先制御なし — すべての VPC アウトバウンドトラフィックを破壊することなく、NAT ゲートウェイバウンドトラフィックを特定の AWS サービスに制限することはできません。
-
GB ごとの料金処理 NAT データの — 大規模な 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 に同期し、内部タスク IP に解決する DNS ホスト名を保持します。
長所:
-
最低遅延 — トラフィックはコンテナ → コンテナで直接流れます
-
シンプルなアーキテクチャ、追加コンポーネントなし
欠点:
-
アプリケーションはリトライロジックを実装し、古い DNS レコード (TTL キャッシングは存在しなくなったコンテナの IP を返す可能性があります) をグレースフルに処理する必要があります
-
Service Connect ほどレジリエンスが高くない、または観測不可能
📝 Service Discovery がまだ勝つとき: CodeDeploy による Blue/Green デプロイメントを使用している場合、Service Connect は歴史的に互換性がありません (CodeDeploy
DeploymentControllerタイプはサポートされていません)。ネイティブ ECS Blue/Green は現在 Service Connect でサポートされていますが、デプロイメント制御互換性を確認してから選択してください。
3. 内部ロードバランサー
VPC 内部に完全にデプロイされた ALB または NLB。ServiceA はロードバランサーへの接続を開きます; ロードバランサーは ServiceB タスクへの接続を開きます。
長所:
-
接続の集中管理
-
自動ヘルスチェックは不良ターゲットを削除
-
アプリケーションはダウンストリームコンテナ数を追跡する必要はありません
欠点:
-
コスト — ロードバランサーには AZ ごとに冗長リソースが必要
-
軽減: パスベースのルーティング (例:
/api/user/*→ ユーザーサービス、/api/order/*→ 注文サービス) を使用して複数のサービス全体で 1 つの ALB を共有
4. Amazon VPC Lattice (モダンオプション)
マネージドアプリケーションネットワーキングサービス。ECS サービスを VPC Lattice ターゲットグループと関連付けると、ECS はタスクを IP ターゲットとして自動登録します。コード変更なしに、コンピュートサービス、VPC、アカウント全体のアプリを接続、監視、保護するのに便利です。
モニタリング
クラスターを立ち上げる前に、以下の質問に答える監視計画を構築します:
-
監視の目標は何ですか?
-
どのリソースを監視しますか?
-
どのくらいの頻度で?
-
どのツール?
-
誰が監視を実行しますか?
-
何か問題が起きたときに誰がページングされますか?
最小ベースラインメトリクス
-
CPU とメモリ予約 + 使用率クラスターレベル
-
CPU とメモリ使用率サービスレベル
利用可能なメトリクスは起動タイプによって異なります:
-
Fargate: CPU とメモリ使用率メトリクスはサービスごとに自動的に提供されます
-
EC2: EC2 インスタンス自体も監視する必要があります; クラスター/サービス/タスクレベルの予約および使用率メトリクスも利用可能です
ツーリングオプション
-
CloudWatch アラーム — しきい値ベースの警告; Fargate サービスに対するオートスケーリングも駆動できます
-
CloudWatch Logs — タスク定義で
awslogsログドライバーを設定してコンテナ stdout/stderr をキャプチャ -
CloudWatch Events / EventBridge — イベントをマッチングし、自動対応のためにターゲットにルーティング
-
Container Insights — 構造化 JSON パフォーマンスログイベントを使用してコンテナ化されたワークロードのパフォーマンスメトリクスとログを収集、集計、要約します; CloudWatch はクラスター/サービス/タスクレベルで集計メトリクスを作成します (Enhanced Observability モードがコンテナレベルの詳細を追加)
-
CloudTrail — API アクション をログ; CloudWatch Logs にシップしてリアルタイム監視
-
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 Logs または S3 にログインでき、CloudTrail は誰が接続したか、いつ接続したかを記録
ECS Exec はAWS Systems Manager Session Manager を接続に使用し、IAM ポリシーを認可に使用します。SSM エージェントバイナリはコンテナにバインドマウントされ、ECS/Fargate エージェントはアプリケーションと並行して SSM コアエージェントを起動します。
ECS クラスター
クラスターはタスクとサービスの論理的グループです。以下を含みます:
-
インフラストラクチャキャパシティプロバイダー
-
ネットワーク (VPC とサブネット)
-
オプションの名前空間 — Service Connect 用
-
監視オプション (例: Container Insights)
キャパシティプロバイダー — Fargate
Fargate を使用する場合、キャパシティを作成または管理しません。これら 2 つの事前定義されたプロバイダーのいずれかまたは両方をクラスターと関連付けます:
-
FARGATE -
FARGATE_SPOT
Spot タスクが回収されると、ECS は停止理由を記述する task state change イベントを EventBridge に送信します。
キャパシティプロバイダー — EC2
Auto Scaling Groups (ASG) を使用してクラスターに登録された EC2 インスタンスを管理します。ECS はマネージドスケーリング経由でスケールイン/スケールアウトを管理するか、自分で管理できます。
🔹 ベストプラクティス: キャパシティプロバイダー用に新しい、空の ASG を作成します。既に登録されたインスタンスを持つ既存の ASG を再利用すると、キャパシティプロバイダーとの登録ミスマッチが発生する可能性があります。
🔹 スケールイン時の EC2 の正常な終了のためのマネージドインスタンスドレイン (デフォルトでオン) を有効にします。
キャパシティプロバイダー戦略
2 つのパラメーターを使用してプロバイダー全体にタスクを配布:
-
base— 特定のプロバイダーで実行する必要がある最小タスク数。戦略内の 1 つのプロバイダーのみが基数を定義できます。 -
weight— 相対的なパーセンテージ分割。capacityProviderA=1およびcapacityProviderB=4の場合、A の 1 タスクはごとに B で 4 タスクが一致します。
例: 75% Fargate / 25% Fargate Spot → FARGATE で重み 3、FARGATE_SPOT で重み 1。
コンテナインスタンスの状態: Draining と Deregistering
これら 2 つの操作はよく混同されます。
ドレイニング
インスタンスを DRAINING に移行して、新しいタスクのスケジューリングを防止し、実行中のタスクを安全に削除します。システム更新、スケールイン、またはメンテナンス中に使用されます。
サービスの場合:
-
保留中のタスクは直ちに停止されます。スケジューラーはクラスターキャパシティが許す場合、置き換えを起動します。
-
実行中のタスクは
STOPPEDに移行されます。スケジューラーはデプロイメント設定に基づいてそれらを置き換えます:minimumHealthyPercent— 健全なタスク数の下限。desiredCount=4とminimumHealthyPercent=50%の場合、少なくとも 2 つのタスクが健全である必要があります。スケジューラーは、置き換えを起動する前に最大 2 つのタスクを停止できます。maximumPercent— 上限。desiredCount=4とmaximumPercent=200%の場合、置き換え中に同時に最大 8 つのタスクが実行できます。より速い blue/green スタイルの置き換えが可能です。
スタンドアロンタスク: 保留中および実行中のタスクは影響を受けません。完了するまで、または手動で停止するまで待つ必要があります。インスタンスは完了または再活性化まで DRAINING のまま保持されます。
ドレイニングインスタンスは、その状態を ACTIVE に戻すと 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 / オートスケーリングロール | スケジュール済みタスクと Application Auto Scaling に必要です。 |
タスクネットワークモード (EC2 起動タイプ)
タスク定義で定義されます。各モードにはトレードオフがあります。
awsvpc (推奨)
各タスクに EC2 インスタンスと同じネットワーク プロパティを付与 — 独自のプライベート IP を持つ ENI (デュアルスタックの場合は IPv6)。
-
きめ細かなセキュリティ — タスクごとのセキュリティグループ、VPC フローログなど。
-
より単純なネットワーク — ポート衝突なし; 同じタスク内のコンテナは
localhostを共有。 -
各タスクは 1 つの ENI のみを持つことができます。
host
コンテナネットワークは EC2 ホストに直接結合されます。コンテナはホストの IP とポートでリッスンします。
-
重大な欠点: ホストごとに 1 つのタスクインスタンスのみ (ポート衝突); ポート リマッピングなし。
-
推奨されていません。
bridge
ホストとコンテナ間の仮想ネットワークブリッジ、ポートマッピング (静的または動的)。
-
静的マッピング — ホストポート → コンテナポートを明示的にマッピング。
hostと同じホストごとに 1 つのインスタンスの制限。 -
動的マッピング — Docker はホストのランダムなエフェメラルポートを割り当てます。ホストごとに複数のインスタンスが可能になります。
-
欠点: 動的ポートはサービス間のセキュリティグループをロックダウンするのを難しくします (広いポート範囲を開く必要があります)。
| モード | ホストごとに複数のタスク? | タスクごと SG? | 最適な用途 |
awsvpc | ✅ | ✅ | デフォルト選択 |
host | ❌ | ❌ | ホストレベルネットワークが必要な稀なケース |
bridge (static) | ❌ | ❌ | レガシーまたは特定のポート必要 |
bridge (dynamic) | ✅ | ❌ | 複数インスタンス awsvpc が使用不可の場合 |
ストレージオプション
ECS はタスクのいくつかのボリュームタイプをサポートしています。正しい選択は永続性、共有、パフォーマンスニーズに依存します:
-
バインドマウント — ホストファイルシステムマウント; エフェメラル
-
Docker ボリューム — ホストでの Docker 管理
-
Amazon EFS — 共有、永続、マルチ AZ; 共有状態に最適で Fargate
-
Amazon FSx for Windows File Server — Windows コンテナ with SMB
-
Amazon EBS — ブロックストレージ、EC2 起動タイプ
-
エフェメラルストレージ — 一時的、タスク生存期間にスコープ
完全なパラメーター参照については、AWS タスク定義ドキュメントを参照してください。
タスクスケジューリングとプレースメント
ECS は柔軟なスケジューリングを提供: 長実行アプリ用サービススケジューラー、バッチ/単一実行ジョブ用スタンドアロンまたはスケジュール済みタスク。
プレースメント コンポーネント
-
タスクプレースメント戦略 — インスタンス選択 (および終了するタスク選択) アルゴリズム。例: ランダム、スプレッド、ビンパック。
-
タスクグループ — 関連タスクの論理グループ (例: すべての DB タスク)。
-
タスクプレースメント制約 — インスタンスがタスクをホストするために必ず満たす必要のあるルール。満たされていない制約はタスクを
PENDINGのままにします。
EC2 起動タイプ — プレースメントアルゴリズム
タスクを配置する場合、ECS:
-
CPU/GPU/メモリ/ポート要件を満たすインスタンスを識別
-
プレースメント制約によるフィルター
-
プレースメント戦略によるフィルター
-
最適なインスタンスを選択
デフォルト:
-
サービスの一部として実行されるタスク:
spreadattribute:ecs.availability-zone全体 -
スタンドアロンタスク: デフォルト制約なし
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 が (起動タイプまたはキャパシティプロバイダー戦略を使用して) キャパシティを見つけ、ライフサイクルを通じて移動します。マネージドスケーリングキャパシティプロバイダーを使用する場合、キャパシティ不足のタスクは即座に失敗するのではなく PROVISIONING のままです。
タスク起動時間の最適化
-
キャッシュイメージ + ビンパック — ECS エージェントのイメージプル動作を
prefer-cached(EC2 のみ) に設定し、binpack戦略を使用してタスクをより少ないインスタンスに統合します。大きなイメージを持つ Windows ワークロードに役立ちます。ENI トランキングを有効にして、インスタンスごとにより多くの同時awsvpcタスクをサポートします。 -
適切なネットワークモードを選択 —
awsvpcは ENI プロビジョニング遅延を追加します; タスクごとのセキュリティグループが不要な場合はbridgeの方が高速です。 -
起動ライフサイクルを監視 — Task metadata エンドポイントを使用して
ContainerStartTime→ readiness をキャプチャし、イメージサイズとブートストラップオーバーヘッドをトリム。 -
インスタンスのサイズを適切に調整 — CPU/メモリを実際の予約に合わせます (例: 0.5 vCPU/2 GB ごとに 4 つのタスクをホストする
m5.largeで 2 vCPU/8 GB)。
EventBridge Scheduler
サーバーレススケジューラー — EventBridge バス/ルールとは独立して動作し、より広い API ターゲットをサポート。以下をサポート:
-
レートベーススケジュール (例: 5 分ごと)
-
Cron ベーススケジュール
-
1 回限りスケジュール
ECS サービス
サービスは同時に目的のタスク数を実行および維持します。タスクが失敗した場合、サービススケジューラーが置き換えを起動します。
スケジューリング戦略
| 戦略 | 動作 | Fargate? |
REPLICA | クラスター全体で目的のタスク数を維持 (デフォルト: AZ 全体にスプレッド)。 | ✅ |
DAEMON | プレースメント制約を満たすアクティブなコンテナインスタンスごとに正確に 1 つのタスクを実行。 | ❌ サポートなし |
REPLICA 戦略
-
desiredCountを定義 -
タスクはロードバランサーの背後に配置できます
-
戦略/制約でプレースメントをカスタマイズ
-
コンテナヘルスチェックまたは LB ターゲットグループヘルスチェック経由のヘルスモニタリング
-
障害スロットリング — タスクが繰り返し
RUNNINGに入ることに失敗する場合、スケジューラーは起動試行を遅くし、サービスイベントを発行してリソース浪費を防止
ヒント: REPLICA で AZ Rebalancing を使用 して AZ 全体でタスクを均等に分散。
不健全タスク置き換えフロー:
-
サービスはタスクに不健全というマークをつける
-
スケジューラーが置き換えを開始
-
置き換えが
HEALTHYの場合 → 元の不健全なタスクが停止 -
置き換えが
UNHEALTHYの場合 → スケジューラーはdesiredCountの近くに合計を保つために不健全なタスクのいずれかをランダムに停止 -
maximumPercentが最初のブロックをブロックしている場合、スケジューラーは容量を解放するために 1 つの不健全なタスクを停止し、その後置き換えを起動 -
すべての不健全なタスクが置き換えられるまで繰り返す; 過剰がある場合、健全なタスクはランダムに
desiredCountまで停止
DAEMON 戦略
-
アクティブなコンテナインスタンスごとに正確に 1 つのタスク
-
ECS は daemon タスク用に CPU、メモリ、ネットワークインターフェースを予約
-
Daemon タスクはプライオリティ — クラスターが daemon + replica サービスを混在させる場合、最初に起動し、最後に停止
-
理想的にはログ/監視エージェントで、すべてのホストで実行する必要があります
利用可能性ゾーンのリバランシング
サービスが定常状態に達した後、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 を5s、threshold を2 に設定 — 合計~10s。メジャーデプロイメント高速化。
接続ドレイニングの最適化
クライアントは再利用のために接続を開いたままにします; ロードバランサーはターゲットを停止する前にクライアントが接続をクローズしたかどうかをチェック。
-
deregistration_delay.timeout_seconds— ロードバランサーがターゲットをUNUSEDに強制する前に待つ時間。デフォルト: 300s。 -
1 秒未満のレスポンス時間を持つサービスの場合、これを5s に設定。
SIGTERM の応答性
-
ECS_CONTAINER_STOP_TIMEOUT—SIGTERMとSIGKILL間の時間。デフォルト: 30s。 -
高速シャットダウンアプリの場合、2s に低下させ、コードで
SIGTERMをトラップ:
process.on('SIGTERM', function() {
server.close();
});
これは新しいリクエストを受け入れるのを停止し、フライト中のリクエストを完了し、クリーンに終了 — しばしばストップタイムアウトをはるかに下回り、SIGKILL を回避。
🆕 2025 年 12 月 — Fargate での カスタム停止信号。 Fargate は現在 OCI 準拠コンテナイメージから
STOPSIGNALを読み取り、タスク終了中に適切な信号 (SIGQUIT、SIGINTなど) を送信します。これは常にSIGTERMを送信するのではなく、アプリケーション (例: Nginx グレースフルシャットダウン) が非デフォルト信号を使用します。追加コストなしですべてのリージョンで利用可能。
オートスケーリング
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 でステータスをクエリ。外部サービスがタスクライフサイクルを追跡する場合に便利 — 例: ゲームサーバーコントローラーがユーザーのログイン時にタスクをマーク、ログアウト時にクリア。
内部エージェントエンドポイントから保護を設定し、外部コントローラーから削除の両方を組み合わせることができます。
クイックリファレンスチートシート
起動タイプの決定
-
最低の運用オーバーヘッドが必要? → 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 Mode (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 リージョンで利用可能
-
コンソール、CLI、SDK、CloudFormation、CDK、Terraform 経由で管理可能
ECS Managed Instances (2025 年 9 月ローンチ、2025 年 10 月 GA、Spot サポート 2025 年 12 月)
上記のキャパシティオプションセクションで取り上げられています。TL;DR: インスタンスプロビジョニング、14 日ごとのパッチング、継続的なタスクプレースメント最適化を処理するフルマネージド EC2 キャパシティプロバイダー — Fargate のハンズオフ感と EC2 の柔軟性 (GPU、カスタムインスタンスタイプなど) を組み合わせます。
Fargate 上のカスタムコンテナ停止信号 (2025 年 12 月)
Fargate は現在 OCI 準拠イメージから STOPSIGNAL を読み取り、常に SIGTERM を送信するのではなく、タスク終了中に適切な信号 (SIGQUIT、SIGINT など) を送信します。アプリ (例: 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 サービスは現在、IP ターゲットとしてVPC Lattice ターゲットグループと関連付けることができます。ECS は起動時にターゲットグループにタスクを自動登録し、クロス VPC、クロスアカウントアプリケーションネットワーキングを組み込み可観測性とセキュリティで有効にします — コード変更なし。
Service Connect でのネイティブ Blue/Green
2025 年初め、ECS ネイティブ Blue/Green デプロイメントは、ロードバランサーと並行して Service Connect サポートを追加しました。Service Discovery を選択する理由の 1 つであった CodeDeploy DeploymentController の非互換性を削除 (歴史的に)。
キャパシティプロバイダーが起動タイプより推奨
AWS は現在、新しいワークロードのタスク起動の主要なメカニズムとしてキャパシティプロバイダーを使用することを明示的に推奨しています。タスク定義の requiresCompatibilities フィールドで互換性検証用にのみ起動タイプを使用してください。キャパシティプロバイダーはより優れたリソース制御を提供し、コンピュートタイプ間のシームレスな移行を可能にし、ECS Managed Instances に必要です。
Copilot CLI サンセット
AWS Copilot CLI は 2026 年 6 月 12 日にサポート終了に達します。 GitHub オープンソースプロジェクトとして利用可能なままですが、AWS から新しい機能またはセキュリティ更新を受け取ることはありません。ECS Express Mode は今後の簡素化ストーリーの一部として配置されています。
まとめ
ECS は AWS でコンテナを実行するための深く統合された方法を提供 — クラスター、タスク定義、タスク、サービスはスケーラブルで、回復力があり、観測可能なコンテナワークロードを配信するために構成されます。大きなレバレッジポイント:
-
起動タイプを直接使用するのではなく、キャパシティプロバイダーを使用、新しいワークロード
-
適切なキャパシティオプションを選択 — 低運用オーバーヘッド向け Fargate、EC2 柔軟性向け ECS Managed Instances (ASG 管理なし)、完全制御向け自己管理 EC2
-
シンプルな Web アプリと API 向け ECS Express Mode を試す — 3 つの入力、本番対応スタック
-
特定の理由がない限り
awsvpcネットワーク を使用 -
サービス間通信に Service Connect を優先
-
ヘルスチェック、登録解除遅延、
SIGTERM処理をチューニング 高速デプロイメント用 -
キャパシティにリニアに応答するメトリクスでターゲットトラッキングオートスケーリングを使用
-
プレースメント戦略と AZ Rebalancing でスプレッド レジリエンス用
-
スケールイン保護で長実行タスクを保護 スケールインから
参考資料
-
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