# Amazon ECS がタスクをコンテナインスタンスに配置する方法
<a name="task-placement"></a>

タスク配置を使用して、アベイラビリティーゾーンやインスタンスタイプなど、特定の基準を満たすコンテナインスタンスにタスクを配置するように Amazon ECS を設定できます。

以下はタスク配置のコンポーネントです。
+ タスク配置戦略 - タスク配置またはタスクの終了でコンテナインスタンスを選択するためのアルゴリズムです。例えば、Amazon ECS でランダムにコンテナインスタンスを選択することも、インスタンスのグループ間に均等に分散されているタスクを持つコンテナインスタンスを選択することもできます。
+ タスクグループ - データベースタスクなどの関連タスクのグループ。
+ タスク配置制約事項 - コンテナインスタンスにタスクを配置するために満たす必要があるルールです。この制約が満たされない場合、タスクは配置されず、`PENDING` 状態のままになります。たとえば、制約を使用して、特定のインスタンスタイプにのみタスクを割り当てることができます。

Amazon ECS には、容量オプションごとに異なるアルゴリズムがあります。

## Amazon ECS マネージドインスタンス
<a name="managed-instances-launch-type"></a>

Amazon ECS マネージドインスタンスで実行されるタスクの場合、Amazon ECS はタスクを配置する場所と、タスク数をスケールダウンするときに終了するタスクを決定する必要があります。Amazon ECS は、キャパシティプロバイダーの起動テンプレートで指定されたインスタンス要件、CPU やメモリなどのタスク定義で指定された要件、およびタスクの配置に関する制約に基づいて、この決定を行います。

**注記**  
Amazon ECS マネージドインスタンスはタスク配置戦略をサポートしていません。Amazon ECS は、アクセス可能なアベイラビリティーゾーンにタスクを分散するよう最善を尽くします。

Amazon ECSがタスクを配置する際は、以下のプロセスでコンテナインスタンスを選択します。

1. タスク定義の CPU、GPU、メモリ、ポートの要件を満たすコンテナインスタンスを識別します。

1. タスク配置の制約事項を満たすコンテナインスタンスを識別します。

1. キャパシティプロバイダーの起動テンプレートで指定されたインスタンスの要件を満たしているコンテナインスタンスを特定します。

1. タスクを配置するコンテナインスタンスを選択します。

## EC2
<a name="ec2-launch-type"></a>

EC2 起動タイプを使用するタスクには、Amazon ECS ではタスク定義で指定されている CPU やメモリなどの要件に基づいてタスクを配置する場所を決定する必要があります。同様に、タスク数を減らすときも、Amazon ECS でどのタスクを終了させるか決定する必要があります。タスク配置の戦略と制約を適用することで、Amazon ECS がタスクを配置および終了する方法をカスタマイズできます。

デフォルトのタスク配置戦略は、タスクを手動 (スタンドアロンタスク) で実行するのか、それともサービス内で実行するのかによって異なります。Amazon ECS サービスの一部として実行されるタスクの場合、タスク配置戦略は `attribute:ecs.availability-zone` を使用した `spread` です。サービス内にないタスクには、デフォルトのタスク配置の制約はありません。詳細については、「[Amazon ECS でコンテナをスケジュールする](scheduling_tasks.md)」を参照してください。

**注記**  
タスク配置戦略はベストエフォートです。Amazon ECSは、最適な配置オプションが利用できない場合でも、タスクの配置を試みます。ただし、タスク配置の制約が有効な場合、タスクを配置できないことがあります。

タスク配置戦略と制約は併用できます。例えば、タスク配置戦略とタスク配置制約を使用して、アベイラビリティーゾーン間でタスクを分散し、各アベイラビリティーゾーン内のメモリに基づいてビンパックタスクを分散できます。ただし、G2 インスタンスのみです。

Amazon ECSがタスクを配置する際は、以下のプロセスでコンテナインスタンスを選択します。

1. タスク定義の CPU、GPU、メモリ、ポートの要件を満たすコンテナインスタンスを識別します。

1. タスク配置の制約事項を満たすコンテナインスタンスを識別します。

1. タスク配置戦略を満たすコンテナインスタンスを識別します。

1. タスクを配置するコンテナインスタンスを選択します。

## Fargate
<a name="fargate-launch-type"></a>

