ECS サービスについて理解しよう！

Posted at 2025-10-01

はじめに

本記事では AWS が提供するコンテナサービス「Amazon Elastic Container Service（ECS）」のコアコンポーネントであるサービスについて説明していきたいと思います。
初心者向けの内容となっていますが、ECS の全体像について理解しきれていないという方は先に以下の記事をご一読いただければと思います。

また、同じく ECS のコアコンポーネントであるクラスターについて理解したいという方は以下の記事をご一読いただければと思います。

本記事のゴール

ECS サービスについて設定可能なオプション群を理解し、ワークロードに適したサービスを作成できるようになる。

サービスとは（おさらい）

サービスは、「タスク定義をもとに、指定した数のタスク（コンテナアプリケーション）を動かし続ける仕組み」です。
サービスはそのタスクを監視し、停止したら自動で新しいタスクを起動するという「管理者」の役割を果たします。

設定可能なオプションとその選び方

サービス作成時に設定可能なオプションについて説明していきます。

サービスの詳細

ECS サービスを作成する際、最初に設定する基本的な項目があります。
これらは後から変更が困難または不可能なものも含まれるため、作成時に適切に設定することが重要です。

タスク定義ファミリー

サービスが使用するタスク定義ファミリーを選択します。
タスク定義ファミリーは、アプリケーションの設計図となるタスク定義のグループ名です。

タスク定義のリビジョン

選択したタスク定義ファミリーの中から、使用する具体的なリビジョンを指定します。

環境別の実装パターン

本項目の設定に関して、環境ごとにまとめると以下のようになります。

環境	推奨	理由
本番	特定リビジョン	予期しない変更を完全に防ぎ、確実なロールバックを保証
ステージング	特定リビジョン	問題発生時の原因特定を容易にし、本番同等のデプロイプロセスの検証を保証
開発	リビジョン指定なし（最新を自動使用）	開発速度の最大化とコミット即時反映を優先

サービス名

サービス名は作成後に変更することができないため、慎重に決める必要があります。

制約

文字数：最大 255 文字
有効な文字： a ~ z , A ~ Z , 0 ~ 9 , ハイフン（-） , アンダースコア（_）
一意制約

環境

サービスが実行される環境とコンピューティングリソースを設定します。
この設定により、タスクがどのようなインフラストラクチャで実行されるかが決まります。

既存のクラスター

サービスを作成するクラスターを選択します。

コンピューティング設定

タスクを実行するインフラストラクチャの管理方法を設定します。

コンピューティングオプション

コンピューティングタイプ間でタスクを分散させるには、適切なコンピューティングオプションを使用する必要があります。
タスクを分散するためのコンピューティングオプションには以下の 2 つの選択肢があります。

キャパシティプロバイダー戦略
起動タイプ

キャパシティプロバイダー戦略

キャパシティープロバイダー戦略により、Amazon ECS がタスクを 1 つまたは複数のキャパシティプロバイダーに分散させます。
クラスターのデフォルトキャパシティープロバイダー戦略を選択するか、カスタムオプションを選択して別の戦略を設定することが可能です。

キャパシティプロバイダーの設定項目

キャパシティプロバイダー：FARGATE , FARGATE_SPOT など
ベース：キャパシティプロバイダーで実行するタスクの最小数
ウェイト：キャパシティプロバイダーで実行するタスクの分散比率

起動タイプ

起動タイプにより、Amazon ECS は Fargate またはクラスターに登録された EC2 インスタンスのいずれかでタスクを直接起動します。

起動タイプの選択肢

FARGATE
EC2
EXTERNAL

※ EC2 , EXTERNAL を指定する場合、クラスターへの登録が必要です。

プラットフォームバージョン

Fargate または Fargate Spot キャパシティープロバイダー、または Fargate 起動タイプのいずれかを使用する場合は、プラットフォームバージョンも選択する必要があります。
プラットフォームバージョンによって、使用するランタイム環境やタスクに使用できる機能が決まります。

推奨設定

