

# Amazon ECS のサービスイベントメッセージ
<a name="service-event-messages-list"></a>

以下は、Amazon ECS コンソールで確認できる可能性があるサービスイベントメッセージの例です。

## サービス (*service-name*) が定常状態に達しました。
<a name="service-event-messages-steady"></a>

サービススケジューラは、サービスが正常で、必要な数のタスクが定常状態になったときに、`service (service-name) has reached a steady state.` サービスイベントを送信します。

サービススケジューラは定期的にステータスを報告するため、このメッセージを複数回受信する場合があります。

## サービス (*service-name*) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。
<a name="service-event-messages-1"></a>

サービススケジューラは、別のタスクを追加するために利用可能なリソースが見つからなかったときに、このイベントメッセージを送信します。以下に示しているのは、その考えられる原因です。

キャパシティープロバイダーを使用して、EC2 インスタンスを自動的にスケーリングします。詳細については、「[EC2 ワークロード用の Amazon ECS キャパシティプロバイダー](asg-capacity-providers.md)」を参照してください。  
キャパシティープロバイダーを使用する場合は、キャパシティープロバイダー戦略を渡すか、クラスターに関連付けられたデフォルトのキャパシティープロバイダー戦略があり、起動タイプとキャパシティープロバイダー戦略を入力として渡していないことを確認してください

クラスターにコンテナインスタンスが見つかなかった  
タスクを実行しようとしているクラスターにコンテナインスタンスが登録されていない場合は、このエラーが返されます。コンテナインスタンスをクラスターに追加する必要があります。詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。

ポートが足りない  
タスクで固定ホストポートマッピングを使用している場合 (タスクでウェブサーバーのホスト上のポート 80 を使用している場合など)、1 つのコンテナが一度に使用できるホストポートは 1 つのみであるため、タスクごとに 1 つ以上のコンテナインスタンスが必要です。コンテナインスタンスをクラスターに追加するか、タスクの必要数を減らす必要があります。

登録されたポートが多すぎる  
タスク配置に最も近いコンテナインスタンスは、コンテナインスタンスごとに許可される最大予約ホストポート数である 100 を超えることはできません。ホストポートの動的マッピングを使用すると、問題を解決できる場合があります。

ポートは既に使用中です  
このタスクのタスク定義は、選択されたコンテナインスタンスで既に実行されているタスクと同じポートをポートマッピングで使用します。サービスイベントメッセージは、以下のメッセージの一部としてコンテナインスタンス ID を本来選択していました。  

```
The closest matching container-instance is already using a port required by your task.
```

メモリが足りない  
タスク定義で 1,000 MiB のメモリを指定しており、クラスター内の各コンテナインスタンスのメモリが 1,024 MiB の場合、コンテナインスタンスごとにこのタスクのコピーを 1 つのみ実行できます。タスク定義でメモリを減らしてコンテナインスタンスごとに複数のタスクを起動できるようにするか、クラスターで起動するコンテナインスタンスを増やすことができます。  
リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。

CPU が足りない  
コンテナインスタンスには、CPU コアごとに 1,024 個の CPU ユニットがあります。タスク定義で 1,000 個の CPU ユニットを指定しており、クラスター内の各コンテナインスタンスの CPU ユニットが 1,024 個である場合、コンテナインスタンスごとにこのタスクのコピーを 1 つのみ実行できます。タスク定義で CPU ユニット数を減らしてコンテナインスタンスごとに複数のタスクを起動できるようにするか、クラスターで起動するコンテナインスタンスを増やすことができます。

十分な数の ENI アタッチメントポイントを利用できない  
`awsvpc` ネットワークモードを使用するタスクには、それぞれ独自の Elastic Network Interface (ENI) が提供されます。この ENI は、ENI をホストするコンテナインスタンスに添付されています。Amazon EC2 インスタンスは添付できる ENI の数には制限があり、クラスター内に利用可能なENI 容量があるコンテナインスタンスはありません。  
個別のコンテナインスタンスの ENI 制限は、以下の条件によって異なります。  
+ `awsvpcTrunking` アカウント設定を**オプトインしていない**場合、各コンテナインスタンスの ENI 制限は、インスタンスタイプによって異なります。詳細については、*Amazon EC2 ユーザーガイド*の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ `awsvpcTrunking` アカウント設定を**オプトインしている**が、オプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを**起動していない**場合、各コンテナインスタンスの ENI 制限はデフォルト値のままです。詳細については、*Amazon EC2 ユーザーガイド*の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ `awsvpcTrunking` アカウント設定を**オプトインしていて**、かつオプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを**起動している**場合、追加の ENI オプトインを利用できます。詳細については、「[Amazon ECS コンテナネットワークインターフェイスの増加でサポートされるインスタンス](eni-trunking-supported-instance-types.md)」を参照してください。
`awsvpcTrunking` アカウント設定のオプトインの詳細については、「[Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす](container-instance-eni.md)」を参照してください。  
クラスターにコンテナインスタンスを追加することで、利用できるネットワークアダプタの数を増やすことができます。

