# Amazon ECS クラスター
<a name="clusters"></a>

Amazon ECS クラスターは、コンテナ化されたアプリケーションのインフラストラクチャ容量を提供する、タスクまたはサービスの論理グループです。クラスター作成時には、3 つの主要なインフラストラクチャタイプから選択します。各タイプは、異なるユースケースと運用要件に合わせて最適化されています。

## 適切なクラスタータイプの選択
<a name="cluster-types-overview"></a>

Amazon ECS では、クラスター用に 3 つのインフラストラクチャタイプが用意されています。ワークロード要件、運用設定、コスト最適化の目標に最適なタイプを選択します。

Amazon ECS マネージドインスタンス (推奨)  
**ほとんどのワークロードに最適** – AWS は、プロビジョニング、パッチ適用、スケーリングなど、基盤となる Amazon EC2 インスタンスを完全に管理します。このオプションを使用すると、パフォーマンス、コスト効率、運用のシンプルさについて最適なバランスが得られます。  
**次の場合に使用:**  
+ AWS にインフラストラクチャ管理を任せたい
+ 自動最適化による費用対効果の高いコンピューティングが必要
+ インフラストラクチャではなくアプリケーションに集中したい
+ 柔軟なスケーリングで予測可能なパフォーマンスが必要

Fargate  
**サーバーレスコンピューティング** – インフラストラクチャを管理せずに、タスクが使用するリソースに対してのみ料金を支払うサーバーレスコンピューティング。可変ワークロードや、すぐに使用開始する場合に最適です。  
**次の場合に使用:**  
+ 完全にサーバーレスなオペレーションが必要
+ 予測不可能なワークロードまたは可変ワークロードがある
+ 運用上のオーバーヘッドを最小限に抑えたい
+ 迅速なデプロイとスケーリングが必要

Amazon EC2 インスタンス  
**フルコントロール** – インスタンスの選択、設定、メンテナンスなど、基盤となる Amazon EC2 インスタンスを直接管理します。  
**次の場合に使用:**  
+ 特定のインスタンスタイプまたは設定が必要
+ 活用する既存の Amazon EC2 インフラストラクチャがある
+ カスタム AMI または特殊なソフトウェアが必要
+ 基盤となるインフラストラクチャを最大限制御する必要がある

**注記**  
Amazon ECS マネージドインスタンスは、パフォーマンス、コスト最適化、運用のシンプルさを適切に組み合わせることができる一方で、AWS がインフラストラクチャ管理タスクを処理できるようになるため、ほとんどの新しいワークロードに推奨される選択肢です。

## クラスターコンポーネント
<a name="cluster-components"></a>

クラスターは、インフラストラクチャの容量に加えて以下のリソースで構成されます。
+ タスクとサービスが実行されるネットワーク (VPC およびサブネット)

  キャパシティとして Amazon ECS マネージドインスタンスまたは Amazon EC2 インスタンスを使用する場合、サブネットはアベイラビリティーゾーン、ローカルゾーン、Wavelength ゾーン、または AWS Outposts に含められます。
+ オプションの名前空間

  名前空間は、Service Connect とのサービス間通信に使用されます。
+ モニタリングオプション

  CloudWatch Container Insights は追加料金がかかるフルマネージドサービスです。Amazon ECS のメトリクスとログを自動で収集、集計、要約します。

## クラスターの概念
<a name="cluster-concepts"></a>

Amazon ECS クラスターに関する全般的な概念を以下に示します。
+ クラスターを作成してリソースを分離します。
+ クラスターは AWS リージョン 固有です。
+ クラスターは、次のいずれかの状態になります。  
アクティブ  
クラスターはタスクを受け入れる準備ができており、該当する場合は、クラスターにコンテナインスタンスを登録できます。  
PROVISIONING  
クラスターにはキャパシティプロバイダーが関連付けられており、キャパシティプロバイダーに必要なリソースが作成されています。  
プロビジョン解除中  
クラスターにはキャパシティプロバイダーが関連付けられており、キャパシティプロバイダーに必要なリソースが削除されています。  
FAILED  
クラスターにはキャパシティプロバイダーが関連付けられており、キャパシティプロバイダーに必要なリソースの作成に失敗しました。  
INACTIVE  
クラスターは削除されました。`INACTIVE` ステータスのクラスターは、一定期間アカウント内で検出可能なままになる場合があります。この動作は今後変更される可能性があるため、`INACTIVE` クラスターの永続的な使用を前提としないようにしてください。
+ クラスターには、Amazon EC2 マネージドインスタンス、AWS Fargate、Amazon EC2 インスタンス、または外部インスタンスでホストされているタスクを混在させることができます。タスクは、起動タイプまたはキャパシティプロバイダー戦略として、Amazon ECS マネージドインスタンス、Fargate、または EC2 のインフラストラクチャで実行できます。EC2 キャパシティプロバイダーを使用する場合、Amazon ECS は Amazon EC2 Auto Scaling グループのキャパシティを追跡およびスケーリングしません。
+ クラスターには、Amazon ECS マネージドインスタンスキャパシティプロバイダー、Auto Scaling グループキャパシティプロバイダー、および Fargate キャパシティプロバイダーの組み合わせを含めることができます。キャパシティプロバイダー戦略には、Amazon ECS マネージドインスタンスキャパシティプロバイダー、Auto Scaling グループキャパシティプロバイダー、または Fargate キャパシティプロバイダーのみを含めることができます。
+ Amazon ECS マネージドインスタンスと EC2、または Auto Scaling グループのキャパシティプロバイダーには、異なるインスタンスタイプを使用できます。インスタンスは、一度に 1 つのクラスターにしか登録できません。
+ カスタム IAM ポリシーを作成することで、クラスターへのアクセスを制限できます。詳細については、「[Amazon Elastic Container Service のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」の「[Amazon ECS クラスターの例](security_iam_id-based-policy-examples.md#IAM_cluster_policies)」セクションを参照してください。
+ サービス自動スケーリングを使用して Fargate タスクをスケーリングできます。詳細については、「[Amazon ECS サービスを自動的にスケールする](service-auto-scaling.md)」を参照してください。
+ クラスターのデフォルトの Service Connect 名前空間を設定できます。デフォルトの Service Connect 名前空間を設定したら、Service Connect を有効にすることで、クラスター内で作成された新しいサービスを名前空間のクライアントサービスとして追加できます。追加の設定は必要ありません。詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。

## キャパシティープロバイダー
<a name="capacity-providers"></a>

Amazon ECS キャパシティープロバイダーは、クラスター内のタスクに対するインフラストラクチャのスケーリングを管理できます。各クラスターには、1 つ以上のキャパシティプロバイダーがあり、さらにオプションとしてキャパシティプロバイダー戦略があります。クラスターにデフォルトのキャパシティープロバイダー戦略を割り当てられます。キャパシティープロバイダー戦略は、クラスターの複数のキャパシティープロバイダー間にタスクを分散する方法を決定します。スタンドアロンタスクを実行するか、サービスを作成するときは、クラスターのデフォルトのキャパシティプロバイダー戦略か、クラスターのデフォルト戦略をオーバーライドするキャパシティプロバイダー戦略のいずれかを使用します。クラスターのデフォルトのキャパシティプロバイダー戦略は、タスクまたはサービスの起動タイプまたはキャパシティプロバイダー戦略を指定しない場合にのみ適用されます。これらのパラメータのいずれかを指定した場合、デフォルトの戦略は使用されません。

Amazon ECS には、クラスター用に 3 種類のキャパシティプロバイダーを提供します。

Amazon ECS マネージドインスタンスのキャパシティプロバイダー  
AWS は、プロビジョニング、パッチ適用、スケーリング、ライフサイクル管理など、基盤となる Amazon EC2 インスタンスを完全に管理します。これにより、パフォーマンス、コスト効率、運用のシンプルさの最適なバランスが得られます。Amazon ECS マネージドインスタンスキャパシティプロバイダーは、ワークロードの要件に基づいてインスタンスの選択とスケーリングを自動的に最適化します。  
Amazon ECS マネージドインスタンスには次のメリットがあります。  
+ インスタンスの自動プロビジョニングとスケーリング
+ マネージドパッチ適用とセキュリティ更新
+ インテリジェントなインスタンス選択によるコスト最適化
+ 運用オーバーヘッドの削減

Fargate キャパシティプロバイダー  
インフラストラクチャを管理せずに、タスクが使用するリソースに対してのみ料金を支払うサーバーレスコンピューティング。事前定義されたキャパシティプロバイダー (Fargate および Fargate Spot) をクラスターに関連付けるだけで利用できます。

Auto Scaling グループキャパシティープロバイダー  
キャパシティとして Amazon EC2 インスタンスを使用する場合は、Auto Scaling グループを使用して Amazon EC2 インスタンスを管理します。Auto Scaling により、アプリケーションの負荷を処理するために適切な数の使用可能な Amazon EC2 インスタンスを確保できるようになります。基盤となるインフラストラクチャを完全に制御できます。

クラスターには、Amazon ECS マネージドインスタンス、AWS Fargate、Amazon EC2 インスタンス、または外部インスタンスでホストされているタスクを混在させることができます。タスクは、起動タイプまたはキャパシティプロバイダー戦略として、Amazon ECS マネージドインスタンス、Fargate、または EC2 のインフラストラクチャで実行できます。EC2 を起動タイプとして使用する場合、Amazon ECS は Amazon EC2 Auto Scaling グループのキャパシティーを追跡およびスケーリングしません。

クラスターには、Amazon ECS マネージドインスタンスキャパシティプロバイダー、Auto Scaling グループキャパシティプロバイダー、および Fargate キャパシティプロバイダーの組み合わせを含めることができます。キャパシティプロバイダー戦略には、Amazon ECS マネージドインスタンスキャパシティプロバイダー、Auto Scaling グループキャパシティプロバイダー、または Fargate キャパシティプロバイダーのみを含めることができます。

# Amazon ECS マネージドインスタンスのクラスター
<a name="managed-instance-clusters"></a>

Amazon ECS キャパシティープロバイダーは、クラスター内のタスクに対するインフラストラクチャのスケーリングを管理できます。クラスターを作成したら、1 つ以上のキャパシティプロバイダーと、クラスターのキャパシティプロバイダー戦略 (オプション) を作成します。キャパシティープロバイダー戦略は、クラスターの複数のキャパシティープロバイダー間にタスクを分散する方法を決定します。スタンドアロンタスクを実行するか、サービスを作成するときは、クラスターのデフォルトのキャパシティプロバイダー戦略か、クラスターのデフォルト戦略をオーバーライドするキャパシティプロバイダー戦略のいずれかを使用します。

Amazon ECS マネージドインスタンスには、次のキャパシティプロバイダーがあります。


| タイプ | インスタンスの選択に使用される基準 | 
| --- | --- | 
| デフォルト | 次に示すタスク定義とサービスパラメータ要件を満たす最も費用対効果の高いインスタンス。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/managed-instance-clusters.html) | 
| カスタム | クラスターの作成時に指定した属性とタイプの要件を満たすインスタンス。属性の詳細については、「[Amazon ECS コンテナインスタンス属性](task-placement-constraints.md#attributes)」を参照してください。インスタンスタイプの詳細については、「Amazon EC2 インスタンスタイプ」の「[Amazon EC2 インスタンスタイプの仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html)」を参照してください。 | 

Amazon ECS はインスタンスを起動し、起動したインスタンスを Amazon ECS マネージドインスタンスキャパシティプロバイダーに関連付けます。カスタムキャパシティプロバイダーの場合、Amazon ECS はキャパシティプロバイダーも作成します。

# Amazon ECS マネージドインスタンスのクラスターを作成する
<a name="create-cluster-managed-instances"></a>

クラスターを作成して、タスクとサービスを実行するインフラストラクチャを定義します。

Amazon ECS マネージドインスタンスのクラスターを作成すると、デフォルトで `FARGATE_MANAGED_INSTANCE` キャパシティプロバイダーにアクセスできるようになります。このキャパシティプロバイダーは、ワークロード用に最もコストが最適化されたインスタンスタイプを自動的に選択します。特定のインスタンス属性またはタイプが必要な場合は、カスタムキャパシティプロバイダーを作成することもできます。

クラスターの作成プロセスをできるだけ簡単にするために、コンソールには多くの選択肢がデフォルトで用意されています。
+ AWS Cloud Map に、クラスターと同じ名前のデフォルトの名前空間を作成します。名前空間を使用すると、クラスターで作成したサービスを、追加の設定なしで名前空間内の他のサービスに接続できます。

  詳細については、「[Amazon ECS サービスを相互接続する](interconnecting-services.md)」を参照してください。

以下のオプションを変更できます。
+ クラスターに関連付けられたデフォルトの名前空間を変更します。

  名前空間を使用すると、クラスターで作成したサービスを、追加の設定なしで名前空間内の他のサービスに接続できます。デフォルトの名前空間は、クラスター名と同じです。詳細については、「[Amazon ECS サービスを相互接続する](interconnecting-services.md)」を参照してください。
+ マネージドストレージに AWS KMS キーを割り当てます。キーの作成方法の詳細については、*AWS Key Management Service ユーザーガイド*の「[KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
+ クラスターを識別しやすいようにタグを追加します。

## 前提条件
<a name="create-cluster-managed-instances-prerequisites"></a>

これを開始する前に、「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」 の手順を完了し、適切な IAM 許可を割り当てる必要があります。詳細については、「[Amazon ECS クラスターの例](security_iam_id-based-policy-examples.md#IAM_cluster_policies)」を参照してください。

クラスターを作成するユーザーには、追加のアクセス許可 `iam:CreateServiceLinkedRole` が必要です。

デフォルトでは、Amazon ECS はタスク定義で指定した要件に基づいてインスタンスタイプを選択します。これがデフォルトのキャパシティプロバイダーになります。特定のインスタンス属性またはタイプが必要な場合は、すべての要件を確認してください。カスタムキャパシティプロバイダーを使用して、インスタンスの要件を指定する必要があります。

インスタンスの選択方法を理解します。詳細については、「[Amazon ECS マネージドインスタンスにおけるインスタンス選択のベストプラクティス](managed-instances-instance-selection-best-practices.md)」を参照してください。

Amazon ECS マネージドインスタンスに必要な IAM ロールがあること。これには、以下が含まれます。
+ **インフラストラクチャロール** – Amazon ECS がユーザーに代わって AWS サービスを呼び出し、Amazon ECS マネージドインスタンスインフラストラクチャを管理できるようにします。

  詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。
+ **インスタンスプロファイル** – マネージドインスタンスで実行されている Amazon ECS コンテナエージェントと Docker デーモンへのアクセス許可を提供します。

  詳細については、「[Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md)」を参照してください。

## コンソール手順
<a name="create-cluster-managed-instances-console"></a>

**新しいクラスターを作成するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、**[Create Cluster]** (クラスターの作成) を選択します。

1. **[クラスター設定]** で以下を設定します。
   + **[クラスター名]** に一意の名前を入力します。

     名前には、最大 255 文字 (大文字と小文字)、数字、およびハイフンを含めることができます。
   + (オプション) Service Connect に使用する名前空間をクラスター名と別のものにするには、**[名前空間]** に一意の名前を入力します。

1. **[カスタムキャパシティプロバイダー]** の場合は、次の操作を行います。
   + **[EC2 キャパシティの取得方法を選択]** で、**[Amazon ECS マネージドインスタンス]** を選択します。
   + [インスタンスプロファイル] で、インスタンスプロファイルのロールを選択します。
   + インフラストラクチャロール については、インフラストラクチャロールを選択します。
   + カスタムキャパシティプロバイダーを使用するには、**[インスタンス選択]** で **[カスタムを使用]**を選択します。次に、属性ごとに **[属性値]** を入力します。

1. (オプション) Container Insights を使用して **モニタリング** を展開し、次のいずれかのオプションを選択します。
   + オブザーバビリティが強化された推奨の Container Insights を使用するには、**[オブザーバビリティが強化された Container Insights]** を選択します。
   + Container Insights を使用するには、**[Container Insights]** を選択します。

1. (オプション) マネージドストレージのデータを暗号化します。**[暗号化]** の **[マネージドストレージ]** に、マネージドストレージデータの暗号化に使用する AWS KMS キーの ARN を入力します。

1. (オプション) クラスターを識別しやすくするには、**[Tags]** (タグ) を展開し、タグを設定します。

   [タグの追加] [**タグの追加**] を選択して、以下を実行します。
   + [**キー**] にはキー名を入力します。
   + [**値**] にキー値を入力します。

1. **[作成]** を選択します。

## AWS CLI の手順
<a name="create-cluster-managed-instances-cli"></a>

AWS CLI を使用して、Amazon ECS マネージドインスタンスのクラスターを作成できます。AWS CLI の最新バージョンを使用する。最新のバージョンにアップグレードする方法については、「[AWS CLI の最新バージョンをインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。

**注記**  
デュアルスタックサービスエンドポイントを使用することで、AWS AWS CLI、SDK、Amazon ECS API から、IPv4 と IPv6 の両方を経由して Amazon ECS とやり取りができます。詳細については、「[Amazon ECS デュアルスタックエンドポイントの使用](dual-stack-endpoint.md)」を参照してください。

**新しいクラスターを作成するには (AWS CLI)**

1. 以下のコマンドを使用して、一意の名前を付けたクラスターを作成します。

   ```
   aws ecs create-cluster --cluster-name managed-instances-cluster
   ```

   出力:

   ```
   {
       "cluster": {
           "status": "ACTIVE", 
           "defaultCapacityProviderStrategy": [], 
           "statistics": [], 
           "capacityProviders": [], 
           "tags": [], 
           "clusterName": "managed-instances-cluster", 
           "settings": [
               {
                   "name": "containerInsights", 
                   "value": "disabled"
               }
           ], 
           "registeredContainerInstancesCount": 0, 
           "pendingTasksCount": 0, 
           "runningTasksCount": 0, 
           "activeServicesCount": 0, 
           "clusterArn": "arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster"
       }
   }
   ```

1. (オプション) クラスターのオブザーバビリティが強化された Container Insights を有効にするには、次のコマンドを使用します。

   ```
   aws ecs put-account-setting --name containerInsights --value enhanced
   ```

1. (オプション) クラスターにタグを追加するには、次のコマンドを使用します。

   ```
   aws ecs tag-resource --resource-arn arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster --tags key=Environment,value=Production
   ```

## 次のステップ
<a name="cluster-next-steps-managed-instances"></a>

Amazon ECS マネージドインスタンスのタスク定義を作成します。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。

スタンドアロンタスクとして、またはサービスの一部としてアプリケーションを実行します。詳細については次を参照してください:
+ [Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)
+ [Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)

# Amazon ECS マネージドインスタンスを使用するようにクラスターを更新する
<a name="update-cluster-managed-instances"></a>

Amazon ECS マネージドインスタンスを使用するように既存のクラスターを更新できます。

Amazon ECS マネージドインスタンスをクラスターに追加すると、デフォルトで `FARGATE_MANAGED_INSTANCE` キャパシティプロバイダーにアクセスできるようになります。このキャパシティプロバイダーは、ワークロードに最もコストが最適化された汎用インスタンスタイプを自動的に選択します。特定のインスタンス属性またはタイプが必要な場合は、カスタムキャパシティプロバイダーを作成することもできます。

## 前提条件
<a name="update-cluster-managed-instances-prerequisites"></a>

デフォルトでは、Amazon ECS はタスク定義で指定した要件に基づいてインスタンスタイプを選択します。これがデフォルトのキャパシティプロバイダーになります。特定のインスタンス属性またはタイプが必要な場合は、すべての要件を確認してください。カスタムキャパシティプロバイダーを使用して、インスタンスの要件を指定する必要があります。

Amazon ECS マネージドインスタンスに必要な IAM ロールがあること。これには、以下が含まれます。
+ **インフラストラクチャロール** – Amazon ECS がユーザーに代わって AWS サービスを呼び出し、Amazon ECS マネージドインスタンスインフラストラクチャを管理できるようにします。

  詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。
+ **インスタンスプロファイル** – マネージドインスタンスで実行されている Amazon ECS コンテナエージェントと Docker デーモンへのアクセス許可を提供します。

  詳細については、「[Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md)」を参照してください。

## 更新に関する考慮事項
<a name="cluster-update-considerations-managed-instances"></a>

Amazon ECS マネージドインスタンスのクラスターを更新する場合は、次の点を考慮してください。
+ 実行中のタスク – クラスター設定を更新しても、現在実行中のタスクには影響しません。更新後に起動される新しいタスクに変更が適用されます。
+ キャパシティプロバイダーの変更 – キャパシティプロバイダー設定を変更すると、既存のマネージドインスタンスは引き続き実行されますが、新しいインスタンスは更新された設定を使用します。
+ 変更のモニタリング – Container Insights を有効または無効にすると、クラスター全体のメトリクス収集に影響します。

## コンソール手順
<a name="update-cluster-managed-instances-console"></a>

**クラスターを更新するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページで、更新するクラスターを選択します。

1. **[クラスターを更新]** を選択します。

1. (オプション) キャパシティプロバイダーの設定を変更するには、**[カスタムキャパシティプロバイダー]**で、必要に応じて以下を更新します。
   + **[インスタンスプロファイル]** で、必要に応じて別のインスタンスプロファイルロールを選択します。
   + **[インフラストラクチャロール]** で、必要に応じて別のインフラストラクチャロールを選択します。
   + カスタムキャパシティプロバイダーを使用するには、**[インスタンスの選択]** で **[属性値]** の設定を更新します。

1. **[更新]** を選択します。

## AWS CLI の手順
<a name="update-cluster-managed-instances-cli"></a>

AWS CLI を使用して、Amazon ECS マネージドインスタンスのクラスターを更新できます。AWS CLI の最新バージョンを使用する。最新のバージョンにアップグレードする方法については、「[AWS CLI の最新バージョンをインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。

**注記**  
デュアルスタックサービスエンドポイントを使用することで、AWS AWS CLI、SDK、Amazon ECS API から、IPv4 と IPv6 の両方を経由して Amazon ECS とやり取りができます。詳細については、「[Amazon ECS デュアルスタックエンドポイントの使用](dual-stack-endpoint.md)」を参照してください。

**クラスターを更新するには (AWS CLI)**

1. 次のキャパシティプロバイダーを作成します。次のコマンドを実行します。

   *user-input* を独自の値に置き換えます。

   ```
   aws ecs create-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider \
       --instance-profile arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile \
       --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRole \
       --instance-requirements '{
           "vCpuCount": {"min": 2, "max": 8},
           "memoryMiB": {"min": 4096, "max": 16384}
       }
   ```

1. 次のコマンドを使用して、クラスターにキャパシティプロバイダーを追加します。

   *user-input* を独自の値に置き換えます。

   ```
   aws ecs put-cluster-capacity-providers --cluster managed-instances-cluster --capacity-providers my-managed-instances-provider --default-capacity-provider-strategy capacityProvider=my-managed-instances-provider,weight=1
   ```

# Amazon ECS マネージドインスタンスのキャパシティプロバイダー
<a name="managed-instances-capacity-providers-concept"></a>

Amazon ECS マネージドインスタンスキャパシティプロバイダーは、AWS で運用上およびセキュリティ上の責任を管理しながら、幅広い AWS の機能と Amazon EC2 サービスにアクセスできるコンテナコンピューティングモデルを提供します。AWS は、ソフトウェアと OS のパッチ適用、インスタンスのスケーリング、メンテナンスを処理し、すべての AWS 機能と統合へのアクセスを維持しながら、運用における Fargate のメリットを提供します。

Amazon ECS は、Amazon ECS マネージドインスタンスの起動テンプレートを作成します。このテンプレートは、タスクのインスタンスプロファイル、ネットワークとストレージの設定、容量オプション、柔軟なインスタンスタイプ選択のためのインスタンス要件など、Amazon ECS が Amazon ECS マネージドインスタンスを起動する条件を定義します。

## カスタムキャパシティプロバイダーを使用する場面
<a name="when-to-use-managed-instances"></a>

ワークロードで以下が必要な場合は、カスタムキャパシティプロバイダーの使用を検討します。
+ 特定のコンピューティング要件: アクセラレーテッドコンピューティング、特定の CPU 命令セット、ネットワークの高パフォーマンス、標準の Fargate オプションでは利用できない大きなメモリ設定を必要とするアプリケーションなど。
+ GPU ワークロード: NVIDIA または AMD GPU へのアクセスを必要とする機械学習推論、リアルタイムイメージレンダリング、ビデオエンコーディング、その他の GPU アクセラレーションアプリケーションなど。
+ キャパシティ予約: 予測可能なキャパシティの可用性を必要とするミッションクリティカルなワークロード。
+ 高度なオブザーバビリティ: eBPF ベースのモニタリングソリューションやネットワーク分析ツールなど、基盤となる OS への特権アクセスを必要とするセキュリティおよびモニタリングツール。
+ コストの最適化: マルチタスク配置、共有インフラストラクチャコンポーネント、大型のインスタンスタイプの使用率を最大化する必要があるワークロード。

## モニタリングオプション
<a name="monitoring-options-managed-instances"></a>

Amazon ECS マネージドインスタンスは、コンテナ化されたワークロードのパフォーマンス、ヘルス、リソース使用率の追跡に役立つ包括的なモニタリング機能を提供します。運用要件に基づき、さまざまなモニタリングレベルから選択できます。
+ **基本モニタリング** – ほとんどのメトリクスでは 5 分間隔、ステータスチェックでは 1 分間隔で必須メトリクスを提供します。デフォルトで有効になっています。追加料金はありません。
+ **詳細モニタリング** – すべてのメトリクスを 1 分間隔で利用できるため、可視性が向上し、運用上の問題の検出と対応が高速化します。詳細については、「[Amazon ECS マネージドインスタンスの詳細なモニタリング](monitoring-managed-instances.md#detailed-monitoring-managed-instances)」を参照してください。

どちらのモニタリングオプションも CloudWatch とシームレスに統合され、最適なアプリケーションのパフォーマンスと可用性の維持に役立つダッシュボード、アラーム、自動応答機能を提供します。

## キャパシティープロバイダーに関する考慮事項
<a name="capacity-provider-considerations-managed-instances"></a>

クラスターには、Amazon ECS マネージドインスタンスキャパシティプロバイダー、Auto Scaling グループキャパシティプロバイダー、および Fargate キャパシティプロバイダーの組み合わせを含めることができます。キャパシティプロバイダー戦略には、Amazon ECS マネージドインスタンスキャパシティプロバイダー、Auto Scaling グループキャパシティプロバイダー、または Fargate キャパシティプロバイダーのみを含めることができます。

## タグ伝達
<a name="tag-propagation-managed-instances"></a>

Amazon ECS マネージドインスタンスキャパシティプロバイダーは、タグの伝播をサポートしています。タグの伝播では、キャパシティプロバイダーによって管理されるすべてのリソース (マネージドインスタンス、Amazon ECS コンテナインスタンス、起動テンプレート、ボリューム、Elastic Network Interfaces) は、キャパシティプロバイダーレベルで指定されたものと同じタグでタグ付けされます。キャパシティプロバイダーの作成時にタグを指定し、`propagateTags` パラメータを `CAPACITY_PROVIDER` として指定することでタグの伝播を有効にできます。

Amazon ECS マネージドインスタンスでのタグ付けの詳細については、「[Amazon ECS マネージドインスタンスのタグ](instance-details-tags-managed-instances.md)」を参照してください。

# Amazon ECS マネージドインスタンスのキャパシティプロバイダー更新のベストプラクティス
<a name="capacity-provider-managed-instances-best-practices"></a>

最高レベルの安全性とロールバックのサポートを利用するには、キャパシティプロバイダーをイミュータブルリソースとして扱うことをお勧めします。キャパシティプロバイダーの設定を更新する必要がある場合は、次の推奨ワークフローに従います。

1. 既存の設定を変更する代わりに、更新した設定の**新規キャパシティプロバイダー**を作成します。

1. 新規キャパシティプロバイダーを使用するように**各サービスを更新**し、デプロイを完了できるようにします。

1. 新しい設定が正常に機能することを確認したら、**古いキャパシティプロバイダーを削除します**。

このアプローチにはいくつかの利点があります。
+ **ロールアウトを管理可能** – サービスを一度に 1 つずつ更新し、影響をモニタリングできます。
+ **ロールバックが簡単** – 問題が発生した場合は、すぐにサービスを元に戻し、以前のキャパシティプロバイダーを使用することができます。
+ **影響が及ぶ範囲を縮小** – 新しい設定で問題が発生した場合でも、直ちにすべてのワークロードには影響しません。

**注記**  
CloudFormation を使用している場合は、スタックの変更をロールバックできるように、後のデプロイまで古いキャパシティプロバイダーを維持することを検討してください。

このアプローチでは、設置したキャパシティプロバイダーは更新できますが、制御されない影響の及ぶ範囲が大きくなります。インプレース更新では、今後プロビジョニングされるすべての新しいキャパシティに新しい設定が適用されますが、サービスのデプロイはトリガーされません。したがって、時間が経過してサービスのスケーリングが必要になってから設定の問題が検出される可能性があります。

# Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成する
<a name="create-capacity-provider-managed-instances"></a>

Amazon ECS マネージドインスタンスは、キャパシティプロバイダを使用してワークロードのコンピューティングキャパシティを管理します。デフォルトでは、Amazon ECS は、最もコスト最適化された汎用インスタンスタイプを自動的に選択するデフォルトのキャパシティプロバイダーを提供します。ただし、カスタムキャパシティプロバイダーを作成して、インスタンスタイプ、CPU 製造元、アクセラレータータイプ、その他の要件などのインスタンス属性を指定することもできます。

カスタムキャパシティプロバイダーは、属性ベースのインスタンスタイプの選択を使用しており、一連の属性としてインスタンス要件を表現できます。これらの要件は、一致するすべての Amazon EC2 インスタンスタイプに自動的に変換されるため、インスタンスタイプ設定の作成とメンテナンスが簡素化されます。インスタンスの要件と属性ベースの選択の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 Fleet の属性ベースのインスタンスタイプの選択](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)」ドキュメントを参照してください。

## 前提条件
<a name="create-capacity-provider-managed-instances-prerequisites"></a>

作業を開始する前に、以下を完了していることを確認してください。
+ 使用するモニタリングのタイプを決定する。詳細については、「[Amazon ECS マネージドインスタンスの詳細なモニタリング](monitoring-managed-instances.md#detailed-monitoring-managed-instances)」を参照してください。
+ 既存のクラスターがあるか、クラスターを作成する予定である。詳細については、「[Amazon ECS マネージドインスタンスのクラスターを作成する](create-cluster-managed-instances.md)」を参照してください。
+ Amazon ECS マネージドインスタンスに必要な IAM ロールがあること。これには、以下が含まれます。
  + **インフラストラクチャロール** – Amazon ECS がユーザーに代わって AWS サービスを呼び出し、Amazon ECS マネージドインスタンスインフラストラクチャを管理できるようにします。

    詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。
  + **インスタンスプロファイル** – マネージドインスタンスで実行されている Amazon ECS コンテナエージェントと Docker デーモンへのアクセス許可を提供します。

    詳細については、「[Amazon ECS マネージドインスタンスのインスタンスプロファイル](managed-instances-instance-profile.md)」を参照してください。

インスタンスの選択方法を理解します。詳細については、「[Amazon ECS マネージドインスタンスにおけるインスタンス選択のベストプラクティス](managed-instances-instance-selection-best-practices.md)」を参照してください。

## コンソール手順
<a name="create-capacity-provider-managed-instances-console"></a>

**Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページでクラスターの名前を選択します。

1. クラスターのページで、**[インフラストラクチャ]** タブを選択します。

1. **[キャパシティプロバイダー]** セクションで、**[キャパシティプロバイダーを作成]** を選択します。

1. **[キャパシティプロバイダー設定]**で、以下を設定します。
   + **[キャパシティプロバイダー名]** に、一意のキャパシティプロバイダー名を入力します。
   + **[キャパシティプロバイダータイプ]** で、**[Amazon ECS マネージドインスタンス]** を選択します。

1. **[インスタンス設定]** で以下を設定します。
   + **[インスタンスプロファイル]** で、Amazon ECS マネージドインスタンス用に作成したインスタンスプロファイルロールを選択します。
   + **[インフラストラクチャロール]** で、Amazon ECS マネージドインスタンス用に作成したインフラストラクチャロールを選択します。

1. **[インスタンス要件]**で、インスタンスの属性を指定します。次の項目を任意で組み合わせて設定できます。
   + **[vCPU カウント]** – vCPU の数を指定します (`4` など。`8-16` のように範囲指定も可)。
   + **[メモリ (MiB)]** – メモリの量を MiB 単位で指定します (`8192` など。`16384-32768` のように範囲指定も可)。
   + **[インスタンスタイプ]** – 特定のインスタンスタイプを指定します (`m5.large,m5.xlarge,c5.large` など)。
   + **[CPU メーカー]** – `intel`、`amd`、`amazon-web-services` から選択します。
   + **[アクセラレーターのタイプ]** – `gpu`、`fpga`、`inference` などのアクセラレータータイプを指定します。
   + **[アクセラレーター数]** – アクセラレーターの数を指定します (`1` など。`2-4` のように範囲指定も可)。

1. **[詳細設定]** で、次のいずれかのモニタリングオプションを選択します。
   + CloudWatch でステータスチェックメトリクスを送信する場合は、**[基本]** を選択します。
   + CloudWatch ですべてのメトリクスを送信する場合は、**[詳細]** を選択します。

1. (オプション) キャパシティプロバイダーを識別しやすくするには、**[タグ]** を展開し、タグを設定します。

   キャパシティプロバイダーからマネージドリソース (キャパシティプロバイダーから起動されたインスタンスなど) へのタグの伝播を有効にするには、**[タグの伝播元]** で **[キャパシティプロバイダー]** を選択します。

   [タグの追加] [**タグの追加**] を選択して、以下を実行します。
   + [**キー**] にはキー名を入力します。
   + [**値**] にキー値を入力します。

1. **[作成]** を選択します。

## AWS CLI の手順
<a name="create-capacity-provider-managed-instances-cli"></a>

AWS CLI を使用して、Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成できます。AWS CLI の最新バージョンを使用する。最新のバージョンにアップグレードする方法については、「[AWS CLI の最新バージョンをインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。

**Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成するには (AWS CLI)**

1. 次のコマンドを実行します。

   ```
   aws ecs create-capacity-provider --cli-input-json file://capacity-provider-definition.json
   ```

   以下のように、`capacity-provider-definition.json` を使用して、基本的なインスタンス要件、インスタンスストレージサイズを指定し、タグ伝播を有効にすることができます。

   ```
   {
       "name": "my-managed-instances-provider",
       "cluster": "my-cluster",
       "tags": [ 
           { 
               "key": "version",
               "value": "test"
           }
       ],    
       "managedInstancesProvider": {
           "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
           "instanceLaunchTemplate": {
               "ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
               "instanceRequirements": {
                   "vCpuCount": {
                       "min": 4,
                       "max": 8
                   },
                   "memoryMiB": {
                       "min": 8192,
                       "max": 16384
                   }
               },
               "networkConfiguration": {
                   "subnets": [
                       "subnet-abcdef01234567",
                       "subnet-bcdefa98765432"
                   ],
                   "securityGroups": [
                       "sg-0123456789abcdef"
                   ]
               },
               "storageConfiguration": {
                   "storageSizeGiB": 100
               },
               "monitoring": "basic"
           },
           "propagateTags": "CAPACITY_PROVIDER"
       }
   }
   ```

1. キャパシティプロバイダーが正常に作成されたことを確認します。

   ```
   aws ecs describe-capacity-providers \
       --capacity-providers my-managed-instances-provider
   ```

## 次のステップ
<a name="capacity-provider-managed-instances-next-steps"></a>

キャパシティプロバイダーの作成後は、サービスの作成時またはタスクの実行時に使用できます。
+ サービスでキャパシティプロバイダーを使用する場合は、「[Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)」を参照してください。
+ スタンドアロンタスクでキャパシティプロバイダーを使用する場合は、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」を参照してください。

# Amazon ECS マネージドインスタンスのモニタリングを更新する
<a name="update-capacity-provider-managed-instances"></a>

Amazon ECS マネージドインスタンスキャパシティプロバイダーのモニタリングオプションを変更して、基本モニタリングと詳細モニタリングを変更できます。この機能で、キャパシティプロバイダーを再作成することなく、収集されたモニタリングデータのレベルを調整できます。

モニタリングオプションの詳細については、「[Amazon ECS マネージドインスタンスのモニタリング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-managed-instances.html)」を参照してください。

## コンソール手順
<a name="update-capacity-provider-managed-instances-console"></a>

**Amazon ECS マネージドインスタンスのモニタリングを更新するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページでクラスターの名前を選択します。

1. クラスターのページで、**[インフラストラクチャ]** タブを選択します。

1. **[詳細設定]** で、次のいずれかのモニタリングオプションを選択します。
   + CloudWatch でステータスチェックメトリクスを送信する場合は、**[基本]** を選択します。
   + CloudWatch ですべてのメトリクスを送信する場合は、**[詳細]** を選択します。

1. **[更新]** を選択します。

既存の Amazon ECS マネージドインスタンスキャパシティプロバイダーに関連付けられているタグを更新するには、次の手順に従います。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. [クラスター] ページで、**[インフラストラクチャ]** を選択します。

1. [インフラストラクチャページ] で、作成したキャパシティプロバイダーを選択します。

1. [キャパシティプロバイダー] ページで、**[タグ]** を選択します。

1. **[タグ]** の項目で、**[タグの管理]** を選択します。

1. タグを追加するには、追加するタグのキーと値を指定し、**[保存]** を選択します。一度に複数のタグを追加するには、追加するタグごとに **[タグを追加]** を選択します。最大 50 個のタグを追加できます。

   タグを削除するには**[削除]** を選択してください。
**注記**  
タグ伝播が有効になっている場合、キャパシティプロバイダーの作成後に追加または削除されたタグは、それ以前にキャパシティプロバイダーで作成されたリソースには適用されません。

## AWS CLI の手順
<a name="update-capacity-provider-managed-instances-cli"></a>

AWS CLI を使用して、Amazon ECS マネージドインスタンスのキャパシティプロバイダーを更新できます。AWS CLI の最新バージョンを使用する。最新のバージョンにアップグレードする方法については、「[AWS CLI の最新バージョンをインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。

**Amazon ECS マネージドインスタンスのモニタリングを更新するには (AWS CLI)**

1. 詳細モニタリングを有効にするには、次のコマンドを使用します。

   ```
   aws ecs update-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider '{
           "instanceLaunchTemplateUpdate": {
               "monitoring": "DETAILED"
           }
       }'
   ```

1. 基本モニタリングを有効にするには、次のコマンドを使用します。

   ```
   aws ecs update-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider '{
           "instanceLaunchTemplateUpdate": {
               "monitoring": "BASIC"
           }
       }'
   ```

# Amazon ECS マネージドインスタンスキャパシティプロバイダーを削除する
<a name="delete-capacity-provider-managed-instances-console-v2"></a>

Amazon ECS マネージドインスタンスキャパシティプロバイダーは、使い終わったら削除できます。グループが削除されると、Amazon ECS マネージドインスタンスキャパシティプロバイダーは `INACTIVE` 状態に移行します。`INACTIVE` ステータスのキャパシティープロバイダーは、一定期間アカウント内で検出可能になる場合があります。ただし、この動作は今後変更される予定であり、`INACTIVE` のキャパシティープロバイダーを永続的に使用するのは避けてください。Amazon ECS マネージドインスタンスキャパシティプロバイダーを削除する前に、すべてのサービスからキャパシティプロバイダー戦略を削除する必要があります。サービスのキャパシティプロバイダー戦略からキャパシティプロバイダーを削除するには、`UpdateService` API または Amazon ECS コンソールのサービス更新ワークフローを使用できます。**[新しいデプロイの強制]** オプションを使用して、キャパシティプロバイダーによって提供される Amazon ECS マネージドインスタンスキャパシティを使用する任意のタスクを、残りのキャパシティプロバイダーのキャパシティを使用するように移行することができます。

**クラスターのキャパシティプロバイダーを削除するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、クラスターを選択します。

1. **[クラスター: *名前*]** ページの **[インフラストラクチャ]** で、Amazon ECS マネージドインスタンスキャパシティプロバイダーを選択し、**[削除]** を選択します。

1. 確認ボックスに、「**delete *Amazon ECS マネージドインスタンスキャパシティプロバイダー名***」と入力します。

1. **[削除]** を選択します。

# Amazon ECS マネージドインスタンスで実行されている Amazon ECS ワークロードを安全に停止する
<a name="managed-instance-task-scale-in-protect"></a>

Amazon ECS タスクスケールイン保護を使用すると、サービスのスケーリングまたはデプロイからのスケールインイベントによってタスクが終了されるのを防ぐことができます。

特定のアプリケーションでは、使用率が低いときやサービスのデプロイ中に、ミッションクリティカルなタスクがスケールインイベントによって終了されるのを防ぐメカニズムが必要です。例えば、次のようになります。
+ ビデオトランスコーディングジョブなどのキュー処理型の非同期アプリケーションでは、サービスの累積使用率が低い場合でも、一部のタスクは何時間も実行する必要があります。
+ ゲームアプリケーションによっては、ゲームサーバーはタスクとして実行されますが、サーバー再起動時の起動待ち時間を短縮するため、すべてのユーザーがログアウトした場合でも実行を続ける必要があります。
+ 新しいコードバージョンをデプロイする場合、再処理にはコストがかかるため、タスクは実行し続ける必要があります。

サービスに属するタスクがスケールインイベントで終了されることを防ぐには、`ProtectionEnabled` 属性を `true` に設定します。`ProtectionEnabled` を true に設定すると、タスクはデフォルトで 2 時間保護されます。その後、保護期間は、`ExpiresInMinutes` 属性を使用してカスタマイズできます。タスクの保護期間は最短で 1 分間、最長で 2,880 分 (48 時間) です。AWS CLI を使用している場合は、`--protection-enabled` オプションを指定できます。

タスクが必要な作業を完了した後は、`ProtectionEnabled` 属性を `false` に設定して、以降のスケールインイベントによってタスクが終了されるようにできます。AWS CLI を使用している場合は、`--no-protection-enabled` オプションを指定できます。

## タスクスケールイン保護メカニズム
<a name="managed-instance-task-scale-in-protection-mechanisms"></a>

Amazon ECS コンテナエージェントエンドポイントまたは Amazon ECS API を使用して、タスクスケールイン保護を設定および取得できます。
+ **Amazon ECS コンテナエージェントエンドポイント**

  保護の必要性を自己判断できるタスクには、Amazon ECS コンテナエージェントエンドポイントを使用することをお勧めします。このアプローチは、キューベースのワークロードまたはジョブ処理ワークロードに使用します。

  コンテナが、例えば SQS メッセージを使用するなどして処理を開始すると、コンテナ内からタスクスケールイン保護のエンドポイントパス「`ProtectionEnabled`」を使用して `$ECS_AGENT_URI/task-protection/v1/state` 属性を設定できます。スケールインイベントの際、Amazon ECS はこのタスクを終了しません。タスクの処理が完了した後は、同じエンドポイントを使用して `ProtectionEnabled` 属性をクリアし、以降のスケールインイベントでタスクが終了されるようにできます。

  Amazon ECS コンテナエージェントエンドポイントの詳細については、「[Amazon ECS タスクスケールイン保護のエンドポイント](managed-instance-task-scale-in-protection-endpoint.md)」を参照してください。
+ **Amazon ECS API**

  アプリケーションにアクティブなタスクの状態を追跡するコンポーネントがある場合は、Amazon ECS API を使用してタスクスケールイン保護を設定および取得できます。`UpdateTaskProtection` を使用して、1 つ以上のタスクを保護対象としてマークします。`GetTaskProtection` を使用して保護ステータスを取得します。

  このアプローチの例としては、アプリケーションがゲームサーバーセッションを Amazon ECS タスクとしてホストしている場合が挙げられます。ユーザーがサーバー上のセッション (タスク) にログインすると、そのタスクを保護対象としてマークできます。ユーザーがログアウトした後は、サーバーのアイドル状態を維持することの要件に応じて、このタスク限定でクリアすることも、アクティブなセッションがなくなった同様のタスクについて定期的に保護をクリアすることもできます。

  詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html)」と「[GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)」を参照してください。

両方のアプローチを組み合わせることができます。例えば、Amazon ECS エージェントエンドポイントを使用してコンテナ内からタスク保護を設定し、Amazon ECS API を使用して外部コントローラーサービスからタスク保護を削除するなどです。

## 考慮事項
<a name="managed-instance-task-scale-in-protection-considerations"></a>

タスクスケールイン保護を使用する前に、次の点を考慮してください。
+ タスクのスケールイン保護は、サービスからデプロイされたタスクでのみサポートされます。
+ タスクのスケールイン保護は、Amazon ECS マネージドインスタンスで実行されているサービスからデプロイされたタスクでサポートされます。
+ Amazon ECS エージェントには再試行メカニズムが組み込まれており、そのインターフェイスはよりシンプルであるため、Amazon ECS コンテナエージェントエンドポイントを使用することをお勧めします。
+ 既に保護がオンになっているタスクのために `UpdateTaskProtection` を呼び出すことで、タスクのスケールイン保護の有効期間をリセットできます。
+ タスクが必要な作業を完了するのに必要な時間を判断し、それに応じて `expiresInMinutes` プロパティを設定してください。保護の有効期限を必要以上に長く設定すると、コストが発生すると共に、新しいタスクのデプロイが遅れることになります。
+ デプロイに関する考慮事項:
  + サービスがローリングアップデートを使用する場合、新しいタスクは作成できますが、古いバージョンを実行しているタスクは、`protectionEnabled` がクリアされるか、または失効するまで終了しません。デプロイ設定の `maximumPercentage` パラメータは、古いタスクが保護されている場合でも新しいタスクを作成できるように値を調整できます。
  + CloudFormation を使用する場合、更新スタックのタイムアウトは 3 時間です。そのため、タスク保護を 3 時間以上設定すると、CloudFormation のデプロイで障害が発生してロールバックが発生する可能性があります。

    古いタスクが保護されている間、CloudFormation スタックは `UPDATE_IN_PROGRESS` を表示します。タスクのスケールイン保護が削除されるか、または 3 時間のウィンドウ内に失効する場合、デプロイは成功し、`UPDATE_COMPLETE` ステータスに移行します。デプロイが `UPDATE_IN_PROGRESS` のまま 3 時間以上滞っていると、デプロイは失敗して `UPDATE_FAILED` 状態が表示され、古いタスクセットにロールバックされてしまいます。
  + 保護されたタスクが原因でデプロイ (ローリングまたはブルー/グリーン) が定常状態に到達できない場合、Amazon ECS はサービスイベントを送信し、これによりユーザーは是正措置を講じることができます。タスクの保護ステータスを更新しようとする際に `DEPLOYMENT_BLOCKED` エラーメッセージが表示される場合、サービスの要求されるタスク数よりも多くの保護されたタスクがあることを意味します。この問題を解決するには、次のいずれかの操作を実行します。
    + 現在のタスク保護の有効期限が切れるのを待ちます。次に、タスク保護を設定します。
    + どのタスクを停止できるかを決定します。その後、これらのタスクについて `protectionEnabled` オプションを `false` に設定して `UpdateTaskProtection` を使用します。
    + サービスの必要なタスク数を増やして、保護されているタスクの数よりも多くします。

## タスクスケールイン保護に必要な IAM アクセス許可
<a name="managed-instance-task-scale-in-protection-iam"></a>

タスクには、以下のアクセス許可を持つ Amazon ECS タスクロールが必要です。
+ `ecs:GetTaskProtection`: Amazon ECS コンテナエージェントが `GetTaskProtection` を呼び出すことを許可します。
+ `ecs:UpdateTaskProtection`: Amazon ECS コンテナエージェントが `UpdateTaskProtection` を呼び出すことを許可します。

# Amazon ECS タスクスケールイン保護のエンドポイント
<a name="managed-instance-task-scale-in-protection-endpoint"></a>

Amazon ECS コンテナエージェントは、`ECS_AGENT_URI` 環境変数を Amazon ECS タスクのコンテナに自動的に挿入して、コンテナエージェント API エンドポイントとやり取りする方法を提供します。

保護の必要性を自己判断できるタスクには、Amazon ECS コンテナエージェントエンドポイントを使用することをお勧めします。

コンテナが処理を開始すると、コンテナ内からタスクスケールイン保護のエンドポイントパス「`protectionEnabled`」を使用して `$ECS_AGENT_URI/task-protection/v1/state` 属性を設定できます。

コンテナ内からこの URI への PUT リクエストを使用すると、タスクのスケールイン保護が設定されます。この URI への GET リクエストは、タスクの現在の保護ステータスを返します。

## タスクスケールイン保護のリクエストパラメータ
<a name="managed-instance-task-scale-in-protection-request"></a>

次のリクエストパラメータで、`${ECS_AGENT_URI}/task-protection/v1/state` エンドポイントを使用してタスクスケールインプロテクションを設定できます。

`ProtectionEnabled`  
`true` を指定して、タスクを保護できるようにマークします。`false` を指定して保護を解除し、タスクを終了できるようにします。  
タイプ: ブール値  
必須: はい

`ExpiresInMinutes`  
タスクが保護されている時間 (分)。最小 1 分から最大 2,880 分 (48 時間) まで指定できます。この期間中、自動スケーリングサービスまたはデプロイからのスケールインイベントによってタスクが終了することはありません。この時間が経過すると、`protectionEnabled` パラメータは `false` に設定されます。  
時間を指定しない場合、タスクは自動的に 120 分 (2 時間) 保護されます。  
タイプ: 整数  
必須: いいえ

次の例は、異なる継続時間を持つタスク保護を設定する方法を示します。

**デフォルトの期間を使用してタスクを保護する方法の例**

この例は、デフォルトの期間が 2 時間に設定されているタスクを保護する方法を示しています。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```

**タスクを 60 分間保護する方法の例**

この例は、`expiresInMinutes` パラメータを使用してタスクを 60 分間保護する方法を示しています。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'      
```

**タスクを 24 時間保護する方法の例**

この例は、`expiresInMinutes` パラメータを使用してタスクを 24 時間保護する方法を示しています。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'      
```

PUT リクエストは次のレスポンスを返します。

```
{
  "protection": {
    "ExpirationDate": "2023-12-20T21:57:44.837Z",
    "ProtectionEnabled": true,
    "TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
  }
}
```

## タスクスケールイン保護のレスポンスパラメータ
<a name="managed-instance-task-scale-in-protection-response"></a>

次の情報が、JSON レスポンスタスクのスケールインプロテクションエンドポイント `${ECS_AGENT_URI}/task-protection/v1/state` から返されます。

`ExpirationDate`  
タスクの保護が期限切れになるエポックタイム。タスクが保護されていない場合、この値は NULL です。

`ProtectionEnabled`  
タスクのプロテクションステータス。タスクのスケールインプロテクションが有効になっている場合、値は `true` です。それ以外の場合は、`false` です。

`TaskArn`  
コンテナが属しているタスクの完全な Amazon リソースネーム (ARN)。

次の例は、保護されたタスクについて返される詳細を示しています。

```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```

```
{
    "protection":{
        "ExpirationDate":"2023-12-20T21:57:44Z",
        "ProtectionEnabled":true,
        "TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
    }
}
```

障害が発生すると、次の情報が返されます。

`Arn`  
タスクの完全な Amazon リソースネーム (ARN)。

`Detail`  
障害に関する詳細。

`Reason`  
失敗の理由。

次の例は、保護されていないタスクについて返される詳細を示しています。

```
{
    "failure":{
        "Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
        "Detail":null,
        "Reason":"TASK_NOT_VALID"
    }
}
```

例外が発生すると、次の情報が返されます。

`requestID`  
例外が発生する Amazon ECS API 呼び出しの AWS リクエスト ID。

`Arn`  
タスクまたはサービスの完全な Amazon リソースネーム (ARN)。

`Code`  
エラーコードです。

`Message`  
エラーメッセージです。  
`RequestError` または `RequestTimeout` エラーが表示される場合は、ネットワークに問題がある可能性があります。Amazon ECS の VPC エンドポイントを使用してみてください。

次の例は、エラーが発生したときに返される詳細を示したものです。

```
{
    "requestID":"12345-abc-6789-0123-abc",
    "error":{
        "Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
        "Code":"AccessDeniedException",
        "Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
    }    
}
```

ネットワークの問題や Amazon ECS コントロールプレーンがダウンしているなどの理由で Amazon ECS エージェントが Amazon ECS エンドポイントから応答を得られない場合、次のエラーが表示されます。

```
{
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "RequestCanceled",
    "Message": "Timed out calling Amazon ECS Task Protection API"
  }
}
```

Amazon ECS エージェントが Amazon ECS からスロットリング例外を受け取ると、次のエラーが表示されます。

```
{
  "requestID": "12345-abc-6789-0123-abc",
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "ThrottlingException",
    "Message": "Rate exceeded"
  }
}
```

# Fargate 用の Amazon ECS クラスター
<a name="fargate-capacity-providers"></a>

AWS Fargate キャパシティプロバイダーで Amazon ECS を使用すると、Amazon ECS タスクで Fargate と Fargate Spot キャパシティの両方を使用できます。

Fargate Spot を使用すると、割り込み許容のある Amazon ECS タスクを、Fargate 料金と比較して割引料金で実行できます。Fargate Spot は、予備のコンピュートキャパシティーでタスクを実行します。AWS がキャパシティを戻す必要がある場合、タスクは中断され、2 分間の警告が表示されます。

Fargate·と·Fargate·Spot キャパシティープロバイダーを使用するタスクが停止した場合、タスク状態の変更イベントが Amazon EventBridge に対し送信されます。停止した理由は原因を説明しています。詳細については、「[Amazon ECS タスク状態変更イベント](ecs_task_events.md)」を参照してください。

クラスターには、Fargate キャパシティプロバイダーと Auto Scaling グループキャパシティプロバイダーを混在させることができます。ただし、キャパシティプロバイダー戦略に含めることができるのは Fargate または Auto Scaling グループキャパシティプロバイダーのみで、両方を含めることはできません。詳細については、「[Auto Scaling グループキャパシティープロバイダー](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html#asg-capacity-providers)」を参照してください。

キャパシティプロバイダーを使用する場合は、次の点を考慮します。
+ キャパシティープロバイダーは、キャパシティープロバイダー戦略に関連付ける前に、クラスターに関連付ける必要があります。
+ キャパシティープロバイダー戦略には、最大 20 のキャパシティープロバイダーを指定できます。
+ Auto Scaling グループキャパシティプロバイダーを使用するサービスは、Fargate キャパシティプロバイダーを使用するように更新することはできません。逆の場合も同様です。
+ キャパシティプロバイダー戦略では、コンソールでキャパシティプロバイダーに `weight` 値が指定されていない場合、`1` のデフォルト値が使用されます。API または AWS CLI を使用する場合は、`0` のデフォルト値が使用されます。
+ キャパシティプロバイダー戦略内で複数のキャパシティプロバイダーを指定する場合、少なくとも 1 つのキャパシティプロバイダーのウェイト値が 0 より大きい必要があります。ウェイトが 0 のキャパシティープロバイダーはタスクの配置に使用されません。戦略に複数のキャパシティプロバイダーを指定し、すべて同じウェイトを 0 にした場合、キャパシティプロバイダー戦略を使用する `RunTask` または `CreateService` のアクションは失敗します。
+ キャパシティプロバイダー戦略では、1 つのキャパシティプロバイダーのみが定義された*ベース*値を持つことができます。ベース値を指定しない場合は、デフォルト値の 0 が使用されます。
+ クラスターには、Auto Scaling グループキャパシティプロバイダーと Fargate キャパシティプロバイダーの両方を混在させることができます。ただし、キャパシティプロバイダー戦略に含めることができるのは Auto Scaling グループまたは Fargate キャパシティプロバイダーのいずれかのみとなっており、両方を含めることはできません。
+ クラスターには、両方のキャパシティプロバイダーを使用するサービスとスタンドアロンタスクを混在させることができます。サービスは、起動タイプではなくキャパシティプロバイダー戦略を使用するように更新できます。ただし、その場合は強制的に新しいデプロイを行う必要があります。

## Fargate Spot 終了通知
<a name="fargate-capacity-providers-termination"></a>

需要が非常に多い時期は、Fargate Spot のキャパシティーが利用できない場合があります。これにより、Fargate Spot のタスクが遅れる可能性があります。これが発生すると、Amazon ECS サービスは必要なキャパシティーが使用可能になるまでタスクの起動を再試行します。Fargate が Spot キャパシティーをオンデマンドキャパシティに置き換えることはありません。

スポットの中断により Fargate Spot キャパシティーを使用するタスクが停止すると、タスクが停止する前に 2 分間の警告が送信されます。警告は、タスク状態変更イベントとして Amazon EventBridge に送信され、実行中のタスクに SIGTERM シグナルとして送信されます。サービスの一部として Fargate Spot を使用する場合、このシナリオでは、サービススケジューラは中断信号を受信し、利用可能なキャパシティがあれば Fargate Spot で追加のタスクを起動しようとします。タスクが 1 つしかないサービスは、キャパシティが利用可能になるまで中断されます。正常なシャットダウンの詳細については、「[ECS による正常なシャットダウン](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/)」を参照してください。

タスクが停止する前にコンテナが正常に終了するように、以下を設定できます。
+ タスクが使用しているコンテナ定義には、`120` 秒以下の `stopTimeout` 値を指定できます。デフォルトの `stopTimeout` 値は 30 秒です。`stopTimeout` 値を長く指定すると、タスク状態変更イベントが受信した時点から、コンテナが強制的に停止するまでの時間を長くすることができます。詳細については、「[[コンテナのタイムアウト]](task_definition_parameters.md#container_definition_timeout)」を参照してください。
+ クリーンアップアクションを実行するには、コンテナ内から SIGTERM シグナルを受信する必要があります。このシグナルの処理に失敗すると、`stopTimeout` が設定された後に SIGKILL シグナルを受信し、データが損失または破損する可能性があります。

タスク状態変更イベントのスニペットを以下に示します。このスニペットには、Fargate Spot 中断の停止理由と停止コードが表示されます。

```
{
  "version": "0",
  "id": "9bcdac79-b31f-4d3d-9410-fbd727c29fab",
  "detail-type": "ECS Task State Change",
  "source": "aws.ecs",
  "account": "111122223333",
  "resources": [
    "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6f1cebef"
  ],
  "detail": {
    "clusterArn": "arn:aws:ecs:us-east-1:111122223333:cluster/default",
    "createdAt": "2016-12-06T16:41:05.702Z",
    "desiredStatus": "STOPPED",
    "lastStatus": "RUNNING",
    "stoppedReason": "Your Spot Task was interrupted.",
    "stopCode": "SpotInterruption",
    "taskArn": "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6fEXAMPLE",
    ...
  }
}
```

以下は、Amazon ECS タスク状態変更イベントの EventBridge ルールを作成するために使用されるイベントパターンです。オプションで、`detail` フィールドでクラスターを指定できます。そうすると、そのクラスターのタスク状態変更イベントを受信することになります。EventBridge ルールの作成の詳細については、「*Amazon EventBridge ユーザーガイド*」の「[Amazon EventBridge の開始方法](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)」を参照してください。

```
{
    "source": [
        "aws.ecs"
    ],
    "detail-type": [
        "ECS Task State Change"
    ],
    "detail": {
        "clusterArn": [
            "arn:aws:ecs:us-west-2:111122223333:cluster/default"
        ]
    }
}
```

# Fargate ワークロード用の Amazon ECS クラスターを作成する
<a name="create-cluster-console-v2"></a>

クラスターを作成して、タスクとサービスを実行するインフラストラクチャを定義します。

これを開始する前に、「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」 の手順を完了し、適切な IAM 許可を割り当てる必要があります。詳細については、「[Amazon ECS クラスターの例](security_iam_id-based-policy-examples.md#IAM_cluster_policies)」を参照してください。Amazon ECS コンソールでは、CloudFormation スタックを作成することで、Amazon ECS クラスターに必要なリソースを作成します。

コンソールは、自動的に Fargate および Fargate Spot キャパシティープロバイダーをクラスターに関連付けます。

以下のオプションを変更できます。
+ クラスターに名前空間を追加します。

  名前空間を使用すると、クラスターで作成したサービスを、追加の設定なしで名前空間内の他のサービスに接続できます。詳細については、「[Amazon ECS サービスを相互接続する](interconnecting-services.md)」を参照してください。
+ タスクイベントを有効にして、タスク状態の変更に関する EventBridge 通知を受信します。
+ クラスターを識別しやすいようにタグを追加します。
+ マネージドストレージに AWS KMS キーを割り当てます。キーの作成方法の詳細については、*AWS Key Management Service ユーザーガイド*の「[KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
+ Fargate エフェメラルストレージに AWS KMS キーを割り当てます。キーの作成方法の詳細については、*AWS Key Management Service ユーザーガイド*の「[KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
+ ECS Exec の AWS KMS キーとログ記録を設定します。

## 手順
<a name="create-cluster-console-v2-procedure"></a>

**新しいクラスターを作成するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、**[Create Cluster]** (クラスターの作成) を選択します。

1. **[クラスター設定]** で以下を設定します。
   + **[クラスター名]** に一意の名前を入力します。

     名前には、最大 255 文字 (大文字と小文字)、数字、およびハイフンを含めることができます。
   + (オプション) Service Connect に使用する名前空間をクラスター名と別のものにするには、**[Service Connect のデフォルト]** の **[名前空間]** で、名前空間名を選択または入力します。共有名前空間を使用するには、名前空間 ARN を選択または入力します。共有名前空間の使用について詳しくは、「[共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect](service-connect-shared-namespaces.md)」を参照してください。

1. (オプション) Container Insights を使用して **モニタリング** を展開し、次のいずれかのオプションを選択します。
   + オブザーバビリティが強化された推奨の Container Insights を使用するには、**[オブザーバビリティが強化された Container Insights]** を選択します。
   + Container Insights を使用するには、**[Container Insights]** を選択します。

1. (オプション) タスクイベントを有効にするには、**[タスクイベント]** を展開し、**[タスクイベントを有効化]** をオンにします。

   タスクイベントを有効にすると、Amazon ECS はタスク状態変更イベントを EventBridge に送信します。これにより、タスクライフサイクルの変更を自動的にモニタリングして対応できます。

1. (オプション) ECS Exec を使用してクラスター内のタスクをデバッグするには、**[トラブルシューティング設定]** を展開し、以下を設定します。
   + (オプション) **[ECS Exec の AWS KMS キー]** には、ECS Exec セッションデータの暗号化に使用する AWS KMS キーの ARN を入力します。
   + (オプション) **[ECS Exec ログ記録]** で、ログの送信先を選択します。
     + CloudWatch Logs にログを送信するには、**[Amazon CloudWatch]** を選択します。
     + Amazon S3 にログを送信するには、**[Amazon S3]** を選択します。
     + ログ記録を無効にするには、**[なし]** を選択します。

1. (オプション) **[暗号化]** で以下を設定できます。
   + Fargate エフェメラルストレージ上のデータを暗号化します。**[暗号化]** の **[Fargate エフェメラルストレージ]** で、Fargate エフェメラルストレージデータの暗号化に使用する AWS KMS キーの ARN を入力します。
   + マネージドストレージのデータを暗号化します。**[暗号化]** の **[マネージドストレージ]** に、マネージドストレージデータの暗号化に使用する AWS KMS キーの ARN を入力します。

1. (オプション) クラスターを識別しやすくするには、**[Tags]** (タグ) を展開し、タグを設定します。

   [タグの追加] [**タグの追加**] を選択して、以下を実行します。
   + [**キー**] にはキー名を入力します。
   + [**値**] にキー値を入力します。

   [タグを削除] タグのキーと値の右側にある [**削除**] を選択します。

1. **[作成]** を選択します。

## 次のステップ
<a name="fargate-cluster-next-steps"></a>

クラスターを作成したら、アプリケーションのタスク定義を作成し、スタンドアロンタスク、またはサービスの一部として実行できます。詳細については次を参照してください:
+ [Amazon ECS のタスク定義](task_definitions.md)
+ [Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)
+ [Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)

# EC2 ワークロード用の Amazon ECS キャパシティプロバイダー
<a name="asg-capacity-providers"></a>

キャパシティーとして Amazon EC2 インスタンスを使用する場合は、Auto Scaling グループを使用し、クラスターに登録されている Amazon EC2 インスタンスを管理します。Auto Scaling により、アプリケーションの負荷を処理するために適切な数の使用可能な Amazon EC2 インスタンスを確保できるようになります。

マネージドスケーリング機能を使用して、Auto Scaling グループのスケールインおよびスケールアウトアクションを Amazon ECS に管理させることも、自分自身でスケーリングアクションを管理することもできます。詳細については、「[クラスターの自動スケーリングで Amazon ECS キャパシティーを自動的に管理する](cluster-auto-scaling.md)」を参照してください。

新しい空の Auto Scaling グループを作成することをお勧めします。既存の Auto Scaling グループを使用する場合、キャパシティプロバイダーの作成に使用される Auto Scaling グループの前に、既に実行され、Amazon EC2 クラスターに登録されていたグループに関連付けられた Amazon ECS インスタンスが、キャパシティプロバイダーに正しく登録されないことがあります。これにより、キャパシティプロバイダー戦略でキャパシティプロバイダーを使用するときに問題が発生する可能性があります。`DescribeContainerInstances` を使用し、コンテナインスタンスがキャパシティープロバイダーに関連付けられているかどうかを確認できます。

**注記**  
空の Auto Scaling グループを作成するには、必要なカウントをゼロに設定します。キャパシティプロバイダーを作成してクラスターに関連付けた後、スケールアウトできます。  
Amazon ECS コンソールを使用する場合、Amazon ECS は、CloudFormation スタックの一部として、ユーザーの代わりに Amazon EC2 起動テンプレートと Auto Scaling グループを作成します。これらには、プレフィックスとして `EC2ContainerService-<ClusterName>` が付きます。Auto Scaling グループは、そのクラスターのキャパシティープロバイダーとして使用できます。

マネージドインスタンスドレイニングを使用して、ワークロードを中断することなく Amazon EC2 インスタンスを正常終了できるようにすることをお勧めします。この機能は、デフォルトでオンになっています。詳細については、[EC2 インスタンスで実行されている Amazon ECS ワークロードを安全に停止する](managed-instance-draining.md)を参照してください。

コンソール内の Auto Scaling グループキャパシティープロバイダーを使用する場合は、次の点を考慮する必要があります。
+ Auto Scaling グループをスケールアウトするには、その `MaxSize` が 0 より大きくなければなりません。
+ Auto Scaling グループは、インスタンスの重み付けを設定することはできません。
+ Auto Scaling グループが実行されるタスクの数に合わせてスケールアウトできない場合、タスクは `PROVISIONING` の後の状態に移行できません。
+ キャパシティプロバイダーによって管理される Auto Scaling グループに関連付けられているスケーリングポリシーリソースは、変更しないでください。
+ キャパシティプロバイダーの作成時にマネージドスケーリングがオンになっている場合、Auto Scaling グループの希望するカウントを `0` に設定できます。マネージドスケーリングがオンになっている場合、Amazon ECS は Auto Scaling グループのスケールインアクションとスケールアウトアクションを管理します。
+ キャパシティープロバイダーは、キャパシティープロバイダー戦略に関連付ける前に、クラスターに関連付ける必要があります。
+ キャパシティープロバイダー戦略には、最大 20 のキャパシティープロバイダーを指定できます。
+ Auto Scaling グループキャパシティプロバイダーを使用するサービスは、Fargate キャパシティプロバイダーを使用するように更新することはできません。逆の場合も同様です。
+ キャパシティプロバイダー戦略では、コンソールでキャパシティプロバイダーに `weight` 値が指定されていない場合、`1` のデフォルト値が使用されます。API または AWS CLI を使用する場合は、`0` のデフォルト値が使用されます。
+ キャパシティプロバイダー戦略内で複数のキャパシティプロバイダーを指定する場合、少なくとも 1 つのキャパシティプロバイダーのウェイト値が 0 より大きい必要があります。ウェイトが 0 のキャパシティープロバイダーはタスクの配置に使用されません。戦略に複数のキャパシティプロバイダーを指定し、すべて同じウェイトを 0 にした場合、キャパシティプロバイダー戦略を使用する `RunTask` または `CreateService` のアクションは失敗します。
+ キャパシティプロバイダー戦略では、1 つのキャパシティプロバイダーのみが定義された*ベース*値を持つことができます。ベース値を指定しない場合は、デフォルト値の 0 が使用されます。
+ クラスターには、Auto Scaling グループキャパシティプロバイダーと Fargate キャパシティプロバイダーの両方を混在させることができます。ただし、キャパシティプロバイダー戦略に含めることができるのは Auto Scaling グループまたは Fargate キャパシティプロバイダーのみで、両方を含めることはできません。
+ クラスターには、キャパシティプロバイダーと起動タイプの両方を使用するサービスとスタンドアロンタスクを混在させることができます。サービスは、起動タイプではなくキャパシティプロバイダー戦略を使用するように更新できます。ただし、その場合は強制的に新しいデプロイを行う必要があります。
+ Amazon ECS では、Amazon EC2 Auto Scaling ウォームプールをサポートします。ウォームプールは、事前に初期化済みの Amazon EC2 インスタンスグループでサービス開始が準備されています。アプリケーションがスケールアウトする必要がある場合は、常に Amazon EC2 Auto Scaling はコールドインスタンスを起動するのではなく、ウォームプールから事前に初期化されたインスタンスを使用します。これにより、インスタンスがサービスを開始する前に、最終的な初期化プロセスを実行できるようになります。詳細については、「[Amazon ECS Auto Scaling グループ用に事前初期化されたインスタンスを設定する](using-warm-pool.md)」を参照してください。

Amazon EC2 Auto Scaling 起動テンプレートの作成についての詳細は、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling 起動テンプレート](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)」を参照してください。Amazon EC2 Auto Scaling グループの作成についての詳細は、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)」を参照してください。

# Amazon ECS の Amazon EC2 コンテナインスタンスのセキュリティに関する考慮事項
<a name="ec2-security-considerations"></a>

脅威モデル内での単一のコンテナインスタンスとそのアクセスを考慮する必要があります。たとえば、影響を受けるひとつのタスクが、同じインスタンス上の感染していないタスクの IAM アクセス許可を利用できる場合があります。

これを防ぐには、次のことを行うことをお勧めします。
+ タスクを実行するときは、管理者権限を使用しないでください。
+ タスクに割り当てるタスクロールは最小特権にします。

  コンテナエージェントは、Amazon ECS リソースへのアクセスに使用される固有の認証情報 ID を持つトークンを自動的に作成します。
+ `awsvpc` ネットワークモードを使用するタスクで実行されたコンテナが、Amazon EC2 のインスタンスプロファイルに入力されている認証情報にアクセスするのを防止しつつ、タスクロールで指定されている許可を有効にするには、エージェントの設定ファイルで `ECS_AWSVPC_BLOCK_IMDS` エージェント設定変数を [true] に設定し、そのエージェントを再起動します。
+ Amazon GuardDuty ランタイムモニタリングを使用して、AWS 環境内のクラスターとコンテナの脅威を検出します。Runtime Monitoring では、ファイルアクセス、プロセス実行、ネットワーク接続などの個々の Amazon ECS ワークロードを実行時に可視化する、GuardDuty セキュリティエージェントを使用します。詳細については、「*GuardDuty ユーザーガイド*」の「[GuardDuty ランタイムモニタリング](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)」を参照してください。

# Amazon EC2 ワークロード用の Amazon ECS クラスターを作成する
<a name="create-ec2-cluster-console-v2"></a>

クラスターを作成して、タスクとサービスを実行するインフラストラクチャを定義します。

これを開始する前に、「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」 の手順を完了し、適切な IAM 許可を割り当てる必要があります。詳細については、「[Amazon ECS クラスターの例](security_iam_id-based-policy-examples.md#IAM_cluster_policies)」を参照してください。Amazon ECS コンソールでは、CloudFormation スタックを作成することで、Amazon ECS クラスターに必要なリソースを簡単に作成できます。

クラスターの作成プロセスをできるだけ簡単にするために、コンソールには、以下で説明する多くの選択肢に対するデフォルトの選択肢があります。コンソール内のほとんどのセクションには、詳細なコンテキストを提供するヘルプパネルもあります。

クラスターの作成時に Amazon EC2 インスタンスを登録することや、作成後のクラスターに対し、追加のインスタンスを登録することもできます。

以下のデフォルトオプションを変更できます。
+ インスタンスを起動するサブネットを変更します。
+ コンテナインスタンスへのトラフィックを制御するために使用されるセキュリティグループを変更します。
+ クラスターに名前空間を追加します。

  名前空間を使用すると、クラスターで作成したサービスを、追加の設定なしで名前空間内の他のサービスに接続できます。詳細については、「[Amazon ECS サービスを相互接続する](interconnecting-services.md)」を参照してください。
+ タスクイベントを有効にして、タスク状態の変更に関する EventBridge 通知を受信します。
+ マネージドストレージに AWS KMS キーを割り当てます。キーの作成方法の詳細については、*AWS Key Management Service ユーザーガイド*の「[KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
+ Fargate エフェメラルストレージに AWS KMS キーを割り当てます。キーの作成方法の詳細については、*AWS Key Management Service ユーザーガイド*の「[KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
+ ECS Exec の AWS KMS キーとログ記録を設定します。
+ クラスターを識別しやすいようにタグを追加します。

## Auto Scaling グループオプション
<a name="capacity-providers"></a>

Amazon EC2 インスタンスを使用する場合は、タスクとサービスが実行されるインフラストラクチャを管理するために Auto Scaling グループを指定する必要があります。

新しい Auto Scaling グループの作成を選択すると、自動的に次の動作が設定されます。
+ Amazon ECS は Auto Scaling グループのスケールインアクションとスケールアウトアクションを管理します。
+ Amazon ECS は、タスクを含む Auto Scaling グループ内の Amazon EC2 インスタンスがスケールインアクション中に終了されるのを防ぎます。詳細については、*AWS Auto Scaling ユーザーガイド*の「[インスタンスの保護](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection)」を参照してください。

次の Auto Scaling グループプロパティを構成し、グループに対して起動するインスタンスのタイプと数を決定します。
+ Amazon ECS に最適化された AMI。
+ インスタンスタイプ。
+ インスタンスに接続するときに ID を証明する SSH キーペア。SSH キーの作成については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 のキーペアと Linux インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。
+ Auto Scaling グループに対して起動するインスタンスの最小数。
+ Auto Scaling グループに対して開始されるインスタンスの最大数。

  グループをスケールアウトするには、最大値を 0 より大きくする必要があります。

Amazon ECS は、CloudFormation スタックの一部としてユーザーに代わり Amazon EC2 Auto Scaling 起動テンプレートと Auto Scaling グループを作成します。AMI、インスタンスタイプ、SSH キーペアのために指定した値は、起動テンプレート内に保存されます。テンプレートは `EC2ContainerService-<ClusterName>` プレフィックスが付いているため、識別が容易になります。Auto Scaling グループのプレフィックスは `<ClusterName>-ECS-Infra-ECSAutoScalingGroup` です。

Auto Scaling グループに対して起動されたインスタンスは、起動テンプレートを使用します。

## ネットワークのオプション
<a name="networking-options"></a>

デフォルトでは、インスタンスはリージョンのデフォルトのサブネットで起動されます。コンテナインスタンスへのトラフィックを制御するセキュリティグループは、現在サブネットに関連付けられているものが使用されます。インスタンスのサブネットとセキュリティグループは変更できます。

既存のサブネットを選択できます。既存のセキュリティグループを使用するか、セキュリティグループを新規作成できます。IPv6 のみの設定でタスクを作成するには、IPv6 CIDR ブロックのみを含むサブネットを使用します。

セキュリティグループを新規作成する場合は、少なくとも 1 つのインバウンドルールを指定する必要があります。

インバウンドルールは、コンテナインスタンスに到達できるトラフィックを決定し、以下のプロパティを含みます。
+ 許可するプロトコル
+ 許可するポートの範囲
+ インバウンドトラフィック (送信元)

特定のアドレスまたは CIDR ブロックからのインバウンドトラフィックを許可するには、許可された CIDR で [**送信元**] に [**カスタム**] を使用します。

すべての送信先からのインバウンドトラフィックを許可するには、[**送信元**] に [**すべて**] を使用してください。これにより、これにより、0.0.0.0/0 IPv4 CIDR ブロックと::/0 IPv6 CIDR ブロックが自動的に追加されます。

ローカルコンピューターからのインバウンドトラフィックを許可するには、[**送信元**] に [**ソースグループ**] を使用します。これにより、ローカルコンピュータの現在の IP アドレスが送信元アドレスとして自動的に追加されます。

**新しいクラスターを作成するには (Amazon ECS コンソール)**

開始する前に、適切な IAM アクセス許可を割り当ててください。詳細については、「[Amazon ECS クラスターの例](security_iam_id-based-policy-examples.md#IAM_cluster_policies)」を参照してください。

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、**[Create Cluster]** (クラスターの作成) を選択します。

1. **[クラスター設定]** で以下を設定します。
   + **[クラスター名]** に一意の名前を入力します。

     名前には、最大 255 文字 (大文字と小文字)、数字、およびハイフンを含めることができます。
   + (オプション) Service Connect に使用する名前空間をクラスター名と別のものにするには、**[Service Connect のデフォルト]** の **[名前空間]** で、名前空間名を選択または入力します。共有名前空間を使用するには、名前空間 ARN を選択または入力します。共有名前空間の使用について詳しくは、「[共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect](service-connect-shared-namespaces.md)」を参照してください。

1. Amazon EC2 インスタンスをクラスターに追加するには、**[インフラストラクチャ]** を展開し、次に **[Fargate インスタンスとセルフマネージドインスタンス]** を選択します。

   次に、キャパシティープロバイダーとして機能する Auto Scaling グループを設定します。

   1. 既存の Auto Scaling グループを使用するには、**[Auto Scaling group (ASG)]** (Auto Scaling グループ) からグループを選択します。

   1. Auto Scaling グループを作成するには、**Auto Scaling group(ASG)** (Auto Scaling グループ) から、**[Create new group]** (新しいグループの作成) を選択し、グループに関する以下の詳細情報を入力します。
      + **[プロビジョニングモデル]** で、**[オンデマンド]**インスタンスと**[スポット]**インスタンスのどちらを使用するかを選択します。
      + スポットインスタンスを使用する場合は、**[割り当て戦略]** で、インスタンスに使用するスポットキャパシティプール (インスタンスタイプおよびアベイラビリティーゾーン) を選択します。

        ほとんどのワークロードでは、**[料金キャパシティ最適化]** を選択できます。

        詳細については、「*Amazon EC2 ユーザーガイド*」の「[スポットインスタンスの配分戦略](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html)」を参照してください。
      + **コンテナインスタンスの Amazon マシンイメージ (AMI)** で、Auto Scaling グループインスタンスの [Amazon ECS 最適化 AMI] を選択します。
      + **[EC2 instance type]** (EC2 インスタンスタイプ) を使用する場合、ワークロードのインスタンスタイプを選択します。

         マネージドスケーリングは、Auto Scaling グループが同じインスタンスタイプまたは類似のインスタンスタイプを使用している場合に最適です。
      + **[EC2 インスタンスロール]**では、既存のコンテナインスタンスロールを選択するか、新しいコンテナインスタンスロールを作成できます。

        詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
      + **[Capacity]** (キャパシティー) には、Auto Scaling グループで起動するインスタンスの最小数と最大数を入力します。
      + **[SSH key pair]** (SSH キーペア) を使用する場合、インスタンスに接続する際に ID を証明するペアを選択してください。
      + より大きなイメージとストレージを許容するには、**[ルート EBS ボリュームサイズ]** に単位 GiB で値を入力します。

1. (オプション) VPC とサブネットを変更するには、**[Amazon EC2 インスタンスのネットワーキング]** で、次のいずれかの操作を実行します。
   + サブネットを削除するには、**[Subnets]** (サブネット) で、削除するサブネットごとに **[X]** を選択します。
   + **デフォルト** VPC 以外の VPC に変更するには、**[VPC]** で既存の **VPC** を選択し、**[サブネット]** でサブネットを選択します。IPv6 のみの設定の場合は、IPv6 CIDR ブロックを持つ VPC と IPv6 CIDR ブロックのみを持つサブネットを選択します。
   + セキュリティグループを選択します。[**セキュリティグループ**] で、次のいずれかのオプションを選択します。
     + 既存のセキュリティグループを選択するには、[**既存のセキュリティグループの選択**] を選択してから、セキュリティグループを選択します。
     + 新しいセキュリティグループを作成するには、[**新しいセキュリティグループの作成**] を選択します。その後、各インバウンドルールについて [**ルールの追加**] を選択します。

       インバウンドルールの詳細については、「[ネットワークのオプション](#networking-options)」を参照してください。
   + Amazon EC2 コンテナインスタンスにパブリック IP アドレスを自動的に割り当てるには、**[パブリック IP の自動割り当て]** で以下のいずれかのオプションを選択します。
     + **サブネット設定を使用** — インスタンスが起動するサブネットがパブリックサブネットの場合、パブリック IP アドレスをインスタンスに割り当てます。
     + **オンにする** — インスタンスにパブリック IP アドレスを割り当てます。

1. (オプション) Container Insights を使用して **モニタリング** を展開し、次のいずれかのオプションを選択します。
   + オブザーバビリティが強化された推奨の Container Insights を使用するには、**[オブザーバビリティが強化された Container Insights]** を選択します。
   + Container Insights を使用するには、**[Container Insights]** を選択します。

1. (オプション) タスクイベントを有効にするには、**[タスクイベント]** を展開し、**[タスクイベントを有効化]** をオンにします。

   タスクイベントを有効にすると、Amazon ECS はタスク状態変更イベントを EventBridge に送信します。これにより、タスクライフサイクルの変更を自動的にモニタリングして対応できます。

1. (オプション) ECS Exec を使用してクラスター内のタスクをデバッグするには、**[トラブルシューティング設定]** を展開し、以下を設定します。
   + (オプション) **[ECS Exec の AWS KMS キー]** には、ECS Exec セッションデータの暗号化に使用する AWS KMS キーの ARN を入力します。
   + (オプション) **[ECS Exec ログ記録]** で、ログの送信先を選択します。
     + CloudWatch Logs にログを送信するには、**[Amazon CloudWatch]** を選択します。
     + Amazon S3 にログを送信するには、**[Amazon S3]** を選択します。
     + ログ記録を無効にするには、**[なし]** を選択します。

1. (オプション)

   ランタイムのモニタリングを手動オプションで使用していて、このクラスターを GuardDuty でモニタリングしたい場合は、**[タグを追加]** を選択して次の操作を行います。
   + **[キー]** で「**guardDutyRuntimeMonitoringManaged**」と入力します。
   + **[Value]** (値) に「**true**」と入力します。

1. (オプション) マネージドストレージのデータを暗号化します。**[暗号化]** の **[マネージドストレージ]** に、マネージドストレージデータの暗号化に使用する AWS KMS キーの ARN を入力します。

1. (オプション) クラスタータグを管理するには、**[Tags]** (タグ) を展開し、次のいずれかのオペレーションを実行します。

   [タグの追加] [**タグの追加**] を選択して、以下を実行します。
   + [**キー**] にはキー名を入力します。
   + [**値**] にキー値を入力します。

   [タグを削除] タグのキーと値の右側にある [**削除**] を選択します。

1. **[作成]** を選択します。

## 次のステップ
<a name="ec2-cluster-next-steps"></a>

クラスターを作成したら、アプリケーションのタスク定義を作成し、スタンドアロンタスク、またはサービスの一部として実行できます。詳細については次を参照してください:
+ [Amazon ECS のタスク定義](task_definitions.md)
+ [Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)
+ [Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)

# クラスターの自動スケーリングで Amazon ECS キャパシティーを自動的に管理する
<a name="cluster-auto-scaling"></a>

Amazon ECS では、クラスターに登録された Amazon EC2 インスタンスのスケーリングを管理できます。これは、Amazon ECS *クラスターの自動スケーリング*と呼ばれます。Amazon ECS Auto Scaling グループのキャパシティープロバイダーを作成するときに、マネージドスケーリングを有効にします。その後、この Auto Scaling グループのインスタンス使用率のターゲットパーセンテージ (`targetCapacity`) を設定します。Amazon ECS は 2 つのカスタム CloudWatch メトリクス、および Auto Scaling グループに対するターゲット追跡スケーリングポリシーを作成します。また、Amazon ECS は、タスクが使用するリソース使用率に基づいて、スケールインアクションとスケールアウトアクションを管理します。

クラスターに関連付けられている各 Auto Scaling グループのキャパシティプロバイダーについて、Amazon ECS は次のリソースを作成し、管理します。
+ 低いメトリクス値の CloudWatch アラーム
+ 高いメトリクス値の CloudWatch アラーム
+ ターゲットの追跡スケーリングポリシー
**注記**  
Amazon ECS は、ターゲットの追跡スケーリングポリシーを作成し、Auto Scaling グループにアタッチします。ターゲットの追跡スケーリングポリシーを更新するには、スケーリングポリシーを直接更新するのではなく、キャパシティプロバイダーのマネージドスケーリング設定を更新します。

マネージドスケーリングを無効にするか、クラスターからキャパシティプロバイダーの関連付けを解除すると、Amazon ECS は CloudWatch メトリクスとターゲットの追跡スケーリングポリシーのリソースの両方を削除します。

Amazon ECS では、実行するアクションを決定するのに次のメトリクスを使用します。

`CapacityProviderReservation`  
特定のキャパシティプロバイダーで使用されているコンテナインスタンスの割合。Amazon ECS はこのメトリクスを生成します。  
Amazon ECS は、`CapacityProviderReservation` の値を 0～100 の数値に設定します。Amazon ECS は、次の式を使用して Auto Scaling グループに残っているキャパシティの割合を表します。その後、Amazon ECS は CloudWatch にメトリクスをパブリッシュします。メトリクスの算出方法の詳細については、「[Amazon ECS クラスター自動スケーリングを詳しく知る](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)」を参照してください。  

```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```

`DesiredCapacity`  
Auto Scaling グループのキャパシティ量。このメトリクスは CloudWatch に公開されていません。

Amazon ECS は `AWS/ECS/ManagedScaling` 名前空間内の CloudWatch に `CapacityProviderReservation` メトリックを公開します。`CapacityProviderReservation` メトリクスは、次のいずれかのアクションを実行します。

**`CapacityProviderReservation` の値は `targetCapacity` に等しいです**  
Auto Scaling グループはスケールインまたはスケールアウトする必要はありません。目標使用率に達しました。

**`CapacityProviderReservation` の値は `targetCapacity` より大きいです**  
キャパシティのパーセンテージを使用しているタスクの数が、自分の `targetCapacity` のパーセンテージを上回っています。`CapacityProviderReservation` メトリクスの値が増加すると、関連する CloudWatch アラームが動作します。このアラームは Auto Scaling グループの `DesiredCapacity` 値を更新します。Auto Scaling グループはこの値を使用して EC2 インスタンスを起動し、クラスターに登録します。  
`targetCapacity` がデフォルト値の 100% の場合、インスタンスにタスクを実行できる空き容量がないため、スケールアウト中は新しいタスクは `PENDING` 状態になります。新しいインスタンスが ECS に登録されると、これらのタスクは新しいインスタンスで開始されます。

**`CapacityProviderReservation` の値は `targetCapacity` 未満です**  
キャパシティのパーセンテージを使用しているタスクが自分の `targetCapacity` のパーセンテージよりも少なく、終了できるインスタンスが少なくとも 1 つあります。`CapacityProviderReservation` メトリクスの値が減少すると、関連する CloudWatch アラームが動作します。このアラームは Auto Scaling グループの `DesiredCapacity` 値を更新します。Auto Scaling グループはこの値を使用して EC2 コンテナインスタンスを終了し、クラスターから登録解除します。  
Auto Scaling グループは、終了ポリシーを使用して、スケールインイベント中に最初に終了するインスタンスを決定します。さらに、インスタンスのスケールイン保護の設定は、回避します。クラスター自動スケーリングでは、マネージドターミネーション保護を有効にすると、どのインスタンスにインスタンススケールイン保護が設定されているかを管理できます。終了保護の詳細については、「[Amazon ECS が終了するインスタンスの制御](managed-termination-protection.md)」を参照してください。詳細については、*Amazon EC2 Auto Scaling ユーザーガイド*の「[スケールイン時にどの自動スケーリングインスタンスを終了するかのコントロール](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html)」を参照してください。

クラスターの自動スケーリングを使用するときは、次の点を考慮してください。
+ キャパシティプロバイダーに関連付けられている Auto Scaling グループが希望するキャパシティは、Amazon ECS が管理しているもの以外のスケーリングポリシーを変更または管理しないでください。
+ Amazon ECS が 0 インスタンスからスケールアウトする場合、自動的に 2 つのインスタンスを起動します。
+ Amazon ECS は、ユーザーに代わって AWS Auto Scaling を呼び出すために必要なアクセス許可として `AWSServiceRoleForECS` サービスにリンクされた IAM ロールを使用します。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
+ Auto Scaling グループでキャパシティプロバイダーを使用する場合、キャパシティプロバイダーを作成するユーザー、グループ、ロールには `autoscaling:CreateOrUpdateTags` アクセス許可が必要です。これは、Auto Scaling グループが、キャパシティープロバイダーに関連付けるときに、Amazon ECS が Auto Scaling グループにタグを追加するためです。
**重要**  
ツールの使用により `AmazonECSManaged` タグが Auto Scaling グループから削除されないようにしてください。このタグが削除されると、Amazon ECS はスケーリングを管理できません。
+ クラスターの自動スケーリングは、グループの **[MinimumCapacity]** と **[MaximumCapacity]** を変更しません。グループをスケールアウトするには、**[MaximumCapacity]** を 0 より大きくする必要があります。
+ 自動スケーリング(マネージドスケーリング) がオンになっている場合、キャパシティプロバイダーは、同時に 1 つのクラスターにしか接続できません。キャパシティープロバイダーがマネージドスケーリングをオフにしている場合は、複数のクラスターに関連付けることができます。
+ マネージドスケーリングがオフの場合、キャパシティプロバイダーはスケールインまたはスケールアウトを実行しません。キャパシティプロバイダー戦略を使用して、キャパシティプロバイダー間でタスクのバランスを取ることができます。
+ `binpack` 戦略は、キャパシティに関して最も効率的な戦略です。
+ ターゲットキャパシティが 100% 未満の場合、配置戦略内では、`binpack` 戦略が `spread` 戦略よりも高い優先順位を持つ必要があります。こうすることで、各タスクにハードウェア専有インスタンスが割り当てられるか、上限に達するまで、キャパシティプロバイダーはスケールアウトできなくなります。

## クラスターの自動スケーリングをオンにする
<a name="cluster-auto-scale-use"></a>

コンソールまたは AWS CLI を使用して、クラスターの自動スケーリングをオンにすることができます。

コンソールを使用して EC2 キャパシティプロバイダーを用いるクラスターを作成すると、Amazon ECS がユーザーに代わって Auto Scaling グループを作成し、ターゲット容量を設定します。詳細については、「[Amazon EC2 ワークロード用の Amazon ECS クラスターを作成する](create-ec2-cluster-console-v2.md)」を参照してください。

ユーザーが Auto Scaling グループを作成してクラスターに割り当てることもできます。詳細については、「[Amazon ECS キャパシティープロバイダーを更新する](update-capacity-provider-console-v2.md)」を参照してください。

AWS CLI を使用する場合、クラスターを作成した後、次の手順に従います。

1. キャパシティプロバイダーを作成する前に、Auto Scaling グループを作成する必要があります。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)」を参照してください。

1. `put-cluster-capacity-providers` を使用して、クラスターキャパシティプロバイダーを変更します。詳細については、「[Amazon ECS クラスターの自動スケーリングを有効にする](turn-on-cluster-auto-scaling.md)」を参照してください。

# Amazon ECS クラスターの自動スケーリングの最適化
<a name="capacity-cluster-speed-up-ec2"></a>

Amazon EC2 で Amazon ECS を実行するお客様は、クラスターの自動スケーリングを利用して Amazon EC2 Auto Scaling グループのスケーリングを管理できます。クラスターの自動スケーリングを使用すると、Auto Scaling グループを自動的にスケーリングするように Amazon ECS を設定することができ、ユーザーはタスクの実行に集中できます。Amazon ECS では、追加の操作を必要とせずに、必要に応じて Auto Scaling グループがスケールインおよびスケールアウトします。Amazon ECS キャパシティープロバイダーは、アプリケーションの需要を満たすのに十分なコンテナインスタンスを確保することで、クラスター内のインフラストラクチャを管理するために使用されます。クラスターの自動スケーリングが内部でどのように機能するかについては、「[Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)」を参照してください。

クラスターの自動スケーリングは、Auto Scaling グループとの CloudWatch ベースの 統合を利用して、クラスターキャパシティーを調整します。したがって、次に関連する固有のレイテンシーがあります。
+ CloudWatch メトリクスの発行 
+ メトリクス `CapacityProviderReservation` が CloudWatch アラームに抵触 (高と低の両方) するまでにかかる時間
+ 新しく起動した Amazon EC2 インスタンスがウォームアップするのにかかる時間 以下のアクションを実行して、クラスターの自動スケーリングの応答性を高め、デプロイを高速化できます。

## キャパシティープロバイダーのステップスケーリングサイズ
<a name="cas-step-size"></a>

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 を介してのみ使用できます。

## インスタンスのウォームアップ期間
<a name="instance-warmup-period"></a>

インスタンスのウォームアップ期間は、新たに起動された Amazon EC2 インスタンスが Auto Scaling グループの CloudWatch メトリックスに反映されるまでの時間です。指定されたウォームアップ期間が終了すると、そのインスタンスは Auto Scaling グループの集計メトリクスにカウントされ、クラスターの自動スケーリングは、必要なインスタンス数を推定するための次の計算ループに進みます。

[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) または [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API を使用して小さい値に設定することで、スケーリングの応答性を向上させることができます。過剰なプロビジョニングを回避できるように、値を 60 秒以上に設定することをお勧めします。

## 予備のキャパシティー
<a name="spare-capacity"></a>

キャパシティープロバイダーにタスクを配置するために使用できるコンテナインスタンスがない場合は、Amazon EC2 インスタンスをその場で起動してクラスターキャパシティーを増やし (スケールアウトし)、それらのインスタンスが起動するまで待ってからコンテナを起動する必要があります。これにより、タスクの起動レートが大幅に低下する可能性があります。ここでは 2 つのオプションがあります。

 この場合、予備の Amazon EC2 キャパシティーを事前に起動してタスクを実行する準備をしておくことで、実質的なタスク起動レートを上げることができます。`Target Capacity` 設定を使用して、クラスターで予備のキャパシティーを保持するかどうかを指定できます。例えば、`Target Capacity` を 80 % に設定することで、クラスターに常に 20 % の予備のキャパシティーが必要であることを示します。この予備のキャパシティーにより、スタンドアロンタスクをすぐに起動できるようになり、タスクの起動がスロットリングされなくなります。このアプローチのトレードオフは、予備のクラスターキャパシティーを保持するコストが増加する可能性があることです。

検討できる代替アプローチは、キャパシティープロバイダーではなくサービスにヘッドルームを追加することです。つまり、予備のキャパシティーを起動するための `Target Capacity` 設定を小さくする代わりに、ターゲット追跡スケーリングメトリクス、またはサービス自動スケーリングのステップスケーリングのしきい値を変更することで、サービス内のレプリカの数を増やすことができます。このアプローチが有用なのはワークロードの急増に対してのみであり、新しいサービスをデプロイし、初めて 0 から N タスクに移行する場合には効果がないことに注意してください。関連するスケーリングポリシーの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html)」または「[ステップスケーリングポリシー](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html)」を参照してください。

# Amazon ECS マネージドスケーリング動作
<a name="managed-scaling-behavior"></a>

マネージドスケーリングを使用する Auto Scaling グループキャパシティプロバイダーがある場合、Amazon ECS はクラスターに追加する最適なインスタンス数を見積もり、この値を使用してリクエストまたはリリースするインスタンス数を決定します。

## マネージドスケールアウト動作
<a name="managed-scaling-scaleout"></a>

Amazon ECS は、サービス、スタンドアロンタスク、またはクラスターのデフォルトからのキャパシティープロバイダー戦略に従って、各タスクのキャパシティープロバイダーを選択します。Amazon ECS は、単一のキャパシティプロバイダーのために、これらの残りのステップに従います。

キャパシティプロバイダー戦略のないタスクはキャパシティプロバイダーによって無視されます。キャパシティプロバイダー戦略がない保留中のタスクによって、キャパシティプロバイダーがスケールアウトされることはありません。タスクまたはサービスが起動タイプを設定する場合、タスクまたはサービスはキャパシティプロバイダー戦略を設定できません。

以下では、スケールアウト動作について詳しく説明します。
+ このキャパシティプロバイダーのすべてのプロビジョニングタスクをグループ化し、各グループが同じリソース要件を持つようにします。
+ グループ内の複数のインスタンスタイプを使用する場合、Auto Scaling グループ内のインスタンスタイプはパラメータによってソートされます。これらのパラメータには vCPU、メモリ、Elastic Network Interface (ENI)、ポート、GPU が含まれます。各パラメータの最小インスタンスタイプと最大インスタンスタイプが選択されます。インスタンスタイプの選択方法の詳細については、「[Amazon ECS 用の Amazon EC2 コンテナインスタンス](create-capacity.md)」を参照してください。
**重要**  
タスクのグループに、Auto Scaling グループの最小のインスタンスタイプよりも大きなリソース要件がある場合、そのタスクのグループは、このキャパシティプロバイダーでは実行できません。キャパシティプロバイダーは、Auto Scaling グループをスケールしません。タスクは `PROVISIONING` 状態のままです。  
タスクが `PROVISIONING` 状態にとどまらないようにするには、最小リソース要件ごとに個別の Auto Scaling グループとキャパシティプロバイダーを作成することをお勧めします。タスクを実行するか、サービスを作成するときは、Auto Scaling グループ内の最小インスタンスタイプでタスクを実行できるキャパシティプロバイダーのみをキャパシティプロバイダー戦略に追加します。他のパラメータでは、配置制約を使用できます
+ タスクグループごとに、Amazon ECS は未配置タスクの実行に必要なインスタンス数を計算します。この計算には、`binpack` 戦略が用いられます。この戦略では、タスクの vCPU、メモリ、Elastic Network Interface (ENI)、ポートや GPU の要件を考慮します。また、Amazon EC2 インスタンスのリソースの可用性も考慮されます。最大インスタンスタイプの値は、計算された最大インスタンス数として扱われます。最小のインスタンスタイプの値は、保護として使用されます。最小インスタンスタイプでタスクの少なくとも 1 つのインスタンスを実行できない場合、計算ではタスクが互換性がないと見なされます。その結果、タスクはスケールアウト計算から除外されます。すべてのタスクに最小のインスタンスタイプとの互換性がないときは、クラスター 自動スケーリングは停止し、`CapacityProviderReservation` 値は `targetCapacity` のままになります。
+ Amazon ECS は、次のいずれかに該当する場合、`minimumScalingStepSize` に関連した CloudWatch に `CapacityProviderReservation` メトリクスをパブリッシュします。
  + 計算された最大インスタンス数が最小スケーリングステップサイズを下回っています。
  + `maximumScalingStepSize` か、計算された最大インスタンス数のどちらか低い方の値。
+ CloudWatch アラームは、キャパシティプロバイダーの `CapacityProviderReservation` メトリクスを使用します。`CapacityProviderReservation` メトリクスが `targetCapacity` 値より大きい場合、アラームでは、Auto Scaling グループの `DesiredCapacity` も増加します。`targetCapacity` 値は、クラスターの自動スケーリングがアクティブ化されているフェーズ中に CloudWatch アラームに送信されるキャパシティプロバイダー設定です。

  デフォルトの `targetCapacity` は 100 % です。
+ Auto Scaling グループは追加の EC2 インスタンスを起動します。オーバープロビジョニングを防ぐため、Auto Scaling では、最近起動された EC2 インスタンスのキャパシティが新たなインスタンスを起動する前に安定させています。自動スケーリングは、既存のすべてのインスタンスが `instanceWarmupPeriod` (現在はインスタンスの起動時間を減じたもの) を経過したかどうかを確認します。`instanceWarmupPeriod` 内にあるインスタンスのスケールアウトはブロックされます。

  新しく起動されたインスタンスがウォームアップに達するまでのデフォルト秒数は 300 です。

詳細については、「[Amazon ECS のクラスター自動スケーリングに関する詳細な説明](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)」を参照してください。

### スケールアウトの考慮事項
<a name="scale-out-considerations"></a>

 スケールアウトのプロセスでは、次の点を考慮してください。
+ 配置制約は複数ありますが、`distinctInstance` タスク配置の制約事項のみを使用することをお勧めします。サンプリングされたインスタンスと互換性がない配置制約を使用しているため、これにより、スケールアウトプロセスが停止するのを防ぐことができます。
+ マネージドスケーリングは、Auto Scaling グループが同じインスタンスタイプまたは類似のインスタンスタイプを使用している場合に最適です。
+ スケールアウトプロセスが必要で現在実行中のコンテナインスタンスがない場合は、Amazon ECS は常に 2 つのインスタンスにスケールアウトしてから追加のスケールアウト/インプロセスを実行します。追加のスケールアウトは、インスタンスのウォームアップ期間を待ちます。スケールインプロセスの場合、Amazon ECS はスケールアウトプロセスの後 15 分待ってから、常にスケールインプロセスを開始します。
+ 2 番目のスケールアウトのステップは `instanceWarmupPeriod` が期限切れになるまで待つ必要があるため、全体的なスケール制限に影響する可能性があります。この時間を短縮する必要がある場合は、`instanceWarmupPeriod` が EC2 インスタンスが Amazon ECS エージェントを起動して開始するのに十分な大きさであることを確認してください (オーバープロビジョニングを防げます)。
+ クラスターの自動スケーリングは、キャパシティプロバイダーの Auto Scaling グループ内の起動設定、起動テンプレート、複数のインスタンスタイプをサポートします。複数のインスタンスタイプを使用せずに、属性ベースのインスタンスタイプの選択も使用できます。
+ オンデマンドインスタンスと複数のインスタンスタイプ、またはスポットインスタンスを持つ Auto Scaling グループを使用する場合は、大きいインスタンスタイプを優先順位リストで上位に配置し、ウェイトを指定しないでください。現時点では、ウェイトの指定はサポートされていません。詳細については、*AWS Auto Scalingユーザーガイド*の「[複数のインスタンスタイプと Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html)」を参照してください。
+ Amazon ECS は、計算された最大インスタンス数が最小スケーリングステップサイズより小さい場合は `minimumScalingStepSize` を、あるいは `maximumScalingStepSize` または計算された最大インスタンスカウント値のいずれか小さい方を起動します。
+ Amazon ECS サービスまたは `run-task` がタスクを起動し、キャパシティープロバイダーのコンテナインスタンスにタスクを開始するために十分なリソースがない場合、Amazon ECS は、各クラスターでこのステータスのタスク数を制限し、タスクがこの制限を超えることを防ぎます。詳細については、「[Amazon ECS の Service Quotas](service-quotas.md)」を参照してください。

## マネージドスケールイン動作
<a name="managed-scaling-scalein"></a>

Amazon ECS は、クラスター内の各キャパシティプロバイダーのコンテナインスタンスをモニタリングします。コンテナインスタンスがタスクを実行していない場合、コンテナインスタンスは空であるとみなされ、Amazon ECS はスケールインプロセスを開始します。

CloudWatch スケールインアラームは、Auto Scaling グループのスケールインプロセスが開始する前に 15 データポイント (15 分) を必要とします。スケールインプロセスがスタートされた後から Amazon ECS が登録されたコンテナインスタンス数を減らす必要があるまで、Auto Scaling グループは `DesireCapacity` 値を 1 つのインスタンスより大きく、かつ毎分 50% 未満に設定します。

Amazon ECS がスケールアウトをリクエストしたときに (`CapacityProviderReservation` が 100 より大きいとき) スケールインプロセスが進行中の場合、スケールインプロセスは停止して、必要に応じて最初から開始されます。

次では、スケールイン動作について詳しく説明します。

1. Amazon ECS は、空のコンテナインスタンスの数を計算します。デーモンタスクが実行されている場合でも、コンテナインスタンスは空であるとみなされます。

1. Amazon ECS では、`CapacityProviderReservation` 値を 0 ～ 100 の数値に設定します。この数値は、Auto Scaling グループが必要とする規模と実際の規模との比率をパーセンテージで表す次の式を使用します。その後、Amazon ECS は CloudWatch にメトリクスをパブリッシュします。メトリクスの算出方法の詳細については、「[Amazon ECS クラスター自動スケーリングのDeep Dive](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)」を参照してください。

   ```
   CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
   ```

1. `CapacityProviderReservation` メトリクスは CloudWatch アラームを生成します。このアラームは Auto Scaling グループの `DesiredCapacity` 値を更新します。すると、以下のいずれかのアクションが発生します。
   + キャパシティプロバイダーによるマネージド終了を使用しない場合、Auto Scaling グループは、Auto Scaling グループ終了ポリシーを使用して EC2 インスタンスを選択し、EC2 インスタンス数が `DesiredCapacity` に達するまでインスタンスを終了します。その後、コンテナインスタンスがクラスターから登録解除されます。
   + すべてのコンテナインスタンスがマネージド型の終了保護を使用している場合、Amazon ECS は空のコンテナインスタンスのスケールイン保護を削除します。Auto Scaling グループは EC2 インスタンスを終了できるようになります。その後、コンテナインスタンスがクラスターから登録解除されます。

# Amazon ECS が終了するインスタンスの制御
<a name="managed-termination-protection"></a>

**重要**  
クラスター自動スケーリングのマネージドターミネーション保護機能を使用するには、Auto Scaling グループで*自動スケーリングインスタンス*のスケールイン保護を有効にする必要があります。

マネージド終了保護を使用すると、クラスターの自動スケーリングで、どのインスタンスを終了するかを制御できます。マネージド終了保護を使用した場合、Amazon ECS は、実行中の Amazon ECS タスクがない EC2 インスタンスのみを終了します。`DAEMON` スケジューリング戦略を使用するサービスによって実行されるタスクは無視され、インスタンスがこれらのタスクを実行している場合でも、クラスター自動スケーリングによってインスタンスを終了できます。これは、クラスター内のすべてのインスタンスがこれらのタスクを実行しているためです。

Amazon ECS は最初に Auto Scaling グループの EC2 インスタンスに対するインスタンススケールイン保護オプションを有効にします。次に、Amazon ECS がインスタンスにタスクを配置します。デーモン以外のすべてのタスクがインスタンスで停止すると、Amazon ECS はスケールインプロセスを開始し、EC2 インスタンスのスケールイン保護をオフにします。Auto Scaling グループはインスタンスを終了できます。

自動スケーリングインスタンスのスケールイン保護は、終了できる EC2 インスタンスを制御します。スケールイン機能がオンになっているインスタンスは、スケールインプロセス中に終了できません。自動スケーリングのインスタンススケールイン保護についての詳細は、「Amazon EC2 Auto Scaling ユーザーガイド」の「[インスタンススケールイン保護を使用する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html)」を参照してください。

キャパシティに余裕を持たせるように `targetCapacity` の割合を設定できます。こうすると、Auto Scaling グループが起動するインスタンスが増えないため、以降のタスクがより速く起動します。Amazon ECS では、ターゲットキャパシティー値を使用して、サービスによって作成される CloudWatch メトリクスを管理します。Amazon ECS は CloudWatch メトリクスを管理します。Auto Scaling グループが定常状態として扱われるため、スケーリングアクションが必要なくなります。値は 0-100% の範囲で指定できます。例えば、Amazon ECS タスクで使用されるキャパシティーに加えて 10% の空き容量を維持するように Amazon ECS を設定するには、ターゲットキャパシティー値を 90% に設定します。キャパシティプロバイダーで `targetCapacity` 値を設定する際には、次の点を考慮します。
+ 100% 未満の `targetCapacity` 値は、クラスター内に必要な空き容量 (Amazon EC2 インスタンス) を表します。空き容量とは、実行中のタスクがないことを意味します。
+ アベイラビリティーゾーンなどの配置制約は、追加の `binpack` がなければ、Amazon ECS が最終的にインスタンスごとに 1 つのタスクを実行するように強制しますが、これは望ましい動作ではない可能性があります。

マネージド終了保護を使用するには、Auto Scaling グループで 自動スケーリングインスタンスのスケールイン保護を有効にする必要があります。スケールイン保護を有効にしていない場合、マネージド終了保護を有効にすると、望ましくない動作が発生する可能性があります。例えば、インスタンスのドレイン状態のままになっている場合を考えてみます。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[インスタンスのスケールイン保護の使用](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html)」を参照してください。

キャパシティープロバイダーで終了保護を使用するときは、キャパシティープロバイダーに関連付けられた Auto Scaling グループで、インスタンスのデタッチなどの手動アクションを実行しないでください。手動操作を行うと、キャパシティープロバイダーのスケールイン操作が中断される可能性があります。Auto Scaling グループからインスタンスをデタッチする場合は、Amazon ECS クラスターからも[デタッチしたインスタンスを登録解除する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deregister_container_instance.html)必要があります。

# Amazon ECS キャパシティープロバイダーのマネージド終了保護の更新
<a name="update-managed-termination-protection"></a>

マネージド終了保護を使用する場合は、既存のキャパシティープロバイダーの設定を更新する必要があります。

## コンソール
<a name="update-managed-termination-protection-console"></a>

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. **[Clusters]** (クラスター) ページで、クラスターを選択します。

1. クラスターのページで、**[インフラストラクチャ]** タブを選択します。

1. キャパシティプロバイダーを選択します。

1. **[更新]** を選択して、キャパシティープロバイダーの設定を変更します。

1. **[Auto Scaling グループ設定]**で、**[マネージド終了保護]**を切り替えて機能を有効または無効にします。

1. **[更新]** を選択します。

## AWS CLI
<a name="update-managed-termination-protection-cli"></a>

キャパシティープロバイダーのマネージド終了保護設定は、`update-capacity-provider` コマンドを使用して更新できます。

マネージド終了保護を有効にするには:

```
aws ecs update-capacity-provider \
  --name CapacityProviderName \
  --auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=ENABLED"
```

マネージド終了保護を無効にするには:

```
aws ecs update-capacity-provider \
  --name CapacityProviderName \
  --auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=DISABLED"
```

**注記**  
クラスター全体で変更が有効になるまでに数分かかる場合があります。マネージド終了保護を有効にすると、すでにタスクを実行しているインスタンスはスケールインイベントから保護されます。マネージド終了保護を無効にすると、次の ECS キャパシティープロバイダー管理サイクル中に保護フラグがインスタンスから削除されます。

## タスクを実行するコンソール
<a name="update-managed-termination-protection-console"></a>

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. **[Clusters]** (クラスター) ページで、クラスターを選択します。

1. クラスターのページで、**[タスク]** タブを選択します。

1. タスクを選択します。

1. **[設定]** で、**[マネージド終了保護]** を切り替えて機能を有効または無効にします。

1. **[タスクのスケールイン保護を設定する]** を選択します。

   **[タスクのスケールイン保護を設定する]** ダイアログボックスが表示されます。

   1. **[タスクのスケールイン保護]** で、**[オンにする]** に切り替えます。

   1. **[分単位で期限切れになる]** に設定する場合、タスクのスケールイン保護が終了するまでの分数を入力します。

   1. **[Update]** (更新) を選択する

# Amazon ECS クラスターの自動スケーリングを有効にする
<a name="turn-on-cluster-auto-scaling"></a>

クラスターの自動スケーリングを有効にして、Amazon ECS がクラスターに登録された Amazon EC2 インスタンスのスケーリングを管理するようにします。

コンソールを使用してクラスターの自動スケーリングを有効にする場合は、「[Amazon ECS のキャパシティープロバイダーを作成する](create-capacity-provider-console-v2.md)」を参照してください。

開始する前に、Auto Scaling グループとキャパシティープロバイダーを作成します。詳細については、「[EC2 ワークロード用の Amazon ECS キャパシティプロバイダー](asg-capacity-providers.md)」を参照してください。

クラスターの自動スケーリングを有効にする場合は、キャパシティープロバイダーをクラスターに関連付けてから、クラスターの自動スケーリングを有効にします。

1. `put-cluster-capacity-providers` コマンドを使用して、1 つ以上のキャパシティープロバイダーをクラスターに関連付けます。

   AWS Fargate キャパシティプロバイダーを追加するには、リクエストに `FARGATE` および `FARGATE_SPOT` キャパシティプロバイダーを入れます。詳細については、AWS CLI コマンドリファレンスの「`[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)`」を参照してください。

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers CapacityProviderName FARGATE FARGATE_SPOT \
     --default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
   ```

   EC2 の Auto Scaling グループを追加するには、リクエストに Auto Scaling グループ名を含めます。詳細については、AWS CLI コマンドリファレンスの「`[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)`」を参照してください。

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers CapacityProviderName \
     --default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
   ```

1. `describe-clusters` コマンドを使用して、関連付けが成功したことを確認します。詳細については、AWS CLI コマンドリファレンスの「`[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)`」を参照してください。

   ```
   aws ecs describe-clusters \
     --cluster ClusterName \
     --include ATTACHMENTS
   ```

1. キャパシティープロバイダーのマネージド自動スケーリングを有効にするには、`update-capacity-provider` コマンドを使用します。詳細については、AWS CLI コマンドリファレンスの「`[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)`」を参照してください。

   ```
   aws ecs update-capacity-provider \
     --name CapacityProviderName \
     --auto-scaling-group-provider "managedScaling={status=ENABLED}"
   ```

# Amazon ECS クラスターの自動スケーリングを無効にする
<a name="turn-off-cluster-auto-scaling"></a>

クラスターに登録されている EC2 インスタンスをよりきめ細かく制御する必要がある場合は、クラスターの自動スケーリングを無効にします。

クラスターの自動スケーリングを無効にするには、キャパシティープロバイダーとクラスターから有効にしたマネージドスケーリングの関連付けを解除するか、キャパシティープロバイダーを更新してマネージドスケーリングを無効にします。

## キャパシティープロバイダーの関連付けを解除する
<a name="disassociate-capacity-provider"></a>

キャパシティープロバイダーとクラスターとの関連付けを解除するには、次の手順を実行します。

1. `put-cluster-capacity-providers` コマンドを使用して、Auto Scaling グループのキャパシティープロバイダーとクラスターとの関連付けを解除します。クラスターは、AWS Fargate キャパシティープロバイダーとの関連付けを保持できます。詳細については、AWS CLI コマンドリファレンスの「`[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)`」を参照してください。

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers FARGATE FARGATE_SPOT \
     --default-capacity-provider-strategy '[]'
   ```

   `put-cluster-capacity-providers` コマンドを使用して、Auto Scaling グループのキャパシティープロバイダーとクラスターとの関連付けを解除します。詳細については、AWS CLI コマンドリファレンスの「`[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)`」を参照してください。

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers [] \
     --default-capacity-provider-strategy '[]'
   ```

1. `describe-clusters` コマンドを使用して、関連付けの解除が成功したことを確認します。詳細については、AWS CLI コマンドリファレンスの「`[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)`」を参照してください。

   ```
   aws ecs describe-clusters \
     --cluster ClusterName \
     --include ATTACHMENTS
   ```

## キャパシティープロバイダーのマネージドスケーリングを無効にする
<a name="turn-off-managed-scaling"></a>

キャパシティープロバイダーのマネージドスケーリングを無効にするには、次のステップに従います。
+ キャパシティープロバイダーのマネージド自動スケーリングを無効にするには、`update-capacity-provider` コマンドを使用します。詳細については、AWS CLI コマンドリファレンスの「`[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)`」を参照してください。

  ```
  aws ecs update-capacity-provider \
    --name CapacityProviderName \
    --auto-scaling-group-provider "managedScaling={status=DISABLED}"
  ```

# Amazon ECS のキャパシティープロバイダーを作成する
<a name="create-capacity-provider-console-v2"></a>

クラスターの作成が完了したら、EC2 の新しいキャパシティプロバイダー (Auto Scaling グループ) を作成できます。キャパシティープロバイダーは、アプリケーションのインフラストラクチャの管理とスケーリングに役立ちます。

キャパシティプロバイダーを作成する前に、Auto Scaling グループを作成する必要があります。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)」を参照してください。

**クラスターのキャパシティプロバイダーを作成するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、クラスターを選択します。

1. **[Cluster : *name*]** (クラスター : 名) ページで、**[Infrastructure]** (インフラストラクチャ) を選択し、**[Create]** (作成) を選択します。

1. **[Create capacity providers]** (キャパシティプロバイダーの作成) ページで、次のオプションを設定します。

   1. **[Basic details]** (基本的な詳細) の下の **[Capacity provider name]** (キャパシティプロバイダー名) に、一意のキャパシティプロバイダー名を入力します。

   1. **[Auto Scaling group]** (Auto Scaling グループ) の **[Use an existing Auto Scaling group]** (既存の Auto Scaling グループを使用する) で、Auto Scaling グループを選択します。

   1. (オプション) スケーリングポリシーを設定するには、**[Scaling policies]** (スケーリングポリシー) で次のオプションを設定します。
      + スケールインおよびスケールアウトアクションを Amazon ECS に管理させるには、**[Turn on managed scaling]** (マネージドスケーリングをオンにする) を選択します。
      + Amazon ECS タスクが実行されている EC2 インスタンスが終了しないようにするには、**[Turn on scaling protection]** (スケーリング保護を有効にする) を選択します。
      + **[Set target capacity]** (ターゲットキャパシティの設定) に、Amazon ECS マネージド対象ターゲット追跡スケーリングポリシーで使用される CloudWatch メトリクスのターゲット値を入力します。

1. **[作成]** を選択します。

# Amazon ECS キャパシティープロバイダーを更新する
<a name="update-capacity-provider-console-v2"></a>

Auto Scaling グループをキャパシティプロバイダーとして使用する場合、グループのスケーリングポリシーを変更できます。

**クラスターのキャパシティプロバイダーを更新するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、クラスターを選択します。

1. **[Cluster : *name*]** (クラスター : 名) ページで、**[Infrastructure]** (インフラストラクチャ) を選択し、**[Update]** (更新) を選択します。

1. **[Create capacity providers]** (キャパシティプロバイダーの作成) ページで、次のオプションを設定します。

   1. **[Auto Scaling グループ]** の **[スケーリングポリシー]** で、以下のオプションを設定します。
     + スケールインおよびスケールアウトアクションを Amazon ECS に管理させるには、**[Turn on managed scaling]** (マネージドスケーリングをオンにする) を選択します。
     + Amazon ECS タスクが実行されている EC2 インスタンスが終了しないようにするには、**[スケーリング保護をオンにする]** を選択します。
     + **[Set target capacity]** (ターゲットキャパシティの設定) に、Amazon ECS マネージド対象ターゲット追跡スケーリングポリシーで使用される CloudWatch メトリクスのターゲット値を入力します。

1. **[更新]** を選択します。

# Amazon ECS キャパシティープロバイダーを削除する
<a name="delete-capacity-provider-console-v2"></a>

Auto Scaling グループキャパシティープロバイダーは、使い終わったら削除できます。グループが削除されると、Auto Scaling グループのキャパシティープロバイダーは `INACTIVE` 状態に移行します。`INACTIVE` ステータスのキャパシティープロバイダーは、一定期間アカウント内で検出可能になる場合があります。ただし、この動作は今後変更される予定であり、`INACTIVE` のキャパシティープロバイダーを永続的に使用するのは避けてください。Auto Scaling グループキャパシティプロバイダーを削除する前に、すべてのサービスのキャパシティプロバイダー戦略からキャパシティプロバイダーを削除する必要があります。サービスのキャパシティプロバイダー戦略からキャパシティプロバイダーを削除するには、`UpdateService` API または Amazon ECS コンソールのサービス更新ワークフローを使用できます。**[新しいデプロイの強制]** オプションを使用すると、キャパシティプロバイダーが提供する Amazon EC2 インスタンスキャパシティを使用している任意のタスクを、残りのキャパシティプロバイダーのキャパシティを使用するように移行できます。

**クラスターのキャパシティプロバイダーを削除するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、クラスターを選択します。

1. **[Cluster : *name*]** (クラスター : 名) ページで、**[Infrastructure]** (インフラストラクチャ) を選択し、Auto Scaling グループを選択して、**[Delete]** (削除) を選択します。

1. 確認ボックスに、「**delete *Auto Scaling グループの名前***」と入力します。

1. **[削除]** を選択します。

# EC2 インスタンスで実行されている Amazon ECS ワークロードを安全に停止する
<a name="managed-instance-draining"></a>

マネージドインスタンスドレイニングを使用すると、Amazon EC2 インスタンスの正常な終了が容易になります。この結果、ワークロードを安全に停止し、終了しないインスタンスに再スケジュールできます。インフラストラクチャのメンテナンスと更新は、ワークロードの中断を心配することなく実行できます。マネージドインスタンスドレイニングを使用することで、Amazon EC2 インスタンスの置換を必要とするインフラストラクチャ管理ワークフローを簡素化しつつ、アプリケーションの耐障害性と可用性を確保できます。

Amazon ECS マネージドインスタンスドレイニングは、Auto Scaling グループのインスタンス置換と連動します。インスタンスの更新とインスタンスの最大有効期間に基づいて、お客様は最新の OS およびキャパシティに関するセキュリティ要件に常に準拠できます。

マネージドインスタンスドレイニングは、Amazon ECS キャパシティープロバイダーでのみ使用できます。Amazon ECS コンソール、AWS CLI、または SDK を使用して Auto Scaling グループのキャパシティープロバイダーを作成または更新するときに、マネージドインスタンスドレイニングを有効にできます。

以下のイベントは Amazon ECS マネージドインスタンスドレイニングの対象となります。
+ [Auto Scaling グループのインスタンス更新](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html) - インスタンス更新を使用すると、バッチによる手動ではなく、Auto Scaling グループ内の Amazon EC2 インスタンスのローリング置換を実行できます。これは、多数のインスタンスを置換する必要がある場合に便利です。インスタンス更新は、Amazon EC2 コンソールまたは `StartInstanceRefresh` API により開始されます。マネージドターミネーション保護を使用している場合は、`StartInstanceRefresh` を呼び出す際に必ず `Replace` を選択してスケールイン保護をしてください。
+ [インスタンスの最大有効期間](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-max-instance-lifetime.html) - Auto Scaling グループインスタンスの置換に至るまでの最大有効期間を定義できます。これは、内部のセキュリティポリシーやコンプライアンスに基づいて置換インスタンスをスケジュールするのに役立ちます。
+ Auto Scaling グループのスケールイン - スケーリングポリシーとスケジュールされたスケーリングアクションに基づいて、Auto Scaling グループはインスタンスの自動スケーリングをサポートします。Amazon ECS キャパシティープロバイダーとして Auto Scaling グループを使用することで、タスクが実行されていないときに Auto Scaling グループのインスタンスをスケールインすることができます。
+ [Auto Scaling グループのヘルスチェック](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html) - Auto Scaling グループは、異常のあるインスタンスの終了を管理するための多くのヘルスチェックをサポートしています。
+ [CloudFormation スタックの更新](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html) - CloudFormation スタックに `UpdatePolicy` 属性を追加することで、グループが変更されたときにローリング更新を実行できます。
+ [スポットキャパシティーの再調整](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) - Auto Scaling グループは、Amazon EC2 のキャパシティー再調整通知に基づいて、中断のリスクが高いスポットインスタンスを事前対応的に置換しようとします。Auto Scaling グループは、置換インスタンスが起動して正常になると、古いインスタンスを終了します。Amazon ECS マネージドインスタンスドレイニングでは、非スポットインスタンスをドレインするのと同じ方法でスポットインスタンスをドレインします。
+ [スポット中断](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html) - スポットインスタンスは 2 分間の通知の後に終了します。Amazon ECS マネージドインスタンスドレイニングでは、それに応じてインスタンスがドレイニング状態になります。

**マネージドインスタンスドレイニングがある Amazon EC2 Auto Scaling のライフサイクルフック**  
Auto Scaling グループのライフサイクルフックを使用すると、お客様はインスタンスライフサイクルの特定のイベントによってトリガーされるソリューションを作成し、その特定のイベントが発生したときにカスタムアクションを実行できます。Auto Scaling グループでは、最大 50 個のフックを使用できます。複数の終了フックが存在する場合があり、それらは同時に実行されるため、Auto Scaling グループはすべてのフックが終了するのを待ってからインスタンスを終了します。

Amazon ECS マネージド型のフック終了に加えて、独自のライフサイクル終了フックを設定することもできます。ライフサイクルフックには `default action` があります。Amazon ECS マネージドフックなどの他のフックがカスタムフックによるエラーの影響を受けないようにするために、`continue` をデフォルトとして設定することをお勧めします。

Auto Scaling グループの終了ライフサイクルフックを既に設定していて、Amazon ECS マネージドインスタンスドレイニングも有効にしている場合、両方のライフサイクルフックが実行されます。ただし、相対的なタイミングは保証されません。ライフサイクルフックには、タイムアウトが終了したときに実行するアクションを指定する `default action` 設定があります。障害が発生した場合は、`continue` をカスタムフックのデフォルト結果として使用することをお勧めします。このようにすることで、他のフック、特に Amazon ECS マネージドフックは、カスタムライフサイクルフックのエラーの影響を受けなくなります。`abandon` による別の結果では、ほかのすべてのフックがスキップされるので、避けるべきです。Auto Scaling グループのライフサイクルフックの詳細については、「*Amazon EC2* Auto Scaling ユーザーガイド」の「[Amazon EC2 Auto Scaling のライフサイクルフック](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)」を参照してください。

**タスクとマネージドインスタンスドレイニング**  
Amazon ECS マネージドインスタンスドレイニングでは、コンテナインスタンスにある既存のドレイニング機能を使用します。[コンテナインスタンスドレイニング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-draining.html)機能は、Amazon ECS サービスに属するレプリカタスクの置換と停止を実行します。スタンドアロンタスク (`RunTask` によって呼び出されたタスクなど) は、`PENDING` または `RUNNING` の状態にある場合には影響を受けません。そのようなタスクは、完了するまで待つか、手動で停止する必要があります。コンテナインスタンスは、すべてのタスクが停止されるか、48 時間が経過するまで `DRAINING` 状態のままになります。デーモンタスクは、すべてのレプリカタスクが停止した後に、最後に停止します。

**マネージドインスタンスドレイニングとマネージドターミネーション保護**  
マネージドインスタンスドレイニングは、マネージド終了が無効になっている場合でも機能します。マネージド終了保護の詳細については、「[Amazon ECS が終了するインスタンスの制御](managed-termination-protection.md)」を参照してください。

次の表は、マネージドターミネーションとマネージドドドレイニングのさまざまな組み合わせの動作をまとめたものです。


|  マネージドターミネーション  |  マネージドドドレイニング  |  結果  | 
| --- | --- | --- | 
|  有効  | 有効 | Amazon ECS は、タスクを実行している Amazon EC2 インスタンスがスケールインイベントによって終了するのを防ぎます。終了保護が設定されていないインスタンス、スポット中断を受けたインスタンス、インスタンス更新によって強制されたインスタンスなど、終了中のインスタンスがすべて正常にドレインされます。 | 
|  Disabled  | 有効 | Amazon ECS は、タスクを実行している Amazon EC2 インスタンスがスケールインされないように保護することはしません。ただし、終了されるインスタンスはすべて正常にドレインされます。 | 
|  有効  | Disabled | Amazon ECS は、タスクを実行している Amazon EC2 インスタンスがスケールインイベントによって終了するのを防ぎます。ただし、スポット中断や強制的なインスタンス更新によって、またはタスクがまったく実行されていない場合に、インスタンスは終了する可能性があります。Amazon ECS はこれらのインスタンスに対して正常なドレインを実行せず、停止後に置換サービスタスクを起動します。 | 
|  Disabled  | Disabled | Amazon EC2 インスタンスは、Amazon ECS タスクを実行している場合でも、いつでもスケールインまたは終了できます。Amazon ECS は、インスタンスが停止した後に置換サービスタスクを起動します。 | 

**マネージドインスタンスドレイニングとスポットインスタンスドレイニング**  
スポットインスタンスドレイニングでは、Amazon ECS エージェントに環境変数 `ECS_ENABLE_SPOT_INSTANCE_DRAINING` を設定できます。これにより、Amazon ECS は 2 分間のスポット中断に応答して、インスタンスをドレイン中ステータスに移行できます。Amazon ECS マネージドインスタンスドレイニングを使用すると、スポット中断だけでなく、さまざまな理由で終了中の Amazon EC2 インスタンスを正常にシャットダウンできます。例えば、Amazon EC2 Auto Scaling のキャパシティー再調整を使用して、中断のリスクが高まっているスポットインスタンスを事前対応的に置換できます。そして、マネージドインスタンスドレイニングにより、置換対象のスポットインスタンスの正常シャットダウンが実行されます。マネージドインスタンスドレイニングを使用する場合、スポットインスタンスドレイニングを個別に有効にする必要がないため、Auto Scaling グループのユーザーデータの `ECS_ENABLE_SPOT_INSTANCE_DRAINING` が冗長になります。スポットインスタンスドレイニングの詳細については、「[スポットインスタンス](create-capacity.md#container-instance-spot)」を参照してください。

## マネージドインスタンスドレイニングと EventBridge の連携
<a name="managed-instance-draining-eventbridge"></a>

Amazon ECS マネージドインスタンスドレイニングイベントは Amazon EventBridge に発行され、Amazon ECS はマネージドインスタンスドレイニングをサポートするために、アカウントのデフォルトバスに EventBridge マネージドルールを作成します。これらのイベントを Lambda、Amazon SNS、および Amazon SQS などのほかの AWS サービスにフィルタリングして、モニタリングおよびトラブルシューティングできます。
+ Amazon EC2 Auto Scaling は、ライフサイクルフックを呼び出すときに EventBridge にイベントを送信します。
+ スポット中断通知は EventBridge に発行されます。
+ Amazon ECS は、エラーメッセージを生成します。このエラーメッセージは、Amazon ECS コンソールおよび API を介して取得することができます。
+ EventBridge には、一時的な障害を軽減するための再試行メカニズムが組み込まれています。

# インスタンスを安全にシャットダウンするように Amazon ECS キャパシティープロバイダーを設定する
<a name="enable-managed-instance-draining"></a>

Amazon ECS コンソールと AWS CLI を使用して Auto Scaling グループのキャパシティープロバイダーを作成または更新するときに、マネージドインスタンスドレイニングを有効にできます。

**注記**  
キャパシティープロバイダーを作成すると、マネージドインスタンスドレイニングはデフォルトで有効になります。

以下に、AWS CLI を使用してマネージドインスタンスドレイニングを有効にしたキャパシティプロバイダーを作成し、クラスターの既存のキャパシティプロバイダーのマネージドインスタンスドレイニングを有効にする例を示します。

**マネージドインスタンスドレイニングを有効にしたキャパシティプロバイダーを作成する**  
マネージドインスタンスドレイニングを有効にしたキャパシティプロバイダーを作成するには、`create-capacity-provider` コマンドを使用します。`managedDraining` パラメータを `ENABLED` に設定します。

```
aws ecs create-capacity-provider \
--name capacity-provider \
--auto-scaling-group-provider '{
  "autoScalingGroupArn": "asg-arn",
  "managedScaling": {
    "status": "ENABLED",
    "targetCapacity": 100,
    "minimumScalingStepSize": 1,
    "maximumScalingStepSize": 1
  },
  "managedDraining": "ENABLED",
  "managedTerminationProtection": "ENABLED",
}'
```

レスポンス:

```
{
    "capacityProvider": {
        "capacityProviderArn": "capacity-provider-arn",
        "name": "capacity-provider",
        "status": "ACTIVE",
        "autoScalingGroupProvider": {
            "autoScalingGroupArn": "asg-arn",
            "managedScaling": {
                "status": "ENABLED",
                "targetCapacity": 100,
                "minimumScalingStepSize": 1,
                "maximumScalingStepSize": 1
            },
            "managedTerminationProtection": "ENABLED"
            "managedDraining": "ENABLED"
        }
    }
}
```

**クラスターの既存のキャパシティプロバイダーに対してマネージドインスタンスドレイニングを有効にします。**  
`update-capacity-provider` コマンドを使用して、クラスターの既存のキャパシティプロバイダーに対してマネージドインスタンスドレイニングを有効にします。現在 `managedDraining` が `DISABLED` で、`updateStatus` が `UPDATE_IN_PROGRESS` になっているのがわかります。

```
aws ecs update-capacity-provider \
--name cp-draining \
--auto-scaling-group-provider '{
  "managedDraining": "ENABLED"
}
```

レスポンス:

```
{
    "capacityProvider": {
        "capacityProviderArn": "cp-draining-arn",
        "name": "cp-draining",
        "status": "ACTIVE",
        "autoScalingGroupProvider": {
            "autoScalingGroupArn": "asg-draining-arn",
            "managedScaling": {
                "status": "ENABLED",
                "targetCapacity": 100,
                "minimumScalingStepSize": 1,
                "maximumScalingStepSize": 1,
                "instanceWarmupPeriod": 300
            },
            "managedTerminationProtection": "DISABLED",
            "managedDraining": "DISABLED" // before update
        },
        "updateStatus": "UPDATE_IN_PROGRESS", // in progress and need describe again to find out the result
        "tags": [
        ]
    }
}
```



`describe-clusters` コマンドを使用して `ATTACHMENTS` を含めます。マネージドインスタンスドレイニングアタッチメントの `status` は `PRECREATED` で、全体の `attachmentsStatus` は `UPDATING` です。

```
aws ecs describe-clusters --clusters cluster-name --include ATTACHMENTS
```

レスポンス:

```
{
    "clusters": [
        {
            ...

            "capacityProviders": [
                "cp-draining"
            ],
            "defaultCapacityProviderStrategy": [],
            "attachments": [
                # new precreated managed draining attachment
                {
                    "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
                    "type": "managed_draining",
                    "status": "PRECREATED",
                    "details": [
                        {
                            "name": "capacityProviderName",
                            "value": "cp-draining"
                        },
                        {
                            "name": "autoScalingLifecycleHookName",
                            "value": "ecs-managed-draining-termination-hook"
                        }
                    ]
                },

                ...

            ],
            "attachmentsStatus": "UPDATING"
        }
    ],
    "failures": []
}
```

更新が終了したら、`describe-capacity-providers` を使用します。すると、`managedDraining` が `ENABLED` になったのがわかります。

```
aws ecs describe-capacity-providers --capacity-providers cp-draining
```

レスポンス:

```
{
    "capacityProviders": [
        {
            "capacityProviderArn": "cp-draining-arn",
            "name": "cp-draining",
            "status": "ACTIVE",
            "autoScalingGroupProvider": {
                "autoScalingGroupArn": "asg-draning-arn",
                "managedScaling": {
                    "status": "ENABLED",
                    "targetCapacity": 100,
                    "minimumScalingStepSize": 1,
                    "maximumScalingStepSize": 1,
                    "instanceWarmupPeriod": 300
                },
                "managedTerminationProtection": "DISABLED",
                "managedDraining": "ENABLED" // successfully update
            },
            "updateStatus": "UPDATE_COMPLETE",
            "tags": []
        }
    ]
}
```

## Amazon ECS マネージドインスタンスドレイニングのトラブルシューティング
<a name="managed-instance-troubleshooting"></a>

マネージドインスタンスドレイニングに関する問題のトラブルシューティングが必要になる場合があります。以下は、使用中に発生する可能性のある問題と解決方法の例です。

**自動スケーリングの使用時に、最大インスタンス有効期間を超えてもインスタンスが終了しません。**  
Auto Scaling グループの使用中に最大インスタンス有効期間に到達および超過した後もインスタンスが終了しない場合、スケールインから保護されていることが原因である可能性があります。マネージド終了を無効にし、マネージドドレイニングがインスタンスのリサイクルを処理できるようにすることができます。

## Amazon ECS マネージドインスタンスのドレイニング動作
<a name="managed-instances-draining-behavior"></a>

Amazon ECS マネージドインスタンスの終了は、コストを最適化し、システムの健全性を維持しながら、ワークロードを正常に移行します。終了システムには、インスタンスの終了に関する 3 つの異なる決定パスがあり、それぞれのタイミングの特性やお客様に影響する事項が異なります。

### 終了決定パス
<a name="managed-instances-termination-paths"></a>

お客様が開始した終了  
コンテナインスタンスをすぐにサービスから削除する必要がある場合に、インスタンスの削除を直接制御できます。強制フラグを true に設定して DeregisterContainerInstance API を呼び出します。これは、ワークロードが実行中にもかかわらず即時終了が必要であることを示します。

システムによるアイドル終了  
Amazon ECS マネージドインスタンスは、タスクを実行していないアイドル状態の Amazon ECS コンテナインスタンスを終了することで、コストを継続的にモニタリングし、プロアクティブに最適化します。ECS はヒューリスティック遅延を使用して、コンテナインスタンスが終了する前に新しく起動されたタスクを取得する時間を提供します。これは、`scaleInAfter` Amazon ECS マネージドインスタンスのキャパシティープロバイダー設定パラメータを使用してカスタマイズできます。

インフラストラクチャの更新の終了  
Amazon ECS マネージドインスタンスでは、ワークロードの可用性を維持しながら、マネージドコンテナインスタンスのソフトウェアを自動的に管理および更新することで、セキュリティとコンプライアンスを確実にします。詳細については、[Amazon ECS マネージドインスタンスでのパッチ適用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html)を参照してください。

### 正常なドレイニングとワークロードの移行
<a name="managed-instances-draining-coordination"></a>

正常なドレイニングシステムは、Amazon ECS サービス管理との高度な調整を実装し、サービスマネージドタスクが、終了予定のインスタンスから適切に移行されるようにします。

**サービスタスクドレイニングの調整**  
インスタンスが DRAINING 状態に移行すると、Amazon ECS スケジューラは、既存のサービスタスクに正常なシャットダウン手順を実装しながら、インスタンスへの新しいタスクの配置を自動的に停止します。サービスタスクドレイニングには、最適な移行タイミングと成功率を確保するために、サービスデプロイ戦略、ヘルスチェック要件、ドレイニング設定の調整が含まれます。

**スタンドアロンタスク処理**  
スタンドアロンタスクは、自動サービス管理の恩恵を受けないため、さまざまな処理が必要です。システムは、スタンドアロンのタスク特性 (タスク期間の見積もり、完了確率分析、顧客への影響評価など) を評価します。正常な完了戦略により、スタンドアロンタスクは猶予期間の延長中に自然に完了できます。また、強制終了により、タスクが自然に完了していない場合、許容期間内にインフラストラクチャの更新を実行するようになります。

### 2 フェーズ完了戦略
<a name="managed-instances-two-phase-completion"></a>

終了システムは、ワークロードの継続性とインフラストラクチャ管理要件のバランスを取る、2 段階のアプローチを実行します。

**フェーズ 1: 正常な完了期間**  
このフェーズでは、システムはワークロードの継続性を優先する、正常なドレイニング戦略を実行します。サービスタスクは通常の Amazon ECS スケジューリングプロセスによって正常にドレインされます。スタンドアロンタスクは実行を継続しますが、自然に完了する可能性があります。システムはすべてのタスクが自然な完了プロセスを通じて停止状態に到達しているかどうかをモニタリングします。

**フェーズ 2: 厳格な期限の適用**  
正常な完了が、許容可能な期間内に終了目標を達成しない場合、システムは厳格な期限の適用を実行します。厳格な期限では、通常ドレイン開始日時に 7 日を加えて設定されるため、運用要件は維持されますが、正常な完了にはかなりの時間がかかります。強制には、強制登録解除手順の自動呼び出しと、完了ステータスを考慮しない残りのすべてのタスクの即時終了が含まれます。

# AWS マネジメントコンソール を使用した Amazon ECS クラスターの自動スケーリング用のリソースの作成
<a name="tutorial-cluster-auto-scaling-console"></a>

AWS マネジメントコンソール を使用してクラスターの自動スケーリング用のリソースを作成する方法について説明します。リソースに名前が必要な場合は、プレフィックス `ConsoleTutorial` を使用して、すべてのリソースに一意の名前があることを確認し、見つけやすくします。

**Topics**
+ [前提条件](#console-tutorial-prereqs)
+ [ステップ 1: Amazon ECS クラスターを作成する](#console-tutorial-cluster)
+ [ステップ 2: タスク定義を登録する](#console-tutorial-register-task-definition)
+ [ステップ 3: タスクを実行する](#console-tutorial-run-task)
+ [ステップ 4: 確認する](#console-tutorial-verify)
+ [ステップ 5：クリーンアップ](#console-tutorial-cleanup)

## 前提条件
<a name="console-tutorial-prereqs"></a>

このチュートリアルでは、以下の前提条件が完了済みであることを前提としています。
+ 「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」のステップを完了していること。
+ IAM ユーザーに [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM ポリシー例で指定されている必要なアクセス権限があること。
+ Amazon ECS コンテナインスタンス IAM ロールが作成されます。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
+ Amazon ECS サービスにリンクされた IAM ロールが作成されます。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
+ 自動スケーリングのサービスにリンクされたIAMロールを作成する 詳細については、*Amazon EC2 Auto Scaling ユーザーガイド*の「[Amazon EC2 Auto Scaling のサービスにリンクされたロール](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html)」を参照してください。
+ VPC およびセキュリティグループが使用できるように作成されていること。詳細については、「[仮想プライベートクラウドを作成する](get-set-up-for-amazon-ecs.md#create-a-vpc)」を参照してください。

## ステップ 1: Amazon ECS クラスターを作成する
<a name="console-tutorial-cluster"></a>

次の手順に従って Amazon ECS クラスターを作成します。

Amazon ECS は、CloudFormation スタックの一部としてユーザーに代わり Amazon EC2 Auto Scaling 起動テンプレートと Auto Scaling グループを作成します。

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで、[**クラスター**] を選択し、[**クラスターの作成**] を選択します。

1. **[クラスター設定]** の **[クラスター名]** に、「`ConsoleTutorial-cluster`」と入力します。

1. [**インフラストラクチャ**] で、[AWS Fargate (サーバーレス)] を選択解除し、**[Amazon EC2 インスタンス]** を選択します。次に、キャパシティプロバイダーとして動作する、Auto Scaling グループを設定します。

   1. **[自動スケーリンググループ (ASG)]** の下です。**[新しい ASG を作成]** を選択し、次に、そのグループに関する詳細を以下のように入力します。
     + **[オペレーティングシステム/アーキテクチャ]** で、**[Amazon Linux 2]** を選択します。
     + **[EC2 インスタンスタイプ]** で [**t3.nano**] を選択します。
     + **[Capacity]** (キャパシティー) には、Auto Scaling グループで起動するインスタンスの最小数と最大数を入力します。

1. (オプション) クラスタータグを管理するには、**[Tags]** (タグ) を展開し、次のいずれかのオペレーションを実行します。

   [タグの追加] [**タグの追加**] を選択して、以下を実行します。
   + [**キー**] にはキー名を入力します。
   + [**値**] にキー値を入力します。

   [タグを削除] タグのキーと値の右側にある [**削除**] を選択します。

1. **[作成]** を選択します。

## ステップ 2: タスク定義を登録する
<a name="console-tutorial-register-task-definition"></a>

クラスターでタスクを実行する前に、タスク定義を登録する必要があります。タスク定義とは、1 つにグループ化されたコンテナのリストです。次の例は、Docker Hub から取得した `amazonlinux` イメージを使用し、スリープ状態になるシンプルなタスク定義です。使用できるタスク定義パラメータの詳細については、「[Amazon ECS のタスク定義](task_definitions.md)」を参照してください。

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで、**タスクの定義** を選択します。

1. **[Create new task definition]** (新しいタスク定義の作成)、**[Create new task definition with JSON]** (JSON で新しいタスク定義を作成) の順に選択します。

1. **[JSON エディタ]** ボックスには、以下の内容を貼り付けます。

   ```
   {
       "family": "ConsoleTutorial-taskdef",
       "containerDefinitions": [
           {
               "name": "sleep",
               "image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
               "memory": 20,
               "essential": true,
               "command": [
                   "sh",
                   "-c",
                   "sleep infinity"
               ]
           }
       ],
       "requiresCompatibilities": [
           "EC2"
       ]
   }
   ```

1. **[作成]** を選択します。

## ステップ 3: タスクを実行する
<a name="console-tutorial-run-task"></a>

アカウントのタスク定義を登録したら、クラスターでタスクを実行できます。このチュートリアルでは、`ConsoleTutorial-cluster` クラスターで `ConsoleTutorial-taskdef` タスク定義のインスタンスを 5 つ実行します。

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. **[クラスター]** ページで、**[コンソールチュートリアル – クラスター]** を選択します。

1. **[タスク]** で、**[新しいタスクの実行]** を選択します

1. **[環境]** セクションの **[コンピューティングオプション]** で、**[キャパシティープロバイダー戦略]** を選択します。

1. **[デプロイメント構成]** の **[アプリケーション タイプ]** で、**[タスク]** を選択します。

1.  **[ファミリー]** ドロップダウン リストから **[ConsoleTutorial-taskdef]** を選択します。

1. **[希望するタスク]** で、「5」と入力します。

1. **[作成]** を選択します。

## ステップ 4: 確認する
<a name="console-tutorial-verify"></a>

チュートリアルのこの時点で、5 つのタスクが実行されているクラスターと、キャパシティープロバイダーを備えた Auto Scaling グループができているはずです。キャパシティープロバイダーが Amazon ECS マネージドスケーリングを有効にしています。

CloudWatch メトリクス、Auto Scaling グループ設定、最後に Amazon ECS クラスタータスク数を表示することで、すべてが正常に機能していることを確認できます。

**クラスターの CloudWatch メトリクスを表示するには**

1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。

1. 画面上部のナビゲーションバーで、 リージョンを選択します。

1. ナビゲーションペインで、**[メトリクス]** から **[すべてのメトリクス]** を選択します。

1. **[すべてのメトリクス]** ページの **[参照]** タブで、`AWS/ECS/ManagedScaling` を選択します。

1. [**CapacityProviderName, ClusterName**] を選択します。

1. `ConsoleTutorial-cluster` **[クラスター名]** に対応するチェックボックスを選択します。

1. **[グラフ化メトリクス]** タブで、**[期間]** を **[30 秒]**、**[統計]** を **[最大]** に変更します。

   グラフに表示される値は、キャパシティープロバイダーのターゲットキャパシティー値を示します。これは、設定したターゲットキャパシティーパーセントである `100` から開始する必要があります。`200` までスケールアップすると、ターゲット追跡スケーリングポリシーのアラームがトリガーされます。その後、アラームが発生し Auto Scaling グループがスケールアウトします。

次のステップに従って、Auto Scaling グループの詳細を表示し、スケールアウトアクションが発生したことを確認します。

**Auto Scaling グループがスケールアウトされたことを確認するには**

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. 画面上部のナビゲーションバーで、 リージョンを選択します。

1. ナビゲーションペインの **自動スケーリング** で、**[Auto Scaling Groups]** (Auto Scaling グループ) を選択します。

1. このチュートリアルで作成した `ConsoleTutorial-cluster` Auto Scaling グループを選択します。**[必要なキャパシティー]** の値を表示し、**[インスタンス管理]** タブでインスタンスを表示して、グループが 2 つのインスタンスにスケールアウトされていることを確認します。

次のステップを使用して Amazon ECS クラスターを表示し、Amazon EC2 インスタンスがクラスターに登録され、タスクが `RUNNING` ステータスに移行したことを確認します。

**Auto Scaling グループに含まれるインスタンスを確認する方法**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページで、`ConsoleTutorial-cluster` クラスターを選択します。

1. [**タスク**] タブで、5 つのタスクが `RUNNING` ステータスになっていることを確認します。

## ステップ 5：クリーンアップ
<a name="console-tutorial-cleanup"></a>

このチュートリアルが終了したら、使用していないリソースに対する料金が発生しないように、チュートリアルに関連付けられたリソースをクリーンアップします。キャパシティープロバイダーとタスク定義の削除はサポートされていませんが、これらのリソースに関連するコストは発生しません。

**チュートリアルリソースをクリーンアップするには**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページで、**[コンソールチュートリアル – クラスター]** を選択します。

1. **[ConsoleTutorial-cluster]** ページで、**[タスク]** タブを選択し、**[停止]**、**[すべて停止]** の順に選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページで、**[コンソールチュートリアル – クラスター]** を選択します。

1. ページの右上で、**[クラスターを削除]** を選択します。

1. 確認ボックスに **[**ConsoleTutorial-cluster** を削除]** と入力し、**[削除]** を選択します。

1. 以下のステップに従って Auto Scaling グループを削除します。

   1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

   1. 画面上部のナビゲーションバーで、 リージョンを選択します。

   1. ナビゲーションペインの **自動スケーリング** で、**[Auto Scaling Groups]** (Auto Scaling グループ) を選択します。

   1. `ConsoleTutorial-cluster` Auto Scaling グループ > **[アクション]** の順に選択します。

   1.  [**アクション**] メニューから、[**削除**] を選択します。確認ボックスに **[削除]** と入力し、**[削除]** を選択します。

# Amazon ECS 用の Amazon EC2 コンテナインスタンス
<a name="create-capacity"></a>

Amazon ECS コンテナインスタンスは、Amazon ECS コンテナエージェントを実行し、クラスターに登録されている Amazon EC2 インスタンスです。キャパシティプロバイダー、外部キャパシティプロバイダー、または Auto Scaling グループキャパシティプロバイダーを使用して Amazon ECS でタスクを実行すると、タスクはアクティブなコンテナインスタンス上に配置されます。コンテナインスタンスの管理とメンテナンスはお客様の責任となります。

Amazon ECS で一元化されたワークロードを実行するために必要な基本的な仕様を満たす独自の Amazon EC2 インスタンス AMI を作成することはできますが、Amazon ECS に最適化された AMI は事前設定され、AWS エンジニアにより Amazon ECS でテストされています。これは最も簡単に開始できる方法であり、AWS でコンピューティングリソースをすばやく実行できます。

コンソールを使用してクラスターを作成すると、Amazon ECS は選択したオペレーティングシステムに関連付けられた最新の AMI を使用してインスタンスの起動テンプレートを作成します。

CloudFormation を使用してクラスターを作成する場合、SSM パラメータは Auto Scaling グループインスタンスの Amazon EC2 起動テンプレートの一部となります。動的な Systems Manager パラメータを使用して、デプロイする Amazon ECS Optimized AMI を決定するようにテンプレートを設定できます。このパラメータにより、スタックをデプロイするたびに、EC2 インスタンスに適用する必要がある利用可能な更新があるかどうかがチェックされます。Systems Manager パラメータの使用方法の例については、「*AWS CloudFormation ユーザーガイド*」の「[Amazon ECS に最適化された Amazon Linux 2023 AMI を使用して Amazon ECS クラスターを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI)」を参照してください。
+ [Amazon ECS に最適化された Linux AMI メタデータを取得する](retrieve-ecs-optimized_AMI.md)
+ [Amazon ECS に最適化された Bottlerocket AMI メタデータを取得する](ecs-bottlerocket-retrieve-ami.md)
+ [Amazon ECS に最適化された Windows AMI メタデータを取得する](retrieve-ecs-optimized_windows_AMI.md)

アプリケーションと互換性のあるインスタンスタイプから選択できます。大きいインスタンスでは、同時に多くのタスクを起動できます。インスタンスが小さい場合は、よりきめ細かくスケールアウトしてコストを節約できます。クラスター内のすべてのアプリケーションに対応する Amazon EC2 インスタンスタイプを 1 つ選択する必要はありません。代わりに、複数の Auto Scaling グループを作成し、各グループが異なるインスタンスタイプを持つこともできます。次に、これらのグループごとに Amazon EC2 キャパシティープロバイダーを作成できます。

使用するインスタンスファミリータイプとインスタンスタイプを決定するには、以下のガイドラインを使用します。
+ アプリケーションの特定の要件を満たしていないインスタンスタイプまたはインスタンスファミリーを除外します。例えば、アプリケーションに GPU が必要な場合は、GPU がないインスタンスタイプをすべて除外できます。
+ ネットワークスループットやストレージなどの要件を検討します。
+ CPU とメモリを検討します。原則として、CPU とメモリは、実行するタスクのレプリカを少なくとも 1 つ保存できる大きさである必要があります。

## スポットインスタンス
<a name="container-instance-spot"></a>

Spot キャパシティーは、オンデマンドインスタンスに比べて大幅なコスト削減が可能です。Spot キャパシティーとは、オンデマンドまたはリザーブドキャパシティーよりも大幅に低価格の余剰容量です。Spot キャパシティーは、バッチ処理や機械学習のワークロード、開発環境やステージング環境に適しています。より一般的には、一時的なダウンタイムを許容するあらゆるワークロードに適しています。

Spot キャパシティーが常に利用できるわけではないため、次のような結果が生じることを理解してください。
+ 需要が非常に多い時期には、Spot キャパシティーが利用できない場合があります。これにより、Amazon EC2 スポットインスタンスの起動が遅れる場合があります。このようなイベントで、Amazon ECS サービスはタスクの起動を再試行し、Amazon EC2 Auto Scaling グループも、必要なキャパシティーが利用可能になるまでインスタンスの起動を再試行します。Amazon EC2 は Spot キャパシティーをオンデマンドキャパシティーに置き換えません。
+ キャパシティーに対する全体的な需要が高まると、スポットインスタンスとタスクは 2 分間の警告だけで終了する場合があります。警告が送信されたら、インスタンスが完全に終了する前に、必要に応じてタスクを順番にシャットダウンする必要があります。これにより、エラーの可能性を最小限に抑えられます。正常なシャットダウンの詳細については、「[ECS による正常なシャットダウン](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/)」を参照してください。

スポットのキャパシティー不足を最小限に抑えるために、次の推奨事項を検討してください。
+ 複数のリージョンとアベイラビリティーゾーンを使用する - Spot キャパシティーはリージョンとアベイラビリティーゾーンによって異なります。複数のリージョンとアベイラビリティーゾーンでワークロードを実行することで、スポットの可用性を向上できます。可能な場合は、タスクとインスタンスを実行するリージョンのすべてのアベイラビリティーゾーンのサブネットを指定してください。
+ 複数の Amazon EC2 インスタンスタイプを使用する- Amazon EC2 Auto Scaling で混合インスタンスポリシーを使用すると、複数のインスタンスタイプが Auto Scaling グループに起動されます。これにより、Spot キャパシティーのリクエストを必要なときに確実に処理できます。信頼性を最大化し、複雑さを最小限に抑えるには、混合インスタンスポリシーでほぼ同じ量の CPU とメモリを備えたインスタンスタイプを使用してください。これらのインスタンスは、異なる世代のものでも、同じ基本インスタンスタイプのバリアントのものでもかまいません。不要な追加機能が付属している場合があることに注意してください。このようなリストの例としては、m4.large、m5.large、m5a.large、m5d.large、m5n.large、m5dn.large、m5ad.large などがあります。詳細については「Amazon EC2 Auto Scaling ユーザーガイド」の「[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html)」を参照してください。**
+ キャパシティーが最適化されたスポット割り当て戦略を使用する - Amazon EC2 スポットでは、容量を最適化する割り当て戦略とコストを最適化する割り当て戦略のどちらかを選択できます。新しいインスタンスを起動するときにキャパシティー最適化戦略を選択した場合、Amazon EC2 スポットは選択したアベイラビリティーゾーンで最も可用性の高いインスタンスタイプを選択します。これにより、インスタンスが起動後すぐに終了する可能性が低くなります。

コンテナインスタンスでスポット終了通知を設定する方法については、以下を参照してください。
+ [スポットインスタンス通知を受信するように Amazon ECS Linux コンテナインスタンスを設定する](spot-instance-draining-linux-container.md)
+ [スポットインスタンス通知を受信するように Amazon ECS Windows コンテナインスタンスを設定する](windows-spot-instance-draining-container.md)

# Amazon ECS に最適化された Linux AMI
<a name="ecs-optimized_AMI"></a>

**重要**  
Amazon ECS 向けに最適化された Amazon Linux 2 AMI は 2026 年 6 月 30 日にサポート終了となり、上流の Amazon Linux 2 オペレーティングシステムと同じ終了日が反映されます (詳細については、「[Amazon Linux 2 に関するよくある質問](https://aws.amazon.com/amazon-linux-2/faqs/)」を参照してください)。アプリケーションをアップグレードして、2028 年までの長期サポートが提供されている Amazon Linux 2023 を使用することをお勧めします。Amazon Linux 2 から Amazon Linux 2023 への移行については、「[Migrating from the Amazon Linux 2 Amazon ECS-optimized AMI to the Amazon Linux 2023 Amazon ECS-optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html)」を参照してください。

Amazon ECS に最適化された AMI はすべて、非推奨になる日が AMI 作成日から 2 年後にデフォルト設定されています。Amazon EC2 `DescribeImages` API を使用して、AMI の非推奨化ステータスと日付を確認できます。詳細については、「*Amazon Elastic Compute Cloud API リファレンス*」の「[DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html)」を参照してください。

Amazon ECS は、コンテナワークロードを実行する要件と推奨事項で事前設定された Amazon ECS に最適化された AMI を備えています。Amazon EC2 インスタンスには、Amazon ECS 向けに最適化された Amazon Linux 2023 AMI を使用することをお勧めします。最新の Amazon ECS に最適化された AMI からコンテナインスタンスを起動することで、最新のセキュリティアップデートや、現行バージョンのコンテナエージェントを確実に取得できます。インスタンスを起動する方法についての詳細は、[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md) を参照してください。

コンソールを使用してクラスターを作成すると、Amazon ECS は選択したオペレーティングシステムに関連付けられた最新の AMI を使用してインスタンスの起動テンプレートを作成します。

CloudFormation を使用してクラスターを作成する場合、SSM パラメータは Auto Scaling グループインスタンスの Amazon EC2 起動テンプレートの一部となります。動的な Systems Manager パラメータを使用して、デプロイする Amazon ECS Optimized AMI を決定するようにテンプレートを設定できます。このパラメータにより、スタックをデプロイするたびに、EC2 インスタンスに適用する必要がある利用可能な更新があるかどうかがチェックされます。Systems Manager パラメータの使用方法の例については、「*AWS CloudFormation ユーザーガイド*」の「[Amazon ECS に最適化された Amazon Linux 2023 AMI を使用して Amazon ECS クラスターを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI)」を参照してください。

Amazon ECS に最適化された AMI をカスタマイズする必要がある場合は、GitHub の「[Amazon ECS Optimized AMI Build Recipes](https://github.com/aws/amazon-ecs-ami)」を参照してください。

Amazon Linux 2023 オペレーティングシステムを実行する Amazon EC2 インスタンスでは、Amazon ECS に最適化された AMI の次のバリアントを使用できます。


| オペレーティングシステム | AMI | 説明 | ストレージ設定 | 
| --- | --- | --- | --- | 
| Amazon Linux 2023 |  Amazon ECS 最適化 Amazon Linux 2023 AMI |  Amazon Linux 2023 は、AWS の次世代 Amazon Linux です。ほとんどの場合、Amazon ECS ワークロードのために Amazon EC2 インスタンスを起動するためにお勧めします。詳細については、「Amazon Linux 2023 ユーザーガイド」の「[Amazon Linux 2023 とは](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html)」を参照してください。  | デフォルトでは、Amazon ECS 最適化 Amazon Linux 2023 AMI は 単一の 30 GiB ルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS 最適化 Amazon Linux 2023 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
| Amazon Linux 2023 (arm64) |  Amazon ECS 最適化 Amazon Linux 2023 (arm64) AMI |  この AMI は Amazon Linux 2023 に基づいており、ARM ベースの AWS Graviton/Graviton 2/Graviton 3/Graviton 4 プロセッサを搭載した Amazon EC2 インスタンスを、Amazon ECS ワークロードのために起動する場合に使用することが推奨されています。詳細については、「*Amazon EC2 インスタンスタイプガイド*」の「[Amazon EC2 汎用インスタンスの仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html)」を参照してください。  | デフォルトでは、Amazon ECS 最適化 Amazon Linux 2023 AMI は 単一の 30 GiB ルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS 最適化 Amazon Linux 2023 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
| Amazon Linux 2023 (Neuron) |  Amazon ECS 最適化 Amazon Linux 2023 AMI  |  これは Amazon Linux 2023 をベースにした、Amazon EC2 Inf1、Trn1、または Inf2 インスタンス用の AMI です。AWS Inferentia および AWS Trainium ドライバーと Docker 用の AWS Neuron ランタイムが事前設定されており、Amazon ECS での機械学習推論ワークロードの実行が容易になります。詳細については、「[AWS Neuron 機械学習ワークロードでの Amazon ECS タスク定義](ecs-inference.md)」を参照してください。 Amazon ECS に最適化された Amazon Linux 2023 (Neuron) AMI には、AWS CLI はプリインストールされていません。  | デフォルトでは、Amazon ECS 最適化 Amazon Linux 2023 AMI は 単一の 30 GiB ルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS 最適化 Amazon Linux 2023 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
| Amazon Linux 2023 GPU | Amazon ECS 最適化 Amazon Linux 2023 GPU AMI |  この AMI は Amazon Linux 2023 に基づいており、Amazon EC2 GPU ベースのインスタンスを、Amazon ECS ワークロードのために起動する場合に使用することが推奨されています。NVIDIA カーネルドライバーと Docker GPU ランタイムが事前に構成されており、Amazon ECS で GPU を利用する実行中のワークロードになります。詳細については、「[GPU ワークロード向けの Amazon ECS タスク定義](ecs-gpu.md)」を参照してください。  | デフォルトでは、Amazon ECS 最適化 Amazon Linux 2023 AMI は 単一の 30 GiB ルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS 最適化 Amazon Linux 2023 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 

Amazon Linux 2 オペレーティングシステムを実行する Amazon EC2 インスタンスでは、Amazon ECS に最適化された AMI の次のバリアントを使用できます。


| オペレーティングシステム | AMI | 説明 | ストレージ設定 | 
| --- | --- | --- | --- | 
|  **Amazon Linux 2**   |  Amazon ECS に最適化された Amazon Linux 2 カーネル 5.10 AMI | この AMI は Amazon Linux 2 をベースにしており、Amazon ECS ワークロードに Linux カーネル 4.14 ではなく Linux カーネル 5.10 を使用して、Amazon EC2 インスタンスを起動したい場合に使用します。Amazon ECS に最適化された Amazon Linux 2 カーネル 5.10 AMI では、AWS CLI は事前インストールされていません。 | デフォルトでは、Amazon Linux 2 ベースの Amazon ECS に最適化された AMI（Amazon ECS に最適化された Amazon Linux 2 AMI、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI、および Amazon ECS GPU に最適化された AMI）には、1 つの 30 GiB のルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS に最適化された Amazon Linux 2 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
|  **Amazon Linux 2**  |  Amazon ECS に最適化された Amazon Linux 2 AMI | これは Amazon ECS のワークロード用です。Amazon ECS に最適化された Amazon Linux 2 AMI には、AWS CLI はプリインストールされていません。 | デフォルトでは、Amazon Linux 2 ベースの Amazon ECS に最適化された AMI（Amazon ECS に最適化された Amazon Linux 2 AMI、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI、および Amazon ECS GPU に最適化された AMI）には、1 つの 30 GiB のルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS に最適化された Amazon Linux 2 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
|  **Amazon Linux 2 (arm64)**  |  Amazon ECS に最適化された Amazon Linux 2 カーネル 5.10 (arm64) AMI |  この AMI は Amazon Linux 2 をベースにし、ARM ベースの AWS Graviton/Graviton 2/Graviton 3/Graviton 4 プロセッサを搭載したAmazon EC2 インスタンス用であり、Amazon EC2 S ワークロードに Linux カーネル 4.14 ではなく Linux カーネル 5.10を使用する場合に使用します。詳細については、「*Amazon EC2 インスタンスタイプガイド*」の「[Amazon EC2 汎用インスタンスの仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html)」を参照してください。 Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI には、AWS CLI はプリインストールされていません。  | デフォルトでは、Amazon Linux 2 ベースの Amazon ECS に最適化された AMI（Amazon ECS に最適化された Amazon Linux 2 AMI、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI、および Amazon ECS GPU に最適化された AMI）には、1 つの 30 GiB のルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS に最適化された Amazon Linux 2 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
| Amazon Linux 2 (arm64) | Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI |  この AMI は Amazon Linux 2 をベースにしており、Amazon ECS ワークロードに ARM ベースの AWS Graviton/Graviton 2/Graviton 3/Graviton 4 プロセッサを搭載した Amazon EC2 インスタンスを起動する場合に使用します。 Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI には、AWS CLI はプリインストールされていません。  | デフォルトでは、Amazon Linux 2 ベースの Amazon ECS に最適化された AMI（Amazon ECS に最適化された Amazon Linux 2 AMI、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI、および Amazon ECS GPU に最適化された AMI）には、1 つの 30 GiB のルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS に最適化された Amazon Linux 2 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
|  **Amazon Linux 2 (GPU)**  | Amazon ECS GPU に最適化されたカーネル 5.10 AMI | この AMI は Amazon Linux 2 に基づいており、Amazon ECS ワークロード用に Linux カーネル 5.10 で Amazon EC2 GPU ベースのインスタンスを起動する場合に使用することをお勧めします。NVIDIA カーネルドライバーと Docker GPU ランタイムが事前に構成されており、Amazon ECS で GPU を利用する実行中のワークロードになります。詳細については、「[GPU ワークロード向けの Amazon ECS タスク定義](ecs-gpu.md)」を参照してください。 | デフォルトでは、Amazon Linux 2 ベースの Amazon ECS に最適化された AMI（Amazon ECS に最適化された Amazon Linux 2 AMI、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI、および Amazon ECS GPU に最適化された AMI）には、1 つの 30 GiB のルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS に最適化された Amazon Linux 2 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
| Amazon Linux 2 (GPU) | Amazon ECS GPU に最適化された AMI | この AMI は Amazon Linux 2 に基づいており、Amazon ECS ワークロード用に Linux カーネル 4.14 で Amazon EC2 GPU ベースのインスタンスを起動する場合に使用することをお勧めします。NVIDIA カーネルドライバーと Docker GPU ランタイムが事前に構成されており、Amazon ECS で GPU を利用する実行中のワークロードになります。詳細については、「[GPU ワークロード向けの Amazon ECS タスク定義](ecs-gpu.md)」を参照してください。 | デフォルトでは、Amazon Linux 2 ベースの Amazon ECS に最適化された AMI（Amazon ECS に最適化された Amazon Linux 2 AMI、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI、および Amazon ECS GPU に最適化された AMI）には、1 つの 30 GiB のルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS に最適化された Amazon Linux 2 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
| Amazon Linux 2 (Neuron)  | Amazon ECS に最適化された Amazon Linux 2 (Neuron) カーネル 5.10 AMI  | これは Amazon Linux 2 をベースにした、Amazon EC2 Inf1、Trn1、または Inf2 インスタンス用の AMI です。Linux カーネル 5.10 搭載 AWS Inferentia および AWS Trainium ドライバーと Docker 用の AWS Neuron ランタイムが事前設定されており、Amazon ECS での機械学習推論ワークロードの実行が容易になります。詳細については、「[AWS Neuron 機械学習ワークロードでの Amazon ECS タスク定義](ecs-inference.md)」を参照してください。Amazon ECS 最適化 Amazon Linux 2 (Neuron) AMI には、AWS CLI はプリインストールされていません。 | デフォルトでは、Amazon Linux 2 ベースの Amazon ECS に最適化された AMI（Amazon ECS に最適化された Amazon Linux 2 AMI、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI、および Amazon ECS GPU に最適化された AMI）には、1 つの 30 GiB のルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS に最適化された Amazon Linux 2 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 
| Amazon Linux 2 (Neuron)  | Amazon ECS 最適化 Amazon Linux 2 (Neuron) AMI | これは Amazon Linux 2 をベースにした、Amazon EC2 Inf1、Trn1、または Inf2 インスタンス用の AMI です。AWS Inferentia および AWS Trainium ドライバーと Docker 用の AWS Neuron ランタイムが事前設定されており、Amazon ECS での機械学習推論ワークロードの実行が容易になります。詳細については、「[AWS Neuron 機械学習ワークロードでの Amazon ECS タスク定義](ecs-inference.md)」を参照してください。Amazon ECS 最適化 Amazon Linux 2 (Neuron) AMI には、AWS CLI はプリインストールされていません。 | デフォルトでは、Amazon Linux 2 ベースの Amazon ECS に最適化された AMI（Amazon ECS に最適化された Amazon Linux 2 AMI、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI、および Amazon ECS GPU に最適化された AMI）には、1 つの 30 GiB のルートボリュームが付属しています。30 GiB ルートボリュームのサイズを起動時に変更して、コンテナインスタンスで使用可能なストレージを増やすことができます。このストレージは、オペレーティングシステム用と Docker イメージおよびメタデータ用に使用されます。Amazon ECS に最適化された Amazon Linux 2 AMI のデフォルトファイルシステムは`xfs`を使用しており、Dockerは `overlay2` ストレージドライバーを使用しています。詳細については、Docker ドキュメントの「[OverlayFS ストレージドライバーを使用する](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)」を参照してください。 | 

Amazon ECS は、GitHub で Amazon ECS を使用して最適化した AMI の Linux バリアントの変更ログを提供します。詳細については、「[Changelog](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md)」を参照してください。

Amazon ECS 最適化 AMI の Linux バリエーションは、Amazon Linux 2 AMI または Amazon Linux 2023 AMI をベースとして使用します。Systems Manager Parameter Store API をクエリすることで、各バリアントの AMI 名を取得できます。詳細については、「[Amazon ECS に最適化された Linux AMI メタデータを取得する](retrieve-ecs-optimized_AMI.md)」を参照してください。Amazon Linux 2 AMI リリースノートも公開されています。詳細については、「[Amazon Linux 2 リリースノート](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html)」を参照してください。Amazon Linux 2023 リリースノートも公開されています。詳細については、「[Amazon Linux 2023 リリースノート](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html)」を参照してください。

次のページでは、変更に関する追加情報を説明します。
+ GitHub の[ソース AMI リリース](https://github.com/aws/amazon-ecs-ami/releases)ノート
+ Docker ドキュメントの「[Docker Engine リリースノート](https://docs.docker.com/engine/release-notes/)」
+ NVIDIA ドキュメントの「[NVIDIA ドライバードキュメント](https://docs.nvidia.com/datacenter/tesla/index.html)」
+ GitHub での [Amazon ECS エージェントの変更ログ](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md)

  `ecs-init` アプリケーションのソースコード、エージェントをパッケージ化するためのスクリプトと構成は、エージェントリポジトリの一部になりました。`ecs-init` の古いバージョンおよびパッケージについては、GitHub で「[Amazon ecs-init の変更ログ](https://github.com/aws/amazon-ecs-init/blob/master/CHANGELOG.md)」を参照してください。

## Amazon ECS に最適化された AMI へのセキュリティ更新の適用
<a name="ecs-optimized-AMI-security-changes"></a>

Amazon Linux に基づく Amazon ECS に最適化された AMI には、cloud-init のカスタマイズされたバージョンが含まれています。Cloud-init は、Linux イメージをクラウドコンピューティング環境でブートストラップし、インスタンスの起動時に必要なアクションを実行するために使用されるパッケージです。デフォルトで、2024 年 6 月 12 日より前にリリースされた Amazon Linux に基づくすべての Amazon ECS に最適化された AMI では、インスタンスの起動時にすべての「重大」および「重要」なセキュリティ更新が適用されます。

2024 年 6 月 12 日のリリース以降、Amazon Linux 2 に基づく Amazon ECS に最適化された AMI の デフォルトの動作には、起動時のパッケージの更新が含まれなくなります。代わりに、リリースが利用可能になりしだい、Amazon ECS に最適化された新しい AMI に更新することをお勧めします。Amazon ECS に最適化された AMI は、利用可能なセキュリティ更新またはベース AMI の変更があったときにリリースされます。この結果、最新のパッケージバージョンとセキュリティ更新が確実に適用され、パッケージバージョンはインスタンスの起動を通じて不変です。Amazon ECS に最適化された最新の AMI の取得方法の詳細については、「[Amazon ECS に最適化された Linux AMI メタデータを取得する](retrieve-ecs-optimized_AMI.md)」を参照してください。

新しい AMI が利用可能になりしだい更新するように環境を自動化することをお勧めします。利用可能なオプションの詳細については、「[Amazon ECS のマネージドインスタンスドレインにより Amazon EC2 キャパシティの管理が容易に](https://aws.amazon.com/blogs/containers/amazon-ecs-enables-easier-ec2-capacity-management-with-managed-instance-draining/)」を参照してください。

特定の AMI バージョンに「重大」および「重要」のセキュリティ更新を引き続き手動で適用する場合は、Amazon EC2 インスタンスで次のコマンドを実行します。

```
yum update --security
```

**警告**  
 Docker または containerd パッケージを更新すると、ホストで実行中のすべてのコンテナが停止するため、実行中のすべての Amazon ECS タスクも停止されることになります。サービスの中断を最小限に抑えるため、適切に計画してください。

起動時にセキュリティ更新を再度有効にする場合は、Amazon EC2 インスタンスの起動時に cloud-init ユーザーデータの `#cloud-config` セクションに次の行を追加できます。詳細については、「*Amazon Linux ユーザーガイド*」の「[Amazon Linux 2 で cloud–init を使用する](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html)」を参照してください。

```
#cloud-config
repo_upgrade: security
```

## Amazon ECS 最適化 AL2023 GPU AMI のバージョンロックパッケージ
<a name="ecs-optimized-ami-version-locked-packages"></a>

Amazon ECS 最適化 AL2023 GPU AMI で GPU 機能の正確かつ高性能な動作を確保するには、特定のパッケージが不可欠です。具体的には次のとおりです。
+ NVIDIA ドライバー (`nvidia*`)
+ カーネルモジュール (`kmod*`)
+ NVIDIA ライブラリ (`libnvidia*`)
+ カーネルパッケージ (`kernel*`)

**注記**  
これは網羅的なリストではありません。ロックされたパッケージの完全なリストは、`dnf versionlock list` を使用することで入手できます。

これらのパッケージは、安定性を確保し、GPU ワークロードを中断する可能性のある意図しない変更を防ぐためにバージョンロックされています。このため、これらのパッケージの変更は、潜在的な問題を適切に処理し、GPU の機能性を維持するマネージドプロセスの範囲内で行う必要があるのが一般的です。

意図しない変更を防ぐため、これらのパッケージには `dnf versionlock` プラグインが使用されています。

ロックされたパッケージを変更したい場合は、以下を実行できます。

```
# unlock a single package
sudo dnf versionlock delete $PACKAGE_NAME

# unlock all packages
sudo dnf versionlock clear
```

**重要**  
これらのパッケージを更新する必要があるお客様は、必要な更新が含まれる最新の AMI バージョンの使用を検討するようにしてください。既存のインスタンスを更新する必要がある場合は、パッケージのロック解除、更新、再ロックを含めた慎重なアプローチを用いることで、プロセスの全体を通じて GPU の機能性を常に確保するようにしてください。

# Amazon ECS に最適化された Linux AMI メタデータを取得する
<a name="retrieve-ecs-optimized_AMI"></a>

Amazon ECS に最適化された AMI のメタデータをプログラムで取得できます。メタデータには、AMI 名、Amazon ECS コンテナエージェントバージョン、Docker バージョンを含む ECS ランタイムバージョンなどが入っています。

コンソールを使用してクラスターを作成すると、Amazon ECS は選択したオペレーティングシステムに関連付けられた最新の AMI を使用してインスタンスの起動テンプレートを作成します。

CloudFormation を使用してクラスターを作成する場合、SSM パラメータは Auto Scaling グループインスタンスの Amazon EC2 起動テンプレートの一部となります。動的な Systems Manager パラメータを使用して、デプロイする Amazon ECS Optimized AMI を決定するようにテンプレートを設定できます。このパラメータにより、スタックをデプロイするたびに、EC2 インスタンスに適用する必要がある利用可能な更新があるかどうかがチェックされます。Systems Manager パラメータの使用方法の例については、「*AWS CloudFormation ユーザーガイド*」の「[Amazon ECS に最適化された Amazon Linux 2023 AMI を使用して Amazon ECS クラスターを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI)」を参照してください。

Amazon ECS に最適化された AMI の各バリアントの AMI ID、イメージ名、オペレーティングシステム、コンテナエージェントバージョン、ソースイメージ名、ランタイムバージョンは、Systems Manager Parameter Store API にクエリすることでプログラムで取得できます。Systems Manager パラメータストア API の詳細については、「[GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)」および「[GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html)」を参照してください。

**注記**  
Amazon ECS に最適化された AMI メタデータを取得するには、管理ユーザーに次の IAM アクセス権限が必要です。`AmazonECS_FullAccess` IAM ポリシーには、次の許可が追加されています。  
ssm:GetParameters
ssm:GetParameter
ssm:GetParametersByPath

## Systems Manager パラメータストアのパラメータフォーマット
<a name="ecs-optimized-ami-parameter-format"></a>

以下は、各 Amazon ECS に最適化された AMI バリアントのパラメータ名のフォーマットです。

**Linux Amazon ECS に最適化された AMI**
+ Amazon Linux 2023 AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/<version>
  ```
+ Amazon Linux 2023 (arm64) AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/<version>
  ```
+ Amazon Linux 2023 (Neuron) AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/<version>
  ```
+ Amazon Linux 2023 (GPU) AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/<version>
  ```

  Amazon Linux 2 AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/<version>
  ```
+ Amazon Linux 2 カーネル 5.10 AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/<version>
  ```
+ Amazon Linux 2 (arm64) AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/<version>
  ```
+ Amazon Linux 2 カーネル 5.10 (arm64) AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/<version>
  ```
+ Amazon ECS GPU に最適化されたカーネル 5.10 AMI のメタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/<version>
  ```
+ Amazon Linux 2 (GPU) AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/<version>
  ```
+ Amazon ECS に最適化された Amazon Linux 2 (Neuron) カーネル 5.10 AMI のメタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/<version>
  ```
+ Amazon Linux 2 (Neuron) AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/inf/<version>
  ```

以下のパラメータ名の形式は、サブパラメータ `image_id` を使用して、推奨される最新の Amazon ECS に最適化された Amazon Linux 2 AMI のイメージ ID を取得します。

```
/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id
```

以下のパラメータ名の形式は、AMI 名を指定して、特定の Amazon ECS に最適化された AMI バージョンのメタデータを取得します。
+ Amazon ECS に最適化された Amazon Linux 2 AMI メタデータ:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20181112-x86_64-ebs
  ```

**注記**  
Amazon ECS に最適化された Amazon Linux 2 AMI のすべてのバージョンを取得できます。Amazon ECS に最適化された AMI バージョン `amzn-ami-2017.09.l-amazon-ecs-optimized` (Linux) 以降のみ取得できます。

## 例
<a name="ecs-optimized-ami-parameter-examples"></a>

以下の例は、それぞれの Amazon ECS に最適化された AMI バリアントのメタデータを取得する方法を示しています。

### 推奨される最新の Amazon ECS に最適化された AMI メタデータを取得する
<a name="ecs-optimized-ami-parameter-examples-1"></a>

推奨される最新の Amazon ECS に最適化された AMI を取得するには、AWS CLI で次の AWS CLI コマンドを使用します。

**Linux Amazon ECS に最適化された AMI**
+ **Amazon ECS 最適化 Amazon Linux 2023 AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended --region us-east-1
  ```
+ **Amazon ECS 最適化 Amazon Linux 2023 (arm64) AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/recommended --region us-east-1
  ```
+ **Amazon ECS に最適化された Amazon Linux 2023 (Neuron) AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended --region us-east-1
  ```
+ **Amazon ECS に最適化された Amazon Linux 2023 GPU AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/recommended --region us-east-1
  ```
+ **Amazon ECS に最適化された Amazon Linux 2 カーネル 5.10 AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended --region us-east-1
  ```
+ **Amazon ECS に最適化された Amazon Linux 2 AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region us-east-1
  ```
+ **Amazon ECS に最適化された Amazon Linux 2 カーネル 5.10 (arm64) AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/recommended --region us-east-1
  ```
+ **Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/recommended --region us-east-1
  ```
+ **Amazon ECS GPU に最適化されたカーネル 5.10 AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended --region us-east-1
  ```
+ **Amazon ECS GPU に最適化された AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
  ```
+ **Amazon ECS に最適化された Amazon Linux 2 (Neuron) カーネル 5.10 AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/recommended --region us-east-1
  ```
+ **Amazon ECS 最適化 Amazon Linux 2 (Neuron) AMI の場合:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/inf/recommended --region us-east-1
  ```

### 推奨される最新の Amazon ECS に最適化された Amazon Linux 2023 AMI のイメージ ID を取得する
<a name="ecs-optimized-ami-parameter-examples-6"></a>

推奨される最新の Amazon ECS に最適化された Amazon Linux 2023 AMI ID のイメージ ID を取得するには、サブパラメータ `image_id` を使用します。

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1
```

`image_id` 値のみを取得するには、特定のパラメータ値のみのクエリを行うことができます。次に例を示します。

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```

### Amazon ECS に最適化された特定の Amazon Linux 2 AMI バージョンのメタデータを取得する
<a name="ecs-optimized-ami-parameter-examples-2"></a>

Amazon ECS に最適化された特定の Amazon Linux AMI バージョンのメタデータを取得するには、AWS CLI で次の AWS CLI コマンドを使用します。AMI 名を、Amazon ECS に最適化された Amazon Linux AMI の名前と置き換えます。

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20200928-x86_64-ebs --region us-east-1
```

### Systems Manager の GetParametersByPath API を使用した Amazon ECS に最適化された Amazon Linux 2 カーネル 5.10 AMI メタデータの取得
<a name="ecs-optimized-ami-parameter-examples-3"></a>

Systems Manager の GetParametersByPath API を使用して、Amazon ECS に最適化された Amazon Linux 2 AMI メタデータを取得します。AWS CLI で次のコマンドを使用します。

```
aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/ --region us-east-1
```

### 推奨される最新の Amazon ECS に最適化された Amazon Linux 2 カーネル 5.10 AMI のイメージ ID を取得する
<a name="ecs-optimized-ami-parameter-examples-4"></a>

サブパラメータ `image_id` を使用することで、推奨される最新の Amazon ECS に最適化された Amazon Linux 2 カーネル 5.10 AMI ID のイメージ ID を取得できます。

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id --region us-east-1
```

`image_id` 値のみを取得するには、特定のパラメータ値のみのクエリを行うことができます。次に例を示します。

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```

### CloudFormation テンプレートの推奨される最新の Amazon ECS に最適化された AMI を使用する
<a name="ecs-optimized-ami-parameter-examples-5"></a>

Systems Manager パラメータストア名を参照することにより、CloudFormation テンプレートで推奨される最新の Amazon ECS に最適化された AMI を参照できます。

**Linux の例**

```
Parameters:kernel-5.10
  LatestECSOptimizedAMI:
    Description: AMI ID
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id
```

# Amazon Linux 2 から Amazon Linux 2023 Amazon ECS 最適化 AMI への移行
<a name="al2-to-al2023-ami-transition"></a>

[Amazon Linux](https://aws.amazon.com/amazon-linux-2/faqs) に続いて、Amazon ECS は、2026 年 6 月 30 日をもって Amazon Linux 2 Amazon ECS 最適化 AMI の標準サポートを終了します。この日以降は、Amazon ECS エージェントバージョンは固定され、新しい Amazon Linux 2 Amazon ECS 最適化 AMI は、ソースとなる Amazon Linux 2 AMI が更新された場合にのみ公開されます。完全なサポート終了 (EOL) は 2026 年 6 月 30 日に発生します。その後は、ソースとなる AMI が更新されても、Amazon ECS 向けに最適化された Amazon Linux 2 AMI は公開されません。

Amazon Linux 2023 は、デフォルトで安全性を確保するアプローチを採用し、事前設定されたセキュリティポリシー、Permissive モードの SELinux、デフォルトで有効になっている IMDSv2-only モード、最適化された起動時間、セキュリティとパフォーマンスの向上を目的として改善されたパッケージ管理機能を提供します。

Amazon Linux 2 と Amazon Linux 2023 の Amazon ECS 最適化 AMI は互換性が高く、ほとんどのお客様が感じる 2 つのオペレーティングシステム間でのワークロードの変化は最小限となるか、全く感じられないでしょう。

AL2 および AL2023 間の主な相違点の詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[Amazon Linux 2 と *Amazon Linux 2023* の比較](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html)」と「[AL 2023 に関するよくある質問](https://aws.amazon.com/linux/amazon-linux-2023/faqs)」を参照してください。

## 互換性に関する考慮事項
<a name="al2-to-al2023-ami-transition-compatibility"></a>

### パッケージ管理と OS の更新
<a name="al2-to-al2023-ami-transition-compatibility-package-management"></a>

Amazon Linux の以前のバージョンとは異なり、Amazon ECS 向けに最適化された Linux 2023 AMI の Amazon Linux リポジトリは特定のバージョンにロックされています。このため、不要な変更や互換性を破る変更を引き起こす可能性のあるパッケージを誤って更新することがありません。詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[Managing repositories and OS updates in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)」を参照してください。

### Linux カーネルバージョン
<a name="al2-to-al2023-ami-transition-compatibility-kernel"></a>

Amazon Linux 2 AMI は Linux カーネル 4.14 および 5.10 をベースにしており、Amazon Linux 2023 は Linux カーネル 6.1 および 6.12 を使用しています。Amazon Linux 2023 の詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[Comparing Amazon Linux 2 and Amazon Linux 2023 kernels](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html)」を参照してください。

### パッケージアベイラビリティの変更
<a name="al2-to-al2023-ami-transition-compatibility-packages"></a>

Amazon Linux 2023 でのパッケージにおける重要な変更点は次のとおりです。
+ Amazon Linux 2 の一部のソースバイナリパッケージは、Amazon Linux 2023 では利用できなくなりました。詳細については、「*Amazon Linux 2023 リリースノート*」の「[Packages removed from Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/removed.html)」を参照してください。
+ Amazon Linux がさまざまなバージョンのパッケージをサポートする方法が変更されました。Amazon Linux 2 で使用される `amazon-linux-extras` システムは、Amazon Linux 2023 には存在しません。すべてのパッケージは、単純に「コア」リポジトリから使用できます。
+ Enterprise Linux (EPEL) の追加パッケージは Amazon Linux 2023 ではサポートされません。詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[EPEL compatibility in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/epel.html)」を参照してください。
+ 32-bit アプリケーションは Amazon Linux 2023 ではサポートされていません。詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[Deprecated features from Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms)」を参照してください。

### コントロールグループ (cgroups) の変更点
<a name="al2-to-al2023-ami-transition-compatibility-cgroups"></a>

コントロールグループ (cgroup) は、プロセスを階層的に整理し、システムリソースをプロセス間で分散するための Linux カーネルの機能です。コントロールグループは、コンテナランタイムの実装や、さまざまな用途に `systemd` によって使用されています。

Amazon ECS エージェント、Docker、および containerd はすべて cgroupv1 と cgroupv2 の両方をサポートしています。Amazon ECS エージェントとコンテナランタイムが cgroup を管理するため、Amazon ECS のお客様は、この基盤となる cgroup アップグレードに変更を加える必要はありません。

cgroupv2 の詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[Control groups v2 in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/cgroupv2.html)」を参照してください。

### インスタンスメタデータサービス (IMDS) の変更点
<a name="al2-to-al2023-ami-transition-compatibility-imds"></a>

Amazon Linux 2023 では、デフォルトではインスタンスメタデータサービスのバージョン 2 (IMDSv2) が必要になります。IMDSv2 には、セキュリティ体制の改善に役立ついくつかの利点があります。セッション指向の認証方式を使用しており、セッションを開始するためにシンプルな HTTP PUT リクエストでシークレットトークンを作成する必要があります。セッショントークンの有効期間は 1 秒～ 6 時間です。

IMDSv1 から IMDSv2 への移行の詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータサービスバージョン 2 の使用への移行](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html)」を参照してください。

IMDSv1 を使用する場合は、インスタンスのメタデータオプションの起動プロパティで設定を手動で上書きすることで使用可能になります。

### メモリスワップの変更点
<a name="al2-to-al2023-ami-transition-compatibility-memory-swappiness"></a>

コンテナごとのメモリスワップは、Amazon Linux 2023 および cgroups v2 ではサポートされていません。詳細については、「[Amazon ECS のコンテナスワップメモリ空間の管理](container-swap.md)」を参照してください。

### FIPS 検証の変更点
<a name="al2-to-al2023-ami-transition-compatibility-fips"></a>

Amazon Linux 2 は FIPS 140-2 に基づいて認定されており、Amazon Linux 2023 は FIPS 140-3 に基づいて認定されています。

Amazon Linux 2023 で FIPS モードを有効にするには、Amazon EC2 インスタンスに必要なパッケージをインストールし、「*Amazon Linux 2023 ユーザーガイド*」の「[Enable FIPS Mode on Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html)」に記載された手順に従って設定を行います。

### インスタンスのサポートの高速化
<a name="al2-to-al2023-ami-transition-compatibility-accelerated"></a>

Amazon ECS 向けに最適化された Amazon Linux 2023 AMI は、Neuron と GPU の両方の高速化インスタンスタイプをサポートしています。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。

## カスタム AMI の構築
<a name="al2-to-al2023-ami-transition-custom-ami"></a>

Amazon Linux 2023 では、正式にサポートおよび公開されている Amazon ECS 最適化 AMI に移行することをお勧めしますが、Amazon ECS 最適化 AMI の Linux バリアントの構築に使用されているオープンソースのビルドスクリプトを使用することで、引き続きカスタム Amazon Linux 2 Amazon ECS 最適化 AMI を構築できます。詳細については、「[Amazon ECS 最適化 Linux AMI のビルドスクリプト](ecs-ami-build-scripts.md)」を参照してください。

## 移行戦略
<a name="al2-to-al2023-ami-transition-migration"></a>

徹底的なアプリケーションテストを含む移行計画を作成して実装することをお勧めします。以下のセクションでは、Amazon ECS インフラストラクチャの管理方法に基づくさまざまな移行戦略についての概要を説明します。

### Amazon ECS キャパシティプロバイダーを利用した移行
<a name="al2-to-al2023-ami-transition-migration-capacity-providers"></a>

1. 新しい起動テンプレートを使用して、新しいキャパシティプロバイダーを作成します。これは、既存の起動テンプレートと類似した起動テンプレートを持つ Auto Scaling グループを参照する必要がありますが、Amazon Linux 2 Amazon ECS 最適化 AMI ではなく、Amazon Linux 2023 バリアントのいずれかを指定する必要があります。この新しいキャパシティプロバイダーを既存の Amazon ECS クラスターに追加します。

1. クラスターのデフォルトのキャパシティプロバイダー戦略を更新して、既存の Amazon Linux 2 キャパシティプロバイダーと新しい Amazon Linux 2023 キャパシティプロバイダーの両方が含まれるようにします。Amazon Linux 2 プロバイダーの重みを大きく、Amazon Linux 2023 プロバイダーの重みを小さく設定します (Amazon Linux 2: 重み 80、Amazon Linux 2023: 重み 20 など)。これにより、新しいタスクがスケジュールされると、Amazon ECS は Amazon Linux 2023 インスタンスのプロビジョニングを開始します。インスタンスが正しく登録されていること、タスクが新しいインスタンスで正常に実行できることを確認します。

1. クラスターのデフォルト戦略におけるキャパシティプロバイダーの重みを徐々に調整し、Amazon Linux 2023 プロバイダーの重みを増加させつつ、Amazon Linux 2 プロバイダーの重みを時間の経過とともに減らします (例: 60/40、40/60、20/80)。個々のサービスプロバイダー戦略を更新して、Amazon Linux 2023 インスタンスを優先させることもできます。タスクの配置を監視して、Amazon Linux 2023 インスタンスで正常に実行されていることを確認します。

1. 必要に応じて Amazon Linux 2 コンテナインスタンスをドレインして、タスクの移行を高速化します。Amazon Linux 2023 に置き換える十分な容量がある場合は、Amazon ECS コンソールまたは AWS CLI を使用して Amazon Linux 2 コンテナインスタンスを手動でドレインすることで、Amazon Linux 2 から Amazon Linux 2023 へのタスクの移行を高速化できます。移行が完了したら、クラスターから Amazon Linux 2 キャパシティプロバイダーを削除し、関連する Auto Scaling グループを削除します。

### Amazon EC2 Auto Scaling グループを使用した移行
<a name="al2-to-al2023-ami-transition-migration-asg"></a>

1. 新しい起動テンプレートを使用して、新しい Amazon EC2 Auto Scaling グループを作成します。これは既存の起動テンプレートと類似しているはずですが、Amazon Linux 2 Amazon ECS 最適化 AMI の代わりに、Amazon Linux 2023 バリアントのいずれかを指定する必要があります。この新しい Auto Scaling グループは、既存のクラスターにインスタンスを起動できます。

1. Auto Scaling グループをスケールアップして、Amazon Linux 2023 インスタンスがクラスターに登録されるようにします。インスタンスが正しく登録されていること、タスクが新しいインスタンスで正常に実行できることを確認します。

1. タスクが Amazon Linux 2023 で動作することを検証したら、Amazon Linux 2023 Auto Scaling グループをスケールアップしつつ、Amazon Linux 2 Auto Scaling グループを徐々にスケールダウンし、すべての Amazon Linux 2 インスタンスが完全に置き換えられるまで継続します。

1. Amazon Linux 2023 に置き換える十分な容量がある場合は、コンテナインスタンスを明示的にドレインすることで、Amazon Linux 2 から Amazon Linux 2023 へのタスクの移行を高速化できます。詳細については、「[Amazon ECS コンテナインスタンスをドレインする](container-instance-draining.md)」を参照してください。

### 手動マネージドインスタンスを使用した移行
<a name="al2-to-al2023-ami-transition-migration-manual"></a>

1. Amazon Linux 2 の代わりに Amazon ECS に最適化された Amazon Linux 2023 AMI を使用して、新しい Amazon EC2 インスタンスを手動で起動 (または起動するスクリプトを調整) します。これらのインスタンスが既存の Amazon Linux 2 インスタンスと同じセキュリティグループ、サブネット、IAM ロール、クラスター設定を使用していることを確認します。インスタンスは、起動時に既存の Amazon ECS クラスターに自動的に登録される必要があります。

1. 新しい Amazon Linux 2023 インスタンスが Amazon ECS クラスターに正常に登録され、`ACTIVE` 状態であることを確認します。自然にタスクが配置されるのを待つか、一部のタスクを手動で停止/開始してスケジュール変更を開始することで、これらの新しいインスタンスでタスクを適切にスケジュールして実行できることをテストします。

1. 必要に応じて追加の Amazon Linux 2023 インスタンスを起動し、Amazon Linux 2 インスタンスを手動でドレインして 1 つずつ終了することで、Amazon Linux 2 インスタンスを段階的に置き換えます。インスタンスを `DRAINING` ステータスに設定することで、Amazon ECS コンソールからインスタンスをドレインできます。これにより、インスタンスへの新しいタスクの配置が停止し、既存のタスクの終了や別の場所への再スケジュールが可能になります。

# Amazon ECS 最適化 Linux AMI のビルドスクリプト
<a name="ecs-ami-build-scripts"></a>

Amazon ECS は、Amazon ECS に最適化された AMI の Linux バリアントの構築に使用するビルドスクリプトをオープンソース化しました。これらのビルドスクリプトは、現在 GitHub で入手できます。詳細については、GitHub の「[amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami)」を参照してください。

Amazon ECS に最適化された AMI をカスタマイズする必要がある場合は、GitHub の「[Amazon ECS Optimized AMI Build Recipies](https://github.com/aws/amazon-ecs-ami)」を参照してください。

ビルドスクリプトレポジトリには、[HashiCorp Packer](https://developer.hashicorp.com/packer/docs) テンプレートと、Amazon ECS に最適化された AMI の各 Linux バリアントを生成するためのビルドスクリプトが含まれています。ここに置かれているものは、Amazon ECS 最適化 AMI のビルド用として最も信頼できるソーススクリプトであるため、GitHub リポジトリの状態をフォローすることで、AMI に対し実施された変更をモニタリングできます。例えば、独自の AMI で、Amazon ECS チームが正式な AMI に使用するのと同じバージョンの Docker を使用できます。

詳細については、GitHub の Amazon ECS AMI リポジトリにある「[aws/amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami)」を参照してください。

**Amazon ECS に最適化された Linux AMI を構築するには**

1. `aws/amazon-ecs-ami` GitHub リポジトリのクローンを作成する

   ```
   git clone https://github.com/aws/amazon-ecs-ami.git
   ```

1. AMI の作成時に使用する AWS リージョンの環境変数を追加します。`us-west-2` 値を使用するリージョンに置き換えます。

   ```
   export REGION=us-west-2
   ```

1. AMI を構築するための Makefile が提供されます。クローンされたリポジトリのルートディレクトリから、構築する Amazon ECS 最適化 AMI の Linux バリアントに対応する次のコマンドのいずれかを使用します。
   + Amazon ECS に最適化された Amazon Linux 2 AMI

     ```
     make al2
     ```
   + Amazon ECS に最適化された Amazon Linux 2(arm64) AMI

     ```
     make al2arm
     ```
   + Amazon ECS GPU に最適化された AMI

     ```
     make al2gpu
     ```
   + Amazon ECS 最適化 Amazon Linux 2 (Neuron) AMI

     ```
     make al2inf
     ```
   + Amazon ECS 最適化 Amazon Linux 2023 AMI

     ```
     make al2023
     ```
   + Amazon ECS 最適化 Amazon Linux 2023 (arm64) AMI

     ```
     make al2023arm
     ```
   + Amazon ECS 最適化 Amazon Linux 2023 GPU AMI

     ```
     make al2023gpu
     ```
   + Amazon ECS 最適化 Amazon Linux 2023 (Neuron) AMI

     ```
     make al2023neu
     ```

# Amazon ECS 最適化 Bottlerocket AMI
<a name="ecs-bottlerocket"></a>

Bottlerocket は Linux ベースのオープンソースのオペレーティングシステムで、仮想マシンやベアメタルホスト上でコンテナを実行するために AWS によって専用に構築されています。Amazon ECS 最適化 Bottlerocket AMI は安全で、コンテナの実行に必要な最小数のパッケージのみが含まれています。これは、リソースの使用量を改善し、セキュリティのアタックサーフェスを縮小し、管理オーバーヘッドを削減するのに役立ちます。Bottlerocket AMI は Amazon ECS とも統合するため、クラスター内のコンテナインスタンスの更新に伴う運用上のオーバーヘッドを削減するのに役立ちます。

Bottlerocket は、次の点で Amazon Linux とは異なります。
+ Bottlerocket にはパッケージマネージャーが含まれておらず、そのソフトウェアはコンテナとしてのみ実行できます。Bottlerocket に対する更新は、1 つのステップで適用され、1 つのステップでロールバックできるため、更新エラーの可能性が低くなります。
+ Bottlerocket ホストを管理する主なメカニズムでは、コンテナスケジューラを使用します。Amazon Linux とは異なり、個別の Bottlerocket インスタンスへのログインは、高度なデバッグとトラブルシューティングのみを目的として、低頻度で実行される操作であることを想定しています。

Bottlerocket の詳細については、「GitHub」の「[ドキュメント](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md)」と「[リリース](https://github.com/bottlerocket-os/bottlerocket/releases)」を参照してください。

Amazon ECS に最適化された Bottlerocket AMI には、カーネル 6.1 用とカーネル 5.10 用のバリアントがあります。

以下のバリアントはカーネル 6.1 を使用します。
+ `aws-ecs-2`
+ `aws-ecs-2-nvidia`

以下のバリアントはカーネル 5.10 を使用します。
+ `aws-ecs-1`
+ `aws-ecs-1-nvidia`

  `aws-ecs-1-nvidia` バリアントの詳細については、「[Amazon ECS での Bottlerocket 向け NVIDIA GPU サポートの発表](https://aws.amazon.com/blogs/containers/announcing-nvidia-gpu-support-for-bottlerocket-on-amazon-ecs/)」を参照してください。

## 考慮事項
<a name="ecs-bottlerocket-considerations"></a>

Amazon ECS で Bottlerocket AMI を使用する場合は、次の点を考慮してください。
+ Bottlerocket は、`x86_64` と `arm64` プロセッサを搭載した Amazon EC2 インスタンスをサポートします。Bottlerocket AMI を Inferentia チップを搭載した Amazon EC2 インスタンスで使用することはお勧めしません。
+ Bottlerocket イメージには、SSH サーバーまたはシェルは含まれません。ただし、帯域外管理ツールを使用して、SSH 管理者アクセスを取得し、ブートストラップを実行できます。

   詳細については、「GitHub」の「[bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket)」のセクションを参照してください。
  + [探査](https://github.com/bottlerocket-os/bottlerocket#exploration)
  + [管理者コンテナ](https://github.com/bottlerocket-os/bottlerocket#admin-container)
+ デフォルトで、Bottlerocket には有効になっている[コントロールコンテナ](https://github.com/bottlerocket-os/bottlerocket-control-container)があります。このコンテナは、Amazon EC2 Bottlerocket インスタンス上でのコマンドの実行やシェルセッションの開始に使用できる [AWS Systems Manager エージェント](https://github.com/aws/amazon-ssm-agent)を実行します。詳細については、*AWS Systems Manager ユーザーガイド*の [Session Manager のセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html)を参照してください。
+ Bottlerocketはコンテナのワークロード向けに最適化されており、セキュリティに重点を置いています。Bottlerocket にはパッケージマネージャーが含まれておらず、イミュータブルです。

  セキュリティ機能とガイダンスについては、GitHub の「[セキュリティ機能](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_FEATURES.md)」および「[セキュリティガイダンス](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md)」を参照してください。
+ `awsvpc` ネットワークモードは、`1.1.0` 以降の Bottlerocket AMI バージョンでサポートされています。
+ タスク定義の App Mesh は Bottlerocket AMI バージョン `1.15.0` 以降でサポートされています。
+ タスク定義パラメータ `initProcessEnabled` は Bottlerocket AMI バージョン `1.19.0` 以降でサポートされています。
+ Bottlerocket AMI は、次のサービスと機能もサポートしていません。
  + ECS Anywhere
  + Service Connect
  + 暗号化モードの Amazon EFS
  + `awsvpc` ネットワークモードの Amazon EFS
  + Amazon EBS ボリュームをマウントできない
  + Elastic Inference アクセラレーター

# Amazon ECS に最適化された Bottlerocket AMI メタデータを取得する
<a name="ecs-bottlerocket-retrieve-ami"></a>

AWS Systems Manager パラメータストア API をクエリすることで、Amazon ECS に最適化された AMI の Amazon マシンイメージ (AMI) ID を取得できます。このパラメータを使用することで、Amazon ECS 最適化 AMI ID を手動で検索する必要がなくなります。Systems Manager Parameter Store API の詳細については、[GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html) を参照してください。使用するユーザーには、Amazon ECS 最適化 AMI メタデータを取得するための `ssm:GetParameter` IAM 許可が必要です。

## `aws-ecs-2` Bottlerocket AMI バリアント
<a name="ecs-bottlerocket-aws-ecs-2-variant"></a>

AWS CLI または AWS マネジメントコンソール を使用して、AWS リージョン およびアーキテクチャ別に、最新の安定した `aws-ecs-2` Bottlerocket AMI バリアントを取得できます。
+ **AWS CLI** – サブパラメータ `image_id` を指定しながら次の AWS CLI コマンドを使用することで、推奨される最新の Amazon ECS 最適化 Bottlerocket AMI のイメージ ID を取得できます。`region` を、AMI ID が必要な地域コードに置き換えます。

  サポートされている AWS リージョン については、GitHub での「[AMI の検索](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)」を参照してください。最新バージョン以外を取得するには、`latest` をバージョン番号に置き換えてください。
  + 64 ビット (`x86_64`) アーキテクチャの場合:

    ```
    aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + 64 ビット Arm (`arm64`) アーキテクチャの場合:

    ```
    aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **AWS マネジメントコンソール** – AWS マネジメントコンソール で URL を使用して、推奨される Amazon ECS 最適化 AMI ID をクエリできます。この URL により、Amazon EC2 Systems Manager コンソールが開き、パラメータに対応した ID 値が表示されます 次の URL で、`region` を、AMI ID が必要なリージョンコードに置き換えます。

   サポートされている AWS リージョン については、GitHub での「[AMI の検索](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)」を参照してください。
  + 64 ビット (`x86_64`) アーキテクチャの場合:

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id/description?region=region#
    ```
  + 64 ビット Arm (`arm64`) アーキテクチャの場合:

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id/description?region=region#
    ```

## `aws-ecs-2-nvidia` Bottlerocket AMI バリアント
<a name="ecs-bottlerocket-aws-ecs-1-nvidia-variants"></a>

AWS CLI または AWS マネジメントコンソール を使用して、リージョンおよびアーキテクチャ別に、最新の安定した `aws-ecs-2-nvdia` Bottlerocket AMI バリアントを取得できます。
+ **AWS CLI** – サブパラメータ `image_id` を指定しながら次の AWS CLI コマンドを使用することで、推奨される最新の Amazon ECS 最適化 Bottlerocket AMI のイメージ ID を取得できます。`region` を、AMI ID が必要な地域コードに置き換えます。

   サポートされている AWS リージョン については、GitHub での「[AMI の検索](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)」を参照してください。最新バージョン以外を取得するには、`latest` をバージョン番号に置き換えてください。
  + 64 ビット (`x86_64`) アーキテクチャの場合:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + 64 ビット Arm (`arm64`) アーキテクチャの場合:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **AWS マネジメントコンソール** – AWS マネジメントコンソール で URL を使用して、推奨される Amazon ECS 最適化 AMI ID をクエリできます。この URL により、Amazon EC2 Systems Manager コンソールが開き、パラメータに対応した ID 値が表示されます 次の URL で、`region` を、AMI ID が必要なリージョンコードに置き換えます。

  サポートされている AWS リージョン については、GitHub での「[AMI の検索](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)」を参照してください。
  + 64 ビット (`x86_64`) アーキテクチャの場合:

    ```
    https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id/description?region=region#
    ```
  + 64 ビット Arm (`arm64`) アーキテクチャの場合:

    ```
    https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id/description?region=region#
    ```

## `aws-ecs-1` Bottlerocket AMI バリアント
<a name="ecs-bottlerocket-aws-ecs-1-variant"></a>

AWS CLI または AWS マネジメントコンソール を使用して、AWS リージョン およびアーキテクチャ別に、最新の安定した `aws-ecs-1` Bottlerocket AMI バリアントを取得できます。
+ **AWS CLI** – サブパラメータ `image_id` を指定しながら次の AWS CLI コマンドを使用することで、推奨される最新の Amazon ECS 最適化 Bottlerocket AMI のイメージ ID を取得できます。`region` を、AMI ID が必要な地域コードに置き換えます。

  サポートされている AWS リージョン については、GitHub での「[AMI の検索](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)」を参照してください。最新バージョン以外を取得するには、`latest` をバージョン番号に置き換えてください。
  + 64 ビット (`x86_64`) アーキテクチャの場合:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + 64 ビット Arm (`arm64`) アーキテクチャの場合:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **AWS マネジメントコンソール** – AWS マネジメントコンソール で URL を使用して、推奨される Amazon ECS 最適化 AMI ID をクエリできます。この URL により、Amazon EC2 Systems Manager コンソールが開き、パラメータに対応した ID 値が表示されます 次の URL で、`region` を、AMI ID が必要なリージョンコードに置き換えます。

  サポートされている AWS リージョン については、GitHub での「[AMI の検索](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)」を参照してください。
  + 64 ビット (`x86_64`) アーキテクチャの場合:

    ```
    https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id/description
    ```
  + 64 ビット Arm (`arm64`) アーキテクチャの場合:

    ```
    https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id/description
    ```

## `aws-ecs-1-nvidia` Bottlerocket AMI バリアント
<a name="ecs-bottlerocket-aws-ecs-1-nvidia-variants"></a>

AWS CLI または AWS マネジメントコンソール を使用して、リージョンおよびアーキテクチャ別に、最新の安定した `aws-ecs-1-nvdia` Bottlerocket AMI バリアントを取得できます。
+ **AWS CLI** – サブパラメータ `image_id` を指定しながら次の AWS CLI コマンドを使用することで、推奨される最新の Amazon ECS 最適化 Bottlerocket AMI のイメージ ID を取得できます。`region` を、AMI ID が必要な地域コードに置き換えます。

  サポートされている AWS リージョン については、GitHub での「[AMI の検索](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)」を参照してください。
  + 64 ビット (`x86_64`) アーキテクチャの場合:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + 64 ビット Arm (`arm64`) アーキテクチャの場合:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **AWS マネジメントコンソール** – AWS マネジメントコンソール で URL を使用して、推奨される Amazon ECS 最適化 AMI ID をクエリできます。この URL により、Amazon EC2 Systems Manager コンソールが開き、パラメータに対応した ID 値が表示されます 次の URL で、`region` を、AMI ID が必要なリージョンコードに置き換えます。

  サポートされている AWS リージョン については、GitHub での「[AMI の検索](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)」を参照してください。
  + 64 ビット (`x86_64`) アーキテクチャの場合:

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id/description?region=region#
    ```
  + 64 ビット Arm (`arm64`) アーキテクチャの場合:

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id/description?region=region#
    ```

## 次のステップ
<a name="bottlerocket-next-steps"></a>

Amazon ECS で Bottlerocket オペレーティングシステムの使用を開始する方法の詳細なチュートリアルについては、GitHub の「[Using a Bottlerocket AMI with Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md)」および AWS ブログサイトの「[Getting started with Bottlerocket and Amazon ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/)」を参照してください。

Bottlerocket インスタンスを起動する方法については、「[Amazon ECS の Bottlerocket インスタンスの起動](bottlerocket-launch.md)」を参照してください。

# Amazon ECS の Bottlerocket インスタンスの起動
<a name="bottlerocket-launch"></a>

Bottlerocket インスタンスを起動することで、コンテナワークロードを実行することができます。

AWS CLI を使用して Bottlerocket インスタンスを起動できます。

1. `userdata.toml` というファイルを作成します。このファイルは、インスタンスのユーザーデータに使用されます。*cluster-name* をクラスターの名前に置き換えます。

   ```
   [settings.ecs]
   cluster = "cluster-name"
   ```

1. [Amazon ECS に最適化された Bottlerocket AMI メタデータを取得する](ecs-bottlerocket-retrieve-ami.md) に含まれているコマンドのいずれかを使用して、Bottlerocket AMI ID を取得します。これは次のステップで使用します。

1. 次のコマンドを実行して、Bottlerocket インスタンスを起動します。次のパラメータを必ず置き換えてください。
   + *subnet* を、インスタンスを起動するプライベートまたはパブリックサブネットの ID に置き換えます。
   + *bottlerocket\$1ami* を、前のステップの AMI ID に置き換えます。
   + *t3.large* を、使用するインスタンスタイプに置き換えます。
   + *region* を、リージョンコードに置き換えます。

   ```
   aws ec2 run-instances --key-name ecs-bottlerocket-example \
      --subnet-id subnet \
      --image-id bottlerocket_ami \
      --instance-type t3.large \
      --region region \
      --tag-specifications 'ResourceType=instance,Tags=[{Key=bottlerocket,Value=example}]' \
      --user-data file://userdata.toml \
      --iam-instance-profile Name=ecsInstanceRole
   ```

1. 次のコマンドを実行して、コンテナインスタンスがクラスターに登録されていることを検証します。このコマンドを実行するときは、次のパラメータを必ず置き換えてください。
   + *cluster* を、自分のクラスター名に置き換えます。
   + *region* を、リージョンコードに置き換えます。

   ```
   aws ecs list-container-instances --cluster cluster-name --region region
   ```

Amazon ECS で Bottlerocket オペレーティングシステムの使用を開始する方法の詳細なチュートリアルについては、GitHub の「[Using a Bottlerocket AMI with Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md)」および AWS ブログサイトの「[Getting started with Bottlerocket and Amazon ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/)」を参照してください。

# Amazon ECS Linux コンテナインスタンスの管理
<a name="manage-linux"></a>

Amazon ECS ワークロードに EC2 インスタンスを使用する場合、インスタンスの維持はユーザーの責任となります。

**Topics**
+ [コンテナインスタンスの起動](launch_container_instance.md)
+ [Linux コンテナインスタンスのブートストラップ](bootstrap_container_instance.md)
+ [スポットインスタンス通知を受信するようにコンテナインスタンスを設定する](spot-instance-draining-linux-container.md)
+ [コンテナインスタンスの起動時にスクリプトを実行する](start_task_at_launch.md)
+ [Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす](container-instance-eni.md)
+ [コンテナインスタンスのメモリを予約する](memory-management.md)
+ [コンテナインスタンスのリモート管理](ec2-run-command.md)
+ [Linux コンテナインスタンスに HTTP プロキシを使用する](http_proxy_config.md)
+ [Auto Scaling グループ用に事前初期化されたインスタンスを設定する](using-warm-pool.md)
+ [Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)

Amazon ECSコンテナエージェントの各バージョンは、異なる機能セットをサポートし、以前のバージョンのバグ修正を提供します。可能であれば、最新バージョンの Amazon ECSコンテナエージェントを使用することを常にお勧めします。コンテナエージェントを最新バージョンに更新するには、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。

どの機能と拡張が各エージェントリリースに含まれているか確認するには、[https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases) を参照してください。

**重要**  
信頼できるメトリクスの最小 Docker バージョンは、Amazon ECS 最適化 AMI `20220607` 以降に含まれる Docker バージョン `v20.10.13` 以降です。  
バージョン `1.20.0` 以降のAmazon ECSエージェントでは、`18.01.0` より前のバージョンの Docker のサポートが廃止されました。

# Amazon ECS Linux コンテナインスタンスの起動
<a name="launch_container_instance"></a>

Amazon EC2 コンソールを使用して Amazon ECS コンテナインスタンスを作成できます。

インスタンスは、Amazon EC2 コンソール、AWS CLI、SDK など、さまざまな方法で起動できます。インスタンスを起動する他の方法については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスを起動する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)」を参照してください。

起動ウィザードの詳細については、「*Amazon EC2 ユーザーガイド*」の「[新しいインスタンス起動ウィザードを使用してインスタンスを起動する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)」を参照してください。

開始する前に、「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」のステップを完了します。

新しい Amazon EC2 ウィザードを使用してインスタンスを起動できます。インスタンス起動ウィザードでは、インスタンスの起動に必要な起動パラメータを指定します。

**Topics**
+ [手順](#linux-liw-initiate-instance-launch)
+ [名前とタグ](#linux-liw-name-and-tags)
+ [アプリケーションと OS イメージ (Amazon マシンイメージ)](#linux-liw-ami)
+ [インスタンスタイプ](#linux-liw-instance-type)
+ [キーペア (ログイン)](#linux-liw-key-pair)
+ [ネットワーク設定](#linux-liw-network-settings)
+ [ストレージの設定](#linux-liw-storage)
+ [高度な詳細](#linux-liw-advanced-details)

## 手順
<a name="linux-liw-initiate-instance-launch"></a>

開始する前に、「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」のステップを完了します。

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. 画面の上のナビゲーションバーで、現在の AWS リージョンが表示されます (例: 米国東部 (オハイオ))。インスタンスを起動するリージョンを選択します。

1. Amazon EC2 コンソールダッシュボードで、[**インスタンスを起動**] を選択してください。

## 名前とタグ
<a name="linux-liw-name-and-tags"></a>

インスタンス名はタグで、キーは **[Name]** (名前)、値は指定した名前です。インスタンス、ボリューム、および伸縮自在なグラフィックスにタグ付けできます。スポットインスタンスの場合、スポットインスタンスリクエストにのみタグを付けることができます。

インスタンス名と追加のタグを指定することはオプションです。
+ **[Name]** (名前) に、インスタンスのわかりやすい名前を入力します。名前を指定しない場合は、インスタンスをその ID で識別できます。ID は、インスタンスの起動時に自動的に生成されます。
+ タグを追加するには、**[Add additional tag]** (追加のタグを追加) を選択します。**[Add tag]** (タグを追加) を選択し、キーと値を入力し、タグ付けするリソースタイプを選択します。追加するタグごとに **[Add tag]** (タグの追加) を選択します。

## アプリケーションと OS イメージ (Amazon マシンイメージ)
<a name="linux-liw-ami"></a>

Amazon マシンイメージ (AMI) には、インスタンスの作成に必要な情報が含まれています。例えば、ある AMI には、ウェブサーバーとして動作するために必要なソフトウェア (Apache やウェブサイトなど) が含まれています。

**[Search]** (検索) バーを使用して、AWS によって発行された適切な Amazon ECS 最適化 AMI を検索します。

1. **[Search]** (検索) バーに次のいずれかの用語を入力します。
   + **ami-ecs**
   + Amazon ECS 最適化 AMI の **[Value]** (値)。

     最新の Amazon ECS 最適化 AMI とその値については、「[Linux Amazon ECS に最適化された AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux)」を参照してください。

1. **[Enter]** キーを押します。

1. **[Choose an Amazon Machine Image (AMI)]** (Amazon マシンイメージ (AMI) を選択) ページで、**[AWS Marketplace AMIs]** タブを選択します。

1. 左側の **[結果を絞り込む]** ペインから、**[Amazon Web Services]** を **[パブリッシャー]** として選択します。

1. 使用する AMI の行で **[Select]** (選択) を選択します。

   または、**[Cancel]** (キャンセル) (右上) を選択することで、AMI を選択せずにインスタンス起動ウィザードに戻ります。デフォルトの AMI が選択されます。AMI が、「[Amazon ECS に最適化された Linux AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)」で概説されている要件を満たしていることを確認します。

## インスタンスタイプ
<a name="linux-liw-instance-type"></a>

インスタンスタイプは、インスタンスのハードウェア設定とサイズを定義します。インスタンスタイプが大きくなると、CPU およびメモリも増えます。詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。IPv6 のみのワークロードを実行する場合、一部のインスタンスタイプでは IPv6 アドレスがサポートされません。詳細については、Amazon EC2 ユーザーガイドの [IPv6 アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing)を参照してください。
+ **[Instance type]** (インスタンスタイプ) で、インスタンスのインスタンスタイプを選択します。

   選択したインスタンスタイプによって、タスクの実行に使用できるリソースが決まります。

## キーペア (ログイン)
<a name="linux-liw-key-pair"></a>

**[Key pair name]** (キーペア名) には、既存のキーペアを選択するか、**[Create new key pair]** (新しいキーペアを作成) を選択して新しいキーペアを作成します。

**重要**  
[**Proceed without key pair**] (キーペアなしで進む) オプションを選択した場合 (非推奨)、ユーザーが別の方法でログインすることを許可するように設定された AMI を選択した場合でなければ、インスタンスに接続できなくなります。

## ネットワーク設定
<a name="linux-liw-network-settings"></a>

フォームのネットワーク設定セクションの **[編集]** ボタンを選択した後、必要に応じて **[ネットワーク設定]** を構成します。
+ **[VPC]** で、DB インスタンスを起動する先の VPC を選択します。IPv6 のみのワークロードを実行するには、IPv4 と IPv6 CIDR ブロックの両方を含むデュアルスタック VPC を選択します。
+ **[サブネット]** で、インスタンスを起動するサブネットを選択します。インスタンスは、アベイラビリティーゾーン、ローカルゾーン、Wavelength Zone、Outpost のいずれかに関連付けられたサブネットで起動できます。

  アベイラビリティーゾーンでインスタンスを起動するには、インスタンスを起動するサブネットを選択します。新しいサブネットを作成するには、[**Create new subnet**] を選択して Amazon VPC コンソールに移動します。終了したらインスタンス起動ウィザードに戻り、[Refresh] (更新) アイコンを選択して一覧にサブネットを読み込みます。

  ローカルゾーンでインスタンスを起動するには、ローカルゾーン内に作成したサブネットを選択します。

  アウトポストでインスタンスを起動するには、アウトポストに関連付けられた VPC 内のサブネットを選択します。

  IPv6 のみのワークロードを実行するには、IPv6 CIDR ブロックのみを含むサブネットを選択します。
+ **[Auto-assign Public IP]** (パブリック IP の自動割り当て): インスタンスをインターネットからアクセス可能にする場合は、**[Auto-assign Public IP]** (パブリック IP の自動割り当て) フィールドが **[Enable]** (有効) に設定されていることを確認します。可能にしない場合には、このフィールドを [**無効**] に設定します。
**注記**  
コンテナインスタンスには、Amazon ECS サービスエンドポイントと通信するためのアクセスが必要です。これは、インターフェイス VPC エンドポイントを介して、またはパブリック IP アドレスを持つコンテナインスタンスを通じて可能になります。  
インターフェイス VPC エンドポイントについての詳細は、「[Amazon ECS とインターフェイス VPC エンドポイント (AWS PrivateLink)](vpc-endpoints.md)」を参照してください。  
インターフェイス VPC エンドポイントが設定されておらず、コンテナインスタンスがパブリック IP アドレスを持たない場合、ネットワークアドレス変換 (NAT) を使用してこのアクセスを提供する必要があります。詳細については、「*Amazon VPC ユーザーガイド*」の「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」、およびこのガイドの「[Amazon ECS Linux コンテナインスタンスに HTTP プロキシを使用する](http_proxy_config.md)」を参照してください。
+ デュアルスタック VPC と IPv6 のみのサブネットを選択した場合、**[自動割り当て IPv6 IP]** で **[有効化]** を選択します。
+ **[Firewall (security groups)]** (ファイアウォール (セキュリティグループ)): セキュリティグループを使用して、コンテナインスタンスのファイアウォールルールを定義します。このルールでは、どの着信ネットワークトラフィックをコンテナインスタンスに配信するかを指定します。他のトラフィックはすべて無視されます。
  + 既存のセキュリティグループを選択するには、**[Select existing security group]** (既存のセキュリティグループを選択) を選択し、[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md) で作成したセキュリティグループを選択します。
+ IPv6 のみのワークロードのインスタンスを起動する場合は、**[高度なネットワーク設定]** を選択し、**[プライマリ IPv6 IP の割り当て]** に **[はい]** を選択します。
**注記**  
プライマリ IPv6 アドレスがない場合、ホストまたはブリッジネットワークモードのコンテナインスタンスで実行されているタスクは、ロードバランサーまたは AWS Cloud Map に登録されません。

## ストレージの設定
<a name="linux-liw-storage"></a>

選択した AMI には、ルートボリュームを含む、1 つまたは複数のストレージボリュームが含まれます。インスタンスにアタッチする追加のボリュームを指定できます。

**[Simple]** (シンプル) ビューを使用できます。
+ **[Storage type]** (ストレージタイプ): コンテナインスタンスのストレージを設定します。

  Amazon ECS に最適化された Amazon Linux 2 AMI を使用している場合、1 つの 30 GiB ボリュームがインスタンスに設定されます。これは、オペレーティングシステムと Docker の間で共有されます。

  Amazon ECS に最適化された AMI を使用している場合、インスタンスには 2 つのボリュームが設定されます。[**Root**] ボリュームはオペレーティングシステム用で、2 番目の Amazon EBS ボリューム (`/dev/xvdcz` にアタッチ) は Docker 用です。

  オプションで、アプリケーションのニーズに合わせてインスタンスのボリュームサイズを増減できます。

## 高度な詳細
<a name="linux-liw-advanced-details"></a>

[**Advanced details**] で、セクションを開いてフィールドを表示し、インスタンスの追加パラメータを指定します。
+ **[Purchasing option]** (購入のオプション): **[Request Spot Instances]** (スポットインスタンスのリクエスト) を選択して、スポットインスタンスをリクエストします。また、スポットインスタンスに関連する他のフィールドも設定する必要があります。詳細については、「[スポットインスタンスのリクエスト](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html)」を参照してください。
**注記**  
スポットインスタンスを使用していて、"`Not available`" メッセージが表示される場合は、別のインスタンスタイプを選択する必要があります。
+ **[IAM instance profile]** (IAM インスタンスプロフィール): コンテナインスタンス IAM ロールを選択します。通常、これは `ecsInstanceRole` という名前です。
**重要**  
適切な IAM アクセス許可を使用してコンテナインスタンスを起動しないと、Amazon ECS エージェントはクラスターに接続できません。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
+ **[ユーザーデータ]**: [Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)からのエージェント環境変数のようなユーザーデータを使用して、Amazon ECS コンテナインスタンスを設定します。Amazon EC2 ユーザーデータスクリプトはインスタンスの初回起動時に 1 回のみ実行されます。以下に、ユーザーデータを使用する目的の一般的な例を紹介します。
  + デフォルトでは、コンテナインスタンスはデフォルトのクラスターで起動されます。デフォルト以外のクラスターで起動するには、**[Advanced Details]** (高度な詳細) リストを選択します。次に、[**User data**] フィールドに以下のスクリプトを貼り付け、*your\$1cluster\$1name* を使用するクラスターの名前に置き換えます。

    ```
    #!/bin/bash
    echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config
    ```
  + Amazon S3 に `ecs.config` ファイルがあり、コンテナインスタンスロールへの Amazon S3 読み取り専用アクセスを有効にしている場合は、[**高度な詳細**] リストを選択します。次に、[**User data (ユーザーデータ)**] フィールドに以下のスクリプトを貼り付け、*your\$1bucket\$1name* を、AWS CLI をインストールして起動時に設定ファイルを書き込むバケットに置き換えます。
**注記**  
この設定の詳細については、「[Amazon S3 に Amazon ECS コンテナインスタンスの設定を保存する](ecs-config-s3.md)」を参照してください。

    ```
    #!/bin/bash
    yum install -y aws-cli
    aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
    ```
  + `ECS_CONTAINER_INSTANCE_TAGS` 設定パラメータを使用して、コンテナインスタンスのタグを指定します。これにより Amazon ECS にのみ関連付けられているタグが作成され、そのタグは Amazon EC2 API ではリスト取得できません。
**重要**  
Amazon EC2 Auto Scaling グループを使用してコンテナインスタンスを起動する場合は、ECS\$1CONTAINER\$1INSTANCE\$1TAGS エージェント設定パラメータを使用してタグを追加する必要があります。これは、Auto Scaling グループを使用して起動される Amazon EC2 インスタンスにタグを追加する方法によるものです。

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_CONTAINER_INSTANCE_TAGS={"tag_key": "tag_value"}
    EOF
    ```
  + コンテナインスタンスのタグを指定してから、`ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM` 設定パラメータを使用してそれらを Amazon EC2 から Amazon ECS に伝播します。

    次に、コンテナインスタンスに関連付けられたタグを伝達し、さらに `your_cluster_name` という名前のクラスターでコンテナインスタンスを登録するユーザーデータスクリプトの例を示します。

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM=ec2_instance
    EOF
    ```
  + デフォルトでは、Amazon ECS コンテナエージェントは、インスタンスのデフォルト IPv4 および IPv6 ルートを確認することで、そのコンテナインスタンスが IPv6-only 設定に対応しているかどうかを検出します。この動作を上書きするには、インスタンスの `/etc/ecs/ecs.config` ファイルで ` ECS_INSTANCE_IP_COMPATIBILITY` パラメータを `ipv4` または `ipv6` に設定してください。

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_INSTANCE_IP_COMPATIBILITY=ipv6
    EOF
    ```

  詳細については、「[Amazon ECS Linux コンテナインスタンスをブートストラップしてデータを渡す](bootstrap_container_instance.md)」を参照してください。

# Amazon ECS Linux コンテナインスタンスをブートストラップしてデータを渡す
<a name="bootstrap_container_instance"></a>

Amazon EC2 インスタンスを起動するときに、ユーザーデータを EC2 インスタンスに渡すことができます。インスタンスの起動時に、データを使って、一般的な自動設定タスクを実行したり、スクリプトを実行したりできます。Amazon ECS では、ユーザーデータの最も一般的なユースケースは、設定情報を Docker デーモンと Amazon ECS コンテナエージェントに渡すことです。

クラウドブートフック、シェルスクリプト、`cloud-init` ディレクティブなど、複数タイプのユーザーデータを Amazon EC2 に渡すことができます。これらおよびその他の形式の種類の詳細については、「[Cloud-Init のドキュメント](https://cloudinit.readthedocs.io/en/latest/explanation/format.html)」を参照してください。

Amazon EC2 起動ウィザードの使用時にユーザーデータを渡すには、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。

コンテナインスタンスがデータを渡すようにするための設定を、コンテナエージェント設定または Docker デーモン設定で行うことができます。

## Amazon ECS コンテナエージェント
<a name="bootstrap_container_agent"></a>

Amazon ECS に最適化された AMI の Linux バリアントは、コンテナエージェントの開始時に `/etc/ecs/ecs.config` ファイルでエージェント設定データを検索します。Amazon EC2 ユーザーデータを使用して、起動時に、この設定データを指定することができます。利用可能な Amazon ECS コンテナエージェントの設定変数の詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。

クラスター名など、単一エージェントの設定変数のみを設定するには、**echo** を使用して、変数を設定ファイルにコピーします。

```
#!/bin/bash
echo "ECS_CLUSTER=MyCluster" >> /etc/ecs/ecs.config
```

`/etc/ecs/ecs.config` に書き込む変数が複数ある場合は、以下の `heredoc` 形式を使用します。この形式は **cat** で始まる行と `EOF` の間のすべてを設定ファイルに書き込みます。

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
ECS_LOGLEVEL=debug
ECS_WARM_POOLS_CHECK=true
EOF
```

カスタムインスタンス属性を設定するには、`ECS_INSTANCE_ATTRIBUTES` 環境変数を設定します。

```
#!/bin/bash
cat <<'EOF' >> ecs.config
ECS_INSTANCE_ATTRIBUTES={"envtype":"prod"}
EOF
```

## Docker デーモン
<a name="bootstrap_docker_daemon"></a>

Docker デーモンの構成情報は Amazon EC2 ユーザーデータで指定できます。設定オプションの詳細については、「[Docker デーモンのドキュメント](https://docs.docker.com/reference/cli/dockerd/)」を参照してください。

**注記**  
カスタム Docker 設定は、将来の Amazon ECS の変更や機能と警告なしに競合する可能性があるため、AWS はサポートしていません。

以下の例では、カスタムオプションが Docker デーモン構成ファイル `/etc/docker/daemon.json` に追加され、インスタンスの起動時にユーザーデータで指定されます。

```
#!/bin/bash
cat <<EOF >/etc/docker/daemon.json
{"debug": true}
EOF
systemctl restart docker --no-block
```

以下の例では、カスタムオプションが Docker デーモン構成ファイル `/etc/docker/daemon.json` に追加され、インスタンスの起動時にユーザーデータで指定されます。この例は、Docker デーモン設定ファイルの docker-proxy を無効にする方法を示します。

```
#!/bin/bash
cat <<EOF >/etc/docker/daemon.json
{"userland-proxy": false}
EOF
systemctl restart docker --no-block
```

# スポットインスタンス通知を受信するように Amazon ECS Linux コンテナインスタンスを設定する
<a name="spot-instance-draining-linux-container"></a>

利用可能なキャパシティーがなくなった場合、または、スポット料金がお客様のリクエストの上限料金を超えた場合には、Amazon EC2 はスポットインスタンスを終了、停止、または休止状態にします。Amazon EC2 は、終了アクションおよび停止アクションに対して、スポットインスタンスに 2 分間の中断通知を提供します。休止状態のアクションについては、2 分間の通知は提供されません。インスタンスで Amazon ECS スポットインスタンスドレイニングが有効になっている場合、Amazon ECS はスポットインスタンスの中断通知を受け取り、インスタンスを `DRAINING` ステータスにします。

**重要**  
自動スケーリングキャパシティの再分散よってインスタンスが削除された場合、Amazon ECS は Amazon EC2 から通知を受信しません。詳細については、「[Amazon EC2 Auto Scaling キャパシティの再分散](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html)」を参照してください。

コンテナインスタンスを `DRAINING` に設定すると、Amazon ECS によって新規タスクがそのコンテナインスタンスに配置されなくなります。ドレインしているコンテナインスタンス上にある `PENDING` 状態のサービスタスクは即時停止されます。クラスター内に使用可能なコンテナインスタンスがある場合、そのインスタンスで代わりのサービスタスクが開始されます。

デフォルトでは、スポットインスタンスドレイニングは無効になっています。

インスタンスの起動時にスポットインスタンスドレイニングを有効にできます。次のスクリプトを **[ユーザーデータ]** フィールドに追加します。*MyCluster* は、コンテナインスタンスを登録するクラスターの名前に置き換えてください。

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
EOF
```

詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。

**既存のコンテナインスタンスに対してスポットインスタンスのドレインを有効にするには**

1. SSH 経由でスポットインスタンスに接続します。

1. `/etc/ecs/ecs.config` ファイルを編集して、以下を追加します。

   ```
   ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
   ```

1. `ecs` サービスを再起動します。
   + Amazon ECS に最適化された Amazon Linux 2 AMI の場合:

     ```
     sudo systemctl restart ecs
     ```

1. (オプション) エージェント詳細分析 API オペレーションをクエリして、エージェントが実行されていることを確認し、新しいコンテナインスタンスに関する情報の一部を表示できます。詳細については、「[Amazon ECS コンテナの詳細分析](ecs-agent-introspection.md)」を参照してください。

   ```
   curl http://localhost:51678/v1/metadata
   ```

# Amazon ECS Linux コンテナインスタンスの起動時にスクリプトを実行する
<a name="start_task_at_launch"></a>

すべてのコンテナインスタンスで特定のコンテナを実行して、モニタリング、セキュリティ、メトリクス、サービス検出、ログ記録などのオペレーションやセキュリティの問題に対処する必要がある場合があります。

これを行うには、起動時にユーザーデータスクリプトで、または Upstart や **systemd** などの一部の init システムで、**docker run** コマンドを呼び出すように、コンテナインスタンスを設定できます。これは機能しますが、いくつかの欠点があります。Amazon ECS は、コンテナに関する情報を渡されず、CPU、メモリ、ポートなどのリソースをモニタリングできないためです。Amazon ECS がすべてのタスクリソースについて適切に情報を得られるように、コンテナインスタンスで実行するコンテナのタスク定義を作成します。その後、Amazon ECS を使用して、起動時に Amazon EC2 ユーザーデータを渡してタスクを配置します。

以下の手順の Amazon EC2 ユーザーデータスクリプトは、Amazon ECS イントロスペクション API を使用してコンテナインスタンスを識別します。次に、AWS CLI と **start-task** コマンドを使用して、指定されたタスクをスタートアップ時に実行します。

**コンテナインスタンスの起動時にタスクを開始するには**

1. `ecsInstanceRole` IAM ロールを変更して、`StartTask` API オペレーションに対するアクセス権限を追加します。詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに対するアクセス許可を更新する](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-permissions.html)」を参照してください。

1. Amazon ECS に最適化された Amazon Linux 2 AMI を使用して、1 つ以上のコンテナインスタンスを起動します。新しいコンテナインスタンスを起動し、EC2 ユーザーデータで次のサンプルスクリプトを使用します。*your\$1cluster\$1name* は、コンテナインスタンスに登録するクラスターに置き換え、*my\$1task\$1def* は、起動時にインスタンスで実行するタスク定義に置き換えてください。

   詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。
**注記**  
以下の MIME マルチパートの内容では、シェルスクリプトを使用して値を設定し、パッケージをインストールしています。また、systemd ジョブを使用して、**ecs** サービスが実行されイントロスペクション API が使用可能になった後にタスクが開始されるようにしています。

   ```
   Content-Type: multipart/mixed; boundary="==BOUNDARY=="
   MIME-Version: 1.0
   
   --==BOUNDARY==
   Content-Type: text/x-shellscript; charset="us-ascii"
   
   #!/bin/bash
   # Specify the cluster that the container instance should register into
   cluster=your_cluster_name
   
   # Write the cluster configuration variable to the ecs.config file
   # (add any other configuration variables here also)
   echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config
   
   START_TASK_SCRIPT_FILE="/etc/ecs/ecs-start-task.sh"
   cat <<- 'EOF' > ${START_TASK_SCRIPT_FILE}
   	exec 2>>/var/log/ecs/ecs-start-task.log
   	set -x
   	
   	# Install prerequisite tools
   	yum install -y jq aws-cli
   	
   	# Wait for the ECS service to be responsive
   	until curl -s http://localhost:51678/v1/metadata
   	do
   		sleep 1
   	done
   
   	# Grab the container instance ARN and AWS Region from instance metadata
   	instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F/ '{print $NF}' )
   	cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' )
   	region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}')
   
   	# Specify the task definition to run at launch
   	task_definition=my_task_def
   
   	# Run the AWS CLI start-task command to start your task on this container instance
   	aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region
   EOF
   
   # Write systemd unit file
   UNIT="ecs-start-task.service"
   cat <<- EOF > /etc/systemd/system/${UNIT}
         [Unit]
         Description=ECS Start Task
         Requires=ecs.service
         After=ecs.service
    
         [Service]
         Restart=on-failure
         RestartSec=30
         ExecStart=/usr/bin/bash ${START_TASK_SCRIPT_FILE}
   
         [Install]
         WantedBy=default.target
   EOF
   
   # Enable our ecs.service dependent service with `--no-block` to prevent systemd deadlock
   # See https://github.com/aws/amazon-ecs-agent/issues/1707
   systemctl enable --now --no-block "${UNIT}"
   --==BOUNDARY==--
   ```

1. コンテナインスタンスが正しいクラスターで起動し、タスクが開始されていることを確認します。

   1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

   1. ナビゲーションバーから、クラスターがあるリージョンを選択します。

   1. ナビゲーションペインで [**Clusters**] を選択し、コンテナインスタンスをホストするクラスターを選択します。

   1. **[クラスター]** ページで **[タスク]** を選択した後、使用するタスクを選択します。

      起動した各コンテナインスタンスでは、このタスクが実行状態になります。

      タスクが表示されない場合は、SSH を使用してコンテナインスタンスにログインし、`/var/log/ecs/ecs-start-task.log` ファイルでデバッグの情報を確認できます。

# Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす
<a name="container-instance-eni"></a>

**注記**  
この機能は Fargate では使用できません。

`awsvpc` ネットワークモードを使用するタスクには、それぞれ独自の Elastic Network Interface (ENI) が提供されます。この ENI は、ENI をホストするコンテナインスタンスにアタッチされています。Amazon EC2 インスタンスにアタッチできるネットワークインターフェイスの数にはデフォルトの制限があり、プライマリネットワークインターフェイスも 1 つとしてカウントされます。例えば、デフォルトでは `c5.large` インスタンスには最大 3 つの ENI がアタッチされています。このインスタンスのプライマリネットワークインターフェイスも 1 つとしてカウントされるため、このインスタンスに追加でアタッチできる ENI は 2 つです。`awsvpc` ネットワークモードを使用する各タスクには ENI が必要なため、通常このインスタンスタイプでは、このようなタスクを 2 つだけ実行できます。

Amazon ECS は、サポートされている Amazon EC2 インスタンスタイプを使用して、ENI 密度が高いコンテナインスタンスの起動をサポートしています。これらのインスタンスタイプを使用し、`awsvpcTrunking` アカウント設定を有効にすると、新しく起動されたコンテナインスタンスで追加の ENI を利用できます。この設定により、各コンテナインスタンスにより多くのタスクを配置できます。コンソールを使用して機能を有効にするには、「[Amazon ECS アカウント設定の変更](ecs-modifying-longer-id-settings.md)」を参照してください。AWS CLI を使用して機能を有効にするには、「[AWS CLI を使用した Amazon ECS アカウント設定の管理](account-setting-management-cli.md)」を参照してください。

例えば、`awsvpcTrunking` を持つ `c5.large` インスタンスでは、ENI の制限が 12 に引き上げられています。コンテナインスタンスはプライマリネットワークインターフェイスを持ち、Amazon ECS はコンテナインスタンスの「トランク」ネットワークインターフェイスを作成およびアタッチします。したがって、この設定では、現在の 2 個ではなく 10 個のタスクをコンテナインスタンスで起動できます。

トランクネットワークインターフェイスは Amazon ECS によって完全に管理され、コンテナインスタンスを削除またはクラスターから登録解除するときに削除されます。詳細については、「[EC2 の Amazon ECS タスクネットワークオプション](task-networking.md)」を参照してください。

## 考慮事項
<a name="eni-trunking-considerations"></a>

ENI トランキング機能を使用する場合は、以下の点を考慮してください。
+ ENI の制限引き上げに対応しているのは、Amazon ECS に最適化された AMI の Linux バリアント、バージョン `1.28.1` 以降のコンテナエージェントを備えたその他の Amazon Linux バリアント、バージョン `1.28.1-2` 以降の ecs-init パッケージのみです。Amazon ECS に最適化された AMI の最新の Linux バリアントを使用する場合、これらの要件が満たされます。現時点では、Windows コンテナはサポートされていません。
+ `awsvpcTrunking` を有効にした後に起動した新しい Amazon EC2 インスタンスのみに、引き上げられた ENI 制限とトランクネットワークインターフェイスが適用されます。以前に起動されたインスタンスは、実行されたアクションに関係なく、これらの機能を受け取りません。
+ Amazon EC2 インスタンスでは、リソースベースの IPv4 DNS リクエストがオフになっている必要があります。このオプションを無効にする場合、Amazon EC2 コンソールをで新しいインスタンスを作成する際に、**[Enable resource-based IPV4 (A record) DNS requests](リソースベースの IPV4 (A レコード) DNS リクエストを有効化)** オプションの選択を外します。AWS CLI を使ってこのオプションを無効にするには、次のコマンドを使用します。

  ```
  aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
  ```
+ 共有サブネットの Amazon EC2 インスタンスはサポートされません。これらを使用すると、クラスターへの登録に失敗します。
+ タスクは、`awsvpc` ネットワークモードと EC2 を使用する必要があります。Fargate を使用するタスクは、起動数に関係なく、常に専用の ENI が割り当てられるため、この機能は必要ありません。
+ タスクは、コンテナインスタンスと同じ Amazon VPC で起動する必要があります。タスクが同じ VPC 内にない場合は属性エラーが発生し、タスクを開始することができません。
+ 新しいコンテナインスタンスを起動するときに、インスタンスは `REGISTERING` 状態に移行し、トランク Elastic Network Interface がインスタンスに対してプロビジョニングされます。登録に失敗した場合、インスタンスは `REGISTRATION_FAILED` 状態に移行します。失敗した登録のトラブルシューティングを行うには、コンテナインスタンスを記述して、失敗の原因を説明する `statusReason` フィールドを表示するようにします。その後、コンテナインスタンスは手動で登録解除または終了できます。コンテナインスタンスが正常に登録解除または終了すると、Amazon ECS はトランク ENI を削除します。
**注記**  
Amazon ECS は、`REGISTRATION_FAILED` 状態に移行するインスタンスを監視できるコンテナインスタンスの状態変更イベントを発行します。詳細については、「[Amazon ECS コンテナインスタンス状態変更イベント](ecs_container_instance_events.md)」を参照してください。
+ コンテナインスタンスが削除されると、インスタンスは `DEREGISTERING` 状態に移行し、トランク Elastic Network Interface が解放されます。次に、インスタンスは `INACTIVE` 状態に移行します。
+ ENI 制限が引き上げられたパブリックサブネットのコンテナインスタンスが停止した後再起動されると、インスタンスはパブリック IP アドレスを失い、コンテナエージェントは接続を失います。
+ `awsvpcTrunking` を有効にすると、コンテナインスタンスは VPC のデフォルトセキュリティグループを使用する追加の ENI が割り当てられ、Amazon ECS によって管理されます。

  デフォルト VPC には、各アベイラビリティーゾーンのパブリックサブネット、インターネットゲートウェイ、および DNS 解決を有効にするための設定があります。サブネットはパブリックサブネットです。メインルートテーブルがインターネット用のサブネットのトラフィックをインターネットゲートウェイに送信するためです。デフォルトサブネットをプライベートサブネットにするには、送信元 0.0.0.0/0 からインターネットゲートウェイへのルートを削除します。ただし、この操作を行った場合、そのサブネットで実行されているすべてのコンテナインスタンスがインターネットにアクセスできなくなります。セキュリティグループルールを追加または削除して、サブネットに出入りするトラフィックを制御できます。詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[セキュリティグループのルール](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)」を参照してください。

## 前提条件
<a name="eni-trunking-launching"></a>

ENI 制限が引き上げられたコンテナインスタンスを起動する前に、次の前提条件を満たす必要があります。
+ Amazon ECS のサービスにリンクされたロールを作成する必要があります。Amazon ECS のサービスにリンクされたロールは、Amazon ECS に、お客様に代わって他のAWSサービスを呼び出すアクセス権限を付与します。このロールは、クラスターを作成する際、または AWS マネジメントコンソール でサービスを作成または更新すると、自動的に作成されます。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。サービスにリンクされたロールは、次の AWS CLI コマンドを使用して作成することもできます。

  ```
  aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
  ```
+ お客様のアカウントまたはコンテナインスタンスの IAM ロールは、`awsvpcTrunking` アカウント設定に有効化する必要があります。2 つのコンテナインスタンスロール (`ecsInstanceRole`) を作成することをお勧めします。そして、1 つのロールの `awsvpcTrunking` アカウント設定を有効にして、そのロールを ENI トランキングを必要とするタスクに使用することができます。コンテナインスタンスロールについては、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。

前提条件が満たされると、サポートされているいずれかの Amazon EC2 インスタンスタイプを使用して新しいコンテナインスタンスを起動でき、インスタンスの ENI 制限が引き上げられています。サポートされているインスタンスタイプについては[Amazon ECS コンテナネットワークインターフェイスの増加でサポートされるインスタンス](eni-trunking-supported-instance-types.md)を参照してください。コンテナインスタンスで、バージョン `1.28.1` 以降のコンテナエージェントと、バージョン `1.28.1-2` 以降の ecs-init パッケージが必要です。Amazon ECS に最適化された AMI の最新の Linux バリアントを使用する場合、これらの要件が満たされます。詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。

**重要**  
Amazon EC2 インスタンスでは、リソースベースの IPv4 DNS リクエストがオフになっている必要があります。このオプションを無効にする場合は、Amazon EC2 コンソールを使用した新しいインスタンスの作成時に **[Enable resource-based IPV4 (A record) DNS requests]** (リソースベースの IPV4 (A レコード) DNS リクエストを有効化) オプションを選択していないことを確認してください。AWS CLI を使ってこのオプションを無効にするには、次のコマンドを使用します。  

```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```

**AWS CLI を使用して、ENI 制限が引き上げられたコンテナインスタンスを表示するには**

各コンテナインスタンスにはデフォルトのネットワークインターフェイスがあり、これはトランクネットワークインターフェイストランクと呼ばれます。トランクネットワークインターフェイスがあることを示す `ecs.awsvpc-trunk-id` 属性のクエリを実行して、ENI 制限が引き上げられたコンテナインスタンスを一覧表示するには、次のコマンドを使用します。
+ [list-attributes](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-attributes.html) (AWS CLI)

  ```
  aws ecs list-attributes \
        --target-type container-instance \
        --attribute-name ecs.awsvpc-trunk-id \
        --cluster cluster_name \
        --region us-east-1
  ```
+ [Get-ECSAttributeList](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ECSAttributeList.html) (AWS Tools for Windows PowerShell)

  ```
  Get-ECSAttributeList -TargetType container-instance -AttributeName ecs.awsvpc-trunk-id -Region us-east-1
  ```

# Amazon ECS コンテナネットワークインターフェイスの増加でサポートされるインスタンス
<a name="eni-trunking-supported-instance-types"></a>

以下に示しているのは、サポートされる Amazon EC2 インスタンスタイプと、`awsvpcTrunking` アカウント設定を有効化する前後で各インスタンスタイプにおいて `awsvpc` ネットワークモードを使用して起動できるタスクの数です。

**重要**  
同じインスタンスファミリーでは、他のインスタンスタイプがサポートされていますが、`a1.metal`、`c5.metal`、`c5a.8xlarge`、`c5ad.8xlarge`、`c5d.metal`、`m5.metal`、`p3dn.24xlarge`、`r5.metal`、`r5.8xlarge`、`r5d.metal` の各インスタンスタイプはサポートされていません。  
`c5n`、`d3`、`d3en`、`g3`、`g3s`、`g4dn`、`i3`、`i3en`、`inf1`、`m5dn`、`m5n`、`m5zn`、`mac1`、`r5b`、`r5n`、`r5dn`、`u-12tb1`、`u-6tb1`、`u-9tb1`、および `z1d` インスタンスファミリーはサポートされていません。

**Topics**
+ [汎用](#eni-branch-gp)
+ [コンピューティングの最適化](#eni-branch-co)
+ [メモリ最適化](#eni-branch-mo)
+ [ストレージの最適化](#eni-branch-so)
+ [高速コンピューティング](#eni-branch-ac)
+ [ハイパフォーマンスコンピューティング](#eni-branch-hpc)

## 汎用
<a name="eni-branch-gp"></a>


| インスタンスタイプ | ENI トランキングなしのタスク制限 | ENI トランキングありのタスク制限 | 
| --- | --- | --- | 
| a1.medium | 1 | 10 | 
| a1.large | 2 | 10 | 
| a1.xlarge | 3 | 20 | 
| a1.2xlarge | 3 | 40 | 
| a1.4xlarge | 7 | 60 | 
| m5.large | 2 | 10 | 
| m5.xlarge | 3 | 20 | 
| m5.2xlarge | 3 | 40 | 
| m5.4xlarge | 7 | 60 | 
| m5.8xlarge | 7 | 60 | 
| m5.12xlarge | 7 | 60 | 
| m5.16xlarge | 14 | 120 | 
| m5.24xlarge | 14 | 120 | 
| m5a.large | 2 | 10 | 
| m5a.xlarge | 3 | 20 | 
| m5a.2xlarge | 3 | 40 | 
| m5a.4xlarge | 7 | 60 | 
| m5a.8xlarge | 7 | 60 | 
| m5a.12xlarge | 7 | 60 | 
| m5a.16xlarge | 14 | 120 | 
| m5a.24xlarge | 14 | 120 | 
| m5ad.large | 2 | 10 | 
| m5ad.xlarge | 3 | 20 | 
| m5ad.2xlarge | 3 | 40 | 
| m5ad.4xlarge | 7 | 60 | 
| m5ad.8xlarge | 7 | 60 | 
| m5ad.12xlarge | 7 | 60 | 
| m5ad.16xlarge | 14 | 120 | 
| m5ad.24xlarge | 14 | 120 | 
| m5d.large | 2 | 10 | 
| m5d.xlarge | 3 | 20 | 
| m5d.2xlarge | 3 | 40 | 
| m5d.4xlarge | 7 | 60 | 
| m5d.8xlarge | 7 | 60 | 
| m5d.12xlarge | 7 | 60 | 
| m5d.16xlarge | 14 | 120 | 
| m5d.24xlarge | 14 | 120 | 
| m5d.metal | 14 | 120 | 
| m6a.large | 2 | 10 | 
| m6a.xlarge | 3 | 20 | 
| m6a.2xlarge | 3 | 40 | 
| m6a.4xlarge | 7 | 60 | 
| m6a.8xlarge | 7 | 90 | 
| m6a.12xlarge | 7 | 120 | 
| m6a.16xlarge | 14 | 120 | 
| m6a.24xlarge | 14 | 120 | 
| m6a.32xlarge | 14 | 120 | 
| m6a.48xlarge | 14 | 120 | 
| m6a.metal | 14 | 120 | 
| m6g.medium | 1 | 4 | 
| m6g.large | 2 | 10 | 
| m6g.xlarge | 3 | 20 | 
| m6g.2xlarge | 3 | 40 | 
| m6g.4xlarge | 7 | 60 | 
| m6g.8xlarge | 7 | 60 | 
| m6g.12xlarge | 7 | 60 | 
| m6g.16xlarge | 14 | 120 | 
| m6g.metal | 14 | 120 | 
| m6gd.medium | 1 | 4 | 
| m6gd.large | 2 | 10 | 
| m6gd.xlarge | 3 | 20 | 
| m6gd.2xlarge | 3 | 40 | 
| m6gd.4xlarge | 7 | 60 | 
| m6gd.8xlarge | 7 | 60 | 
| m6gd.12xlarge | 7 | 60 | 
| m6gd.16xlarge | 14 | 120 | 
| m6gd.metal | 14 | 120 | 
| m6i.large | 2 | 10 | 
| m6i.xlarge | 3 | 20 | 
| m6i.2xlarge | 3 | 40 | 
| m6i.4xlarge | 7 | 60 | 
| m6i.8xlarge | 7 | 90 | 
| m6i.12xlarge | 7 | 120 | 
| m6i.16xlarge | 14 | 120 | 
| m6i.24xlarge | 14 | 120 | 
| m6i.32xlarge | 14 | 120 | 
| m6i.metal | 14 | 120 | 
| m6id.large | 2 | 10 | 
| m6id.xlarge | 3 | 20 | 
| m6id.2xlarge | 3 | 40 | 
| m6id.4xlarge | 7 | 60 | 
| m6id.8xlarge | 7 | 90 | 
| m6id.12xlarge | 7 | 120 | 
| m6id.16xlarge | 14 | 120 | 
| m6id.24xlarge | 14 | 120 | 
| m6id.32xlarge | 14 | 120 | 
| m6id.metal | 14 | 120 | 
| m6idn.large | 2 | 10 | 
| m6idn.xlarge | 3 | 20 | 
| m6idn.2xlarge | 3 | 40 | 
| m6idn.4xlarge | 7 | 60 | 
| m6idn.8xlarge | 7 | 90 | 
| m6idn.12xlarge | 7 | 120 | 
| m6idn.16xlarge | 14 | 120 | 
| m6idn.24xlarge | 14 | 120 | 
| m6idn.32xlarge | 15 | 120 | 
| m6idn.metal | 15 | 120 | 
| m6in.large | 2 | 10 | 
| m6in.xlarge | 3 | 20 | 
| m6in.2xlarge | 3 | 40 | 
| m6in.4xlarge | 7 | 60 | 
| m6in.8xlarge | 7 | 90 | 
| m6in.12xlarge | 7 | 120 | 
| m6in.16xlarge | 14 | 120 | 
| m6in.24xlarge | 14 | 120 | 
| m6in.32xlarge | 15 | 120 | 
| m6in.metal | 15 | 120 | 
| m7a.medium | 1 | 4 | 
| m7a.large | 2 | 10 | 
| m7a.xlarge | 3 | 20 | 
| m7a.2xlarge | 3 | 40 | 
| m7a.4xlarge | 7 | 60 | 
| m7a.8xlarge | 7 | 90 | 
| m7a.12xlarge | 7 | 120 | 
| m7a.16xlarge | 14 | 120 | 
| m7a.24xlarge | 14 | 120 | 
| m7a.32xlarge | 14 | 120 | 
| m7a.48xlarge | 14 | 120 | 
| m7a.metal-48xl | 14 | 120 | 
| m7g.medium | 1 | 4 | 
| m7g.large | 2 | 10 | 
| m7g.xlarge | 3 | 20 | 
| m7g.2xlarge | 3 | 40 | 
| m7g.4xlarge | 7 | 60 | 
| m7g.8xlarge | 7 | 60 | 
| m7g.12xlarge | 7 | 60 | 
| m7g.16xlarge | 14 | 120 | 
| m7g.metal | 14 | 120 | 
| m7gd.medium | 1 | 4 | 
| m7gd.large | 2 | 10 | 
| m7gd.xlarge | 3 | 20 | 
| m7gd.2xlarge | 3 | 40 | 
| m7gd.4xlarge | 7 | 60 | 
| m7gd.8xlarge | 7 | 60 | 
| m7gd.12xlarge | 7 | 60 | 
| m7gd.16xlarge | 14 | 120 | 
| m7gd.metal | 14 | 120 | 
| m7i.large | 2 | 10 | 
| m7i.xlarge | 3 | 20 | 
| m7i.2xlarge | 3 | 40 | 
| m7i.4xlarge | 7 | 60 | 
| m7i.8xlarge | 7 | 90 | 
| m7i.12xlarge | 7 | 120 | 
| m7i.16xlarge | 14 | 120 | 
| m7i.24xlarge | 14 | 120 | 
| m7i.48xlarge | 14 | 120 | 
| m7i.metal-24xl | 14 | 120 | 
| m7i.metal-48xl | 14 | 120 | 
| m7i-flex.large | 2 | 4 | 
| M7i-flex.xlarge | 3 | 10 | 
| m7i-flex.2xlarge | 3 | 20 | 
| m7i-flex.4xlarge | 7 | 40 | 
| m7i-flex.8xlarge | 7 | 60 | 
| m7i-flex.12xlarge | 7 | 120 | 
| m7i-flex.16xlarge | 14 | 120 | 
| m8a.medium | 1 | 4 | 
| m8a.large | 2 | 10 | 
| m8a.xlarge | 3 | 20 | 
| m8a.2xlarge | 3 | 40 | 
| m8a.4xlarge | 7 | 60 | 
| m8a.8xlarge | 9 | 90 | 
| m8a.12xlarge | 11 | 120 | 
| m8a.16xlarge | 15 | 120 | 
| m8a.24xlarge | 15 | 120 | 
| m8a.48xlarge | 23 | 120 | 
| m8a.metal-24xl | 15 | 120 | 
| m8a.metal-48xl | 23 | 120 | 
| m8azn.medium | 2 | 4 | 
| m8azn.large | 3 | 10 | 
| m8azn.xlarge | 3 | 20 | 
| m8azn.3xlarge | 7 | 40 | 
| m8azn.6xlarge | 7 | 60 | 
| m8azn.12xlarge | 15 | 120 | 
| m8azn.24xlarge | 15 | 120 | 
| m8azn.metal-12xl | 15 | 120 | 
| m8azn.metal-24xl | 15 | 120 | 
| m8g.medium | 1 | 4 | 
| m8g.large | 2 | 10 | 
| m8g.xlarge | 3 | 20 | 
| m8g.2xlarge | 3 | 40 | 
| m8g.4xlarge | 7 | 60 | 
| m8g.8xlarge | 7 | 60 | 
| m8g.12xlarge | 7 | 60 | 
| m8g.16xlarge | 14 | 120 | 
| m8g.24xlarge | 14 | 120 | 
| m8g.48xlarge | 14 | 120 | 
| m8g.metal-24xl | 14 | 120 | 
| m8g.metal-48xl | 14 | 120 | 
| m8gb.medium | 1 | 4 | 
| m8gb.large | 2 | 10 | 
| m8gb.xlarge | 3 | 20 | 
| m8gb.2xlarge | 3 | 40 | 
| m8gb.4xlarge | 7 | 60 | 
| m8gb.8xlarge | 9 | 60 | 
| m8gb.12xlarge | 11 | 60 | 
| m8gb.16xlarge | 15 | 120 | 
| m8gb.24xlarge | 23 | 120 | 
| m8gb.48xlarge | 23 | 120 | 
| m8gb.metal-24xl | 23 | 120 | 
| m8gb.metal-48xl | 23 | 120 | 
| m8gd.medium | 1 | 4 | 
| m8gd.large | 2 | 10 | 
| m8gd.xlarge | 3 | 20 | 
| m8gd.2xlarge | 3 | 40 | 
| m8gd.4xlarge | 7 | 60 | 
| m8gd.8xlarge | 7 | 60 | 
| m8gd.12xlarge | 7 | 60 | 
| m8gd.16xlarge | 14 | 120 | 
| m8gd.24xlarge | 14 | 120 | 
| m8gd.48xlarge | 14 | 120 | 
| m8gd.metal-24xl | 14 | 120 | 
| m8gd.metal-48xl | 14 | 120 | 
| m8gn.medium | 1 | 4 | 
| m8gn.large | 2 | 10 | 
| m8gn.xlarge | 3 | 20 | 
| m8gn.2xlarge | 3 | 40 | 
| m8gn.4xlarge | 7 | 60 | 
| m8gn.8xlarge | 9 | 60 | 
| m8gn.12xlarge | 11 | 60 | 
| m8gn.16xlarge | 15 | 120 | 
| m8gn.24xlarge | 23 | 120 | 
| m8gn.48xlarge | 23 | 120 | 
| m8gn.metal-24xl | 23 | 120 | 
| m8gn.metal-48xl | 23 | 120 | 
| m8i.large | 2 | 10 | 
| m8i.xlarge | 3 | 20 | 
| m8i.2xlarge | 3 | 40 | 
| m8i.4xlarge | 7 | 60 | 
| m8i.8xlarge | 9 | 90 | 
| m8i.12xlarge | 11 | 120 | 
| m8i.16xlarge | 15 | 120 | 
| m8i.24xlarge | 15 | 120 | 
| m8i.32xlarge | 23 | 120 | 
| m8i.48xlarge | 23 | 120 | 
| m8i.96xlarge | 23 | 120 | 
| m8i.metal-48xl | 23 | 120 | 
| m8i.metal-96xl | 23 | 120 | 
| m8id.large | 2 | 10 | 
| m8id.xlarge | 3 | 20 | 
| m8id.2xlarge | 3 | 40 | 
| m8id.4xlarge | 7 | 60 | 
| m8id.8xlarge | 9 | 90 | 
| m8id.12xlarge | 11 | 120 | 
| m8id.16xlarge | 15 | 120 | 
| m8id.24xlarge | 15 | 120 | 
| m8id.32xlarge | 23 | 120 | 
| m8id.48xlarge | 23 | 120 | 
| m8id.96xlarge | 23 | 120 | 
| m8id.metal-48xl | 23 | 120 | 
| m8id.metal-96xl | 23 | 120 | 
| m8i-flex.large | 2 | 4 | 
| m8i-flex.xlarge | 3 | 10 | 
| m8i-flex.2xlarge | 3 | 20 | 
| m8i-flex.4xlarge | 7 | 40 | 
| m8i-flex.8xlarge | 9 | 60 | 
| m8i-flex.12xlarge | 11 | 120 | 
| m8i-flex.16xlarge | 15 | 120 | 
| mac2.metal | 7 | 12 | 
| mac2-m1ultra.metal | 7 | 12 | 
| mac2-m2.metal | 7 | 12 | 
| mac2-m2pro.metal | 7 | 12 | 
| mac-m4.metal | 7 | 12 | 
| mac-m4pro.metal | 7 | 12 | 

## コンピューティングの最適化
<a name="eni-branch-co"></a>


| インスタンスタイプ | ENI トランキングなしのタスク制限 | ENI トランキングありのタスク制限 | 
| --- | --- | --- | 
| c5.large | 2 | 10 | 
| c5.xlarge | 3 | 20 | 
| c5.2xlarge | 3 | 40 | 
| c5.4xlarge | 7 | 60 | 
| c5.9xlarge | 7 | 60 | 
| c5.12xlarge | 7 | 60 | 
| c5.18xlarge | 14 | 120 | 
| c5.24xlarge | 14 | 120 | 
| c5a.large | 2 | 10 | 
| c5a.xlarge | 3 | 20 | 
| c5a.2xlarge | 3 | 40 | 
| c5a.4xlarge | 7 | 60 | 
| c5a.12xlarge | 7 | 60 | 
| c5a.16xlarge | 14 | 120 | 
| c5a.24xlarge | 14 | 120 | 
| c5ad.large | 2 | 10 | 
| c5ad.xlarge | 3 | 20 | 
| c5ad.2xlarge | 3 | 40 | 
| c5ad.4xlarge | 7 | 60 | 
| c5ad.12xlarge | 7 | 60 | 
| c5ad.16xlarge | 14 | 120 | 
| c5ad.24xlarge | 14 | 120 | 
| c5d.large | 2 | 10 | 
| c5d.xlarge | 3 | 20 | 
| c5d.2xlarge | 3 | 40 | 
| c5d.4xlarge | 7 | 60 | 
| c5d.9xlarge | 7 | 60 | 
| c5d.12xlarge | 7 | 60 | 
| c5d.18xlarge | 14 | 120 | 
| c5d.24xlarge | 14 | 120 | 
| c6a.large | 2 | 10 | 
| c6a.xlarge | 3 | 20 | 
| c6a.2xlarge | 3 | 40 | 
| c6a.4xlarge | 7 | 60 | 
| c6a.8xlarge | 7 | 90 | 
| c6a.12xlarge | 7 | 120 | 
| c6a.16xlarge | 14 | 120 | 
| c6a.24xlarge | 14 | 120 | 
| c6a.32xlarge | 14 | 120 | 
| c6a.48xlarge | 14 | 120 | 
| c6a.metal | 14 | 120 | 
| c6g.medium | 1 | 4 | 
| c6g.large | 2 | 10 | 
| c6g.xlarge | 3 | 20 | 
| c6g.2xlarge | 3 | 40 | 
| c6g.4xlarge | 7 | 60 | 
| c6g.8xlarge | 7 | 60 | 
| c6g.12xlarge | 7 | 60 | 
| c6g.16xlarge | 14 | 120 | 
| c6g.metal | 14 | 120 | 
| c6gd.medium | 1 | 4 | 
| c6gd.large | 2 | 10 | 
| c6gd.xlarge | 3 | 20 | 
| c6gd.2xlarge | 3 | 40 | 
| c6gd.4xlarge | 7 | 60 | 
| c6gd.8xlarge | 7 | 60 | 
| c6gd.12xlarge | 7 | 60 | 
| c6gd.16xlarge | 14 | 120 | 
| c6gd.metal | 14 | 120 | 
| c6gn.medium | 1 | 4 | 
| c6gn.large | 2 | 10 | 
| c6gn.xlarge | 3 | 20 | 
| c6gn.2xlarge | 3 | 40 | 
| c6gn.4xlarge | 7 | 60 | 
| c6gn.8xlarge | 7 | 60 | 
| c6gn.12xlarge | 7 | 60 | 
| c6gn.16xlarge | 14 | 120 | 
| c6i.large | 2 | 10 | 
| c6i.xlarge | 3 | 20 | 
| c6i.2xlarge | 3 | 40 | 
| c6i.4xlarge | 7 | 60 | 
| c6i.8xlarge | 7 | 90 | 
| c6i.12xlarge | 7 | 120 | 
| c6i.16xlarge | 14 | 120 | 
| c6i.24xlarge | 14 | 120 | 
| c6i.32xlarge | 14 | 120 | 
| c6i.metal | 14 | 120 | 
| c6id.large | 2 | 10 | 
| c6id.xlarge | 3 | 20 | 
| c6id.2xlarge | 3 | 40 | 
| c6id.4xlarge | 7 | 60 | 
| c6id.8xlarge | 7 | 90 | 
| c6id.12xlarge | 7 | 120 | 
| c6id.16xlarge | 14 | 120 | 
| c6id.24xlarge | 14 | 120 | 
| c6id.32xlarge | 14 | 120 | 
| c6id.metal | 14 | 120 | 
| c6in.large | 2 | 10 | 
| c6in.xlarge | 3 | 20 | 
| c6in.2xlarge | 3 | 40 | 
| c6in.4xlarge | 7 | 60 | 
| c6in.8xlarge | 7 | 90 | 
| c6in.12xlarge | 7 | 120 | 
| c6in.16xlarge | 14 | 120 | 
| c6in.24xlarge | 14 | 120 | 
| c6in.32xlarge | 15 | 120 | 
| c6in.metal | 15 | 120 | 
| c7a.medium | 1 | 4 | 
| c7a.large | 2 | 10 | 
| c7a.xlarge | 3 | 20 | 
| c7a.2xlarge | 3 | 40 | 
| c7a.4xlarge | 7 | 60 | 
| c7a.8xlarge | 7 | 90 | 
| c7a.12xlarge | 7 | 120 | 
| c7a.16xlarge | 14 | 120 | 
| c7a.24xlarge | 14 | 120 | 
| c7a.32xlarge | 14 | 120 | 
| c7a.48xlarge | 14 | 120 | 
| c7a.metal-48xl | 14 | 120 | 
| c7g.medium | 1 | 4 | 
| c7g.large | 2 | 10 | 
| c7g.xlarge | 3 | 20 | 
| c7g.2xlarge | 3 | 40 | 
| c7g.4xlarge | 7 | 60 | 
| c7g.8xlarge | 7 | 60 | 
| c7g.12xlarge | 7 | 60 | 
| c7g.16xlarge | 14 | 120 | 
| c7g.metal | 14 | 120 | 
| c7gd.medium | 1 | 4 | 
| c7gd.large | 2 | 10 | 
| c7gd.xlarge | 3 | 20 | 
| c7gd.2xlarge | 3 | 40 | 
| c7gd.4xlarge | 7 | 60 | 
| c7gd.8xlarge | 7 | 60 | 
| c7gd.12xlarge | 7 | 60 | 
| c7gd.16xlarge | 14 | 120 | 
| c7gd.metal | 14 | 120 | 
| c7gn.medium | 1 | 4 | 
| c7gn.large | 2 | 10 | 
| c7gn.xlarge | 3 | 20 | 
| c7gn.2xlarge | 3 | 40 | 
| c7gn.4xlarge | 7 | 60 | 
| c7gn.8xlarge | 7 | 60 | 
| c7gn.12xlarge | 7 | 60 | 
| c7gn.16xlarge | 14 | 120 | 
| c7gn.metal | 14 | 120 | 
| c7i.large | 2 | 10 | 
| c7i.xlarge | 3 | 20 | 
| c7i.2xlarge | 3 | 40 | 
| c7i.4xlarge | 7 | 60 | 
| c7i.8xlarge | 7 | 90 | 
| c7i.12xlarge | 7 | 120 | 
| c7i.16xlarge | 14 | 120 | 
| c7i.24xlarge | 14 | 120 | 
| c7i.48xlarge | 14 | 120 | 
| c7i.metal-24xl | 14 | 120 | 
| c7i.metal-48xl | 14 | 120 | 
| c7i-flex.large | 2 | 4 | 
| c7i-flex.xlarge | 3 | 10 | 
| c7i-flex.2xlarge | 3 | 20 | 
| c7i-flex.4xlarge | 7 | 40 | 
| c7i-flex.8xlarge | 7 | 60 | 
| c7i-flex.12xlarge | 7 | 120 | 
| c7i-flex.16xlarge | 14 | 120 | 
| c8a.medium | 1 | 4 | 
| c8a.large | 2 | 10 | 
| c8a.xlarge | 3 | 20 | 
| c8a.2xlarge | 3 | 40 | 
| c8a.4xlarge | 7 | 60 | 
| c8a.8xlarge | 9 | 90 | 
| c8a.12xlarge | 11 | 120 | 
| c8a.16xlarge | 15 | 120 | 
| c8a.24xlarge | 15 | 120 | 
| c8a.48xlarge | 23 | 120 | 
| c8a.metal-24xl | 15 | 120 | 
| c8a.metal-48xl | 23 | 120 | 
| c8g.medium | 1 | 4 | 
| c8g.large | 2 | 10 | 
| c8g.xlarge | 3 | 20 | 
| c8g.2xlarge | 3 | 40 | 
| c8g.4xlarge | 7 | 60 | 
| c8g.8xlarge | 7 | 60 | 
| c8g.12xlarge | 7 | 60 | 
| c8g.16xlarge | 14 | 120 | 
| c8g.24xlarge | 14 | 120 | 
| c8g.48xlarge | 14 | 120 | 
| c8g.metal-24xl | 14 | 120 | 
| c8g.metal-48xl | 14 | 120 | 
| c8gb.medium | 1 | 4 | 
| c8gb.large | 2 | 10 | 
| c8gb.xlarge | 3 | 20 | 
| c8gb.2xlarge | 3 | 40 | 
| c8gb.4xlarge | 7 | 60 | 
| c8gb.8xlarge | 9 | 60 | 
| c8gb.12xlarge | 11 | 60 | 
| c8gb.16xlarge | 15 | 120 | 
| c8gb.24xlarge | 23 | 120 | 
| c8gb.48xlarge | 23 | 120 | 
| c8gb.metal-24xl | 23 | 120 | 
| c8gb.metal-48xl | 23 | 120 | 
| c8gd.medium | 1 | 4 | 
| c8gd.large | 2 | 10 | 
| c8gd.xlarge | 3 | 20 | 
| c8gd.2xlarge | 3 | 40 | 
| c8gd.4xlarge | 7 | 60 | 
| c8gd.8xlarge | 7 | 60 | 
| c8gd.12xlarge | 7 | 60 | 
| c8gd.16xlarge | 14 | 120 | 
| c8gd.24xlarge | 14 | 120 | 
| c8gd.48xlarge | 14 | 120 | 
| c8gd.metal-24xl | 14 | 120 | 
| c8gd.metal-48xl | 14 | 120 | 
| c8gn.medium | 1 | 4 | 
| c8gn.large | 2 | 10 | 
| c8gn.xlarge | 3 | 20 | 
| c8gn.2xlarge | 3 | 40 | 
| c8gn.4xlarge | 7 | 60 | 
| c8gn.8xlarge | 9 | 60 | 
| c8gn.12xlarge | 11 | 60 | 
| c8gn.16xlarge | 15 | 120 | 
| c8gn.24xlarge | 23 | 120 | 
| c8gn.48xlarge | 23 | 120 | 
| c8gn.metal-24xl | 23 | 120 | 
| c8gn.metal-48xl | 23 | 120 | 
| c8i.large | 2 | 10 | 
| c8i.xlarge | 3 | 20 | 
| c8i.2xlarge | 3 | 40 | 
| c8i.4xlarge | 7 | 60 | 
| c8i.8xlarge | 9 | 90 | 
| c8i.12xlarge | 11 | 120 | 
| c8i.16xlarge | 15 | 120 | 
| c8i.24xlarge | 15 | 120 | 
| c8i.32xlarge | 23 | 120 | 
| c8i.48xlarge | 23 | 120 | 
| c8i.96xlarge | 23 | 120 | 
| c8i.metal-48xl | 23 | 120 | 
| c8i.metal-96xl | 23 | 120 | 
| c8id.large | 2 | 10 | 
| c8id.xlarge | 3 | 20 | 
| c8id.2xlarge | 3 | 40 | 
| c8id.4xlarge | 7 | 60 | 
| c8id.8xlarge | 9 | 90 | 
| c8id.12xlarge | 11 | 120 | 
| c8id.16xlarge | 15 | 120 | 
| c8id.24xlarge | 15 | 120 | 
| c8id.32xlarge | 23 | 120 | 
| c8id.48xlarge | 23 | 120 | 
| c8id.96xlarge | 23 | 120 | 
| c8id.metal-48xl | 23 | 120 | 
| c8id.metal-96xl | 23 | 120 | 
| c8i-flex.large | 2 | 4 | 
| c8i-flex.xlarge | 3 | 10 | 
| c8i-flex.2xlarge | 3 | 20 | 
| c8i-flex.4xlarge | 7 | 40 | 
| c8i-flex.8xlarge | 9 | 60 | 
| c8i-flex.12xlarge | 11 | 120 | 
| c8i-flex.16xlarge | 15 | 120 | 

## メモリ最適化
<a name="eni-branch-mo"></a>


| インスタンスタイプ | ENI トランキングなしのタスク制限 | ENI トランキングありのタスク制限 | 
| --- | --- | --- | 
| r5.large | 2 | 10 | 
| r5.xlarge | 3 | 20 | 
| r5.2xlarge | 3 | 40 | 
| r5.4xlarge | 7 | 60 | 
| r5.12xlarge | 7 | 60 | 
| r5.16xlarge | 14 | 120 | 
| r5.24xlarge | 14 | 120 | 
| r5a.large | 2 | 10 | 
| r5a.xlarge | 3 | 20 | 
| r5a.2xlarge | 3 | 40 | 
| r5a.4xlarge | 7 | 60 | 
| r5a.8xlarge | 7 | 60 | 
| r5a.12xlarge | 7 | 60 | 
| r5a.16xlarge | 14 | 120 | 
| r5a.24xlarge | 14 | 120 | 
| r5ad.large | 2 | 10 | 
| r5ad.xlarge | 3 | 20 | 
| r5ad.2xlarge | 3 | 40 | 
| r5ad.4xlarge | 7 | 60 | 
| r5ad.8xlarge | 7 | 60 | 
| r5ad.12xlarge | 7 | 60 | 
| r5ad.16xlarge | 14 | 120 | 
| r5ad.24xlarge | 14 | 120 | 
| r5b.16xlarge | 14 | 120 | 
| r5d.large | 2 | 10 | 
| r5d.xlarge | 3 | 20 | 
| r5d.2xlarge | 3 | 40 | 
| r5d.4xlarge | 7 | 60 | 
| r5d.8xlarge | 7 | 60 | 
| r5d.12xlarge | 7 | 60 | 
| r5d.16xlarge | 14 | 120 | 
| r5d.24xlarge | 14 | 120 | 
| r5dn.16xlarge | 14 | 120 | 
| r6a.large | 2 | 10 | 
| r6a.xlarge | 3 | 20 | 
| r6a.2xlarge | 3 | 40 | 
| r6a.4xlarge | 7 | 60 | 
| r6a.8xlarge | 7 | 90 | 
| r6a.12xlarge | 7 | 120 | 
| r6a.16xlarge | 14 | 120 | 
| r6a.24xlarge | 14 | 120 | 
| r6a.32xlarge | 14 | 120 | 
| r6a.48xlarge | 14 | 120 | 
| r6a.metal | 14 | 120 | 
| r6g.medium | 1 | 4 | 
| r6g.large | 2 | 10 | 
| r6g.xlarge | 3 | 20 | 
| r6g.2xlarge | 3 | 40 | 
| r6g.4xlarge | 7 | 60 | 
| r6g.8xlarge | 7 | 60 | 
| r6g.12xlarge | 7 | 60 | 
| r6g.16xlarge | 14 | 120 | 
| r6g.metal | 14 | 120 | 
| r6gd.medium | 1 | 4 | 
| r6gd.large | 2 | 10 | 
| r6gd.xlarge | 3 | 20 | 
| r6gd.2xlarge | 3 | 40 | 
| r6gd.4xlarge | 7 | 60 | 
| r6gd.8xlarge | 7 | 60 | 
| r6gd.12xlarge | 7 | 60 | 
| r6gd.16xlarge | 14 | 120 | 
| r6gd.metal | 14 | 120 | 
| r6i.large | 2 | 10 | 
| r6i.xlarge | 3 | 20 | 
| r6i.2xlarge | 3 | 40 | 
| r6i.4xlarge | 7 | 60 | 
| r6i.8xlarge | 7 | 90 | 
| r6i.12xlarge | 7 | 120 | 
| r6i.16xlarge | 14 | 120 | 
| r6i.24xlarge | 14 | 120 | 
| r6i.32xlarge | 14 | 120 | 
| r6i.metal | 14 | 120 | 
| r6id.large | 2 | 10 | 
| r6id.xlarge | 3 | 20 | 
| r6id.2xlarge | 3 | 40 | 
| r6id.4xlarge | 7 | 60 | 
| r6id.8xlarge | 7 | 90 | 
| r6id.12xlarge | 7 | 120 | 
| r6id.16xlarge | 14 | 120 | 
| r6id.24xlarge | 14 | 120 | 
| r6id.32xlarge | 14 | 120 | 
| r6id.metal | 14 | 120 | 
| r6idn.large | 2 | 10 | 
| r6idn.xlarge | 3 | 20 | 
| r6idn.2xlarge | 3 | 40 | 
| r6idn.4xlarge | 7 | 60 | 
| r6idn.8xlarge | 7 | 90 | 
| r6idn.12xlarge | 7 | 120 | 
| r6idn.16xlarge | 14 | 120 | 
| r6idn.24xlarge | 14 | 120 | 
| r6idn.32xlarge | 15 | 120 | 
| r6idn.metal | 15 | 120 | 
| r6in.large | 2 | 10 | 
| r6in.xlarge | 3 | 20 | 
| r6in.2xlarge | 3 | 40 | 
| r6in.4xlarge | 7 | 60 | 
| r6in.8xlarge | 7 | 90 | 
| r6in.12xlarge | 7 | 120 | 
| r6in.16xlarge | 14 | 120 | 
| r6in.24xlarge | 14 | 120 | 
| r6in.32xlarge | 15 | 120 | 
| r6in.metal | 15 | 120 | 
| r7a.medium | 1 | 4 | 
| r7a.large | 2 | 10 | 
| r7a.xlarge | 3 | 20 | 
| r7a.2xlarge | 3 | 40 | 
| r7a.4xlarge | 7 | 60 | 
| r7a.8xlarge | 7 | 90 | 
| r7a.12xlarge | 7 | 120 | 
| r7a.16xlarge | 14 | 120 | 
| r7a.24xlarge | 14 | 120 | 
| r7a.32xlarge | 14 | 120 | 
| r7a.48xlarge | 14 | 120 | 
| r7a.metal-48xl | 14 | 120 | 
| r7g.medium | 1 | 4 | 
| r7g.large | 2 | 10 | 
| r7g.xlarge | 3 | 20 | 
| r7g.2xlarge | 3 | 40 | 
| r7g.4xlarge | 7 | 60 | 
| r7g.8xlarge | 7 | 60 | 
| r7g.12xlarge | 7 | 60 | 
| r7g.16xlarge | 14 | 120 | 
| r7g.metal | 14 | 120 | 
| r7gd.medium | 1 | 4 | 
| r7gd.large | 2 | 10 | 
| r7gd.xlarge \$1 | 3 | 20 | 
| r7gd.2xlarge | 3 | 40 | 
| r7gd.4xlarge | 7 | 60 | 
| r7gd.8xlarge | 7 | 60 | 
| r7gd.12xlarge | 7 | 60 | 
| r7gd.16xlarge | 14 | 120 | 
| r7gd.metal | 14 | 120 | 
| r7i.large | 2 | 10 | 
| r7i.xlarge | 3 | 20 | 
| r7i.2xlarge | 3 | 40 | 
| r7i.4xlarge | 7 | 60 | 
| r7i.8xlarge | 7 | 90 | 
| r7i.12xlarge | 7 | 120 | 
| r7i.16xlarge | 14 | 120 | 
| r7i.24xlarge | 14 | 120 | 
| r7i.48xlarge | 14 | 120 | 
| r7i.metal-24xl | 14 | 120 | 
| r7i.metal-48xl | 14 | 120 | 
| r7iz.large | 2 | 10 | 
| r7iz.xlarge | 3 | 20 | 
| r7iz.2xlarge | 3 | 40 | 
| r7iz.4xlarge | 7 | 60 | 
| r7iz.8xlarge | 7 | 90 | 
| r7iz.12xlarge | 7 | 120 | 
| r7iz.16xlarge | 14 | 120 | 
| r7iz.32xlarge | 14 | 120 | 
| r7iz.metal-16xl | 14 | 120 | 
| r7iz.metal-32xl | 14 | 120 | 
| r8a.medium | 1 | 4 | 
| r8a.large | 2 | 10 | 
| r8a.xlarge | 3 | 20 | 
| r8a.2xlarge | 3 | 40 | 
| r8a.4xlarge | 7 | 60 | 
| r8a.8xlarge | 9 | 90 | 
| r8a.12xlarge | 11 | 120 | 
| r8a.16xlarge | 15 | 120 | 
| r8a.24xlarge | 15 | 120 | 
| r8a.48xlarge | 23 | 120 | 
| r8a.metal-24xl | 15 | 120 | 
| r8a.metal-48xl | 23 | 120 | 
| r8g.medium | 1 | 4 | 
| r8g.large | 2 | 10 | 
| r8g.xlarge | 3 | 20 | 
| r8g.2xlarge | 3 | 40 | 
| r8g.4xlarge | 7 | 60 | 
| r8g.8xlarge | 7 | 60 | 
| r8g.12xlarge | 7 | 60 | 
| r8g.16xlarge | 14 | 120 | 
| r8g.24xlarge | 14 | 120 | 
| r8g.48xlarge | 14 | 120 | 
| r8g.metal-24xl | 14 | 120 | 
| r8g.metal-48xl | 14 | 120 | 
| r8gb.medium | 1 | 4 | 
| r8gb.large | 2 | 10 | 
| r8gb.xlarge | 3 | 20 | 
| r8gb.2xlarge | 3 | 40 | 
| r8gb.4xlarge | 7 | 60 | 
| r8gb.8xlarge | 9 | 60 | 
| r8gb.12xlarge | 11 | 60 | 
| r8gb.16xlarge | 15 | 120 | 
| r8gb.24xlarge | 23 | 120 | 
| r8gb.48xlarge | 23 | 120 | 
| r8gb.metal-24xl | 23 | 120 | 
| r8gb.metal-48xl | 23 | 120 | 
| r8gd.medium | 1 | 4 | 
| r8gd.large | 2 | 10 | 
| r8gd.xlarge | 3 | 20 | 
| r8gd.2xlarge | 3 | 40 | 
| r8gd.4xlarge | 7 | 60 | 
| r8gd.8xlarge | 7 | 60 | 
| r8gd.12xlarge | 7 | 60 | 
| r8gd.16xlarge | 14 | 120 | 
| r8gd.24xlarge | 14 | 120 | 
| r8gd.48xlarge | 14 | 120 | 
| r8gd.metal-24xl | 14 | 120 | 
| r8gd.metal-48xl | 14 | 120 | 
| r8gn.medium | 1 | 4 | 
| r8gn.large | 2 | 10 | 
| r8gn.xlarge | 3 | 20 | 
| r8gn.2xlarge | 3 | 40 | 
| r8gn.4xlarge | 7 | 60 | 
| r8gn.8xlarge | 9 | 60 | 
| r8gn.12xlarge | 11 | 60 | 
| r8gn.16xlarge | 15 | 120 | 
| r8gn.24xlarge | 23 | 120 | 
| r8gn.48xlarge | 23 | 120 | 
| r8gn.metal-24xl | 23 | 120 | 
| r8gn.metal-48xl | 23 | 120 | 
| r8i.large | 2 | 10 | 
| r8i.xlarge | 3 | 20 | 
| r8i.2xlarge | 3 | 40 | 
| r8i.4xlarge | 7 | 60 | 
| r8i.8xlarge | 9 | 90 | 
| r8i.12xlarge | 11 | 120 | 
| r8i.16xlarge | 15 | 120 | 
| r8i.24xlarge | 15 | 120 | 
| r8i.32xlarge | 23 | 120 | 
| r8i.48xlarge | 23 | 120 | 
| r8i.96xlarge | 23 | 120 | 
| r8i.metal-48xl | 23 | 120 | 
| r8i.metal-96xl | 23 | 120 | 
| r8id.large | 2 | 10 | 
| r8id.xlarge | 3 | 20 | 
| r8id.2xlarge | 3 | 40 | 
| r8id.4xlarge | 7 | 60 | 
| r8id.8xlarge | 9 | 90 | 
| r8id.12xlarge | 11 | 120 | 
| r8id.16xlarge | 15 | 120 | 
| r8id.24xlarge | 15 | 120 | 
| r8id.32xlarge | 23 | 120 | 
| r8id.48xlarge | 23 | 120 | 
| r8id.96xlarge | 23 | 120 | 
| r8id.metal-48xl | 23 | 120 | 
| r8id.metal-96xl | 23 | 120 | 
| r8i-flex.large | 2 | 4 | 
| r8i-flex.xlarge | 3 | 10 | 
| r8i-flex.2xlarge | 3 | 20 | 
| r8i-flex.4xlarge | 7 | 40 | 
| r8i-flex.8xlarge | 9 | 60 | 
| r8i-flex.12xlarge | 11 | 120 | 
| r8i-flex.16xlarge | 15 | 120 | 
| u-3tb1.56xlarge | 7 | 12 | 
| u-6tb1.56xlarge | 14 | 12 | 
| u-18tb1.112xlarge | 14 | 12 | 
| u-18tb1.metal | 14 | 12 | 
| u-24tb1.112xlarge | 14 | 12 | 
| u-24tb1.metal | 14 | 12 | 
| u7i-6tb.112xlarge | 14 | 120 | 
| u7i-8tb.112xlarge | 14 | 120 | 
| u7i-12tb.224xlarge | 14 | 120 | 
| u7in-16tb.224xlarge | 15 | 120 | 
| u7in-24tb.224xlarge | 15 | 120 | 
| u7in-32tb.224xlarge | 15 | 120 | 
| u7inh-32tb.480xlarge | 15 | 120 | 
| x2gd.medium | 1 | 10 | 
| x2gd.large | 2 | 10 | 
| x2gd.xlarge | 3 | 20 | 
| x2gd.2xlarge | 3 | 40 | 
| x2gd.4xlarge | 7 | 60 | 
| x2gd.8xlarge | 7 | 60 | 
| x2gd.12xlarge | 7 | 60 | 
| x2gd.16xlarge | 14 | 120 | 
| x2gd.metal | 14 | 120 | 
| x2idn.16xlarge | 14 | 120 | 
| x2idn.24xlarge | 14 | 120 | 
| x2idn.32xlarge | 14 | 120 | 
| x2idn.metal | 14 | 120 | 
| x2iedn.xlarge | 3 | 13 | 
| x2iedn.2xlarge | 3 | 29 | 
| x2iedn.4xlarge | 7 | 60 | 
| x2iedn.8xlarge | 7 | 120 | 
| x2iedn.16xlarge | 14 | 120 | 
| x2iedn.24xlarge | 14 | 120 | 
| x2iedn.32xlarge | 14 | 120 | 
| x2iedn.metal | 14 | 120 | 
| x2iezn.2xlarge | 3 | 64 | 
| x2iezn.4xlarge | 7 | 120 | 
| x2iezn.6xlarge | 7 | 120 | 
| x2iezn.8xlarge | 7 | 120 | 
| x2iezn.12xlarge | 14 | 120 | 
| x2iezn.metal | 14 | 120 | 
| x8g.medium | 1 | 4 | 
| x8g.large | 2 | 10 | 
| x8g.xlarge | 3 | 20 | 
| x8g.2xlarge | 3 | 40 | 
| x8g.4xlarge | 7 | 60 | 
| x8g.8xlarge | 7 | 60 | 
| x8g.12xlarge | 7 | 60 | 
| x8g.16xlarge | 14 | 120 | 
| x8g.24xlarge | 14 | 120 | 
| x8g.48xlarge | 14 | 120 | 
| x8g.metal-24xl | 14 | 120 | 
| x8g.metal-48xl | 14 | 120 | 
| x8aedz.large | 3 | 10 | 
| x8aedz.xlarge | 3 | 20 | 
| x8aedz.3xlarge | 7 | 40 | 
| x8aedz.6xlarge | 7 | 60 | 
| x8aedz.12xlarge | 15 | 120 | 
| x8aedz.24xlarge | 15 | 120 | 
| x8aedz.metal-12xl | 15 | 120 | 
| x8aedz.metal-24xl | 15 | 120 | 
| x8i.large | 2 | 10 | 
| x8i.xlarge | 3 | 20 | 
| x8i.2xlarge | 3 | 40 | 
| x8i.4xlarge | 7 | 60 | 
| x8i.8xlarge | 9 | 90 | 
| x8i.12xlarge | 11 | 120 | 
| x8i.16xlarge | 15 | 120 | 
| x8i.24xlarge | 15 | 120 | 
| x8i.32xlarge | 23 | 120 | 
| x8i.48xlarge | 23 | 120 | 
| x8i.64xlarge | 23 | 120 | 
| x8i.96xlarge | 23 | 120 | 
| x8i.metal-48xl | 23 | 120 | 
| x8i.metal-96xl | 23 | 120 | 

## ストレージの最適化
<a name="eni-branch-so"></a>


| インスタンスタイプ | ENI トランキングなしのタスク制限 | ENI トランキングありのタスク制限 | 
| --- | --- | --- | 
| i4g.large | 2 | 10 | 
| i4g.xlarge | 3 | 20 | 
| i4g.2xlarge | 3 | 40 | 
| i4g.4xlarge | 7 | 60 | 
| i4g.8xlarge | 7 | 60 | 
| i4g.16xlarge | 14 | 120 | 
| i4i.xlarge | 3 | 8 | 
| i4i.2xlarge | 3 | 28 | 
| i4i.4xlarge | 7 | 58 | 
| i4i.8xlarge | 7 | 118 | 
| i4i.12xlarge | 7 | 118 | 
| i4i.16xlarge | 14 | 248 | 
| i4i.24xlarge | 14 | 118 | 
| i4i.32xlarge | 14 | 498 | 
| i4i.metal | 14 | 498 | 
| i7i.large | 2 | 10 | 
| i7i.xlarge | 3 | 20 | 
| i7i.2xlarge | 3 | 40 | 
| i7i.4xlarge | 7 | 60 | 
| i7i.8xlarge | 7 | 90 | 
| i7i.12xlarge | 7 | 90 | 
| i7i.16xlarge | 14 | 120 | 
| i7i.24xlarge | 14 | 120 | 
| i7i.48xlarge | 14 | 120 | 
| i7i.metal-24xl | 14 | 120 | 
| i7i.metal-48xl | 14 | 120 | 
| i7ie.large | 2 | 20 | 
| i7ie.xlarge | 3 | 29 | 
| i7ie.2xlarge | 3 | 29 | 
| i7ie.3xlarge | 3 | 29 | 
| i7ie.6xlarge | 7 | 60 | 
| i7ie.12xlarge | 7 | 60 | 
| i7ie.18xlarge | 14 | 120 | 
| i7ie.24xlarge | 14 | 120 | 
| i7ie.48xlarge | 14 | 120 | 
| i7ie.metal-24xl | 14 | 120 | 
| i7ie.metal-48xl | 14 | 120 | 
| i8g.large | 2 | 10 | 
| i8g.xlarge | 3 | 20 | 
| i8g.2xlarge | 3 | 40 | 
| i8g.4xlarge | 7 | 60 | 
| i8g.8xlarge | 7 | 60 | 
| i8g.12xlarge | 7 | 60 | 
| i8g.16xlarge | 14 | 120 | 
| i8g.24xlarge | 14 | 120 | 
| i8g.48xlarge | 14 | 120 | 
| i8g.metal-24xl | 14 | 120 | 
| i8g.metal-48xl | 14 | 120 | 
| i8ge.large | 2 | 20 | 
| i8ge.xlarge | 3 | 29 | 
| i8ge.2xlarge | 3 | 29 | 
| i8ge.3xlarge | 5 | 29 | 
| i8ge.6xlarge | 9 | 60 | 
| i8ge.12xlarge | 11 | 60 | 
| i8ge.18xlarge | 15 | 120 | 
| i8ge.24xlarge | 15 | 120 | 
| i8ge.48xlarge | 23 | 120 | 
| i8ge.metal-24xl | 15 | 120 | 
| i8ge.metal-48xl | 23 | 120 | 
| im4gn.large | 2 | 10 | 
| im4gn.xlarge | 3 | 20 | 
| im4gn.2xlarge | 3 | 40 | 
| im4gn.4xlarge | 7 | 60 | 
| im4gn.8xlarge | 7 | 60 | 
| im4gn.16xlarge | 14 | 120 | 
| is4gen.medium | 1 | 4 | 
| is4gen.large | 2 | 10 | 
| is4gen.xlarge | 3 | 20 | 
| is4gen.2xlarge | 3 | 40 | 
| is4gen.4xlarge | 7 | 60 | 
| is4gen.8xlarge | 7 | 60 | 

## 高速コンピューティング
<a name="eni-branch-ac"></a>


| インスタンスタイプ | ENI トランキングなしのタスク制限 | ENI トランキングありのタスク制限 | 
| --- | --- | --- | 
| dl1.24xlarge | 59 | 120 | 
| dl2q.24xlarge | 14 | 120 | 
| f2.6xlarge | 7 | 90 | 
| f2.12xlarge | 7 | 120 | 
| f2.48xlarge | 14 | 120 | 
| g4ad.xlarge | 1 | 12 | 
| g4ad.2xlarge | 1 | 12 | 
| g4ad.4xlarge | 2 | 12 | 
| g4ad.8xlarge | 3 | 12 | 
| g4ad.16xlarge | 7 | 12 | 
| g5.xlarge | 3 | 6 | 
| g5.2xlarge | 3 | 19 | 
| g5.4xlarge | 7 | 40 | 
| g5.8xlarge | 7 | 90 | 
| g5.12xlarge | 14 | 120 | 
| g5.16xlarge | 7 | 120 | 
| g5.24xlarge | 14 | 120 | 
| g5.48xlarge | 6 | 120 | 
| g5g.xlarge | 3 | 20 | 
| g5g.2xlarge | 3 | 40 | 
| g5g.4xlarge | 7 | 60 | 
| g5g.8xlarge | 7 | 60 | 
| g5g.16xlarge | 14 | 120 | 
| g5g.metal | 14 | 120 | 
| g6.xlarge | 3 | 20 | 
| g6.2xlarge | 3 | 40 | 
| g6.4xlarge | 7 | 60 | 
| g6.8xlarge | 7 | 90 | 
| g6.12xlarge | 7 | 120 | 
| g6.16xlarge | 14 | 120 | 
| g6.24xlarge | 14 | 120 | 
| g6.48xlarge | 14 | 120 | 
| g6e.xlarge | 3 | 20 | 
| g6e.2xlarge | 3 | 40 | 
| g6e.4xlarge | 7 | 60 | 
| g6e.8xlarge | 7 | 90 | 
| g6e.12xlarge | 9 | 120 | 
| g6e.16xlarge | 14 | 120 | 
| g6e.24xlarge | 19 | 120 | 
| g6e.48xlarge | 39 | 120 | 
| g6f.large | 1 | 10 | 
| g6f.xlarge | 3 | 20 | 
| g6f.2xlarge | 3 | 40 | 
| g6f.4xlarge | 7 | 60 | 
| gr6.4xlarge | 7 | 60 | 
| gr6.8xlarge | 7 | 90 | 
| gr6f.4xlarge | 7 | 60 | 
| g7e.2xlarge | 3 | 242 | 
| g7e.4xlarge | 7 | 242 | 
| g7e.8xlarge | 7 | 242 | 
| g7e.12xlarge | 9 | 242 | 
| g7e.24xlarge | 19 | 242 | 
| g7e.48xlarge | 39 | 242 | 
| inf2.xlarge | 3 | 20 | 
| inf2.8xlarge | 7 | 90 | 
| inf2.24xlarge | 14 | 120 | 
| inf2.48xlarge | 14 | 120 | 
| p4d.24xlarge | 59 | 120 | 
| p4de.24xlarge | 59 | 120 | 
| p5.4xlarge | 3 | 60 | 
| p5.48xlarge | 63 | 242 | 
| p5e.48xlarge | 63 | 242 | 
| p5en.48xlarge | 63 | 242 | 
| p6-b200.48xlarge | 31 | 242 | 
| p6-b300.48xlarge | 67 | 242 | 
| p6e-gb200.36xlarge | 38 | 120 | 
| trn1.2xlarge | 3 | 19 | 
| trn1.32xlarge | 39 | 120 | 
| trn1n.32xlarge | 79 | 242 | 
| trn2.3xlarge | 1 | 14 | 
| trn2.48xlarge | 31 | 242 | 
| trn2u.48xlarge | 31 | 242 | 
| vt1.3xlarge | 3 | 40 | 
| vt1.6xlarge | 7 | 60 | 
| vt1.24xlarge | 14 | 120 | 

## ハイパフォーマンスコンピューティング
<a name="eni-branch-hpc"></a>


| インスタンスタイプ | ENI トランキングなしのタスク制限 | ENI トランキングありのタスク制限 | 
| --- | --- | --- | 
| hpc6a.48xlarge | 1 | 120 | 
| hpc6id.32xlarge | 1 | 120 | 
| hpc7g.4xlarge | 3 | 120 | 
| hpc7g.8xlarge | 3 | 120 | 
| hpc7g.16xlarge | 3 | 120 | 
| hpc8a.96xlarge | 3 | -2 | 

# Amazon ECS Linux コンテナインスタンスのメモリを予約する
<a name="memory-management"></a>

Amazon ECS コンテナエージェントがクラスターにコンテナインスタンスを登録する場合、エージェントは、コンテナインスタンスがタスク用に予約できるメモリ容量を決定する必要があります。プラットフォームのメモリオーバーヘッドとシステムカーネルが占めるメモリのため、この数値は、Amazon EC2 インスタンスとして公開されているインストール済みメモリ量とは異なります。例えば、`m4.large` インスタンスには 8 GiB のメモリがインストールされています。しかし、これはコンテナインスタンスが登録されたときに、タスクに使用できるメモリが正確に 8192 MiB に変換されるとは限りません。

## ECS マネージドインスタンスのメモリリソースの決定
<a name="ecs-mi-memory-calculation"></a>

Amazon ECS マネージドインスタンスは、階層的なアプローチを使用してタスクのメモリリソース要件を決定します。Docker のメモリイントロスペクションに依存する EC2 上の ECS とは異なり、ECS マネージドインスタンスは、スケジューリングの決定時にタスクペイロードから直接メモリ要件を計算します。

ECS マネージドインスタンスのエージェントはタスクを受信すると、次の優先順位を使用してメモリ要件を計算します。

1. **タスクレベルのメモリ (最高優先度)** – タスクレベルのメモリがタスク定義で指定されている場合、エージェントはこの値を直接使用します。この場合、すべてのコンテナレベルのメモリ設定より優先されます。

1. **コンテナレベルのメモリ合計 (フォールバック)** – タスクレベルのメモリが指定されていない場合 (または 0 の場合)、エージェントはタスク内のすべてのコンテナのメモリ要件を合計します。コンテナごとに以下を使用します。

   1. *メモリ予約 (ソフト制限)* – コンテナが設定で `memoryReservation` を指定した場合、エージェントはこの値を使用します。

   1. *コンテナメモリ (ハード制限)* – `memoryReservation` が指定されていない場合、エージェントはコンテナの `memory`フィールドを使用します。

**Example 指定されたタスクレベルのメモリ**  
タスクレベルのメモリを指定すると、コンテナレベルの設定より優先されます。  

```
{
  "family": "my-task",
  "memory": "2048",
  "containerDefinitions": [
    {
      "name": "container1",
      "memory": 1024,
      "memoryReservation": 512
    }
  ]
}
```
エージェントは 2048 MiB を予約します (タスクレベルのメモリが優先)。

**Example 予約を含むコンテナレベルのメモリ**  
タスクレベルのメモリが指定されていない場合、エージェントはコンテナのメモリ要件を合計します。  

```
{
  "family": "my-task",
  "containerDefinitions": [
    {
      "name": "container1",
      "memory": 1024,
      "memoryReservation": 512
    },
    {
      "name": "container2",
      "memory": 512
    }
  ]
}
```
エージェントは 512 MiB (container1 予約) \$1 512 MiB (container2 メモリ) = 合計 1024 MiB を予約します。

ECS マネージドインスタンスのエージェントは、次の 3 つのフェーズでメモリ計算を実行します。

1. **タスク受信** – ECS コントロールプレーンからタスクペイロードが到着すると、エージェントは直ちに必要なメモリを計算します。

1. **リソースストレージ** – 計算されたメモリ要件は、後でリソースの課金オペレーションで使用するため、タスクモデルに保存されます。

1. **スケジュールの決定** – タスクを受け入れる前に、エージェントは十分なメモリが使用可能かどうかを確認します。メモリが不足している場合タスクは拒否され、リソースが利用可能になるまで ECS サービスキューに残留します。

**注記**  
EC2 の ECS とは異なり、ECS マネージドインスタンスは `ECS_RESERVED_MEMORY` の設定変数を使用しません。システムプロセスのメモリ予約は、基盤となるプラットフォームのリソース管理を通じて処理され、エージェントはタスク定義に基づいて正確なリソースの課金を実行します。

 EC2 上の ECS の場合、Amazon ECS コンテナエージェントには、タスクに割り当てられたプールから指定したメモリ容量 (MiB) を削除するのに使用できる、`ECS_RESERVED_MEMORY` という設定変数があります。これにより、重要なシステムプロセスのメモリを効果的に確保することができます。

タスクでコンテナインスタンスのすべてのメモリを占有している場合、メモリが不可欠なシステムプロセスとタスクが競合し、システム障害が発生する可能性があります。

例えば、コンテナエージェント設定ファイルで `ECS_RESERVED_MEMORY=256` を指定すると、そのインスタンスの総メモリマイナス 256 MiB が登録され、256 MiBのメモリは ECS タスクに割り当てされなくなります。エージェント構成変数とその設定方法の詳細については、[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md) および [Amazon ECS Linux コンテナインスタンスをブートストラップしてデータを渡す](bootstrap_container_instance.md) を参照してください 。

タスクに 8192 MiB を指定して、使用可能なメモリが 8192 MiB 以上のコンテナインスタンスがなくこの要件を満たせない場合、そのタスクはクラスターに配置できません。マネージド型コンピューティング環境を使用している場合、リクエストに対応するために AWS Batch はより大きなインスタンスタイプを起動する必要があります。

Amazon ECS コンテナエージェントは、Docker `ReadMemInfo()`関数を使用してオペレーティングシステムで使用可能な合計メモリのクエリを実行します。Linux と Windows の両方に、合計メモリを判断できるコマンドラインユーティリティが備わっています。

**Example - Linux 合計メモリを決定**  
**free** コマンドは、オペレーティングシステムによって認識される合計メモリを返します。  

```
$ free -b
```
Amazon ECS に最適化された Amazon Linux AMI を実行する `m4.large` インスタンスの出力例。  

```
             total       used       free     shared    buffers     cached
Mem:    8373026816  348180480 8024846336      90112   25534464  205418496
-/+ buffers/cache:  117227520 8255799296
```
このインスタンスには 8373026816 バイトの合計メモリーがあり、タスクに使用できる 7985 MiB に変換されます。

**Example -Windows 合計メモリを決定**  
**wmic** コマンドは、オペレーティングシステムによって認識される合計メモリを返します。  

```
C:\> wmic ComputerSystem get TotalPhysicalMemory
```
Amazon ECS に最適化された Windows Server AMI を実行する `m4.large` インスタンスの出力例。  

```
TotalPhysicalMemory
8589524992
```
このインスタンスには合計メモリーが 8589524992 バイトあり、タスクに使用可能な 8191 MiB に変換されます。

## コンテナインスタンスのメモリを表示する
<a name="viewing-memory"></a>

Amazon ECS コンソール (または [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html) API 操作) で、コンテナインスタンスに登録されているメモリ容量を表示できます。特定のインスタンスタイプに対して、可能な限り多くのメモリをタスクに割り当て、リソース使用率を最大化しようとしている場合は、そのコンテナインスタンスに使用可能なメモリを確認してから、そのタスクに十分なメモリを割り当てることができます。

**コンテナインスタンスメモリを表示するには**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[クラスター]** を選択し、コンテナインスタンスをホストするクラスターを選択します。

1. **[インフラストラクチャ]** を選択し、[コンテナインスタンス] でコンテナインスタンスを選択します。

1. **[リソース]** セクションに、コンテナインスタンス用に登録された使用可能なメモリが表示されます。

   **[登録済み]** メモリの値は、Amazon ECS の初回起動時に登録されたときのコンテナインスタンスのメモリの値で、**[利用可能]** メモリの値は、まだ タスクに割り当てられていないメモリの値です。

# AWS Systems Manager を使用して Amazon ECS コンテナインスタンスをリモートで管理する
<a name="ec2-run-command"></a>

AWS Systems Manager (Systems Manager) で Run Command 機能を使用すると、Amazon ECS コンテナインスタンスの設定を安全にリモートで管理できます。Run Command を使用すると、インスタンスにローカルにログオンしなくても一般的な管理タスクを簡単に実行することができます。複数のコンテナインスタンスでコマンドを同時に実行することで、クラスター全体の設定の変更を管理できます。Run Command は各コマンドのステータスと結果をレポートします。

ここでは、Run Command を使用して実行できるタスクのタイプについていくつか例を示します。
+ パッケージをインストールまたはアンインストールする。
+ セキュリティ更新プログラムを実行する。
+ Docker イメージをクリーンアップする。
+ サービスを停止または起動する。
+ システムリソースを表示する。
+ ログファイルを表示する。
+ ファイルオペレーションを実行する。

Run Command の詳細については、の「*AWS Systems Managerユーザーガイド*」の「[AWS Systems ManagerRun Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)」を参照してください。

Amazon ECS で Systems Manager を使用するには、以下の前提条件があります。

1. コンテナインスタンスロール (**ecsInstanceRole**) に、Systems Manager API にアクセスするためのアクセス許可を付与する必要があります。これを行うには、**AmazonSSMManagedInstanceCore** を `ecsInstanceRole` ロールに割り当てます。ポリシーをロールにアタッチする方法については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに対するアクセス許可を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)」を参照してください。

1. SSM Agent がコンテナインスタンスにインストールされていることを確認します。詳細については、「[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)」を参照してください。

Systems Manager 管理ポリシーを `ecsInstanceRole` にアタッチして、AWS Systems Manager エージェント (SSM Agent) がコンテナインスタンスにインストールされていることを確認したら、Run Command を使用してコマンドをコンテナインスタンスに送信することができます。インスタンスでのコマンドおよびシェルスクリプトの実行と、その結果の出力の表示については、*AWS Systems Managerユーザーガイド* の「[Systems Manager Run Command を使用したコマンドの実行](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)」および「[Run Command のチュートリアル](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command-walkthroughs.html)」を参照してください。

一般的なユースケースは、Run Command でコンテナインスタンスソフトウェアを更新することです。「AWS Systems Manager ユーザーガイド」の手順を実行し、以下のパラメータを指定します。


| パラメータ | 値 | 
| --- | --- | 
|  **コマンドのドキュメント**  | AWS-RunShellScript | 
| コマンド |  <pre>$ yum update -y</pre> | 
| ターゲットインスタンス | コンテナインスタンス | 

# Amazon ECS Linux コンテナインスタンスに HTTP プロキシを使用する
<a name="http_proxy_config"></a>

Amazon ECS コンテナエージェントと Docker デーモンの両方に HTTP プロキシを使用するように Amazon ECS コンテナインスタンスを設定できます。これは、コンテナインスタンスに、Amazon VPC インターネットゲートウェイ、NAT ゲートウェイ、またはインスタンスを介した外部ネットワークアクセスがない場合に便利です。

HTTP プロキシを使用するように Amazon ECS Linux コンテナインスタンスを設定するには、起動時に該当するファイルで以下の変数に Amazon EC2 ユーザーデータを設定します。手動で設定ファイルを編集してから、エージェントを再起動することもできます。

`/etc/ecs/ecs.config` (Amazon Linux 2 および Amazon Linux AMI)    
`HTTP_PROXY=10.0.0.131:3128`  
この値を、Amazon ECS エージェントがインターネットへの接続に使用する HTTP プロキシのホスト名 (または IP アドレス) とポート番号に設定します。例えば、コンテナインスタンスに、Amazon VPC インターネットゲートウェイ、NAT ゲートウェイ、またはインスタンスを介した外部ネットワークアクセスがない場合です。  
`NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`  
この値を `169.254.169.254,169.254.170.2,/var/run/docker.sock` に設定して、EC2 インスタンスのメタデータ、タスク用の IAM; ロール、および Docker デーモンのトラフィックをプロキシからフィルタリングします。

`/etc/systemd/system/ecs.service.d/http-proxy.conf` (Amazon Linux 2 のみ)    
`Environment="HTTP_PROXY=10.0.0.131:3128/"`  
この値を、`ecs-init` がインターネットへの接続に使用する HTTP プロキシのホスト名 (または IP アドレス) とポート番号に設定します。例えば、コンテナインスタンスに、Amazon VPC インターネットゲートウェイ、NAT ゲートウェイ、またはインスタンスを介した外部ネットワークアクセスがない場合です。  
`Environment="NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock"`  
この値を `169.254.169.254,169.254.170.2,/var/run/docker.sock` に設定して、EC2 インスタンスのメタデータ、タスク用の IAM; ロール、および Docker デーモンのトラフィックをプロキシからフィルタリングします。

`/etc/init/ecs.override` (Amazon Linux AMI のみ)    
`env HTTP_PROXY=10.0.0.131:3128`  
この値を、`ecs-init` がインターネットへの接続に使用する HTTP プロキシのホスト名 (または IP アドレス) とポート番号に設定します。例えば、コンテナインスタンスに、Amazon VPC インターネットゲートウェイ、NAT ゲートウェイ、またはインスタンスを介した外部ネットワークアクセスがない場合です。  
`env NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`  
この値を `169.254.169.254,169.254.170.2,/var/run/docker.sock` に設定して、EC2 インスタンスのメタデータ、タスク用の IAM; ロール、および Docker デーモンのトラフィックをプロキシからフィルタリングします。

`/etc/systemd/system/docker.service.d/http-proxy.conf` (Amazon Linux 2 のみ)    
`Environment="HTTP_PROXY=http://10.0.0.131:3128"`  
この値を、Docker デーモンがインターネットへの接続に使用する HTTP プロキシのホスト名 (または IP アドレス) とポート番号に設定します。例えば、コンテナインスタンスに、Amazon VPC インターネットゲートウェイ、NAT ゲートウェイ、またはインスタンスを介した外部ネットワークアクセスがない場合です。  
`Environment="NO_PROXY=169.254.169.254,169.254.170.2"`  
この値を `169.254.169.254,169.254.170.2` に設定して、EC2 インスタンスのメタデータをプロキシからフィルタリングします。

`/etc/sysconfig/docker` (Amazon Linux AMI および Amazon Linux 2 のみ)    
`export HTTP_PROXY=http://10.0.0.131:3128`  
この値を、Docker デーモンがインターネットへの接続に使用する HTTP プロキシのホスト名 (または IP アドレス) とポート番号に設定します。例えば、コンテナインスタンスに、Amazon VPC インターネットゲートウェイ、NAT ゲートウェイ、またはインスタンスを介した外部ネットワークアクセスがない場合です。  
`export NO_PROXY=169.254.169.254,169.254.170.2`  
この値を `169.254.169.254,169.254.170.2` に設定して、EC2 インスタンスのメタデータをプロキシからフィルタリングします。

これらの環境変数を上記のファイルで設定すると、Amazon ECS コンテナエージェント、`ecs-init`、および Docker デーモンのみに影響があります。プロキシを使用する他のサービス (**yum** など) を設定することはありません。

プロキシを保護する方法については、「[How do I set up an HTTP proxy for Docker and the Amazon ECS container agent in Amazon Linux 2 or AL2023](https://repost.aws/knowledge-center/ecs-http-proxy-docker-linux2)」を参照してください。

# Amazon ECS Auto Scaling グループ用に事前初期化されたインスタンスを設定する
<a name="using-warm-pool"></a>

Amazon ECS では、Amazon EC2 Auto Scaling ウォームプールをサポートします。ウォームプールは、事前に初期化済みの Amazon EC2 インスタンスグループでサービス開始が準備されています。アプリケーションがスケールアウトする必要がある場合は、常に Amazon EC2 Auto Scaling はコールドインスタンスを起動するのではなく、ウォームプールから事前に初期化されたインスタンスを使用し、最終的な初期化プロセスの実行を許可し、インスタンスを使用開始します。

ウォームプールの詳細、および Auto Scaling グループにウォームプールを追加する方法については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Amazon EC2 Auto Scaling のウォームプール](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html)」を参照してください。

Amazon ECS の Auto Scaling グループのウォームプールを作成または更新する場合、スケールイン (`ReuseOnScaleIn`) 時にインスタンスをウォームプールに戻すオプションを設定することはできません。詳細については、「AWS Command Line Interface リファレンス」の「[put-warm-pool](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-warm-pool.html)」を参照してください。

Amazon ECS クラスターでウォームプールを使用するには、Amazon EC2 Auto Scaling グループ起動テンプレートの **[User data]** (ユーザーデータ) フィールドで `ECS_WARM_POOLS_CHECK` エージェント設定変数を `true` に設定します。

以下は、Amazon EC2 起動テンプレートの **[User data]** (ユーザーデータ) フィールドでエージェント設定変数の指定方法の例を示しています。*MyCluster* は、自分のクラスターの名前に置き換えてください。

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_WARM_POOLS_CHECK=true
EOF
```

この `ECS_WARM_POOLS_CHECK` 変数は、エージェントバージョン `1.59.0` 以降でのみサポートされています。変数の詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。

# Amazon ECS コンテナエージェントをアップデートする
<a name="ecs-agent-update"></a>

場合によっては、バグの修正や新機能を取得するために Amazon ECS コンテナエージェントを更新する必要があります。Amazon ECS コンテナエージェントの更新によって、コンテナインスタンスで実行中のタスクやサービスが中断されることはありません。エージェントを更新するプロセスは、コンテナインスタンスが Amazon ECS 対応 AMI で起動されたか、別のオペレーティングシステムで起動されたかによって異なります。

**注記**  
エージェント更新は Windows コンテナインスタンスに適用されません。Windows クラスター内のエージェントバージョンを更新するには、新しいコンテナインスタンスを起動することをお勧めします。

## Amazon ECSコンテナエージェントバージョンの確認
<a name="checking_agent_version"></a>

コンテナインスタンスで実行中のコンテナエージェントのバージョンをチェックして、更新が必要かどうかを確認できます。Amazon ECSコンソールのコンテナインスタンスビューにエージェントバージョンが表示されます。以下の手順を使用してエージェントバージョンを確認します。

------
#### [ Amazon ECS console ]

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、外部インスタンスが存在するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択し、外部インスタンスをホストするクラスターを選択します。

1. **[Cluster : *name*]** (クラスター: 名前) のページで、**[Infrastructure]** (インフラストラクチャ) タブを選択します。

1. **[Container instances]** (コンテナインスタンス) で、コンテナインスタンスの **[Agent version]** (エージェントバージョン) 列に注意してください。コンテナインスタンスに最新バージョンのコンテナエージェントが含まれていない場合、コンソールにアラートメッセージが表示され、古いエージェントバージョンにフラグが設定されます。

   エージェントバージョンが古い場合、次の手順でコンテナエージェントを更新できます。
   + コンテナインスタンスで Amazon ECS 対応AMIを実行している場合は、「[Amazon ECS 対応 AMI での Amazon ECS コンテナエージェントのアップデート](agent-update-ecs-ami.md)」を参照してください。
   + コンテナインスタンスで Amazon ECS 対応AMI を実行してない場合は、「[Amazon ECS コンテナエージェントの手動更新（Amazon ECS 最適化以外の AMI の場合）](manually_update_agent.md)」を参照してください。
**重要**  
Amazon ECS 対応AMIで Amazon ECSエージェントバージョンを v1.0.0 より古いバージョンから更新するには、現行のコンテナインスタンスを終了し、最新バージョンの AMI で新しいインスタンスを起動することをお勧めします。プレビューバージョンを使用しているコンテナインスタンスは削除し、最新バージョンの AMI に置き換える必要があります。詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。

------
#### [ Amazon ECS container agent introspection API  ]

また、コンテナインスタンス自体からAmazon ECS コンテナエージェントの詳細分析 API のバージョンを確認するために使用できます。詳細については、「[Amazon ECS コンテナの詳細分析](ecs-agent-introspection.md)」を参照してください。

**詳細分析 API を使用して、Amazon ECS コンテナエージェントで最新バージョンが実行されているかどうかを確認するには**

1. SSH 経由でコンテナインスタンスにログインします。

1. 詳細分析 API をクエリします。

   ```
   [ec2-user ~]$ curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```
**注記**  
詳細分析 API は`Version` 情報を Amazon ECS コンテナエージェントのバージョン v1.0.0 に追加しました。詳細分析 API をクエリして `Version` が存在しない場合、または詳細分析 API 自体がエージェントに存在しない場合、実行しているバージョンが v0.0.3 以前であり、更新する必要があります。

------

# Amazon ECS 対応 AMI での Amazon ECS コンテナエージェントのアップデート
<a name="agent-update-ecs-ami"></a>

Amazon ECS対応AMI を使用している場合は、いくつかの方法で最新バージョンの Amazon ECS コンテナエージェントを取得できます (推奨される順に示します)。
+ 現在のコンテナインスタンスを終了して Amazon ECS 対応 Amazon Linux 2 AMI最新バージョンを起動します (手動で起動するか、最新の AMI で自動スケーリング起動設定を更新して起動します)。これにより、最新のテスト済みおよび検証済みバージョンの Amazon Linux、Docker、`ecs-init`、および Amazon ECS コンテナエージェントを備えたの新しいコンテナインスタンスが提供されます。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。
+ インスタンスに SSH で接続し、`ecs-init` パッケージ (および依存関係) を最新バージョンに更新します。このオペレーションにより、Amazon Linux リポジトリで最新のテスト済みおよび検証済みバージョンの Docker と `ecs-init`、およびAmazon ECS コンテナエージェントの最新バージョンが提供されます。詳細については、「[Amazon ECS対応 &AMI; の `ecs-init` パッケージを更新するには](#procedure_update_ecs-init)」を参照してください。
+ コンソールまたは AWS CLI や AWS SDK 経由で `UpdateContainerAgent` API オペレーションを使用し、コンテナエージェントを更新します。詳細については、「[`UpdateContainerAgent` API オペレーションで Amazon ECS コンテナエージェントを更新する](#agent-update-api)」を参照してください。

**注記**  
エージェント更新は Windows コンテナインスタンスに適用されません。Windows クラスター内のエージェントバージョンを更新するには、新しいコンテナインスタンスを起動することをお勧めします。<a name="procedure_update_ecs-init"></a>

**Amazon ECS対応 &AMI; の `ecs-init` パッケージを更新するには**

1. SSH 経由でコンテナインスタンスにログインします。

1. 次のコマンドを使用して、`ecs-init` パッケージを更新します。

   ```
   sudo yum update -y ecs-init
   ```
**注記**  
`ecs-init` パッケージと Amazon ECS コンテナエージェントが即座に更新されます。ただし、新しいバージョンの Docker は、Docker デーモンを再起動するまでロードされません。インスタンスを再起動するか、インスタンスで次のコマンドを実行して、再起動します。  
Amazon ECS に最適化された Amazon Linux 2 AMI  

     ```
     sudo systemctl restart docker
     ```
Amazon ECS に最適化された Amazon Linux AMI  

     ```
     sudo service docker restart && sudo start ecs
     ```

## `UpdateContainerAgent` API オペレーションで Amazon ECS コンテナエージェントを更新する
<a name="agent-update-api"></a>

**重要**  
-`UpdateContainerAgent`API は、Amazon ECS に最適化された AMI の Linux バリアントでのみサポートされます。ただし、Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI は例外です。Amazon ECS に最適化された Amazon Linux 2 (arm64) AMI を使用するコンテナインスタンスの場合、`ecs-init`パッケージを使用してエージェントを更新します。他のオペレーティングシステムを実行しているコンテナインスタンスについては、「[Amazon ECS コンテナエージェントの手動更新（Amazon ECS 最適化以外の AMI の場合）](manually_update_agent.md)」を参照してください。Windows コンテナインスタンスを使用している場合は、新しいコンテナインスタンスを起動して、Windows クラスター内のエージェントバージョンを更新することをお勧めします。

`UpdateContainerAgent`API 処理は、コンソールまたは AWS CLI または AWS SDKを使ってエージェントのアップデートを要求したときに始まります。Amazon ECS は、現在のエージェントバージョンと使用可能な最新バージョンを比較し、更新が可能かどうかを確認します。更新が利用できない場合 (例えばすでに最新バージョンがエージェントで実行されている場合) は、`NoUpdateAvailableException` が返されます。

上に示した更新プロセスのステージは、次のとおりです。

`PENDING`  
エージェントを更新できます。更新プロセスが開始されました。

`STAGING`  
エージェントで、エージェントの更新のダウンロードが開始されています。エージェントで更新をダウンロードできない場合や、更新の内容が正しくないか破損している場合、エージェントは失敗通知を送信し、更新は `FAILED` 状態に遷移します。

`STAGED`  
エージェントのダウンロードが完了し、エージェントの内容が確認されました。

`UPDATING`  
`ecs-init` サービスが再起動され、新しいエージェントバージョンが取得されます。エージェントが何らかの理由で再起動できない場合、更新は `FAILED` 状態に遷移します。それ以外の場合は、エージェントから Amazon ECS に更新完了のシグナルが送信されます。

**注記**  
エージェント更新は Windows コンテナインスタンスに適用されません。Windows クラスター内のエージェントバージョンを更新するには、新しいコンテナインスタンスを起動することをお勧めします。

**Amazon ECSに最適化されたAMIのAmazon ECS コンテナエージェントをコンソールでアップデートするには**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、外部インスタンスが存在するリージョンを選択します。

1. ナビゲーションペインで、[**Clusters**] を選択し、クラスターを選択します。

1. **[Cluster : *name*]** (クラスター: 名前) のページで、**[Infrastructure]** (インフラストラクチャ) タブを選択します。

1. **[コンテナインスタンス]** で、更新するインスタンスを選択し、**[アクション]**、**[エージェントの更新]** を選択します。

# Amazon ECS コンテナエージェントの手動更新（Amazon ECS 最適化以外の AMI の場合）
<a name="manually_update_agent"></a>

場合によっては、バグの修正や新機能を取得するために Amazon ECS コンテナエージェントを更新する必要があります。Amazon ECS コンテナエージェントの更新によって、コンテナインスタンスで実行中のタスクやサービスが中断されることはありません。
**注記**  
エージェント更新は Windows コンテナインスタンスに適用されません。Windows クラスター内のエージェントバージョンを更新するには、新しいコンテナインスタンスを起動することをお勧めします。

1. SSH 経由でコンテナインスタンスにログインします。

1. エージェントが `ECS_DATADIR` 環境変数を使用して状態を保存しているかどうかを確認します。

   ```
   ubuntu:~$ docker inspect ecs-agent | grep ECS_DATADIR
   ```

   出力:

   ```
   "ECS_DATADIR=/data",
   ```
**重要**  
前のコマンドで `ECS_DATADIR` 環境変数が返されない場合は、エージェントを更新する前に、このコンテナインスタンスで実行されているタスクをすべて停止する必要があります。より新しいエージェントは `ECS_DATADIR` 環境変数を使用して状態を保存するため、タスクが実行中でも問題なく更新できます。

1. Amazon ECS コンテナエージェントを停止します。

   ```
   ubuntu:~$ docker stop ecs-agent
   ```

1. エージェントコンテナを削除します。

   ```
   ubuntu:~$ docker rm ecs-agent
   ```

1. `/etc/ecs` ディレクトリと Amazon ECS コンテナエージェント設定ファイルが `/etc/ecs/ecs.config` に存在することを確認します。

   ```
   ubuntu:~$ sudo mkdir -p /etc/ecs && sudo touch /etc/ecs/ecs.config
   ```

1. `/etc/ecs/ecs.config` ファイルを編集して、少なくとも以下の変数宣言が必ず含まれるようにします。コンテナインスタンスをデフォルトのクラスターに登録しない場合は、クラスター名を `ECS_CLUSTER` の値として指定します。

   ```
   ECS_DATADIR=/data
   ECS_ENABLE_TASK_IAM_ROLE=true
   ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true
   ECS_LOGFILE=/log/ecs-agent.log
   ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
   ECS_LOGLEVEL=info
   ECS_CLUSTER=default
   ```

   これらや他のエージェントランタイムオプションの詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
**注記**  
オプションで、エージェント環境変数を Amazon S3 に保存できます (これらの環境変数は、Amazon EC2 ユーザーデータを使用して、起動時にコンテナインスタンスにダウンロードできます)。これは、プライベートリポジトリの認証情報のような機密情報の場合に推奨されます。詳細については、「[Amazon S3 に Amazon ECS コンテナインスタンスの設定を保存する](ecs-config-s3.md)」および「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。

1. Amazon Elastic Container Registry Public から最新の Amazon ECS コンテナエージェントイメージを取得します。

   ```
   ubuntu:~$ docker pull public.ecr.aws/ecs/amazon-ecs-agent:latest
   ```

   出力:

   ```
   Pulling repository amazon/amazon-ecs-agent
   a5a56a5e13dc: Download complete
   511136ea3c5a: Download complete
   9950b5d678a1: Download complete
   c48ddcf21b63: Download complete
   Status: Image is up to date for amazon/amazon-ecs-agent:latest
   ```

1. コンテナインスタンスで最新の Amazon ECS コンテナエージェントを実行します。
**注記**  
Docker 再起動ポリシーまたはプロセスマネージャー (**upstart** または **systemd** など) を使用してコンテナエージェントをサービスまたはデーモンとして扱い、終了後に確実に再起動されるようにします。Amazon ECS に最適化された AMI はこのために `ecs-init` RPM を使用します。この[[RPM のソースコード](https://github.com/aws/amazon-ecs-init)]は、GitHub で参照できます。

   次のエージェント実行コマンドの例は、各オプションを示すために複数の行に分けられています。これらや他のエージェントランタイムオプションの詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
**重要**  
SELinux 対応オペレーティングシステムでは、**docker run** コマンドに `--privileged` オプションが必要です。さらに、SELinux 対応コンテナインスタンスの場合は、`/log` および `/data` ボリュームマウントに `:Z` オプションを追加することをお勧めします。ただし、コマンドを実行する前に、これらのボリュームのホストマウントが存在する必要があります。存在しないと、`no such file or directory` エラーが発生します。SELinux 対応コンテナインスタンスで Amazon ECS エージェントの実行に問題が発生する場合は、次のアクションを実行します。  
コンテナインスタンスにホストボリュームマウントポイントを作成します。  

     ```
     ubuntu:~$ sudo mkdir -p /var/log/ecs /var/lib/ecs/data
     ```
`--privileged` オプションを次の **docker run** コマンドに追加します。
以下の **docker run** コマンドで、`/log` および `/data` コンテナボリュームマウントに `:Z` オプションを追加します (`--volume=/var/log/ecs/:/log:Z` など)。

   ```
   ubuntu:~$ sudo docker run --name ecs-agent \
   --detach=true \
   --restart=on-failure:10 \
   --volume=/var/run:/var/run \
   --volume=/var/log/ecs/:/log \
   --volume=/var/lib/ecs/data:/data \
   --volume=/etc/ecs:/etc/ecs \
   --volume=/etc/ecs:/etc/ecs/pki \
   --net=host \
   --env-file=/etc/ecs/ecs.config \
   amazon/amazon-ecs-agent:latest
   ```
**注記**  
`Error response from daemon: Cannot start container` メッセージが表示された場合は、**sudo docker rm ecs-agent** コマンドを使用して障害のあるコンテナを削除し、再度エージェントの実行を試みることができます。

# Amazon ECS に最適化された Windows AMI
<a name="ecs-optimized_windows_AMI"></a>

Amazon ECS に最適化された AMI には、Amazon ECS ワークロードの実行に必要なコンポーネントがあらかじめ設定されています。Amazon ECSで一元化されたワークロードを実行するために必要な基本的な仕様を満たす独自のコンテナインスタンス AMI を作成することはできますが、Amazon ECS に最適化された AMI は事前設定され、AWS エンジニアにより Amazon ECS でテストされています。これは最も簡単に開始できる方法であり、AWS でコンピューティングリソースをすばやく実行できます。

Amazon ECS に最適化された AMI メタデータ (各バリアントの AMI 名、Amazon ECS コンテナエージェントバージョン、Docker バージョンを含む Amazon ECS ランタイムバージョンなど) は、プログラムで取得できます。詳細については、「[Amazon ECS に最適化された Windows AMI メタデータを取得する](retrieve-ecs-optimized_windows_AMI.md)」を参照してください。

**重要**  
 2022 年 8 月以降に作成された ECS に最適化された AMI バリアントはすべて Docker EE (Mirantis) から Docker CE (Moby プロジェクト) に移行されます。  
お客様がデフォルトで最新のセキュリティ更新を受けられるように、Amazon ECS は Windows ECS に最適化された AMI を 3 つ以上維持しています。Amazon ECS は、新しい Windows Amazon ECS に最適化された AMI をリリースした後、古いプライベートである Windows Amazon ECS に最適化された AMI を作成します。アクセスが必要なプライベート AMI がある場合は、クラウドSupport のチケットを提出してください。

## Amazon ECS に最適化された AMI バリアント
<a name="ecs-optimized-ami-variants"></a>

Amazon EC2 インスタンスでは、Amazon ECS に最適化された AMI の次の Windows Server バリアントを使用できます。

**重要**  
8 月以降に製造された ECS に最適化された AMI バリアントはすべて Docker EE (Mirantis) から Docker CE (Moby プロジェクト) に移行される予定です。
+ **Amazon ECS に最適化された Windows Server 2025 Full AMI** 
+ **Amazon ECS に最適化された Windows Server 2025 Core AMI** 
+ **Amazon ECS に最適化された Windows Server 2022 Full AMI** 
+ **Amazon ECS に最適化された Windows Server 2022 Core AMI** 
+ **Amazon ECS に最適化された Windows Server 2019 Full AMI** 
+ **Amazon ECS に最適化された Windows Server 2019 Core AMI** 
+ **Amazon ECS に最適化された Windows Server 2016 Full AMI**

**重要**  
Windows Server 2016 は、25.x.x などの最新の Docker バージョンをサポートしていません。そのため、Windows Server 2016 Full AMI には Docker ランタイムに対するセキュリティパッチやバグパッチは適用されません。次の Windows プラットフォームのいずれかに移行することをお勧めします。  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

2022 年 8 月 9 日、Amazon ECS に最適化された Windows Server 20H2 Core AMI はサポートを終了しました。この AMI の新しいバージョンはリリースされません。詳細については、「[Windows Server のリリース情報](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info)」を参照してください。

Windows Server 2025、Windows Server 2022、Windows Server 2019 および Windows Server 2016 は、長期サービスチャネル (LTSC) リリースです。Windows Server 20H2 は、半期チャネル (SAC) リリースです。詳細については、「[Windows Server のリリース情報](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info)」を参照してください。

### 考慮事項
<a name="windows_caveats"></a>

以下は、Amazon EC2 Windows コンテナと Amazon ECS についての留意点です。
+ Windows コンテナは Linux コンテナインスタンスでは実行できません。逆の場合も同様です。Windows タスクと Linux タスクをより適切に配置するには、Windows コンテナインスタンスと Linux コンテナインスタンスを別々のクラスターに保持し、Windows タスクは Windows クラスターにのみ配置します。次の配置制約 `memberOf(ecs.os-type=='windows')` を設定して、Windows のタスク定義が Windows インスタンスのみに配置されるようにする必要があります。
+ Windows コンテナは、EC2 および Fargate を使用するタスクでサポートされています。
+ Windows コンテナとコンテナインスタンスでは、Linux コンテナとコンテナインスタンス用のタスク定義パラメータは全面的にはサポートされていません。まったくサポートされないパラメータもあり、Windows での動作と Linux での動作が異なるパラメータもあります。詳細については、「[Windows を実行している EC2 インスタンスでの Amazon ECS タスク定義の違い](windows_task_definitions.md)」を参照してください。
+ タスクの IAM ロール 機能については、起動時に機能を許可するように Windows コンテナインスタンスを設定する必要があります。コンテナは、この機能を使用するときに、指定された PowerShell コードの一部を実行する必要があります。詳細については、「[Amazon EC2 Windows インスタンスの追加設定](task-iam-roles.md#windows_task_IAM_roles)」を参照してください。
+ タスク用の IAM ロール の機能では認証情報プロキシを使用してコンテナに認証情報を提供します。この認証情報プロキシは、コンテナインスタンスのポート 80 を占有するため、タスク用の IAM ロール を使用する場合、タスクにポート 80 を使用することができません。ウェブサービスコンテナの場合は、 Application Load Balancer と動的なポートマッピングを使用して標準の HTTP ポート 80 接続をコンテナに提供できます。詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](service-load-balancing.md)」を参照してください。
+ Windows サーバーのドッカーイメージは大きめです (9 GiB)。そのため、Windows コンテナインスタンスには Linux コンテナインスタンスよりも多くのストレージスペースが必要です。
+ Windows Server で Windows コンテナを実行するには、コンテナのベースイメージの OS バージョンがホストのバージョンと一致する必要があります。詳細については、マイクロソフトのドキュメント Web サイトの「[Windows コンテナバージョンの互換性](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11)」を参照してください。クラスターが複数の Windows バージョンを実行している場合、次の配置制約を使用して、同じバージョンで実行されている EC2 インスタンスにタスクが配置されるようにすることができます: `memberOf(attribute:ecs.os-family == WINDOWS_SERVER_<OS_Release>_<FULL or CORE>)`。詳細については、「[Amazon ECS に最適化された Windows AMI メタデータを取得する](retrieve-ecs-optimized_windows_AMI.md)」を参照してください。

# Amazon ECS に最適化された Windows AMI メタデータを取得する
<a name="retrieve-ecs-optimized_windows_AMI"></a>

Amazon ECS に最適化された AMI の各バリアントの AMI ID、イメージ名、オペレーティングシステム、コンテナエージェントバージョン、ランタイムバージョンは、Systems Manager パラメータストア API のクエリを実行してプログラムで取得できます。Systems Manager パラメータストア API の詳細については、「[GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)」および「[GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html)」を参照してください。

**注記**  
Amazon ECS に最適化された AMI メタデータを取得するには、管理ユーザーに次の IAM アクセス権限が必要です。`AmazonECS_FullAccess` IAM ポリシーには、次の許可が追加されています。  
ssm:GetParameters
ssm:GetParameter
ssm:GetParametersByPath

## Systems Manager パラメータストアのパラメータフォーマット
<a name="ecs-optimized-ami-parameter-format"></a>

**注記**  
以下の Systems Manager Parameter Store API パラメータは廃止されているため、最新の Windows AMI の取得には使用しないでください。  
`/aws/service/ecs/optimized-ami/windows_server/2016/english/full/recommended/image_id `
`/aws/service/ecs/optimized-ami/windows_server/2019/english/full/recommended/image_id`

以下は、各 Amazon ECS に最適化された AMI バリアントのパラメータ名のフォーマットです。
+ Windows Server 2025 Full AMI メタデータ:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
  ```
+ Windows Server 2025 Core AMI メタデータ:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
  ```
+ Windows Server 2022 Full AMI メタデータ:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
  ```
+ Windows Server 2022 Core AMI メタデータ:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
  ```
+ Windows Server 2019 フル AMI メタデータ:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
  ```
+ Windows Server 2019 コア AMI メタデータ:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
  ```
+ Windows Server 2016 フル AMI メタデータ:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
  ```

次のパラメーター名の形式は、最新の安定した Windows Server 2019 Full AMI のメタデータを取得します

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```

以下は、パラメータ値で返る JSON オブジェクトの例です。

```
{
    "Parameters": [
        {
            "Name": "/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
            "Type": "String",
            "Value": "{\"image_name\":\"Windows_Server-2019-English-Full-ECS_Optimized-2023.06.13\",\"image_id\":\"ami-0debc1fb48e4aee16\",\"ecs_runtime_version\":\"Docker (CE) version 20.10.21\",\"ecs_agent_version\":\"1.72.0\"}",
            "Version": 58,
            "LastModifiedDate": "2023-06-22T19:37:37.841000-04:00",
            "ARN": "arn:aws:ssm:us-east-1::parameter/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
            "DataType": "text"
        }
    ],
    "InvalidParameters": []
}
```

上記の出力の各フィールドは、サブパラメータとしてクエリに利用できます。サブパラメータのパラメータパスを構築するには、選択した AMI のパスにサブパラメータ名を追加します。以下のサブパラメータが利用可能です。
+ `schema_version`
+ `image_id`
+ `image_name`
+ `os`
+ `ecs_agent_version`
+ `ecs_runtime_version`

## 例
<a name="ecs-optimized-ami-windows-parameter-examples"></a>

以下の例は、それぞれの Amazon ECS に最適化された AMI バリアントのメタデータを取得する方法を示しています。

### 安定している最新の Amazon ECS に最適化された AMI メタデータを取得する
<a name="ecs-optimized-ami-windows-parameter-examples-1"></a>

安定している最新の Amazon ECS に最適化された AMI を取得するには、AWS CLI で次の AWS CLI コマンドを使用します。
+ **Amazon ECS に最適化された Windows Server 2025 Full AMI**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Amazon ECS に最適化された Windows Server 2025 Core AMI**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Amazon ECS に最適化された Windows Server 2022 Full AMI**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Amazon ECS に最適化された Windows Server 2022 Core AMI**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Amazon ECS に最適化された Windows Server 2019 Full AMI**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Amazon ECS に最適化された Windows Server 2019 Core AMI**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Amazon ECS に最適化された Windows Server 2016 Full AMI**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized --region us-east-1
  ```

### CloudFormation テンプレートの推奨される最新の Amazon ECS に最適化された AMI を使用する
<a name="ecs-optimized-ami-windows-parameter-examples-5"></a>

Systems Manager パラメータストア名を参照することにより、CloudFormation テンプレートで推奨される最新の Amazon ECS に最適化された AMI を参照できます。

```
Parameters:
  LatestECSOptimizedAMI:
    Description: AMI ID
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized/image_id
```

# Amazon ECS に最適化された Windows AMI バージョン
<a name="ecs-windows-ami-versions"></a>

Amazon ECS に最適化された AMI の現在のバージョンと以前のバージョン、それらに対応する Amazon ECS コンテナエージェント、Docker、`ecs-init` パッケージのバージョンを表示します。

AMI ID を含む、Amazon ECS に最適化された AMI のメタデータでは、各バリアントをプログラム的に取得することができます。詳細については、「[Amazon ECS に最適化された Windows AMI メタデータを取得する](retrieve-ecs-optimized_windows_AMI.md)」を参照してください。

次のタブには、Windows Amazon ECS に最適化された AMI のバージョンの一覧が表示されます。CloudFormation テンプレートで Systems Manager パラメータストアのパラメータを参照する方法については、[CloudFormation テンプレートの推奨される最新の Amazon ECS に最適化された AMI を使用する](retrieve-ecs-optimized_AMI.md#ecs-optimized-ami-parameter-examples-5) を参照してください。

**重要**  
お客様がデフォルトで最新のセキュリティ更新を受けられるように、Amazon ECS は Windows ECS に最適化された AMI を 3 つ以上維持しています。Amazon ECS は、新しい Windows Amazon ECS に最適化された AMI をリリースした後、古いプライベートである Windows Amazon ECS に最適化された AMI を作成します。アクセスが必要なプライベート AMI がある場合は、クラウドSupport のチケットを提出してください。  
Windows Server 2016 は、25.x.x などの最新の Docker バージョンをサポートしていません。そのため、Windows Server 2016 Full AMI には Docker ランタイムに対するセキュリティパッチやバグパッチは適用されません。次の Windows プラットフォームのいずれかに移行することをお勧めします。  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

**注記**  
gMSA プラグインのログ記録は、2025 年 8 月の AMI リリースで、ファイルベースのログ記録 `(C:\ProgramData\Amazon\gmsa)` から Windows Event logging  に移行されました。パブリックログコレクタースクリプトは、すべての gMSA ログを収集します。詳細については、「[Amazon ECS ログコレクターを使用したコンテナログの収集](ecs-logs-collector.md)」を参照してください。

------
#### [ Windows Server 2025 Full AMI versions ]

下の表は、Amazon ECS に最適化された Windows Server 2025 Full AMI の現在のバージョンと以前のバージョン、およびそれらに対応するバージョンの Amazon ECS コンテナエージェントと Docker のリスト表示です。


|  Amazon ECS に最適化された Windows Server 2025 Full AMI  |  Amazon ECS コンテナエージェントバージョン  |  Docker バージョン  |  [可視性]  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.07.16**  |  `1.96.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.06.13**  |  `1.94.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

現在の Amazon ECS に最適化された Windows Server 2025 Full AMI は、AWS CLI の次のコマンドで取得できます。

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2025 Core AMI versions ]

下の表は、Amazon ECS に最適化された Windows Server 2025 Core AMI の現在のバージョンと以前のバージョン、およびそれらに対応するバージョンの Amazon ECS コンテナエージェントと Docker のリスト表示です。


|  Amazon ECS に最適化された Windows Server 2025 Core AMI  |  Amazon ECS コンテナエージェントバージョン  |  Docker バージョン  |  [可視性]  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.07.16**  |  `1.96.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.06.13**  |  `1.94.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

現在の Amazon ECS に最適化された Windows Server 2025 Core AMI は、AWS CLI の次のコマンドで取得できます。

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2022 Full AMI versions ]

下の表は、Amazon ECS に最適化された Windows Server 2022 Full AMI の現在のバージョンと以前のバージョン、およびそれらに対応するバージョンの Amazon ECS コンテナエージェントと Docker のリスト表示です。


|  Amazon ECS に最適化された Windows Server 2022 Full AMI  |  Amazon ECS コンテナエージェントバージョン  |  Docker バージョン  |  [可視性]  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

現在の Amazon ECS に最適化された Windows Server 2022 Full AMI は、AWS CLI の次のコマンドで取得できます。

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2022 Core AMI versions ]

下の表は、Amazon ECS に最適化された Windows Server 2022 Core AMI の現在のバージョンと以前のバージョン、およびそれらに対応するバージョンの Amazon ECS コンテナエージェントと Docker のリスト表示です。


|  Amazon ECS に最適化された Windows Server 2022 Core AMI  |  Amazon ECS コンテナエージェントバージョン  |  Docker バージョン  |  [可視性]  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

現在の Amazon ECS に最適化された Windows Server 2022 Full AMI は、AWS CLI の次のコマンドで取得できます。

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2019 Full AMI versions ]

下の表は、Amazon ECS に最適化された Windows Server 2019 Full AMI の現在のバージョンと以前のバージョン、およびそれらに対応するバージョンの Amazon ECS コンテナエージェントと Docker のリスト表示です。


|  Amazon ECS に最適化された Windows Server 2019 Full AMI  |  Amazon ECS コンテナエージェントバージョン  |  Docker バージョン  |  [可視性]  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

現在の Amazon ECS に最適化された Windows Server 2019 Full AMI は、AWS CLI の次のコマンドで取得できます。

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2019 Core AMI versions ]

下の表は、Amazon ECS に最適化された Windows Server 2019 Core AMI の現在のバージョンと以前のバージョン、およびそれらに対応するバージョンの Amazon ECS コンテナエージェントと Docker のリスト表示です。


|  Amazon ECS に最適化された Windows Server 2019 Core AMI  |  Amazon ECS コンテナエージェントバージョン  |  Docker バージョン  |  [可視性]  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

現在の Amazon ECS に最適化された Windows Server 2019 Full AMI は、AWS CLI の次のコマンドで取得できます。

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2016 Full AMI versions ]

**重要**  
Windows Server 2016 は、25.x.x などの最新の Docker バージョンをサポートしていません。そのため、Windows Server 2016 Full AMI には Docker ランタイムに対するセキュリティパッチやバグパッチは適用されません。次の Windows プラットフォームのいずれかに移行することをお勧めします。  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

下の表は、Amazon ECS に最適化された Windows Server 2016 Full AMI の現在のバージョンと以前のバージョン、およびそれらに対応するバージョンの Amazon ECS コンテナエージェントと Docker のリスト表示です。


|  Amazon ECS に最適化された Windows Server 2016 Full AMI  |  Amazon ECS コンテナエージェントバージョン  |  Docker バージョン  |  [可視性]  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `20.10.23 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.08.16**  |  `1.97.1`  |  `20.10.23 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `20.10.23 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.06.13**  |  `1.94.0`  |  `20.10.23 (Docker CE)`  |  Public  | 

次の AWS CLI Amazon ECS に最適化された Windows Server 2016 Full AMI を使用します。

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```

------

# Amazon ECS に最適化された独自の Windows AMI の作成
<a name="windows-custom-ami"></a>

EC2 Image Builder を使用して、Amazon ECS に最適化された独自のカスタム Windows AMI を構築します。これにより、Amazon ECS の独自のライセンスを持つ Windows AMI を簡単に使用できます。Amazon ECS は、コンテナをホストするために Windows インスタンスを実行するために必要なシステム設定を行うマネージド Image Builder コンポーネントを提供します。各 Amazon ECS マネージドコンポーネントには、特定のコンテナエージェントと Docker バージョンが含まれます。最新の Amazon ECS マネージドコンポーネントを使用するようにイメージをカスタマイズできます。また、古いコンテナエージェントまたは Docker バージョンが必要な場合は、別のコンポーネントを指定できます。

EC2 Image Builder 全体の使用に関するチュートリアルについては、「*EC2 Image Builder ユーザーガイド*」の[「EC2 Image Builder入門」](https://docs.aws.amazon.com/imagebuilder/latest/userguide/set-up-ib-env.html#image-builder-accessing-prereq)を参照してください。

EC2 Image Builder を使ってAmazon ECS に最適化された Windows AMI を構築する場合は、イメージ recipe を作成します。イメージ recipe は、次の要件を満たしている必要があります。
+ **[ソースイメージ]** は、Windows Server 2019 Core、Windows Server 2019 Full、Windows Server 2022 Core、または Windows Server 2022 Full に基づいている必要があります。その他の Windows オペレーティングシステムはサポートされておらず、コンポーネントと互換性がない可能性があります。
+ **ビルドコンポーネント**を指定する場合、`ecs-optimized-ami-windows` コンポーネントは必須です。`update-windows` コンポーネントをお勧めします。これにより、イメージに最新のセキュリティ更新プログラムが含まれるようになります。

  別のコンポーネントバージョンを指定するには、[**Versioning options**] メニューを展開し、使用するコンポーネントバージョンを指定します。詳細については、「[`ecs-optimized-ami-windows` コンポーネントバージョンの一覧表示](#windows-component-list)」を参照してください。

## `ecs-optimized-ami-windows` コンポーネントバージョンの一覧表示
<a name="windows-component-list"></a>

EC2 Image Builder recipe を作成して `ecs-optimized-ami-windows` コンポーネントを指定するときは、デフォルトのオプションを使用するか、特定のコンポーネントバージョンを指定できます。コンポーネント内に含まれる Amazon ECS コンテナエージェントおよび Docker バージョンとともに、使用可能なコンポーネントバージョンを確認するには、AWS マネジメントコンソール を使用します。

**使用可能な `ecs-optimized-ami-windows` コンポーネントバージョンを一覧表示するには**

1. で EC2 Image Builder コンソールを開きます。[https://console.aws.amazon.com/imagebuilder/](https://console.aws.amazon.com/imagebuilder/)。

1. ナビゲーションバーで、イメージを構築しているリージョンを選択します。

1. ナビゲーションペインの [**Saved configurations**] メニューで、[**Components**] を選択します。

1. [**Components**] ページの検索バーに `ecs-optimized-ami-windows` を入力して認証情報メニューをプルダウンし、[**Quick start (Amazon-managed)**] を選択します。

1. [**説明**] 列を用いて、Amazon ECS コンテナエージェントを使用したコンポーネントのバージョンと、イメージに必要なバージョンの Docker バージョンを特定します。

# Amazon ECS Windows コンテナインスタンスの管理
<a name="manage-windows"></a>

Amazon ECS ワークロードに EC2 インスタンスを使用する場合、インスタンスの維持はユーザーの責任となります。

エージェント更新は Windows コンテナインスタンスに適用されません。Windows クラスター内のエージェントバージョンを更新するには、新しいコンテナインスタンスを起動することをお勧めします。

**Topics**
+ [コンテナインスタンスの起動](launch_window-container_instance.md)
+ [コンテナインスタンスのブートストラップ](bootstrap_windows_container_instance.md)
+ [Windows コンテナインスタンスに HTTP プロキシを使用する](http_proxy_config-windows.md)
+ [スポットインスタンス通知を受信するようにコンテナインスタンスを設定する](windows-spot-instance-draining-container.md)

# Amazon ECS Windows コンテナインスタンスの起動
<a name="launch_window-container_instance"></a>

Amazon ECS コンテナインスタンスは、Amazon EC2 コンソールを使用して作成されます。開始する前に、[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md) のステップを完了するようにしてください。

起動ウィザードの詳細については、「*Amazon EC2 ユーザーガイド*」の「[新しいインスタンス起動ウィザードを使用してインスタンスを起動する](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-launch-instance-wizard.html)」を参照してください。

新しい Amazon EC2 ウィザードを使用してインスタンスを起動できます。パラメータには次のリストを使用できます。リストされていないパラメータは、デフォルトのままにしてください。次の手順では、各パラメータグループについて説明します。

## 手順
<a name="liw-initiate-instance-launch"></a>

開始する前に、「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」のステップを完了します。

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. 画面の上のナビゲーションバーで、現在の AWS リージョンが表示されます (例: 米国東部 (オハイオ))。インスタンスを起動するリージョンを選択します。一部の Amazon EC2 リソースはリージョン間で共有できるため、この選択は重要です。

1. Amazon EC2 コンソールダッシュボードで、[**インスタンスを起動**] を選択してください。

## 名前とタグ
<a name="liw-name-and-tags"></a>

インスタンス名はタグで、キーは **[Name]** (名前)、値は指定した名前です。インスタンス、ボリューム、および伸縮自在なグラフィックスにタグ付けできます。スポットインスタンスの場合、スポットインスタンスリクエストにのみタグを付けることができます。

インスタンス名と追加のタグを指定することはオプションです。
+ **[Name]** (名前) に、インスタンスのわかりやすい名前を入力します。名前を指定しない場合は、インスタンスをその ID で識別できます。ID は、インスタンスの起動時に自動的に生成されます。
+ タグを追加するには、**[Add additional tag]** (追加のタグを追加) を選択します。**[Add tag]** (タグを追加) を選択し、キーと値を入力し、タグ付けするリソースタイプを選択します。追加するタグごとに **[Add tag]** (タグの追加) を選択します。

## アプリケーションと OS イメージ (Amazon マシンイメージ)
<a name="liw-ami"></a>

Amazon マシンイメージ (AMI) には、インスタンスの作成に必要な情報が含まれています。例えば、ある AMI には、ウェブサーバーとして動作するために必要なソフトウェア (Apache やウェブサイトなど) が含まれています。

最新の Amazon ECS 最適化 AMI とその値については、「[Windows Amazon ECS-optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html)」(Windows Amazon ECS に最適化された AMI) を参照してください。

**[Search]** (検索) バーを使用して、AWS によって発行された適切な Amazon ECS 最適化 AMI を検索します。

1. 要件に基づいて、**[Search]** (検索) バーに次の AMI のいずれかを入力し、**[Enter]** を押します。
   + Windows\$1Server-2022-English-Full-ECS\$1Optimized
   + Windows\$1Server-2022-English-Core-ECS\$1Optimized
   + Windows\$1Server-2019-English-Full-ECS\$1Optimized
   + Windows\$1Server-2019-English-Core-ECS\$1Optimized
   + Windows\$1Server-2016-English-Full-ECS\$1Optimized

1. **[Choose an Amazon Machine Image (AMI])** (Amazon マシンイメージ (AMI) を選択) ページで、**[Community AMIs]** (コミュニティ AMI) タブを選択します。

1. 表示されるリストから、発行日が最新の Microsoft 検証済み AMI を選択し、**[Select]** (選択) をクリックします。

## インスタンスタイプ
<a name="liw-instance-type"></a>

インスタンスタイプは、インスタンスのハードウェア設定とサイズを定義します。インスタンスタイプが大きくなると、CPU およびメモリも増えます。詳細については、[インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)を参照してください。
+ **[Instance type]** (インスタンスタイプ) で、インスタンスのインスタンスタイプを選択します。

   選択したインスタンスタイプによって、タスクの実行に使用できるリソースが決まります。

## キーペア (ログイン)
<a name="liw-key-pair"></a>

**[Key pair name]** (キーペア名) には、既存のキーペアを選択するか、**[Create new key pair]** (新しいキーペアを作成) を選択して新しいキーペアを作成します。

**重要**  
[**Proceed without key pair**] (キーペアなしで進む) オプションを選択した場合 (非推奨)、ユーザーが別の方法でログインすることを許可するように設定された AMI を選択した場合でなければ、インスタンスに接続できなくなります。

## ネットワーク設定
<a name="liw-network-settings"></a>

必要に応じて、ネットワーク設定を設定します。
+ **[Networking platform]** (ネットワーキングプラットフォーム): **[Virtual Private Cloud (VPC)]** を選択して、**[Network interfaces]** (ネットワークインターフェイス) セクションでサブネットを指定します。
+ **[VPC]**: セキュリティグループを作成する既存の VPC を選択します。
+ [**サブネット**]: インスタンスは、アベイラビリティーゾーン、ローカルゾーン、Wavelength Zone、Outpost のいずれかに関連付けられたサブネットで起動できます。

  アベイラビリティーゾーンでインスタンスを起動するには、インスタンスを起動するサブネットを選択します。新しいサブネットを作成するには、[**Create new subnet**] を選択して Amazon VPC コンソールに移動します。終了したらインスタンス起動ウィザードに戻り、[Refresh] (更新) アイコンを選択して一覧にサブネットを読み込みます。

  ローカルゾーンでインスタンスを起動するには、ローカルゾーン内に作成したサブネットを選択します。

  アウトポストでインスタンスを起動するには、アウトポストに関連付けられた VPC 内のサブネットを選択します。
+ **[Auto-assign Public IP]** (パブリック IP の自動割り当て): インスタンスをインターネットからアクセス可能にする場合は、**[Auto-assign Public IP]** (パブリック IP の自動割り当て) フィールドが **[Enable]** (有効) に設定されていることを確認します。可能にしない場合には、このフィールドを [**無効**] に設定します。
**注記**  
コンテナインスタンスには、Amazon ECS サービスエンドポイントと通信するためのアクセスが必要です。これは、インターフェイス VPC エンドポイントを介して、またはパブリック IP アドレスを持つコンテナインスタンスを通じて可能になります。  
インターフェイス VPC エンドポイントについての詳細は、「[Amazon ECS とインターフェイス VPC エンドポイント (AWS PrivateLink)](vpc-endpoints.md)」を参照してください。  
インターフェイス VPC エンドポイントが設定されておらず、コンテナインスタンスがパブリック IP アドレスを持たない場合、ネットワークアドレス変換 (NAT) を使用してこのアクセスを提供する必要があります。詳細については、「*Amazon VPC ユーザーガイド*」の「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」、およびこのガイドの「[Amazon ECS Linux コンテナインスタンスに HTTP プロキシを使用する](http_proxy_config.md)」を参照してください。
+ **[Firewall (security groups)]** (ファイアウォール (セキュリティグループ)): セキュリティグループを使用して、コンテナインスタンスのファイアウォールルールを定義します。このルールでは、どの着信ネットワークトラフィックをコンテナインスタンスに配信するかを指定します。他のトラフィックはすべて無視されます。
  + 既存のセキュリティグループを選択するには、**[Select existing security group]** (既存のセキュリティグループを選択) を選択し、[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md) で作成したセキュリティグループを選択します。

## ストレージの設定
<a name="liw-storage"></a>

選択した AMI には、ルートボリュームを含む、1 つまたは複数のストレージボリュームが含まれます。インスタンスにアタッチする追加のボリュームを指定できます。

**[Simple]** (シンプル) ビューを使用できます。
+ **[Storage type]** (ストレージタイプ): コンテナインスタンスのストレージを設定します。

  Amazon ECS に最適化された Amazon Linux AMI を使用している場合、インスタンスには 2 つのボリュームが設定されます。[**Root**] ボリュームはオペレーティングシステム用で、2 番目の Amazon EBS ボリューム (`/dev/xvdcz` にアタッチ) は Docker 用です。

  オプションで、アプリケーションのニーズに合わせてインスタンスのボリュームサイズを増減できます。

## 高度な詳細
<a name="liw-advanced-details"></a>

[**Advanced details**] で、セクションを開いてフィールドを表示し、インスタンスの追加パラメータを指定します。
+ **[Purchasing option]** (購入のオプション): **[Request Spot Instances]** (スポットインスタンスのリクエスト) を選択して、スポットインスタンスをリクエストします。また、スポットインスタンスに関連する他のフィールドも設定する必要があります。詳細については、「[スポットインスタンスのリクエスト](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html)」を参照してください。
**注記**  
スポットインスタンスを使用していて、"`Not available`" メッセージが表示される場合は、別のインスタンスタイプを選択する必要があります。

  .
+ **[IAM instance profile]** (IAM インスタンスプロフィール): コンテナインスタンス IAM ロールを選択します。通常、これは `ecsInstanceRole` という名前です。
**重要**  
適切な IAM アクセス許可を使用してコンテナインスタンスを起動しないと、Amazon ECS エージェントはクラスターに接続できません。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
+ (オプション) **[User data]** (ユーザーデータ): [Amazon ECS コンテナエージェントの設定](ecs-agent-config.md) からのエージェント環境変数のようなユーザーデータを使用して、Amazon ECS コンテナインスタンスを設定します。Amazon EC2 ユーザーデータスクリプトはインスタンスの初回起動時に 1 回のみ実行されます。以下に、ユーザーデータを使用する目的の一般的な例を紹介します。
  + デフォルトでは、コンテナインスタンスはデフォルトのクラスターで起動されます。デフォルト以外のクラスターで起動するには、**[Advanced Details]** (高度な詳細) リストを選択します。次に、[**User data**] フィールドに以下のスクリプトを貼り付け、*your\$1cluster\$1name* を使用するクラスターの名前に置き換えます。

    `EnableTaskIAMRole`は、タスクの Task IAM ロール機能をオンにします。

    さらに、以下のオプションは、`awsvpc` ネットワークモードを使用する場合に使用できます。
    + `EnableTaskENI`: このフラグは、`awsvpc`ネットワークモードを使用する場合に、タスクネットワークをオンにします。
    + `AwsvpcBlockIMDS`: `awsvpc`ネットワークモードで実行中のタスクコンテナが IMDS にアクセスするのをブロックします。
    + `AwsvpcAdditionalLocalRoutes`: このオプションフラグを使用すると、タスクの名前空間に追加のルートを持つことができます。

      置換 `ip-address`を追加ルートの IP アドレス (例えば 172.31.42.23/32) に置き換えます。

    ```
    <powershell>
    Import-Module ECSTools
    Initialize-ECSAgent -Cluster your_cluster_name -EnableTaskIAMRole -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
    '["ip-address"]'
    </powershell>
    ```

# Amazon ECS Windows コンテナインスタンスをブートストラップしてデータを渡す
<a name="bootstrap_windows_container_instance"></a>

Amazon EC2 インスタンスを起動するときに、ユーザーデータを EC2 インスタンスに渡すことができます。インスタンスの起動時に、データを使って、一般的な自動設定タスクを実行したり、スクリプトを実行したりできます。Amazon ECS では、ユーザーデータの最も一般的なユースケースは、設定情報を Docker デーモンと Amazon ECS コンテナエージェントに渡すことです。

クラウドブートフック、シェルスクリプト、`cloud-init` ディレクティブなど、複数タイプのユーザーデータを Amazon EC2 に渡すことができます。これらおよびその他の形式の種類の詳細については、「[Cloud-Init のドキュメント](https://cloudinit.readthedocs.io/en/latest/explanation/format.html)」を参照してください。

Amazon EC2 起動ウィザードを使用するときに、このユーザーデータを渡すことができます。詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。

## デフォルト Windows ユーザーデータ
<a name="windows-default-userdata"></a>

このユーザーデータスクリプト例で、コンソールを使用する場合、Windows コンテナインスタンスが受け取るデフォルトのユーザーデータが確認できます。以下のスクリプトでは下記を実行します。
+ クラスター名に入力した名前を設定します。
+ タスクの IAM ロールを設定します。
+ `json-file` および `awslogs` を使用可能なロギングドライバーとして設定します。

さらに、以下のオプションは、`awsvpc` ネットワークモードを使用する場合に使用できます。
+ `EnableTaskENI`: このフラグは、`awsvpc`ネットワークモードを使用する場合に、タスクネットワークをオンにします。
+ `AwsvpcBlockIMDS`: このオプションのフラグは、`awsvpc`ネットワークモードで実行されているタスクコンテナに対する IMDS アクセスをブロックします。
+ `AwsvpcAdditionalLocalRoutes`: このオプションフラグを使用すると、追加のルートを持つことができます。

  置換 `ip-address`を追加ルートの IP アドレス (例えば 172.31.42.23/32) に置き換えます。

このスクリプトは、独自のコンテナインスタンスに使用できます (Amazon ECS 最適化　Windows Server AMI から起動される場合)。

`-Cluster cluster-name` 行を置き換えて、独自のクラスター名を指定します。

```
<powershell>
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
</powershell>
```

 `awslogs` ログドライバーを使用するように設定された Windows タスクの場合は、コンテナインスタンスで `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` 環境変数も設定する必要があります。以下の構文を使用します。

`-Cluster cluster-name` 行を置き換えて、独自のクラスター名を指定します。

```
<powershell>
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
</powershell>
```

## Windows エージェントのインストールユーザーデータ
<a name="agent-service-userdata"></a>

この例のユーザーデータスクリプトは、**Windows\$1Server-2016-English-Full-Containers** AMI で起動されたインスタンスにAmazon ECS コンテナエージェントをインストールします。これは、[Amazon ECS コンテナエージェントの GitHub リポジトリ](https://github.com/aws/amazon-ecs-agent) README ページのエージェントのインストール手順から変更されています。

**注記**  
このスクリプトは、サンプル目的で共有されます。Amazon ECS に最適化された Windows AMI を使用すると、Windows コンテナの使用を開始するほうが、はるかに簡単です。詳細については、「[Fargate ワークロード用の Amazon ECS クラスターを作成する](create-cluster-console-v2.md)」を参照してください。

Windows Server 2022 Full に Amazon ECS エージェントをインストールする方法については、GitHub の「[Issue 3753](https://github.com/aws/amazon-ecs-agent/issues/3753)」を参照してください。

このスクリプトは、独自のコンテナインスタンスに使用できます (それらのインスタンスが **Windows\$1Server-2016-English-Full-Containers** AMI のバージョンで起動される場合)。`windows` 行を置き換えて、独自のクラスターの名前を指定します (`windows` クラスターを使用しない場合)。

```
<powershell>
# Set up directories the agent uses
New-Item -Type directory -Path ${env:ProgramFiles}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS\data -Force
# Set up configuration
$ecsExeDir = "${env:ProgramFiles}\Amazon\ECS"
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", "windows", "Machine")
[Environment]::SetEnvironmentVariable("ECS_LOGFILE", "${env:ProgramData}\Amazon\ECS\log\ecs-agent.log", "Machine")
[Environment]::SetEnvironmentVariable("ECS_DATADIR", "${env:ProgramData}\Amazon\ECS\data", "Machine")
# Download the agent
$agentVersion = "latest"
$agentZipUri = "https://s3.amazonaws.com/amazon-ecs-agent/ecs-agent-windows-$agentVersion.zip"
$zipFile = "${env:TEMP}\ecs-agent.zip"
Invoke-RestMethod -OutFile $zipFile -Uri $agentZipUri
# Put the executables in the executable directory.
Expand-Archive -Path $zipFile -DestinationPath $ecsExeDir -Force
Set-Location ${ecsExeDir}
# Set $EnableTaskIAMRoles to $true to enable task IAM roles
# Note that enabling IAM roles will make port 80 unavailable for tasks.
[bool]$EnableTaskIAMRoles = $false
if (${EnableTaskIAMRoles}) {
  $HostSetupScript = Invoke-WebRequest https://raw.githubusercontent.com/aws/amazon-ecs-agent/master/misc/windows-deploy/hostsetup.ps1
  Invoke-Expression $($HostSetupScript.Content)
}
# Install the agent service
New-Service -Name "AmazonECS" `
        -BinaryPathName "$ecsExeDir\amazon-ecs-agent.exe -windows-service" `
        -DisplayName "Amazon ECS" `
        -Description "Amazon ECS service runs the Amazon ECS agent" `
        -DependsOn Docker `
        -StartupType Manual
sc.exe failure AmazonECS reset=300 actions=restart/5000/restart/30000/restart/60000
sc.exe failureflag AmazonECS 1
Start-Service AmazonECS
</powershell>
```

# Amazon ECS Windows コンテナインスタンスに HTTP プロキシを使用する
<a name="http_proxy_config-windows"></a>

Amazon ECS コンテナエージェントと Docker デーモンの両方に HTTP プロキシを使用するように Amazon ECS コンテナインスタンスを設定できます。これは、コンテナインスタンスに、Amazon VPC インターネットゲートウェイ、NAT ゲートウェイ、またはインスタンスを介した外部ネットワークアクセスがない場合に便利です。

Amazon ECS Windows コンテナインスタンスが HTTP プロキシを使用するように設定するには、起動時に (Amazon EC2ユーザーデータを使用して) 以下の変数を設定します。

`[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.mydomain:port", "Machine")`  
`HTTP_PROXY` を、Amazon ECS エージェントがインターネットへの接続に使用する HTTP プロキシのホスト名 (または IP アドレス) とポート番号に設定します。例えば、コンテナインスタンスに、Amazon VPC インターネットゲートウェイ、NAT ゲートウェイ、またはインスタンスを介した外部ネットワークアクセスがない場合です。

`[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")`  
`NO_PROXY` を `169.254.169.254,169.254.170.2,\\.\pipe\docker_engine` に設定して、EC2 インスタンスのメタデータ、タスク用の IAM ロール、および Docker デーモンのトラフィックをプロキシからフィルタリングします。

**Example Windows HTTP プロキシのユーザーデータスクリプト**  
以下のユーザーデータ PowerShell スクリプトの例では、 Amazon ECS コンテナエージェント、および Docker デーモンが指定された HTTP プロキシを使用するように設定します。コンテナインスタンス自体が登録されているクラスターを指定することもできます。  
コンテナインスタンスの起動時にこのスクリプトを使用するには、「[Amazon ECS Windows コンテナインスタンスの起動](launch_window-container_instance.md)」のステップに従います。以下の PowerShell スクリプトをコピーして [**ユーザーデータ**] フィールドに貼り付けます (必ず、赤いサンプル値を実際のプロキシおよびクラスターの情報に置き換えてください)。  
この `-EnableTaskIAMRole` オプションは、タスクの IAM ロールを有効にするために必要です。詳細については、「[Amazon EC2 Windows インスタンスの追加設定](task-iam-roles.md#windows_task_IAM_roles)」を参照してください。

```
<powershell>
Import-Module ECSTools

$proxy = "http://proxy.mydomain:port"
[Environment]::SetEnvironmentVariable("HTTP_PROXY", $proxy, "Machine")
[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")

Restart-Service Docker
Initialize-ECSAgent -Cluster MyCluster -EnableTaskIAMRole
</powershell>
```

# スポットインスタンス通知を受信するように Amazon ECS Windows コンテナインスタンスを設定する
<a name="windows-spot-instance-draining-container"></a>

利用可能なキャパシティーがなくなった場合、または、スポット料金がお客様のリクエストの上限料金を超えた場合には、Amazon EC2 はスポットインスタンスを終了、停止、または休止状態にします。Amazon EC2 はスポットインスタンスが中断される 2 分前に、そのインスタンスに対し中断を警告するための通知を送信します。インスタンスで Amazon ECS スポットインスタンスのドレインが有効になっている場合、ECS はスポットインスタンスの中断通知を受け取り、インスタンスを `DRAINING` ステータスにします。

**重要**  
Amazon ECS は、`terminate` および `stop` インスタンスアクションがあるスポットインスタンスの中断通知をモニタリングします。スポットインスタンスまたはスポットフリートのリクエスト時に `hibernate` インスタンスの中断動作を指定した場合、Amazon ECS スポットインスタンスのドレインはこれらのインスタンスではサポートされません。

コンテナインスタンスを `DRAINING` に設定すると、Amazon ECS によって新規タスクがそのコンテナインスタンスに配置されなくなります。ドレインしているコンテナインスタンス上にある `PENDING` 状態のサービスタスクは即時停止されます。クラスター内に使用可能なコンテナインスタンスがある場合、そのインスタンスで代わりのサービスタスクが開始されます。

インスタンスの起動時にスポットインスタンスドレイニングを有効にできます。コンテナエージェントを開始する前に `ECS_ENABLE_SPOT_INSTANCE_DRAINING` パラメータを設定する必要があります。*マイクラスター* の部分は自分のクラスター名に置き換えます。

```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_SPOT_INSTANCE_DRAINING", "true", "Machine")

# Initialize the agent
Initialize-ECSAgent -Cluster my-cluster
```

詳細については、「[Amazon ECS Windows コンテナインスタンスの起動](launch_window-container_instance.md)」を参照してください。

# 外部インスタンスの Amazon ECS クラスター
<a name="ecs-anywhere"></a>

Amazon ECS Anywhere は、オンプレミスサーバーや仮想マシン (VM) などの*外部インスタンス*を Amazon ECS クラスターに登録するためのサポートを提供します。外部インスタンスは、アウトバウンドトラフィックを生成したり、データを処理したりするアプリケーションを実行するために最適化されています。アプリケーションがインバウンドトラフィックを必要とする場合、Elastic Load Balancing のサポートがないため、これらのワークロードの実行効率が低下します。Amazon ECS は、新しい`EXTERNAL`起動タイプで、サービスを作成したり、外部インスタンスでタスクを実行したりできます。

## サポートされるオペレーティングシステムとシステムアーキテクチャ
<a name="ecs-anywhere-supported-os"></a>

以下は、サポートされているオペレーティングシステムのリストです。`x86_64`および`ARM64`CPU アーキテクチャがサポートされています。
+ Amazon Linux 2023
+ Ubuntu 20、Ubuntu 22、Ubuntu 24
+ RHEL 9 – [ECS Anywhere インストールスクリプト](https://github.com/aws/amazon-ecs-agent/blob/master/scripts/ecs-anywhere-install.sh)を実行する前に、Docker がインストールされていることを確認する必要があります。詳細については、Docker ドキュメントの「[Install Docker Engine on RHEL](https://docs.docker.com/engine/install/rhel/)」を参照してください。

以下のオペレーティングシステムは、2026 年 8 月 7 日付けで Amazon ECS Anywhere のサポート対象外になります。
+ Amazon Linux 2
+ CentOS Stream 9
+ RHEL 7、RHEL 8
+ Fedora 32、Fedora 33、Fedora 40
+ openSUSE タンブルウィード
+ Ubuntu 18
+ Debian 9、Debian 10、Debian 11、Debian 12
+ SUSE Enterprise Server 15
+ Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 20H2

## 考慮事項
<a name="ecs-anywhere-considerations"></a>

外部インスタンスの使用を開始する前に、以下の考慮事項に注意してください。
+ 外部インスタンスは、一度に 1 つずつクラスターに登録できます。外部インスタンスを別のクラスターに登録する方法については、「[Amazon ECS 外部インスタンスの登録を解除する](ecs-anywhere-deregistration.md)」を参照してください。
+ 外部インスタンスには、AWS API との通信を許可する IAM ロールが必要です。詳細については、「[Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md)」を参照してください。
+ 外部インスタンスには、事前設定されたインスタンス認証情報チェーンをローカルに定義しないでください。これは、登録スクリプトに干渉するためです。
+ コンテナログを CloudWatch Logs に送信するには、タスク定義でタスク実行 IAM ロールを作成し、指定してください。
+ 外部インスタンスがクラスターに登録されると、`ecs.capability.external`属性がインスタンスに関連付けられています。この属性は、インスタンスを外部インスタンスとして識別します。カスタム属性を外部インスタンスに追加して、タスクの配置制約として使用できます。詳細については、「[カスタム属性](task-placement-constraints.md#ecs-custom-attributes)」を参照してください。
+ 外部インスタンスにリソースタグを追加できます。詳細については、「[Amazon ECS の外部コンテナインスタンスにタグを追加する](instance-details-tags-external.md)」を参照してください。
+ ECS Exec は、外部インスタンスでサポートされています。詳細については、「[ECS Exec を使用して Amazon ECS コンテナをモニタリングする](ecs-exec.md)」を参照してください。
+ 外部インスタンスとのネットワーキングに固有の追加の考慮事項を次に示します。詳細については、「[ネットワーク](#ecs-anywhere-networking)」を参照してください。
  + サービスの負荷分散はサポートされていません。
  + サービス検出はサポートされていません。
  + 外部インスタンスで実行されるタスクは、`bridge`,`host`, または`none` ネットワークモードを使用する必要があります。`awsvpc` ネットワークモードはサポートされていません。
  + 各 AWS リージョンに Amazon ECS サービスドメインがあります。これらのサービスドメインは、外部インスタンスへのトラフィックの送信を許可する必要があります。
  + 外部インスタンスにインストールされた SSM Agent は、ハードウェアフィンガープリントを使用して 30 分ごとにローテーションされる IAM 認証情報を保持します。外部インスタンスがAWSに設定されている場合、SSM Agent は接続の再確立後にクレデンシャルを自動的に更新します。詳細については、*AWS Systems Managerユーザーガイド*の「[ハードウェアフィンガープリントを使用したオンプレミスサーバーと仮想マシンの検証](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation)」を参照してください。
  + インスタンスが IPv6 のみのサブネットにある限り、IPv6 のみの設定の外部インスタンスで Linux タスクを実行できます。詳細については、「[IPv6-only モードで VPC を使用する](task-networking.md#networking-ipv6-only)」を参照してください。
+ `UpdateContainerAgent` API はサポートされません。外部インスタンスで SSM Agent または Amazon ECS エージェントを更新する方法については、「[外部インスタンス上の AWS Systems Manager エージェントと Amazon ECS コンテナエージェントを更新する](ecs-anywhere-updates.md)」を参照してください。
+ Amazon ECS キャパシティープロバイダーはサポートされていません。外部インスタンスでサービスを作成したり、スタンドアロンタスクを実行するには、`EXTERNAL`起動タイプを使用するタスクにのみ使用されます。
+ SELinux はサポートされません。
+ Amazon EFS ボリュームの使用、または `EFSVolumeConfiguration` はサポートされていません。
+ App Mesh との統合はサポートされていません。
+ コンソールを使用して外部インスタンスタスク定義を作成する場合は、コンソール JSON エディタでタスク定義を作成する必要があります。
+ Amazon ECS に最適化されていない AMI を使用する場合は、外部コンテナインスタンスで次のコマンドを実行して、タスクに IAM ロールを使用するルールを設定します。詳細については、「[外部インスタンスの追加設定](task-iam-roles.md#enable_task_iam_roles)」を参照してください。

  ```
  $ sysctl -w net.ipv4.conf.all.route_localnet=1
  $ iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679
  $ iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
  ```

### ネットワーク
<a name="ecs-anywhere-networking"></a>

Amazon ECS 外部インスタンスは、アウトバウンドトラフィックを生成したり、データを処理したりするアプリケーションを実行するために最適化されています。アプリケーションがウェブサービスなどのインバウンドトラフィックを必要とする場合、Elastic Load Balancing のサポートがないため、これらのワークロードをロードバランサーの背後に配置するためのサポートがないため、これらのワークロードの実行効率が低下します。

外部インスタンスとのネットワークに固有の追加の考慮事項を次に示します。
+ サービスの負荷分散はサポートされていません。
+ サービス検出はサポートされていません。
+ 外部インスタンスで実行される Linux タスクは、`bridge`、`host`、または`none` ネットワークモードを使用する必要があります。`awsvpc` ネットワークモードはサポートされていません。

  各ネットワークモードの詳細については、「[EC2 の Amazon ECS タスクネットワークオプション](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html)」を参照してください。
+ インスタンスが IPv6 のみのサブネットにある限り、IPv6 のみの設定の外部インスタンスで Linux タスクを実行できます。詳細については、「[IPv6-only モードで VPC を使用する](task-networking.md#networking-ipv6-only)」を参照してください。
+ 各リージョンには Amazon ECS サービスドメインがあり、外部インスタンスへのトラフィックの送信を許可する必要があります。
+ 外部インスタンスにインストールされた SSM Agent は、ハードウェアフィンガープリントを使用して 30 分ごとにローテーションされる IAM 認証情報を保持します。外部インスタンスがAWSに設定されている場合、SSM Agent は接続の再確立後にクレデンシャルを自動的に更新します。詳細については、*AWS Systems Managerユーザーガイド*の「[ハードウェアフィンガープリントを使用したオンプレミスサーバーと仮想マシンの検証](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation)」を参照してください。

次のドメインは、Amazon ECS サービスと外部インスタンスにインストールされている Amazon ECS エージェント間の通信に使用されます。トラフィックが許可されていることと、DNS 解決が機能していることを確認します。各エンドポイントでは、*リージョン*は、米国東部 (オハイオ) リージョンの `us-east-2` のように、Amazon ECS でサポートされている AWS リージョンのリージョン識別子を表します。使用するすべてのリージョンのエンドポイントを許可する必要があります。`ecs-a`および`ecs-t`エンドポイントを使用する場合は、アスタリスク (例えば、`ecs-a-*`) を含める必要があります。
+ `ecs-a-*.region.amazonaws.com`— このエンドポイントは、タスクを管理するときに使用されます。
+ `ecs-t-*.region.amazonaws.com`— このエンドポイントは、タスクとコンテナのメトリクスを管理するために使用されます。
+ `ecs.region.amazonaws.com` — これは、Amazon ECS のサービスエンドポイントです。
+ `ssm.region.amazonaws.com ` — これは、AWS Systems Manager のサービスエンドポイントです。
+ `ec2messages.region.amazonaws.com` — これは、AWS Systems Manager がクラウド内の Systems Manager エージェントと Systems Manager サービスの間の通信に使用するサービスエンドポイントです。
+ `ssmmessages.region.amazonaws.com` — これは、クラウド内の Session Manager サービスでセッションチャネルを作成および削除するために必要なサービスエンドポイントです。
+ タスクが他のタスクとの通信を必要とする場合AWSサービスを使用する場合は、これらのサービスエンドポイントが許可されていることを確認します。アプリケーション例としては、Amazon ECR を使用してコンテナイメージを取得したり、CloudWatch Logs に CloudWatch を使用したりすることが挙げられます。詳細については、*AWS 全般のリファレンスガイド*の「[サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照してください。

### ECS Anywhere を使用した Amazon FSx for Windows File Server
<a name="ecs-anywhere-fsx"></a>

**重要**  
Amazon ECS Anywhere の Windows サポートは廃止されました。このセクションは適用されなくなりました。

Amazon ECS 外部インスタンスで Amazon FSx for Windows File Server を使用するには、オンプレミスのデータセンターと AWS クラウド の間に接続を確立する必要があります。ネットワークを VPC に接続するオプションについては、「[Amazon Virtual Private Cloud 接続オプション](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)」を参照してください。

### ECS Anywhere を使用した gMSA
<a name="ecs-anywhere-gmsa"></a>

**重要**  
Amazon ECS Anywhere の Windows サポートは廃止されました。このセクションは適用されなくなりました。

以下のユースケースは、Windows がサポート対象オペレーティングシステムであったときに ECS Anywhere でサポートされていたものです。
+ アクティブディレクトリは、AWS クラウド にあります。この構成では、AWS クラウド 接続を使用してオンプレミスネットワークと AWS Direct Connect の間の接続を確立します。接続を作成する方法については、「[Amazon 仮想プライベートクラウド接続オプション](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)」を参照してください。AWS クラウド にアクティブディレクトリを作成します。AWS Directory Service の使用開始方法の詳細については、「*AWS Directory Service 管理ガイド*」の「[AWS Directory Service の設定](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/setting_up.html)」を参照してください。その後、AWS Direct Connect 接続を使用して、外部インスタンスをドメインに参加させることができます。Amazon ECS での gMSA の操作方法については、「[Amazon ECS の EC2 Windows コンテナで gMSA を使用する方法について説明します。](windows-gmsa.md)」を参照してください。
+ アクティブディレクトリは、オンプレミスデータセンターで管理されています。-この設定では、外部インスタンスをオンプレミスのアクティブディレクトリに参加させます。その後、Amazon ECS タスクを実行する際に、ローカルで使用可能な認証情報を使用します。

# 外部インスタンスワークロード用の Amazon ECS クラスターを作成する
<a name="create-cluster-console-v2-ecs-anywhere"></a>

クラスターを作成して、タスクとサービスを実行するインフラストラクチャを定義します。

これを開始する前に、「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」 の手順を完了し、適切な IAM 許可を割り当てる必要があります。詳細については、「[Amazon ECS クラスターの例](security_iam_id-based-policy-examples.md#IAM_cluster_policies)」を参照してください。Amazon ECS コンソールでは、CloudFormation スタックを作成することで、Amazon ECS クラスターに必要なリソースを簡単に作成できます。

クラスターの作成プロセスをできるだけ簡単にするために、コンソールには、以下で説明する多くの選択肢に対するデフォルトの選択肢があります。コンソール内のほとんどのセクションには、詳細なコンテキストを提供するヘルプパネルもあります。

以下のオプションを変更できます。
+ クラスターに名前空間を追加します。

  名前空間を使用すると、クラスターで作成したサービスを、追加の設定なしで名前空間内の他のサービスに接続できます。詳細については、「[Amazon ECS サービスを相互接続する](interconnecting-services.md)」を参照してください。
+ クラスターを外部インスタンス用に設定します。
+ マネージドストレージに AWS KMS キーを割り当てます。キーの作成方法の詳細については、*AWS Key Management Service ユーザーガイド*の「[KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
+ クラスターを識別しやすいようにタグを追加します。

**新しいクラスターを作成するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、**[Create Cluster]** (クラスターの作成) を選択します。

1. **[クラスター設定]** で以下を設定します。
   + **[クラスター名]** に一意の名前を入力します。

     名前には、最大 255 文字 (大文字と小文字)、数字、およびハイフンを含めることができます。
   + (オプション) Service Connect に使用する名前空間をクラスター名と別のものにするには、**[名前空間]** に一意の名前を入力します。

1. (オプション) Container Insights を使用して **モニタリング** を展開し、次のいずれかのオプションを選択します。
   + オブザーバビリティが強化された推奨の Container Insights を使用するには、**[オブザーバビリティが強化された Container Insights]** を選択します。
   + Container Insights を使用するには、**[Container Insights]** を選択します。

1. (オプション) ECS Exec を使用してクラスター内のタスクをデバッグするには、**[トラブルシューティング設定]** を展開し、以下を設定します。
   + **[ECS Exec をオンにする]** を選択します。
   + (オプション) **[ECS Exec の AWS KMS キー]** には、ECS Exec セッションデータの暗号化に使用する AWS KMS キーの ARN を入力します。
   + (オプション) **[ECS Exec ログ記録]** で、ログの送信先を選択します。
     + CloudWatch Logs にログを送信するには、**[Amazon CloudWatch]** を選択します。
     + Amazon S3 にログを送信するには、**[Amazon S3]** を選択します。
     + ログ記録を無効にするには、**[なし]** を選択します。

1. (オプション) マネージドストレージのデータを暗号化します。**[暗号化]** の **[マネージドストレージ]** に、マネージドストレージデータの暗号化に使用する AWS KMS キーの ARN を入力します。

1. (オプション) クラスターを識別しやすくするには、**[Tags]** (タグ) を展開し、タグを設定します。

   [タグの追加] [**タグの追加**] を選択して、以下を実行します。
   + [**キー**] にはキー名を入力します。
   + [**値**] にキー値を入力します。

1. **[作成]** を選択します。

## 次のステップ
<a name="cluster-next-steps-ecs-anywhere"></a>

インスタンスをクラスターに登録する必要があります。詳細については、「[Amazon ECS クラスターに外部インスタンスを登録する](ecs-anywhere-registration.md)」を参照してください。

外部起動タイプのタスク定義を作成します。詳細については、[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)を参照してください。

スタンドアロンタスクとして、またはサービスの一部としてアプリケーションを実行します。詳細については次を参照してください:
+ [Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)
+ [Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)

# Amazon ECS クラスターに外部インスタンスを登録する
<a name="ecs-anywhere-registration"></a>

Amazon ECS クラスターに登録する外部インスタンスごとに、SSM Agent、Amazon ECS コンテナエージェント、および Docker がインストールされている必要があります。外部インスタンスを Amazon ECS クラスターに登録するには、最初に AWS Systems Manager マネージドインスタンスを登録する必要があります。インストールスクリプトは、Amazon ECS コンソールで数回クリックするだけで作成できます。インストールスクリプトには、Systems Manager のアクティベーションキーと、必要なエージェントと Docker をインストールするためのコマンドが含まれています。インストールと登録の手順を完了するには、オンプレミスのサーバーまたは VM でインストールスクリプトを実行する必要があります。

**注記**  
Linux の外部インスタンスをクラスターに登録する前に、`/etc/ecs/ecs.config` ファイルを作成し、必要なコンテナエージェント設定パラメータを追加します。外部インスタンスをクラスターに登録した後は、これを行うことはできません。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。

------
#### [ AWS マネジメントコンソール ]

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. リポジトリの [**クラスター**] ページで、外部インスタンスを登録するクラスターを選択します。

1. **[Cluster : *name*]** (クラスター: 名前) のページで、**[Infrastructure]** (インフラストラクチャ) タブを選択します。

1. **[Register external instances]** (外部インスタンスの登録) ページで、次のステップを完了します。

   1. **[Activation key duration (in days)]** (アクティベーションキーの期間 (日数)) を使用する場合、アクティベーションキーがアクティブなままになる日数を入力します。入力した日数が経過すると、外部インスタンスの登録時にキーが機能しなくなります。

   1. **インスタンス数**を使用する場合　アクティベーションキーを使用してクラスターに登録する外部インスタンスの数を入力します。

   1. **インスタンスロール**を使用する場合、外部インスタンスに関連付ける IAM ロールを選択します。ロールがまだ作成されていない場合は、**新規ロールの作成**を選択すると、Amazon ECS がユーザーに代わってロールを作成します。外部インスタンスに必要な IAM 許可の詳細については、「[Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md)」を参照してください。

   1.  登録コマンドをコピーします。このコマンドは、クラスターに登録する各外部インスタンスで実行する必要があります。
**重要**  
スクリプトの bash 部分は root として実行する必要があります。コマンドが root として実行されない場合、エラーが返されます。

   1. [**閉じる**] を選択してください。

------
#### [ AWS CLI for Linux operating systems ]

1. Systems Manager のアクティベーションペアを作成します。これは、Systems Manager が管理するインスタンスのアクティベーションに使用されます。出力には、`ActivationId`および`ActivationCode`が含まれます。これらは、後のステップで使用します。作成した ECS Anywhere IAM ロールを指定していることを確認します。詳細については、「[Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md)」を参照してください。

   ```
   aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
   ```

1. オンプレミスのサーバーまたは仮想マシン (VM) で、インストールスクリプトをダウンロードします。

   ```
   curl --proto "https" -o "/tmp/ecs-anywhere-install.sh" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
   ```

1. (オプション) オンプレミスサーバーまたは仮想マシン (VM) で、次の手順を使用して、スクリプト署名ファイルを使用してインストールスクリプトを確認します。

   1. GnuPG をダウンロードし、インストールします。GNUpg の詳細については、「[GnuPG ウェブサイト](https://www.gnupg.org)」を参照してください。Linux システムの場合は、お使いの Linux ディストリビューションでパッケージマネージャーを使用して `gpg` をインストールします。

   1. Amazon ECS PGP パブリックキーを取得します。

      ```
      gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
      ```

   1. インストールスクリプトの署名をダウンロードします。署名は、ASCII でデタッチ済みの PGP 署名で、拡張子が `.asc` のファイルに保存されています。

      ```
      curl --proto "https" -o "/tmp/ecs-anywhere-install.sh.asc" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh.asc"
      ```

   1. キーを使用してインストールスクリプトファイルを確認します。

      ```
      gpg --verify /tmp/ecs-anywhere-install.sh.asc /tmp/ecs-anywhere-install.sh
      ```

      予想される出力は次のようになります。

      ```
      gpg: Signature made Tue 25 May 2021 07:16:29 PM UTC
      gpg:                using RSA key 50DECCC4710E61AF
      gpg: Good signature from "Amazon ECS <ecs-security@amazon.com>" [unknown]
      gpg: WARNING: This key is not certified with a trusted signature!
      gpg:          There is no indication that the signature belongs to the owner.
      Primary key fingerprint: F34C 3DDA E729 26B0 79BE  AEC6 BCE9 D9A4 2D51 784F
           Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB  346F 50DE CCC4 710E 61AF
      ```

1. オンプレミスのサーバーまたは仮想マシン (VM) で、インストールスクリプトを実行します。クラスター名、リージョン、Systems Manager のアクティベーション ID とアクティベーションコードを、最初のステップで指定します。

   ```
   sudo bash /tmp/ecs-anywhere-install.sh \
       --region $REGION \
       --cluster $CLUSTER_NAME \
       --activation-id $ACTIVATION_ID \
       --activation-code $ACTIVATION_CODE
   ```

   オンプレミスサーバーまたは仮想マシン (VM) で、GPU ワークロード用の NVIDIA ドライバーがインストールされている場合は、インストールスクリプトに `--enable-gpu` フラグを設定する必要があります。このフラグを指定すると、インストールスクリプトは NVIDIA ドライバが実行中であることを確認してから、Amazon ECS タスクを実行するために必要な構成変数を追加します。GPU ワークロードの実行と、タスク定義での GPU 要件の指定の詳細については、「[Amazon ECS タスク定義での GPU の指定](ecs-gpu-specifying.md)」を参照してください。

   ```
   sudo bash /tmp/ecs-anywhere-install.sh \
       --region $REGION \
       --cluster $CLUSTER_NAME \
       --activation-id $ACTIVATION_ID \
       --activation-code $ACTIVATION_CODE \
       --enable-gpu
   ```

既存の外部インスタンスを別のクラスターに登録するには、次のステップを実行します。

**既存の外部インスタンスを別のクラスターに登録するには**

1. Amazon ECS コンテナエージェントを停止します。

   ```
   sudo systemctl stop ecs.service
   ```

1. `/etc/ecs/ecs.config`ファイルと`ECS_CLUSTER`行を編集して、クラスター名が外部インスタンスを登録するクラスターの名前と一致していることを確認します。

1. 既存の Amazon ECS エージェントデータを削除します。

   ```
   sudo rm /var/lib/ecs/data/agent.db
   ```

1. Amazon ECS コンテナエージェントを開始する

   ```
   sudo systemctl start ecs.service
   ```

------
#### [ AWS CLI for Windows operating systems ]

1. Systems Manager のアクティベーションペアを作成します。これは、Systems Manager が管理するインスタンスのアクティベーションに使用されます。出力には、`ActivationId`および`ActivationCode`が含まれます。これらは、後のステップで使用します。作成した ECS Anywhere IAM ロールを指定していることを確認します。詳細については、「[Amazon ECS Anywhere IAM ロール](iam-role-ecsanywhere.md)」を参照してください。

   ```
   aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
   ```

1. オンプレミスのサーバーまたは仮想マシン (VM) で、インストールスクリプトをダウンロードします。

   ```
   Invoke-RestMethod -URI "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install.ps1" -OutFile “ecs-anywhere-install.ps1”
   ```

1. (オプション) Powershell スクリプトは Amazon によって署名されているため、Windows は同じ場所で証明書の検証を自動的に実行します。手動で検証を実行する必要はありません。

   証明書を手動で検証するには、ファイルを右クリックしてプロパティに移動し、[Digital Signatures] (デジタル署名) タブを使用して詳細を取得します。

   このオプションは、ホストが証明書ストアに証明書がある場合にのみ使用できます。

   検証の結果、次のような情報が返されます。

   ```
   # Verification (PowerShell)
   Get-AuthenticodeSignature -FilePath .\ecs-anywhere-install.ps1
   
   SignerCertificate                         Status      Path
   -----------------                         ------      ----
   EXAMPLECERTIFICATE                        Valid       ecs-anywhere-install.ps1
   
   ...
   
   Subject              : CN="Amazon Web Services, Inc.",...
   
   ----
   ```

1. オンプレミスのサーバーまたは仮想マシン (VM) で、インストールスクリプトを実行します。クラスター名、リージョン、Systems Manager のアクティベーション ID とアクティベーションコードを、最初のステップで指定します。

   ```
   .\ecs-anywhere-install.ps1 -Region $Region -Cluster $Cluster -ActivationID $ActivationID -ActivationCode $ActivationCode
   ```

1. Amazon ECS コンテナエージェントが実行されていることを確認します。

   ```
   Get-Service AmazonECS
   
   Status   Name               DisplayName
   ------   ----               -----------
   Running  AmazonECS          Amazon ECS
   ```

既存の外部インスタンスを別のクラスターに登録するには、次のステップを実行します。

**既存の外部インスタンスを別のクラスターに登録するには**

1. Amazon ECS コンテナエージェントを停止します。

   ```
   Stop-Service AmazonECS
   ```

1. クラスター名が外部インスタンスを登録するクラスターの名前と一致するように `ECS_CLUSTER` パラメータを変更します。

   ```
   [Environment]::SetEnvironmentVariable("ECS_CLUSTER", $ECSCluster, [System.EnvironmentVariableTarget]::Machine)
   ```

1. 既存の Amazon ECS エージェントデータを削除します。

   ```
   Remove-Item -Recurse -Force $env:ProgramData\Amazon\ECS\data\*
   ```

1. Amazon ECS コンテナエージェントを開始する

   ```
   Start-Service AmazonECS
   ```

------

AWS CLIを使用して、外部インスタンスの登録プロセスを完了するためにインストールスクリプトを実行する前に、Systems Manager のアクティベーションを作成できます

# Amazon ECS 外部インスタンスの登録を解除する
<a name="ecs-anywhere-deregistration"></a>

インスタンスの使用が終了したら、Amazon ECS とAWS Systems Manager をインスタンスから登録解除することをお勧めします。登録解除後、コンテナインスタンスは新しいタスクを受けることができなくなります。

登録解除するときにコンテナインスタンスでタスクが実行されている場合、インスタンスを削除するかタスクが他の手段で停止するまで、これらのタスクは実行されたままになります。ただし、これらのタスクは Amazon ECS によるモニタリングや情報収集の対象外になります。外部インスタンス上のこれらのタスクが Amazon ECS サービスに含まれる場合、サービススケジューラは、可能であれば、別のコンテナインスタンスでそのタスクの別のコピーを開始します。

インスタンスの登録を解除した後、インスタンス上の残りの AWS リソースをクリーンアップします。その後、新しいクラスターに登録できます。

## 手順
<a name="ecs-anywhere-deregistration-procedure"></a>

------
#### [ AWS マネジメントコンソール ]

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、外部インスタンスが存在するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択し、外部インスタンスをホストするクラスターを選択します。

1. **[Cluster : *name*]** (クラスター: 名前) のページで、**[Infrastructure]** (インフラストラクチャ) タブを選択します。

1. **[Container instances]** (コンテナインスタンス)で、登録解除する外部のインスタンス ID を選択します。コンテナインスタンスの詳細ページにリダイレクトされます。

1. **[Container Instance : *id*]** (コンテナインスタンス: id) ページで、**[Deregister]** (登録解除) を選択します。

1. 登録解除メッセージを確認します。[**Deregistered fromAWS Systems Manager**]を選択して、外部インスタンスを Systems Manager 管理対象インスタンスとして登録解除することもできます。**[Deregister]** (登録解除) を選択します。
**注記**  
Systems Manager コンソールで、外部インスタンスを Systems Manager 管理対象インスタンスとして登録解除できます。手順については、「*AWS Systems Manager ユーザーガイド*」の「[ハイブリッドおよびマルチクラウド環境でのマネージドノードの登録解除](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-deregister-hybrid-nodes.html)」を参照してください。

1. インスタンスの登録を解除した後は、オンプレミスサーバーまたは VM にある AWS リソースをクリーンアップします。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)

------
#### [ AWS CLI ]

1. コンテナインスタンスを登録解除するには、インスタンス ID とコンテナインスタンス ARN が必要です。これらの値がない場合は、次のコマンドを実行してください

   次のコマンドを実行して、インスタンス ID を取得します。

   インスタンス ID (`instanceID`) を使用し、コンテナインスタンス ARN (`containerInstanceARN`) を取得します。

   ```
   instanceId=$(aws ssm describe-instance-information --region "{{ region }}" | jq ".InstanceInformationList[] |select(.IPAddress==\"{{ IPv4 Address }}\") | .InstanceId" | tr -d'"'
   ```

   以下のコマンドを実行します。

   インスタンス (`deregister-container-instance`) を登録解除するには、コマンドのパラメータとして `containerInstanceArn` を使用します。

   ```
   instances=$(aws ecs list-container-instances --cluster "{{ cluster }}" --region "{{ region }}" | jq -c '.containerInstanceArns')
   containerInstanceArn=$(aws ecs describe-container-instances --cluster "{{ cluster }}" --region "{{ region }}" --container-instances $instances | jq ".containerInstances[] | select(.ec2InstanceId==\"{{ instanceId }}\") | .containerInstanceArn" | tr -d '"')
   ```

1.  次のコマンドを実行して、インスタンスをドレインします。

   ```
   aws ecs update-container-instances-state --cluster "{{ cluster }}" --region "{{ region }}" --container-instances "{{ containerInstanceArn }}" --status DRAINING
   ```

1. コンテナインスタンスのドレインが終了したら、次のコマンドを実行してインスタンスを登録解除します。

   ```
   aws ecs deregister-container-instance --cluster "{{ cluster }}" --region "{{ region }}" --container-instance "{{ containerInstanceArn }}"
   ```

1. 次のコマンドを実行し、SSM からコンテナインスタンスを削除します。

   ```
   aws ssm deregister-managed-instance --region "{{ region }}" --instance-id "{{ instanceId }}"
   ```

1. インスタンスの登録を解除した後は、オンプレミスサーバーまたは VM にある AWS リソースをクリーンアップします。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)

------

# 外部インスタンス上の AWS Systems Manager エージェントと Amazon ECS コンテナエージェントを更新する
<a name="ecs-anywhere-updates"></a>

オンプレミスのサーバーまたは VM で、AWS Systems Managerエージェント（SSM Agent）と Amazon ECS コンテナエージェント（Amazon ECS ワークロードの実行時）AWSは、機能が追加または更新されたときに、これらのエージェントの新しいバージョンをリリースします。外部インスタンスがいずれかのエージェントの以前のバージョンを使用している場合は、次の手順を使用して更新できます。

## 外部インスタンスでの SSM Agent の更新
<a name="ecs-anywhere-updates-ssmagent"></a>

AWS Systems Managerインスタンスで SSM Agent を更新するプロセスを自動化することをお勧めします。これらは、更新を自動化するためのいくつかの方法を提供します。詳細については、*AWS Systems Managerユーザーガイド*の「[SSM Agent の更新を自動化する](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html)」を参照してください。

## 外部インスタンス上の Amazon ECS エージェントを更新しています
<a name="ecs-anywhere-updates-ecsagent"></a>

外部インスタンスでは、Amazon ECS コンテナエージェントは`ecs-init`パッケージをアップグレードすることで更新されます。Amazon ECS エージェントを更新しても、実行中のタスクやサービスが中断されることはありません。Amazon ECS が`ecs-init`パッケージと署名ファイルを、各リージョンの Amazon S3 バケットに作成します。`ecs-init`から始まるバージョン`1.52.1-1`では、Amazon ECS は、外部インスタンスが使用するオペレーティングシステムとシステムアーキテクチャに応じて個別の `ecs-init` パッケージを提供します。

以下の表を使用して、`ecs-init`パッケージは、外部インスタンスが使用するオペレーティングシステムとシステムアーキテクチャに基づいてダウンロードする必要があります。

**注記**  
次のコマンドを使用して、外部インスタンスが使用するオペレーティングシステムおよびシステムアーキテクチャを決定できます。  

```
cat /etc/os-release
uname -m
```


| オペレーティングシステム (アーキテクチャ) | ecs-init パッケージ | 
| --- | --- | 
|  CentOS 7 (x86-64) CentOS 8 (x86\$164) CentOS Stream 9 (x86\$164) SUSE Enterprise Server 15 (x86\$164) RHEL 7 (x86\$164) RHEL 8 (x86\$164)  |  `amazon-ecs-init-latest.x86_64.rpm`  | 
|  CentOS 7 (aarch64) CentOS 8 (aarch64) CentOS Stream 9 (aarch64) RHEL 7 (aarch64)  |  `amazon-ecs-init-latest.aarch64.rpm`  | 
|  Debian 9 (x86\$164) Debian 10 (x86\$164) Debian 11 (x86\$164) Debian 12 (x86\$164) Ubuntu 18 (x86\$164) Ubuntu 20 (x86\$164) Ubuntu 22 (x86\$164) Ubuntu 24 (x86\$164)  |  `amazon-ecs-init-latest.amd64.deb`  | 
|  Debian 9 (aarch64) Debian 10 (aarch64) Debian 11 (aarch64) Debian 12 (aarch64) Ubuntu 18 (aarch64) Ubuntu 20 (aarch64) Ubuntu 22 (aarch64) Ubuntu 24 (aarch64)  |  `amazon-ecs-init-latest.arm64.deb`  | 

Amazon ECS エージェントを更新するには、以下の手順に従います。

**Amazon ECS エージェントを更新するには**

1. 実行している Amazon ECS エージェントのバージョンを確認します。

   ```
   curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```

1. オペレーティングシステムとシステムアーキテクチャー用の`ecs-init`パッケージをダウンロードします。Amazon ECS が`ecs-init`パッケージファイルを、各リージョンの Amazon S3 バケットに作成します。置き換えることを確認します。*<region>*コマンド内の識別子を、地理的に最も近いリージョン名 (例:`us-west-2`）に置き換えることを確認します。

   **amazon-ecs-init-latest.x86\$164.rpm**

   ```
   curl -o amazon-ecs-init.rpm https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.x86_64.rpm
   ```

   **amazon-ecs-init-latest.aarch64.rpm**

   ```
   curl -o amazon-ecs-init.rpm https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.aarch64.rpm
   ```

   **amazon-ecs-init-latest.amd64.deb**

   ```
   curl -o amazon-ecs-init.deb https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.amd64.deb
   ```

   **amazon-ecs-init-latest.arm64.deb**

   ```
   curl -o amazon-ecs-init.deb https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.arm64.deb
   ```

1. (オプション) PGP 署名を使用して、`ecs-init`パッケージファイルの妥当性を検証します。

   1. GnuPG をダウンロードし、インストールします。GNUpg の詳細については、「[GnuPG ウェブサイト](https://www.gnupg.org)」を参照してください。Linux システムの場合は、お使いの Linux ディストリビューションでパッケージマネージャーを使用して `gpg` をインストールします。

   1. Amazon ECS PGP パブリックキーを取得します。

      ```
      gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
      ```

   1. `ecs-init` パッケージ署名ファイルをダウンロードします。署名は、ASCII でデタッチ済みの PGP 署名で、拡張子が `.asc` のファイルに保存されています。Amazon ECS は、各リージョンの Amazon S3 バケットに署名ファイルを提供します。置き換えることを確認します。*<region>*コマンド内の識別子を、地理的に最も近いリージョン名 (例:`us-west-2`）に置き換えることを確認します。

      **amazon-ecs-init-latest.x86\$164.rpm**

      ```
      curl -o amazon-ecs-init.rpm.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.x86_64.rpm.asc
      ```

      **amazon-ecs-init-latest.aarch64.rpm**

      ```
      curl -o amazon-ecs-init.rpm.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.aarch64.rpm.asc
      ```

      **amazon-ecs-init-latest.amd64.deb**

      ```
      curl -o amazon-ecs-init.deb.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.amd64.deb.asc
      ```

      **amazon-ecs-init-latest.arm64.deb**

      ```
      curl -o amazon-ecs-init.deb.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.arm64.deb.asc
      ```

   1. キーを使用して`ecs-init`パッケージファイルを検証します。

      **`rpm`パッケージ向け**

      ```
      gpg --verify amazon-ecs-init.rpm.asc ./amazon-ecs-init.rpm
      ```

      **`deb`パッケージ向け**

      ```
      gpg --verify amazon-ecs-init.deb.asc ./amazon-ecs-init.deb
      ```

      予想される出力は次のようになります。

      ```
      gpg: Signature made Fri 14 May 2021 09:31:36 PM UTC
      gpg:                using RSA key 50DECCC4710E61AF
      gpg: Good signature from "Amazon ECS <ecs-security@amazon.com>" [unknown]
      gpg: WARNING: This key is not certified with a trusted signature!
      gpg:          There is no indication that the signature belongs to the owner.
      Primary key fingerprint: F34C 3DDA E729 26B0 79BE  AEC6 BCE9 D9A4 2D51 784F
           Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB  346F 50DE CCC4 710E 61AF
      ```

1. `ecs-init` パッケージをインストールします。

   **`rpm`パッケージ向けは、CentOS 7、CentOS 8、および RHEL 7 に搭載されています。**

   ```
   sudo yum install -y ./amazon-ecs-init.rpm
   ```

   **SUSE Enterprise Server 15 の`rpm`パッケージ向け**

   ```
   sudo zypper install -y --allow-unsigned-rpm ./amazon-ecs-init.rpm
   ```

   **`deb`パッケージ向け**

   ```
   sudo dpkg -i ./amazon-ecs-init.deb
   ```

1. `ecs` サービスを再起動します。

   ```
   sudo systemctl restart ecs
   ```

1. Amazon ECS エージェントのバージョンが更新されたことを確認します。

   ```
   curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```

# Amazon ECS クラスターを更新する
<a name="update-cluster-v2"></a>

次のクラスタープロパティを変更できます。
+ デフォルトのキャパシティプロバイダーを設定する

  各クラスターには、1 つ以上のキャパシティプロバイダーがあり、さらにオプションとしてキャパシティプロバイダー戦略があります。キャパシティープロバイダー戦略は、クラスターの複数のキャパシティープロバイダー間にタスクを分散する方法を決定します。スタンドアロンタスクを実行するか、サービスを作成するときは、クラスターのデフォルトのキャパシティプロバイダー戦略か、クラスターのデフォルト戦略をオーバーライドするキャパシティプロバイダー戦略のいずれかを使用します。
+ Container Insights をオンにします。

  CloudWatch Container Insights は、コンテナ化されたアプリケーションおよびマイクロサービスのメトリクスとログを収集、集約、要約します。Container Insights は、問題の迅速な特定と解決に使用するコンテナの再起動失敗などの診断情報も提供します。詳細については、「[オブザーバビリティが強化された Container Insights を使用し、Amazon ECS コンテナを監視する](cloudwatch-container-insights.md)」を参照してください。
+ クラスターを識別しやすいようにタグを追加します。

**手順**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、クラスターを選択します。

1. **[クラスター: *name*]** ページで、**[クラスターを更新]** を選択します。

1. デフォルトのキャパシティプロバイダーを設定するには、**[デフォルトのキャパシティプロバイダー戦略]** で **[さらに追加]** を選択します。

   1. [**キャパシティプロバイダー**] で、キャパシティプロバイダーを選択します。

   1. (オプション) **[ベース]** で、キャパシティプロバイダーで実行されるタスクの最小数を入力します。

      1 つのキャパシティプロバイダーには、1 つの **[ベース]** 値のみを設定できます。

   1. (オプション) **[重み]** で、指定されたキャパシティプロバイダーを使用する、起動されたタスクの合計数の相対的な割合を入力します。

   1. (オプション) 追加のキャパシティプロバイダーについて、ステップを繰り返します。

1. Container Insights をオンまたはオフにするには、**[モニタリング]** を展開し、**[Container Insights を使用]** をオンにします。

1. クラスターを識別しやすくするには、**[タグ]** を展開し、タグを設定します。

   [タグの追加] [**タグの追加**] を選択して、以下を実行します。
   + [**キー**] にはキー名を入力します。
   + [**値**] にキー値を入力します。

   [タグを削除] タグのキーと値の右側にある [**削除**] を選択します。

1. **[更新]** を選択します。

# Amazon ECS クラスターを削除する
<a name="delete_cluster-new-console"></a>

クラスターの使用を終了する場合は、クラスターを削除できます。クラスターを削除すると、`INACTIVE` 状態に移行します。`INACTIVE` ステータスのクラスターは、一定期間アカウント内で検出可能なままになる場合があります。ただし、この動作は今後変更される可能性があるため、`INACTIVE` クラスターの永続化に頼るべきではありません。

クラスターを削除する前に、次のオペレーションを実行する必要があります。
+ クラスター内のすべてのサービスを削除します。詳細については、「[コンソールを使用して Amazon ECS サービスの削除](delete-service-v2.md)」を参照してください。
+ 現在実行中のタスクをすべて停止します。詳細については、「[Amazon ECS タスクの停止](standalone-task-stop.md)」を参照してください。
+ クラスターに登録されているすべてのコンテナインスタンスの登録を解除します。詳細については、「[Amazon ECS コンテナインスタンスの登録を解除する](deregister_container_instance.md)」を参照してください。
+ 名前空間を削除します。詳細については、*AWS Cloud Map デベロッパーガイド*の[名前空間の削除](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html)を参照してください。

**手順**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、使用するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、削除するクラスターを選択します。

1. ページの右上で、**[Delete Cluster]** (クラスターを削除) を選択します。

   クラスターに関連付けられているすべてのリソースを削除しなかった場合は、メッセージが表示されます。

1. 確認ボックスに **[delete *cluster name]*** (削除 クラスター名) と入力してください。

# Amazon ECS コンテナインスタンスの登録を解除する
<a name="deregister_container_instance"></a>

**重要**  
このトピックは、Amazon EC2 で作成されたコンテナインスタンスのみを対象としています。外部インスタンスの登録を解除する方法については、[Amazon ECS 外部インスタンスの登録を解除する](ecs-anywhere-deregistration.md) を参照してください。

Amazon EC2 でバックアップされたコンテナインスタンスの使用を終了する場合は、そのインスタンスをクラスターから登録解除できます。登録解除後、コンテナインスタンスは新しいタスクを受けることができなくなります。

登録解除するときにコンテナインスタンスでタスクが実行されている場合、インスタンスを削除するかタスクが他の手段で停止するまで、これらのタスクは実行されたままになります。ただし、これらのタスクは孤立しています (Amazon ECS によるモニタリングや情報収集の対象外になります)。コンテナインスタンス上の孤立したタスクが Amazon ECS サービスに含まれる場合、サービススケジューラは、可能であれば、別のコンテナインスタンスでそのタスクの別のコピーを開始します。Application Load Balancer ターゲットグループに登録されている、孤立したサービスタスクのコンテナは、すべてその登録が解除されます。これらはロードバランサーまたはターゲットグループの設定に従って Connection Draining が開始されます。`awsvpc` ネットワークモードを使用している孤立したタスク、その Elastic Network Interface は削除されます。

登録解除後に、コンテナインスタンスを別の用途に使用する予定の場合は、登録解除前に、コンテナインスタンスで実行中のすべてのタスクを停止する必要があります。これにより、孤立したタスクによってリソースが消費されなくなります。

コンテナインスタンスの登録を解除するときは、以下の考慮事項に注意してください。
+ 各コンテナインスタンスには、それぞれに固有の状態情報があるため、1 つのクラスターから登録解除して別のクラスターに再登録しないでください。コンテナインスタンスリソースを再配置するには、1 つのクラスターからコンテナインスタンスを終了し、新しいクラスターで新しいコンテナインスタンスを起動することをお勧めします。詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスの終了](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html)」および [Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md) を参照してください。
+ コンテナインスタンスが Auto Scaling グループまたはCloudFormationスタックで管理されている場合は、Auto Scaling グループを更新するか、CloudFormationスタックでインスタンスを終了します。それ以外の場合は、Auto Scaling グループまたはCloudFormationにより、インスタンス終了後に新しいインスタンスが作成されます。
+ 接続された Amazon ECS コンテナエージェントを使用して実行中のコンテナインスタンスを削除する場合は、エージェントによってクラスターからインスタンスが自動的に登録解除されます。停止したコンテナインスタンス、または切断されたエージェントがあるインスタンスは、終了時に自動的に登録解除されません。
+ コンテナインスタンスを登録解除すると、インスタンスがクラスターから削除されますが、Amazon EC2 インスタンスは終了しません。インスタンスの使用を終了する場合は、必ずインスタンスを終了して課金を停止します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスの終了](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html)」を参照してください。

## 手順
<a name="deregister_container_instance_procedure"></a>

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションバーから、外部インスタンスが存在するリージョンを選択します。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択し、インスタンスをホストするクラスターを選択します。

1. **[Cluster : *name*]** (クラスター: 名前) のページで、**[Infrastructure]** (インフラストラクチャ) タブを選択します。

1. **[Container instances]** (コンテナインスタンス)で、登録解除するインスタンス ID を選択します。コンテナインスタンスの詳細ページにリダイレクトされます。

1. **[Container Instance : *id*]** (コンテナインスタンス: id) ページで、**[Deregister]** (登録解除) を選択します。

1. 確認画面で **[登録解除]** を選択します。

1. コンテナインスタンスの使用を終了する場合は、基になる Amazon EC2 インスタンスを終了します。詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスの終了](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html)」を参照してください。

# Amazon ECS コンテナインスタンスをドレインする
<a name="container-instance-draining"></a>

クラスターからコンテナインスタンスを削除する必要がある場合があります。例えば、システム更新を実行したり、クラスターキャパシティーをスケールダウンしたりする場合などです。Amazon ECS では、コンテナインスタンスを`DRAINING` ステータスに遷移する能力を提供します。これは、*コンテナインスタンスのドレイン*と呼ばれます。コンテナインスタンスを `DRAINING` に設定すると、Amazon ECS によって新規タスクがそのコンテナインスタンスに配置されなくなります。

## サービスのドレイニング動作
<a name="draining-service-behavior"></a>

`PENDING` 状態にあるサービスの一部であるタスクは、直ちに停止されます。クラスター内に利用可能なコンテナインスタンス容量がある場合、サービススケジューラによって置き換えタスクが開始されます。十分なコンテナインスタンス容量がない場合、問題を示すサービスイベントメッセージが送信されます。

`RUNNING` 状態にあるコンテナインスタンス上のサービスの一部であるタスクは、`STOPPED` 状態に移行します。サービススケジューラは、サービスのデプロイタイプ、デプロイ設定パラメータ、`minimumHealthyPercent` および `maximumPercent` に従って、タスクを置き換えようとします。詳細については、「[Amazon ECS サービス](ecs_services.md)」および「[Amazon ECS サービス定義パラメータ](service_definition_parameters.md)」を参照してください。
+ `minimumHealthyPercent` が 100% を下回っている場合、タスクの代替中、スケジューラは一時的に `desiredCount` を無視できます。例えば、`desiredCount` が 4 つのタスクの場合、最小値 50% でスケジューラは 2 つの既存タスクを停止してから 2 つの新規タスクを開始できます。最小が 100% の場合、サービススケジューラは、代替タスクが正常な状態と見なされるまで既存タスクを削除できません。ロードバランサーを使用しないサービスのタスクが `RUNNING` 状態にある場合、正常な状態と見なされます。ロードバランサーを使用するサービスのタスクは、`RUNNING` 状態にあり、そのタスクをホストするコンテナインスタンスがロードバランサーによって正常と報告された場合に、正常であると見なされます。
**重要**  
スポットインスタンスを使用していて、`minimumHealthyPercent` が 100% 以上の場合、サービスには、スポットインスタンスが終了する前にタスクを置き換えるための十分な時間がありません。
+ `maximumPercent` パラメータは、タスクの置き換え中に実行できるタスク数の上限を表します。これは、置き換えのバッチサイズを定義するために使用できます。例えば、`desiredCount` が 4 つのタスクで、最大が 200% であればドレインされる 4 つのタスクを停止する前に 4 つの新規タスクを開始できます (これを行うために必要なクラスターリソースを使用できる場合)。最大が 100% の場合、代替タスクは、ドレインするタスクが停止するまで開始できません。
**重要**  
`minimumHealthyPercent` と `maximumPercent` の両方が 100% の場合、サービスは既存のタスクを削除できず、代替タスクを開始することもできません。これにより、コンテナインスタンスのドレインの成功を防止し、新たなデプロイが防止されます。

## スタンドアロンタスクのドレイニング動作
<a name="draining-standalone-behavior"></a>

`PENDING` または `RUNNING` 状態のスタンドアロンタスクは影響を受けません。自分で停止するか、手動で停止するまで待つ必要があります。コンテナインスタンスは `DRAINING` ステータスのままです。

## Amazon ECS マネージドインスタンスのドレイニング動作
<a name="managed-instances-draining-behavior"></a>

Amazon ECS マネージドインスタンスの終了は、コストを最適化し、システムの健全性を維持しながら、ワークロードを正常に移行します。終了システムには、インスタンスの終了に関する 3 つの異なる決定パスがあり、それぞれのタイミングの特性やお客様に影響する事項が異なります。

お客様が開始した終了  
コンテナインスタンスをすぐにサービスから削除する必要がある場合に、インスタンスの削除を直接制御できます。`force` リクエストパラメータを true に設定して、`deregister-container-instance` を実行します。つまり、実行中のワークロードがあっても、即時終了が必要になります。

システムによるアイドル終了  
Amazon ECS マネージドインスタンスは、タスクを実行していないアイドル状態の Amazon ECS コンテナインスタンスを終了することで、コストを継続的にモニタリングし、プロアクティブに最適化します。ECS はヒューリスティック遅延を使用して、コンテナインスタンスが終了する前に新しく起動されたタスクを取得する時間を提供します。これは、`scaleInAfter` Amazon ECS マネージドインスタンスのキャパシティープロバイダー設定パラメータを使用してカスタマイズできます。

インフラストラクチャの更新の終了  
Amazon ECS マネージドインスタンスでは、ワークロードの可用性を維持しながら、マネージドコンテナインスタンスのソフトウェアを自動的に管理および更新することで、セキュリティとコンプライアンスを確実にします。詳細については、[Amazon ECS マネージドインスタンスでのパッチ適用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html)を参照してください。

終了システムは、ワークロードの継続性とインフラストラクチャ管理要件のバランスを取る、2 段階のアプローチを実行します。

**フェーズ 1: 正常な完了期間**  
このフェーズでは、システムはワークロードの継続性を優先する、正常なドレイニング戦略を実行します。サービスタスクは、通常の Amazon ECS スケジューリングプロセスによって正常にドレインされます。スタンドアロンタスクは自然に完了する可能性があるため、実行が継続されます。システムは、自然な完了プロセスを通じて停止状態に達するように、すべてのタスクをモニタリングします。

**フェーズ 2: 厳格な期限の適用**  
正常な完了が、許容可能な期間内に終了目標を達成しない場合、システムは厳格な期限の適用を実行します。厳格な期限では、通常ドレイン開始日時に 7 日を加えて設定されるため、運用要件は維持されますが、正常な完了にはかなりの時間がかかります。強制には、強制登録解除手順の自動実行と、完了ステータスを考慮しない残りのすべてのタスクの即時終了が含まれます。

インスタンスで実行されているすべてのタスクが `STOPPED` 状態に移行すると、コンテナインスタンスのドレインが完了します。コンテナインスタンスは、再びアクティブ化または削除されるまで、`DRAINING` 状態のままです。コンテナインスタンス上のタスクの状態を確認するには、[ListTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ListTasks.html) オペレーションを `containerInstance` パラメータと共に使用して、インスタンス上のタスクのリストを取得した後、各 Amazon リソースネーム (ARN) または各タスクの ID で [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) オペレーションを実行して、タスクの状態を確認します。

コンテナインスタンスがタスクのホスティングを再開する準備ができたら、コンテナインスタンスの状態を `DRAINING` から `ACTIVE` に変更します。Amazon ECS サービススケジューラは、コンテナインスタンスを再度検討してタスクを配置します。

## 手順
<a name="drain-instances"></a>

次の手順に従って、新しい AWS マネジメントコンソール を使用してコンテナインスタンスをドレインする設定ができます。

また、[UpdateContainerInstancesState](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateContainerInstancesState.html) API アクションまたは [update-container-instances-state](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-container-instances-state.html) コマンドを使用して、コンテナインスタンスのステータスを `DRAINING` に変更することも可能です。

**AWS マネジメントコンソール**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[Clusters]** (クラスター) ページで、インスタンスをホストするクラスターを選択します。

1. **[Cluster : *name*]** (クラスター: 名前) のページで、**[Infrastructure]** (インフラストラクチャ) タブを選択します。次に、**[Container instances]** (コンテナインスタンス) タブを選択し、ドレインしたい各コンテナインスタンスのチェックボックスをオンにします。

1. **[アクション]**、**[ドレイン]** の順に選択します。

# Auto Scaling グループ外のインスタンスのタイプまたはサイズを変更する
<a name="container-instance-change-type"></a>

AWS では、イミュータブルなインフラストラクチャを維持することをお勧めします。インスタンスサイズを変更する必要がある場合は、次のいずれかを実行できます。
+ 水平方向にスケーリングし、インスタンスを追加します。次に、それらのインスタンスに追加のタスクを配置します。または、
+ 垂直方向にスケーリングし、新しい大規模/小規模インスタンスを起動して、古いインスタンスをドレインします。

これらのアプローチは、いずれもアプリケーションの可用性への影響を最小限に抑えるのに役立ちます。

別の方法を使用してインスタンスを変更した場合、次のエラーが表示されることがあります。

```
Container instance type changes are not supported.
```

このエラーが表示されたら、次の手順を実行します。

1. 目的のインスタンスタイプで新しいインスタンスを起動します。

1. 古いインスタンスタイプをドレインします。詳細については、「[Amazon ECS コンテナインスタンスをドレインする](container-instance-draining.md)」を参照してください。

# Amazon ECS EC2 コンテナインスタンス
<a name="ecs-agent-versions"></a>

Amazon ECS エージェントは、クラスターに登録されているすべてのコンテナインスタンスで実行されるプロセスです。これにより、コンテナインスタンスと Amazon ECS の間の通信が容易になります。

**注記**  
Linux コンテナインスタンスでは、エージェントコンテナは `/lib`、`/lib64`、`/proc` などの最上位ディレクトリをマウントします。これは、Amazon EBS ボリューム、`awsvpc` ネットワークモード、Amazon ECS Service Connect、FireLens – Amazon ECS といった、ECS の様々な機能を利用するために必要です。

Amazon ECSコンテナエージェントの各バージョンは、異なる機能セットをサポートし、以前のバージョンのバグ修正を提供します。可能であれば、最新バージョンの Amazon ECSコンテナエージェントを使用することを常にお勧めします。コンテナエージェントを最新バージョンに更新するには、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。

Amazon ECS コンテナエージェントには `amazon-ecs-pause` イメージが含まれています。Amazon ECS は、`awsvpc` ネットワークモードを使用するタスクにこのイメージを使用します。

どの機能と拡張が各エージェントリリースに含まれているか確認するには、[https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases) を参照してください。

**重要**  
信頼できるメトリクスの最小 Docker バージョンは、Amazon ECS 最適化 AMI `20220607` 以降に含まれる Docker バージョン `v20.10.13` 以降です。  
バージョン `1.20.0` 以降のAmazon ECSエージェントでは、`18.01.0` より前のバージョンの Docker のサポートが廃止されました。

## ライフサイクル
<a name="container-lifecycle"></a>

Amazon ECS コンテナエージェントが Amazon EC2 インスタンスをクラスターに登録すると、Amazon EC2 インスタンスのステータスは、`ACTIVE` として、エージェントの接続ステータスは、`TRUE` としてレポートされます。このコンテナインスタンスはタスクの実行リクエストを受けることができます。

コンテナインスタンスを (終了ではなく) 停止した場合、ステータスは `ACTIVE` のままになりますが、エージェント接続ステータスは数分以内に `FALSE` になります。コンテナインスタンスで実行されていたタスクはすべて停止します。コンテナインスタンスを再び開始すると、コンテナエージェントは、Amazon ECS サービスと再接続し、インスタンスでタスクを再実行できるようになります。

コンテナインスタンスのステータスを `DRAINING` に変更すると、新しいタスクはそのコンテナインスタンスに配置されません。そのコンテナインスタンスで実行されているサービスタスクは、可能な場合は削除され、システム更新を実行できるようになります。詳細については、「[Amazon ECS コンテナインスタンスをドレインする](container-instance-draining.md)」を参照してください。

コンテナインスタンスを登録解除または終了した場合、コンテナインスタンスのステータスは直ちに `INACTIVE` に変わり、コンテナインスタンスを一覧表示しても、そのコンテナインスタンスはレポートされなくなります。ただし、終了後 1 時間は、コンテナインスタンスの内容を表示できます。1 時間後、インスタンスの内容は表示できなくなります。

インスタンスを手動でドレインさせるか、Auto Scaling グループのライフサイクルフックを構築して、インスタンスの状態を `DRAINING` にさせます。Auto Scaling ライフサイクルフックの詳細については、「[Amazon EC2 Auto Scaling ライフサイクルフック](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)」を参照してください。

## Docker サポート
<a name="docker-support"></a>

Amazon ECS は、Amazon Linux で公開された Docker の直近の 2 つの主要バージョンをサポートしています。現在、これには Docker 20.10.x と Docker 25.x が含まれます。

Amazon ECS に必要な最低限の Docker バージョンは、GitHub の [Amazon ECS エージェント仕様ファイル](https://github.com/aws/amazon-ecs-agent/blob/dev/packaging/amazon-linux-ami-integrated/ecs-agent.spec#L53)にあります。

Amazon ECS に最適化された AMI を使用する場合、Docker は Amazon ECS コンテナエージェントで動作するように事前にインストールおよび設定されています。AMI には、Amazon ECS でテストおよびサポートされている Docker バージョンが含まれています。

**注記**  
Amazon ECS は複数の Docker バージョンをサポートしていますが、最高の互換性とサポートを確保するために、Amazon ECS 最適化 AMI に付属する Docker バージョンを使用することをお勧めします。

## Amazon ECS に最適化された AMI
<a name="ecs-optimized-ami"></a>

Amazon ECS に最適化された AMI の詳細については、「[Amazon ECS に最適化された Linux AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)」を参照してください。

## 追加情報
<a name="additional-information"></a>

次のページでは、変更に関する追加情報を説明します。
+ GitHub の [Amazon ECS Agent の変更ログ](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md)
+ [Amazon Linux 2 リリースノート](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html)。
+ Docker ドキュメントの「[Docker Engine リリースノート](https://docs.docker.com/engine/release-notes/27/)」
+ NVIDIA ドキュメントの「[NVIDIA ドライバードキュメント](https://docs.nvidia.com/datacenter/tesla/index.html)」

# Amazon ECS コンテナエージェントの設定
<a name="ecs-agent-config"></a>

**適用対象**: EC2 インスタンス

Amazon ECS コンテナエージェントでは、多数の設定オプションがサポートされており、そのほとんどは環境変数を介して設定します。

コンテナインスタンスが Amazon ECS に最適化されたAMIの Linux バリアントを使用して起動された場合は、これらの環境変数を `/etc/ecs/ecs.config` ファイルに設定してからエージェントを再び開始できます。起動時に Amazon EC2 ユーザーデータを使用して、コンテナインスタンスにこれらの設定変数を作成することもできます。詳細については、「[Amazon ECS Linux コンテナインスタンスをブートストラップしてデータを渡す](bootstrap_container_instance.md)」を参照してください。

コンテナインスタンスが Amazon ECS に最適化された AMI の Windows バリアントを使用して起動された場合は、PowerShell SetEnvironmentVariable コマンドを使用して、これらの環境変数を設定してからエージェントを再び開始できます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[ユーザーデータ入力を使用して EC2 インスタンスを起動するときにコマンドを実行する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)」および「[Amazon ECS Windows コンテナインスタンスをブートストラップしてデータを渡す](bootstrap_windows_container_instance.md)」を参照してください。

Amazon ECS コンテナエージェントを手動で開始する場合 ( Amazon ECSに最適化されていない AMI い場合)、これらの環境変数は、エージェントの起動に使用する **docker run** コマンドで使用できます。これらの変数は構文 `--env=VARIABLE_NAME=VARIABLE_VALUE` で使用します。プライベートリポジトリの認証情報など、機密性の高い情報の場合は、エージェントの環境変数をファイルに保存し、`--env-file path_to_env_file` オプションを使用して、それらすべてを一度に渡す必要があります。以下のコマンドを使用して変数を追加できます。

```
sudo systemctl stop ecs
sudo vi /etc/ecs/ecs.config 
# And add the environment variables with VARIABLE_NAME=VARIABLE_VALUE format.
sudo systemctl start ecs
```

## ホスト PID 名前空間を使用した Amazon ECS エージェントの実行
<a name="ecs-agent-pid-namespace"></a>

デフォルトで、Amazon ECS エージェントは独自の PID 名前空間で実行されます。以下の設定で、ホスト PID 名前空間で実行するように Amazon ECS エージェントを設定できます。
+ SELinux 強制モードが有効になっています。
+ Docker の SELinux セキュリティポリシーが true に設定されています。

この動作を設定するには、`/etc/ecs/ecs.config` ファイルで `ECS_AGENT_PID_NAMESPACE_HOST` 環境変数を `true` に設定します。この変数を有効にすると、`ecs-init` はホストの PID 名前空間 (`--pid=host`) で Amazon ECS エージェントコンテナを起動します。これにより、エージェントは SELinux 強制環境で適切に自身をブートストラップできます。この機能は、Amazon ECS エージェントバージョン `1.94.0` 以降で使用できます。

この機能を有効にするには、`/etc/ecs/ecs.config` ファイルに次の行を追加します。

```
ECS_AGENT_PID_NAMESPACE_HOST=true
```

この変更を行った後に、Amazon ECS エージェントを再起動して変更を有効にします。

```
sudo systemctl restart ecs
```

以下の機能は、SELinux 強制モードが有効で、Docker セキュリティポリシーが true に設定されている場合でも、`ECS_AGENT_PID_NAMESPACE_HOST=true` が設定されていても動作しません。
+ Amazon ECS Exec
+ Amazon EBS タスクアタッチ
+ Service Connect
+ Amazon ECS の FireLens

## 使用できるパラメータ
<a name="ecs-agent-availparam"></a>

使用可能な Amazon ECS コンテナエージェントの設定パラメータについては、GitHub の「[Amazon ECS コンテナエージェント](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)」を参照してください。

# Amazon S3 に Amazon ECS コンテナインスタンスの設定を保存する
<a name="ecs-config-s3"></a>

Amazon ECS コンテナエージェントの設定は、環境変数によって制御されます。Amazon ECS に最適化されたAMIの Linux バリアントは、コンテナエージェントの起動時に `/etc/ecs/ecs.config` でこれらの変数を検索し、見つかった変数に応じてエージェントを設定します。`ECS_CLUSTER` などの機密性の低い環境変数は、Amazon EC2 のユーザーデータを経由して起動時にコンテナインスタンスに渡され、そのままこのファイルに書き込まれます。ただし、AWS 認証情報や `ECS_ENGINE_AUTH_DATA` 変数など機密性の高い情報は、ユーザーデータでインスタンスに渡したり、`.bash_history` ファイルに表示される可能性のある方法で `/etc/ecs/ecs.config` に書き込んだりしないでください。

設定情報を Amazon S3 のプライベートバケットに保存し、コンテナインスタンスの IAM ロールに読み取り専用アクセス権限を付与するのが、コンテナインスタンスの起動時に設定を許可する安全で便利な方法です。`ecs.config` ファイルのコピーはプライベートバケットに保存できます。その後、AWS CLI Amazon EC2 ユーザーデータを使用してをインストールし、インスタンスの起動時に設定情報を `/etc/ecs/ecs.config` にコピーできます。

**`ecs.config` Amazon S3 のファイルを保存するには**

1. コンテナインスタンスロール (**ecsInstanceRole**) に、Amazon S3 への読み取り専用アクセス権を持つためのアクセス許可を付与する必要があります。これを行うには、**AmazonS3ReadOnlyAccess** を `ecsInstanceRole` ロールに割り当てます。ポリシーをロールにアタッチする方法については、「*AWS Identity and Access Management ユーザーガイド*」の「[ロールに対するアクセス許可を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)」を参照してください。

1. 次の形式を使用して、有効な Amazon ECS エージェントの設定変数を含む `ecs.config` ファイルを作成します。この例では、プライベートレジストリ認証を設定しています。詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。

   ```
   ECS_ENGINE_AUTH_TYPE=dockercfg
   ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
   ```
**注記**  
利用可能な Amazon ECS エージェントの設定変数の完全なリストについては、GitHub の「[Amazon ECS コンテナエージェント](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)」を参照してください。

1. 設定ファイルを保存するには、Amazon S3 内にプライベートバケットを作成します。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)」を参照してください。

1. `ecs.config` ファイルを S3 バケットにアップロードします。詳細については、*Amazon Simple Storage Service 開発者ガイド*の「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)」を参照してください。

**起動時に `ecs.config` ファイルを Amazon S3 からロードするには**

1. このセクションの上記の手順を完了して、読み取り専用 Amazon S3 アクセス権限をコンテナインスタンスに許可し、 `ecs.config` ファイルをプライベート S3 バケットに保存します。

1. 新しいコンテナインスタンスを起動し、EC2 ユーザーデータで次のサンプルスクリプトを使用します。このスクリプトは AWS CLI をインストールし、設定ファイルを `/etc/ecs/ecs.config` にコピーします。詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。

   ```
   #!/bin/bash
   yum install -y aws-cli
   aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
   ```

# Amazon ECS コンテナエージェントをインストールする
<a name="ecs-agent-install"></a>

Amazon ECS クラスターに Amazon EC2 インスタンスを登録する必要があり、そのインスタンスが Amazon ECS に最適化された AMI に基づく AMI を使用していない場合は、次の手順を使用して Amazon ECS コンテナエージェントを手動でインストールできます。これを行うには、リージョンの Amazon S3 バケットのいずれかから、または Amazon Elastic Container Registry Public からエージェントをダウンロードできます。リージョンの Amazon S3 バケットのいずれかからダウンロードする場合は、必要に応じて、PGP 署名を使用してコンテナエージェントファイルの有効性を検証できます。

**注記**  
Amazon ECS と Docker サービスの両方の `systemd` ユニットには、両方のサービスを開始する前に `cloud-init` が終了するのを待つディレクティブがあります。Amazon EC2ユーザーデータの実行が終了するまで、`cloud-init` プロセスは終了したと見なされません。したがって、Amazon EC2 ユーザーデータを介して Amazon ECS または Docker を起動すると、デッドロックが発生する可能性があります。Amazon EC2 ユーザーデータを使用してコンテナエージェントを起動するには、`systemctl enable --now --no-block ecs.service` を使用できます。

## 非 Amazon Linux EC2 インスタンスに Amazon ECS コンテナエージェントをインストールする
<a name="ecs-agent-install-nonamazonlinux"></a>

Amazon EC2 インスタンスに Amazon ECS コンテナエージェントをインストールするには、リージョンの Amazon S3 バケットのいずれかからエージェントをダウンロードしてインストールできます。

**注記**  
Amazon Linux AMI 以外を使用する場合、Amazon ECS エージェントがタスクレベルのリソース制限をサポートするためには、Amazon EC2 インスタンスは `cgroup` ドライバーの `cgroupfs` サポートが必要です。詳細については、[GitHub で Amazon ECS エージェントについて](https://github.com/aws/amazon-ecs-agent)参照してください。

各システムアーキテクチャの最新 Amazon ECS コンテナエージェントファイルは、リージョン別に参考として以下に示します。


| リージョン | リージョン名 | Amazon ECS init deb ファイル | Amazon ECS init rpm ファイル | 
| --- | --- | --- | --- | 
| us-east-2 | 米国東部 (オハイオ) |  [Amazon ECS init amd64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us–east–1 | 米国東部 (バージニア北部) |  [Amazon ECS init amd64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-west-1 | 米国西部 (北カリフォルニア) |  [Amazon ECS init amd64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-west-2 | 米国西部 (オレゴン) |  [Amazon ECS init amd64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-east-1 | アジアパシフィック (香港) |  [Amazon ECS init amd64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-northeast-1 | アジアパシフィック (東京) |  [Amazon ECS init amd64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-northeast-2 | アジアパシフィック (ソウル) |  [Amazon ECS init amd64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-south-1 | アジアパシフィック (ムンバイ) |  [Amazon ECS init amd64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-southeast-1 | アジアパシフィック (シンガポール) |  [Amazon ECS init amd64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-southeast-2 | アジアパシフィック (シドニー) |  [Amazon ECS init amd64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ca-central-1 | カナダ (中部) |  [Amazon ECS init amd64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-central-1 | 欧州 (フランクフルト) |  [Amazon ECS init amd64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-1 | 欧州 (アイルランド) |  [Amazon ECS init amd64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-2 | 欧州 (ロンドン) |  [Amazon ECS init amd64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-3 | 欧州 (パリ) |  [Amazon ECS init amd64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| sa-east-1 | 南米 (サンパウロ) |  [Amazon ECS init amd64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.x86_64.rpm) [Amazon ECS init aarch64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-gov-east-1 | AWS GovCloud (米国東部) |  [Amazon ECS init amd64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-gov-west-1 | AWS GovCloud (米国西部) |  [Amazon ECS init amd64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 

**非 Amazon Linux AMI を使用した Amazon EC2 インスタンスに Amazon ECS コンテナエージェントをインストールするには**

1. Amazon ECSへのアクセスを許可する IAM; ロールを使用して Amazon EC2インスタンスを起動します。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。

1. インスタンスに接続します。

1. 最新バージョンの Docker をインスタンスにインストールします。

1. Docker のバージョンをチェックして、システムがバージョンの最小要件を満たしていることを確認します。Docker のサポートの詳細については、「[Amazon ECS EC2 コンテナインスタンス](ecs-agent-versions.md)」を参照してください。

   ```
   docker --version
   ```

1. オペレーティングシステムとシステムアーキテクチャ用の適切な Amazon ECS エージェントファイルをダウンロードし、インストールします。

   `deb` アーキテクチャの場合:

   ```
   ubuntu:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb
   ubuntu:~$ sudo dpkg -i amazon-ecs-init-latest.amd64.deb
   ```

   `rpm` アーキテクチャの場合:

   ```
   fedora:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm
   fedora:~$ sudo yum localinstall -y amazon-ecs-init-latest.x86_64.rpm
   ```

1. `/lib/systemd/system/ecs.service` ファイルを編集し、`[Unit]` セクションの最後に次の行を追加します。

   ```
   After=cloud-final.service
   ```

1. (オプション) インスタンスを `default` クラスター以外のクラスターに登録するには、`/etc/ecs/ecs.config` ファイルを編集して以下の内容を追加します。次の例は `MyCluster` クラスターを指定します。

   ```
   ECS_CLUSTER=MyCluster
   ```

   これらや他のエージェントランタイムオプションの詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
**注記**  
オプションで、エージェント環境変数を Amazon S3 に保存できます (これらの環境変数は、Amazon EC2 ユーザーデータを使用して、起動時にコンテナインスタンスにダウンロードできます)。これは、プライベートリポジトリの認証情報のような機密情報の場合に推奨されます。詳細については、「[Amazon S3 に Amazon ECS コンテナインスタンスの設定を保存する](ecs-config-s3.md)」および「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。

1. `ecs` サービスを開始します。

   ```
   ubuntu:~$ sudo systemctl start ecs
   ```

## ホストネットワークモードで Amazon ECS エージェントを実行する
<a name="container_agent_host"></a>

Amazon ECSコンテナエージェントを実行している場合、`ecs-init` は `host` ネットワークモードでコンテナエージェントのコンテナを作成します。これは、コンテナエージェントのコンテナでサポートされている唯一のネットワークモードです。

これにより、コンテナエージェントにより開始されたコンテナの [Amazon EC2 インスタンスのメタデータサービスエンドポイント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) (`http://169.254.169.254`) へのアクセスをブロックできます。これにより、コンテナはコンテナインスタンスプロファイルから IAM ロール認証情報にアクセスできなくなります。また、タスクでは IAM タスクロールの認証情報のみが使用されます。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。

また、コンテナエージェントが `docker0` ブリッジ上の接続とネットワークトラフィックで競合しないようにもできます。

## Amazon ECS コンテナエージェントのログ設定パラメータ
<a name="agent-logs"></a>

Amazon ECS コンテナエージェントは、コンテナインスタンスのログを保存します。

コンテナエージェントバージョン 1.36.0 以降の場合、デフォルトでは、ログは Linux インスタンスの `/var/log/ecs/ecs-agent.log` および Windows インスタンスの `C:\ProgramData\Amazon\ECS\log\ecs-agent.log` にあります。

コンテナエージェントバージョン 1.35.0 以前の場合、デフォルトでは、ログは Linux インスタンスの `/var/log/ecs/ecs-agent.log.timestamp` および Windows インスタンスの `C:\ProgramData\Amazon\ECS\log\ecs-agent.log.timestamp` にあります。

デフォルトでは、エージェントログは 1 時間ごとにローテーションされ、最大 24 個のログが保存されます。

以下のコンテナエージェントの設定変数は、エージェントのデフォルトのログ記録動作を変更するために使用できます。使用可能なすべての設定パラメータの詳細については、[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md) または GitHub の「[Amazon ECS Agent README](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)」を参照してください。

コンテナエージェントバージョン 1.36.0 以降では、`logfmt` 形式を使用した場合のログファイルは以下の例のようになります。

```
level=info time=2019-12-12T23:43:29Z msg="Loading configuration" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-agent:latest" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Amazon ECS agent Version: 1.36.0, Commit: ca640387" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Creating root ecs cgroup: /ecs" module=init_linux.go
level=info time=2019-12-12T23:43:29Z msg="Creating cgroup /ecs" module=cgroup_controller_linux.go
level=info time=2019-12-12T23:43:29Z msg="Loading state!" module=statemanager.go
level=info time=2019-12-12T23:43:29Z msg="Event stream ContainerChange start listening..." module=eventstream.go
level=info time=2019-12-12T23:43:29Z msg="Restored cluster 'auto-robc'" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Restored from checkpoint file. I am running as 'arn:aws:ecs:us-west-2:0123456789:container-instance/auto-robc/3330a8a91d15464ea30662d5840164cd' in cluster 'auto-robc'" module=agent.go
```

JSON 形式を使用した場合のログファイルは以下の例のようになります。

```
{"time": "2019-11-07T22:52:02Z", "level": "info", "msg": "Starting Amazon Elastic Container Service Agent", "module": "engine.go"}
```

# プライベート Docker イメージ用の Amazon ECS コンテナインスタンスを設定する
<a name="private-auth-container-instances"></a>

Amazon ECS コンテナエージェントは、基本認証を使用してプライベートレジストリで認証できます。プライベートレジストリ認証を有効にすると、タスク定義のプライベート Docker イメージを使用できます。この機能は、EC2 を使用するタスクでのみサポートされています。

プライベートレジストリ認証を有効にする別の方法では、AWS Secrets Manager を使用して、プライベートレジストリ認証情報を安全に保存してから、コンテナの定義で参照します。これにより、プライベートリポジトリのイメージをタスクで使用できるようになります。このメソッドは、EC2 または Fargate のいずれかを使用するタスクをサポートします。詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。

Amazon ECS コンテナエージェントでは、起動時に次の 2 つの環境変数を検索します。
+ `ECS_ENGINE_AUTH_TYPE`。送信する認証データのタイプを指定します。
+ `ECS_ENGINE_AUTH_DATA`。実際の認証情報が含まれます。

Amazon ECSに最適化されたAMIのLinuxバリアントは、コンテナインスタンスの起動時、およびサービスが開始されるたびに（**sudo start ecs** コマンドを使用して）、`/etc/ecs/ecs.config` ファイルをスキャンしてこれらの変数を探します。Amazon ECSに最適化されていないAMIは、これらの環境変数をファイルに保存し、`--env-file path_to_env_file`オプションを付けてコンテナエージェントを起動する**docker run**コマンドに渡す必要があります。

**重要**  
これらの認証環境変数を、 Amazon EC2 ユーザーデータを使用してインスタンス起動時に挿入することや、`--env` オプションを使用して **docker run** コマンドに渡すことはお勧めしません。これらの方法は、認証情報などの機密データには適していません。認証情報をコンテナインスタンスに安全に追加する方法については、「[Amazon S3 に Amazon ECS コンテナインスタンスの設定を保存する](ecs-config-s3.md)」を参照してください。

## 認証形式
<a name="docker-auth-formats"></a>

プライベートレジストリ認証には、`dockercfg` と `docker` の 2 つの形式を使用できます。

**dockercfg 認証形式**  
`dockercfg` 形式は、**docker login** コマンドの実行時に作成した設定ファイルに保存されている認証情報を使用します。このファイルを作成するには、ローカルシステムで **docker login** を実行し、レジストリのユーザー名、パスワード、および E メールアドレスを入力します。コンテナインスタンスにログインして、そこでコマンドを実行することもできます。Docker のバージョンによって、ファイルは `~/.dockercfg` または `~/.docker/config.json` として保存されます。

```
cat ~/.docker/config.json
```

出力:

```
{
  "auths": {
    "https://index.docker.io/v1/": {
      "auth": "zq212MzEXAMPLE7o6T25Dk0i"
    }
  }
}
```

**重要**  
Docker の新しいバージョンは、外部 `auths` オブジェクトを使用して、上に示したような設定ファイルを作成します。Amazon ECS エージェントは、`auths` オブジェクトを持たない、以下の形式の `dockercfg` 認証データのみをサポートします。**jq** ユーティリティをインストール済みである場合、このデータは **cat \$1/.docker/config.json \$1 jq .auths** コマンドを使用して抽出できます。

```
cat ~/.docker/config.json | jq .auths
```

出力:

```
{
  "https://index.docker.io/v1/": {
    "auth": "zq212MzEXAMPLE7o6T25Dk0i",
    "email": "email@example.com"
  }
}
```

上記の例では、以下の環境変数を、Amazon ECS コンテナエージェントが実行時にロードする環境変数ファイル ( `/etc/ecs/ecs.config` Amazon ECSに最適化された AMI の場合は ) に追加しなければなりません。Amazon ECS に最適化された AMI を使用せず、 **docker run** を使用して手動でエージェントを開始する場合は、エージェント開始時に `--env-file path_to_env_file` オプションを使用して環境変数ファイルを指定します。

```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```

次の構文を使用して複数のプライベートレジストリを設定できます。

```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example-01.com"},"repo.example-02.com":{"auth":"fQ172MzEXAMPLEoF7225DU0j","email":"email@example-02.com"}}
```

**docker 認証形式**  
`docker` 形式は、エージェントが認証する必要があるレジストリサーバーの JSON 表現を使用します。また、そのレジストリに必要な認証パラメータ (ユーザー名、パスワード、およびそのアカウントの E メールアドレスなど) も含まれます。Docker Hub アカウントの場合、JSON 表現は次のようになります。

```
{
  "https://index.docker.io/v1/": {
    "username": "my_name",
    "password": "my_password",
    "email": "email@example.com"
  }
}
```

この例では、以下の環境変数を、Amazon ECS コンテナエージェントが実行時にロードする環境変数ファイル ( `/etc/ecs/ecs.config` Amazon ECSに最適化された AMI の場合は ) に追加する必要があります。Amazon ECS に最適化された AMI を使用せず、 **docker run** を使用して手動でエージェントを開始する場合は、エージェント開始時に `--env-file path_to_env_file` オプションを使用して環境変数ファイルを指定します。

```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
```

次の構文を使用して複数のプライベートレジストリを設定できます。

```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"username":"my_name","password":"my_password","email":"email@example-01.com"},"repo.example-02.com":{"username":"another_name","password":"another_password","email":"email@example-02.com"}}
```

## 手順
<a name="enabling-private-registry"></a>

以下の手順を使用して、コンテナインスタンスのプライベートレジストリをオン状態にします。

**Amazon ECS に最適化された AMI のプライベートレジストリを有効にするには**

1. SSH を使用してコンテナインスタンスにログインします。

1. `/etc/ecs/ecs.config` ファイルを開いて、レジストリとアカウントの `ECS_ENGINE_AUTH_TYPE` 値と `ECS_ENGINE_AUTH_DATA` 値を追加します。

   ```
   sudo vi /etc/ecs/ecs.config
   ```

   この例では Docker Hub のユーザーアカウントが認証されます。

   ```
   ECS_ENGINE_AUTH_TYPE=docker
   ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
   ```

1. エージェントが `ECS_DATADIR` 環境変数を使用して状態を保存しているかどうかを確認します。

   ```
   docker inspect ecs-agent | grep ECS_DATADIR
   ```

   出力:

   ```
   "ECS_DATADIR=/data",
   ```
**重要**  
前のコマンドで `ECS_DATADIR` 環境変数が返されない場合は、エージェントを停止する前に、このコンテナインスタンスで実行されているタスクをすべて停止する必要があります。より新しいエージェントは `ECS_DATADIR` 環境変数を使用して状態を保存するため、タスクが実行中でも問題なく停止および起動できます。詳細については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。

1. `ecs` サービスを停止します。

   ```
   sudo stop ecs
   ```

   出力:

   ```
   ecs stop/waiting
   ```

1. `ecs` サービスを再起動します。
   + Amazon ECS に最適化された Amazon Linux 2 AMI の場合:

     ```
     sudo systemctl restart ecs
     ```
   + Amazon ECS に最適化された Amazon Linux AMI の場合:

     ```
     sudo stop ecs && sudo start ecs
     ```

1. (オプション) エージェント詳細分析 API オペレーションをクエリして、エージェントが実行されていることを確認し、新しいコンテナインスタンスに関する情報の一部を表示できます。詳細については、「[Amazon ECS コンテナの詳細分析](ecs-agent-introspection.md)」を参照してください。

   ```
   curl http://localhost:51678/v1/metadata
   ```

# Amazon ECS タスクとイメージの自動クリーンアップ
<a name="automated_image_cleanup"></a>

タスクがコンテナインスタンスに配置されるたびに、Amazon ECS コンテナエージェントによって、タスクが参照するイメージがリポジトリの指定されたタグの最新版であるかどうかが確認されます。そうでない場合、デフォルトの動作では、エージェントがそれぞれのリポジトリからイメージを取得します。タスクやサービスで頻繁にイメージを更新する場合は、コンテナインスタンスのストレージが、もう使用しておらず、今後使用する予定もない Docker イメージですぐにいっぱいになってしまいます。例えば、継続的な統合や継続的なデプロイ (CI/CD) パイプラインを使用している場合です。

**注記**  
Amazon ECS エージェントイメージのプル動作は、`ECS_IMAGE_PULL_BEHAVIOR` パラメータを使用してカスタマイズできます。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。

同様に、停止したタスクに属するコンテナも、ログ情報、データボリューム、その他の生成物でコンテナインスタンスストレージを消費します。これらの生成物は、コンテナが予期せずに停止した場合のデバッグには役に立ちますが、このストレージのほとんどが一定期間後は安全に解放できます。

デフォルトでは、Amazon ECS コンテナエージェントによって、停止したタスクとコンテナインスタンスのどのタスクでも使用されていない Docker イメージがクリーンアップされます。

**注記**  
自動イメージクリーンアップ機能には、Amazon ECS コンテナエージェントのバージョン 1.13.0 以上が必要です。エージェントを最新バージョンに更新するには、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。

以下のエージェント設定変数を使用して、タスクとイメージの自動クリーンアップの使い勝手を調整できます。コンテナインスタンスでこれらの変数を設定する方法の詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。

`ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`  
停止したタスクのコンテナを削除する際のデフォルトの待機時間。1 未満に設定すると、その値は無視されます。デフォルトでは、このパラメータは 3 時間に設定されていますが、アプリケーションでの必要に応じて、最短で 1 秒まで短縮できます。  
イメージクリーンアッププロセスは、そのイメージを参照するコンテナがある限りイメージを削除できません。コンテナが削除されると、参照されていない画像は、いずれも画像クリーンアップの設定パラメーターに基づいてクリーンアップの対象となります。

`ECS_DISABLE_IMAGE_CLEANUP`  
この変数を `true` に設定した場合は、コンテナインスタンスでのイメージの自動クリーンアップはオフになり、イメージの自動的な削除は実行されません。

`ECS_IMAGE_CLEANUP_INTERVAL`  
この変数は、イメージの自動クリーンアッププロセスが削除するイメージをチェックする頻度を指定します。デフォルトでは 30 分ごとですが、より頻繁にイメージを削除するには最短で 10 分まで短くできます。

`ECS_IMAGE_MINIMUM_CLEANUP_AGE`  
この変数は、イメージが取得されてから、削除の対象になるまでの期間の最短時間を指定します。これは、取得されたばかりのイメージがクリーンアップされるのを防ぐために使用されます。デフォルトは 1 時間です。

`ECS_NUM_IMAGES_DELETE_PER_CYCLE`  
この変数は、1 つのクリーンアップサイクルで削除するイメージの数を指定します。デフォルトは 5 で、最小は 1 です。

Amazon ECS コンテナエージェントが実行中でありイメージの自動クリーンアップがオフになっていない場合、エージェントは `ECS_IMAGE_CLEANUP_INTERVAL` 変数で決定された頻度で、実行中または停止されたコンテナから参照されていない Docker イメージをチェックします。使用されていないイメージが見つかり、それらが `ECS_IMAGE_MINIMUM_CLEANUP_AGE` 変数で指定された最短クリーンアップ時間よりも古い場合、エージェントは `ECS_NUM_IMAGES_DELETE_PER_CYCLE` 変数で指定された最大数までイメージを削除します。最後に参照された日時が最も古いイメージから順に削除されます。イメージが削除されると、エージェントは次の間隔まで待ってから、再度プロセスを繰り返します。