本項目の設定に関して、基本的には最新のプラットフォームバージョンを使用することが推奨されます。

設定値	推奨度	適用場面
LATEST	◎	通常の本番/開発環境
特定バージョン	△	互換性を重視、特定機能に依存

デプロイ設定

サービスの実行方法とデプロイメント時の動作について設定します。

スケジューリング戦略

スケジューラーがクラスターにタスクを配置する方法を決定します。
利用できるサービススケジューラ戦略としては以下の 2 つの選択肢があります。

レプリカ：クラスター全体で必要な数のタスクを配置して維持
デーモン：各コンテナインスタンスに、タスクのコピーを 1 つ配置して維持

※ Fargate タスクはデーモンスケジュール戦略をサポートしていません。

必要なタスク

起動するタスクの数を指定します。

ヘルスチェックの猶予期間

タスクが最初に開始された後で、ヘルスチェックの結果を無視する期間 (秒単位)。
ヘルスチェックの猶予期間を指定しない場合は、デフォルト値の 0 が使用されます。

デプロイオプション

サービスにタスクがデプロイされる際の動作について設定します。

デプロイコントローラーのタイプ

デプロイコントローラーには以下の 3 つの選択肢があります。

ECS
CODE_DEPLOY
EXTERNAL

※ 本記事は ECS デプロイコントローラーを利用する前提のものとなっています。

デプロイ戦略

新しいバージョンのサービスの提供方法を指定します。
以下 2 つの選択肢があります。

ローリングアップデート
ブルー/グリーン

ローリングアップデート

以前のバージョンを実行しているタスクを 1 つずつ新しいタスクに置き換えます。

特徴

タスクを1つずつ順次置き換えるため、サービス全体がオフラインになることはない
同時に2つの完全な環境を実行する必要がないため、リソースコストを抑制できる
デプロイ中もサービスが継続稼働するが、タスクの置き換えに時間がかかる
ロードバランサーの設定が不要でシンプルなデプロイが可能
ロールバック時も段階的な置き換えが必要なため、復旧に数分要する

設定項目

デプロイ戦略としてローリングアップデートを選択した場合に設定する必要がある項目は以下の 2 つです。

最小実行タスク %：デプロイ中に RUNNING 状態を維持するタスク数の下限
最大実行タスク %：デプロイ中に RUNNING または PENDING 状態を許可するタスク数の上限

ブルー/グリーン

現在のバージョン (ブルー) と新しいバージョン (グリーン) を実行する 2 つの別々の環境を作成します。

特徴

本番トラフィックを流す前に新しいバージョンの動作確認が可能
トラフィックの切り替えが瞬時に行われるため、デプロイ時間が短い
問題発生時は即座に元の環境にロールバック可能
デプロイ中は2つの環境を同時実行するため、リソース使用量が倍増する
Application Load Balancer または Network Load Balancer の設定が必要

設定項目

デプロイ戦略としてブルー/グリーンを選択した場合に設定する必要がある項目は以下の 1 つです。

ベイク時間：本番トラフィックがグリーンに切り替わった後、ブルーとグリーンの両環境を同時実行する時間

デプロイ戦略比較

前述の特徴を踏まえて 2 つのデプロイ戦略を比較すると以下のようになります。

比較項目	ローリングアップデート	ブルー/グリーン
ダウンタイム	なし	なし
デプロイ時間	長い	短い
ロールバック	数分	数秒
デプロイ前検証	△	〇
リソースコスト	低い	高い
設定の簡単さ	〇	△
適用条件	制限なし	ALB or NLB が必要

デプロイライフサイクルフック

ブルー/グリーンデプロイの特定の段階で実行され、デプロイの正常性と機能を検証する Lambda 関数を設定します。

ライフサイクルステージ