コンテナインスタンスに必須の属性がない  
一部のタスク定義パラメータでは、特定バージョンの Docker リモート API をコンテナインスタンスにインストールする必要があります。ロギングドライバーオプションなどのその他のパラメータでは、コンテナインスタンスに `ECS_AVAILABLE_LOGGING_DRIVERS` エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とするパラメータが含まれており、この要件を満たすことができるコンテナインスタンスがない場合、そのタスクは配置できません。  
このエラーの一般的な原因は、サービスが `awsvpc` ネットワークおよび EC2 を使用している場合です。指定したクラスターには、サービスの作成時に `awsvpcConfiguration` で指定されたものと同じサブネットにコンテナインスタンスが登録されていません。  
トラブルシューティングには、AWSSupport-TroubleshootECSContainerInstance ランブックを使用できます。ランブックでは、インスタンスのユーザーデータに正しいクラスター情報が含まれているかどうか、インスタンスプロファイルに必要なアクセス権限が含まれているかどうか、およびネットワーク設定の問題が確認されます。詳細については、*「AWS Systems Manager オートメーションランブックリファレンスユーザーガイド」*の「[AWSSupport-TroubleshootECSContainerInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshoot-ecs-container-instance.html)」を参照してください。  
特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「[Fargate での Amazon ECS タスク定義パラメータ](task_definition_parameters.md)」と「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。

## サービス (*service-name*) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。container-instance-id に最も近い *container-instance-id* には、使用可能な CPU ユニットがありません。
<a name="service-event-messages-2"></a>

タスク配置に最も一致するコンテナインスタンスに、タスク定義の要件を満たす十分な CPU ユニットがありません。タスク定義のタスクサイズとコンテナ定義の両方のパラメータで、CPU の要件を確認します。

## サービス (*service-name*) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。container-instance-id に最も近い *container-instance-id* で、エラー「AGENT」が発生しました。
<a name="service-event-messages-3"></a>

