# Amazon ECS のソリューションの構築
アプリケーションを*コンテナ*上で実行できるように設計する必要があります。コンテナとは、ソフトウェアアプリケーションの実行に必要なものをすべて保持する、標準化されたソフトウェア開発の単位です。これには、関連するコード、ランタイム、システムツール、およびシステムライブラリが含まれます。コンテナは、*イメージ*と呼ばれる読み取り専用テンプレートから作成されます。コンテナイメージは、アプリケーションとその依存関係を含む静的アーティファクトです。イメージは通常 Dockerfile から構築されます。Dockerfile は、コンテナを構築するための手順を含むプレーンテキストファイルです。これらのイメージは、Amazon ECR など、構築された後にダウンロード可能な場所である*レジストリ*に保存されます。
イメージを作成して保存した後、Amazon ECS のタスク定義を作成します。*タスク定義*はアプリケーションのブループリントです。これは、アプリケーションを形成するパラメータと 1 つ以上のコンテナを記述する JSON 形式のテキストファイルです。例えば、オペレーティングシステムのパラメータ、使用するコンテナ、アプリケーションで開くポート、タスクのコンテナで使用するデータボリュームなどの指定に使用できます。タスク定義で使用できる特定のパラメータは、お客様の特定のアプリケーションのニーズによって異なります。
タスク定義を定義したら、それをサービスまたはタスクとしてクラスターにデプロイします。*クラスター*は、クラスターに登録されているキャパシティインフラストラクチャ上で実行されるタスクまたはサービスを論理的にグループ化したものです。
タスクはクラスター内のタスク定義のインスタンス化です。スタンドアロンタスクを実行することもできますし、サービスの一部としてタスクを実行することもできます。Amazon ECS *サービス*を使用すると、Amazon ECS クラスターで必要な数のタスクを同時に実行して維持できます。仕組みとしては、タスクがいずれかの理由で失敗または停止した場合に、Amazon ECS サービススケジューラがタスク定義に基づいて別のインスタンスを起動することによって動作します。これは、それを置き換え、サービス内の必要な数のタスクを維持するために行われます。
*コンテナエージェント*は Amazon ECS クラスター内の各コンテナインスタンス上で実行されます。エージェントは、現在実行中のタスクとリソースのコンテナの使用率に関する情報を Amazon ECS に送信します。Amazon ECS からのリクエストを受信するたびに、タスクを開始および停止します。
タスクまたはサービスをデプロイしたら、次のいずれかのツールを使用してデプロイとアプリケーションを監視できます。
+ CloudWatch
+ Runtime Monitoring
## Capacity
容量は、コンテナが実行されるインフラストラクチャです。Amazon ECS では、クラスター用に 3 つのインフラストラクチャタイプが用意されています。
+ Amazon ECS マネージドインスタンス – AWS はプロビジョニング、パッチ適用、スケーリングなど、アカウントで動作している基盤となる Amazon EC2 インスタンスを完全に管理します。このオプションを使用すると、パフォーマンス、コスト効率、運用のシンプルさについて最適なバランスが得られます。
+ サーバーレス (Fargate) – インフラストラクチャを管理せずに、タスクで使用されるリソースに対してのみ支払います。可変ワークロードやすぐに始めたいときに最適です。
+ Amazon EC2 インスタンス – 基盤となる Amazon EC2 インスタンスの管理、例えばインスタンスの選択、設定、メンテナンスなどを直接行います。
Amazon ECS マネージドインスタンスは、次のような場合に使用します。
+ 基盤となるインフラストラクチャをより細かく制御できる Fargate のシンプルさを求めている場合。
+ 予測可能なパフォーマンスとコスト最適化が必要な場合。
+ AWS を使用して、柔軟に対応しながらインフラストラクチャを管理したい場合。
Fargate は、次のような場合に使用します。
+ インフラストラクチャを管理せずにアプリケーションに集中したい場合。
+ 可変または予測不可能なワークロードがある場合。
+ コンテナの使用を開始していて、シンプルなデプロイオプションが必要な場合。
Amazon EC2 インスタンスは、次のような場合に使用します。
+ 特殊なハードウェア要件 (GPU アクセラレーション、高性能コンピューティング) が必要な場合。
+ キャパシティ予約または特定のインスタンスタイプが必要な場合。
+ 特権機能またはカスタム AMI が必要な場合。
クラスターを作成する際、インフラストラクチャを指定します。タスク定義を登録する際、インフラストラクチャタイプも指定します。タスク定義では、インフラストラクチャを「起動タイプ」と呼びます。キャパシティプロバイダーを使用することもできます。
## サービスエンドポイント
サービスエンドポイントは、インターネットプロトコルバージョン 4 (IPv4) またはインターネットプロトコルバージョン 6 (IPv6) を使用してプログラムでサービスに接続するために使用する Amazon ECS のエントリポイントの URL です。デフォルトでは、Amazon ECS にプログラムで接続するために行うリクエストは、IPv4 リクエストのみをサポートするサービスエンドポイントを使用します。IPv4 と IPv6 リクエストのどちらからでもプログラムで Amazon ECS に接続したい場合は、デュアルスタックエンドポイントを使用できます。デュアルスタックのエンドポイントの詳細については、「[Amazon ECS デュアルスタックエンドポイントの使用](dual-stack-endpoint.md)」を参照してください。
## ネットワーク
AWS リソースはサブネットに作成されます。EC2 インスタンスを使用する場合、Amazon ECS はクラスターの作成時に指定したサブネットでインスタンスを起動します。タスクはインスタンスのサブネットで実行されます。Fargate またはオンプレミス仮想マシンの場合は、タスクを実行するとき、またはサービスを作成するときにサブネットを指定します。
アプリケーションに応じて、サブネットはプライベートサブネットでもパブリックサブネットでもよく、サブネットは次の AWS リソースのどれにあってもかまいません。
+ アベイラビリティーゾーン
+ ローカルゾーン
+ Wavelength Zone
+ AWS リージョン
+ AWS Outposts
詳細については「[共有サブネット、Local Zones、および Wavelength Zones の Amazon ECS アプリケーション](cluster-regions-zones.md)」または「[AWS OutpostsのAmazon Elastic Container Service](using-outposts.md)」を参照してください。
次のいずれかの方法を使用して、アプリケーションをインターネットに接続できます。
+ インターネットゲートウェイを持つパブリックサブネット
大量の帯域幅や最小のレイテンシーを必要とするパブリックアプリケーションがある場合は、パブリックサブネットを使用してください。該当するシナリオには、ビデオストリーミングやゲームサービスが含まれます。
+ NAT ゲートウェイを持つプライベートサブネット
外部からの直接アクセスからコンテナを保護するには、プライベートサブネットを使用してください。該当するシナリオには、支払い処理システムや、ユーザーデータとパスワードを格納するコンテナなどがあります。
+ AWS PrivateLink
トラフィックをパブリックインターネットに公開することのない、VPC、AWS サービス、オンプレミスネットワークの間のプライベート接続を提供するには、AWS PrivateLink を使用してください。
## 機能アクセス
Amazon ECS アカウント設定を使用して、次の機能にアクセスできます。
+ Container Insights
CloudWatch Container Insights は、コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集、集約、要約します。このメトリクスには、CPU、メモリ、ディスク、ネットワークなどのリソース使用率が含まれます。
+ `awsvpc` トランキング
特定の EC2 インスタンスタイプでは、新しく起動したコンテナインスタンスで追加のネットワークインターフェイス (ENI) を使用できます。
+ タグ付け認可
ユーザーには、リソースを作成するアクションの許可が必要です (`ecsCreateCluster` など)。リソース作成アクションでタグが指定されている場合、AWS は `ecs:TagResource` アクションに対して追加の認可を実行して、ユーザーまたはロールがタグを作成するための許可を持っているかどうかを確認します。
+ Fargate FIPS-140 コンプライアンス
Fargate は、機密情報を保護する暗号モジュールのセキュリティ要件を指定する連邦情報処理標準 (FIPS-140) をサポートしています。これは現在の米国およびカナダの政府標準であり、Federal Information Security Management Act (FISMA) または Federal Risk and Authorization Management Program (FedRAMP) への準拠が要求されるシステムに適用されます。
+ Fargate タスクの廃止時間の変更
Fargate タスクが廃止されるまでの待機時間を設定できます。
+ デュアルスタック VPC
タスクが IPv4、IPv6、またはその両方を介して通信できるようにします。
+ Amazon リソースネーム (ARN) 形式
タグ付け認可などの特定の機能には、新しい Amazon リソースネーム (ARN) 形式が必要です。
詳細については、「[アカウント設定による Amazon ECS 機能へのアクセス](ecs-account-settings.md)」を参照してください。
## IAM ロール
IAM ロール は、特定の許可があり、アカウントで作成できるもう 1 つの IAM アイデンティティです。Amazon ECS では、コンテナやサービスなどの Amazon ECS リソースにアクセス許可を付与するロールを作成できます。
Amazon ECS の一部の機能にはロールが必要です。詳細については、「[Amazon ECS の IAM ロール](ecs-iam-role-overview.md)」を参照してください。
## ログ記録
ログ記録およびモニタリングは、Amazon ECS ワークロードの信頼性、可用性、パフォーマンスを維持する上で重要な要素です。以下のオプションが利用できます。
+ Amazon CloudWatch ログ- ログを Amazon CloudWatch にルーティングする
+ Amazon ECS 用 FireLens - ログを AWS サービスまたは AWS Partner Network の宛先にルーティングして、ログの保存と分析を行います。AWS Partner Network は、プログラム、専門知識、リソースを活用して顧客向けサービスの構築、マーケティング、販売を行うパートナーのグローバルコミュニティです。
## コンテナイメージのベストプラクティス
Amazon ECS コンテナイメージの主な原則は次のとおりです。
+ イメージにすべての依存関係を含める
+ コンテナごとに 1 つのプロセスを実行する
+ 正常なシャットダウンのために `SIGTERM` を使用する
+ ログを `stdout`と `stderr` に書き込む
+ 本番環境では `latest` を避け、一意のタグを使用する
# Amazon ECS の起動タイプとキャパシティプロバイダー
Amazon ECS には、ワークロードのキャパシティを設定するための 2 つの方法があります。起動タイプかキャパシティプロバイダーを使用できます。起動タイプには、EC2、Fargate、External があります。キャパシティプロバイダーは、キャパシティ管理のための高い柔軟性と高度な機能を備えています。Fargate および Fargate スポットキャパシティプロバイダーを使用するサーバーレスコンピューティング、Auto Scaling グループキャパシティプロバイダーを使用するセルフマネージド EC2 インスタンス、または Fargate のシンプルさと EC2 コンピューティングの柔軟性を組み合わせた Amazon ECS マネージドインスタンスキャパシティプロバイダーを使用するフルマネージドコンピューティングでワークロードを実行できます。キャパシティプロバイダーは、リソース割り当てをより適切に制御し、パフォーマンスとコストの両方を最適化することができます。従来の起動タイプと比較すると、ワークロードのキャパシティの設定のために推奨される方法です。キャパシティプロバイダーと起動タイプの違いを理解するために、以下を参考にしてください。
## ベストプラクティス
ベストプラクティスは以下のとおりです。
起動タイプを使用してインフラストラクチャの互換性を定義する
起動タイプでは、タスクとサービスを実行するインフラストラクチャを定義します。タスクを定義するときは、`RequiresCompatibilities` を指定して、タスクと互換性のある 1 つ以上の起動タイプを含めます。起動タイプとして、EC2、Fargate、External、Amazon ECS マネージドインスタンスを使用できます。起動タイプを使用してタスクまたはサービスを実行することもできますが、起動タイプはタスク定義での互換性の定義のみに使用し、タスクやサービスの起動にはキャパシティプロバイダーを使用することをお勧めします。タスクの互換性を定義には、1 つ以上の起動タイプを選択することができます。
キャパシティプロバイダーを使用してコンピューティングキャパシティーを設定する
タスクまたはサービスを起動するときは、キャパシティプロバイダー戦略を設定します。Amazon ECS でサポートされているキャパシティプロバイダーは、Fargate および FARGATE\$1SPOT、セルフマネージド EC2 インスタンス用の Auto Scaling グループ、Amazon ECS マネージドインスタンスです。スポットフリートはキャパシティプロバイダーとしてのみ使用でき、起動タイプとしては使用できないことに注意してください。クラスター内には、Amazon ECS マネージドインスタンスキャパシティプロバイダーまたは Amazon EC2 Auto Scaling グループキャパシティプロバイダーを 1 つ、または複数作成できます。Fargate および Fargate Spot キャパシティプロバイダーは、すべてのクラスターで Amazon ECS によって作成および管理されるため、作成する必要はありません。クラスターではすべてのタイプのキャパシティプロバイダーを組み合わせることができますが、キャパシティプロバイダー戦略では異なるタイプのキャパシティプロバイダーを組み合わせることはできません。
サービスのキャパシティを更新する
サービスのキャパシティプロバイダー戦略を更新するだけで、サービスをコンピューティングタイプ間で移動させることができます。
## サービスのミュータビリティ
Amazon ECS は、異なるキャパシティプロバイダー間のサービスの更新をサポートしています。そのため、次のことが可能になります。
+ 起動タイプからキャパシティプロバイダーへのシームレスな更新
+ 異なるタイプのキャパシティプロバイダー間の移行
+ サービスの再作成なしでさまざまなコンピューティングオプションをテスト
以下に、プロセスの概要を示します。
1. タスク定義を更新する – 例えば、`requiresCompatibilities` にターゲットキャパシティプロバイダー (` MANAGED_INSTANCES` など) が含まれていることを確認します。
**注記**
タスク定義は、ターゲットキャパシティプロバイダーの互換性検証に合格する必要があります。タスク定義バージョンの `requiresCompatibilities` チェックが失敗した場合、`UpdateService` 呼び出しは失敗します。
1. キャパシティプロバイダーを作成する – カスタム Amazon EC2 Auto Scaling グループを使用する場合は、キャパシティプロバイダーを作成します。
1. サービスを更新する – 起動タイプの代わりにキャパシティプロバイダー戦略を使用するようにサービスを変更します。
1. デプロイを検証する – タスクが正常にデプロイされたことを確認します。
1. モニタリングして最適化する — 必要に応じてキャパシティプロバイダーの設定を調整します。
### キャパシティプロバイダーからキャパシティプロバイダー
キャパシティプロバイダーからキャパシティプロバイダーへの更新はすべてサポートされています。
+ Amazon EC2 Auto Scaling グループキャパシティプロバイダーから Amazon ECS マネージドインスタンス
+ Fargate キャパシティプロバイダーから Amazon ECS マネージドインスタンス
+ Amazon EC2 Auto Scaling グループキャパシティプロバイダーから Fargate キャパシティプロバイダー
+ Amazon ECS マネージドインスタンスから Fargate キャパシティプロバイダー
+ Fargate キャパシティプロバイダーから Amazon EC2 Auto Scaling グループキャパシティプロバイダー
+ Amazon ECS マネージドインスタンスから Amazon EC2 Auto Scaling グループキャパシティプロバイダー
### 起動タイプからキャパシティプロバイダー
起動タイプからキャパシティプロバイダーへの更新はすべてサポートされています。
+ EC2 起動タイプから Amazon ECS マネージドインスタンス
+ Fargate 起動タイプから Amazon ECS マネージドインスタンス
+ EC2 起動タイプから Fargate キャパシティプロバイダー
+ EC2 起動タイプから EC2 Auto Scaling グループキャパシティプロバイダー
+ Fargate 起動タイプから Amazon EC2 Auto Scaling グループキャパシティプロバイダー
+ Fargate 起動タイプから Fargate キャパシティプロバイダー
+ 外部起動タイプから Amazon ECS マネージドインスタンス
+ 外部起動タイプから Fargate キャパシティプロバイダー
+ 外部起動タイプから Amazon EC2 Auto Scaling グループキャパシティプロバイダー
### 起動タイプから起動タイプ
起動タイプから起動タイプへの更新はサポートされていません。
+ EC2 起動タイプから Fargate 起動タイプ (代わりに Fargate キャパシティプロバイダーを使用)
+ Fargate 起動タイプから EC2 起動タイプ (代わりに Amazon EC2 Auto Scaling グループキャパシティプロバイダーを使用)
起動タイプ間での移行の代わりに、機能の強化と将来の互換性の確保のために、同等のキャパシティプロバイダーに移行します。
**注記**
タスク定義は、ターゲットキャパシティプロバイダーの互換性検証に合格する必要があります。タスク定義バージョンの `requiresCompatibilities` チェックが失敗した場合、`UpdateService` 呼び出しは失敗します。
# Amazon ECS デュアルスタックエンドポイントの使用
Amazon ECS デュアルスタックエンドポイントは、インターネットプロトコルバージョン 4 (IPv4) およびインターネットプロトコルバージョン 6 (IPv6) を介した Amazon ECS へのリクエストをサポートします。すべての Amazon ECS エンドポイントのリストについては、「AWS 全般のリファレンス」の「[Amazon ECS のエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html)」を参照してください。
REST API を使用する場合、エンドポイント名 (URI) を使用して直接 Amazon ECS エンドポイントにアクセスします。Amazon ECS はリージョン固有のデュアルスタックエンドポイント名のみをサポートしており、名前の一部としてリージョンを指定する必要があります。
デュアルスタックエンドポイント名には、次の命名規則を使用します: `ecs.region.api.aws`。
AWS Command Line Interface (AWS CLI) や AWS SDK を使用している場合、パラメータまたはフラグを使ってデュアルスタックエンドポイントに変更できます。設定ファイル内の Amazon ECS エンドポイントをオーバーライドして、デュアルスタックエンドポイントを直接指定することもできます。
以下のセクションでは、AWS CLI、AWS SDK、および REST API からデュアルスタックエンドポイントを使用する方法について説明します。
**Topics**
+ [AWS CLI からのデュアルスタックのエンドポイントの使用](#dual-stack-endpoints-cli)
+ [AWS SDK からデュアルスタックのエンドポイントを使用する](#dual-stack-endpoints-sdks)
+ [REST API からのデュアルスタックのエンドポイントの使用](#dual-stack-endpoints-examples-rest-api)
## AWS CLI からのデュアルスタックのエンドポイントの使用
このセクションでは、デュアルスタックのエンドポイントへリクエストするのに使用される AWS CLI コマンドの例を示します。AWS CLI のインストールまたは最新バージョンへのアップグレードについては、「*バージョン 2 向けの AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
デュアルスタックエンドポイントを使用する際には、AWS CLI の `config` ファイルの設定値 `use_dualstack_endpoint` を `true` に設定することで、`ecs` AWS CLI コマンドによるすべての Amazon ECS リクエストを指定されたリージョンのデュアルスタックエンドポイントに転送することができます。`--region` オプションを使用して `config` ファイルまたはコマンドでリージョンを指定します。AWS CLI の構成ファイルの詳細については、「*バージョン 2 向けの AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の構成および認証ファイル設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)」を参照してください。
特定の AWS CLI コマンドについてデュアルスタックエンドポイントを使用するには、次のいずれかの方法を使用できます。
+ 任意の `ecs` コマンドについて `--endpoint-url` パラメータを `https://ecs.aws-region.api.aws` もしくは `http://ecs.aws-region.api.aws` に設定することで、個別のコマンド単位でデュアルスタックエンドポイントを使用できます。
次のコマンド例では、使用可能なすべてのクラスターを一覧表示し、リクエストにデュアルスタックエンドポイントを使用しています。
```
$ aws ecs list-clusters --endpoint-url https://ecs.aws-region.api.aws
```
+ AWS Config ファイル内で別々のプロファイルを設定する。たとえば、`use_dualstack_endpoint` を `true` に設定するプロファイルと `use_dualstack_endpoint` を設定しないプロファイルを作成します。コマンドを実行する際には、デュアルスタックのエンドポイントを使用するかどうかによって、適切なプロファイルを指定します。
## AWS SDK からデュアルスタックのエンドポイントを使用する
このセクションでは、AWS SDK を使用してデュアルスタックのエンドポイントにアクセスする方法の例を示します。
------
#### [ AWS SDK for Java 2.x ]
次の例は、AWS SDK for Java 2.x を使用して `us-east-1` リージョンのデュアルスタックエンドポイントを指定する方法を示しています。
```
Region region = Region.US_EAST_1
EcsClient client = EcsClient.builder().region(region).dualstackEnabled(true).build();
```
------
#### [ AWS SDK for Go ]
次の例は、AWS SDK for Go を使用して `us-east-1` リージョンのデュアルスタックエンドポイントを指定する方法を示しています。
```
sess := session.Must(session.NewSession())
svc := ecs.New(sess, &aws.Config{
Region: aws.String(endpoints.UsEast1RegionID),
Endpoint: aws.String("https://ecs.us-east-1.api.aws")
})
```
------
詳細については、「*AWS SDK とツールリファレンスガイド*」の「[デュアルスタックおよび FIPS エンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)」を参照してください。
## REST API からのデュアルスタックのエンドポイントの使用
REST API を使用する場合、リクエスト内でデュアルスタックエンドポイントを指定することで、特定のデュアルスタックエンドポイントに直接アクセスできます。次の例では、デュアルスタックエンドポイントを使用して、`us-east-1` リージョン内のすべての Amazon ECS クラスターを一覧表示しています。
```
POST / HTTP/1.1
Host: ecs.us-east-1.api.aws
Accept-Encoding: identity
Content-Length: 2
X-Amz-Target: AmazonEC2ContainerServiceV20141113.ListClusters
X-Amz-Date: 20150429T170621Z
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{}
```
# 共有サブネット、Local Zones、および Wavelength Zones の Amazon ECS アプリケーション
Amazon ECS は、低レイテンシーまたはローカルデータ処理が必要な場合に、Local Zones、Wavelength Zone、および AWS Outposts を利用するワークロードをサポートします。
+ Local Zones を AWS リージョン の拡張に使用して、エンドユーザーにより近い複数の場所にリソースを配置できます。
+ Wavelength Zone を使用すると、5G デバイスやエンドユーザーに非常に低いレイテンシーを提供するアプリケーションを構築できます。Wavelength は標準の AWS コンピューティングおよびストレージサービスを通信事業者の 5G ネットワークのエッジにデプロイします。
+ AWS Outposts では、ネイティブの AWS のサービス、インフラストラクチャ、運用モデルをほぼすべてのデータセンター、コロケーションスペース、オンプレミスの施設で利用できます。
**重要**
AWS Fargate ワークロードの Amazon ECS は、現時点では、Local Zones、Wavelength Zone、または AWS Outposts ではサポートされていません。
ローカルゾーン、Wavelength ゾーン、AWS Outposts の違いについては、「AWS Wavelength のよくある質問」の「[低レイテンシーやローカルデータ処理を必要とするアプリケーションに、AWS Wavelength ゾーン、AWS ローカルゾーン、または AWS Outposts をいつ使用するとよいですか?](https://aws.amazon.com/wavelength/faqs/)」を参照してください。
## 共有サブネット
*VPC 共有*を使用して、同じ AWS Organizations 内でサブネットを他の AWS アカウントと共有できます。
EC2 には共有 VPC を使用できますが、次の点を考慮してください。
+ VPC サブネットの所有者は、参加者アカウントで Amazon ECS リソース用にサブネットを使用する前に、そのサブネットをそのアカウントに共有する必要があります。
+ VPC のデフォルトセキュリティグループは所有者に属しているため、コンテナインスタンスには VPC のデフォルトセキュリティグループを使用できません。また、参加者は、他の参加者または所有者が所有するセキュリティグループを使用してインスタンスを起動することはできません。
+ 共有サブネットでは、参加者と所有者がそれぞれのアカウント内のセキュリティグループを個別に管理します。サブネットの所有者は、参加者が作成したセキュリティグループを表示できますが、これらのグループに対してアクションを実行することはできません。サブネットの所有者がこれらのセキュリティグループの削除または変更を希望する場合は、セキュリティグループを作成した参加者がそのアクションを実行する必要があります。
+ 共有 VPC の所有者は、参加者が共有サブネット内に作成したクラスターを表示、更新、削除することはできません。これは、アカウントごとに異なるアクセス権を持つ VPC リソースに加えて適用されます。詳細については、「*Amazon VPC ユーザーガイド*」の「[所有者および参加者の責任と権限](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations)」を参照してください。
Fargate には共有 VPC を使用できますが、次の点を考慮してください。
+ VPC サブネットの所有者は、参加者アカウントで Amazon ECS リソース用にサブネットを使用する前に、そのサブネットをそのアカウントに共有する必要があります。
+ VPC のデフォルトセキュリティグループは所有者に属しているため、デフォルトのセキュリティグループを使用してサービスを作成したりタスクを実行したりすることはできません。また、参加者は、他の参加者または所有者が所有するセキュリティグループを使用してサービスを作成したりタスクを実行したりすることはできません。
+ 共有サブネットでは、参加者と所有者がそれぞれのアカウント内のセキュリティグループを個別に管理します。サブネットの所有者は、参加者が作成したセキュリティグループを表示できますが、これらのグループに対してアクションを実行することはできません。サブネットの所有者がこれらのセキュリティグループの削除または変更を希望する場合は、セキュリティグループを作成した参加者がそのアクションを実行する必要があります。
+ 共有 VPC の所有者は、参加者が共有サブネット内に作成したクラスターを表示、更新、削除することはできません。これは、アカウントごとに異なるアクセス権を持つ VPC リソースに加えて適用されます。詳細については、「*Amazon VPC ユーザーガイド*」の「[所有者および参加者の責任と権限](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations)」を参照してください。
VPC サブネット共有の詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC を他のアカウントと共有する](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations)」を参照してください。
## ローカルゾーン
*Local Zones* は、ユーザーに近い場所に位置する AWS リージョンの拡張です。Local Zones は、インターネットへの独自の接続を持ち、Direct Connect をサポートします。Local Zones で作成したリソースは、低いレイテンシーの通信をローカルユーザーに提供できます。詳細については、「[AWS ローカルゾーン](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)」を参照してください。
Local Zones を表すには、リージョンコードに続けて場所を示す識別子を使用します (例: `us-west-2-lax-1a`)。
Local Zones を使用するには、まずゾーンにオプトインする必要があります。オプトインしたら、Local Zones に Amazon VPC およびサブネットを作成する必要があります。
Amazon ECS クラスターとタスクに使用する Amazon EC2 インスタンス、Amazon FSx ファイルサーバー、Application Load Balancer を起動できます。
詳細については、*AWS ローカルゾーンユーザーガイド*の「[AWS ローカルゾーンとは](https://docs.aws.amazon.com/local-zones/latest/ug/what-is-aws-local-zones.html)」を参照してください。
## Wavelength Zone
*AWS Wavelength* を使用することで、モバイルデバイスおよびエンドユーザー向けに、非常にレイテンシーが低いアプリケーションを構築できます。Wavelength は標準の AWS コンピューティングおよびストレージサービスを通信事業者の 5G ネットワークのエッジにデプロイします。Amazon Virtual Private Cloud は、1 つまたは複数の Wavelength Zone に拡張できます。その後、Amazon EC2 インスタンスなどの AWS リソースを使用して、極めて低いレイテンシーやリージョンの AWS のサービス への接続を必要とするアプリケーションを実行できます。
Wavelength Zone は、Wavelength インフラストラクチャをデプロイする先のキャリアロケーション内の独立したゾーンです。Wavelength Zone は、AWS リージョンに関連付けられています。Wavelength Zone はリージョンの論理的な拡張であり、リージョンの制御プレーンによって管理されます。
Wavelength Zone は、リージョンコードに続けて Wavelength Zone を示す識別子で表されます (例: `us-east-1-wl1-bos-wlz-1`)。
Wavelength Zone を使用するには、まずゾーンにオプトインする必要があります。オプトインしたら、Wavelength Zone に Amazon VPC およびサブネットを作成する必要があります。その後、Amazon ECS クラスターとタスクに使用する Amazon EC2 インスタンスを Zone で起動することができます。
詳細については、*AWS Wavelengthデベロッパーガイド*の「[の使用開始AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/get-started-wavelength.html)」を参照してください。
Wavelength Zone は、すべての AWS リージョンで利用できるわけではありません。Wavelength Zone をサポートするリージョンについては*AWS Wavelength デベロッパーガイド*の[利用可能な Wavelength Zone](https://docs.aws.amazon.com/wavelength/latest/developerguide/available-wavelength-zones.html) をご参照ください。
# AWS OutpostsのAmazon Elastic Container Service
AWS Outposts は、オンプレミス施設でネイティブ AWS サービス、インフラストラクチャ、運用モデルを有効にします。AWS Outposts 環境では、AWS で使用するのと同じ AWS クラウド API、ツール、インフラストラクチャを使用できます。
AWS Outposts の Amazon ECS は、オンプレミスのデータやアプリケーションの近くで実行が必要な、低レイテンシーのワークロードに最適です。
AWS Outposts の詳細については、[https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)を参照してください。
## 考慮事項
AWS Outposts で Amazon ECS を使用する際の考慮事項は以下のとおりです。
+ Amazon Elastic Container Registry、AWS Identity and Access Management、Network Load Balancer は、AWS Outposts ではなく AWS リージョンで実行されます。これにより、これらのサービスとコンテナ間のレイテンシーが増加します。
+ AWS Fargate は AWS Outposts で使用できません。
以下に、AWS Outposts のネットワーク接続に関する考慮事項を示します。
+ AWS Outposts とその AWS リージョン間のネットワーク接続が失われた場合、クラスターは引き続き実行されます。ただし、接続が復元されるまで、新しいクラスターを作成したり、既存のクラスターで新しいアクションを実行したりすることはできません。インスタンスに障害が発生した場合、インスタンスは自動的に置き換えられません。The CloudWatch Logs エージェントは、ログとイベントデータを更新できません。
+ AWS OutpostsとAWS リージョン間で、信頼性が高く、可用性が高く、低レイテンシーの接続を提供することをお勧めします。
## 前提条件
AWS Outposts で Amazon ECS を使用するための前提条件は以下のとおりです。
+ オンプレミスのデータセンターに Outpost をインストールして設定しておく必要があります。
+ Outpost とその AWS リージョンとの間に、信頼できるネットワーク接続が必要です。
## AWS Outposts でのクラスター作成の概要
以下は、設定の概要です。
1. AWS Outposts に対する権限を持つロールとポリシーを作成します。
1. AWS Outposts の権限を持つ IAM インスタンスプロファイルを作成します。
1. VPC を作成、または AWS Outposts と同じリージョンにある既存の VPC を使用します。
1. サブネットを作成、または AWS Outposts に関連付けられている既存のサブネットを使用します。
これは、コンテナインスタンスが実行されるサブネットです。
1. クラスター内にあるコンテナインスタンスのセキュリティグループを作成します。
1. Amazon ECS クラスターを作成します。
1. クラスターでインスタンスを起動するための、Amazon ECS コンテナエージェント環境変数を定義します。
1. コンテナを実行します。
Amazon ECS を AWS Outposts に統合する方法の詳細については、「[Extend Amazon ECS across two AWS Outposts rack](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks)」を参照してください。
次の例では、AWS Outposts に Amazon ECS クラスターを作成します。
1. AWS Outposts に対する権限を持つロールとポリシーを作成します。
`role-policy.json` ファイルは、リソースに対する効果とアクションを含むポリシードキュメントです。ファイル形式の情報については、「[IAM API リファレンス](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)」の「*PutRolePolicy*」を参照してください。
```
aws iam create-role –-role-name ecsRole \
--assume-role-policy-document file://ecs-policy.json
aws iam put-role-policy --role-name ecsRole --policy-name ecsRolePolicy \
--policy-document file://role-policy.json
```
1. AWS Outposts の権限を持つ IAM インスタンスプロファイルを作成します。
```
aws iam create-instance-profile --instance-profile-name outpost
aws iam add-role-to-instance-profile --instance-profile-name outpost \
--role-name ecsRole
```
1. VPC を作成します。
```
aws ec2 create-vpc --cidr-block 10.0.0.0/16
```
1. AWS Outposts に関連付けられたサブネットを作成します。
```
aws ec2 create-subnet \
--cidr-block 10.0.3.0/24 \
--vpc-id vpc-xxxxxxxx \
--outpost-arn arn:aws:outposts:us-west-2:123456789012:outpost/op-xxxxxxxxxxxxxxxx \
--availability-zone-id usw2-az1
```
1. コンテナインスタンスのセキュリティグループを作成し、AWS Outposts に適切な CIDR 範囲を指定します。(この手順は、AWS Outposts では異なります。)
```
aws ec2 create-security-group --group-name MyOutpostSG
aws ec2 authorize-security-group-ingress --group-name MyOutpostSG --protocol tcp \
--port 22 --cidr 10.0.3.0/24
aws ec2 authorize-security-group-ingress --group-name MyOutpostSG --protocol tcp \
--port 80 --cidr 10.0.3.0/24
```
1. クラスターを作成します。
1. Amazon ECS コンテナエージェント環境変数を定義して、前のステップで作成したクラスターにインスタンスを起動し、クラスター (例えば、クラスターが Outpost 用であることを示す `Outpost` など) を識別するのに役立つタグを追加し、定義します。
```
#! /bin/bash
cat << ‘EOF’ >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_IMAGE_PULL_BEHAVIOR=prefer-cached
ECS_CONTAINER_INSTANCE_TAGS={“environment”: ”Outpost”}
EOF
```
**注記**
リージョン内の Amazon ECR からコンテナイメージをプルすることによる遅延を回避するには、イメージキャッシュを使用します。これを行うには、タスクを実行するたびに、`ECS_IMAGE_PULL_BEHAVIOR` を `prefer-cached` に設定して、インスタンス自体でキャッシュされたイメージを使用するように Amazon ECS エージェントをデフォルトに設定します。
1. コンテナインスタンスを作成し、このインスタンスを実行する AWS Outposts の VPC とサブネットを指定して、AWS Outposts で使用できるインスタンスタイプを指定します。(この手順は、AWS Outposts では異なります。)
`userdata.txt` ファイルは、インスタンスの起動後にそのインスタンスが一般的な自動設定タスクを実行したり、スクリプトを実行したりするために使用できるユーザーデータが含まれています。API コールのファイルの情報については、「*Amazon EC2 ユーザーガイド*」の「[起動時に Linux インスタンスでコマンドを実行する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)」を参照してください。
```
aws ec2 run-instances --count 1 --image-id ami-xxxxxxxx --instance-type c5.large \
--key-name aws-outpost-key –-subnet-id subnet-xxxxxxxxxxxxxxxxx \
--iam-instance-profile Name outpost --security-group-id sg-xxxxxx \
--associate-public-ip-address --user-data file://userdata.txt
```
**注記**
このコマンドは、クラスターにインスタンスを追加する場合にも使用されます。クラスターにデプロイされたコンテナは、その特定の AWS Outposts に配置されます。
# Amazon ECS コンテナイメージのベストプラクティス
コンテナイメージは、コンテナの構築方法に関する一連の指示です。コンテナイメージには、アプリケーションコードと、アプリケーションコードの実行に必要なすべての依存関係が保持されます。アプリケーションの依存関係には、アプリケーションコードが依存するソースコードパッケージ、インタープリタ型言語の言語ランタイム、および動的にリンクされたコードが依存するバイナリパッケージが含まれます。
コンテナイメージを設計および構築する際には、次のガイドラインに従ってください。
+ すべてのアプリケーションの依存関係をコンテナイメージ内に静的ファイルとして保存することで、コンテナイメージを完成させます。
コンテナイメージ内の何かを変更する場合は、変更内容を反映した新しいコンテナイメージを構築します。
+ コンテナ内で単一のアプリケーションプロセスを実行します。
コンテナの有効期間は、アプリケーションプロセスが実行されている期間です。Amazon ECS は、クラッシュしたプロセスを置き換えると共に、置き換え後のプロセスをどこで起動するかを決定します。適切に完成されたイメージは、デプロイ全体の耐障害性を高めます。
+ アプリケーションが `SIGTERM` を処理できるようにします。
Amazon ECS は、タスクを停止する場合、まず SIGTERM シグナルをそのタスクに送信し、アプリケーションを終了してシャットダウンする必要があることを通知します。その後、Amazon ECS は `SIGKILL` のメッセージを送信します。アプリケーションが `SIGTERM` を無視した場合、Amazon ECS サービスはしばらく待ってからプロセスを終了する `SIGKILL` シグナルを送信する必要があります。
アプリケーションが作業を完了するまでにかかる時間を特定して、アプリケーションが確実に `SIGTERM` シグナルに対応できるようにしてください。アプリケーションによるシグナル対応においては、アプリケーションがそれ以上新しい作業を取得するのをストップするとともに、進行中の作業を完了するか、または完了までに長い時間がかかる場合は、タスクの外部のストレージに未完了の作業を保存する必要があります。
+ ログを `stdout` および `stderr` に書き込むように、コンテナ化されたアプリケーションを設定します。
ログ処理をアプリケーションコードから分離することで、ログ処理をインフラストラクチャレベルでより柔軟に調整できるようになります。その一例として、ロギングシステムの変更があります。サービスを変更したり、新しいコンテナイメージを構築してデプロイする代わりに、設定の調整により対応できます。
+ タグを使用してコンテナイメージをバージョニングします。
コンテナイメージはコンテナレジストリに保存されます。レジストリ内の各イメージはタグによって識別されます。`latest` というタグがあります。このタグは、git リポジトリの `HEAD` と同様に、アプリケーションコンテナイメージの最新バージョンに対するポインターとして機能します。`latest` タグはテストのみに使用することが推奨されます。ベストプラクティスとして、ビルドごとにコンテナイメージに一意のタグを付けます。イメージの構築に使用された git コミットの git SHA を使用してイメージにタグ付けすることをお勧めします。
コミットごとにコンテナイメージを構築する必要はありません。ただし、特定のコードコミットを本番環境にリリースするたびに、新しいコンテナイメージを構築することをお勧めします。また、イメージに対して、イメージ内のコードの git commit に対応するタグを付けることをお勧めします。イメージに git commit のタグを付けた場合、イメージが実行しているコードのバージョンをより迅速に見つけることができます。
また、Amazon Elastic Container Registry でイミュータブルなイメージタグをオンにすることをお勧めします。この設定では、タグがポイントするコンテナイメージを変更することはできません。代わりに、Amazon ECR は、新しいイメージを新しいタグにアップロードするよう強制します。詳細については、「*Amazon ECR ユーザーガイド*」の「[イメージタグの変更可能性](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-tag-mutability.html)」を参照してください。
AWS Fargate で実行されるアプリケーションを構築する場合には、複数のコンテナを同一のタスク定義にデプロイするか、あるいは複数のタスク定義に個々のコンテナを別々にデプロイするかのいずれかを選択する必要があります。以下のような要件がある場合には、1 つのタスク定義にコンテナを配置することをお勧めします。
+ 各コンテナが同じライフサイクルを共有している (つまり、起動と終了が同時に行われる)。
+ 実行基盤となるホストが同じになるようにコンテナを実行する (つまり、あるコンテナが、localhost ポート上の別のコンテナを参照する) 必要がある。
+ 各コンテナがリソースを共有している。
+ コンテナでデータボリュームを共有している。
上記の要件がない場合は、複数のタスク定義でコンテナを個別にデプロイすることをお勧めします。これにより、各コンテナを個別にスケーリング、プロビジョニング、およびデプロビジョニングできます。
# Amazon ECS ネットワーキングのベストプラクティス
最近のアプリケーションは通常、相互に通信する複数の分散コンポーネントから構築されています。例えば、モバイルアプリケーションやウェブアプリケーションは API エンドポイントと通信したり、その API はインターネット経由で通信する複数のマイクロサービスによって動作していたりします。
インターネットへの接続アプリケーションのベストプラクティスについては、「[Amazon ECS アプリケーションをインターネットに接続する](networking-outbound.md)」を参照してください。
インターネットから Amazon ECS へのインバウンド接続を受信するためのベストプラクティスについては、「[インターネットから Amazon ECS へのインバウンド接続を受信するためのベストプラクティス](networking-inbound.md)」を参照してください。
Amazon ECS を他の AWS サービスに接続するためのベストプラクティスについては、「[Amazon ECS を VPC 内から AWS サービスに接続するためのベストプラクティス](networking-connecting-vpc.md)」を参照してください。
VPC 内のサービスに接続するためのベストプラクティスについては、「[VPC で Amazon ECS サービスを接続するためのベストプラクティス](networking-connecting-services.md)」を参照してください。
AWS アカウント間および VPC 間でのサービスのネットワーキングに関するベストプラクティスについては、「[AWS アカウントおよび VPC の間で Amazon ECS サービスをネットワーキングするためのベストプラクティス](networking-connecting-services-crossaccount.md)」を参照してください。
ネットワーキングの問題をトラブルシューティングするサービスに関するベストプラクティスについては、「[Amazon ECS ネットワーキングのトラブルシューティングのための AWS サービス](networking-troubleshooting.md)」を参照してください。
# Amazon ECS アプリケーションをインターネットに接続する
ほとんどのコンテナ化されたアプリケーションには、少なくとも、インターネットへのアウトバウンドアクセスを必要とするいくつかのコンポーネントが含まれています。たとえば、モバイルアプリのバックエンドでは、プッシュ通知へのアウトバウンドアクセスが必要です。
Amazon Virtual Private Cloud には、VPC とインターネット間の通信を円滑にする主な方法が 2 つあります。
## パブリックサブネットとインターネットゲートウェイ
![\[インターネットゲートウェイに接続されたパブリックサブネットのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/public-network.png)
インターネットゲートウェイへのルートがあるパブリックサブネットを使用すると、コンテナ化されたアプリケーションは、パブリックサブネットの VPC 内のホストで実行できます。コンテナを実行するホストには、パブリック IP アドレスが割り当てられます。このパブリック IP アドレスは、インターネットからルーティング可能です。詳細については、*Amazon VPC ユーザーガイド*の「[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)」を参照してください。
このネットワークアーキテクチャにより、アプリケーションを実行するホストとインターネット上の他のホストとの直接通信が容易になります。通信は双方向です。つまり、インターネット上の他のホストへのアウトバウンド接続を確立できるだけでなく、インターネット上の他のホストもそのホストに接続を試みる可能性があります。そのため、セキュリティグループとファイアウォールのルールには細心の注意を払う必要があります。これにより、インターネット上の他のホストは、開くべきでない接続を開くことができなくなります。
たとえば、アプリケーションが Amazon EC2 で実行されている場合は、SSH アクセス用のポート 22 が開いていないことを確認してください。そうしないと、インスタンスがインターネット上の悪意のあるボットが継続的に SSH 接続を試みる可能性があります。これらのボットはパブリック IP アドレスを総当たり的に調べます。空いている SSH ポートが見つかると、そのようなボットはパスワードをブルートフォース攻撃してインスタンスにアクセスしようとします。このため、多くの組織はパブリックサブネットの使用を制限し、すべてではないにしてもほとんどのリソースをプライベートサブネット内に置くことを好みます。
ネットワークにパブリックサブネットを使用することは、大量の帯域幅や最小のレイテンシーを必要とするパブリックアプリケーションに適しています。該当するユースケースには、ビデオストリーミングやゲームサービスが含まれます。
このネットワークアプローチは、Amazon ECS を Amazon EC2 で使用する場合と、AWS Fargate で使用する場合の両方でサポートされます。
+ Amazon EC2 — パブリックサブネットで EC2 インスタンスを起動できます。Amazon ECS はこれらの EC2 インスタンスをクラスター容量として使用し、インスタンス上で実行されるすべてのコンテナは、ホストの基礎となるパブリック IP アドレスをアウトバウンドネットワークに使用できます。これは `host` および `bridge` ネットワークモードの両方に当てはまります。ただし、`awsvpc` ネットワークモードでは、タスク ENI にパブリック IP アドレスが提供されません。そのため、インターネットゲートウェイを直接使用することはできません。
+ Fargate — Amazon ECS サービスを作成するときは、サービスのネットワーク設定にパブリックサブネットを指定し、**[パブリック IP アドレスの割り当て]** オプションを使用してください。各 Fargate タスクはパブリックサブネットでネットワーク化されており、インターネットと直接通信するための独自のパブリック IP アドレスを持っています。
## プライベートサブネットと NAT ゲートウェイ
![\[NAT ゲートウェイに接続されたプライベートサブネットのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/private-network.png)
プライベートサブネットと NAT ゲートウェイを使用すると、プライベートサブネット内のホストでコンテナ化されたアプリケーションを実行できます。そのため、このホストのプライベート IP アドレスは VPC 内ではルーティング可能ですが、インターネットからはルーティングできません。つまり、VPC 内の他のホストはプライベート IP アドレスを使用してホストに接続できますが、インターネット上の他のホストはそのホストとのインバウンド通信を行うことができません。
プライベートサブネットでは、ネットワークアドレス変換 (NAT) ゲートウェイを使用して、プライベートサブネット内のホストがインターネットに接続できるようにします。インターネット上のホストは、パブリックサブネット内の NAT ゲートウェイのパブリック IP アドレスから送信されているように見えるインバウンド接続を受信します。NAT ゲートウェイは、インターネットとプライベートサブネットの間のブリッジとして機能します。この構成では、VPC がインターネット上の攻撃者による直接アクセスから保護されるため、多くの場合セキュリティ上望ましいものです。詳細については、「*Amazon VPC ユーザーガイド*」の「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」を参照してください。
このプライベートネットワークアプローチは、外部からの直接アクセスからコンテナを保護するシナリオに適しています。該当するシナリオには、支払い処理システムや、ユーザーデータとパスワードを格納するコンテナなどがあります。アカウントで NAT ゲートウェイを作成して使用するには料金がかかります。NAT ゲートウェイの時間単位の使用料金とデータ処理料金も適用されます。冗長性を確保するために、アベイラビリティーゾーンごとに NAT ゲートウェイが必要です。こうすることで、1 つのアベイラビリティーゾーンの可用性が失われても、アウトバウンド接続が損なわれなくなります。このため、ワークロードが少ない場合は、プライベートサブネットと NAT ゲートウェイを使用する方が費用対効果が高い可能性があります。
このネットワークアプローチは、Amazon ECS を Amazon EC2 で使用する場合と、AWS Fargate で使用する場合の両方でサポートされます。
+ Amazon EC2 — プライベートサブネットで EC2 インスタンスを起動できます。これらの EC2 ホストで実行されるコンテナは、基盤となるホストのネットワークを使用し、アウトバウンドリクエストは NAT ゲートウェイを経由します。
+ Fargate — Amazon ECS サービスを作成するときは、サービスのネットワーク設定にプライベートサブネットを指定してください。**[パブリック IP アドレスの割り当て]** オプションは使用しないでください。各 Fargate タスクはプライベートサブネットでホストされます。そのアウトバウンドトラフィックは、そのプライベートサブネットに関連付けた NAT ゲートウェイを経由してルーティングされます。
# インターネットから Amazon ECS へのインバウンド接続を受信するためのベストプラクティス
パブリックサービスを運営している場合は、インターネットからのインバウンドトラフィックを受け入れる必要があります。たとえば、公開 Web サイトはブラウザからのインバウンド HTTP リクエストを受け入れる必要があります。このような場合、インターネット上の他のホストもアプリケーションのホストへのインバウンド接続を開始する必要があります。
この問題に対する 1 つの方法は、パブリック IP アドレスを持つパブリックサブネット内のホスト上でコンテナを起動することです。ただし、大規模なアプリケーションにこれを行うことは推奨しません。このような場合は、インターネットとアプリケーションの間にスケーラブルな入力層を設けるのがより適切なアプローチです。このアプローチでは、このセクションに記載されている AWS サービスのいずれかを入力として使用できます。
## Application Load Balancer
Application Load Balancer はアプリケーション層で機能します。これは、開放型システム間相互接続 (OSI) モデルの第 7 層です。これにより、Application Load Balancer はパブリック HTTP サービスに適しています。ウェブサイトまたは HTTP REST API を使用している場合は、Application Load Balancer がこのワークロードに適したロードバランサーです。詳細については、「*Application Load Balancers ユーザーガイド*」の「[Application Load Balancer とは](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)」を参照してください。
![\[Application Load Balancer を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/alb-ingress.png)
このアーキテクチャでは、パブリックサブネットに Application Load Balancer を作成します。これにより、パブリック IP アドレスが割り当てられ、インターネットからのインバウンド接続を受信できるようになります。Application Load Balancer は、インバウンド接続、より具体的には HTTP リクエストを受信すると、プライベート IP アドレスを使用してアプリケーションへの接続を開きます。次に、リクエストを内部接続経由で転送します。
Application Load Balancer には以下の利点があります。
+ SSL/TLS ターミネーション — Application Load Balancer は、クライアントとの通信用の安全な HTTPS 通信と証明書を維持できます。必要に応じて SSL 接続をロードバランサーレベルで終了できるため、独自のアプリケーションで証明書を処理する必要がありません。
+ 高度なルーティング — Application Load Balancer は複数の DNS ホスト名を持つことができます。また、ホスト名やリクエストのパスなどのメトリックに基づいて、受信した HTTP リクエストをさまざまな宛先に送信する高度なルーティング機能も備えています。つまり、単一の Application Load Balancer をさまざまな内部サービス、さらには REST API のさまざまなパスにあるマイクロサービスの入力として使用できます。
+ gRPC サポートとウェブソケット — Application Load Balancer は HTTP 以外も処理できます。また、HTTP/2 サポートにより、gRPC およびウェブソケットベースのサービスの負荷分散も可能です。
+ セキュリティ — Application Load Balancer は、悪意のあるトラフィックからアプリケーションを保護するのに役立ちます。HTTP 同期解除対策などの機能が含まれており、AWS Web Application Firewall (AWS WAF) と統合されています。AWS WAF は、SQL インジェクションやクロスサイトスクリプティングなどの攻撃パターンを含む可能性のある悪意のあるトラフィックをさらに効果的に除外できます。
## Network Load Balancer
Network Load Balancer は、開放型システム間相互接続 (OSI) モデルの第 4 層で機能します。HTTP 以外のプロトコルや、エンドツーエンドの暗号化が必要なシナリオに適していますが、Application Load Balancer と同じ HTTP 固有の機能はありません。そのため、Network Load Balancer は HTTP を使用しないアプリケーションに最適です。詳細については、「*Network Load Balancers ユーザーガイド*」の「[Network Load Balancer とは](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)」を参照してください。
![\[Network Load Balancer を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/nlbingress.png)
Network Load Balancer を入力として使用すると、Application Load Balancer と同様に機能します。これは、パブリックサブネットで作成されており、インターネット上でアクセスできるパブリック IP アドレスがあるためです。次に、Network Load Balancer は、コンテナを実行しているホストのプライベート IP アドレスへの接続を開き、パブリック側からプライベート側にパケットを送信します。
**Network Load Balancer の機能**
Network Load Balancer はネットワークスタックの下位レベルで動作するため、機能セットは Application Load Balancer と同じではありません。ただし、以下の重要な機能を備えています。
+ エンドツーエンドの暗号化 — Network Load Balancer は OSI モデルの第 4 層で動作するため、パケットの内容を読み取ることはありません。これにより、エンドツーエンドの暗号化を必要とする負荷分散通信に適しています。
+ TLS 暗号化 — エンドツーエンドの暗号化に加えて、Network Load Balancer は TLS 接続を終了することもできます。これにより、バックエンドアプリケーションが独自の TLS を実装する必要がなくなります。
+ UDP サポート — Network Load Balancer は OSI モデルの第 4 層で動作するため、HTTP 以外のワークロードや TCP 以外のプロトコルに適しています。
**接続を終了する**
Network Load Balancer は OSI モデルの上位層ではアプリケーションプロトコルを監視しないため、それらのプロトコルのクライアントにクロージャメッセージを送信することはできません。Application Load Balancer とは異なり、これらの接続はアプリケーションによって閉じられる必要があります。または、タスクが停止または置換されたときに、第 4 レイヤーの接続を閉じるように Network Load Balancer を設定することもできます。[Network Load Balancer のドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay)で、Network Load Balancer のターゲットグループの接続終了設定を参照してください。
Network Load Balancer に第 4 層で接続を終了させると、クライアントがそれを処理しない場合、クライアントが望ましくないエラーメッセージを表示する恐れがあります。推奨されるクライアント設定の詳細については、「[こちらの](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter)」 Builders Library を参照してください。
接続を閉じる方法はアプリケーションによって異なりますが、1 つの方法は、Network Load Balancer のターゲット登録解除の遅延時間をクライアントの接続タイムアウトよりも長くすることです。クライアントは最初にタイムアウトし、Network Load Balancer を介して次のタスクに正常に再接続し、同時に古いタスクではすべてのクライアントがゆっくりとドレインされます。Network Load Balancer のターゲット登録解除を遅延させる方法の詳細については、[Network Load Balancer のドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay)を参照してください。
## Amazon API Gateway HTTP API
Amazon API Gateway は、リクエスト量が突然急増する、またはリクエスト量が少ない HTTP アプリケーションに適しています。詳細については、「*API Gateway デベロッパーガイド*」の「[Amazon API Gateway とは](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)」を参照してください。
![\[API Gateway を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/apigateway-ingress.png)
Application Load Balancer および Network Load Balancer の料金モデルには、ロードバランサーがインバウンド接続を常時受け付けられるようにするための時間単位の料金が含まれています。これとは対照的に、API Gateway ではリクエストごとに個別に請求されます。これには、リクエストを受信しない限り課金されないという効果があります。トラフィック負荷が高い場合、Application Load Balancer または Network Load Balancer は、API Gateway よりも安いリクエストあたりの料金で大量のリクエストを処理できます。ただし、全体的にリクエスト数が少ない場合やトラフィックが少ない期間がある場合は、使用率が低いロードバランサーを維持するために時間単位の料金を支払うよりも、API Gateway を使用する場合の累積料金の方が費用対効果が高くなるでしょう。API Gateway は API レスポンスをキャッシュすることもできるため、バックエンドのリクエスト率が軽減される可能性があります。
API Gateway は、AWS マネージドサービスがプライベート IP アドレスを使用して VPC のプライベートサブネット内のホストに接続できるようにする VPC リンクを使用する機能です。Amazon ECS Service Discovery によって管理されている AWS Cloud Map サービス検出レコードを調べることで、これらのプライベート IP アドレスを検出できます。
API Gateway は、次の機能をサポートしています。
+ API Gateway の動作はロードバランサーに似ていますが、API 管理に固有の追加機能があります。
+ API Gateway は、クライアントの承認、使用レベル、リクエスト/レスポンスの変更に関する追加機能を備えています。詳細については、「[Amazon API Gateway の機能](https://aws.amazon.com//api-gateway/features/)」を参照してください。
+ API Gateway は、エッジ、リージョン、プライベート API ゲートウェイのエンドポイントをサポートできます。エッジエンドポイントは、マネージド CloudFront ディストリビューションを通じて利用できます。リージョナルエンドポイントとプライベートエンドポイントはどちらもリージョンに対してローカルです。
+ SSL/TLS ターミネーション
+ 異なる HTTP パスを別々のバックエンドマイクロサービスにルーティングする
API Gateway は、前述の機能に加えて、API を不正使用から保護するために使用できるカスタム Lambda オーソライザーの使用もサポートしています。詳細については、「[フィールドノート:Amazon ECS と Amazon API Gateway を使用したサーバーレスコンテナベースの API](https://aws.amazon.com/blogs/architecture/field-notes-serverless-container-based-apis-with-amazon-ecs-and-amazon-api-gateway/)」を参照してください。
# Amazon ECS を VPC 内から AWS サービスに接続するためのベストプラクティス
Amazon ECS が正しく機能するためには、各ホストで実行される Amazon ECS コンテナエージェントは Amazon ECS コントロールプレーンと通信する必要があります。コンテナイメージを Amazon ECR に保存している場合、Amazon EC2 ホストは Amazon ECR サービスエンドポイントと、およびイメージレイヤーが保存されている Amazon S3 と通信する必要があります。DynamoDB に保存されているデータの保持など、コンテナ化されたアプリケーションに他の AWS サービスを使用する場合は、必要なネットワーキングのサポートもこのサービスにあることを再確認してください。
## NAT ゲートウェイ
NAT ゲートウェイの使用は、Amazon ECS タスクが他の AWS サービスにアクセスできるようになる最も簡単な方法です。この方法の詳細については、「[プライベートサブネットと NAT ゲートウェイ](networking-outbound.md#networking-private-subnet)」を参照してください。
![\[NAT ゲートウェイを使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/natgateway.png)
この方法の利用における欠点は次のとおりです。
+ NAT ゲートウェイが通信できる宛先を制限することはできません。また、VPC からのすべてのアウトバウンド通信を中断することなく、バックエンド層が通信できる宛先を制限することはできません。
+ NAT ゲートウェイは、通過するデータの GB ごとに課金されます。NAT ゲートウェイを次のいずれかの操作に使用すると、帯域幅の GB ごとに課金されます。
+ Amazon S3 からの大きなファイルのダウンロード
+ DynamoDB に対する大量のデータベースクエリの実行
+ Amazon ECR からのイメージのプル
さらに、NAT ゲートウェイは 5 Gbps の帯域幅をサポートしており、45 Gbps まで自動的にスケールアップします。1 つの NAT ゲートウェイを介してルーティングする場合、非常に大きな帯域幅の接続を必要とするアプリケーションでは、ネットワーク上の制約が発生する可能性があります。回避策として、ワークロードを複数のサブネットに分割し、各サブネットに独自の NAT ゲートウェイを与えることができます。
## AWS PrivateLink
AWS PrivateLink は、トラフィックをパブリックインターネットに公開することのない、VPC、AWS サービス、オンプレミスネットワークの間のプライベート接続を提供します。
VPC エンドポイントにより、VPC とサポートされている AWS サービスおよび VPC エンドポイントサービスとの間のプライベート接続が可能になります。VPC と他のサービス間のトラフィックは、Amazon ネットワークを離れることはありません。VPC エンドポイントは、インターネットゲートウェイ、仮想プライベートゲートウェイ、NAT デバイス、VPN 接続、または Direct Connect 接続を必要としません。VPC の Amazon EC2 インスタンスでは、サービスのリソースと通信するのにパブリック IP アドレスを必要としません。
次の図は、インターネットゲートウェイではなく VPC エンドポイントを使用している場合に、AWS サービスへの通信がどのように機能するかを示しています。AWS PrivateLink はサブネット内で Elastic Network Interface (ENI) をプロビジョニングし、ENI 経由でサービスホスト名への通信を宛先の AWS サービスに直接送信するのに、VPC ルーティングルールが使用されています。このトラフィックは、NAT ゲートウェイまたはインターネットゲートウェイを使用する必要がなくなっています。
![\[AWS PrivateLink を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/endpointaccess-multiple.png)
以下は、Amazon ECS サービスで使用される一般的な VPC エンドポイントの一部です。
+ [Amazon S3 のゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)
+ [DynamoDB VPC エンドポイント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html)
+ [Amazon ECS VPC エンドポイント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html)
+ [Amazon ECR VPC エンドポイント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)
他の多くの AWS サービスは VPC エンドポイントをサポートしています。いずれかの AWS サービスを大量に使用する場合は、そのサービスの特定のドキュメントと、そのトラフィックにおいて VPC エンドポイントを作成する方法を調べる必要があります。
# VPC で Amazon ECS サービスを接続するためのベストプラクティス
VPC で Amazon ECS タスクを使用すると、モノリシックアプリケーションを、安全な環境で個別にデプロイおよびスケーリングできる別々の部分に分割できます。このアーキテクチャは、サービス指向アーキテクチャ (SOA) またはマイクロサービスといいます。ただし、VPC の内外両方で、これらのすべての部分が相互に通信できるようにするのが難しい場合があります。通信を促進する方法は複数ありますが、すべてにさまざまな利点と欠点があります。
## Service Connect の使用
サービス検出、接続、トラフィックモニタリング用の Amazon ECS 設定を提供する Service Connect をお勧めします。Service Connect を使用すると、アプリケーションは短縮名と標準ポートを使用して、同じクラスターや他のクラスター (同じリージョンの VPC 間を含む) 内のサービスに接続できます。詳細については、「[Amazon ECS Service Connect](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html)」を参照してください。
Service Connect を使用すると、Amazon ECS がサービス検出のすべての部分を管理します。つまり、検出可能な名前の作成、タスクの開始と終了時に各タスクのエントリを動的に管理すること、名前を検出するように設定された各タスクでのエージェントの実行などです。アプリケーションは DNS 名の標準機能を使用して接続することで名前を検索できます。アプリケーションがすでにこれを実行している場合、Service Connect を使用する際に、アプリケーションを変更する必要はありません。
![\[サービス接続を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/serviceconnect.png)
**変更はデプロイ中にのみ発生します**
各サービスとタスク定義内で完全な設定を行います。Amazon ECS は、デプロイ内のすべてのタスクが同じように動作するように、サービスデプロイごとにこの設定の変更を管理します。たとえば、サービス検出の DNS でよくある問題は、移行の制御です。新しい IP アドレスを指すように DNS 名を変更すると、すべてのクライアントが新しいサービスの使用を開始するまでに最大 TTL 時間がかかることがあります。Service Connect では、クライアントデプロイメントがクライアントタスクを置き換えて設定を更新します。他のデプロイと同様に、Service Connect の変更に影響するように、デプロイサーキットブレーカーやその他のデプロイ設定を設定できます。
## サービス検出の使用
サービス間の通信のもう 1 つのアプローチは、サービス検出を使用する直接的な通信です。このアプローチでは、Amazon ECS との AWS Cloud Map サービス検出の統合を使用できます。Amazon ECS はサービス検出を使用して、起動されたタスクのリストを AWS Cloud Map に同期します。このホスト名は特定のサービスの 1 つ以上のタスクの内部 IP アドレスに解決される DNS ホスト名を保持します。Amazon VPC の他のサービスは、この DNS ホスト名を使用して、内部 IP アドレスを使用してトラフィックを別のコンテナに直接送信できます。詳細については、「[サービス検出](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html)」を参照してください。
![\[サービス検出を使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/servicediscovery.png)
前出の図では、サービスが 3 つあります。`service-a-local` はコンテナが 1 つあり、コンテナが 2 つある `service-b-local` と通信します。`service-b-local` は、コンテナが 1 つある `service-c-local` とも通信する必要があります。これら 3 つのサービスすべての各コンテナは、AWS Cloud Map の内部 DNS 名を使用して、通信する必要があるダウンストリームサービスからコンテナの内部 IP アドレスを見つけることができます。
このサービス間通信のアプローチでは、レイテンシが低くなります。一見すると、コンテナ間に余分なコンポーネントがないためシンプルでもあります。トラフィックは 1 つのコンテナから別のコンテナに直接移動します。
この方法は、各タスクに固有の IP アドレスが割り当てられる `awsvpc` ネットワークモードを使用する場合に適しています。ほとんどのソフトウェアは、IP アドレスに直接変換される DNS `A` レコードの使用のみをサポートしています。`awsvpc` ネットワークモードを使用する場合、各タスクの IP アドレスは `A` レコードになります。ただし、`bridge` ネットワークモードを使用している場合は、複数のコンテナが同じ IP アドレスを共有している可能性があります。さらに、動的ポートマッピングでは、その 1 つの IP アドレスのポート番号がコンテナにランダムに割り当てられます。この時点では、`A` レコードだけではサービス検出には不十分です。`SRV` レコードも使用する必要があります。このタイプのレコードは IP アドレスとポート番号の両方を記録できますが、アプリケーションを適切に設定する必要があります。使用するビルド済みアプリケーションの中には、`SRV` レコードをサポートしていないものもあります。
`awsvpc` ネットワークモードのもう 1 つの利点は、サービスごとに固有のセキュリティグループがあることです。このセキュリティ グループを設定して、そのサービスと通信する必要がある特定のアップストリームサービスからの受信接続のみを許可することができます。
サービス検出を使用するサービス間直接的な通信の主な欠点は、再試行や接続障害に対処するためのロジックを追加する必要があることです。DNS レコードには、キャッシュされる時間を制御する有効期限 (TTL) があります。DNS レコードが更新されてキャッシュが期限切れになり、アプリケーションが最新バージョンの DNS レコードを取得できるようになるまでには、ある程度の時間がかかります。そのため、アプリケーションが DNS レコードを解決して、もう存在しない別のコンテナを指すようになってしまう可能性があります。アプリケーションには再試行を処理し、不正なバックエンドを無視するロジックが必要です。
## 内部ロードバランサーの使用
サービス間通信のもう 1 つの方法は、内部ロードバランサーを使用することです。内部ロードバランサーは完全に VPC 内に存在し、VPC 内のサービスにのみアクセスできます。
![\[内部ロードバランサーを使用するネットワークのアーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/loadbalancer-internal.png)
ロードバランサーは、冗長リソースを各サブネットにデプロイすることで、高可用性を維持します。`serviceA` のコンテナが `serviceB` のコンテナと通信する必要がある場合、ロードバランサーへの接続が開きます。次に、ロードバランサーは `service B` からコンテナへの接続を開きます。ロードバランサーは、各サービス間のすべての接続を管理するための一元的な場所として機能します。
`serviceB` のコンテナが停止すると、ロードバランサーはそのコンテナをプールから削除できます。また、ロードバランサーはそのプール内の各ダウンストリームターゲットに対してヘルスチェックを行い、再び正常になるまでプールから不正なターゲットを自動的に削除できます。アプリケーションは、ダウンストリームコンテナの数を認識する必要がなくなりました。ロードバランサーへの接続を開くだけです。
この方法は、すべてのネットワークモードで有益です。ロードバランサーは、`awsvpc` ネットワークモードを使用する場合のタスク IP アドレスと、`bridge` ネットワークモードを使用する場合の IP アドレスとポートのより高度な組み合わせを追跡できます。また、実際に複数のコンテナが異なるポートにおいて同じ Amazon EC2 インスタンスでホストされている場合でも、すべての IP アドレスとポートの組み合わせにトラフィックを均等に分散します。
この方法の欠点の 1 つはコストです。可用性を高めるために、ロードバランサーには各アベイラビリティーゾーンにリソースが必要です。この結果、ロードバランサーとロードバランサーを通過するトラフィック量に対して支払うオーバーヘッドにより、追加コストが追加されます。
ただし、複数のサービスでロードバランサーを共有することで、オーバーヘッドコストを削減できます。これは、Application Load Balancer を使用する REST サービスに特に適しています。ユーザーは、異なるサービスにトラフィックをルーティングするパスベースのルーティングルールを作成できます。例えば、`/api/user/*` は `user` サービスの一部であるコンテナにルーティングし、`/api/order/*` は関連付けられた `order` サービスにルーティングできます。この方法では、1 つの Application Load Balancer に対してのみ料金が発生し、API の URL が一貫した 1 つになります。ただし、トラフィックをバックエンドのさまざまなマイクロサービスに分割することはできます。
# AWS アカウントおよび VPC の間で Amazon ECS サービスをネットワーキングするためのベストプラクティス
複数のチームや部門を有する組織に属している場合は、おそらく共有 AWS アカウント内の個別の VPC または複数の個別の AWS アカウントに関連付けられている VPC に、サービスを個別にデプロイするでしょう。どの方法でサービスをデプロイしても、VPC 間でトラフィックをルーティングできるようにネットワークコンポーネントを補完することをお勧めします。そのためには、複数の AWS サービスを使用して、既存のネットワークコンポーネントを補完することができます。
+ AWS Transit Gateway – このネットワーキングサービスを最初に検討する必要があります。このサービスは、Amazon VPC、AWS アカウントおよびオンプレミスネットワーク間の接続をルーティングするための中央ハブとして機能します。詳細については、「Amazon VPC Transit Gateway ガイド」の「[Transit Gateway とは](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)」を参照してください。**
+ Amazon VPC および VPN サポート – このサービスを使用して、オンプレミスネットワークを VPC に接続するためのサイト間 VPN 接続を作成できます。詳細については、「*AWS Site-to-Site VPN ユーザーガイド*」の「[What is AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)」を参照してください。
+ Amazon VPC – 同じアカウント内または複数のアカウント間で複数の VPC を接続できる、Amazon VPC ピアリングを使用できます。詳細については、*Amazon VPC Peering Guide*の「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)」を参照してください。
+ 共有 VPC – 複数の AWS アカウントで VPC と VPC サブネットを使用できます。詳細については、「Amazon VPC ユーザーガイド」の「[共有 VPC の使用](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html)」を参照してください。**
# Amazon ECS ネットワーキングのトラブルシューティングのための AWS サービス
以下のサービスと機能は、ネットワークとサービスの設定に関するインサイトを得るのに役立ちます。この情報を使用することで、ネットワーキング問題のトラブルシューティングを行い、サービスをより適切に最適化できます。
## CloudWatch Container Insights
CloudWatch Container Insights は、コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集、集約、要約します。メトリクスには、CPU、メモリ、ディスク、ネットワークなどのリソースの使用率が含まれています。メトリクスは CloudWatch 自動ダッシュボードで使用できます。詳細については、「Amazon CloudWatch ユーザーガイド」の「[Amazon ECS での Container Insights のセットアップ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS.html)」を参照してください。**
## AWS X-Ray
AWS X-Ray は、アプリケーションが行うネットワークリクエストに関する情報を収集するのに使用できるトレースサービスです。SDK を使用することで、アプリケーションをインストルメント化し、サービス間、およびサービスと AWS サービスエンドポイントとの間のトラフィックのタイミングとレスポンスコードをキャプチャできます。詳細については、「AWS X-Ray デベロッパーガイド**」の「[AWS X-Ray とは](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)」を参照してください。
また、サービスがどのように相互にネットワーキングされているかについての AWS X-Ray グラフを見ることもできます。または、これらを使用して、各サービス間リンクのパフォーマンスに関する総合統計情報を見ることができます。最後に、特定のトランザクションを詳しく調べることで、ネットワーク呼び出しを表すセグメントがその特定のトランザクションにどのように関連付けられているかを確認できます。
これらの機能を使用することで、ネットワーキングのボトルネックがあるかどうか、またはネットワーク内の特定のサービスが期待どおりに動作していないかどうかを特定できます。
## VPC フローログ
Amazon VPC フローログを使用して、ネットワークパフォーマンスを分析したり、接続の問題をデバッグしたりできます。VPC フローログを有効にすると、VPC 内のすべての接続のログをキャプチャできます。この接続には、Elastic Load Balancing、Amazon RDS、NAT ゲートウェイ、および使用している可能性があるその他の主要な AWS サービスに関連付けられているネットワークインターフェイスへの接続が含まれます。詳細については、「Amazon VPC ユーザーガイド」の「[VPC フローログを使用した IP トラフィックのログ記録](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)」を参照してください。
## ネットワーク調整のヒント
ネットワーキングを改善するために微調整できる設定がいくつかあります。
### nofile ulimit
アプリケーションのトラフィックが多く、多数の同時接続を処理することが予想される場合は、許可されるファイル数に対しシステムクォータを考慮する必要があります。多数のネットワークソケットが開いている場合は、それぞれをファイル記述子で表す必要があります。ファイル記述子のクォータが低すぎると、ネットワークソケットが制限されます。この結果、接続が失敗したり、エラーが発生したりします。コンテナ固有のクォータは、Amazon ECS タスク定義内のファイル数に合わせて更新できます。(AWS Fargate ではなく) Amazon EC2 で実行している場合は、基盤となる Amazon EC2 インスタンスでこれらのクォータを調整する必要もあります。
### sysctl ネット
もう 1 つのカテゴリの調整可能な設定は、`sysctl` ネット設定です。選択した Linux ディストリビューションの特定の設定を参照する必要があります。この設定の多くでは、読み取りバッファと書き込みバッファのサイズが調整されます。これは、コンテナが多数ある大規模な Amazon EC2 インスタンスを実行する場合に役立つことがあります。
# Amazon ECS タスクの起動時間を最適化する
タスク起動をスピードアップするために、以下の推奨事項を考慮してください。
+
**コンテナイメージと binpack インスタンスをキャッシュします。**
EC2 を使用する場合、Amazon ECS コンテナエージェントのプル動作を `ECS_IMAGE_PULL_BEHAVIOR`: `prefer-cached` のように設定できます。キャッシュされたイメージがない場合に、リモートでイメージがプルされます。それ以外の場合は、インスタンスにキャッシュされたイメージが使用されます。キャッシュされたイメージが削除されないように、そのコンテナの自動イメージクリーンアップはオフになっています。これにより、次回起動時のイメージのプルタイムが短縮されます。コンテナインスタンスのタスク密度が高い場合、キャッシュの効果はさらに大きくなります。コンテナインスタンスは `binpack` 配置戦略を使用して設定できます。コンテナイメージのキャッシュは、通常はコンテナイメージのサイズが大きい Windows ベースのワークロード (数十 GB) に特に役立ちます。`binpack` 配置戦略を使用する場合は、Elastic Network Interface (ENI) トランキングを使用して、各コンテナインスタンスに `awsvpc` ネットワークモードでより多くのタスクを配置することを検討することもできます。ENI トランキングを使用すると、`awsvpc` モードで実行できるタスク数が増加します。たとえば、同時に 2 つのタスクしか実行できない c5.large インスタンスの場合、ENI トランキングでは最大 10 のタスクを実行できます。
+
**最適なネットワークモードを選択する**
`awsvpc` ネットワークモードが理想的な例は多数ありますが、このネットワークモードは本質的にタスク起動レイテンシーを増加させる可能性があります。これは、`awsvpc` モード内の各タスクについて、Amazon EC2 API を呼び出して ENI をプロビジョニングしてアタッチする必要があるため、タスク起動に数秒のオーバーヘッドが追加されるためです。対照的に、`awsvpc` ネットワークモードを使用する主な利点は、各タスクにトラフィックを許可または拒否するセキュリティグループがあることです。つまり、タスクとサービス間の通信をよりきめ細かく制御できる柔軟性が増します。デプロイ速度を優先する場合は、`bridge` モードを使用してタスクの起動をスピードアップすることを検討してください。詳細については、「[Amazon ECS タスクにネットワークインターフェイスを割り当てる](task-networking-awsvpc.md)」を参照してください。
+
**タスク起動のライフサイクルを追跡して、最適化の機会を見つけます。**
多くの場合、アプリケーションが起動するまでにかかる時間を知ることは困難です。アプリケーションの起動時に、コンテナイメージの起動、起動スクリプトの実行、その他の設定を行うと、驚くほど時間がかかることがあります。タスクメタデータエンドポイントを使用してメトリクスを投稿することで、コンテナメタデータレスポンスの `StartedAt` からタスクまたはサービスまでの `StartedAt` 時間を追跡できます。このデータにより、アプリケーションが起動時間全体にどのような影響を与えているかを把握し、アプリケーション固有の不要なオーバーヘッドを減らし、コンテナイメージを最適化できる領域を見つけることができます。詳細については、「[Amazon ECS 自動スケーリングとキャパシティ管理におけるベストプラクティス](capacity-availability.md)」を参照してください。
+
**最適なインスタンスタイプを選択する (EC2 の場合)**
適切なインスタンスタイプは、タスクに設定したリソース予約 (CPU、メモリなど) に基づいて選択します。したがって、インスタンスのサイズを決定する際には、1 つのインスタンスに配置できるタスクの数を計算できます。適切に配置されたタスクの簡単な例は、m5.large インスタンス (2 vCPU と 8 GB のメモリをサポート) で 0.5 vCPU と 2 GB のメモリ予約を必要とする 4 つのタスクをホストすることです。このタスク定義の予約は、インスタンスのリソースを最大限に活用します。
# Amazon ECS を大規模に運用する
Amazon ECS を大規模に運用し始める際には、Amazon ECS および Amazon ECS と統合する AWS のサービス のサービスクォータと API スロットリングがどのように影響するかを検討します。
**Topics**
+ [Amazon ECS Service Quotas と API スロットリング制限](operating-at-scale-service-quotas-best-practice.md)
+ [Amazon ECS のスロットリングに関する問題を処理する](operating-at-scale-dealing-with-throttles.md)
# Amazon ECS Service Quotas と API スロットリング制限
Amazon ECS は、Elastic Load Balancing、AWS Cloud Map、Amazon EC2 など、いくつかの AWS のサービス と統合されています。この緊密な統合により、Amazon ECS ではサービスのロードバランシング、サービス検出、タスクネットワーク、クラスターの自動スケーリングなどのいくつかの機能を利用できます。Amazon ECS および、統合されているその他の AWS のサービス はすべて、一貫したパフォーマンスと利用率を確保するために、サービスクォータと API レート制限を維持します。また、これらのサービスクォータは、必要以上のリソースを誤ってプロビジョニングすることを防ぎ、請求額を増やす可能性のある悪意のある行為からも保護します。
サービスクォータと AWS API のレート制限をよく理解しておけば、予期しないパフォーマンスの低下を心配することなく、ワークロードのスケーリングを計画できます。詳細については、「[Amazon ECS の Service Quotas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html)」「[Request throttling for the Amazon ECS API](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html)」を参照してください。
Amazon ECS でワークロードをスケーリングする場合は、次のサービスクォータを検討します。サービスクォータの引き上げをリクエストする方法については、「[AWS マネジメントコンソール での Amazon ECS と AWS Fargate サービスクォータの管理](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas-manage.html)」を参照してください。
+ AWS Fargate には、各 AWS リージョン のタスクで同時に実行できるタスクの数を制限するクォータがあります。Amazon ECS では、オンデマンドタスクと Fargate Spot タスクの両方にクォータが設定されています。各サービスクォータには、Fargate で実行するすべての Amazon EKS ポッドも含まれます。Fargate クォータの詳細については、「*AWS Fargate の Amazon Elastic Container Service ユーザーガイド*」にある「[AWS Fargate サービスクォータ](https://docs.aws.amazon.com/AmazonECS/latest/userguide/service-quotas.html#service-quotas-fargate)」を参照してください。
+ Amazon EC2 インスタンスで実行されるタスクの場合、各クラスターに登録できる Amazon EC2 インスタンスの最大数は 5,000 です。Auto Scaling グループの容量プロバイダーで Amazon ECS クラスターの自動スケーリングを使用する場合、またはクラスターの Amazon EC2 インスタンスを自分で管理する場合、このクォータがデプロイのボトルネックになる可能性があります。さらに容量が必要な場合は、クラスターをさらに作成するか、サービスクォータの引き上げをリクエストすることができます。
+ Auto Scaling グループのキャパシティプロバイダーで Amazon ECS クラスターの自動スケーリングを使用する場合は、サービスをスケーリングする際に `Tasks in the PROVISIONING state per cluster` クォータを考慮してください。このクォータは、キャパシティプロバイダーがキャパシティを増やすことができる各クラスターの `PROVISIONING` 状態にあるタスクの最大数です。多数のタスクを同時に起動すると、すぐにこのクォータに達してしまいます。たとえば、それぞれ数百のタスクを含む数十のサービスを同時にデプロイする場合です。この場合、クラスターのキャパシティが不足すると、キャパシティープロバイダーは新しいコンテナインスタンスを起動してタスクを配置する必要があります。キャパシティープロバイダーが追加の Amazon EC2 インスタンスを起動している間、Amazon ECS サービススケジューラーは引き続きタスクを並行して起動する可能性があります。ただし、クラスターのキャパシティが不十分なため、このアクティビティが抑制される可能性があります。Amazon ECS サービススケジューラは、新しいコンテナインスタンスが起動したときにタスク配置を再試行するためのバックオフおよびエクスポネンシャルスロットリング戦略を実装しています。その結果、デプロイやスケールアウトに時間がかかる可能性があります。このような状況を回避するために、以下のいずれかの方法でサービスのデプロイを計画できます。クラスターの容量を増やす必要のないタスクを大量に展開するか、新しいタスクの起動に備えて余剰のクラスター容量を確保しておくかのどちらかです。
ワークロードをスケーリングする際には Amazon ECS サービスクォータを考慮することに加えて、Amazon ECS と統合されている他の AWS のサービス 用のサービスクォータも考慮してください。次のセクションでは、各サービスの主要なレート制限について詳しく説明し、スロットリングの潜在的な問題に対処するための推奨事項を提供します。
## Elastic Load Balancing
Fargate の Amazon ECS サービスは、Elastic Load Balancing を使用してタスク間でトラフィックを均等に分散するように設定できます。ロードバランサーを選択する方法の詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html)」を参照してください。
### Elastic Load Balancing のサービスクォータ
ワークロードをスケーリングするときは、以下の Elastic Load Balancing のサービスクォータを考慮してください。Elastic Load Balancing のサービスクォータのうち、ほとんどは調整可能で、Service Quotas コンソールでリクエストできます。
**Application Load Balancer**
Application Load Balancer を使用する際、ユースケースによっては、以下のクォータ増加をリクエストする必要がある場合があります。
+ Application Load Balancer の背後にあるターゲットの数である `Targets per Application Load Balancer` クォータ。
+ ターゲットグループの背後にあるターゲットの数である `Targets per Target Group per Region` クォータ。
詳細については、「[Quotas for your Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html)」を参照してください。
**Network Load Balancer**
Network Load Balancer に登録できるターゲットの数には、より厳しい制限があります。Network Load Balancer を使用する場合、クロスゾーンサポートを有効にする必要があることがよくあります。これには、各 Network Load Balancer のアベイラビリティーゾーンあたりの `Targets per Availability Zone Per Network Load Balancer` 最大ターゲット数に対する追加のスケーリング制限が伴います。詳細については、「[Network Load Balancer のクォータ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-limits.html)」を参照してください。
### Elastic Load Balancing API のスロットリング
ロードバランサーを使用するように Amazon ECS サービスを設定する場合、サービスが正常であると見なされるには、ターゲットグループのヘルスチェックに合格する必要があります。これらのヘルスチェックを実行するために、Amazon ECS はユーザーに代わって Elastic Load Balancing API 操作を呼び出します。アカウントにロードバランサーが設定されたサービスが多数ある場合、特に `RegisterTarget`、`DeregisterTarget`、`DescribeTargetHealth` Elastic Load Balancing API 操作に関してスロットリングが発生する可能性があるため、サービスのデプロイが遅くなる可能性があります。スロットリングが発生すると、Amazon ECS サービスのイベントメッセージにスロットリングエラーが発生します。
AWS Cloud Map API でスロットリングが発生した場合は、AWS Cloud Map API のスロットリング制限を引き上げる方法について サポート までお問い合わせください。スロットリングエラーの監視とトラブルシューティングの詳細については、「[Handling throttling issues](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)」を参照してください。
## Elastic Network Interface
タスクで `awsvpc` ネットワークモードを使用する場合、Amazon ECS はタスクごとに独自の Elastic Network Interface (ENI) をプロビジョニングします。Amazon ECS サービスが Elastic Load Balancing ロードバランサーを使用する場合、これらのネットワークインターフェイスは、サービスで定義された適切なターゲットグループのターゲットとしても登録されます。
### Elastic Network Interface のサービスクォータ
`awsvpc` ネットワークモードを使用するタスクを実行すると、固有のエラスティックネットワークインターフェイスが各タスクにアタッチされます。インターネット経由でこれらのタスクにアクセスする必要がある場合は、タスクのエラスティックネットワークインターフェイスにパブリック IP アドレスを割り当てます。Amazon ECS ワークロードをスケーリングするときは、次の 2 つの重要なクォータを考慮してください。
+ アカウントの AWS リージョン におけるネットワークインターフェイスの最大数である `Network interfaces per Region` クォータ。
+ AWS リージョン に含まれる Elastic IP アドレスの最大数である `Elastic IP addresses per Region` クォータ。
これらのサービスクォータは両方とも調整可能で、Service Quotas コンソールから増加をリクエストできます。詳細については、「[Amazon VPC サービスクォータ](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-enis)」を参照してください。
Amazon EC2 インスタンスでホストされている Amazon ECS ワークロードの場合、`awsvpc` ネットワークモードを使用するタスクを実行するときは、各 Amazon EC2 インスタンスの最大ネットワークインスタンスの数である `Maximum network interfaces` サービスクォータを考慮してください。このクォータは、1 つのインスタンスに配置できるタスクの数を制限します。クォータを調整することはできず、Service Quotas コンソールでは使用できません。詳細については、「*Amazon EC2 ユーザーガイド*」の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)」を参照してください。
Amazon EC2 インスタンスにアタッチできるネットワークインターフェイスの数は変更できませんが、エラスティックネットワークインターフェイスのトランキング機能を使用して利用可能なネットワークインターフェイスの数を増やすことができます。たとえば `c5.large` インスタンスにはデフォルトでネットワークインターフェイスを最大 3 つアタッチできます。このインスタンスのプライマリネットワークインターフェイスも、1 個としてカウントされます。そのため、このインスタンスに追加で 2 個のネットワークインターフェイスをアタッチできます。`awsvpc` ネットワークモードを使用する各タスクにはネットワークインターフェイスが必要なため、通常このインスタンスタイプでは、これらのタスクを 2 つのみ実行できます。これにより、クラスターの容量が十分に活用されない可能性があります。エラスティックネットワークインターフェイスでトランキングを有効にすると、ネットワークインターフェイスの密度を上げて、各インスタンスにより多くのタスクを配置できます。トランキングをオンにすると、1 つの `c5.large` インスタンスに最大 12 のネットワークインターフェースを設定できます。インスタンスはプライマリネットワークインターフェイスを持ち、Amazon ECS は「トランク」ネットワークインターフェイスを作成し、アタッチします。その結果、この構成では、デフォルトの 2 つのタスクではなく、10 のタスクをインスタンスで実行できます。詳細については、「[Elastic network interface trunking](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html)」を参照してください。
### エラスティックネットワークインターフェイス API のスロットリング
`awsvpc` ネットワークモードを使用するタスクを実行する場合、Amazon ECS は次の Amazon EC2 API に依存します。これらの API にはそれぞれ異なる API スロットリングがあります。詳細については、「[Amazon EC2 API のリクエストスロットリング](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html)」を参照してください。
+ CreateNetworkInterface
+ AttachNetworkInterface
+ DetachNetworkInterface
+ DeleteNetworkInterface
+ DescribeNetworkInterfaces
+ DescribeVpcs
+ DescribeSubnets
+ DescribeSecurityGroups
+ DescribeInstances
エラスティックネットワークインターフェイスのプロビジョニングワークフロー中に Amazon EC2 API コールがスロットリングされた場合、Amazon ECS サービススケジューラは自動的にエクスポネンシャルバックオフを行って再試行します。これらの自動廃止により、タスクの起動が遅れ、デプロイ速度が遅くなることがあります。API スロットリングが発生すると、サービスイベントメッセージにメッセージ `Operations are being throttled. Will try again later.` が表示されます。Amazon EC2 API でスロットリングが継続的に発生する場合は、API のスロットリング制限を引き上げる方法について サポート までお問い合わせください。スロットリングエラーの監視とトラブルシューティングの詳細については、「[スロットリング問題の処理](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)」を参照してください。
## AWS Cloud Map
Amazon ECS サービス検出では、AWS Cloud Map API を使用して Amazon ECS サービスの名前空間を管理します。サービスに多数のタスクがある場合は、以下の推奨事項を考慮してください。詳細については、「[Amazon ECS サービス検出に関する考慮事項](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html#service-discovery-considerations)」を参照してください。
### AWS Cloud Map Service Quotas
Amazon ECS サービスがサービス検出を使用するように設定されている場合、サービスの最大タスク数である `Tasks per service` クォータは、そのサービスの最大インスタンス数である AWS Cloud Map `Instances per service` サービスクォータの影響を受けます。特に、AWS Cloud Map サービスクォータにより、実行できるタスクの数は、サービスあたり最大 1,000 タスクに減少します。AWS Cloud Map のクォータは変更できません。詳細については、「[AWS Cloud Map サービスクォータ](https://docs.aws.amazon.com/general/latest/gr/cloud_map.html)」を参照してください。
### AWS Cloud Map API スロットリング
Amazon ECS はユーザーに代わって`ListInstances`、`GetInstancesHealthStatus`、`RegisterInstance`、および `DeregisterInstance` AWS Cloud Map API を呼び出します。これらはサービス検出を支援し、タスクを起動するとヘルスチェックを実行します。多数のタスクを伴うサービス検出を使用する複数のサービスを同時にデプロイすると、AWS Cloud Map API のスロットリング制限を超える可能性があります。この場合、Amazon ECS サービスのイベントメッセージに次のようなメッセージが表示される場合があります: Amazon ECS サービスイベントで `Operations are being throttled. Will try again later` が発生しました。デプロイとタスクの起動速度が遅くなっています。AWS Cloud Map には、これらの API のスロットリング制限は記録されていません。これらのスロットリングが発生した場合は、API のスロットリング制限を引き上げる方法について サポート までお問い合わせください。このようなスロットリングエラーの監視とトラブルシューティングの詳細については、「[Handling throttling issues](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)」を参照してください。
# Amazon ECS のスロットリングに関する問題を処理する
スロットリングエラーは、同期スロットリングと非同期スロットリングの 2 つの主要なカテゴリに分類されます。
## 同期スロットリング
同期スロットリングが発生すると、すぐに Amazon ECS からエラーレスポンスが届きます。このカテゴリは通常、タスクの実行中またはサービスの作成中に Amazon ECS API を呼び出すと発生します。影響を受けるスロットリングと関連するスロットリング制限の詳細については、「[Amazon ECS API リクエストのスロットリング](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html)」を参照してください。
アプリケーションが、AWS CLI、AWS SDK などを使用して API リクエストを開始すると、API スロットリングを修正できます。そのためには、エラーを処理するようにアプリケーションを設計するか、API コールの再試行ロジックを使用してエクスポネンシャルバックオフとジッター戦略を実装します。詳細については、「[タイムアウト、リトライ、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)」を参照してください。
AWS SDK を使用する場合、自動再試行ロジックは組み込まれており、設定可能です。
## 非同期スロットリング
非同期スロットリングは、Amazon ECS または CloudFormation がユーザーに代わって API を呼び出してリソースをプロビジョニングする非同期ワークフローが原因で発生する場合があります。Amazon ECS がユーザーに代わって呼び出す AWS API がどれなのかを知ることは重要です。たとえば、`CreateNetworkInterface` API は `awsvpc` ネットワークモードを使用するタスクに対して呼び出され、`DescribeTargetHealth` API はロードバランサーに登録されたタスクのヘルスチェックを実行するときに呼び出されます。
ワークロードがかなり大きくなると、これらの API オペレーションがスロットリングされる可能性があります。つまり、Amazon ECS や呼び出される AWS のサービス による制限を超えるほどスロットリングされる可能性があります。たとえば、数百のサービスをデプロイし、それぞれが `awsvpc` ネットワークモードを使用する数百のタスクを同時に実行する場合、Amazon ECS は `CreateNetworkInterface` などの EC2 API 操作および `RegisterTarget`、`DescribeTargetHealth` などの Elastic Load Balancing API 操作を呼び出し、それぞれエラスティックネットワーク、ロードバランサーを登録します。これらの API コールが API の制限を超えると、スロットリングエラーが発生する可能性があります。以下は、サービスイベントメッセージに含まれる Elastic Load Balancing スロットリングエラーの例です。
```
{
"userIdentity":{
"arn":"arn:aws:sts::111122223333:assumed-role/AWSServiceRoleForECS/ecs-service-scheduler",
"eventTime":"2022-03-21T08:11:24Z",
"eventSource":"elasticloadbalancing.amazonaws.com",
"eventName":" DescribeTargetHealth ",
"awsRegion":"us-east-1",
"sourceIPAddress":"ecs.amazonaws.com",
"userAgent":"ecs.amazonaws.com",
"errorCode":"ThrottlingException",
"errorMessage":"Rate exceeded",
"eventID":"0aeb38fc-229b-4912-8b0d-2e8315193e9c"
}
}
```
これらの API コールがアカウント内の他の API トラフィックと制限を共有している場合、サービスイベントとして送信されても監視が難しい場合があります。
## スロットリングを監視する
どの API リクエストがスロットリングされ、誰がリクエストを発行したかを特定することが重要です。AWS CloudTrail を使用すると、スロットリングを監視し、CloudWatch、Amazon Athena、Amazon EventBridge と統合できます。CloudWatch Logs にイベントを送信するように CloudTrail を設定することができます。CloudWatch Logs のログインサイトはイベントを解析して分析します。これにより、呼び出しを行ったユーザーや IAM ロール、行われた API コールの数など、スロットリングイベントの詳細が特定されます。詳細については、「[Amazon CloudWatch Logs で CloudTrail ログファイルを監視する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)」を参照してください。
CloudWatch Logs Insights の詳細および、ログファイルのクエリ方法については、「[CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」を参照してください。
Amazon Athena では、標準 SQL を使用してクエリを作成し、データを分析できます。たとえば、Athena テーブルを作成して CloudTrail イベントを解析することができます。詳細については、「[CloudTrail コンソールを使用して CloudTrail ログ用 Athena テーブルを作成する](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#create-cloudtrail-table-ct)」を参照してください。
Athena テーブルを作成すると、次のような SQL クエリを使用して `ThrottlingException` エラーを調査できます。
*user-input* を独自の値に置き換えます。
```
select eventname, errorcode,eventsource,awsregion, useragent,COUNT(*) count
FROM cloudtrail_table-name
where errorcode = 'ThrottlingException'
AND eventtime between '2024-09-24T00:00:08Z' and '2024-09-23T23:15:08Z'
group by errorcode, awsregion, eventsource, useragent, eventname
order by count desc;
```
Amazon ECS は、Amazon EventBridge にもイベント通知を送信します。リソース状態変更イベントおよびサービスアクションイベントがあります。これらには、`ECS_OPERATION_THROTTLED`、`SERVICE_DISCOVERY_OPERATION_THROTTLED` などの API スロットリングイベントが含まれます。詳細については、「[Amazon ECS サービスアクションイベント](ecs_service_events.md)」を参照してください。
これらのイベントは、応答アクションを実行する目的で、AWS Lambda などのサービスによって利用される可能性があります。詳細については、「[Amazon ECS イベントの処理](ecs_cwet_handling.md)」を参照してください。
スタンドアロンタスクを実行する場合、`RunTask` などの一部の API 操作は非同期となり、再試行操作は自動的に実行されません。このような場合は、EventBridge と統合している AWS Step Functions などのサービスを使用して、スロットリングされた操作や失敗した操作を再試行できます。詳細については、「[コンテナタスクの管理 (Amazon ECS、Amazon SNS)](https://docs.aws.amazon.com/step-functions/latest/dg/sample-project-container-task-notification.html)」を参照してください。
## CloudWatch を使用してスロットリングを監視する
CloudWatch では、**[AWS リソース別]** で `Usage` ネームスペースの API 使用状況をモニタリングできます。これらのメトリクスは タイプ **[API]**、メトリック名 **[CallCount]** で記録されます。これらのメトリクスが特定のしきい値に達するたびに開始するアラームを作成できます。詳細については、「[サービスクォータの視覚化とアラームの設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html)」を参照してください。
CloudWatch には異常検出機能もあります。この機能は、機械学習を使用して、有効にしたメトリクスの特定の動作に基づいて分析し、ベースラインを確立します。異常な API アクティビティが発生した場合は、この機能を CloudWatch アラームと合わせて使用できます。詳細については、「[CloudWatch の異常検出の使用方法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)」を参照してください。
スロットリングエラーをプロアクティブにモニタリングすることで、サポート に連絡することで、関連するスロットリング制限を引き上げたり、アプリケーション固有のニーズに関するガイダンスを受けたりできます。
# Amazon ECS 自動スケーリングとキャパシティ管理におけるベストプラクティス
Amazon ECS では、全サイズのコンテナ化されたアプリケーションワークロードを実行できます。これには、最小限のテスト環境と、グローバル規模で運用される大規模な本番環境が含まれます。
Amazon ECS と併せて、すべての AWS サービスと同様に、使用した分だけお支払いいただきます。アプリケーションを適切に設計することで、必要なときに必要なリソースのみを消費することでコストを削減できます。
以下の推奨事項は、Amazon ECS ワークロードを実行してサービスレベルの目標を達成しつつ、費用対効果の高い運用を行う方法を示しています。
**Topics**
+ [Amazon ECS のタスクサイズの決定](capacity-tasksize-best-practice.md)
+ [Amazon ECS サービスの自動スケーリングの最適化](capacity-autoscaling-best-practice.md)
+ [Amazon ECS のキャパシティとアベイラビリティ](capacity-availability-best-practice.md)
+ [Amazon ECS クラスターのキャパシティ](capacity-cluster-best-practice.md)
+ [Amazon ECS の Fargate タスクサイズの選択](fargate-task-size-best-practice.md)
+ [Amazon EC2 でキャパシティプロバイダーを使用して Amazon ECS クラスターのキャパシティプロビジョニングを高速化する](capacity-cluster-speed-up-ec2-best-practice.md)
# Amazon ECS のタスクサイズの決定
Amazon ECS にコンテナをデプロイする際に、最も重要な選択項目の 1 つとなるのがコンテナとタスクのサイズです。コンテナサイズとタスクサイズは、スケーリングとキャパシティプランニングに不可欠な要素です。
Amazon ECS では、CPU とメモリの 2 種類のリソースメトリクスがキャパシティに使用されます。Amazon ECS では、CPU 量 は、フル vCPU の 1024 分の 1 の単位で測定されます (1024 ユニットは 1 つの全 vCPU に相当します)。Amazon ECS はメモリをメガバイト単位で測定します。
タスク定義では、リソースの予約と制限を宣言できます。
予約を宣言する際は、タスクに最低限必要な量のリソースを宣言します。タスクはリクエストに必要となる最低限の量のリソースを受け取ります。アプリケーションは、宣言された予約量よりも多くの CPU またはメモリを使用できる可能性があります。ただし、これには宣言した制限も適用されます。
予約量を超えるリソースを使用することをバーストと呼びます。バーストとは、アプリケーションが予約したよりも多くのリソースを使用するが、宣言された制限内にとどまることを意味します。Amazon ECS は、予約量を保証します。たとえば、Amazon EC2 インスタンスを使用してキャパシティを提供する場合、Amazon ECS は予約量を満たせないインスタンスにはタスクを課しません。
制限は、コンテナまたはタスクが使用できる CPU ユニットまたはメモリの最大量です。コンテナがこの制限よりも多くの CPU を使用しようとすると、Amazon ECS によってスロットリングされます。コンテナがこの制限よりも多くのメモリを使用しようとすると、Amazon ECS はコンテナを停止します。
これらの値の決定は簡単ではありません。アプリケーションに最も適した値は、そのアプリケーションのリソース要件に大きく依存します。
アプリケーションの負荷テストは、リソース要件をうまく計画する上で重要です。負荷テストは、アプリケーションの要件をよりよく理解するのに役立ちます。
## ステートレスアプリケーション
ロードバランサーの背後にあるアプリケーションなど、水平にスケーリングするタイプのステートレスアプリケーションでは、まずそのアプリケーションがリクエストを処理するときに消費するメモリの量がどの程度になるかを確認することをお勧めします。
そのためには、`ps` や `top` などの従来のツールを使用できます。CloudWatch Container Insights などのモニタリングソリューションを使用することもできます。
CPU 予約を決定する際には、ビジネス要件を満たすためにアプリケーションをどのようにスケーリングすべきかを考慮します。
256 CPU ユニット (つまりフル vCPU の 4 分の 1) などの小さめの CPU 予約を行うことで、コストを最小限に抑えながらきめ細かくスケールアウトできます。ただし、需要が急増した時にスケーリング速度が追い付かない可能性があります。
より大きな CPU 予約量を使用すると、より迅速にスケールインおよびスケールアウトできます。これにより、需要の急増に迅速に対応できます。ただし、CPU の予約量が多いほどコストが高くなります。
## その他のアプリケーション
シングルトンワーカーやデータベースサーバーなど、水平にスケーリングしないタイプのアプリケーションでは、利用可能な容量とコストが最も重要な考慮事項となります。
トラフィックを処理し、サービスレベル目標を達成するためには、負荷テストの結果を確認したうえで必要なメモリと CPU の量を決定します。Amazon ECS は、アプリケーションが十分な容量のあるホストに確実に配置されるようにします。
# Amazon ECS サービスの自動スケーリングの最適化
Amazon ECS サービスは管理されたタスクのコレクションです。各サービスには、関連するタスク定義、必要なタスク数、オプションの配置戦略があります。
Amazon ECS サービスの自動スケーリングは、アプリケーション自動スケーリングサービスを通して行われます。Application Auto Scaling は CloudWatch メトリクスをスケーリングメトリクスのソースとして使用します。また、CloudWatch アラームを使用して、サービスをスケールインまたはスケールアウトするタイミングのしきい値を設定します。
スケーリングのしきい値を指定します。メトリクスターゲットを設定できます。これは*ターゲット追跡スケーリング*と呼ばれています。しきい値を指定することもできます。これは*ステップスケーリング*と呼ばれています。
アプリケーション自動スケーリングを設定した後、サービスに必要となる適切なタスク数が継続的に計算されます。また、必要なタスク数を変更する必要がある場合、スケールアウトまたはスケールインによって Amazon ECS に通知します。
サービスの自動スケーリングを効果的に使用するには、適切なスケーリングメトリクスを選択する必要があります。メトリクスの選択方法については、以下のセクションで説明します。
## アプリケーションの特徴付け
アプリケーションを適切にスケーリングするには、アプリケーションをスケールインする条件とスケールアウトするタイミングを知る必要があります。
基本的に、需要がキャパシティを上回ると予測される場合は、アプリケーションをスケールアウトする必要があります。逆に、リソースが需要を上回る場合は、アプリケーションをスケールインすることでコストを節約できます。
### 使用率メトリクスの特定
効果的にスケーリングするには、使用率または飽和度を示すメトリクスを特定する必要があります。このメトリクスがスケーリングに役立つためには、以下の特性を備えている必要があります。
+ メトリクスは需要と相関している必要があります。リソースを一定に保っていても需要が変化する場合は、メトリクスの値も変化させる必要があります。需要が増減すると、メトリクスも増減します。
+ メトリクスの値はキャパシティに比例してスケールインする必要があります。需要が一定であれば、リソースを追加すると、メトリクスの値も比例して変化する必要があります。そのため、タスクの数を 2 倍にすると、指標は 50% 減少するはずです。
使用率メトリクスを特定する最良の方法は、ステージング環境などの実稼働前の環境で負荷テストを行うことです。商用およびオープンソースの負荷テストソリューションは広く利用可能です。これらのソリューションは通常、合成負荷を生成することも、実際のユーザートラフィックをシミュレートすることもできます。
負荷テストのプロセスを開始するには、アプリケーションの使用率メトリクスを表示するダッシュボードを最初に構築する必要があります。これらのメトリクスには、CPU 使用率、メモリ使用率、I/O 操作、I/O キューの深さ、ネットワークスループットが含まれます。これらのメトリクスは CloudWatch Container Insights などのサービスを使用して収集できます。また、Amazon Managed Grafana と一緒に Amazon Managed Service for Prometheus を使用して収集することもできます。このプロセスでは、アプリケーションの応答時間や作業完了率に関するメトリクスを必ず収集してプロットしてください。
負荷テストを実施する際は、まず小さなリクエストまたはジョブ挿入率から開始します。アプリケーションがウォームアップできるように、このレートを数分間一定に保ってください。その後、速度をゆっくりと上げて、数分間一定に保ちます。アプリケーションの応答時間または完了時間が遅すぎてサービスレベル目標 (SLO) を達成できなくなるまで、このサイクルを繰り返し、その都度レートを上げていきます。
負荷テストを行う際には、各使用率メトリクスを調べます。負荷とともに増加するメトリクスは、最適な使用率メトリクスとして役立つ最有力候補です。
次に、飽和状態に達しているリソースを特定します。同時に、使用率メトリクスを調べて、最初に高いレベルで横ばいになったものを調べます。または、ピークに達して最初にアプリケーションをクラッシュさせるものを調べます。たとえば、負荷を追加するにつれて CPU 使用率が 0% から 70 ～ 80% に増加し、さらに多くの負荷を追加してもそのレベルにとどまる場合は、CPU が飽和状態であると言えます。CPU アーキテクチャによっては、100% に達しない可能性があります。たとえば、負荷を追加するとメモリ使用率が増加し、タスクまたは Amazon EC2 インスタンスのメモリ制限に達するとアプリケーションが突然クラッシュしたとします。このような状況では、メモリが完全に消費された可能性があります。アプリケーションが複数のリソースを消費する可能性があります。そのため、最初に枯渇したリソースを表すメトリクスを選択します。
最後に、タスクまたは Amazon EC2 インスタンスの数を 2 倍にしてから、負荷テストを再試行します。キーメトリクスが以前の半分の速度で、増加または減少すると仮定します。この場合、メトリクスはキャパシティに比例します。これは自動スケーリングに適した使用率メトリクスです。
次に、この架空のシナリオを考えてみましょう。アプリケーションの負荷テストを行い、1 秒あたり 100 リクエストで CPU 使用率が最終的に 80% に達したとします。負荷を追加しても、CPU 使用率は上昇しなくなります。ただし、アプリケーションの応答は遅くなります。次に、負荷テストを再度実行して、タスクの数を 2 倍にしますが、速度は以前のピーク値に保たれます。CPU の平均使用率が約 40% に低下した場合、CPU 平均使用率がスケーリングメトリクスの候補として適しています。一方、タスク数を増やしても CPU 使用率が 80% のままであれば、平均 CPU 使用率は適切なスケーリング指標ではありません。その場合は、適切なメトリクスを見つけるためにさらに調査する必要があります。
### 一般的なアプリケーションモデルおよびスケーリングプロパティ
あらゆる種類のソフトウェアを AWS で実行できます。多くのワークロードは自社開発ですが、他のワークロードは一般的なオープンソースソフトウェアをベースにしています。その出所に関係なく、サービスの一般的なデザインパターンがいくつか確認されています。どの方法で効果的にスケーリングできるかは、そのパターンに大きく依存します。
#### 効率的な CPU バウンドサーバー
効率的な CPU バウンドサーバーは、CPU とネットワークスループット以外のリソースをほとんど使用しません。各リクエストはアプリケーションだけで処理できます。リクエストはデータベースなど他のサービスには依存しません。アプリケーションは何十万もの同時リクエストを処理でき、そのために複数の CPU を効率的に活用できます。各リクエストは、メモリーオーバーヘッドの少ない専用スレッドによって処理されるか、リクエストを処理する各 CPU で実行される非同期イベントループによって処理されます。アプリケーションの各レプリカは、同じようにリクエストを処理できます。CPU が枯渇する前に枯渇する可能性のあるリソースは、ネットワーク帯域幅のみです。CPU バウンドサービスでは、ピークスループットでもメモリ使用率は、利用可能なリソースのほんの一部です。
このタイプのアプリケーションには、CPU ベースの自動スケーリングを使用できます。このアプリケーションはスケーリングに関して最大限の柔軟性を備えています。より大きな Amazon EC2 インスタンスまたは Fargate vCPU を提供することで、垂直方向にスケーリングできます。また、レプリカをさらに追加することで、水平方向にスケールすることもできます。レプリカを追加したり、インスタンスサイズを 2 倍にしたりすると、容量に対する平均 CPU 使用率が半分に削減されます。
このアプリケーションに Amazon EC2 の容量を使用している場合は、`c5` または `c6g` ファミリーなどのコンピューティング最適化インスタンスに配置することを検討してください。
#### 効率的なメモリバウンドサーバー
効率的なメモリバウンドサーバーは、リクエストごとに大量のメモリを割り当てます。同時実行性が最大になると、必ずしもスループットが高くなるわけではありませんが、CPU リソースが使い果たされる前にメモリが使い果たされます。リクエストに関連するメモリは、リクエストが終了すると解放されます。メモリに余裕がある限り、追加のリクエストを受け付けることができます。
このタイプのアプリケーションには、メモリベースの自動スケーリングを使用できます。このアプリケーションはスケーリングに関して最大限の柔軟性を備えています。より大きな Amazon EC2 または Fargate メモリリソースを提供することで、両方を垂直方向にスケーリングできます。また、レプリカをさらに追加することで、水平方向にスケールすることもできます。レプリカを追加したり、インスタンスサイズを 2 倍にしたりすると、容量に対する平均メモリ使用率を半分に減らすことができます。
このアプリケーションに Amazon EC2 キャパシティを使用している場合は、`r5` または `r6g` ファミリーなどのメモリ最適化インスタンスにキャパシティを割り当てることを検討してください。
メモリに制約のあるアプリケーションの中には、同時実行数を減らしても使用されるメモリが減らないように、リクエストの終了時にそのリクエストに関連するメモリを解放しないものがあります。このため、メモリベースのスケーリングを使用することはお勧めしません。
#### ワーカーベースのサーバー
ワーカーベースのサーバーは、個々のワーカースレッドごとに 1 つのリクエストを次々に処理します。ワーカースレッドは POSIX スレッドなどの軽量スレッドでもかまいません。UNIX プロセスなど、より負荷の大きいスレッドの場合もあります。どのスレッドであっても、アプリケーションがサポートできる同時実行数は常に最大です。通常、同時実行数の制限は、使用可能なメモリリソースに比例して設定されます。同時実行数の上限に達すると、アプリケーションにより、追加のリクエストはバックログキューに入れられます。バックログキューがオーバーフローすると、アプリケーションはそれ以降の受信リクエストを直ちに拒否します。このパターンに当てはまる一般的なアプリケーションには、Apache Web サーバーや Gunicorn などがあります。
このアプリケーションを拡張するには、通常、リクエストの同時実行性が最適なメトリクスです。各レプリカには同時実行数の制限があるため、平均制限に達する前にスケールアウトすることが重要です。
リクエストの同時実行メトリクスを取得する最良の方法は、アプリケーションに CloudWatch にレポートさせることです。アプリケーションの各レプリカは、同時リクエストの数をカスタムメトリクスとして高い頻度で公開できます。この頻度は少なくとも 1 分に 1 回に設定することをおすすめします。複数のレポートを収集したら、平均同時実行数をスケーリングメトリクスとして使用できます。このメトリクスは、同時実行数の合計をレプリカ数で割って算出します。たとえば、同時実行数の合計が 1000 で、レプリカの数が 10 の場合、平均同時実行数は 100 です。
アプリケーションが Application Load Balancer の背後にある場合は、ロードバランサーの `ActiveConnectionCount` メトリクスをスケーリングメトリクスの要素として使用することもできます。平均値を求めるには、`ActiveConnectionCount` メトリクスをレプリカの数で割る必要があります。スケーリングには未加工のカウント値ではなく、平均値を使用する必要があります。
この設計を最適に機能させるには、リクエストレートが低い場合でも応答レイテンシの標準偏差を小さくする必要があります。需要が少ない時期には、ほとんどのリクエストに短時間で回答し、平均応答時間よりも大幅に時間がかかるリクエストは多くないことをお勧めします。平均応答時間は 95 パーセンタイル応答時間に近くなります。そうしないと、結果としてキューオーバーフローが発生する可能性があります。これはエラーにつながります。オーバーフローのリスクを軽減するために、必要に応じて追加のレプリカを提供することをお勧めします。
#### 待機中のサーバー
待機中のサーバーはリクエストごとに何らかの処理を行いますが、機能するには 1 つ以上のダウンストリームサービスに大きく依存しています。コンテナアプリケーションは多くの場合、データベースやその他の API サービスなどのダウンストリームサービスを多用します。特に大容量または同時実行の多いシナリオでは、これらのサービスが応答するまでに時間がかかることがあります。これは、これらのアプリケーションが CPU リソースをほとんど使用せず、使用可能なメモリの観点から最大限の同時実行性を利用する傾向があるためです。
待機サービスは、アプリケーションの設計方法に応じて、メモリーバウンドのサーバーパターンとワーカーベースのサーバーパターンのどちらにも適しています。アプリケーションの同時実行がメモリによってのみ制限される場合は、平均メモリ使用率をスケーリングメトリクスとして使用する必要があります。アプリケーションの同時実行がワーカーの制限に基づいている場合は、平均同時実行数をスケーリングメトリクスとして使用する必要があります。
#### Java ベースのサーバー
Java ベースのサーバーが CPU に依存し、CPU リソースに比例してスケーリングする場合は、効率的な CPU バウンドのサーバーパターンに適している場合があります。その場合は、平均 CPU 使用率がスケーリングメトリクスとして適切である場合があります。ただし、多くの Java アプリケーションは CPU に依存していないため、スケーリングが困難です。
最高のパフォーマンスを得るには、Java 仮想マシン (JVM) ヒープにできるだけ多くのメモリーを割り当てることをお勧めします。Java 8 update 191 以降を含む最近のバージョンの JVM では、コンテナに収まるようにヒープサイズをできるだけ大きく自動的に設定しています。つまり、Java では、メモリー使用率がアプリケーション使用率に比例することはほとんどありません。要求率と同時実行数が増加しても、メモリ使用率は一定に保たれます。このため、メモリー使用率に基づいて Java ベースのサーバーをスケーリングすることはお勧めしません。代わりに、通常は CPU 使用率に基づいてスケーリングすることをおすすめします。
Java ベースのサーバーでは、CPU を使い果たす前にヒープが枯渇することがあります。同時実行数が多いとアプリケーションがヒープを使い果たしやすい場合は、平均接続数が最適なスケーリングメトリクスです。アプリケーションが高スループットでヒープを使い果たしやすい場合は、平均リクエストレートが最適なスケーリングメトリクスです。
#### ガベージコレクションされた他のランタイムを使用するサーバー
多くのサーバーアプリケーションは、.NET や Ruby などのガベージコレクションを実行するランタイムをベースにしています。これらのサーバーアプリケーションは、前述のパターンのいずれかに当てはまります。ただし、Java の場合と同様に、これらのアプリケーションの平均メモリ使用率はスループットや同時実行性と相関関係がないことが多いため、メモリに基づいてアプリケーションをスケーリングすることはお勧めしません。
このようなアプリケーションでは、アプリケーションが CPU に制約されている場合は CPU 使用率に基づいてスケールすることをおすすめします。それ以外の場合は、負荷テストの結果に基づいて、平均スループットまたは平均同時実行性を基準にスケーリングすることをお勧めします。
#### ジョブプロセッサ
多くのワークロードには非同期のジョブ処理が含まれます。その中には、リクエストをリアルタイムで受信せず、代わりにワークキューにサブスクライブしてジョブを受け取るアプリケーションが含まれます。この種のアプリケーションでは、ほとんどの場合、適切なスケーリング指標はキューの深さです。キューの増加は、保留中の作業が処理能力を上回っていることを示しているのに対し、キューが空の場合は、実行すべき作業よりも容量が多いことを示します。
Amazon SQS や Amazon Kinesis Data Streams などの AWS メッセージングサービスは、スケーリングに使用できる CloudWatch メトリクスを提供します。Amazon SQS では、`ApproximateNumberOfMessagesVisible` が最適なメトリクスです。Kinesis Data Streams では、Kinesis Client Library (KCL) が公開している `MillisBehindLatest` メトリクスの使用を検討してください。このメトリクスは、スケーリングに使用する前に、すべてのコンシューマで平均化する必要があります。
# Amazon ECS のキャパシティとアベイラビリティ
アプリケーションの可用性は、エラーのないエクスペリエンスを提供し、アプリケーションのレイテンシーを最小限に抑えるために不可欠です。可用性を確保するには、アクセス可能で需要を満たすのに十分なキャパシティーを持つリソースが必要です。AWS では、可用性を管理するためのいくつかのメカニズムが用意されています。Amazon ECS でホストされるアプリケーションの場合、自動スケーリングやアベイラビリティーゾーン (AZ) などがあります。自動スケーリングは、定義したメトリクスに基づいてタスクやインスタンスの数を管理します。一方、アベイラビリティーゾーンを使用すると、分離されているが地理的に近い場所でアプリケーションをホストできます。
タスクサイズと同様に、キャパシティーと可用性には考慮する必要がある特定のトレードオフが存在します。理想は、キャパシティーと需要が完全に一致することです。低レイテンシーやエラー率などのサービスレベル目標 (SLO) を満たすために、リクエストを処理し、ジョブを処理するのに十分なキャパシティーが常に確保されます。キャパシティーが大きすぎて過度のコストがかかったり、キャパシティーが小さすぎてレイテンシーやエラー率が高くなったりすることはありません。
自動スケーリングは潜在的なプロセスです。まず、CloudWatch はリアルタイムメトリクスを受信する必要があります。次に、CloudWatch は、メトリクスを分析するためにこれらを集計する必要があります。メトリクスの詳細度によっては数分かかる場合があります。CloudWatch は、メトリクスをアラームのしきい値と比較して、リソースの不足や超過を特定します。不安定な状態を回避するために、設定されたしきい値を超えた状態が数分間続いたらアラームが作動するようにアラームを設定する必要があります。また、新しいタスクをプロビジョニングしたり、不要になったタスクを終了したりするのにも時間がかかります。
システムでこのような遅延が発生する可能性があるため、オーバープロビジョニングしてある程度の余裕を維持する必要があります。オーバープロビジョニングは、短期的な需要の急増に対応するのに役立ちます。また、アプリケーションを飽和状態に達させずに追加のリクエストを処理するのにも役立ちます。スケーリングのターゲットは、使用率の 60～80 % に設定することをお勧めします。これにより、追加のキャパシティーがプロビジョニングされている間も、アプリケーションは追加需要の急増をより適切に処理できるようになります。
オーバープロビジョニングが推奨されるもう 1 つの理由は、アベイラビリティーゾーンの障害に迅速に対応できるようになることです。AWS では、本番ワークロードを複数のアベイラビリティーゾーンから提供することをお勧めします。これは、1 つのアベイラビリティーゾーンに障害が発生した場合でも、残りのアベイラビリティーゾーンで実行されているタスクが引き続き需要を処理できるためです。アプリケーションが 2 つのアベイラビリティーゾーンで実行されている場合は、通常のタスク数を 2 倍にする必要があります。これは、潜在的な障害の発生時に即時にキャパシティーを提供できるようにするためです。アプリケーションが 3 つのアベイラビリティーゾーンで実行されている場合は、通常のタスク数の 1.5 倍を実行することをお勧めします。つまり、通常のサービス提供に必要な 2 つのタスクごとに 3 つのタスクを実行します。
## スケーリング速度の最大化
自動スケーリングは事後対応型プロセスであるため、効果が現れるまでに時間がかかります。ただし、スケールアウトに必要な時間を最小限に抑えるための方法がいくつかあります。
**イメージサイズを最小限に抑えます。**イメージが大きいほど、イメージリポジトリからのダウンロードと解凍にかかる時間が長くなります。したがって、イメージサイズを小さくすることで、コンテナの起動に必要な時間が短縮されます。イメージサイズを小さくするには、以下の特定の推奨事項に従ってください。
+ 静的バイナリを構築できるか、Golang を使用する場合は、イメージを`FROM`ゼロから構築し、作成されたイメージにバイナリアプリケーションのみを含めます。
+ Amazon Linux や Ubuntu など、アップストリームのディストリビューションベンダーが提供する最小限のベースイメージを使用します。
+ 最終イメージにはビルドアーティファクトを含めないでください。マルチステージビルドを使用することで、これを実現できます。
+ 可能な限り、`RUN` ステージをコンパクトにします。各 `RUN` ステージで新しいイメージレイヤーが作成され、そのレイヤーをダウンロードするための追加のラウンドトリップが発生します。`&&` によって複数のコマンドが結合された単一の `RUN` ステージでは、複数の `RUN` ステージの場合よりレイヤーが少なくなります。
+ 最終イメージに ML 推論データなどのデータを含める場合は、起動とトラフィック処理の開始に必要なデータのみを含めます。サービスに影響を与えずに Amazon S3 または他のストレージからオンデマンドでデータを取得する場合は、代わりにそれらの場所にデータを保存します。
**イメージを近くに保持します。**ネットワークレイテンシーが高いほど、イメージのダウンロードにかかる時間が長くなります。ワークロードと同じ AWS リージョンのリポジトリでイメージをホストします。Amazon ECR は、Amazon ECS を使用可能なすべてのリージョンで使用できる高性能のイメージリポジトリです。インターネットや VPN リンクを経由してコンテナイメージをダウンロードすることは避けてください。同じリージョンでイメージをホストすることで、全体的な信頼性が向上します。これにより、別のリージョンでネットワーク接続の問題や可用性の問題が発生するリスクを軽減できます。または、Amazon ECR クロスリージョンレプリケーションを実装して、これを実現することもできます。
**ロードバランサーのヘルスチェックのしきい値を下げます。**ロードバランサーは、アプリケーションにトラフィックを送信する前にヘルスチェックを実行します。ターゲットグループのデフォルトのヘルスチェック設定には、90 秒以上かかる場合があります。この間に、ロードバランサーはヘルスステータスをチェックし、リクエストを受信します。ヘルスチェックの間隔としきい値のカウントを下げることで、アプリケーションがトラフィックをより迅速に受け入れ、他のタスクの負荷を減らすことができます。
**コールドスタートのパフォーマンスを考慮します。**一部のアプリケーションでは、Java などのランタイムを使用してジャストインタイム (JIT) コンパイルを実行します。コンパイルプロセスは、少なくとも開始時に、アプリケーションのパフォーマンスを示すことができます。回避策は、レイテンシーが重要となるワークロードの部分を、コールドスタート時にパフォーマンスの低下を引き起こさない言語で書き換えることです。
**ターゲット追跡スケーリングポリシーではなく、ステップスケーリングポリシーを使用します。**Amazon ECS タスクには、いくつかの Application Auto Scaling オプションがあります。ターゲットトラッキングは最も使いやすいモードです。これにより、CPU 平均使用率などのメトリクスの目標値を設定するだけです。次に、オートスケーラーは、その値を達成するために必要なタスクの数を自動的に管理します。ステップスケーリングを使用すると、スケーリングメトリクスの特定のしきい値と、しきい値を超えたときに追加または削除するタスクの数を定義できるため、需要の変化に迅速に対応できます。さらに重要なことは、しきい値アラームが超過する時間を最小限に抑えることで、需要の変化に非常に迅速に対応できることです。詳細については、*Amazon Elastic Container Service デベロッパーガイド*の「[サービスのオートスケーリング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)」を参照してください。
Amazon EC2 インスタンスを使用してクラスターキャパシティーを提供する場合は、以下の推奨事項を考慮してください。
**より大きい Amazon EC2 インスタンスと、より高速な Amazon EBS ボリュームを使用します。**より大きい Amazon EC2 インスタンスとより高速な Amazon EBS ボリュームを使用することで、イメージのダウンロードと準備の速度を向上させることができます。特定の Amazon EC2 インスタンスファミリー内では、インスタンスサイズが大きくなると、ネットワークと Amazon EBS の最大スループットが増加します (例えば、`m5.xlarge` から `m5.2xlarge`)。さらに、Amazon EBS ボリュームをカスタマイズして、そのスループットと IOPS を向上させることもできます。例えば、`gp2` ボリュームを使用する場合は、より大きいボリュームを使用すると、ベースラインスループットが高くなります。`gp3` ボリュームを使用する場合は、ボリュームの作成時にスループットと IOPS を指定します。
**Amazon EC2 インスタンスで実行されるタスクには、ブリッジネットワークモードを使用します。**Amazon EC2 で `bridge` ネットワークモードを使用するタスクは、`awsvpc` ネットワークモードを使用するタスクよりも速く開始されます。`awsvpc` ネットワークモードを使用すると、Amazon ECS はタスクを起動する前に Elastic Network Interface (ENI) をインスタンスにアタッチします。これにより、レイテンシーが大きくなります。ただし、ブリッジネットワークの使用には、いくつかのトレードオフがあります。これらのタスクは独自のセキュリティグループを取得しないため、ロードバランシングにいくつかの影響を及ぼします。詳細については、「*Elastic Load Balancing ユーザーガイド*」の「[Load balancer target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html)」を参照してください。
## 需要ショックへの対処
一部のアプリケーションでは、需要が急激に増大することがあります。これは、ニュースイベント、大セール、メディアイベント、急速に拡散されるその他のイベント (トラフィックが非常に短期間で急速かつ大幅に増加する原因となる) など、さまざまな理由で発生します。計画外の場合、これによって使用可能なリソースを需要が急速に上回る可能性があります。
需要ショックに対処する最善の方法は、それらを予測して適切に計画することです。自動スケーリングには時間がかかる場合があるため、需要ショックが始まる前にアプリケーションをスケールアウトすることをお勧めします。最良の結果を得るために、共有カレンダーを使用するチーム間の緊密なコラボレーションを含むビジネス計画を立てることをお勧めします。イベントを計画しているチームは、事前にアプリケーションを担当するチームと緊密に連携する必要があります。これにより、そのチームは明確なスケジューリング計画を立てるのに十分な時間を確保できます。イベント前にスケールアウトし、イベント後にスケールインするキャパシティーをスケジュールできます。詳細については、「*Application Auto Scaling ユーザーガイド*」の「[スケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)」を参照してください。
エンタープライズサポートプランをご利用の場合は、テクニカルアカウントマネージャー (TAM) とも連携してください。TAM はサービスクォータを検証し、イベントの開始前に必要なクォータが引き上げられるようにします。これにより、誤ってサービスクォータに達することがなくなります。また、ロードバランサーなどのサービスを事前準備して、イベントがスムーズに進行するように支援することもできます。
予定外の需要ショックに対処することは、より難しい問題です。予定外のショックが発生し、その振幅が非常に大きい場合、需要がすぐにキャパシティーを超える可能性があります。また、自動スケーリングが反応する能力を上回る可能性もあります。予定外のショックに備える最善の方法は、リソースをオーバープロビジョニングすることです。予想される最大トラフィック需要をいつでも処理できる十分なリソースを確保しておく必要があります。
予定外の需要ショックに備えて最大キャパシティーを維持すると、コストがかかる可能性があります。コストへの影響を軽減するには、大きな需要ショックが差し迫っていることを予測する先行指標となるメトリクスやイベントを見つけます。メトリクスやイベントによって十分な事前通知が確実に提供される場合、イベントが発生したとき、またはメトリクスが設定した特定のしきい値を超えたときには、すぐにスケールアウトプロセスを開始してください。
アプリケーションが突然の予定外の需要ショックを受けやすい場合は、高性能モードをアプリケーションに追加することを検討してください。このモードでは、重要ではない機能を犠牲にして、顧客にとって重要な機能を保持します。例えば、ご使用のアプリケーションでは、コストがかかる高価なカスタマイズされたレスポンスの生成から静的レスポンスページの提供に切り替えることができるとします。このシナリオでは、アプリケーションをまったくスケーリングせずに、スループットを大幅に向上させることができます。
最後に、需要ショックにより適切に対処するために、モノリシックサービスを分割することを検討できます。ご使用のアプリケーションが、実行にコストがかかり、スケーリングに時間がかかるモノリシックサービスである場合、パフォーマンスが重要となる部分を抽出または書き換えて、別のサービスとして実行できる可能性があります。これらの新しいサービスは、重要度の低いコンポーネントから独立してスケーリングできます。パフォーマンスが重要となる機能をアプリケーションの他の部分とは別にスケールアウトする柔軟性を持つことで、キャパシティーの追加にかかる時間の短縮とコストの削減の両方を実現できます。
# Amazon ECS クラスターのキャパシティ
Amazon ECS クラスターに容量を提供するには、いくつかの方法があります。例えば、Amazon EC2 インスタンスを起動し、Amazon ECS コンテナエージェントを使用して起動時にクラスターに登録できます。ただし、スケーリングを自分で管理する必要があるため、この方法は難しい場合があります。そのため、Amazon ECS キャパシティプロバイダーを使用することをお勧めします。キャパシティプロバイダーがリソースのスケーリングを管理します。Amazon EC2、Fargate、Fargate Spot の 3 種類のキャパシティプロバイダーがあります。Fargate キャパシティプロバイダーの詳細については、「[Amazon ECS clusters for Fargate workloads](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html)」を参照し、EC2 ワークロードについては、「[Amazon ECS clusters for EC2 workloads](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html)」を参照してください。
Fargate および Fargate Spot のキャパシティプロバイダーは、Fargate タスクのライフサイクルをユーザーに代わって処理します。Fargate はオンデマンド容量を提供し、Fargate Spot はスポット容量を提供します。タスクを起動すると、Amazon ECS はユーザーに代わって Fargate リソースをプロビジョニングします。この Fargate リソースには、タスク定義で宣言したタスクレベルの制限に直接対応するメモリと CPU ユニットが付属しています。各タスクは独自の Fargate リソースを受け取り、タスクとコンピューティングリソースの間に 1:1 の関係が作成されます。
Fargate Spot で実行されるタスクは中断される可能性があります。中断は 2 分間の警告の後に発生します。これらは、需要が高い時間帯に発生します。Fargate Spot は、バッチジョブ、開発環境、ステージング環境などの中断に対して耐性のあるワークロードに最適です。また、高いアベイラビリティと低い待機時間が要件ではない他のすべてのシナリオにも適しています。
Fargate Spot タスクは、Fargate オンデマンドタスクと一緒に実行できます。これらを一緒に使用することで、プロビジョンの「バースト」キャパシティを低コストで受け取ることができます。
Amazon ECS では、タスクの Amazon EC2 インスタンス容量を管理することもできます。各 Amazon EC2 キャパシティプロバイダーは、指定した Amazon EC2 Auto Scaling グループに関連付けられます。Amazon EC2 キャパシティプロバイダーを使用する場合、クラスターの自動スケーリングは Amazon EC2 Auto Scaling グループのサイズを維持して、スケジュールされたすべてのタスクを配置できるようにします。
# Amazon ECS の Fargate タスクサイズの選択
AWS Fargate タスク定義では、タスクレベルで CPU とメモリを指定する必要があり、オーバーヘッドを考慮する必要はありません。また、コンテナレベルで Fargate タスクの CPU とメモリを指定することもできます。ただし、この設定は必須ではありません。リソース制限は、宣言した予約量以上の値である必要があります。ほとんどの場合、タスク定義で宣言されている各コンテナの予約量の合計に設定できます。次に、その数値を最も近い Fargate サイズに切り上げます。使用可能なサイズの詳細については、「[タスク CPU とメモリ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-size)」を参照してください。
# Amazon EC2 でキャパシティプロバイダーを使用して Amazon ECS クラスターのキャパシティプロビジョニングを高速化する
Amazon EC2 で Amazon ECS を実行するお客様は、[Amazon ECS Cluster Auto Scaling (CAS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html) を利用して Amazon EC2 Auto Scaling グループのスケーリングを管理できます。CAS を使用すると、ASG を自動的にスケールするように Amazon ECS を設定できるため、タスクの実行に集中できます。Amazon ECS により、追加の操作を必要とせずに、必要に応じて ASG をスケールインおよびスケールアウトできるようになります。Amazon ECS キャパシティープロバイダーは、アプリケーションの需要を満たすのに十分なコンテナインスタンスを確保することで、クラスター内のインフラストラクチャを管理するために使用されます。Amazon ECS CAS の仕組みについては、「[Amazon ECS クラスターの Auto Scaling を深く探る](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)」を参照してください。
CAS は、クラスターの容量を調節するにあたり、ASG との CloudWatch ベースの統合に依存するため、CloudWatch メトリクスの公開、メトリクス `CapacityProviderReservation` が CloudWatch アラーム (高と低の両方) に違反するまでの時間、および新しく起動された Amazon EC2 インスタンスがウォームアップするまでの時間に関連する固有のレイテンシーが存在します。以下のアクションを実行することで、CAS の応答性を高め、デプロイを高速化できます。
## キャパシティープロバイダーのステップスケーリングサイズ
Amazon ECS キャパシティープロバイダーは、最終的に、アプリケーションの需要に合わせてコンテナインスタンスを拡大/縮小します。Amazon ECS が起動するインスタンスの最小数は、デフォルトでは 1 に設定されています。そのため、保留中のタスクを配置するために複数のインスタンスが必要な場合は、デプロイにさらに時間がかかることがあります。Amazon ECS API を使用して [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) を増やすことで、Amazon ECS が一度にスケールインまたはスケールアウトするインスタンスの最小数を増やすことができます。[https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) が小さすぎると、一度にスケールインまたはスケールアウトされるコンテナインスタンスの数が制限され、デプロイが遅くなる可能性があります。
**注記**
この設定は現在、[https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) または [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API を使用することでのみ利用可能です。
## インスタンスのウォームアップ期間
インスタンスのウォームアップ期間は、新たに起動された Amazon EC2 インスタンスが Auto Scaling グループの CloudWatch メトリックスに反映されるまでの時間です。指定されたウォームアップ期間が終了すると、そのインスタンスは ASG の集計メトリクスにカウントされ、CAS は、必要なインスタンス数を推定するための次の計算ループへと進みます。
[https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod) のデフォルト値は 300 秒です。この値は [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) API または [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API を使用して小さい値に設定することで、スケーリングの応答性を向上させることができます。
## 予備のキャパシティー
キャパシティープロバイダーにタスクを配置するために使用できるコンテナインスタンスがない場合は、Amazon EC2 インスタンスをその場で起動してクラスターキャパシティーを増やし (スケールアウトし)、それらのインスタンスが起動するまで待ってからコンテナを起動する必要があります。これにより、タスクの起動レートが大幅に低下する可能性があります。ここでは 2 つのオプションがあります。
この場合、予備の Amazon EC2 キャパシティーを事前に起動してタスクを実行する準備をしておくことで、実質的なタスク起動レートを上げることができます。`Target Capacity` 設定を使用して、クラスターで予備のキャパシティーを保持するかどうかを指定できます。例えば、`Target Capacity` を 80 % に設定することで、クラスターに常に 20 % の予備のキャパシティーが必要であることを示します。この予備のキャパシティーにより、スタンドアロンタスクをすぐに起動できるようになり、タスクの起動がスロットリングされなくなります。このアプローチのトレードオフは、予備のクラスターキャパシティーを保持するコストが増加する可能性があることです。
検討できる代替アプローチは、キャパシティープロバイダーではなくサービスにヘッドルームを追加することです。つまり、予備のキャパシティーを起動するための `Target Capacity` 設定を小さくする代わりに、ターゲット追跡スケーリングメトリクス、またはサービス自動スケーリングのステップスケーリングのしきい値を変更することで、サービス内のレプリカの数を増やすことができます。このアプローチが有用なのはワークロードの急増に対してのみであり、新しいサービスをデプロイし、初めて 0 から N タスクに移行する場合には効果がないことに注意してください。関連するスケーリングポリシーの詳細については、「[Target Tracking Scaling Policies](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html)」または「[Step Scaling Policies](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html)」を参照してください。
# アカウント設定による Amazon ECS 機能へのアクセス
Amazon ECS アカウント設定に移動して、特定の機能をオプトインまたはオプトアウトできます。各 AWS リージョンについて、アカウントレベルまたは特定のユーザーまたはロールで、各アカウント設定をオプトインまたはオプトアウトすることができます。
次のいずれかの条件が関係する場合は、特定の機能をオプトインまたはオプトアウトすることが考えられます。
+ ユーザーまたはロールは、個々のアカウントのために特定のアカウント設定をオプトインまたはオプトアウトできます。
+ ユーザーまたはロールはアカウントのすべてのユーザーに対してデフォルトのオプトインまたはオプトアウト設定を定義できます。
+ ルートユーザーまたは管理者権限を持つユーザーは、アカウントの任意の種類のロールまたはユーザーについて、オプトインまたはオプトアウトすることができます。ルートユーザーのアカウント設定が変更されると、個別にアカウント設定が選択されなかったすべてのユーザーとロールに対してデフォルト値が設定されます。
**注記**
フェデレーションユーザーは、ルートユーザーのアカウント設定を想定しており、明示的にアカウント設定を個別に設定することはできません。
以下のアカウント設定を使用できます。アカウント設定ごとに、オプトインおよびオプトアウトする必要があります。
| リソース名 | 詳細情報 |
| --- | --- |
| containerInsights | [Container Insights](#container-insights-setting) |
| serviceLongArnFormat`taskLongArnFormat` `containerInstanceLongArnFormat` | [Amazon リソースネーム (ARN) と ID](#ecs-resource-ids) |
| tagResourceAuthorization | [タグ付け認可](#tag-resources-setting) |
| fargateFIPSMode | [AWS Fargate 連邦情報処理標準 (FIPS-140) コンプライアンス](#fips-setting) |
| fargateTaskRetirementWaitPeriod | [AWS Fargate タスク廃止の待機時間](#fargate-retirement-wait-time) |
| fargateEventWindows | [EC2 イベントウィンドウを使用した AWS Fargate タスクの廃止](#fargate-event-windows) |
| guardDutyActivate | [Runtime Monitoring (Amazon GuardDuty 統合)](#guard-duty-integration) |
| dualStackIPv6 | [デュアルスタック IPv6 VPC](#dual-stack-setting) |
| awsvpcTrunking | [Linux コンテナインスタンスのネットワークインターフェイスを増やす](#vpc-trunking-setting) |
| defaultLogDriverMode | [デフォルトのログドライバーモード](#default-log-driver-mode) |
## Amazon リソースネーム (ARN) と ID
Amazon ECS リソースの作成時に、各リソースには一意の Amazon リソースネーム (ARN) と一意のリソース識別子 (ID) が割り当てられます。コマンドラインツールまたは Amazon ECS API を使用して Amazon ECS を操作する場合、特定のコマンドにはリソース ARNまたはリソース ID が必要になります。例えば、タスクを停止するために [stop-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/stop-task.html) AWS CLI コマンドを使用する場合は、そのコマンドでタスクの ARN または ID を指定する必要があります。
Amazon ECS では、Amazon ECS サービス、タスク、コンテナインスタンスの Amazon リソース名 (ARN) とリソース ID の新しい形式が導入されました。各リソースタイプのオプトインステータスによって、リソースが使用する Amazon リソースネーム (ARN) の形式が決まります。そのリソースタイプのリソースタグ付けなどの機能を使用するには、新しい ARN の形式にオプトインする必要があります。
新しい Amazon リソースネーム (ARN) およびリソース ID の形式は、リージョンごとにオプトインおよびオプトアウトできます。現在、新しく作成されたアカウントはデフォルトでオプトインされています。
新形式の Amazon リソースネーム (ARN) およびリソース ID はいつでもオプトインまたはオプトアウトできます。オプトイン後、作成するすべての新しいリソースは新しい形式を使用します。
**注記**
リソース ID が作成後に変更することはありません。したがって、新しい形式をオプトインまたはオプトアウトしても、既存のリソース ID には影響しません。
以下のセクションでは、ARN およびリソース ID 形式がどのように変更されているかについて説明します。新しい形式への移行の詳細については、「[Amazon Elastic Container Service のよくある質問](https://aws.amazon.com/ecs/faqs/)」を参照してください。
**Amazon リソースネーム (ARN) 形式**
一部のリソースには、`production` という名前のサービスなど、わかりやすい名前があります。それ以外の場合は、Amazon リソースネーム (ARN) 形式を使用してリソースを指定する必要があります。Amazon ECS のタスク、サービス、およびコンテナインスタンスの新しい ARN 形式には、クラスター名が含まれます。新しい ARN 形式へのオプトインの詳細については、「[Amazon ECS アカウント設定の変更](ecs-modifying-longer-id-settings.md)」を参照してください。
各リソースタイプでの現在の形式と新しい形式を次の表に示しています。
| リソースタイプ | ARN |
| --- | --- |
| コンテナインスタンス | 現在: `arn:aws:ecs:region:aws_account_id:container-instance/container-instance-id` 新: `arn:aws:ecs:region:aws_account_id:container-instance/cluster-name/container-instance-id` |
| Amazon ECS サービス | 現在: `arn:aws:ecs:region:aws_account_id:service/service-name` 新: `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name` |
| Amazon ECS タスク | 現在: `arn:aws:ecs:region:aws_account_id:task/task-id` 新: `arn:aws:ecs:region:aws_account_id:task/cluster-name/task-id` |
**リソース ID の長さ**
リソース ID は文字と数字の一意の組み合わせです。新しいリソース ID 形式には、Amazon ECS タスクおよびコンテナインスタンス用の短い ID が含まれます。現在のリソース ID の形式の長さは 36 文字です。新しい ID は 32 文字の形式で、ハイフンは含まれません。新しい リソース ID 形式をオプトインする方法の詳細については、「[Amazon ECS アカウント設定の変更](ecs-modifying-longer-id-settings.md)」を参照してください。
デフォルトは `enabled` です。
オプトインした後に起動されたリソースだけが、新形式の ARN とリソース ID を受け取ります。既存のリソースは、いずれも影響を受けません。Amazon ECS サービスとタスクを新しい ARN およびリソース ID の形式に移行するには、サービスまたはタスクを再作成する必要があります。コンテナインスタンスを新しい ARN およびリソース ID 形式に移行するには、そのコンテナインスタンスを空にし、新規コンテナインスタンスを起動してクラスターに登録する必要があります。
**注記**
Amazon ECS サービスが 2018 年 11 月 16 日以降に作成されていて、そのサービスを作成したユーザーがタスクの新形式をオプトインしている場合、そのサービスによって起動されたタスクだけが新形式の ARN とリソース ID になります。
## ARN およびリソース ID 形式のタイムライン
新しい Amazon リソースネーム (ARN) と Amazon ECS リソースのリソース ID 形式のための、オプトインおよびオプトアウト期間のタイムラインは、2021 年 4 月 1 日に終了しました。デフォルトでは、すべてのアカウントが新しい形式にオプトインされています。新しく作成されたすべてのリソースには新しい形式が適用され、オプトアウトできなくなります。
## Container Insights
2024 年 12 月 2 日、AWS で Amazon ECS 用にオブザーバビリティが強化された Container Insights がリリースされました。このバージョンでは、Fargate Amazon ECS マネージドインスタンスと EC2 を使用して Amazon ECS クラスター用に強化されたオブザーバビリティがサポートされます。Amazon ECS でオブザーバビリティが強化された Container Insights を設定したら、Container Insights は環境内のクラスターレベルからコンテナレベルまでの詳細なインフラストラクチャテレメトリを自動収集し、さまざまなメトリクスとディメンションを示すダッシュボードにデータを表示します。その後、Container Insights コンソールでこれらのすぐに使えるダッシュボードを使用して、コンテナの健全性とパフォーマンスをよりよく理解し、異常を特定することで問題を迅速に軽減することができます。
コンテナ環境で詳細な可視性を提供し、解決までの平均時間を短縮するため、Container Insights ではなく、オブザーバビリティが強化された Container Insights を使用することをお勧めします。詳細については、「*Amazon CloudWatchユーザーガイド*」の「[Amazon ECS 用にオブザーバビリティメトリクスが強化された Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-enhanced-observability-metrics-ECS.html)」を参照してください。
`containerInsights` アカウントのデフォルトは、`disabled` です。
### オブザーバビリティが強化された Container Insights
次のコマンドを使用し、オブザーバビリティが強化された Container Insights を有効にします。
`containerInsights` アカウント設定を `enhanced` に設定します。
```
aws ecs put-account-setting --name containerInsights --value enhanced
```
出力の例
```
{
"setting": {
"name": "containerInsights",
"value": "enhanced",
"principalArn": "arn:aws:iam::123456789012:johndoe",
"type": user
}
}
```
このアカウント設定を行ったら、すべての新しいクラスターはオブザーバビリティが強化された Container Insights を自動的に使用します。`update-cluster-settings` コマンドを使用してオブザーバビリティが強化された Container Insights を既存のクラスターに追加するか、Container Insightsからオブザーバビリティが強化されたContainer Insightsにクラスターをアップグレードします。
```
aws ecs update-cluster-settings --cluster cluster-name --settings name=containerInsights,value=enhanced
```
コンソールを使用して、オブザーバビリティが強化された Container Insights を設定することもできます。詳細については、「[Amazon ECS アカウント設定の変更](ecs-modifying-longer-id-settings.md)」を参照してください。
### Container Insights
`containerInsights` アカウント設定を `enabled` に設定すると、すべての新しいクラスターはデフォルトで Container Insights が有効になります。`update-cluster-settings` を使用して既存のクラスターを変更できます。
Container Insights を使用するには、`containerInsights` アカウント設定を `enabled` に設定します。次のコマンドを使用して Container Insights を有効にします。
```
aws ecs put-account-setting --name containerInsights --value enabled
```
出力の例
```
{
"setting": {
"name": "containerInsights",
"value": "enabled",
"principalArn": "arn:aws:iam::123456789012:johndoe",
"type": user
}
}
```
`containerInsights` アカウント設定を `enabled` に設定すると、すべての新しいクラスターはデフォルトで Container Insights が有効になります。`update-cluster-settings` コマンドを使用して Container Insights を既存のクラスターに追加します。
```
aws ecs update-cluster-settings --cluster cluster-name --settings name=containerInsights,value=enabled
```
コンソールを使用して Container Insights を設定することもできます。詳細については、「[Amazon ECS アカウント設定の変更](ecs-modifying-longer-id-settings.md)」を参照してください。
## AWS Fargate 連邦情報処理標準 (FIPS-140) コンプライアンス
Fargate は、機密情報を保護する暗号モジュールのセキュリティ要件を指定する連邦情報処理標準 (FIPS-140) をサポートしています。これは現在の米国およびカナダの政府標準であり、Federal Information Security Management Act (FISMA) または Federal Risk and Authorization Management Program (FedRAMP) への準拠が要求されるシステムに適用されます。
リソース名は `fargateFIPSMode` です。
デフォルトは `disabled` です。
Fargate で連邦情報処理標準 (FIPS-140) コンプライアンスをオンにする必要があります。詳細については、「[AWS Fargate 連邦情報処理標準 (FIPS-140)](ecs-fips-compliance.md)」を参照してください。
**重要**
`fargateFIPSMode` アカウント設定は、Amazon ECS API または AWS CLI を使用してのみ変更できます。詳細については、「[Amazon ECS アカウント設定の変更](ecs-modifying-longer-id-settings.md)」を参照してください。
`fargateFIPSMode` オプションを `enabled` に設定して `put-account-setting-default` を実行します。詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)」を参照してください。
+ 次のコマンドを使用して、FIPS-140 コンプライアンスをオンにできます。
```
aws ecs put-account-setting-default --name fargateFIPSMode --value enabled
```
出力の例
```
{
"setting": {
"name": "fargateFIPSMode",
"value": "enabled",
"principalArn": "arn:aws:iam::123456789012:root",
"type": user
}
}
```
`list-account-settings` を実行して、現在の FIPS-140 コンプライアンスステータスを表示できます。`effective-settings` オプションを使用して、アカウントレベルの設定を表示します。
```
aws ecs list-account-settings --effective-settings
```
## タグ付け認可
Amazon ECS は、リソース作成のためのタグ付け認可を導入しています。`ecsCreateCluster` などのリソースを作成するアクションには、ユーザーがタグ付けのアクセス許可を持っている必要があります。リソースを作成し、そのリソースのタグを指定すると、AWS は、追加の認可を実行して、タグを作成するための許可があることを検証します。したがって、`ecs:TagResource` アクションを使用するための明示的な許可を付与する必要があります。詳細については、「[リソース作成時にタグ付けするための許可を付与する](supported-iam-actions-tagging.md)」を参照してください。
タグ付け認可にオプトインするには、`tagResourceAuthorization` オプションを `on` に設定して `put-account-setting-default` を実行します。詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)」を参照してください。`list-account-settings` を実行して、現在のタグ付け認可ステータスを表示できます。
+ 次のコマンドを使用して、タグ付け認可を有効にできます。
```
aws ecs put-account-setting-default --name tagResourceAuthorization --value on --region region
```
出力の例
```
{
"setting": {
"name": "tagResourceAuthorization",
"value": "on",
"principalArn": "arn:aws:iam::123456789012:root",
"type": user
}
}
```
タグ付け認可を有効にしたら、作成時にユーザーがリソースにタグ付けできるように、適切なアクセス許可を設定する必要があります。詳細については、「[リソース作成時にタグ付けするための許可を付与する](supported-iam-actions-tagging.md)」を参照してください。
`list-account-settings` を実行して、現在のタグ付け認可ステータスを表示できます。`effective-settings` オプションを使用して、アカウントレベルの設定を表示します。
```
aws ecs list-account-settings --effective-settings
```
## タグ付け認可のタイムライン
`list-account-settings` を実行して `tagResourceAuthorization` 値を表示することで、タグ付け認可がアクティブかどうかを確認できます。値が `on` である場合、タグ付け認可が使用されています。詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[list-account-settings](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-account-settings.html)」を参照してください。
タグ付け認可に関連する重要な日付を次に示します。
+ 2023 年 4 月 18 日 – タグ付け認可が導入されました。この機能を使用するには、新規および既存のすべてのアカウントでオプトインする必要があります。タグ付け認可の使用開始をオプトインできます。オプトインすることにより、適切な許可を付与する必要があります。
+ 2024 年 2 月 9 日から 2024 年 3 月 6 日 — すべての新しいアカウントと影響を受けていない既存のアカウントでは、タグ付け認可がデフォルトで有効になります。`tagResourceAuthorization` アカウント設定を有効/無効にすると、IAM ポリシーを確認できます。
AWS は、影響を受けたアカウントに通知しました。
この機能を無効にするには、`tagResourceAuthorization` オプションを `off` に設定して `put-account-setting-default` を実行します。
+ 2024 年 3 月 7 日 — タグ付け認可を有効にしている場合、アカウント設定を無効にすることはできなくなります。
この日までに IAM ポリシーのテストを完了することをお勧めします。
+ 2024 年 3 月 29 日 — すべてのアカウントがタグ付け認可を使用するようになります。アカウントレベルの設定は、Amazon ECS コンソールまたは AWS CLI では使用できなくなります。
## AWS Fargate タスク廃止の待機時間
廃止の対象としてマークされたプラットフォームバージョンリビジョン上で実行している Fargate タスクがある場合、AWS から通知が送信されます。詳細については、「[AWS Fargate on Amazon ECS のタスクの廃止とメンテナンス](task-maintenance.md)」を参照してください。
AWS Fargate の基盤となるインフラストラクチャに対する、パッチ適用とメンテナンスは、AWS が担当します。Fargate でホストされている Amazon ECS タスクにおいて、セキュリティまたはインフラストラクチャの更新が必要であると AWS が判断した場合、対象のタスクを停止し、それらを置き換えるための新しいタスクを起動する必要があります。Fargate タスクが廃止されるまでの待機時間を設定できます。タスクをすぐに廃止するか、7 暦日または 14 暦日待つかを選択できます。
この設定はアカウントレベルで適用されます。
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)」を参照してください。
次のコマンドを実行して、待機時間を 14 日間に設定できます。
```
aws ecs put-account-setting-default --name fargateTaskRetirementWaitPeriod --value 14
```
出力の例
```
{
"setting": {
"name": "fargateTaskRetirementWaitPeriod",
"value": "14",
"principalArn": "arn:aws:iam::123456789012:root",
"type: user"
}
}
```
現在の Fargate タスク廃止の待機時間は、`list-account-settings` を実行して表示できます。`effective-settings` オプションを使用する
```
aws ecs list-account-settings --effective-settings
```
## EC2 イベントウィンドウを使用した AWS Fargate タスクの廃止
AWS Fargate の基盤インフラストラクチャに対するパッチの適用とメンテナンスは AWS の責任です。Fargate でホストされている Amazon ECS タスクにおいて、セキュリティまたはインフラストラクチャの更新が必要であると AWS が判断した場合、対象のタスクを停止し、それらを置き換えるための新しいタスクを起動する必要があります。このアカウント設定を有効にすると、AWS Fargate が EC2 イベントウィンドウを使用してタスクの廃止日時を判断します。これはアカウントの 1 回限りの有効化であることに注意してください。
Fargate タスクの廃止に対して EC2 イベントウィンドウの使用を有効にするには、次の CLI コマンドを使用できます。
```
aws ecs put-account-setting-default --name fargateEventWindows --value enabled
```
これは、アカウントレベルの設定です。次のインスタンスタグを使用して、EC2 イベントウィンドウをアカウント、クラスター、サービスレベルで Fargate タスクに関連付けることができます。
+ `aws:ecs:serviceArn` : サービスタスク向け
+ `aws:ecs:clusterArn` : クラスターに属するタスク向け
+ `aws:ecs:fargateTask` : アカウント内のすべての Fargate タスクを対象にするために true に設定
Fargate で実行されている Amazon ECS タスク向けの [Amazon EC2 イベントウィンドウ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html)の機能方法に関する詳細については、「[ステップ 1: タスクの待機時間を設定、または Amazon EC2 イベントウィンドウを使用する](prepare-task-retirement.md#prepare-task-retirement-set-time)」を参照してください。
## Linux コンテナインスタンスのネットワークインターフェイスを増やす
`awsvpc` ネットワークモードを使用する各 Amazon ECS タスクには、独自の Elastic Network Interface (ENI) が割り当てられ、その ENI はそれをホストするコンテナインスタンスにアタッチされます。Amazon EC2 インスタンスにアタッチできるネットワークインターフェイスの数にはデフォルトの制限があり、プライマリネットワークインターフェイスも 1 つとしてカウントされます。例えば、デフォルトでは `c5.large` インスタンスには最大 3 つの ENI がアタッチされています。このインスタンスのプライマリネットワークインターフェイスも 1 つとしてカウントされるため、このインスタンスに追加でアタッチできる ENI は 2 つです。`awsvpc` ネットワークモードを使用する各タスクには ENI が必要なため、通常このインスタンスタイプでは、このようなタスクを 2 つだけ実行できます。
Amazon ECS は、サポートされている Amazon EC2 インスタンスタイプを使用して、ENI 密度が高いコンテナインスタンスの起動をサポートしています。これらのインスタンスタイプを使用し、`awsvpcTrunking` アカウント設定を有効にすると、新しく起動されたコンテナインスタンスで追加の ENI を利用できます。この設定により、各コンテナインスタンスにより多くのタスクを配置できます。
例えば、`awsvpcTrunking` を持つ `c5.large` インスタンスでは、ENI の制限が 12 に引き上げられています。コンテナインスタンスはプライマリネットワークインターフェイスを持ち、Amazon ECS はコンテナインスタンスの「トランク」ネットワークインターフェイスを作成およびアタッチします。したがって、この設定では、現在の 2 個ではなく 10 個のタスクをコンテナインスタンスで起動できます。
## Runtime Monitoring (Amazon GuardDuty 統合)
Runtime Monitoring は、AWS ログとネットワークアクティビティを継続的に監視して悪意のある動作や不正な動作を特定することで、Fargate および EC2 で実行されているワークロードを保護するインテリジェントな脅威検出サービスです。
`guardDutyActivate` パラメータは Amazon ECS では読み取り専用で、Amazon ECS アカウントのセキュリティ管理者によってランタイムモニタリングが有効になっているか無効になっているかを示します。GuardDuty は、ユーザーに代わってこのアカウント設定を制御します。詳細については、「[Runtime Monitoring で Amazon ECS ワークロードを保護する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-guard-duty-integration.html)」を参照してください。
`list-account-settings` を実行して、現在の GuardDuty 統合設定を表示できます。
```
aws ecs list-account-settings
```
出力の例
```
{
"setting": {
"name": "guardDutyActivate",
"value": "on",
"principalArn": "arn:aws:iam::123456789012:doej",
"type": aws-managed"
}
}
```
## デュアルスタック IPv6 VPC
Amazon ECS は、プライマリプライベート IPv4 アドレスに加えて IPv6 アドレスを備えたタスクの提供をサポートします。
タスクが IPv6 アドレスを受信するには、タスクが `awsvpc` ネットワークモードを使用し、デュアルスタックモードに設定された VPC で起動し、`dualStackIPv6` アカウント設定を有効にする必要があります。その他の要件の詳細については、EC2 のキャパシティについては「[デュアルスタックモードでの VPC の使用](task-networking-awsvpc.md#task-networking-vpc-dual-stack)」、Amazon ECS マネージドインスタンスのキャパシティについては「[デュアルスタックモードでの VPC の使用](managed-instances-awsvpc-mode.md#managed-instance-networking-vpc-dual-stack)」、Fargate のキャパシティについては「[デュアルスタックモードでの VPC の使用](fargate-task-networking.md#fargate-task-networking-vpc-dual-stack)」を参照してください。
**重要**
`dualStackIPv6` アカウント設定は、Amazon ECS API または AWS CLI を使用してのみ変更できます。詳細については、「[Amazon ECS アカウント設定の変更](ecs-modifying-longer-id-settings.md)」を参照してください。
2020 年 10 月 1 日から 2020 年 11 月 2 日の間に、IPv6 が有効なサブネットで `awsvpc` ネットワークモードを使用してタスクを実行している場合、タスクが実行されていたリージョンの既定の `dualStackIPv6` アカウント設定は `disabled` です。この条件が満たされない場合、リージョンのデフォルト `dualStackIPv6` 設定は `enabled` です。
デフォルトは `disabled` です。
## デフォルトのログドライバーモード
Amazon ECS では、コンテナから選択したログドライバーへのログメッセージのデフォルトの配信モードの設定がサポートされています。配信モードは、コンテナからログドライバーへのログのフローが中断されたときのアプリケーションの安定性に影響します。
`defaultLogDriverMode` 設定では、`blocking` と `non-blocking` の 2 つの値がサポートされています。これらの配信モードの詳細については、「*Amazon Elastic Containers サービス API リファレンス*」の「[LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)」を参照してください。
コンテナ定義の `logConfiguration` で配信モードを指定しない場合、このアカウント設定を使用して指定したモードがデフォルトとして使用されます。
デフォルトの配信モードは `non-blocking` です。
**注記**
2025 年 6 月 25 日、Amazon ECS はデフォルトのログドライバーモードが `blocking` から `non-blocking` に変更され、ログ記録よりもタスクの可用性が優先されるようになりました。この変更以降も `blocking` モードを引き続き使用するには、次のいずれかを実行してください。
コンテナ定義の `logConfiguration` の `mode` オプションを `blocking` に設定します。
`defaultLogDriverMode` アカウント設定を `blocking` に設定します。
デフォルトのログドライバーモードを `blocking` に設定するには、次のコマンドを実行します。
```
aws ecs put-account-setting-default --name defaultLogDriverMode --value "blocking"
```
# コンソールを使用して Amazon ECS のアカウント設定を表示する
コンソールでアカウント設定を表示して、アクセスできる機能を確認します。
**重要**
`dualStackIPv6`、`fargateFIPSMode`、`fargateTaskRetirementWaitPeriod`、および `fargateEventWindows` アカウントの設定を表示または変更するために使用できるのは AWS CLI のみです。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. 上部にあるナビゲーションバーで、アカウント設定を表示するリージョンを選択します。
1. ナビゲーションペインで **[Account Settings]** (アカウント設定) を選択します。
# Amazon ECS アカウント設定の変更
アカウント設定を変更して Amazon ECS 機能にアクセスします。
`guardDutyActivate` パラメータは Amazon ECS では読み取り専用で、Amazon ECS アカウントのセキュリティ管理者によってランタイムモニタリングが有効になっているか無効になっているかを示します。GuardDuty は、ユーザーに代わってこのアカウント設定を制御します。詳細については、「[Runtime Monitoring で Amazon ECS ワークロードを保護する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-guard-duty-integration.html)」を参照してください。
**重要**
`dualStackIPv6`、`fargateFIPSMode`、`fargateTaskRetirementWaitPeriod`、および `fargateEventWindows` アカウントの設定を表示または変更するために使用できるのは AWS CLI のみです。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. 上部にあるナビゲーションバーで、アカウント設定を表示するリージョンを選択します。
1. ナビゲーションペインで **[Account Settings]** (アカウント設定) を選択します。
1. **[更新]** を選択します。
1. (オプション) 各 EC2 インスタンスの awsvpc ネットワークモードで実行できるタスク数を増減するには、**[AWSVPC トランキング]** で **[AWSVPC トランキング]** を選択します。
1. (オプション) クラスターで CloudWatch Container Insights をデフォルトで使用、または使用を停止するには、**CloudWatch Container Insights オブザーバビリティ** で、次のいずれかのオプションを選択します。
+ オブザーバビリティが強化された Container Insights を使用するには、**[オブザーバビリティが強化された Container Insights]** を選択します。
+ Container Insights を使用するには、**[Container Insights]** を選択します。
+ Container Insights の使用を停止するには、**[オフ]**を選択します。
1. (オプション) タグ付け認可を有効または無効にするには、**[リソースのタグ付け認可]** で、**[リソースのタグ付け認可]** を選択または選択解除します。
1. (オプション) コンテナの `logConfiguration` でログ配信モードが定義されていない場合にデフォルトのログドライバーモードを設定するには、**デフォルトのログドライバーモード**で、次のいずれかのオプションを選択します。
+ デフォルトのログドライバーモードを `blocking` に設定するには、**[ブロッキング]** を選択します。
+ デフォルトのログドライバーモードを `non-blocking` に設定するには、**[ノンブロッキング]** を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
1. 確認画面で [**Confirm (確認)**] を選択すると、選択内容が保存されます。
## 次のステップ
オブザーバビリティが強化された Container Insights または Container Insights を有効にした場合、オプションで既存のクラスターを更新してその機能を使用できます。詳細については、「[Amazon ECS クラスターを更新する](update-cluster-v2.md)」を参照してください。
# デフォルトの Amazon ECS アカウント設定の復元
AWS マネジメントコンソール を使用して、Amazon ECS アカウント設定をデフォルトに戻せます。
**[Revert to account default]** (アカウントのデフォルトに戻す) オプションは、アカウント設定がデフォルト設定ではなくなった場合にのみ使用できます。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. 上部にあるナビゲーションバーで、アカウント設定を表示するリージョンを選択します。
1. ナビゲーションペインで **[Account Settings]** (アカウント設定) を選択します。
1. **[更新]** を選択します。
1. **[Revert to account default]** (アカウントのデフォルトに戻す) を選択します。
1. 確認画面で [**Confirm (確認)**] を選択すると、選択内容が保存されます。
# AWS CLI を使用した Amazon ECS アカウント設定の管理
アカウント設定は、Amazon ECS API、AWS CLI、または SDK を使用して管理することができます。`dualStackIPv6`、`fargateFIPSMode`、`fargateTaskRetirementWaitPeriod`、および `fargateEventWindows` アカウントの設定を表示または変更するために使用できるのは、これらのツールのみです。
**注記**
デュアルスタックサービスエンドポイントを使用することで、IPv4 と IPv6 の両方を介して AWS CLI、SDK、および Amazon ECS API から Amazon ECS とやり取りできます。詳細については、「[Amazon ECS デュアルスタックエンドポイントの使用](dual-stack-endpoint.md)」を参照してください。
タスク定義に使用できる API アクションの詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[アカウント設定アクション](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/OperationList-query-account.html)」を参照してください。
アカウントのすべてのユーザーまたはロールのデフォルトアカウント設定を変更するには、以下のいずれかのコマンドを使用します。これらの変更は、ユーザーまたはロールがこれらの設定を明示的に上書きしない限り、AWS アカウント全体に適用されます。
+ [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html) (AWS CLI)
```
aws ecs put-account-setting-default --name serviceLongArnFormat --value enabled --region us-east-2
```
このコマンドを使用して、他のアカウント設定を変更することもできます。そのためには、`name` パラメータを対応するアカウント設定に置き換えます。
+ [Write-ECSAccountSetting](https://docs.aws.amazon.com/powershell/latest/reference/items/Write-ECSAccountSetting.html) (AWS Tools for Windows PowerShell)
```
Write-ECSAccountSettingDefault -Name serviceLongArnFormat -Value enabled -Region us-east-1 -Force
```
**ユーザーアカウントのアカウント設定を変更するには (AWS CLI)**
自分のユーザーのアカウント設定を変更するには、以下のいずれかのコマンドを使用します。ルートユーザーとしてこれらのコマンドを使用する場合、ユーザーまたはロールが対象の設定を明示的に上書きしない限り、この変更内容が AWS アカウント全体に適用されます。
+ [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) (AWS CLI)
```
aws ecs put-account-setting --name serviceLongArnFormat --value enabled --region us-east-1
```
このコマンドを使用して、他のアカウント設定を変更することもできます。そのためには、`name` パラメータを対応するアカウント設定に置き換えます。
+ [Write-ECSAccountSetting](https://docs.aws.amazon.com/powershell/latest/reference/items/Write-ECSAccountSetting.html) (AWS Tools for Windows PowerShell)
```
Write-ECSAccountSetting -Name serviceLongArnFormat -Value enabled -Force
```
**特定のユーザーまたはロールのアカウント設定を変更するには (AWS CLI)**
特定のユーザーまたはロールのアカウント設定を変更するには、以下のいずれかのコマンドを使用して、リクエストの中でユーザー、ロール、またはルートユーザーの ARN を指定します。
+ [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) (AWS CLI)
```
aws ecs put-account-setting --name serviceLongArnFormat --value enabled --principal-arn arn:aws:iam::aws_account_id:user/principalName --region us-east-1
```
このコマンドを使用して、他のアカウント設定を変更することもできます。そのためには、`name` パラメータを対応するアカウント設定に置き換えます。
+ [Write-ECSAccountSetting](https://docs.aws.amazon.com/powershell/latest/reference/items/Write-ECSAccountSetting.html) (AWS Tools for Windows PowerShell)
```
Write-ECSAccountSetting -Name serviceLongArnFormat -Value enabled -PrincipalArn arn:aws:iam::aws_account_id:user/principalName -Region us-east-1 -Force
```
# Amazon ECS の IAM ロール
IAM ロール は、特定の許可があり、アカウントで作成できるもう 1 つの IAM アイデンティティです。Amazon ECS では、コンテナやサービスなどの Amazon ECS リソースにアクセス許可を付与するロールを作成できます。
Amazon ECS が必要とするロールは、タスク定義の起動タイプと使用する機能によって異なります。次の表を参照して、Amazon ECS に必要な IAM ロールを決定します。
| ロール | 定義 | 必要な場合 | 詳細情報 |
| --- | --- | --- | --- |
| タスク実行ロール | このロールにより、Amazon ECS がお客様に代わって他の AWS サービスを利用できるようにします。 | タスクは AWS Fargate または外部インスタンスホストされています。また、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-iam-role-overview.html) タスクは、AWS Fargate または Amazon EC2 インスタンスでホストされています。また、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-iam-role-overview.html) | [Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md) |
| タスクロール | このロールにより、(コンテナ上の) アプリケーションコードが他の AWS サービスを使用できるようになります。 | アプリケーションは、Amazon S3 などの他の AWS サービスにアクセスします。 | [Amazon ECS タスクの IAM ロール](task-iam-roles.md) |
| コンテナインスタンスのロール | このロールにより、EC2 インスタンスまたは外部インスタンスをクラスターに登録できます。 | タスクは Amazon EC2 インスタンスまたは外部インスタンスでホストされています。 | [Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md) |
| Amazon ECS Anywhere ロール | このロールにより、外部インスタンスが AWS API にアクセスできるようになります。 | タスクは外部インスタンスでホストされています。 | [Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md) |
| ロードバランサーロール用の Amazon ECS インフラストラクチャ | このロールにより、Amazon ECS はブルー/グリーンデプロイにおいて、ユーザーに代わってクラスター内のロードバランサーリソースを管理できます。 | Amazon ECS のブルー/グリーンデプロイを使用できます。 | [ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) |
| Amazon ECS CodeDeploy ロール | このロールにより、CodeDeploy はサービスを更新できます。 | CodeDeploy のブルー/グリーンデプロイタイプを使用して、サービスをデプロイします。 | [Amazon ECS CodeDeploy IAM ロール](codedeploy_IAM_role.md) |
| Amazon ECS EventBridge ロール | このロールにより、EventBridge はサービスを更新できます。 | EventBridge のルールとターゲットを使用してタスクをスケジュールします。 | [Amazon ECS EventBridge IAM ロール](CWE_IAM_role.md) |
| Amazon ECS インフラストラクチャロール | このロールにより、Amazon ECS はクラスター内のインフラストラクチャリソースを管理できます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-iam-role-overview.html) | [Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md) |
| インスタンスプロファイル | このロールにより、Amazon ECS マネージドインスタンスはインフラストラクチャロールを安全に引き受けることができます。 | クラスターで Amazon ECS マネージドインスタンスを使用します。 | [Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md) |