ステージ	タイミング	用途
PRE_SCALE_UP	グリーン環境の開始前	デプロイ前の検証
POST_SCALE_UP	グリーン環境の開始後、トラフィック移行前	基本的なヘルスチェック
TEST_TRAFFIC_SHIFT	テストトラフィックのルーティング開始時	機能テスト
POST_TEST_TRAFFIC_SHIFT	テストトラフィックのルーティング後	パフォーマンス検証
PRODUCTION_TRAFFIC_SHIFT	本番トラフィックのシフト開始時	最終検証
POST_PRODUCTION_TRAFFIC_SHIFT	本番トラフィックのシフト後	デプロイ後の検証

Lambda 関数の要件

割り当てる Lambda 関数は次の条件を満たす必要があります。

成功または失敗のレスポンスを返す
Lambda タイムアウト期間 (最大 15 分) 内に完了する
テストに必要なリソースにアクセスするための適切な IAM アクセス許可がある

※ ライフサイクルフックが失敗すると、デプロイは自動的にブルーのデプロイにロールバックされます。

デプロイ不具合の検出

Amazon ECS でデプロイの不具合を検出する方法と、不具合が発生した場合のアクションを指定します。

Amazon ECS デプロイサーキットブレーカー

サーキットブレーカーは、タスクが正常に起動しない場合にデプロイを失敗に設定します。
基本的には有効にすることを強く推奨し、デバッグ時など失敗を詳しく調べたい場合のみ無効にします。

CloudWatch アラームを使用

CloudWatch でエラーや異常を検知した時に、デプロイを自動で止める機能です。
本番環境で詳細な監視が必要な場合に有効、開発環境やシンプルな構成では無効にすることが推奨されます。

失敗時のロールバック

デプロイが失敗した時に、前の安定していた状態に自動で戻してくれる機能です。
本番環境やステージング環境では有効にすることを強く推奨します。

ネットワーキング

サービスのネットワーク設定は、アプリケーションのアクセス性とセキュリティに直結します。

VPC 設定

Amazon ECS リソースに使用する VPC を選択します。

サブネット

タスクスケジューラが配置するために考慮する VPC 内のサブネットを選択します。

サブネットタイプ	アクセス経路	用途
パブリック	インタネットゲートウェイ経由	高帯域幅または低遅延を必要とするパブリックアプリケーション
プライベート	NAT ゲートウェイ経由	外部からの直接アクセスからコンテナを保護するシナリオ

セキュリティグループ

既存のセキュリティグループを選択するか、新しいセキュリティグループを作成します。

推奨設定

セキュリティグループの設定に関する推奨事項は以下の通りです。
通常のセキュリティグループと同様の考慮が必要となります。

最小権限の原則を適用
必要なポートのみ開放
送信元を具体的に指定

パブリック IP

タスクの Elastic Network Interface (ENI) にパブリック IP を自動的に割り当てるかどうかを選択します。

サービス間通信方法の比較

Amazon ECS でサービス間通信を行う方法として、Service Connect、サービス検出、VPC Lattice の3つの主要なアプローチがあります。

Service Connect

Amazon ECS Service Connect では、Amazon ECS 設定としてサービス間通信を管理できます。
従来の IP アドレスやロードバランサーを使った接続ではなく、短い名前でサービス同士を接続できる機能です。

Service Connect の設定

Service Connect の設定として以下の 2 つのモードが選択肢として提供されています。

クライアントモード：名前空間内の他のサービスに接続します
クライアントサーバーモード：このサービスのエンドポイントを提供し、名前空間内の他のサービスに接続します

名前空間

Service Connect で使用する AWS Cloud Map 名前空間を指定します。
名前空間は、相互に対話する Amazon ECS タスクの論理グループとして使用されます。

詳細

Service Connect の使用に関するログ収集の設定を行います。
適切なトラブルシューティングのために、AWS Fargate で実行されるタスクにはログ収集を使用することが推奨されます。

ログ収集の使用

Service Connect プロキシのログをどこに送信するかを設定します。
デフォルト設定を使用して、コンテナログを各種ログ記録サービスに送信するように Envoy サイドカーを設定できます。

ログ記録先の選択

Service Connect では、以下のログ記録先から選択できます。

