# Amazon ECS の AWS Fargate 用のアーキテクト
AWS Fargate Fargate はAmazon ECSで使用できるテクノロジーであり、サーバーやAmazon EC2インスタンスの クラスターを管理することなく[コンテナ](https://aws.amazon.com/containers/)を実行できます。AWS Fargate を使用すると、コンテナを実行するために仮想マシンのクラスターをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。
Fargate を使用してタスクやサービスを実行する場合、アプリケーションをコンテナにパッケージ化し、CPU とメモリ要件を指定して、ネットワークと IAM ポリシーを定義して、アプリケーションを起動します。各Fargate タスクは、独自の分離境界を持ち、基盤となるカーネル、CPU リソース、メモリリソース、Elastic Network Interface を別のタスクと共有しません。Fargate のタスク定義を構成するには、`requiresCompatibilities` タスク定義パラメータを `FARGATE` に設定します。詳細については、「[Capacity](task_definition_parameters.md#requires_compatibilities)」を参照してください。
Fargate は、Amazon Linux 2 (プラットフォームバージョン 1.3.0)、Bottlerocket オペレーティングシステム (プラットフォームバージョン 1.4.0)、および Microsoft Windows 2019 Server Full Edition および Core Edition 用のプラットフォームバージョンを提供しています。特に指定がない限り、この情報はすべての Fargate プラットフォームに適用されます。
Fargate で Linux コンテナをサポートするリージョンの情報については、「[AWS Fargate 上の Linux コンテナ](AWS_Fargate-Regions.md#linux-regions)」を参照してください。
Fargate で Windows コンテナをサポートするリージョンの情報については、「[AWS Fargate 上の Windows コンテナ](AWS_Fargate-Regions.md#windows-regions)」を参照してください。
## チュートリアル
コンソールの使用開始方法については、以下を参照してください。
+ [Fargate 用の Amazon ECS Linux タスクを作成する方法について説明します。](getting-started-fargate.md)
+ [Fargate 用の Amazon ECS Windows タスクを作成する方法について説明します。](Windows_fargate-getting_started.md)
AWS CLI の使用開始方法については、以下を参照してください。
+ [AWS CLI を使用して、Fargate 用の Amazon ECS Linux タスクを作成する](ECS_AWSCLI_Fargate.md)
+ [AWS CLI を使用して、Fargate 用の Amazon ECS Windows タスクを作成する](ECS_AWSCLI_Fargate_windows.md)
## キャパシティープロバイダー
以下のキャパシティプロバイダーが利用可能です。
+ Fargate
+ Fargate Spot - 割り込み許容のある Amazon ECS タスクを、AWS Fargate 料金と比較して割引料金で実行します。Fargate Spot は、予備のコンピュートキャパシティーでタスクを実行します。AWS がキャパシティーを戻す必要がある場合、タスクは中断され、2 分間の警告が表示されます。詳細については、「[Fargate 用の Amazon ECS クラスター](fargate-capacity-providers.md)」を参照してください。
## タスク定義
Fargate タスクは、利用可能な Amazon ECS タスク定義パラメータのすべてをサポートするわけではありません。一部のパラメータはサポートされていません。また、Fargate タスクでは動作が異なるパラメータがあります。詳細については、「[タスク CPU とメモリ](fargate-tasks-services.md#fargate-tasks-size)」を参照してください。
## プラットフォームのバージョン
AWS Fargate プラットフォームのバージョンを使って、Fargate タスクインフラストラクチャの特定のランタイム環境を参照できます。これは、カーネルとコンテナのランタイムバージョンの組み合わせです。同一のタスクを多数管理するためのタスク実行時、またはそのためのサービス作成時には、プラットフォームバージョンを選択します。
ランタイム環境の進化に合わせて、新しいプラットフォームバージョンがリリースされます。例えば、カーネルやオペレーティングシステムの更新、新機能の追加、バグ修正、セキュリティの更新があった場合が当てはまります。Fargate プラットフォームのバージョンは、新しいプラットフォームバージョンのリビジョンを行うことで更新されます。各タスクは、そのライフサイクルを通じて、単一のプラットフォームバージョンのリビジョンで実行されます。最新のプラットフォームバージョンのリビジョンを使用する場合は、新たにタスクを開始する必要があります。Fargate で実行される新しいタスクは、常にプラットフォームバージョンの最新リビジョンで実行されます。これにより、タスクは必ず、安全でパッチ適用済みのインフラストラクチャで開始されることが保証されます。
既存のプラットフォームのバージョンに影響を与えるセキュリティ上の問題が見つかった場合、AWS は、そのプラットフォームバージョンのパッチ済みリビジョンを新たに作成します。また、脆弱性のあるリビジョンで実行しているタスクは廃止されます。場合によっては、Fargate で使用しているタスクについて、廃止の予定が通知されることがあります。詳細については、「[AWS Fargate on Amazon ECS のタスクの廃止とメンテナンス](task-maintenance.md)」を参照してください。
詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
## サービスの負荷分散
AWS Fargate の Amazon ECS サービスは、オプションで Elastic Load Balancing を使用して、サービスのタスク間でトラフィックを均等に分散するように設定できます。
AWS Fargate の Amazon ECS サービスでは、Application Load Balancer、Network Load Balancer、および Gateway Load Balancer のロードバランサータイプがサポートされています。アプリケーションロードバランサーは、HTTP/HTTPS (またはレイヤー 7) トラフィックをルーティングするために使用されます。ネットワークロードバランサーは、TCP または UDP (またはレイヤー 4)トラフィックをルーティングするために使用されます。詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](service-load-balancing.md)」を参照してください。
また、このようなサービスのターゲットグループを作成する場合は、ターゲットタイプとして `instance` ではなく、`ip` を選択する必要があります。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2インスタンスではなく、Elastic Network Interface に関連付けられているためです。詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](service-load-balancing.md)」を参照してください。
Network Load Balancer を使用して AWS Fargate タスクの Amazon ECS に UDP トラフィックをルーティングするには、プラットフォームバージョン 1.4 移行を使用する場合にのみサポートされます。
## 使用状況メトリクス
CloudWatch 使用状況メトリクスを使用して、アカウントのリソースの使用状況を把握できます。これらのメトリクスを使用して、CloudWatch グラフやダッシュボードで現在のサービスの使用状況を可視化できます。
AWS Fargate 使用状況メトリクスは、AWS のサービスクォータに対応しています。使用量がサービスクォータに近づいたときに警告するアラームを設定することもできます。AWS Fargate のサービスクォータに関する詳細については、「*Amazon Web Services 全般のリファレンス*」の「[Amazon ECS のエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html)」を参照してください。
AWS Fargate 使用状況メトリクスの詳細については、「[AWS Fargate 使用状況メトリクス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-fargate-usage.html)」を参照してください。
# Fargate をどのような場合に使用するかについての Amazon ECS セキュリティ上の考慮事項
タスクの強力な分離を求めているお客様には、Fargate を使用することをお勧めします。Fargate はハードウェア仮想化環境で各タスクを実行します。これにより、これらのコンテナ化されたワークロードがネットワークインターフェイス、Fargate の一時ストレージ、CPU、またはメモリを他のタスクと共有しないことが保証されます。詳細については、「[AWS Fargate のセキュリティの概要](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf)」をご参照ください。
# Amazon ECS の Fargate セキュリティのベストプラクティス
AWS Fargate を使用する際には、次のベストプラクティスを考慮することをお勧めします。その他のガイダンスについては、「[AWS Fargate のセキュリティ概要](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf)」を参照してください。
## AWS KMS を使用して Fargate のエフェメラルストレージを暗号化する
エフェメラルストレージは、 AWS KMS または独自のカスタマーマネージドキーで暗号化する必要があります。バージョン `1.4.0` 以降のプラットフォームを使用していて、Fargate でホストされているタスクの場合は、最低 20 GiB のエフェメラルストレージを受け取ります。詳細については、「[カスタマーマネージドキー (CMK)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html)」を参照してください。エフェメラルストレージの総量は、タスク定義で `ephemeralStorage` パラメータを指定することによって、最大 200 GiB まで増やすことができます。2020 年 5 月 28 日以降に起動されたこのようなタスクでは、エフェメラルストレージは、Fargate によって管理される暗号化キーを使用して、AES-256 暗号化アルゴリズムによって暗号化されます。
詳細については、「[Amazon ECS タスクのストレージオプション](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html)」を参照してください。
**例: Fargate プラットフォーム バージョン 1.4.0 で、エフェメラルストレージの暗号化を使用してタスクを起動する**
次のコマンドは、Fargate プラットフォームバージョン 1.4 でタスクを起動します。このタスクは Amazon ECS クラスターの一部として起動されるため、自動的に暗号化された 20 GiB のエフェメラルストレージが使用されます。
```
aws ecs run-task --cluster clustername \
--task-definition taskdefinition:version \
--count 1
--launch-type "FARGATE" \
--platform-version 1.4.0 \
--network-configuration "awsvpcConfiguration={subnets=[subnetid],securityGroups=[securitygroupid]}" \
--region region
```
## Fargate を使用したカーネルシステムコールトレーシングの SYS\$1PTRACE 機能
コンテナに追加または削除される Linux 機能のデフォルト設定は、Docker が行います。
Fargate で起動したタスクでは、`SYS_PTRACE` カーネル機能の追加のみがサポートされます。
Sysdig [Falco](https://github.com/falcosecurity/falco) プロジェクトでこの機能を使用する方法を示す以下の動画。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/OYGKjmFeLqI)
前のビデオで説明したコードは、[こちら](https://github.com/paavan98pm/ecs-fargate-pv1.4-falco)の GitHub にあります。
## Fargate Runtime Monitoring で Amazon GuardDuty を使用する
Amazon GuardDuty は、AWS 環境内のアカウント、コンテナ、ワークロード、データを保護する脅威検知サービスです。GuardDuty は、機械学習（ML）モデル、異常および脅威検出機能を使用して、さまざまなログソースとランタイムアクティビティを継続的に監視し、環境内の潜在的なセキュリティリスクと悪意のあるアクティビティを特定して優先順位を付けます。
GuardDuty のランタイムモニタリングは、AWS ログとネットワークアクティビティを継続的に監視して悪意のある動作や不正な動作を特定することで、Fargate で実行されているワークロードを保護します。ランタイムモニタリングは、軽量でフルマネージド型の GuardDuty セキュリティエージェントを使用して、ファイルアクセス、プロセス実行、ネットワーク接続などのホスト上動作を分析します。これは、Amazon EC2 インスタンスおよびコンテナワークロードでの権限の昇格、流出した認証情報の使用、悪意のある IP アドレスやドメインとの通信、マルウェアの存在などの問題に対応しています。詳細については、「*GuardDuty ユーザーガイド*」の「[GuardDuty ランタイムモニタリング](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)」を参照してください。
# Amazon ECS の Fargate のセキュリティに関する考慮事項
Fargate は各ワークロードを独立した仮想環境で実行するため、各タスクには専用のインフラストラクチャ容量があります。Fargate で実行されるワークロードは、ネットワークインターフェイス、エフェメラルストレージ、CPU、またはメモリを他のタスクと共有しません。アプリケーションコンテナやサイドカーコンテナを含む複数のコンテナをタスク内で実行することも、単にサイドカーを実行することもできます。*サイドカー*は Amazon ECS タスク内のアプリケーションコンテナと一緒に実行されるコンテナです。アプリケーションコンテナはコアアプリケーションコードを実行しますが、サイドカーで実行されるプロセスはアプリケーションを拡張できます。サイドカーはアプリケーションの機能を専用のコンテナに分離するのに役立ち、アプリケーションの一部を簡単に更新することができます。
同じタスクに属するコンテナは、常に同じホスト上で実行され、コンピュートリソースを共有するため、Fargate 起動タイプのリソースを共有します。これらのコンテナは、Fargate が提供するエフェメラルストレージも共有しています。タスク内の Linux コンテナは、IP アドレスやネットワークポートを含むネットワーク名前空間を共有します。タスク内では、タスクに属するコンテナが localhost を介して相互通信できます。
Fargate のランタイム環境では、EC2 インスタンスでサポートされている特定のコントローラー機能を使用できません。Fargate で実行されるワークロードを設計するときは、次の点を考慮してください。
+ 特権コンテナまたはアクセスなし - 特権コンテナやアクセスなどの機能は現在、Fargate では利用できません。これは Docker 内で Docker を実行するなどのユースケースに影響します。
+ Linux 機能への制限付きアクセス - Fargate 上でコンテナが動作する環境はロックダウンされています。CAP\$1SYS\$1ADMIN や CAP\$1NET\$1ADMIN などのそのほかの Linux 機能は、権限昇格を防ぐために制限されています。Fargateは、タスクに [CAP\$1SYS\$1PTRACE](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params) Linux機能を追加することをサポートしています。これにより、タスク内にデプロイされたオブザーバビリティツールとセキュリティツールがコンテナ化されたアプリケーションを監視できるようになります。
+ 基盤となるホストにはアクセスできない - お客様も AWS オペレーターも、お客様のワークロードを実行しているホストには接続できません。ECS Exec を使用して、Fargate で実行されているコンテナでコマンドを実行したり、シェルを取得したりできます。ECS Exec を使用すると、デバッグ用の診断情報を収集できます。また、Fargate は、コンテナがファイルシステム、デバイス、ネットワーク、コンテナランタイムなどの基盤となるホストのリソースにアクセスするのを防ぎます。
+ ネットワーク - セキュリティグループとネットワーク ACL を使用して、インバウンドトラフィックとアウトバウンドトラフィックをコントロールできます。Fargate のタスクは VPC 内の設定済みサブネットから IP アドレスを受け取ります。
# Amazon ECS 向け Fargate プラットフォームバージョン
AWS Fargate プラットフォームのバージョンを使って、Fargate タスクインフラストラクチャの特定のランタイム環境を参照できます。これは、カーネルとコンテナのランタイムバージョンの組み合わせです。同一のタスクを多数管理するためのタスク実行時、またはそのためのサービス作成時には、プラットフォームバージョンを選択します。
ランタイム環境の進化に合わせて、新しいプラットフォームバージョンがリリースされます。例えば、カーネルやオペレーティングシステムの更新、新機能の追加、バグ修正、セキュリティの更新があった場合が当てはまります。Fargate プラットフォームのバージョンは、新しいプラットフォームバージョンのリビジョンを行うことで更新されます。各タスクは、そのライフサイクルを通じて、単一のプラットフォームバージョンのリビジョンで実行されます。最新のプラットフォームバージョンのリビジョンを使用する場合は、新たにタスクを開始する必要があります。Fargate で実行される新しいタスクは、常にプラットフォームバージョンの最新リビジョンで実行されます。これにより、タスクは必ず、安全でパッチ適用済みのインフラストラクチャで開始されることが保証されます。
既存のプラットフォームのバージョンに影響を与えるセキュリティ上の問題が見つかった場合、AWS は、そのプラットフォームバージョンのパッチ済みリビジョンを新たに作成します。また、脆弱性のあるリビジョンで実行しているタスクは廃止されます。場合によっては、Fargate で使用しているタスクについて、廃止の予定が通知されることがあります。詳細については、「[AWS Fargate on Amazon ECS のタスクの廃止とメンテナンス](task-maintenance.md)」を参照してください。
プラットフォームバージョンは、タスクを実行するとき、またはサービスをデプロイするときに指定します。
プラットフォームのバージョンを指定する際には、次の点を検討してください。
+ `1.4.0`、`LATEST` など、特定のバージョン番号を指定できます。
**[LATEST]** の Linux プラットフォームバージョンは `1.4.0` です。
**[LATEST]** の Windows プラットフォームバージョンは `1.0.0` です。
+ サービスのプラットフォームバージョンを更新する場合は、デプロイを作成します。例えば、Linux のプラットフォームバージョン `1.3.0` で、タスクを実行しているサービスがあるとします。Linux プラットフォームバージョン `1.4.0` でタスクを実行するようにサービスを変更するには、サービスを更新し、新しいプラットフォームバージョンを指定します。タスクは、最新のプラットフォームバージョンと最新のプラットフォームバージョンのリビジョンで再デプロイされます。デプロイの詳細については、「[Amazon ECS サービス](ecs_services.md)」を参照してください。
+ サービスがプラットフォームバージョンを更新しないでスケールアップされた場合、これらのタスクには、サービスの最新のデプロイで指定されたプラットフォームのバージョンが提供されます。例えば、Linux のプラットフォームバージョン `1.3.0` で、タスクを実行しているサービスがあるとします。このサービスについて必要とされる数を増加した場合、サービススケジューラーは、プラットフォームバージョン `1.3.0` の最新のプラットフォームバージョンのリビジョンを使用して、新しいタスクを開始します。
+ 新しいタスクは、常にプラットフォームバージョンの最新リビジョンで実行されます。この結果、タスクは常にセキュリティで保護されパッチが適用されたインフラストラクチャ上になります。
+ Fargate の Linux コンテナと Windows コンテナのプラットフォームバージョンの番号は相互に独立しています。例えば、Fargate の Windows コンテナのプラットフォームバージョン `1.0.0` で使用される動作、機能、およびソフトウェアは、Fargate の Linux コンテナのプラットフォームバージョン `1.0.0` の動作、機能、およびソフトウェアとは比較できません。
+ Fargate Windows プラットフォームバージョンには、以下が適用されます。
Microsoft Windows Server のコンテナイメージは、特定のバージョンの Windows Server から作成する必要があります。Windows Server コンテナイメージに適合したタスクの実行やサービスの作成を行う場合は、`platformFamily` で同じバージョンの Windows Server を選択する必要があります。さらに、タスク定義で一致させる `operatingSystemFamily` を指定して、間違った Windows バージョンでタスクが実行されないようにできます。詳細については、Microsoft Learn のウェブサイトで「[コンテナホストのバージョンとコンテナイメージのバージョンを一致させる](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility#matching-container-host-version-with-container-image-versions)」を参照してください。
# Amazon ECS 上の Linux プラットフォームバージョン 1.4.0 への移行
FargateタスクのAmazon ECSをプラットフォームバージョン `1.0.0`、`1.1.0`、`1.2.0`、または `1.3.0` からプラットフォームバージョン `1.4.0` に移行する場合は、次のことを考慮してください。タスクを移行する前に、そのタスクがプラットフォームバージョン `1.4.0` で正しく動作するのを確認することがベストプラクティスです。
+ タスクとの間のネットワークトラフィック動作を更新しました。プラットフォームバージョン 1.4.0 以降では、Fargate タスクでのすべての Amazon ECS は単一の Elastic Network Interface (以降タスク ENI)を受け取り、すべてのネットワークトラフィックは VPC 内でこの ENI を通過します。このトラフィックは VPC フローログを通じて表示されます。詳細については、「[Fargate における Amazon ECS タスクのネットワークオプション](fargate-task-networking.md)」を参照してください。
+ インターフェイス VPC エンドポイントを使用する場合は、次の点を考慮してください。
+ Amazon ECR でホストされているコンテナイメージでは、次のエンドポイントが必要です。詳細については、*Amazon Elastic コンテナレジストリ ユーザーガイド*の [Amazon ECR Interface VPC エンドポイント(AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)を参照してください。
+ **[com.amazonaws.*region*.ecr.dkr]** Amazon ECR VPC エンドポイント
+ **[com.amazonaws.*region*.ecr.api]** Amazon ECR VPC エンドポイント
+ Amazon S3 ゲートウェイエンドポイント
+ コンテナの機密データを取得する際にタスク定義が Secrets Manager シークレットを参照する場合は、Secrets Manager のインターフェイス VPC エンドポイントを作成する必要があります。詳細については、[AWS Secrets Manager ユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html)の *VPC EndpointでSecrets Managerを使用する* を参照してください。
+ コンテナの機密データを取得する際にタスク定義が Systems Manager Parameter Store パラメータを参照する場合は、SystemsManager のインターフェイス VPC エンドポイントを作成する必要があります。詳細については、「AWS Systems Manager ユーザーガイド」の「[Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html)」を参照してください。**
+ タスクに関連付けられた Elastic Network Interface (ENI) のセキュリティグループには、タスクと VPC エンドポイントとの間のトラフィックを許可するセキュリティグループルールが必要です。
# Fargate Linux プラットフォームバージョンの変更ログ
使用できる Linux プラットフォームのバージョンは以下のとおりです。プラットフォームバージョンの廃止については、[AWS Fargate Linux プラットフォームバージョンの廃止](platform-versions-retired.md)を参照してください。
## 1.4.0
以下は、プラットフォームバージョンの変更履歴です`1.4.0`。
+ 2020 年 11 月 5 日以降、プラットフォームバージョン`1.4.0`を使用して Fargate で起動されたすべての新しい Amazon ECS タスクで次の機能を使用できるようになります:
+ Secrets Managerを使用して機密データを保存する場合、特定の JSON キーまたは特定のシークレットのバージョンを環境変数またはログ設定に挿入できます。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
+ `environmentFiles` コンテナ定義パラメータを使用して、環境変数を一括で指定します。詳細については、「[個々の環境変数を Amazon ECS コンテナに渡す](taskdef-envfiles.md)」を参照してください。
+ VPC で実行されるタスクと IPv6 が有効になっているサブネットには、プライベート IPv4 アドレスと IPv6 アドレスの両方が割り当てられます。詳細については、「[Fargate 起動タイプの Amazon ECS タスクのネットワークオプション](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html)」を参照してください。
+ タスクメタデータエンドポイントバージョン 4 には、タスク起動タイプ、コンテナの Amazon リソースネーム (ARN)、使用されるログドライバーとログドライバーオプションなど、タスクとコンテナに関する追加のメタデータが提供されます。`/stats` エンドポイントに対してクエリを実行すると、コンテナのネットワークレート統計も受け取ります。詳細については、「[タスクメタデータエンドポイントバージョン 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html)」を参照してください。
+ 2020 年 7 月 30 日以降、プラットフォームバージョン `1.4.0` を使用して Fargate で起動されたすべての新しい Amazon ECS タスクは、Network Load Balancer を使用して、UDP トラフィックを Fargate タスク上の Amazon ECS にルーティングできるようになります。詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](service-load-balancing.md)」を参照してください。
+ 2020 年 5 月 28 日以降、プラットフォームバージョン`1.4.0`を使用してFargate で起動されたすべての新しい Amazon ECS タスクにはAWS 所有する暗号化キーを使用して AES-256 暗号化アルゴリズムで暗号化されたエフェメラルストレージが搭載されます。詳細については、「[Amazon ECS 向けの Fargate タスクエフェメラルストレージ](fargate-task-storage.md)」および「[Amazon ECS タスクのストレージオプション](using_data_volumes.md)」を参照してください。
+ 永続的なタスクストレージとして Amazon EFS ファイルシステムボリュームを使用するためにサポートを追加しました。詳細については、「[Amazon ECS での Amazon EFS ボリュームの使用](efs-volumes.md)」を参照してください。
+ エフェメラルタスクストレージは、タスクごとに最低 20 GB に増加しました。詳細については、「[Amazon ECS 向けの Fargate タスクエフェメラルストレージ](fargate-task-storage.md)」を参照してください。
+ タスクとの間のネットワークトラフィック動作を更新しました。プラットフォームバージョン 1.4.0 以降、すべての Fargate タスクは単一の Elastic Network Interface (タスク ENI と呼ばれる) を受け取り、すべてのネットワークトラフィックは VPC 内でこの ENI を通過し、VPC フローログを通じて表示されます。Amazon EC2 起動タイプのネットワークの詳細については、「[EC2 起動タイプの Amazon ECS タスクネットワークオプション](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html)」を参照してください。Fargate のネットワーク設定の詳細については、「[Fargate における Amazon ECS タスクのネットワークオプション](fargate-task-networking.md)」を参照してください。
+ タスク ENI は、ジャンボフレームのサポートを追加しています。ネットワークインターフェイスは、最大転送単位 (MTU) で設定されます。MTU は、1 つのフレームに収まるペイロードの最大サイズです。MTU が大きいほど、1 つのフレーム内に収まるアプリケーションのペイロードが増えるため、フレームあたりのオーバーヘッドが減少し、効率が向上します。ジャンボフレームをサポートすると、オーバーヘッドが減ります。タスクと転送先とのネットワークパスでジャンボフレームをサポートすると、VPC 内に残っているすべてのトラフィックなどのオーバーヘッドが軽減されます。
+ CloudWatch Container Insights には、Fargate タスクのネットワークパフォーマンスメトリクスが含まれます。詳細については、「[オブザーバビリティが強化された Container Insights を使用し、Amazon ECS コンテナを監視する](cloudwatch-container-insights.md)」を参照してください。
+ タスクメタデータエンドポイントバージョン 4 のサポートを追加しました。これにより、タスクのネットワーク統計情報や、タスクが実行されているアベイラビリティーゾーンなど、Fargate タスクに関する追加情報が提供されます。詳細については、「[Amazon ECS タスクメタデータエンドポイントバージョン 4](task-metadata-endpoint-v4.md)」および「[Fargate のタスク用の Amazon ECS タスクメタデータエンドポイントバージョン 4](task-metadata-endpoint-v4-fargate.md)」を参照してください。
+ コンテナの定義に `SYS_PTRACE` Linux パラメータのサポートを追加しました。詳細については、「[Linux パラメータ](task_definition_parameters.md#container_definition_linuxparameters)」を参照してください。
+ Fargateコンテナエージェントは、Amazon ECS コンテナエージェントの使用をすべての Fargate タスクに置き換えます。通常、この変更は、タスクの実行方法には影響しません。
+ コンテナランタイムは Docker の代わりに Containerd を使用するようになりました。ほとんどの場合、この変更はタスクの実行方法には影響しません。コンテナランタイムで発生するいくつかのエラーメッセージは、より一般的な内容になり、Docker には言及されなくなります。詳細については、「[Amazon ECS の停止したタスクのエラーメッセージ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html)」を参照してください。
+ Amazon Linux 2 に基づく。
# AWS Fargate Linux プラットフォームバージョンの廃止
**重要**
Fargate での PV 1.3.0 のサポートは 2026 年 6 月 30 日に終了します。2026 年 6 月 15 日付けで、プラットフォームバージョン 1.3.0 が廃止されます。その時点では、プラットフォームバージョン 1.3.0 で設定された新しいタスクを起動したり、新しいサービスを作成したりすることはできませんが、既存のタスクは引き続き実行されます。2026 年 6 月 30 日になると、プラットフォームバージョン 1.3.0 を使用して設定された残りの実行中タスクのすべてが終了されます。
プラットフォームバージョン 1.4 に移行する方法については、「[Amazon ECS 上の Linux プラットフォームバージョン 1.4.0 への移行](platform-version-migration.md)」を参照してください。
次の表は、AWS Fargate で廃止された、または廃止が予定されている Linux プラットフォームのバージョンを示しています。これらのプラットフォームのバージョンは、公開された廃止日までは引き続き利用できます。
廃止予定のプラットフォームのバージョンごとに、*強制更新日*が提供されます。強制更新日に、廃止予定のプラットフォームバージョンを指す`LATEST` プラットフォームバージョンを使用するすべてのサービスは、強制新規デプロイオプションを使用して更新されます。強制新規デプロイオプションを使用してサービスを更新すると、廃止予定のプラットフォームバージョンで実行されているすべてのタスクが停止され、新しいタスクは`LATEST`タグがその時に指すプラットフォームのバージョンを使用して起動されます。明示的なプラットフォームバージョンが設定されているスタンドアロンのタスクまたはサービスは、強制更新日の影響を受けません。
最新のプラットフォームバージョンに移行する方法については、「[Amazon ECS 上の Linux プラットフォームバージョン 1.4.0 への移行](platform-version-migration.md)」を参照してください。
プラットフォームバージョンが*廃止日*に達すると、そのプラットフォームバージョンは新しいタスクやサービスで使用できなくなります。非推奨のプラットフォームバージョンを明示的に使用するスタンドアロンのタスクまたはサービスは、タスクが停止されるまでそのプラットフォームバージョンを使用し続けます。廃止日を過ぎると、非推奨のプラットフォームバージョンはセキュリティのアップデートやバグの修正を受けなくなります。
| プラットフォームバージョン | 強制更新日 | 廃止日 |
| --- | --- | --- |
| 1.0.0 | 2020 年 10 月 26 日 | 2020 年 12 月 14 日 |
| 1.1.0 | 2020 年 10 月 26 日 | 2020 年 12 月 14 日 |
| 1.2.0 | 2020 年 10 月 26 日 | 2020 年 12 月 14 日 |
| 1.3.0 | | 2026 年 6 月 15 日 |
現在のプラットフォームバージョンの詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
## 廃止された Fargate Linux バージョンに関する変更ログ
### 1.3.0
以下は、プラットフォームバージョンの変更履歴です`1.3.0`。
+ 2019 年 9 月 30 日以降、起動されたすべての新しい Fargate タスクでは、`awsfirelens`ログドライバーをサポートします。タスク定義パラメータを使用して、AWS のサービスまたは AWS パートナーネットワーク (APN) の送信先に、ログをルーティングし保存および分析を行うように、FireLens for Amazon ECS を設定します。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。
+ Fargateタスクのタスクリサイクルが追加されました。これは、Amazon ECS サービスの一部であるタスクを更新するプロセスです。詳細については、「[AWS Fargate on Amazon ECS のタスクの廃止とメンテナンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-maintenance.html)」。
+ 2019 年 3 月 27 日以降、起動されたすべての新しい Fargate タスクでは、プロキシ設定、コンテナのスタートアップとシャットダウンの依存関係、コンテナ別の起動と停止のタイムアウト値を定義するための追加タスク定義パラメータを使用できます。詳細については[プロキシ設定](task_definition_parameters.md#proxyConfiguration)、[コンテナの依存関係](task_definition_parameters.md#container_definition_dependson)、および[[コンテナのタイムアウト]](task_definition_parameters.md#container_definition_timeout)を参照してください。
+ 2019 年 4 月 2 日以降、起動されたすべての新しい Fargate タスクでは、機密データをAWS Secrets ManagerシークレットまたはAWS Systems Managerパラメーターストアのパラメーターのいずれかに保存し、コンテナ定義でそれらを参照することにより、コンテナへの機密データの挿入をサポートします。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
+ 2019 年 5 月 1 日以降、起動された新しい Fargate タスクでは、`secretOptions` コンテナ定義パラメータを使用してコンテナのログ設定内の機密データを参照できます。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
+ 2019 年 5 月 1 日以降、起動されるすべての新しいFargate タスクでは、`splunk`ログドライバーに加えて `awslogs`ログドライバーがサポートされます。詳細については、「[ストレージとログ記録](task_definition_parameters.md#container_definition_storage)」を参照してください。
+ 2019 年 7 月 9 日以降に新しく起動された Fargate タスクでは、 CloudWatch Container Insights がサポートされています。詳細については、「[オブザーバビリティが強化された Container Insights を使用し、Amazon ECS コンテナを監視する](cloudwatch-container-insights.md)」を参照してください。
+ 2019 年 12 月 3 日より、Fargate Spot キャパシティープロバイダーがサポートされます。詳細については、「[Fargate 用の Amazon ECS クラスター](fargate-capacity-providers.md)」を参照してください。
+ Amazon Linux 2 に基づく。
### 1.2.0
以下は、プラットフォームバージョンの変更履歴です`1.2.0`。
**注記**
プラットフォームバージョン `1.2.0` は今後利用できません。プラットフォームバージョンの廃止については、[AWS Fargate Linux プラットフォームバージョンの廃止](#platform-versions-retired)を参照してください。
+ AWS Secrets Manager を使用したプライベートレジストリ認証のサポートが追加されました。詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
### 1.1.0
以下は、プラットフォームバージョンの変更履歴です`1.1.0`。
**注記**
プラットフォームバージョン `1.1.0` は今後利用できません。プラットフォームバージョンの廃止については、[AWS Fargate Linux プラットフォームバージョンの廃止](#platform-versions-retired)を参照してください。
+ Amazon ECSタスクメタデータエンドポイントのサポートを追加しました。詳細については、「[Fargate のタスクで使用できる Amazon ECS タスクメタデータ](fargate-metadata.md)」を参照してください。
+ コンテナ定義に追加された Docker ヘルスチェックのサポート。詳細については、「[ヘルスチェック](task_definition_parameters.md#container_definition_healthcheck)」を参照してください。
+ Amazon ECSサービス検出のサポートを追加しました。詳細については、「[サービス検出を使用して Amazon ECS サービスを DNS 名で接続する](service-discovery.md)」を参照してください。
### 1.0.0
以下は、プラットフォームバージョンの変更履歴です`1.0.0`。
**注記**
プラットフォームバージョン `1.0.0` は今後利用できません。プラットフォームバージョンの廃止については、[AWS Fargate Linux プラットフォームバージョンの廃止](#platform-versions-retired)を参照してください。
+ Amazon Linux 2017.09 に基づく。
+ 初回リリース。
# Fargate Windows プラットフォームバージョンの変更ログ
Windows コンテナに使用できるプラットフォームのバージョンは以下のとおりです。
## 1.0.0
以下は、プラットフォームバージョンの変更履歴です`1.0.0`。
+ 以下の Microsoft Windows Server オペレーティングシステムに対応した初期リリース。
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
# Amazon ECS における Fargate 上の Windows コンテナに関する考慮事項
AWS Fargate で Windows コンテナを実行する場合の相違点と考慮事項は次のとおりです。
Linux と Windows のコンテナでタスクを実行する必要がある場合は、オペレーティングシステムごとに別々のタスク定義を作成する必要があります。
オペレーティングシステムのライセンス管理は、AWS が担当します。したがって、お客様は、追加の Microsoft ライセンスの必要はありません。
AWS Fargate の Windows コンテナは以下のオペレーティングシステムをサポートしています。
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
AWS Fargate の Windows コンテナは、awslogs ドライバをサポートしています。詳細については、「[Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)」を参照してください。
Fargate の Windows コンテナでは、以下の機能はサポートされていません。
+ Amazon FSx
+ ENI トランキング
+ Windows コンテナ向け gMSA
+ タスク用 App Mesh サービスとプロキシの統合
+ タスク用 Firelens ログルーターの統合
+ EFS ボリューム
+ EBS ボリューム
+ 以下に示すタスク定義パラメータ。
+ `maxSwap`
+ `swappiness`
+ `environmentFiles`
+ Fargate Spot キャパシティープロバイダー
+ イメージボリューム
Dockerfile `volume` オプションは無視されます。代わりに、タスクの定義でバインドマウントを使用します。詳細については、「[Amazon ECS でのバインドマウントの使用](bind-mounts.md)」を参照してください。
+ Windows コンテナーでは、タスクレベルの CPU およびメモリパラメーターは無視されます。Windows コンテナではコンテナレベルリソースを指定することをお勧めします。
+ タスクのメモリ
+ コンテナのメモリ予約
+ コンテナのポリシーを再起動する
+ サービスの platformFamily を更新することはできません。
# Fargate 上の Linux コンテナにおける Amazon ECS のコンテナイメージのプル動作
すべての Fargate タスクは、専用のシングルユース、シングルテナントのインスタンスで実行されます。Fargate 上で Linux コンテナを実行すると、コンテナイメージまたはコンテナイメージレイヤーはインスタンスにキャッシュされません。したがって、タスクで定義されたコンテナイメージごとに、コンテナイメージ全体を各 Fargate タスクのコンテナイメージレジストリからプルする必要があります。イメージをプルするのにかかる時間は、Fargate タスクを開始するのにかかる時間と直接相関しています。
イメージのプル時間を最適化するために、次の点を考慮してください。
**コンテナイメージの近接性**
コンテナイメージのダウンロードにかかる時間を短縮するには、データをコンピューティングにできるだけ近い場所に配置します。コンテナイメージをインターネット経由または AWS リージョン 間でプルすると、ダウンロード時間に影響する可能性があります。コンテナイメージは、タスクを実行するのと同じリージョンに保存することをお勧めします。コンテナイメージを Amazon ECR に保存する場合は、VPC インターフェイスエンドポイントを使用することでイメージのプル時間をさらに短縮できます。詳細については、「*Amazon ECR ユーザーガイド*」の「[Amazon ECR インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)」を参照してください。
**コンテナイメージのサイズ削減**
コンテナイメージのサイズは、ダウンロード時間に直接影響します。コンテナイメージのサイズまたはコンテナイメージレイヤーの数を減らすことで、イメージのダウンロードにかかる時間を短縮できます。軽量なベースイメージ (最小の Amazon Linux 2023 コンテナイメージなど) は、従来のオペレーティングシステムのベースイメージに基づくイメージよりも大幅に小さくすることができます。最小イメージの詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[AL2023 の最小コンテナイメージ](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html)」を参照してください。
**代替の圧縮アルゴリズム**
多くの場合、コンテナイメージレイヤーは、コンテナイメージレジストリにプッシュされるときに圧縮されます。コンテナイメージレイヤーを圧縮することで、ネットワーク経由で転送され、コンテナイメージレジストリに保存されるデータの量を削減できます。コンテナランタイムによってコンテナイメージレイヤーがインスタンスにダウンロードされた後、そのレイヤーは解凍されます。使用される圧縮アルゴリズムとランタイムに使用できる vCPU の量は、コンテナイメージの解凍にかかる時間に影響します。Fargate では、タスクのサイズを増やすか、よりパフォーマンスの高い zstd 圧縮アルゴリズムを利用することで、解凍にかかる時間を短縮できます。詳細については、GitHub の「[zstd](https://github.com/facebook/zstd)」を参照してください。Fargate のイメージを実装する方法については、「[Reducing AWS Fargate Startup Times with zstd Compressed Container Images](https://aws.amazon.com/blogs/containers/reducing-aws-fargate-startup-times-with-zstd-compressed-container-images/)」を参照してください。
**コンテナイメージの遅延読み込み**
大きなコンテナイメージ (> 250 mb) の場合、すべてのコンテナイメージをダウンロードするのではなく、コンテナイメージを遅延読み込みするのが最適である場合があります。Fargate では、Seekable OCI (SOCI) を使用して、コンテナイメージレジストリからコンテナイメージを遅延読み込みできます。詳細については、GitHub の「[soci-snapshotter](https://github.com/awslabs/soci-snapshotter)」と「[Seekable OCI (SOCI) を使ったコンテナイメージの遅延読み込み](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-soci-images)」を参照してください。
# Fargate 上の Windows コンテナにおける Amazon ECS のコンテナイメージのプル動作
Fargate Windows は、Microsoft から提供された直近の月と前月のサーバーコアのベースイメージをキャッシュします。これらのイメージは、毎週火曜日のパッチで更新される KB /ビルド番号のパッチと一致します。例えば、Microsoft は 2024 年 4 月 9 日に Windows Server 2019 用の KB5036896 (17763.5696) をリリースしました。前月の KB (2024 年 3 月 12 日) は KB5035849 (17763.5576) でした。そのため、プラットフォーム `WINDOWS_SERVER_2019_CORE` および `WINDOWS_SERVER_2019_FULL` では、以下のコンテナイメージがキャッシュされました。
+ `mcr.microsoft.com/windows/servercore:ltsc2019`
+ ` mcr.microsoft.com/windows/servercore:10.0.17763.5696`
+ `mcr.microsoft.com/windows/servercore:10.0.17763.5576`
さらに、Microsoft は 2024 年 4 月 9 日に Windows Server 2022 用の KB5036909 (20348.2402) をリリースしました。前月の KB (2024 年 3 月 12 日) は KB5035857 (20348.2340) でした。そのため、プラットフォーム `WINDOWS_SERVER_2022_CORE` および `WINDOWS_SERVER_2022_FULL` では以下のコンテナイメージがキャッシュされました。
+ `mcr.microsoft.com/windows/servercore:ltsc2022`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2402`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2340`
# Amazon ECS 向けの Fargate タスクエフェメラルストレージ
AWS Fargate の Linux コンテナでホストされている各 Amazon ECS タスクはプロビジョニング時にバインドマウントのために次のエフェメラルストレージを受け取ります。これらをマウントし、タスク定義内で `volumes`、`mountPoints` および `volumesFrom` パラメータを使用しているコンテナ間で共有することが可能です。この設定は AWS Fargate の Windows コンテナではサポートされません。
## Fargate Linux コンテナプラットフォームのバージョン
### バージョン 1.4.0 以降
プラットフォームバージョン `1.4.0` 以降を使用している Fargate でホストされている Amazon ECS タスクは、デフォルトで、最低 20 GiB のエフェメラルストレージを受け取ります。エフェメラルストレージの総量は、最大 200 GiB まで増やすことができます。これを行うには、タスク定義内で `ephemeralStorage` パラメータを設定します。
プル、圧縮、および非圧縮されたコンテナイメージは、エフェメラルストレージに格納されます。タスクを使用するエフェメラルストレージの総量を判断するには、タスクが割り当てられているエフェメラルストレージの総量から、コンテナイメージが使用するストレージの容量を差し引く必要があります。
2020 年 5 月 28 日以降に開始されたプラットフォームバージョン `1.4.0` 以降を使用するタスクでは、エフェメラルストレージが AES-256 暗号化アルゴリズムにより暗号化されます。このアルゴリズムは AWS が所有する暗号化キーを使用するか、独自のカスタマーマネージドキーを作成できます。詳細については、「[Customer managed keys for AWS Fargate ephemeral storage](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html)」を参照してください。
2022 年 11 月 18 日以降に開始されたプラットフォームバージョン `1.4.0` 以降を使用するタスクでは、エフェメラルストレージの使用量がタスクメタデータエンドポイントを通じて報告されます。タスク内のアプリケーションは、タスクメタデータエンドポイントのバージョン 4 に対してクエリを実行して、エフェメラルストレージの予約サイズと使用量を取得できます。
さらに、Container Insights をオンにすると、エフェメラルストレージの予約サイズと使用量が Amazon CloudWatch Container Insights に送信されます。
**注記**
Fargate はディスク上のスペースを予約します。スペースは Fargate によってのみ使用されます。これには課金されることはありません。これらのメトリクスには表示されません。ただし、この追加ストレージは、`df` などの他のツールでも確認できます。
### バージョン 1.3.0 以前
プラットフォームバージョン `1.3.0` 以前を使用する Fargate タスクでの Amazon ECS の場合、各タスクは次のエフェメラルストレージを受け取ります。
+ 10 GB の Docker Layer ストレージ
**注記**
この量には、圧縮および非圧縮のコンテナイメージのアーティファクトの両方が含まれます。
+ ボリュームマウント用の追加 4 GB。これらをマウントし、タスク定義内で `volumes`、`mountPoints` および `volumesFrom` パラメータを使用しているコンテナ間で共有することが可能です。
## Fargate Windows コンテナプラットフォームのバージョン
### バージョン 1.0.0 以降
プラットフォームバージョン `1.0.0` 以降を使用している Fargate でホストされている Amazon ECS タスクは、デフォルトで、最低 20 GiB のエフェメラルストレージを受け取ります。エフェメラルストレージの総量は、最大 200 GiB まで増やすことができます。これを行うには、タスク定義内で `ephemeralStorage` パラメータを設定します。
プル、圧縮、および非圧縮されたコンテナイメージは、エフェメラルストレージに格納されます。タスクが使用するエフェメラルストレージの総量を判断するには、タスクに割り当てられたエフェメラルストレージの総量から、コンテナイメージが使用するストレージの容量を差し引く必要があります。
詳細については、「[Amazon ECS でのバインドマウントの使用](bind-mounts.md)」を参照してください。
# Amazon ECS 向け AWS Fargate エフェメラルストレージ用のカスタマーマネージドキー
AWS Fargate は、エフェメラルストレージに保存されている Amazon ECS タスクのデータを暗号化するカスタマーマネージドキーをサポートし、規制の影響を受けるお客様が内部セキュリティポリシーを満たすことができるよう支援しています。お客様は、Fargate のサーバーレスのメリットを引き続き享受しながら、コンプライアンス監査者に対してセルフマネージドストレージ暗号化の強化された可視性を提供できます。Fargate は、デフォルトで Fargate 管理のエフェメラルストレージ暗号化を備えていますが、お客様は財務情報や健康関連情報などの機密データを暗号化する際に、独自のセルフマネージドキーを使用することもできます。
AWS KMS に独自のキーをインポートするか、AWS KMS でキーを作成できます。これらのセルフマネージドキーは AWS KMS に保存され、ローテーション、無効化、削除などの標準的な AWS KMS のライフサイクルアクションを実行します。CloudTrail ログで、キーのアクセスと使用状況を監査できます。
デフォルトでは、KMS キーはキーごとに 50,000 の許可をサポートします。Fargate は、各カスタマーマネージドキーのタスクに 1 つの AWS KMS 許可を使用するため、1 つのキーに対して最大 50,000 の同時タスクをサポートします。この数を増やしたい場合は、ケースバイケースで承認される制限の引き上げをリクエストすることができます。
Fargate では、カスタマーマネージドキーの使用に追加の料金は発生しません。ストレージと API リクエストに AWS KMS キーを使用するための標準料金のみが請求されます。
**Topics**
+ [
# Amazon ECS 向け Fargate エフェメラルストレージの暗号化キーを作成する
](fargate-create-storage-key.md)
+ [
# Amazon ECS 向け Fargate エフェメラルストレージの AWS KMS キーを管理する
](fargate-managing-kms-key.md)
# Amazon ECS 向け Fargate エフェメラルストレージの暗号化キーを作成する
Fargate エフェメラルストレージに保存されているデータを暗号化するためのカスタマーマネージドキーを作成します。
**注記**
カスタマーマネージドキーによる Fargate エフェメラルストレージの暗号化は、Windows タスククラスターでは利用できません。
カスタマーマネージドキーによる Fargate エフェメラルストレージの暗号化は、`1.4.0` より前のバージョンの `platformVersions` では利用できません。
Fargate は、Fargate のみが使用するエフェメラルストレージのスペースを予約します。そのスペースに対して料金は発生しません。割り当ては、カスタマー管理以外のキータスクとは異なる場合がありますが、スペースの合計は変わりません。この変更については、`df` などのツールで確認できます。
マルチリージョンキーは、Fargate エフェメラルストレージではサポートされていません。
KMS キーエイリアスは、Fargate エフェメラルストレージではサポートされていません。
AWS KMS で Fargate のエフェメラルストレージを暗号化するカスタマーマネージドキー (CMK) を作成するには、次のステップに従ってください。
1. [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) に移動します。
1. 手順については、「[AWS Key Management Service デベロッパーガイド](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)」の「[Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
1. AWS KMS キーを作成するときは、キーポリシーで Fargate サービスに関連する AWS KMS オペレーションのアクセス許可を必ず付与してください。Amazon ECS クラスターリソースでカスタマー管理キーを使用するには、ポリシーで次の API オペレーションを許可する必要があります。
+ `kms:GenerateDataKeyWithoutPlainText` ‐ `GenerateDataKeyWithoutPlainText` を呼び出し、提供された AWS KMS キーから暗号化されたデータキーを生成します。
+ `kms:CreateGrant` - カスタマーマネージドキーに許可を追加します。指定された AWS KMS キーへのアクセス制御を付与します。これは、Amazon ECS Fargate が必要なグラントオペレーションへのアクセスを許可するものです。詳細については、「[AWS Key Management Service デベロッパーガイド](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)」の「[AWS KMS でのグラント](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)」を参照してください。これにより、Amazon ECS Fargate で以下を行うことができます。
+ `Decrypt` から AWS KMS を呼び出し、エフェメラルストレージのデータを復号するための暗号化キーを取得します。
+ `RetireGrant` にサービスが許可するための、廃止するプリンシパルを設定します。
+ `kms:DescribeKey` — カスタマーマネージドキーの詳細を提供し、キーが対称、かつ有効である場合に、Amazon ECS がキーを検証できるようにします。
次の例は、暗号化するターゲットキーに適用する AWS KMS キーポリシーを示しています。ポリシーステートメントの例を使用する際は、*ユーザー入力用プレースホルダー*を独自の情報に置き換えます。通常どおり、必要なアクセス許可のみを設定しますが、エラーを回避するために、少なくとも 1 人のユーザーにアクセス許可付きの AWS KMS を提供する必要があります。
```
{
"Sid": "Allow generate data key access for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:GenerateDataKeyWithoutPlaintext"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow grant creation permission for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:CreateGrant"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow describe key permission for cluster operator - CreateCluster and UpdateCluster.",
"Effect": "Allow",
"Principal": { "AWS":"arn:aws:iam::customerAccountId:role/customer-chosen-role" },
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
}
```
Fargate タスクでは、キーを使用する暗号化オペレーションに `aws:ecs:clusterAccount` および `aws:ecs:clusterName` 暗号化コンテキストキーを使用します。特定のアカウントやクラスターへのアクセスを制限するには、これらのアクセス許可を追加する必要があります。クラスターを指定するときは、ARN ではなくクラスター名を使用してください。
詳しくは、[AWS KMS デベロッパーガイド](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)の [Encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) を参照してください。
クラスターを作成または更新する場合、条件キー `fargateEphemeralStorageKmsKeyId` を使用するオプションを利用できます。この条件キーにより、お客様は IAM ポリシーをよりきめ細かく制御できます。`fargateEphemeralStorageKmsKeyId` 設定の更新は、新しいサービスのデプロイでのみ有効になります。
以下は、お客様が特定の承認された AWS KMS キーのセットにのみアクセス許可を付与できるようにする例です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ecs:fargate-ephemeral-storage-kms-key": "arn:aws:kms:us-west-2:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
}
}
]
}
```
------
次に、クラスターに既に関連付けられている AWS KMS キーの削除を拒否する例を示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"Null": {
"ecs:fargate-ephemeral-storage-kms-key": "true"
}
}
}
}
```
------
お客様は、AWS CLI、`describe-tasks`、`describe-cluster` または `describe-services` コマンドを使用して、管理されていないタスクまたはサービスタスクが、キーを使用して暗号化されているかどうかを確認できます。
詳細については、「[AWS KMS デベロッパーガイド](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)」の「[Condition keys for AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html)」を参照してください。
------
#### [ AWS マネジメントコンソール ]
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. 左側のナビゲーションで **[クラスター]**を選択し、右上で **[クラスターの作成]** を選択するか、既存のクラスターを選択します。既存のクラスターの場合は、右上の **[クラスターの更新]** を選択します。
1. ワークフローの **[暗号化] **セクションでは、**[マネージド型ストレージ]** と **[Fargate エフェメラルストレージ]** で AWS KMS キーを選択することもできます。ここで **[AWS KMS キーの作成]** を選択することもできます。
1. 新しいクラスターの作成が完了したら **[作成]** を選択し、既存のクラスターを更新する場合は **[更新]** を選択します。
------
#### [ AWS CLI ]
以下は、クラスターを作成し、AWS CLI を使用して Fargate エフェメラルストレージを設定する例です (*赤色*の値は独自の値に置き換えてください)。
```
aws ecs create-cluster --cluster clusterName \
--configuration '{"managedStorageConfiguration":{"fargateEphemeralStorageKmsKeyId":"arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"}}'
{
"cluster": {
"clusterArn": "arn:aws:ecs:us-west-2:012345678901:cluster/clusterName",
"clusterName": "clusterName",
"configuration": {
"managedStorageConfiguration": {
"fargateEphemeralStorageKmsKeyId": "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
},
"status": "ACTIVE",
"registeredContainerInstancesCount": 0,
"runningTasksCount": 0,
"pendingTasksCount": 0,
"activeServicesCount": 0,
"statistics": [],
"tags": [],
"settings": [],
"capacityProviders": [],
"defaultCapacityProviderStrategy": []
},
"clusterCount": 5
}
```
------
#### [ CloudFormation ]
以下は、クラスターを作成し、CloudFormation を使用して Fargate エフェメラルストレージを設定するテンプレートの例です (*赤色*の値は独自の値に置き換えてください)。
```
AWSTemplateFormatVersion: 2010-09-09
Resources:
MyCluster:
Type: AWS::ECS::Cluster
Properties:
ClusterName: "clusterName"
Configuration:
ManagedStorageConfiguration:
FargateEphemeralStorageKmsKeyId: "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
------
# Amazon ECS 向け Fargate エフェメラルストレージの AWS KMS キーを管理する
Fargate エフェメラルストレージを暗号化するための AWS KMS キーを作成またはインポートしたら、他の AWS KMS キーと同じ方法で管理します。
**AWS KMS キーの自動ローテーション**
キーの自動ローテーションを有効にするか、手動でローテーションすることができます。キーの自動ローテーションは、キーの新しい暗号化マテリアルを生成することによって、キーを毎年ローテーションします。AWS KMS は、暗号化マテリアルの以前のバージョンもすべて保存するため、以前のキーバージョンを使用したデータを復号化することができます。ローテーションされたマテリアルは、キーを削除するまで AWS KMS によって削除されることはありません。
キーの自動ローテーションはオプションであり、いつでも有効または無効にできます。
**AWS KMS キーの無効化または取り消し**
AWS KMS でカスタマーマネージドキーを無効にした場合でも、タスクの実行に影響はなく、ライフサイクルを通じて引き続き機能します。無効化または取り消しされたキーが新しいタスクで使用されている場合は、キーにアクセスできないためタスクは失敗します。CloudWatch アラームなどを設定し、既に暗号化されたデータを復号するために無効化されたキーが再び必要になることがないことを確認する必要があります。
**AWS KMS キーの削除**
キーの削除は最終的な手段であり、削除されたキーが再び必要になることがないと確信している場合にのみ実行する必要があります。削除されたキーを使用しようとする新しいタスクは、そのキーにアクセスできないため失敗します。AWS KMS では、キーを削除するのではなく、キーを無効にすることをお勧めしています。キーを削除する必要があると思われる場合は、最初にキーを無効にした後、CloudWatch アラームを設定して、不要であることを確認することをお勧めします。キーを削除する場合、AWS KMS では少なくとも 7 日間の猶予期間が付与されているため、その期間に削除を撤回することも可能です。
**AWS KMS キーアクセスの監査**
CloudTrail ログを使用して、AWS KMS キーへのアクセスを監査できます。AWS KMS オペレーション `CreateGrant`、`GenerateDataKeyWithoutPlaintext`、および `Decrypt` を確認できます。これらのオペレーションでは、`EncryptionContext` がログインした CloudTrail の一部として `aws:ecs:clusterAccount` および `aws:ecs:clusterName` も表示されます。
以下は、`GenerateDataKeyWithoutPlaintext`、`GenerateDataKeyWithoutPlaintext (DryRun)`、`CreateGrant`、`CreateGrant (DryRun)`、`RetireGrant` の CloudTrail イベントの例です (*赤色*の値は独自の値に置き換えてください)。
------
#### [ GenerateDataKeyWithoutPlaintext ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"numberOfBytes": 64,
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxxxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ GenerateDataKeyWithoutPlaintext (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"dryRun": true,
"numberOfBytes": 64,
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"retiringPrincipal": "ec2.us-west-2.amazonaws.com"
},
"responseElements": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"dryRun": true,
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ RetireGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "AWS Internal"
},
"eventTime": "2024-04-20T18:37:38Z",
"eventSource": "kms.amazonaws.com",
"eventName": "RetireGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": null,
"responseElements": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"additionalEventData": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
# AWS Fargate on Amazon ECS のタスクの廃止とメンテナンス
AWS は、AWS Fargate の基盤インフラストラクチャを維持する責任を負います。AWS は、プラットフォームバージョンのリビジョンを、インフラストラクチャ用の新しいリビジョンに置き換える必要があるタイミングを決定します。これはタスクの廃止と呼ばれます。プラットフォームバージョンのリビジョンが廃止されると、AWS からタスクの廃止通知が送信されます。サポート対象のプラットフォームバージョンを定期的に更新して、Fargate ランタイムソフトウェアと、オペレーティングシステムやコンテナランタイムなどの内在的な依存関係の更新を含む新しいリビジョンを導入しています。新しいリビジョンが利用可能になった後、すべてのお客様のワークロードが Fargate プラットフォームバージョンの最新リビジョンで実行されるように、古いリビジョンを廃止します。リビジョンが廃止されると、そのリビジョンで実行されていたすべてのタスクが停止します。
Amazon ECS タスクは、サービスタスクまたはスタンドアロンタスクのどちらかに分類されます。サービスタスクは、Amazon ECS サービスの一部としてデプロイされ、Amazon ECS スケジュールによって制御されます。詳細については、「[Amazon ECS サービス](ecs_services.md)」を参照してください。スタンドアロンタスクとは、Amazon ECS `RunTask` API によって開始されるタスクであり、直接または、Amazon EventBridge によって開始されるスケジュールされたタスク、AWS Batch、AWS Step Functions などの外部スケジューラにより開始されます。Amazon ECS スケジューラはタスクを自動的に置き換えるため、サービスタスクのタスク廃止への対応のために措置を講じる必要はありません。
スタンドアロンタスクについては、タスク廃止への対応として追加の処理を実行する必要が生じる場合があります。詳細については、「[Amazon ECS はスタンドアロンタスクを自動的に処理できますか?](#task-retirement-standalone-tasks)」を参照してください。
サービスタスクについては、AWS よりも前にこれらのタスクを置き換える場合を除き、タスク廃止に対する措置を講じる必要はありません。Amazon ECS スケジューラーはタスクを停止すると、`maximumPercent` を使用して新しいタスクを起動し、サービスに必要な数を維持しようとします。ベストプラクティスに従って、タスクの廃止の影響を最小限に抑えます。REPLICA サービススケジューラを使用するサービスのデフォルトの `maximumPercent` 値は 200% です。そのため、AWS Fargate が廃止タスクを開始すると、Amazon ECS はまず新しいタスクをスケジュールし、それが実行されるのを待ってから、古いタスクを廃止します。`maximumPercent` 値を 100% に設定すると、Amazon ECS は最初にタスクを停止し、次にタスクを置き換えます。
スタンドアロンタスクの廃止では、AWS タスク廃止日およびそれ以降のタスクを停止します。タスクが停止したとき、Amazon ECS は代替のタスクを起動しません。これらのタスクを継続して実行する必要がある場合は、通知で示された時間より前に、実行中のタスクを停止し、代替タスクを起動する必要があります。そのためユーザーには、スタンドアロンタスクの状態をモニタリングすることと、必要に応じて停止したタスクを置き換えるロジックの実装が推奨されます。
タスクが停止したシナリオに関係なく、`describe-tasks` を実行することができます。レスポンス内の `stoppedReason` は `ECS is performing maintenance on the underlying infrastructure hosting the task` です。
タスクのメンテナンスは、新しいプラットフォームバージョンのリビジョンを新しいリビジョンで置き換える必要があるときに適用されます。内在する Fargate ホストに問題がある場合、Amazon ECS はタスク終了通知を行わず、ホストを交換します。
## タスク廃止通知の概要
AWS がプラットフォームバージョンリビジョンを要廃止としてマークすると、そのプラットフォームバージョンリビジョンで実行されているすべてのタスクがすべてのリージョンで特定されます。
以下の図は、新しいリビジョンの起動からプラットフォームリビジョンの廃止までの、Fargate プラットフォームバージョンリビジョンのライフサイクルを示しています。
![\[Fargate のタスク廃止ライフサイクルを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/fargate-task-retirement.png)
以下は、ライフサイクルの詳細情報です。
+ 新しいプラットフォームバージョンリビジョンが起動されたら、新しいタスクのすべてがこのリビジョンでスケジュールされます。
+ 実行されているスケジュール済みの既存のタスクは、タスクの期間が終わるまで元々設定されていたリビジョンに残り、新しいリビジョンには移行されません。
+ 新しいタスク (サービスの更新や Fargate のタスク廃止の一環として行われるタスクなど) は、起動時に利用可能な最新のプラットフォームバージョンリビジョンに設定されます。
タスク廃止通知は、AWS Health ダッシュボード、および登録された E メールアドレスへの E メールを通じて送信され、以下の情報が含まれています。
+ タスクの廃止日 - タスクは、この日またはそれ以降に停止されます。
+ タスクの ID (スタンドアロンタスクの場合)。
+ サービスが実行されるクラスターの ID とサービスの ID (サービスタスクの場合)。
+ 次に実行する必要があるステップ。
通常、AWS リージョン のサービスタスクとスタンドアロンのタスクについて、それぞれ 1 件の通知が送信されます。ただし、場合によっては、タスクタイプごとに複数のイベントを受け取ることがあります。たとえば、廃止するタスクが多すぎて通知メカニズムの制限を超える場合などです。
廃止がスケジュールされているタスクは次の方法で識別できます。
+ Health Dashboard
AWS Health 通知は Amazon EventBridge 経由で Amazon Simple Storage Service などのアーカイブストレージに送信すること、AWS Lambda 関数の実行などの自動化されたアクションを取ること、または Amazon Simple Notification Service などのその他の通知システムに送信することができます。詳細については「[Amazon EventBridge による AWS Health イベントのモニタリング](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)」を参照してください。Amazon Chime、Slack、または Microsoft Teams に通知を送信するための設定例については、GitHub の「[AWS Health Aware](https://github.com/aws-samples/aws-health-aware)」リポジトリを参照してください。
EventBridge イベントの例を次に示します。
```
{
"version": "0",
"id": "3c268027-f43c-0171-7425-1d799EXAMPLE",
"detail-type": "AWS Health Event",
"source": "aws.health",
"account": "123456789012",
"time": "2023-08-16T23:18:51Z",
"region": "us-east-1",
"resources": [
"cluster|service",
"cluster|service"
],
"detail": {
"eventArn": "arn:aws:health:us-east-1::event/ECS/AWS_ECS_TASK_PATCHING_RETIREMENT/AWS_ECS_TASK_PATCHING_RETIREMENT_test1",
"service": "ECS",
"eventScopeCode": "ACCOUNT_SPECIFIC",
"communicationId": "7988399e2e6fb0b905ddc88e0e2de1fd17e4c9fa60349577446d95a18EXAMPLE",
"lastUpdatedTime": "Wed, 16 Aug 2023 23:18:52 GMT",
"eventRegion": "us-east-1",
"eventTypeCode": "AWS_ECS_TASK_PATCHING_RETIREMENT",
"eventTypeCategory": "scheduledChange",
"startTime": "Wed, 16 Aug 2023 23:18:51 GMT",
"endTime": "Fri, 18 Aug 2023 23:18:51 GMT",
"eventDescription": [
{
"language": "en_US",
"latestDescription": "\\nA software update has been deployed to Fargate which includes CVE patches or other critical patches. No action is required on your part. All new tasks launched automatically uses the latest software version. For existing tasks, your tasks need to be restarted in order for these updates to apply. Your tasks running as part of the following ECS Services will be automatically updated beginning Wed, 16 Aug 2023 23:18:51 GMT.\\n\\nAfter Wed, 16 Aug 2023 23:18:51 GMT, the ECS scheduler will gradually replace these tasks, respecting the deployment settings for your service. Typically, services should see little to no interruption during the update and no action is required. When AWS stops tasks, AWS uses the minimum healthy percent (1) and launches a new task in an attempt to maintain the desired count for the service. By default, the minimum healthy percent of a service is 100 percent, so a new task is started first before a task is stopped. Service tasks are routinely replaced in the same way when you scale the service or deploy configuration changes or deploy task definition revisions. If you would like to control the timing of this restart you can update the service before Wed, 16 Aug 2023 23:18:51 GMT, by running the update-service command from the ECS command-line interface specifying force-new-deployment for services using Rolling update deployment type. For example:\\n\\n$ aws ecs update-service -service service_name \\\n--cluster cluster_name -force-new-deployment\\n\\nFor services using Blue/Green deployment type with AWS CodeDeploy:\\nPlease refer to create-deployment document (2) and create new deployment using same task definition revision.\\n\\nFor further details on ECS deployment types, please refer to ECS Deployment Developer Guide (1).\\nFor further details on Fargate's update process, please refer to the AWS Fargate User Guide (3).\\nIf you have any questions or concerns, please contact AWS Support (4).\\n\\n(1) https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html\\n(2) https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html\\n(3) https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-maintenance.html\\n(4) https://aws.amazon.com/support\\n\\nA list of your affected resources(s) can be found in the 'Affected resources' tab in the 'Cluster/ Service' format in the AWS Health Dashboard. \\n\\n"
}
],
"affectedEntities": [
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c23333"
},
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c25555"
}
}
]
}
}
```
+ E メール
AWS アカウント ID に対して登録された E メールアドレスに E メールが送信されます。
タスク廃止の準備を行う方法については、「[Amazon ECS での AWS Fargate タスク廃止に備える](prepare-task-retirement.md)」を参照してください。
## タスク廃止をオプトアウトすることはできますか?
いいえ。AWS の責任共有モデルの一環として、AWS は AWS Fargate の基盤となるインフラストラクチャの管理と維持に対する責任を担います。これには、セキュリティと安定性を確保するための定期的なプラットフォーム更新の実施が含まれます。これらの更新は AWS が自動的に適用するため、お客様がオプトアウトすることはできません。これは、EC2 インスタンスでワークロードを実行する代わりに AWS Fargate を使用するときの主なメリットであり、基盤となるプラットフォームを維持する責任は AWS が担います。このモデルは、インフラストラクチャのメンテナンスではなく、アプリケーションに集中することを可能にします。AWS は、これらのプラットフォーム更新を自動的に適用することによって、お客様からのアクションを必要とすることなく、Fargate 環境を最新かつセキュアに保つことができます。これは、Fargate でワークロードを実行するための、セキュアで信頼性が高いコンテナ化された環境の提供に役立ちます。
## 他の AWS サービスを通じてタスク終了通知を受け取ることはできますか?
AWS は、タスク終了通知を、Health Dashboard および AWS アカウント の主要メール連絡先に送信します。Health Dashboard は、EventBridge を含む他の AWS サービスとのさまざまな統合を提供します。EventBridge を使用して、通知の可視性を自動化できます（たとえば、メッセージを ChatOps ツールに転送するなど）。詳細については、「[ソリューションの概要: タスク廃止通知の取得](https://aws.amazon.com/blogs/containers/improving-operational-visibility-with-aws-fargate-task-retirement-notifications/)」を参照してください。
## タスクの廃止はスケジュールされた後に変更できますか?
いいえ。スケジュールはタスク廃止の待機時間 (デフォルトで 7 日間) に基づいています。さらに時間が必要な場合は、待機期間を 14 日間に設定することもできます。詳細については、「[ステップ 2: タスク廃止通知をキャプチャしてチームに警告し、措置を講じる](prepare-task-retirement.md#prepare-task-retirement-capture-task-events)」を参照してください。
2025 年 12 月 18 日より、Amazon ECS で Fargate タスク向けの [Amazon EC2 イベントウィンドウ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html)を設定できるようになりました。業務時間中の中断を避けるためにタスク廃止を週末にスケジュールするなど、廃止のタイミングを正確に制御する必要がある場合は、タスク、サービス、またはクラスターに Amazon EC2 イベントウィンドウを設定できます。「[ステップ 1: タスクの待機時間を設定、または Amazon EC2 イベントウィンドウを使用する](prepare-task-retirement.md#prepare-task-retirement-set-time)」を参照してください。この設定の変更は、今後スケジュールされる廃止に適用されます。現在予定されている廃止には影響しません。また、Fargate タスクに Amazon EC2 イベントウィンドウを設定するときは、このウィンドウがタスク廃止の待機時間設定に優先します。ご不明な点がある場合は、サポート までお問い合わせください。
## Amazon ECS はサービスの一部であるタスクをどのように処理しますか?
サービスタスクについては、AWS よりも前にこれらのタスクを置き換える場合を除き、タスク廃止に対応するための措置を講じる必要はありません。Amazon ECS スケジューラは、タスクを停止する際、最小正常稼働率を使用して新しいタスクを起動し、サービスに必要とされる数を維持しようとします。Fargate のタスク廃止による影響を最小限に抑えるには、Amazon ECS のベストプラクティスに従ってワークロードをデプロイする必要があります。例えば、ウェブまたは API サーバーなど、Amazon ECS サービスとしてステートレスアプリケーションをデプロイする場合、お客様は複数のタスクレプリカをデプロイして、minimumHealthyPercent を 100% に設定する必要があります。サービスの最小ヘルス率はデフォルトで 100% です。そのため、Fargate が廃止タスクを開始すると、Amazon ECS はまず新しいタスクをスケジュールし、それが実行されるのを待ってから、古いタスクを廃止します。サービスタスクは、サービスをスケールする、設定変更をデプロイする、またはタスク定義リビジョンをデプロイするときと同じ方法で、タスク廃止の一環として定期的に置き換えられます。タスク廃止プロセスへの準備を行うには、「[Amazon ECS での AWS Fargate タスク廃止に備える](prepare-task-retirement.md)」を参照してください。
## Amazon ECS はスタンドアロンタスクを自動的に処理できますか?
いいえ。AWS は、`RunTask` が開始したスタンドアロンタスク、スケジュールされたタスク (EventBridge Scheduler の使用など)、AWS Batch、AWS Step Functions に対する交換タスクを作成できません。Amazon ECS はサービスの一部であるタスクのみを管理します。
## タスク廃止中のサービス可用性のトラブルシューティング
タスクの廃止中に Amazon ECS が代替タスクを開始できない場合、サービスの可用性に影響が出る可能性があります。これは、次のような誤ったユーザー設定が原因で発生する可能性があります。
+ IAM ロールが欠落しているか、正しく設定されていない
+ ターゲットサブネットの容量不足
+ セキュリティグループの設定ミス
+ タスク定義エラー
Amazon ECS が代替タスクを起動できない場合、廃止されたタスクは代替されずに停止され、その結果、サービスの使用可能な容量が減少し、サービスの中断を引き起こす可能性があります。サービスのタスク数と Amazon CloudWatch メトリクスをモニタリングして、廃止イベント中に代替タスクが正常に起動されることを確認します。
# Amazon ECS での AWS Fargate タスク廃止に備える
タスク廃止への準備を行うには、以下の手順を実行します。
1. タスク廃止の待機期間を設定するか、Amazon EC2 イベントウィンドウを使用します。
1. タスク廃止通知をキャプチャして、チームメンバーに通知します。
1. 強制デプロイオプションでサービスを更新することにより、すべてのサービスのタスクが最新のプラットフォームリビジョンで実行されるようにすることができます。この手順は省略可能です。
## ステップ 1: タスクの待機時間を設定、または Amazon EC2 イベントウィンドウを使用する
Fargate がタスク廃止を開始する時刻の設定には、`fargateTaskRetirementWaitPeriod` と `fargateEventWindows` の 2 つのアカウント設定オプションがあります。
**fargateTaskRetirementWaitPeriod アカウント設定の使用**
Fargate がタスク廃止を開始する時間を設定できます。デフォルトの待機時間は 7 日間です。アップデートをすぐに適用する必要があるワークロードの場合は、即時設定 (`0`) を選択します。これより長い時間が必要な場合は、`7` 日または `14` 日オプションを設定します。
新しいプラットフォームバージョンのリビジョンを早く取得できるように、待機時間を短くすることをお勧めします。
待機時間を設定するには、ルートユーザーまたは管理者ユーザーで `put-account-setting-default` または `put-account-setting` を実行します。`fargateTaskRetirementWaitPeriod` オプションを `name` に使用し、`value` オプションを次のいずれかの値に設定します。
+ `0` - AWS から通知が送信され、影響を受けたタスクが直ちに廃止されます。
+ `7` - AWS から通知が送信され、7 日間待機してから、影響を受けたタスクの廃止が開始されます。これがデフォルトです。
+ `14` - AWS から通知が送信され、14 日間待機してから、影響を受けたタスクの廃止が開始されます。
詳細については、「Amazon Elastic Container Service API リファレンス」の「[put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)」と「[put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)」を参照してください。
**fargateEventWindows アカウント設定の使用**
2025 年 12 月 18 日より、Amazon ECS で Fargate タスク向けの [Amazon EC2 イベントウィンドウ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html)を設定できるようになりました。業務時間中の中断を避けるためにタスク廃止を週末にスケジュールするなど、廃止のタイミングを正確に制御する必要がある場合は、タスク、サービス、またはクラスターに Amazon EC2 イベントウィンドウを設定できます。
イベントウィンドウを使用する場合、Fargate は、ユーザーが開始したアクション、または基盤ハードウェアの劣化などの重大な正常性イベントによってタスクが停止された場合を除き、タスクが次に使用可能なウィンドウ内で少なくとも 3 日間実行されてから廃止されるようにします。
`fargateEventWindows` アカウント設定を `enabled` に設定します。`put-account-setting-default` API または `put-account-setting` API のいずれかをルートユーザーまたは管理者ユーザーとして使用できます。
各 Amazon EC2 イベントウィンドウの時間枠は少なくとも週に 4 時間 (各時間範囲は少なくとも 2 時間) にする必要があります。大規模なクラスターやサービスの場合は、長時間 (8 時間以上) のイベントウィンドウ、または時間範囲がより頻繁に実施される (少なくとも 3 日に 1 度) イベントウィンドウを設定することが推奨されます。Amazon EC2 イベントウィンドウの考慮事項については、[ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html#event-windows-considerations)で詳細を確認できます。AWS Fargate は、ユーザーが開始したアクション、または基盤ハードウェアの劣化などの重大な正常性イベントによってタスクが停止された場合を除き、タスクが少なくとも 3 日間実行されてから廃止されるようにします。
**重要**
イベントウィンドウ内でのタスクの置き換えはベストエフォートです。イベントウィンドウ外でタスクが廃止されていることに気付いた場合は、時間を延長する (8 時間以上) か、頻度を増やす (少なくとも 3 日に 1 度) ことを検討してください。
Amazon EC2 イベントウィンドウを Fargate タスクの廃止に適用する:
+ `fargateEventWindows` アカウント設定を `enabled` に設定します。`put-account-setting-default` API または `put-account-setting` API のいずれかをルートユーザーまたは管理者ユーザーとして使用できます。これは、Fargate タスクに Amazon EC2 イベントウィンドウ機能を使用するための 1 回限りの有効化であることに注意してください。
+ AWS コンソールまたは AWS CLI を使用して Amazon EC2 イベントウィンドウを作成します。CLI を使用してイベントウィンドウを作成するには、時間範囲または cron 式を設定した EC2 `create-instance-event-window` API を使用します。レスポンス内の `InstanceEventWindowId` を記録しておきます。
```
aws ec2 create-instance-event-window \
--time-range StartWeekDay=monday,StartHour=2,EndWeekDay=wednesday,EndHour=8 \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
また、EC2 イベントウィンドウの作成時には、cron 式を使用することも可能です。
```
aws ec2 create-instance-event-window \
--cron-expression "* 21-23 * * 2,3" \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
+ その後、EC2 `associate-instance-event-window` API を使用して、アカウント内の特定のサービス、クラスター、またはすべてのタスクにイベントウィンドウを関連付けることができます。
+ ECS サービスタスクの場合
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=your-service-arn}]"
```
+ ECS クラスターの場合
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=your-cluster-arn}]"
```
+ イベントウィンドウをアカウント内のすべてのタスクに関連付ける
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]"
```
キーと値のペアを複数使用して、イベントウィンドウを複数のサービスまたはクラスターに関連付けることができます。
Fargate は、各タスクのイベントウィンドウを次の順序で選択します。
+ タスクのサービスに関連付けられたイベントウィンドウがある場合は、そのウィンドウが使用されます。これは、スタンドアロンタスクまたはアンマネージドタスクには適用されません。
+ タスクのクラスターに関連付けられたイベントウィンドウがある場合は、そのウィンドウが使用されます。
+ すべての Fargate タスクに設定されたイベントウィンドウがある場合は、そのウィンドウが使用されます。
+ `fargateTaskRetirementWaitPeriod` 設定は、タスクに一致するイベントウィンドウがない場合に使用されます。
**Fargate タスクのメンテナンス用イベントウィンドウの設定**
異なる可用性要件を持つ複数の ECS サービスが Fargate で実行されている状況を考えてみましょう。こうした状況では、タスクの廃止を正確に制御する必要があります。次のように複数のイベントウィンドウを設定できます。
+ **すべての Fargate タスク向けのデフォルトメンテナンス**: オフピーク時間 (毎日午前 12 時から午前 4 時) に定期的なメンテナンス用のイベントウィンドウを作成し、` aws:ecs:fargateTask` タグを使用してすべての Fargate タスクに関連付けます。
+ **開発クラスター向けの週末限定メンテナンス**: 週末の中断に対応できるサービスが含まれる開発クラスターには、24 時間の週末ウィンドウ (土曜日と日曜日の終日) を作成し、`aws:ecs:clusterArn` タグとクラスター ARN を使用してクラスターに関連付けます。
+ **ミッションクリティカルなサービス向けの制限付きウィンドウ**: 平日に高いアップタイムを維持する必要があるミッションクリティカルな決済処理サービスの場合は、メンテナンスを週末の早朝時間 (土曜日と日曜日の午前12 時から午前 4 時) に制限し、`aws:ecs:serviceArn` タグとサービス ARN を使用して特定のサービスに関連付けます。
この設定では、決済サービスが特定の週末限定ウィンドウ、開発クラスターのサービスとタスクが週末の 24 時間ウィンドウ、他のすべての Fargate タスクがデフォルトの日次メンテナンスウィンドウを使用します。
詳細については、「Amazon Elastic Container Service API リファレンス」の「[put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)」と「[put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)」を参照してください。
## ステップ 2: タスク廃止通知をキャプチャしてチームに警告し、措置を講じる
近日実施されるタスク廃止があるときは、AWS が AWS Health ダッシュボード、および AWS アカウント の主要 E メール連絡先にタスク廃止通知を送信します。AWS Health ダッシュボードは、Amazon EventBridge を含めた他の AWS サービスとの統合を多数提供しています。EventBridge を使用して、ChatOps ツールにメッセージを転送して次回の廃止の視認性を高めるなど、タスク廃止通知からオートメーションを構築することができます。AWS HealthAware は、AWS Health ダッシュボードの能力と、組織全体に通知を配布する方法を説明するリソースです。タスク廃止通知は、Slack などのチャットアプリケーションに転送できます。
以下の図は、このソリューションの概要です。
![\[Fargate のタスク廃止通知をキャプチャする Fargate ソリューションを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/fargate-task-retirement-solution.png)
以下は、ソリューションの詳細情報です。
+ Fargate がタスク廃止通知を AWS Health ダッシュボードに送信します。
+ AWS Health ダッシュボードが AWS アカウント の主要 E メール連絡先に E メールを送信し、EventBridge に通知します。
+ EventBridge には、廃止通知をキャプチャするルールがあります。
このルールは、イベント詳細タイプが `"AWS Health Event" and the Event Detail Type Code: "AWS_ECS_TASK_PATCHING_RETIREMENT"` のイベントを探します。
+ ルールが、Slack Incoming Webhook を使用して情報を Slack に転送する Lambda 関数をトリガーします。詳細については、「[Incoming Webhooks](https://slack.com/marketplace/A0F7XDUAZ-incoming-webhooks)」を参照してください。
コード例については、Github で「[Capturing AWS Fargate Task Retirement Notifications](https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications/tree/main)」を参照してください。
## ステップ 3: タスクの置き換えを制御する
タスク廃止の正確なタイミングを制御することはできませんが、待機時間を定義することは可能です。独自のスケジュールに従ってタスクの置き換えを制御する場合は、タスク廃止通知をキャプチャして、タスク廃止の日付を把握することから始めます。その後、サービスを再度デプロイして代替タスクを起動することができます。スタンドアロンタスクも同様に置き換えます。ローリングデプロイを使用するサービスの場合は、廃止の開始時刻の前に、`force-deployment` オプションがある `update-service` を使用してサービスを更新します。
次の `update-service` 例では、`force-deployment` オプションを使用しています。
```
aws ecs update-service —-service service_name \
--cluster cluster_name \
--force-new-deployment
```
ブルー/グリーンデプロイを使用するサービスの場合は、AWS CodeDeploy で新しいデプロイメントを作成する必要があります。デプロイを作成する方法については、*AWS Command Line Interfaceリファレンス*の「[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)」を参照してください。
# AWS Fargate で使用する Amazon ECS でサポートされているリージョン
次の表を参照すると、AWS Fargate 上の Linux コンテナおよび AWS Fargate 上の Windows コンテナのリージョンサポートを確認できます。
## AWS Fargate 上の Linux コンテナ
AWS Fargate の Amazon ECS Linux コンテナは次の AWS リージョン でサポートされています。該当する場合、サポートされているアベイラビリティーゾーン ID が記載されています。
| リージョン名 | リージョン |
| --- | --- |
| 米国東部 (オハイオ) | us-east-2 |
| 米国東部 (バージニア北部) | us–east–1 |
| 米国西部 (北カリフォルニア) | us-west-1 (`usw1-az1` &`usw1-az3`のみ) |
| 米国西部 (オレゴン) | us-west-2 |
| カナダ (中部) | ca-central-1 |
| カナダ西部 (カルガリー) | ca-west-1 |
| メキシコ (中部) | mx-central-1 |
| アフリカ (ケープタウン) | af-south-1 |
| アジアパシフィック (香港) | ap-east-1 |
| アジアパシフィック (ムンバイ) | ap-south-1 |
| アジアパシフィック (東京) | ap-northeast-1 (`apne1-az1`、`apne1-az2`、&`apne1-az4`のみ) |
| アジアパシフィック (ソウル) | ap-northeast-2 |
| アジアパシフィック (大阪) | ap-northeast-3 |
| アジアパシフィック (ハイデラバード) | ap-south-2 |
| アジアパシフィック (シンガポール) | ap-southeast-1 |
| アジアパシフィック (シドニー) | ap-southeast-2 |
| アジアパシフィック (タイ) | ap-southeast-7 |
| アジアパシフィック (ジャカルタ) | ap-southeast-3 |
| アジアパシフィック (メルボルン) | ap-southeast-4 |
| アジアパシフィック (マレーシア) | ap-southeast-5 |
| カナダ (中部) | ca-central-1 |
| カナダ西部 (カルガリー) | ca-west-1 |
| 中国 (北京) | cn-north-1 (`cnn1-az1` &`cnn1-az2`のみ) |
| 中国 (寧夏) | cn-northwest-1 |
| 欧州 (フランクフルト) | eu-central-1 |
| 欧州 (チューリッヒ) | eu-central-2 |
| 欧州 (アイルランド) | eu-west-1 |
| 欧州 (ロンドン) | eu-west-2 |
| 欧州 (パリ) | eu-west-3 |
| 欧州 (ミラノ) | eu-south-1 |
| 欧州 (スペイン) | eu-south-2 |
| 欧州 (ストックホルム) | eu-north-1 |
| 南米 (サンパウロ) | sa-east-1 |
| イスラエル (テルアビブ) | il-central-1 |
| 中東 (バーレーン) | me-south-1 |
| 中東 (アラブ首長国連邦) | me-central-1 |
| AWS GovCloud (米国東部) | us-gov-east-1 |
| AWS GovCloud (米国西部) | us-gov-west-1 |
## AWS Fargate 上の Windows コンテナ
AWS Fargate の Amazon ECS Windows コンテナは次の AWS リージョン でサポートされています。該当する場合、サポートされているアベイラビリティーゾーン ID が記載されています。
| リージョン名 | リージョン |
| --- | --- |
| 米国東部 (オハイオ) | us-east-2 |
| 米国東部 (バージニア北部) | us-east-1 (`use1-az1`、`use1-az2`、`use1-az4`、`use1-az5`、& `use1-az6` のみ) |
| 米国西部 (北カリフォルニア) | us-west-1 (`usw1-az1` &`usw1-az3`のみ) |
| 米国西部 (オレゴン) | us-west-2 |
| アフリカ (ケープタウン) | af-south-1 |
| アジアパシフィック (香港) | ap-east-1 |
| アジアパシフィック (ムンバイ) | ap-south-1 |
| アジアパシフィック (ハイデラバード) | ap-south-2 |
| アジアパシフィック (大阪) | ap-northeast-3 |
| アジアパシフィック (ソウル) | ap-northeast-2 |
| アジアパシフィック (シンガポール) | ap-southeast-1 |
| アジアパシフィック (シドニー) | ap-southeast-2 |
| アジアパシフィック (メルボルン) | ap-southeast-4 |
| アジアパシフィック (マレーシア) | ap-southeast-5 |
| アジアパシフィック (東京) | ap-northeast-1 (`apne1-az1`、`apne1-az2`、&`apne1-az4`のみ) |
| カナダ (中部) | ca-central-1 (`cac1-az1` &`cac1-az2`のみ) |
| カナダ西部 (カルガリー) | ca-west-1 |
| 中国 (北京) | cn-north-1 (`cnn1-az1` &`cnn1-az2`のみ) |
| 中国 (寧夏) | cn-northwest-1 |
| 欧州 (フランクフルト) | eu-central-1 |
| 欧州 (チューリッヒ) | eu-central-2 |
| 欧州 (アイルランド) | eu-west-1 |
| 欧州 (ロンドン) | eu-west-2 |
| 欧州 (パリ) | eu-west-3 |
| 欧州 (ミラノ) | eu-south-1 |
| 欧州 (スペイン) | eu-south-2 |
| 欧州 (ストックホルム) | eu-north-1 |
| 南米 (サンパウロ) | sa-east-1 |
| イスラエル (テルアビブ) | il-central-1 |
| 中東 (アラブ首長国連邦) | me-central-1 |
| 中東 (バーレーン) | me-south-1 |