タスクの配置戦略および制約事項は、Fargate を使用しているタスクをサポートしていません。Fargate は、アクセス可能なアベイラビリティーゾーンにタスクを分散するよう最善を尽くします。キャパシティープロバイダーに Fargate と Fargate Spot の両方が含まれている場合、スプレッドの動作はキャパシティープロバイダーごとに異なります。

# Amazon ECS マネージドインスタンスの自動スケーリングとタスク配置
<a name="managed-instance-auto-scaling"></a>

Amazon ECS マネージドインスタンスは、インテリジェントなアルゴリズムを使用してクラスターの容量を自動的にスケーリングし、インフラストラクチャ全体にタスクを効率的に配置します。これらのアルゴリズムの仕組みを理解することで、サービス設定を最適化し、配置動作をトラブルシューティングできます。

## タスク配置アルゴリズム
<a name="managed-instance-task-placement-algorithm"></a>

Amazon ECS マネージドインスタンスは、タスクのスケジュールを設定する際に可用性、リソース使用率、ネットワーク要件のバランスを確保する高度な配置アルゴリズムを使用します。

### 分散アベイラビリティーゾーン
<a name="managed-instance-az-spread-behavior"></a>

デフォルトでは、Amazon ECS マネージドインスタンスは複数のアベイラビリティーゾーンにタスクを分散することで可用性を優先します。
+ 複数のタスクが配置されているサービスの場合、Amazon ECS マネージドインスタンスは、可能であれば異なるアベイラビリティーゾーンの少なくとも 3 つのインスタンスに分散します。
+ この動作は耐障害性を実現しますが、インスタンスあたりのリソース使用率が低下する可能性があります。
+ 拡散アベイラビリティーゾーンは、ビンのパッキングの最適化よりも優先されます

### ビンのパッキング動作
<a name="managed-instance-bin-packing"></a>

Amazon ECS マネージドインスタンスは、リソース使用率を最大化するためにビンパッキングを実行できますが、この動作はネットワーク設定の影響を受けます。
+ ビンのパッキングを実現するには、単一のサブネットを使用するようにサービスを設定します。
+ マルチサブネット設定では、リソース密度よりもアベイラビリティーゾーンの分散が優先されます。
+ ビンのパッキングは、スケーリングイベント中よりも初回サービス起動時に実施される可能性が高くなります。

### ENI の密度に関する考慮事項
<a name="managed-instance-eni-density"></a>

`awsvpc` ネットワークモードを使用するサービスの場合、Amazon ECS マネージドインスタンスは配置を決定する際に Elastic Network Interface (ENI) の密度を考慮します。
+ `awsvpc` モードの各タスクには専用の ENI が必要です
+ インスタンスタイプには、タスク密度に影響するさまざまな ENI 制限があります
+ Amazon ECS マネージドインスタンスは、ターゲットインスタンスを選択するときに ENI の可用性を考慮します

**注記**  
ENI 密度の計算は、配置の決定を最適化するために継続的に改善されています。

## キャパシティプロバイダーの決定ロジック
<a name="managed-instance-capacity-provider-decisions"></a>

Amazon ECS マネージドインスタンスのキャパシティプロバイダーは、次の複数の要因に基づいてスケーリングと配置を決定します。

リソースの要件  
保留中のタスクの CPU、メモリ、ネットワークに関する要件

インスタンスの可用性  
既存のインスタンス全体の現在の容量と使用率

ネットワーキングの制約  
サブネット設定と ENI の可用性

アベイラビリティーゾーンの分散  
複数のアベイラビリティーゾーンにわたる耐障害性の維持

## 設定オプション
<a name="managed-instance-configuration-options"></a>

### サブネットの選択戦略
<a name="managed-instance-subnet-strategy"></a>

サブネット設定は、タスク配置の動作に大きな影響を与えます。

複数のサブネット (デフォルト)  
高可用性を実現するためにアベイラビリティーゾーンの拡散を優先する  
インスタンスあたりのリソース使用率が低下する可能性があります  
耐障害性を必要とする本番稼働用ワークロードに推奨

単一サブネット  
ビンパッキングを有効にしてリソース使用率を高める  
タスクを 1 つのアベイラビリティーゾーンに集約することで耐障害性を低減する  
開発またはコスト最適化ワークロードに適しています

### ネットワークモードに関する考慮事項
<a name="managed-instance-network-mode-considerations"></a>