ログ記録先	適用場面
Amazon CloudWatch	標準的な監視・分析
Splunk	既存の Splunk 環境がある場合
Firehose（AWS FireLens 経由）	データ変換・配信が必要
Kinesis Stream（AWS FireLens 経由）	リアルタイム処理が必要
OpenSearch（AWS FireLens 経由）	検索・分析が重要
S3（AWS FireLens 経由）	長期保存・アーカイブが必要
カスタム送信先（AWS FireLens 経由）	特殊な要件がある場合

サービス検出

ECS サービス検出では、AWS Cloud Map を使用してサービスの HTTP および DNS 名前空間を管理できます。
従来の IP アドレスやポート番号を直接指定する方法ではなく、ECS サービスを DNS 名で相互接続する機能です。

名前空間を設定

サービス検出で使用する AWS Cloud Map 名前空間を指定します。
名前空間は、同じドメイン名 (example.com など) を共有するサービス検出サービスの論理グループです。

サービス検出サービスを設定

名前空間内に存在し、名前空間のサービス名および DNS 設定から構成されます。

Amazon ECS タスク状態の伝達

有効にすると、AWS ECS はタスク状態を Route 53 に伝え、異常なタスクを DNS から削除するためにかかる時間を減らします。

VPC Lattice

Amazon VPC Lattice は、コードを変更することなく、AWS コンピューティングサービス、VPC、アカウント全体で構築されたアプリケーションを観察、保護、モニタリングするためのマネージドアプリケーションネットワーキングサービスです。

インフラストラクチャロール

Amazon ECS 用 VPC Lattice は Amazon ECS インフラストラクチャロールを使用して、Amazon ECS がユーザーに代わってクラスター内のリソースを管理できるようにします。

VPC

VPC Lattice リソースの VPC を選択します。
Fargate を利用するサービスと同じ VPC である必要があります。

ターゲットグループ

VPC Lattice は、コンピューティングリソースの集まりであるターゲットグループを使用します。
ECS サービスを VPC Lattice ターゲットグループに関連付けると、その Amazon ECS サービスを VPC Lattice のターゲットとして使用できます。

ターゲットグループの設定項目

ターゲットグループ名
ポート名
プロトコル
ポート

アーキテクチャ・要件別推奨設定

Service Connect

アーキテクチャ	推奨	理由
マイクロサービス構成	◎	サービス間通信を大幅に簡素化
複数サービス連携	○	統一された名前空間で管理が容易
単一サービス構成	×	サービス間通信がないため不要
外部サービス中心	△	Service Connect 対象外のサービスが多い場合は不要

サービス検出

アーキテクチャ	推奨	理由
マイクロサービス構成	◎	サービス間通信を DNS 名で簡素化
複数サービス連携	○	サービス間の依存関係を明確化
単一サービス構成	×	サービス間通信がないため不要
ロードバランサー使用	△	LB 経由のアクセスが中心の場合は不要

VPC Lattice

要件	推奨	理由
クロスアカウント接続	◎	アカウント間の接続を簡素化
異なる VPC 間の接続	◎	VPC 間の通信を統一的に管理
複数コンピューティングサービスが混在	〇	ECS、Lambda、EC2 を統一的に扱える
単一 VPC 内の通信のみ	×	Service Connect やサービス検出で十分

選択の指針

Service Connect

運用の簡素化を重視
標準化された監視・メトリクスが必要
同一クラスター・名前空間内での通信要件
アプリケーション側の複雑性を避けたい

サービス検出

最低レイテンシが重要
既存のアプリケーションの変更を最小限に抑えたい
独自の障害処理ロジックを実装済み
host ネットワークモードを使用している

VPC Lattice

複数の VPC やアカウント間で通信が必要
ECS、Lambda、EC2 など複数のコンピューティングサービスを統一的に管理したい
統合されたセキュリティポリシーとモニタリングが必要
クロスアカウント接続を簡素化したい

ロードバランシング