タスク配置に最も一致するコンテナインスタンス上の Amazon ECS コンテナエージェントが切断されています。コンテナインスタンスに SSH で接続できる場合は、エージェントログを調べることができます。詳細については、「[Amazon ECS コンテナエージェントのログ設定パラメータ](ecs-agent-versions.md#agent-logs)」を参照してください。エージェントがインスタンスで実行されていることも確認する必要があります。Amazon ECS に最適化された AMI を使用している場合、次のコマンドでエージェントを停止して再開始する試みができます。
+ Amazon ECS に最適化された Amazon Linux 2 AMI および Amazon ECS に最適化された Amazon Linux 2023 AMI の場合

  ```
  sudo systemctl restart ecs
  ```
+ Amazon ECS に最適化された Amazon Linux AMI の場合:

  ```
  sudo stop ecs && sudo start ecs
  ```

## サービス (*service–name*) (タスク *task–id*) (インスタンス *instance–id*) は、(reason インスタンスが、少なくとも UnhealthyThreshold 回のヘルスチェックに連続して失敗した) ため、(elb *elb elb–name*) で正常な状態になっていません
<a name="service-event-messages-4"></a>

このサービスはロードバランサーに登録されており、ロードバランサーのヘルスチェックは失敗しています。メッセージには、どの特定のタスクがヘルスチェックに失敗しているかを識別するのに役立つタスク ID が含まれています。詳細については、「[Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md)」を参照してください。

## サービス (*service-name*) は、一貫してタスクを正常に開始できません。
<a name="service-event-messages-5"></a>

このサービスには、連続して試行された後開始に失敗したタスクがあります。この時点で、サービススケジューラによって再試行間隔が段階的に増加し始めます。タスクの起動に失敗している理由をトラブルシューティングする必要があります。詳細については、「[Amazon ECS サービスのスロットルロジック](service-throttle-logic.md)」を参照してください。

更新されたタスク定義などでサービスが更新された後、サービススケジューラは正常な動作を再開します。

## サービス (*service-name*) オペレーションは抑制されています。後で再試行します。
<a name="service-event-messages-6"></a>

このサービスは、API スロットルの制限により、これ以上のタスクを起動できません。サービススケジューラが追加のタスクを起動できるようになると、再開します。

API レート制限クォータの引き上げをリクエストするには、[[AWS サポート Center (センター)](https://console.aws.amazon.com/support/home#/)]の ページを開き、必要に応じてサインインし、[**Create case (ケースを作成する)**] を選択します。**[Service Limit increase]** (サービス制限の緩和) を選択します。フォームに入力して送信します。

## サービス (*service-name*) は、サービスデプロイメント構成のため、デプロイメント中にタスクを停止または開始できませんでした。minimumHealthyPercent または maximumPercent の値を更新してから、もう一度試してください。
<a name="service-event-messages-7"></a>

このサービスは、デプロイメント構成であるため、サービスのデプロイメント中にタスクを停止または開始できません。デプロイ設定は、サービスの作成時に定義される `minimumHealthyPercent` 値と `maximumPercent` 値で構成されます。これらの値は既存のサービスでも更新できます。

`minimumHealthyPercent` は、デプロイ中またはコンテナインスタンスがドレインしているときに、サービスに対して実行する必要があるタスク数の下限を表します。これは、サービスに必要なタスク数に対するパーセンテージです。この値は切り上げられます。例えば、最小正常率が `50` で、必要なタスク数が 4 の場合、スケジューラは 2 つの新しいタスクを開始する前に既存のタスクを 2 つ停止できます。同様に、最小正常率が 75% で、必要なタスク数が 2 の場合、結果の値も 2 であるため、スケジューラはタスクを停止できません。

`maximumPercent` は、デプロイ中またはコンテナインスタンスがドレインしているときに、サービスに対して実行する必要があるタスク数の上限を表します。これは、サービスに必要なタスク数に対するパーセンテージです。この値は切り捨てられます。例えば、最大パーセンテージが `200` で、目的のタスク数が 4 の場合、スケジューラは既存のタスクを 4 つ停止する前に 4 つの新しいタスクを開始できます。同様に、最大比率が `125` で、必要なタスク数が 3 の場合、結果の値も 3 であるため、スケジューラはタスクを開始できません。

最小正常率または最大正常率を設定するときは、デプロイメントがトリガーされたときにスケジューラが 1 つ以上のタスクを停止または開始できることを確認する必要があります。

## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由: 同時に実行できるタスク数の上限に達しました
<a name="service-event-messages-8"></a>

エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「[Amazon ECS の Service Quotas](service-quotas.md)」を参照してください。クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) を参照してください。

## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由: 内部エラー。
<a name="service-event-messages-9"></a>

このエラーが表示される理由として考えられるものは、次のとおりです。

あるサブネットがサポートされていないアベイラビリティーゾーンにあるため、サービスはタスクを開始できません。

サポートされた Fargate リージョンおよびアベイラビリティーゾーンの情報については、[AWS Fargate で使用する Amazon ECS でサポートされているリージョン](AWS_Fargate-Regions.md) を参照してください。

サブネットのアベイラビリティーゾーンを確認する方法については、「*Amazon VPC ユーザーガイド*」の「[サブネットの確認](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#view-subnet)」を参照してください。

## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由:リクエストされた CPU 構成が制限を超えています。
<a name="service-event-messages-10"></a>

エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「[Amazon ECS の Service Quotas](service-quotas.md)」を参照してください。クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) を参照してください。

## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由:リクエストされたメモリ構成が制限を超えています。
<a name="service-event-messages-11"></a>

エラーの原因となったリソースに対して、クォータの引き上げをリクエストすることができます。詳細については、「[Amazon ECS の Service Quotas](service-quotas.md)」を参照してください。クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) を参照してください。

## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由: 同時に実行できる vCPU の上限数に達しました
<a name="service-event-messages-12"></a>

AWS Fargate は、タスク数ベースのクォータから vCPU ベースのクォータに移行しています。

Fargate の vCPU ベースのクォータの引き上げをリクエストできます。詳細については、「[Amazon ECS の Service Quotas](service-quotas.md)」を参照してください。Fargate クォータの引き上げをリクエストするには、「*Service Quotas ユーザーガイド*」の「[クォータ引き上げをリクエストする](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。

## タスクセット (*taskSet-ID*) がスケールインできなかったため、サービス (*service-name*) は定常状態に到達できませんでした。理由: 保護されているタスクの数が、必要なタスク数を超えています
<a name="service-event-messages-13"></a>

サービスに、必要なタスク数よりも多くの保護タスクがあります。次のいずれかを行うことができます。
+ 現在のタスクの保護が期限切れになり、タスクを終了できるようになるまでお待ちください。
+ どのタスクを停止できるかを判断し、`UpdateTaskProtection` API で `protectionEnabled` オプションを `false` に設定し、これらのタスクに対する保護を設定解除します。
+ サービスの必要なタスク数を増やして、保護されているタスクの数よりも多くします。

## サービス (*service-name*) が定常状態に到達できませんでした。理由:キャパシティープロバイダーにコンテナインスタンスが見つかりませんでした。
<a name="service-event-messages-14"></a>

サービススケジューラは、別のタスクを追加するために利用可能なリソースが見つからなかったときに、このイベントメッセージを送信します。以下に示しているのは、その考えられる原因です。

クラスターに関連付けられたキャパシティプロバイダーがありません  
クラスターにキャパシティプロバイダーが関連付けられていることを確認するには、`describe-services` を使用します。サービスのキャパシティプロバイダー戦略を更新できます。  
キャパシティプロバイダーに利用可能なキャパシティがあることを確認します。EC2 の場合は、コンテナインスタンスがタスク定義の要件を満たしていることを確認してください。

クラスターにコンテナインスタンスが見つかなかった  
タスクを実行しようとしているクラスターにコンテナインスタンスが登録されていない場合は、このエラーが返されます。コンテナインスタンスをクラスターに追加する必要があります。詳細については、「[Amazon ECS Linux コンテナインスタンスの起動](launch_container_instance.md)」を参照してください。

ポートが足りない  
タスクで固定ホストポートマッピングを使用している場合 (タスクでウェブサーバーのホスト上のポート 80 を使用している場合など)、タスクごとに 1 つ以上のコンテナインスタンスが必要です。一度に 1 つのホストポートを使用できるコンテナは 1 つだけです。コンテナインスタンスをクラスターに追加するか、タスクの必要数を減らす必要があります。

登録されたポートが多すぎる  
タスク配置に最も近いコンテナインスタンスは、コンテナインスタンスごとに許可される最大予約ホストポート数である 100 を超えることはできません。ホストポートの動的マッピングを使用すると、問題を解決できる場合があります。

ポートは既に使用中です  
このタスクのタスク定義は、選択されたコンテナインスタンスで既に実行されているタスクと同じポートをポートマッピングで使用します。サービスイベントメッセージは、以下のメッセージの一部としてコンテナインスタンス ID を本来選択していました。  

```
The closest matching container-instance is already using a port required by your task.
```

メモリが足りない  
タスク定義で 1,000 MiB のメモリを指定しており、クラスター内の各コンテナインスタンスのメモリが 1,024 MiB の場合、コンテナインスタンスごとにこのタスクのコピーを 1 つのみ実行できます。タスク定義でメモリを減らしてコンテナインスタンスごとに複数のタスクを起動できるようにするか、クラスターで起動するコンテナインスタンスを増やすことができます。  
特定のインスタンスタイプでタスクにできるだけ多くのメモリを提供してリソースの使用率を最大限に高めるには、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。

十分な数の ENI アタッチメントポイントを利用できない  
`awsvpc` ネットワークモードを使用するタスクには、それぞれ独自の Elastic Network Interface (ENI) が提供されます。この ENI は、ENI をホストするコンテナインスタンスに添付されています。Amazon EC2 インスタンスにアタッチできる ENI の数には制限があり、クラスターには利用可能な ENI 容量があるコンテナインスタンスはありません。  
個別のコンテナインスタンスの ENI 制限は、以下の条件によって異なります。  
+ `awsvpcTrunking` アカウント設定を**オプトインしていない**場合、各コンテナインスタンスの ENI 制限は、インスタンスタイプによって異なります。詳細については、*Amazon EC2 ユーザーガイド*の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ `awsvpcTrunking` アカウント設定を**オプトインしている**が、オプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを**起動していない**場合、各コンテナインスタンスの ENI 制限はデフォルト値のままです。詳細については、*Amazon EC2 ユーザーガイド*の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
+ `awsvpcTrunking` アカウント設定を**オプトインしていて**、かつオプトイン後にサポートされているインスタンスタイプを使用して新しいコンテナインスタンスを**起動している**場合、追加の ENI オプトインを利用できます。詳細については、「[Amazon ECS コンテナネットワークインターフェイスの増加でサポートされるインスタンス](eni-trunking-supported-instance-types.md)」を参照してください。
`awsvpcTrunking` アカウント設定のオプトインの詳細については、「[Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす](container-instance-eni.md)」を参照してください。  
クラスターにコンテナインスタンスを追加することで、利用できるネットワークアダプタの数を増やすことができます。

コンテナインスタンスに必須の属性がない  
一部のタスク定義パラメータでは、特定バージョンの Docker リモート API をコンテナインスタンスにインストールする必要があります。ロギングドライバーオプションなどのその他のパラメータでは、コンテナインスタンスに `ECS_AVAILABLE_LOGGING_DRIVERS` エージェント設定変数を使用して、それらのロギングドライバーを登録する必要があります。タスク定義に特定のコンテナインスタンス属性を必要とするパラメータが含まれており、この要件を満たすことができるコンテナインスタンスがない場合、そのタスクは配置できません。  
このエラーの一般的な原因は、サービスが `awsvpc` ネットワークモードを使うタスクを使用中で、EC2 と指定のクラスターに登録されたコンテナインスタンスが、サービス作成時に `awsvpcConfiguration` で指定された同じサブネット内に存在していないことです。  
トラブルシューティングには、AWSSupport-TroubleshootECSContainerInstance ランブックを使用できます。ランブックでは、インスタンスのユーザーデータに正しいクラスター情報が含まれているかどうか、インスタンスプロファイルに必要なアクセス権限が含まれているかどうか、およびネットワーク設定の問題が確認されます。詳細については、*「AWS Systems Manager オートメーションランブックリファレンスユーザーガイド」*の「[AWSSupport-TroubleshootECSContainerInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshoot-ecs-container-instance.html)」を参照してください。  
特定のタスク定義パラメータとエージェント設定変数に必要な属性の詳細については、「[Fargate での Amazon ECS タスク定義パラメータ](task_definition_parameters.md)」と「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。

## サービス [*service-name(サービス-名)*] がタスクを配置できませんでした。理由: 現在、容量は使用できません。後でもう一度試すか、別のアベイラビリティーゾーンで試してください。
<a name="service-event-messages-15"></a>

現在、サービスを実行できる容量がありません。

次のいずれかを行うことができます。
+ Fargate 容量または EC2 コンテナインスタンスが使用可能になるまでお待ちください。
+ サービスを再起動し、追加のサブネットを指定します。

## サービス (*service-name*) のデプロイに失敗しました:タスクを開始できませんでした。
<a name="service-event-messages-16"></a>

サービスのタスクが開始できませんでした。

停止タスクをデバッグする方法については、「[Amazon ECS の停止したタスクのエラーメッセージ](stopped-task-error-codes.md)」を参照してください。

## サービス (*service-name*) が、Amazon ECS エージェントの開始を待ってタイムアウトになりました。/var/log/ecs/ecs-agent.log でログを確認してください。"
<a name="service-event-messages-17"></a>

タスク配置に最も一致するコンテナインスタンス上の Amazon ECS コンテナエージェントが切断されています。コンテナインスタンスに SSH で接続できる場合は、エージェントログを調べることができます。詳細については、「[Amazon ECS コンテナエージェントのログ設定パラメータ](ecs-agent-versions.md#agent-logs)」を参照してください。エージェントがインスタンスで実行されていることも確認する必要があります。Amazon ECS に最適化された AMI を使用している場合、次のコマンドでエージェントを停止して再開始する試みができます。
+ Amazon ECS に最適化された Amazon Linux 2 AMI の場合

  ```
  sudo systemctl restart ecs
  ```
+ Amazon ECS に最適化された Amazon Linux AMI の場合:

  ```
  sudo stop ecs && sudo start ecs
  ```

## `TARGET GROUP IS NOT FOUND` が原因で、ターゲットグループ (*targetGroup-ARN*) 内のサービス (*service-name*) のタスクセット (*TaskSet-ID*) (task *task-id*) に異常があります。
<a name="service-event-messages-18"></a>

ターゲットグループが見つからなかったため、サービスのタスクセットはヘルスチェックに合格できません。メッセージには、どの特定のタスクがヘルスチェックに失敗しているかを識別するのに役立つタスク ID が含まれています。サービスを削除して再作成してください。対応する Amazon ECS サービスが既に削除されていない限り、Elastic Load Balancing のターゲットグループを削除しないでください。

## `TARGET IS NOT FOUND` が原因で、ターゲットグループ (*targetGroup-ARN*) 内のサービス (*service-name*) のタスクセット (*TaskSet-ID*) (task *task-id*) に異常があります。
<a name="service-event-messages-19"></a>

ターゲットが見つからなかったため、サービスのタスクセットはヘルスチェックに合格できません。メッセージには、どの特定のタスクがヘルスチェックに失敗しているかを識別するのに役立つタスク ID が含まれています。

## IAM アクセス許可ポリシーが正しく設定されていないか変更されているため、ECS はサービスを維持できなくなりました
<a name="service-event-messages-20"></a>

IAM アクセス許可ポリシーの設定ミスまたは変更により、サービスはタスクを維持できません。ECS サービスまたはタスクに関連付けられた IAM ロールに必要なアクセス許可がない可能性があります。

この問題を解決するには、IAM ロールに必要なアクセス許可を追加します。IAM アクセス許可ポリシーの管理について詳しくは、「*IAM ユーザーガイド*」の「[IAM ID のアクセス許可の追加および削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。‬‬

## IAM 信頼関係が正しく設定されていないか変更されているため、ECS はサービスを維持できなくなりました。
<a name="service-event-messages-21"></a>

設定ミスや IAM 信頼関係の変更により、サービスはタスクを維持できません。ECS サービスまたはタスクに関連付けられた IAM ロールの信頼ポリシーが正しくない可能性があります。

この問題を解決するには、タスク定義で使用されるロールの信頼ポリシーを設定します。信頼ポリシーの作成について詳しくは、「*IAM ユーザーガイド*」の「[Creating a role for a custom use case](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。

## サービス (*service–name*) は、デプロイ *deployment–id* のタスク *number* 件を起動できませんでした。
<a name="service-event-messages-22"></a>

このイベントメッセージは、デプロイワークフローが一部のタスクを正常に開始したが、容量不足エラーが原因でリクエストされたすべてのタスクを起動できなかった場合、サービススケジューラにより送信されます。これは通常、サーキットブレーカーが有効になっており、デプロイが失敗またはロールバックされる理由が可視化されている場合に発生します。

メッセージには、具体的な障害の原因 (CPU 不足、メモリ不足、その他のリソース制約など) が含まれています。これを確認することで、デプロイの問題を解決するために対処する必要があるリソースを理解できます。

詳細については、「[サービス (*service-name*) で、すべての要件を満たしたコンテナインスタンスがないため、タスクを配置できませんでした。](#service-event-messages-1)」を参照してください。

## サービス (*service–name*) は、タスクのプロビジョニング容量の制限を超えたため、クラスターにタスクを配置できませんでした。
<a name="service-event-messages-23"></a>

このイベントメッセージは、クラスターが同時に `PROVISIONING` 状態になることができる制限値 (タスク 500 件) に達した場合、サービススケジューラにより送信されます。これはクラスターレベルの制限です。サービス固有の問題ではありません。

通常このイベントは、タスクに事前プロビジョニング済みの容量制限がある状態で多数のタスクを実行するサービスを開始した場合や、複数のサービスを同時に開始したためにタスクが大量に作成される場合に発生します。

この問題を解決するには。
+ 既存のタスクのプロビジョニングが完了し、`RUNNING` 状態に移行するまで待機します。
+ プロビジョニングの制限に達しないよう、サービスのスケーリング速度を低下させることを検討してください。
+ クラスターのキャパシティプロバイダー設定を確認して、適切なリソースが使用可能になっていることを確認します。

Amazon ECS Service Quotas の詳細については、「*Amazon Web Services 全般リファレンス*」の「[Amazon Elastic Container Service のエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html)」を参照してください。