選択したネットワークモードは、配置の決定に影響します。
+ `awsvpc` モード – 各タスクには専用の ENI が必要であり、インスタンスあたりのタスク密度が制限されます。
+ `host` モード – タスクはホストのネットワークを直接使用し、配置は主にリソースの可用性によって決定されます。

### CPU アーキテクチャに関する考慮事項
<a name="managed-instance-cpu-architecture-considerations"></a>

タスク定義で指定した `cpuArchitecture` は、特定のアーキテクチャにタスクを配置するために使用されます。`cpuArchitecture` を指定しない場合、Amazon ECS はキャパシティプロバイダーの設定に基づいて、使用可能な CPU アーキテクチャにタスクを配置しようとします。`X86_64` または `ARM64` のどちらかを指定できます。

## タスク配置のトラブルシューティング
<a name="managed-instance-troubleshooting-placement"></a>

### 一般的な配置パターン
<a name="managed-instance-common-placement-patterns"></a>

予想される配置パターンを理解すると、通常の動作と潜在的な問題を区別できるようになります。

分散ディストリビューション  
部分的な使用率で複数のインスタンスに分散されたタスク  
複数のサブネットを使用する場合の通常の動作  
リソース効率よりも可用性が優先されることを示します

集約された配置  
使用率の高い少数のインスタンスに配置された複数のタスク  
単一サブネット設定を使用する場合に想定されます  
最初のサービス起動中に発生する可能性があります

不均等な分散  
一部のインスタンスの使用率が非常に高い一方で、他のインスタンスについては使用率が低い状態が継続します。  
ENI の制限またはリソースの制約を示している場合があります  
インスタンスタイプとネットワーク設定の確認を検討する

### 配置動作の最適化
<a name="managed-instance-placement-optimization"></a>

特定の要件に合わせてタスク配置を最適化するには:

1. コスト最適化のニーズと照らし合わせて可用性要件を評価する

1. 優先順位に基づいて適切なサブネット設定を選択する

1. ネットワークモードに適した ENI 容量を持つインスタンスタイプを選択する

1. 配置パターンをモニタリングし、必要に応じて設定を調整する

## ベストプラクティス
<a name="managed-instance-best-practices"></a>
+ **本稼働ワークロードの場合** – 異なるアベイラビリティーゾーン間で複数のサブネットを使用して高可用性を確保し、リソース使用率のトレードオフを受け入れます。
+ **開発またはテストの場合** – リソース使用率を最大化し、コストを削減するために単一サブネット設定を検討する
+ **`awsvpc` モードの場合** – 配置の制約に抵触することを回避するために、十分な ENI 容量を持つインスタンスタイプを選択する
+ **コスト最適化の場合** – 使用率パターンをモニタリングし、可用性と効率性のバランスを取るようにサービス設定を調整する
+ **トラブルシューティングの場合** — 予期しない配置パターンを調査するときに、サブネット設定とネットワークモードを確認する

# 戦略を使用して Amazon ECS タスク配置を定義する
<a name="task-placement-strategies"></a>

EC2 起動タイプを使用するタスクには、Amazon ECS ではタスク定義で指定されている CPU やメモリなどの要件に基づいてタスクを配置する場所を決定する必要があります。同様に、タスク数を減らすときも、Amazon ECS でどのタスクを終了させるか決定する必要があります。タスク配置の戦略と制約を適用することで、Amazon ECS がタスクを配置および終了する方法をカスタマイズできます。

デフォルトのタスク配置戦略は、タスクを手動 (スタンドアロンタスク) で実行するのか、それともサービス内で実行するのかによって異なります。Amazon ECS サービスの一部として実行されるタスクの場合、タスク配置戦略は `attribute:ecs.availability-zone` を使用した `spread` です。サービス内にないタスクには、デフォルトのタスク配置の制約はありません。詳細については、「[Amazon ECS でコンテナをスケジュールする](scheduling_tasks.md)」を参照してください。

**注記**  
タスク配置戦略はベストエフォートです。Amazon ECSは、最適な配置オプションが利用できない場合でも、タスクの配置を試みます。ただし、タスク配置の制約が有効な場合、タスクを配置できないことがあります。

タスク配置戦略と制約は併用できます。例えば、タスク配置戦略とタスク配置制約を使用して、アベイラビリティーゾーン間でタスクを分散し、各アベイラビリティーゾーン内のメモリに基づいてビンパックタスクを分散できます。ただし、G2 インスタンスのみです。