ECS サービスは、オプションで Elastic Load Balancing を使用して、サービスのタスク間でトラフィックを均等に分散するよう設定できます。

VPC

ロードバランシングリソースの VPC を選択します。
awsvpc ネットワークモードを使用するサービスと同じ VPC である必要があります。

ロードバランサーの種類

ECS サービスでは、Application Load Balancer、Network Load Balancer、および Gateway Load Balancer がサポートされています。
使用するロードバランサーの種類は、アプリケーションの要件によって異なります。

ロードバランサーのタイプ	要件
Application Load Balancer	HTTP/HTTPS（レイヤー7）トラフィックをルーティング
Network Load Balancer	TCP または UDP（レイヤー4）トラフィックをルーティング
Gateway Load Balancer	TCP または UDP（レイヤー4）トラフィックをルーティングファイアウォール、侵入検知および防止システムなどの仮想アプライアンスを使用

コンテナ

受信トラフィックのロードバランス先となるコンテナとポートを選択します。

リスナー

ロードバランサーが接続リクエストをリッスンするポートとプロトコルを指定します。

ターゲットグループ

ロードバランサーが、サービス内のタスクへのルートリクエストに使用するターゲットグループを、新規に作成するか、既存のものから選択するかを指定します。

設定すべきかどうか？

本項目の設定に関して、アプリケーションごとにまとめると以下のようになります。

アプリケーション	推奨	理由
外部公開 Web アプリケーション	◎	トラフィック分散と高可用性の確保が必要
マイクロサービス（内部通信のみ）	×	Service Connect やサービス検出で十分
高トラフィック API	◎	負荷分散とスケーラビリティが必要
バッチ処理	×	ロードバランサー不要

サービスの自動スケーリング

ECS サービスの自動スケーリングは、サービスで必要なタスク数を自動的に増減する機能です。
Application Auto Scaling サービスを活用してこの機能を提供します。

タスクの最小数

Service Auto Scaling による調整可能な下限値を指定します。

タスクの最大数

Service Auto Scaling による調整可能な上限値を指定します。

スケーリングポリシータイプ

ECS サービスで必要なタスク数を自動的に増減させる方法を指定します。
以下の 4 つのスケーリングポリシータイプをサポートしています。

ターゲット追跡
ステップスケーリング
スケジュールスケーリング
予測スケーリング

ポリシータイプ	説明	適用場面
ターゲット追跡	特定のメトリクスのターゲット値を維持	一般的なアプリケーション
ステップスケーリング	しきい値に基づいた段階的なスケーリング	急激な負荷変動への対応
スケジュールスケーリング	日付と時刻に基づいたスケーリング	予測可能なトラフィックパターン
予測スケーリング	履歴パターンを使用した予測的なスケーリング	日次・週次等のパターンがある場合

設定すべきかどうか？

本項目の設定に関して、ワークロードごとにまとめると以下のようになります。

ワークロード	推奨ポリシータイプ	理由
変動するトラフィック	ターゲット追跡	最も簡単で効果的
急激な負荷変動	ステップスケーリング	迅速な対応が可能
予測可能なパターン	スケジュールスケーリング	事前にリソースを確保
規則的な日次・週次パターン	予測スケーリング	自動的にパターンを学習
安定した低トラフィック	設定不要	固定タスク数で十分

ボリューム

タスク内のコンテナ用に追加のストレージを提供するデータボリュームを設定します。
デプロイ時に設定可能なボリュームを含むタスク定義が指定されている場合のデプロイ時にのみ設定できます。

まとめ

環境別の設定方針
- 開発：最新リビジョンを自動使用、開発速度を優先
- ステージング：本番相当の構成で検証、コストバランスを考慮
- 本番：特定リビジョン指定、ロールバック有効化、詳細な監視設定
ワークロード特性に応じた設定
- デプロイ戦略：ダウンタイムの許容度とリソースコストのバランス
- サービス間通信：アーキテクチャの複雑さと管理の容易さ
- 自動スケーリング：トラフィックパターンの予測可能性

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up