Amazon ECSがタスクを配置する際は、以下のプロセスでコンテナインスタンスを選択します。

1. タスク定義の CPU、GPU、メモリ、ポートの要件を満たすコンテナインスタンスを識別します。

1. タスク配置の制約事項を満たすコンテナインスタンスを識別します。

1. タスク配置戦略を満たすコンテナインスタンスを識別します。

1. タスクを配置するコンテナインスタンスを選択します。

タスク配置戦略は、サービス定義または `placementStrategy` パラメータを使用したタスク定義で指定できます。

```
"placementStrategy": [
    {
        "field": "The field to apply the placement strategy against",
        "type": "The placement strategy to use"
    }
]
```

タスクを実行するとき ([RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html))、新しいサービスを作成するとき ([CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html))、または既存のサービスを更新するとき ([UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)) に戦略を指定できます。

次の表は利用可能なタイプとフィールドを説明しています。


| 型 | 有効なフィールド値 | 
| --- | --- | 
| binpack タスクはコンテナインスタンスに配置され、未使用の CPU またはメモリを最小にします。この戦略は、使用中のコンテナインスタンスの数を最小限に抑えます。 この戦略が使用されてスケールインアクションが実行されると、Amazon ECS はタスクを終了します。タスクが終了した後にコンテナインスタンスに残されたリソース量に基づいてこれが実行されます。タスクの終了後に利用可能なリソースが最も多く残るコンテナインスタンスが、そのタスクを終了されます。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 
| random タスクはランダムに配置されます。 | 使用されていない | 
| spreadタスクは指定された値に基づいて均等に配置されます。 サービスタスクはそのサービスからのタスクに基づいて分散されます。スタンドアロンタスクは、同じタスクグループからのタスクに基づいて分散されます。タスクグループの詳細については、「[Amazon ECS タスクをグループ化する](task-groups.md)」を参照してください。`spread` 戦略が使用されてスケールインアクションが実行されると、Amazon ECS は、アベイラビリティーゾーン間のバランスを維持するタスクを選択して終了します。アベイラビリティーゾーン内では、タスクはランダムに選択されます。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 

タスク配置の戦略は、既存のサービスに対しても更新できます。詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。

実行する順序で戦略の配列を作成することで、複数の戦略を使用するタスク配置戦略を作成できます。例えば、複数のアベイラビリティーゾーンにタスクを分散し、各アベイラビリティーゾーン内のメモリに基づいてタスクをビンパックする場合、アベイラビリティーゾーン戦略を指定し、その後にメモリ戦略を指定します。戦略の例については、「[Amazon ECS タスク配置戦略の例](strategy-examples.md)」を参照してください。

# Amazon ECS タスク配置戦略の例
<a name="strategy-examples"></a>

次のアクションを使用してタスク配置戦略を指定できます。[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)、[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)、および [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)。

**Topics**
+ [

## 複数のアベイラビリティーゾーンでタスクを均等に分散する
](#even-az)
+ [

## すべてのインスタンスでタスクを均等に分散する
](#even-instance)
+ [

## メモリに基づいてタスクをビンパックする
](#binpack)
+ [

## タスクをランダムに配置します。
](#random)
+ [

## 複数のアベイラビリティーゾーンでタスクを均等に分散し、各アベイラビリティーゾーン内で複数のインスタンスでタスクを均等に分散する
](#az-instance)
+ [

## 複数のアベイラビリティーゾーンでタスクを均等に分散し、各アベイラビリティーゾーン内でメモリに基づいてタスクをビンパックする
](#az-memory)
+ [

## 複数のインスタンスでタスクを均等に分散し、メモリに基づいてタスクをビンパックする
](#instance-memory)

## 複数のアベイラビリティーゾーンでタスクを均等に分散する
<a name="even-az"></a>

次の戦略は、アベイラビリティーゾーン間でタスクを均等に分散します。

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    }
]
```

## すべてのインスタンスでタスクを均等に分散する
<a name="even-instance"></a>

次の戦略は、すべてのインスタンス間でタスクを均等に分散します。

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## メモリに基づいてタスクをビンパックする
<a name="binpack"></a>

次の戦略はメモリに基づいてタスクをビンパックします。

```
"placementStrategy": [
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## タスクをランダムに配置します。
<a name="random"></a>

次の戦略はタスクをランダムに配置します。

```
"placementStrategy": [
    {
        "type": "random"
    }
]
```

## 複数のアベイラビリティーゾーンでタスクを均等に分散し、各アベイラビリティーゾーン内で複数のインスタンスでタスクを均等に分散する
<a name="az-instance"></a>

次の戦略は、アベイラビリティーゾーン間でタスクを均等に分散し、次に各アベイラビリティーゾーン内でインスタンスを均等に分散します。

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## 複数のアベイラビリティーゾーンでタスクを均等に分散し、各アベイラビリティーゾーン内でメモリに基づいてタスクをビンパックする
<a name="az-memory"></a>

次の戦略は、アベイラビリティーゾーン間でタスクを均等に分散し、次に各アベイラビリティーゾーン内でメモリに基づいてタスクをビンパックします。

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## 複数のインスタンスでタスクを均等に分散し、メモリに基づいてタスクをビンパックする
<a name="instance-memory"></a>

次の戦略は、すべてのインスタンスでタスクを均等に分散し、各インスタンス内のメモリに基づいてタスクをビンパックします。

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

# Amazon ECS タスクをグループ化する
<a name="task-groups"></a>

一連の関連するタスクを識別してタスクグループで配置できます。同じタスクグループ名のすべてのタスクは、`spread`タスクの配置戦略の使用時に、セットとして見なされます。例えば、データベースおよびウェブサーバーなど、1 つのクラスターで異なるアプリケーションを実行していることを想定します。データベースを確実にアベイラビリティーゾーン間に均等に分散するには、それらのデータベースを`databases`という名前のタスクグループに追加し、`spread`タスク配置戦略を使用します。詳細については、「[戦略を使用して Amazon ECS タスク配置を定義する](task-placement-strategies.md)」を参照してください。

タスクグループはタスク配置の制約にも使用できます。`memberOf` 制約でタスクグループを指定したとき、タスクは指定されたタスクグループ内のコンテナインスタンスにのみ送信されます。例については、[Amazon ECS タスク配置の制約事項の例](constraint-examples.md)を参照してください。

デフォルトでは、カスタムタスクグループ名が指定されていない場合、スタンドアロンタスクはタスク定義ファミリ名 (例えば `family:my-task-definition`) をタスクグループ名として使用します。サービスの一部として起動されたタスクは、サービス名をタスクグループ名として使用し、変更することはできません。

タスクグループには次の要件が適用されます。
+ タスクグループ名は 255 文字以下である必要があります。
+ 各タスクを 1 つのグループと同一にできます。
+ タスクを起動後、タスクグループを変更することはできません。

# Amazon ECS がタスクに使用するコンテナインスタンスを定義する
<a name="task-placement-constraints"></a>

タスク配置の制約事項は、Amazon ECS がインスタンス上でタスクを実行できるかどうかを判断するために使用するコンテナインスタンスに関するルールです。少なくとも 1 つのコンテナインスタンスが制約に一致する必要があります。制約に一致するインスタンスがない場合、タスクは `PENDING` 状態のままになります。新しいサービスを作成するか、既存のサービスを更新するときに、サービスのタスク用にタスク配置制約を指定できます。

`placementConstraint` パラメータを使用して、サービス定義、タスク定義、またはタスクでタスク配置制約事項を指定できます。

```
"placementConstraints": [
    {
        "expression": "The expression that defines the task placement constraints",
        "type": "The placement constraint type to use"
    }
]
```

次の表は、パラメータの使用法の説明です。


| [Constraint type (制約タイプ)] | 次の場合に指定できます。 | 
| --- | --- | 
| distinctInstanceそれぞれのアクティブタスクを別々のコンテナインスタンスに配置します。Amazon ECS は、タスク配置におけるタスクの目的のステータスを確認します。例えば、既存のタスクの目的のステータスが `STOPPED` の場合 (ただし、最後のステータスが目的のステータスではない場合)、`distinctInstance` 配置の制約事項にもかかわらず、新しい受信タスクを同じインスタンスに配置することができます。したがって、同じインスタンスで最後のステータスが `RUNNING` のタスクが 2 つ表示される場合があります。 タスクの強力な分離を求めているお客様には、Fargate を使用することをお勧めします。Fargate はハードウェア仮想化環境で各タスクを実行します。これにより、これらのコンテナ化されたワークロードがネットワークインターフェイス、Fargate の一時ストレージ、CPU、またはメモリを他のタスクと共有しないことが保証されます。詳細については、「[AWS Fargate のセキュリティの概要](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf)」をご参照ください。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-constraints.html)  | 
| memberOf式を満たすコンテナインスタンスにタスクを配置します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-constraints.html) | 

`memberOf` 制約事項タイプを使用すると、Amazon ECS がタスクを配置できるコンテナインスタンスを定義するクラスタークエリ言語を使用して式を作成できます。この式は、コンテナインスタンスを属性別にグループ化する方法です。この式は、`placementConstraint` の `expression ` パラメータに含まれます。

## Amazon ECS コンテナインスタンス属性
<a name="attributes"></a>

コンテナインスタンスに*属性*と呼ばれるカスタムメタデータを追加できます。各属性には名前とオプションの文字列値があります。Amazon ECSが提供する組み込み属性を使用することも、カスタム属性を定義することもできます。

次のセクションでは、組み込み型、オプション型、カスタム型属性のサンプルが含まれています。

### 組み込み属性
<a name="ecs-automatic-attributes"></a>

Amazon ECSは次の属性を自動的にコンテナインスタンスに適用します。

`ecs.ami-id`  
インスタンスの起動に使用される AMI の ID。この属性の値の例は「`ami-1234abcd`」です。

`ecs.availability-zone`  
インスタンスのアベイラビリティーゾーン。この属性の値の例は「`us-east-1a`」です。

`ecs.instance-type`  
インスタンスのインスタンスタイプ。この属性の値の例は「`g2.2xlarge`」です。

`ecs.os-type`  
インスタンスのオペレーティングシステム。この属性に指定できる値は `linux` と `windows` です。

`ecs.os-family`  
インスタンスのオペレーティングシステムのバージョン。  
Linux インスタンスの場合、有効な値は `LINUX` です。Windows インスタンスの場合、ECS は値を `WINDOWS_SERVER_<OS_Release>_<FULL or CORE>` 形式で設定します。有効な値は、`WINDOWS_SERVER_2022_FULL`、`WINDOWS_SERVER_2022_CORE`、`WINDOWS_SERVER_20H2_CORE`、`WINDOWS_SERVER_2019_FULL`、`WINDOWS_SERVER_2019_CORE`、および `WINDOWS_SERVER_2016_FULL` です。  
これは、Windows コンテナおよび Windows containers on AWS Fargate にとって重要です。なぜなら、すべての Windows コンテナの OS バージョンがホストのそれと一致する必要があるからです。コンテナイメージの Windows バージョンがホストと異なる場合、コンテナは起動しません。詳細については、マイクロソフトのドキュメント 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)」を参照してください。

`ecs.cpu-architecture`  
インスタンスの CPU アーキテクチャ。この属性の値の例は`x86_64` と `arm64` です。

`ecs.vpc-id`  
インスタンスが起動された VPC。この属性の値の例は「`vpc-1234abcd`」です。

`ecs.subnet-id`  
インスタンスが使用しているサブネット。この属性の値の例は「`subnet-1234abcd`」です。

**注記**  
Amazon ECS マネージドインスタンスは、次の属性のサブセットをサポートしています。  
`ecs.subnet-id`
`ecs.availability-zone`
`ecs.instance-type`
`ecs.cpu-architecture`

### オプションの属性
<a name="ecs-optional-attributes"></a>

Amazon ECS では、コンテナインスタンスに次の属性を追加することができます。

`ecs.awsvpc-trunk-id`  
この属性が存在する場合、インスタンスにトランクネットワークインターフェイスがあります。詳細については、「[Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす](container-instance-eni.md)」を参照してください。

`ecs.outpost-arn`  
この属性が存在する場合は、Outpost の Amazon Resource Name (ARN) が含まれます。詳細については、「[AWS OutpostsのAmazon Elastic Container Service](using-outposts.md)」を参照してください。

`ecs.capability.external`  
この属性が存在する場合、インスタンスは外部インスタンスとして識別されます。詳細については、「[外部インスタンスの Amazon ECS クラスター](ecs-anywhere.md)」を参照してください。

### カスタム属性
<a name="ecs-custom-attributes"></a>

コンテナインスタンスに、カスタム属性を適用できます。例えば、「stack」という名前で「prod」という値の属性を定義できます。

カスタム属性を指定するとき、次の点を考慮する必要があります。
+ `name` は、1～128 文字で指定する必要があります。文字 (大文字と小文字)、数字、ハイフン、アンダースコア、スラッシュ、バックスラッシュ、ピリオドを使用できます。
+ `value` は、1 ～ 128 文字で指定する必要があります。文字 (大文字と小文字)、数字、ハイフン、アンダースコア、ピリオド、アットマーク (@)、スラッシュ、バックスラッシュ、コロン、またはスペースを使用できます。値の先頭または末尾にホワイトスペースを含めることはできません。

# Amazon ECS タスク用のコンテナインスタンスを定義する式を作成する
<a name="cluster-query-language"></a>

クラスタークエリは、オブジェクトをグループ化できる式です。例えば、アベイラビリティーゾーン、インスタンスタイプ、カスタムメタデータなどの属性でコンテナインスタンスをグループ化できます。詳細については、「[Amazon ECS コンテナインスタンス属性](task-placement-constraints.md#attributes)」を参照してください。

コンテナインスタンスのグループを定義した後、グループに基づいてコンテナインスタンスのタスクを配置するように Amazon ECS をカスタマイズできます。詳細については「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」および「[Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)」を参照してください。また、コンテナインスタンスをリスト表示する際にグループフィルタを適用できます。

## 式の構文
<a name="expression-syntax"></a>

式の構文は次のとおりです。

```
subject operator [argument]
```

**件名**  
評価する属性またはフィールド。

`agentConnected`  
Amazon ECS コンテナエージェント接続ステータスでコンテナインスタンスを選択します。このフィルタを使用して、切断されたコンテナエージェントでインスタンスを検索します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、in、not\$1in (\$1in)、matches (=\$1)、not\$1matches (\$1\$1)

`agentVersion`  
Amazon ECS コンテナエージェントバージョンでコンテナインスタンスを選択します。このフィルタを使用して、Amazon ECS コンテナエージェントの古くなったバージョンを実行しているインスタンスを検索します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、greater\$1than (>)、greater\$1than\$1equal (>=)、less\$1than (<)、less\$1than\$1equal (<=)

`attribute:attribute-name`  
属性でコンテナインスタンスを選択します。詳細については、「[Amazon ECS コンテナインスタンス属性](task-placement-constraints.md#attributes)」を参照してください。

`ec2InstanceId`  
Amazon EC2 インスタンス ID で、コンテナインスタンスを選択します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、in、not\$1in (\$1in)、matches (=\$1)、not\$1matches (\$1\$1)

`registeredAt`  
コンテナインスタンス登録日で、コンテナインスタンスを選択します。このフィルタを使用して、新しく登録されたインスタンスまたは古いインスタンスを検索します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、greater\$1than (>)、greater\$1than\$1equal (>=)、less\$1than (<)、less\$1than\$1equal (<=)  
有効な日付形式: 2018-06-18T22:28:28\$100:00、2018-06-18T22:28:28Z、2018-06-18T22:28:28、2018-06-18

`runningTasksCount`  
実行中のタスクの数でコンテナインスタンスを選択します。このフィルタを使用して、空またはほぼ空 (実行中のタスクがほぼない) のインスタンスを検索します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、greater\$1than (>)、greater\$1than\$1equal (>=)、less\$1than (<)、less\$1than\$1equal (<=)

`task:group`  
コンテナインスタンスをタスクグループで選択します。詳細については、「[Amazon ECS タスクをグループ化する](task-groups.md)」を参照してください。

**オペレーター**  
比較演算子。以下の演算子がサポートされています。


|  演算子  |  説明  | 
| --- | --- | 
|  ==, が  |  文字列が等価  | 
|  \$1=、not\$1equals  |  文字列が不等価  | 
|  >、greater\$1than  |  以上  | 
|  >=、greater\$1than\$1equal  |  以上  | 
|  <、less\$1than  |  未満  | 
|  <=、less\$1than\$1equal  |  以下  | 
|  exists  |  対象が存在  | 
|  \$1exists、not\$1exists  |  サブジェクトが存在しません  | 
|  情報  |  引数リストの値  | 
|  \$1in、not\$1in  |  引数リストにない値  | 
|  =\$1、matches  |  パターンが一致  | 
|  \$1\$1、not\$1matches  |  パターンが不一致  | 

**注記**  
1 つの式に括弧を含めることはできません。ただし、複合式で優先順位を指定するために括弧を使用できます。

**引数**  
多くの演算子は、引数がリテラル値です。

`in` および `not_in` 演算子は、引数として引数リストを想定しています。次のように引数リストを指定します。

```
[argument1, argument2, ..., argumentN]
```

matches と not\$1matches 演算子は、Java の正規表現構文に準拠する引数を想定しています。詳細については、[java.util.regex.Pattern](http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html) を参照してください。

**複合式**

次のブール演算子を使用して式を結合できます。
+ &&, および
+ \$1\$1, または
+ \$1, 先頭の文字に

括弧を使用して、優先度を指定できます。

```
(expression1 or expression2) and expression3
```

## 式の例
<a name="expression-examples"></a>

以下に式の例を示します。

**例: 文字列が等価**  
次の式は指定されたインスタンスタイプのインスタンスを選択します。

```
attribute:ecs.instance-type == t2.small
```

**例: 引数リスト**  
次の式は、アベイラビリティーゾーンが us-east-1a または us-east-1b のインスタンスを選択します。

```
attribute:ecs.availability-zone in [us-east-1a, us-east-1b]
```

**例: 複合式**  
次の表現は、us-east-1d アベイラビリティーゾーンにはない G2 インスタンスを選択します。

```
attribute:ecs.instance-type =~ g2.* and attribute:ecs.availability-zone != us-east-1d
```

**例: タスクのアフィニティ**  
次の式は、`service:production` グループのタスクをホストするインスタンスを選択します。

```
task:group == service:production
```

**例: タスクのアンチアフィニティ**  
次の表現は、データベースグループでタスクをホストしないインスタンスを選択します。

```
not(task:group == database)
```

**例: 実行中のタスクの数**  
次の式は、1 つのタスクのみを実行しているインスタンスを選択します。

```
runningTasksCount == 1
```

**Amazon ECS コンテナエージェントバージョン**  
次の式は、コンテナエージェントバージョン 1.14.5 より前のバージョンを実行しているインスタンスを選択します。

```
agentVersion < 1.14.5
```

**例: インスタンス登録時**  
次の式は、2018 年 2 月 13 日以前に登録されているインスタンスを選択します。

```
registeredAt < 2018-02-13
```

**例: Amazon EC2 インスタンス ID**  
次の式は、以下の Amazon EC2 インスタンス ID のインスタンスを選択します。

```
ec2InstanceId in ['i-abcd1234', 'i-wxyx7890']
```

# Amazon ECS タスク配置の制約事項の例
<a name="constraint-examples"></a>

以下はタスク配置の制約事項の例です。

この例では、`memberOf` 制約を使用して T2 インスタンスにタスクを配置します。次のアクションを使用して指定できます。[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)、[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)、[RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html)、および [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)。

```
"placementConstraints": [
    {
        "expression": "attribute:ecs.instance-type =~ t2.*",
        "type": "memberOf"
    }
]
```

この例では、`memberOf` 制約を使用して、指定されたタスク配置方法に従って、`daemon-service` タスクグループ内のデーモンサービスタスクを持つインスタンスに、レプリカタスクを配置します。この制約により、デーモンサービスタスクはレプリカサービスタスクよりも前に EC2 インスタンスに配置されます。

`daemon-service` を デーモンサービスの名前に置き換えます。

```
"placementConstraints": [
    {
        "expression": "task:group == service:daemon-service",
        "type": "memberOf"
    }
]
```

この例では、`memberOf` 制約を使用して、指定されたタスク配置方法に従って、`databases` タスクグループ内の他のタスクとともにインスタンスにタスクを配置します。タスクグループの詳細については、「[Amazon ECS タスクをグループ化する](task-groups.md)」を参照してください。次のアクションを使用して指定できます。[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)、[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)、[RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html)、および [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)。

```
"placementConstraints": [
    {
        "expression": "task:group == databases",
        "type": "memberOf"
    }
]
```

`distinctInstance` 制約は、グループ内の各タスクを別のインスタンスに配置します。次のアクションを使用して指定できます。[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)、[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)、および [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)。

Amazon ECS は、タスク配置におけるタスクの目的のステータスを確認します。例えば、既存のタスクの目的のステータスが `STOPPED` の場合 (ただし、最後のステータスが目的のステータスではない場合)、`distinctInstance` 配置の制約事項にもかかわらず、新しい受信タスクを同じインスタンスに配置することができます。したがって、同じインスタンスで最後のステータスが `RUNNING` のタスクが 2 つ表示される場合があります。

```
"placementConstraints": [
    {
        "type": "distinctInstance"
    }
]
```