Menu
Amazon EC2 Container Service
Developer Guide (API Version 2014-11-13)

Amazon ECS Troubleshooting

You may need to troubleshoot issues with your load balancers, tasks, services, or container instances. This chapter helps you find diagnostic information from the Amazon ECS container agent, the Docker daemon on the container instance, and the service event log in the Amazon ECS console.

Checking Stopped Tasks for Errors

If you have trouble starting a task (for example, you run the task and the task displays a PENDING status and then disappears) your task might be stopping because of an error. You can view errors like this in the Amazon ECS console by displaying the stopped task and inspecting it for error messages.

To check stopped tasks for errors

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the Clusters page, choose the cluster in which your stopped task resides.

  3. On the Cluster : clustername page, choose the Tasks tab to view your tasks.

  4. In the Desired task status table header, choose Stopped to view stopped tasks, and then choose the stopped task you want to inspect. The most recent stopped tasks are listed first.

  5. In the Details section, inspect the Stopped reason field to see the reason the task was stopped.

    
                        Stopped task reason

    Some possible reasons and their explanations are listed below:

    Task failed ELB health checks in (elb elb-name)

    The current task failed the ELB health check for the load balancer that is associated with the task's service. For more information, see Troubleshooting Service Load Balancers.

    Scaling activity initiated by (deployment deployment-id)

    When you reduce the desired count of a stable service, some tasks need to be stopped in order to reach the desired number. Tasks that are stopped by downscaling services have this stopped reason.

    Host EC2 (instance id) stopped/terminated

    If you stop or terminate a container instance with running tasks, then the tasks are given this stopped reason.

    Container instance deregistration forced by user

    If you force the deregistration of a container instance with running tasks, then the tasks are given this stopped reason.

    Essential container in task exited

    Containers marked as essential in task definitions cause a task to stop if they exit or die. When an essential container exiting is the cause of a stopped task, the Step 6 can provide more diagnostic information as to why the container stopped.

  6. If you have a container that has stopped, expand the container and inspect the Status reason row to see what caused the task state to change.

    
                            Stopped container error
    In the previous example, the container image name cannot be found. This can happen if you misspell the image name.

    If this inspection does not provide enough information, you can connect to the container instance with SSH and inspect the Docker container locally. For more information, see Inspect Docker Containers.

Service Event Messages

If you are troubleshooting a problem with a service, the first place you should check for diagnostic information is the service event log.

To check the service event log in the Amazon ECS console

  1. Open the Amazon ECS console at https://console.aws.amazon.com/ecs/.

  2. On the Clusters page, choose the cluster in which your service resides.

  3. On the Cluster : clustername page, choose the service that you would like to inspect.

  4. On the Service : servicename page, choose the Events tab.

    
                        Service event messages
  5. Examine the Message column for errors or other helpful information.

(service service-name) was unable to place a task because the resources could not be found.

In the above image, this service could not find the available resources to add another task. The possible causes for this are:

Not enough ports

If your task uses fixed host port mapping (for example, your task uses port 80 on the host for a web server), you must have at least one container instance per task, because only one container can use a single host port at a time. You should add container instances to your cluster or reduce your number of desired tasks.

Not enough memory

If your task definition specifies 1000 MiB of memory, and the container instances in your cluster each have 1024 MiB of memory, you can only run one copy of this task per container instance. You can experiment with less memory in your task definition so that you could launch more than one task per container instance, or launch more container instances into your cluster.

Not enough CPU

A container instance has 1,024 CPU units for every CPU core. If your task definition specifies 1,000 CPU units, and the container instances in your cluster each have 1,024 CPU units, you can only run one copy of this task per container instance. You can experiment with less CPU units in your task definition so that you could launch more than one task per container instance, or launch more container instances into your cluster.

Container instance missing required attribute

Some task definition parameters require a specific Docker remote API version to be installed on the container instance. Others, such as the logging driver options, require the container instances to register those log drivers with the ECS_AVAILABLE_LOGGING_DRIVERS agent configuration variable. If your task definition contains a parameter that requires a specific container instance attribute, and you do not have any available container instances that can satisfy this requirement, the task cannot be placed. For more information on which attributes are required for specific task definition parameters and agent configuration variables, see Task Definition Parameters and Amazon ECS Container Agent Configuration.

(service service-name) was unable to place a task because no container instance met all of its requirements. The closest matching container-instance container-instance-id encountered error "AGENT".

The Amazon ECS container agent on the closest matching container instance for task placement is disconnected. If you can connect to the container instance with SSH, you can examine the agent logs; for more information, see Amazon ECS Container Agent Log. You should also verify that the agent is running on the instance. If you are using the Amazon ECS-optimized AMI, you can try stopping and restarting the agent with the following commands:

Copy to clipboard
[ec2-user ~]$ sudo stop ecs ecs stop/waiting [ec2-user ~]$ sudo start ecs ecs start/running, process 26119

(service service-name) (instance instance-id) is unhealthy in (elb elb-name) due to (reason Instance has failed at least the UnhealthyThreshold number of health checks consecutively.)

This service is registered with a load balancer and the load balancer health checks are failing. For more information, see Troubleshooting Service Load Balancers.

Troubleshooting Service Load Balancers

Amazon ECS services can register tasks with an Elastic Load Balancing load balancer. Load balancer configuration errors are common causes for stopped tasks. If your stopped tasks were started by services that use a load balancer, consider the following possible causes.

Improper IAM permissions for the ecsServiceRole IAM role

The ecsServiceRole allows Amazon ECS services to register container instances with Elastic Load Balancing load balancers. You must have the proper permissions set for this role. For more information, see Amazon ECS Service Scheduler IAM Role.

Container instance security group

If your container is mapped to port 80 on your container instance, your container instance security group must allow inbound traffic on port 80 for the load balancer health checks to pass.

Elastic Load Balancing load balancer not configured for all Availability Zones

Your load balancer should be configured to use all of the Availability Zones in a region, or at least all of the Availability Zones in which your container instances reside. If a service uses a load balancer and starts a task on a container instance that resides in an Availability Zone that the load balancer is not configured to use, the task never passes the health check and it is killed.

Elastic Load Balancing load balancer health check misconfigured

The load balancer health check parameters can be overly restrictive or point to resources that do not exist. If a container instance is determined to be unhealthy, it is removed from the load balancer. Be sure to verify that the following parameters are configured correctly for your service load balancer.

Ping Port

The Ping Port value for a load balancer health check is the port on the container instances that the load balancer checks to determine if it is healthy. If this port is misconfigured, the load balancer will likely deregister your container instance from itself. This port should be configured to use the hostPort value for the container in your service's task definition that you are using with the health check.

Ping Path

This value is often set to index.html, but if your service does not respond to that request, then the health check fails. If your container does not have an index.html file, you can set this to / to target the base URL for the container instance.

Response Timeout

This is the amount of time that your container has to return a response to the health check ping. If this value is lower than the amount of time required for a response, the health check fails.

Health Check Interval

This is the amount of time between health check pings. The shorter your health check intervals are, the faster your container instance can reach the Unhealthy Threshold.

Unhealthy Threshold

This is the number of times your health check can fail before your container instance is considered unhealthy. If you have an unhealthy threshold of 2, and a health check interval of 30 seconds, then your task has 60 seconds to respond to the health check ping before it is assumed unhealthy. You can raise the unhealthy threshold or the health check interval to give your tasks more time to respond.

Unable to update the service servicename: Load balancer container name or port changed in task definition

If your service uses a load balancer, the load balancer configuration defined for your service when it was created cannot be changed. If you update the task definition for the service, the container name and container port that were specified when the service was created must remain in the task definition.

To change the load balancer name, the container name, or the container port associated with a service load balancer configuration, you must create a new service.

Enabling Docker Debug Output

If you are having trouble with Docker containers or images, you can enable debug mode on your Docker daemon. Enabling debugging provides more verbose output from the daemon and you can use this information to find out more about why your containers or images are having issues.

Enabling Docker debug mode can be especially useful in retrieving error messages that are sent from container registries, such as Amazon ECR, and, in many circumstances, enabling debug mode is the only way to see these error messages.

To enable debug mode on your Docker daemon

  1. Connect to your container instance. For more information, see Connect to Your Container Instance.

  2. Open the Docker options file with a text editor, such as vi.

    • For Amazon Linux, Red Hat Enterprise Server, and CentOS, the Docker options file is at /etc/sysconfig/docker.

    • For Ubuntu and Debian, the Docker options file is at /etc/default/docker.

  3. Find the Docker options statement and add the -D option to the string, inside the quotes.

    Note

    If the Docker options statement begins with a #, you need to remove that character to uncomment the statement and enable the options.

    • For Amazon Linux, Red Hat Enterprise Server, and CentOS, the Docker options statement is called OPTIONS. For example:

      Copy to clipboard
      # Additional startup options for the Docker daemon, for example: # OPTIONS="--ip-forward=true --iptables=true" # By default we limit the number of open files per container OPTIONS="-D --default-ulimit nofile=1024:4096"

    • For Ubuntu and Debian, the Docker options statement is called DOCKER_OPTS. For example:

      Copy to clipboard
      # Use DOCKER_OPTS to modify the daemon startup options. DOCKER_OPTS="-D --dns 8.8.8.8 --dns 8.8.4.4"

  4. Save the file and exit your text editor.

  5. Restart the Docker daemon.

    Copy to clipboard
    $ sudo service docker restart Stopping docker: [ OK ] Starting docker: . [ OK ]

Your Docker logs should now show more verbose output. For example:

Copy to clipboard
time="2015-12-30T21:48:21.907640838Z" level=debug msg="Unexpected response from server: \"{\\\"errors\\\":[{\\\"code\\\":\\\"DENIED\\\",\\\"message\\\":\\\"User: arn:aws:sts::1111:assumed-role/ecrReadOnly/i-abcdefg is not authorized to perform: ecr:InitiateLayerUpload on resource: arn:aws:ecr:us-east-1:1111:repository/nginx_test\\\"}]}\\n\" http.Header{\"Connection\":[]string{\"keep-alive\"}, \"Content-Type\":[]string{\"application/json; charset=utf-8\"}, \"Date\":[]string{\"Wed, 30 Dec 2015 21:48:21 GMT\"}, \"Docker-Distribution-Api-Version\":[]string{\"registry/2.0\"}, \"Content-Length\":[]string{\"235\"}}"

Amazon ECS Log File Locations

Amazon ECS stores logs in the /var/log/ecs folder of your container instances. There are logs available from the Amazon ECS container agent and the ecs-init service that controls the state of the agent (start/stop) on the container instance. You can view these log files by connecting to a container instance using SSH. For more information, see Connect to Your Container Instance.

Note

If you are unsure how to collect all of the various logs on your container instances, you can use the Amazon ECS logs collector. For more information, see Amazon ECS Logs Collector.

Amazon ECS Container Agent Log

The Amazon ECS container agent stores logs at /var/log/ecs/ecs-agent.log.timestamp.

Note

You can increase the verbosity of the container agent logs by setting ECS_LOGLEVEL=debug and restarting the container agent. For more information, see Amazon ECS Container Agent Configuration.

Copy to clipboard
[ec2-user ~]$ cat /var/log/ecs/ecs-agent.log.2016-08-15-15 2016-08-15T15:54:41Z [INFO] Starting Agent: Amazon ECS Agent - v1.12.0 (895f3c1) 2016-08-15T15:54:41Z [INFO] Loading configuration 2016-08-15T15:54:41Z [WARN] Invalid value for task cleanup duration, will be overridden to 3h0m0s, parsed value 0, minimum threshold 1m0s 2016-08-15T15:54:41Z [INFO] Checkpointing is enabled. Attempting to load state 2016-08-15T15:54:41Z [INFO] Loading state! module="statemanager" 2016-08-15T15:54:41Z [INFO] Detected Docker versions [1.17 1.18 1.19 1.20 1.21 1.22] 2016-08-15T15:54:41Z [INFO] Registering Instance with ECS 2016-08-15T15:54:41Z [INFO] Registered! module="api client"

Amazon ECS ecs-init Log

The ecs-init process stores logs at /var/log/ecs/ecs-init.log.timestamp.

Copy to clipboard
[ec2-user ~]$ cat /var/log/ecs/ecs-init.log.2015-04-22-20 2015-04-22T20:51:45Z [INFO] pre-start 2015-04-22T20:51:45Z [INFO] Loading Amazon EC2 Container Service Agent into Docker 2015-04-22T20:51:46Z [INFO] start 2015-04-22T20:51:46Z [INFO] No existing agent container to remove. 2015-04-22T20:51:46Z [INFO] Starting Amazon EC2 Container Service Agent

IAM Roles for Tasks Credential Audit Log

When the IAM roles for tasks credential provider is used to provide credentials to tasks, these requests are logged in /var/log/ecs/audit.log.YYYY-MM-DD-HH. The log entry format is as follows:

  • Timestamp

  • HTTP response code

  • IP address and port number of request origin

  • Relative URI of the credential provider

  • The user agent that made the request

  • The task ARN that the requesting container belongs to

  • The GetCredentials API name and version number

  • The Amazon ECS cluster name that the container instance is registered to

  • The container instance ARN

An example log entry is shown below:
Copy to clipboard
[ec2-user ~]$ cat /var/log/ecs/audit.log.2016-07-13-16 2016-07-13T16:11:53Z 200 172.17.0.5:52444 "/v1/credentials" "python-requests/2.7.0 CPython/2.7.6 Linux/4.4.14-24.50.amzn1.x86_64" TASK_ARN GetCredentials 1 CLUSTER_NAME CONTAINER_INSTANCE_ARN

Amazon ECS Logs Collector

If you are unsure how to collect all of the various logs on your container instances, you can use the Amazon ECS logs collector, which is available on GitHub. The script collects general operating system logs as well as Docker and Amazon ECS container agent logs, which can be helpful for troubleshooting AWS Support cases, and then it compresses and archives the collected information into a single file that can easily be shared for diagnostic purposes. It also supports enabling debug mode for the Docker daemon and the Amazon ECS container agent on Amazon Linux variants, such as the Amazon ECS-optimized AMI. Currently, the Amazon ECS logs collector supports the following operating systems:

  • Amazon Linux

  • Red Hat Enterprise Linux 7

  • Debian 8

Note

The source code for the Amazon ECS logs collector is available on GitHub. We encourage you to submit pull requests for changes that you would like to have included. However, Amazon Web Services does not currently provide support for running modified copies of this software.

To download and run the Amazon ECS logs collector

  1. Connect to your container instance. For more information, see Connect to Your Container Instance.

  2. Download the Amazon ECS logs collector script.

    Copy to clipboard
    [ec2-user ~]$ curl -O https://raw.githubusercontent.com/awslabs/ecs-logs-collector/master/ecs-logs-collector.sh

  3. Run the script to collect the logs and create the archive.

    Note

    To enable debug mode for the Docker daemon and the Amazon ECS container agent, add the --mode=debug option to the command below.

    Copy to clipboard
    [ec2-user ~]$ sudo bash ./ecs-logs-collector.sh

After you have run the script, you can examine the collected logs in the collect folder that the script created. The collect.tgz file is a compressed archive of all of the logs, which you can share with AWS Support for diagnostic help.

Agent Introspection Diagnostics

The Amazon ECS agent introspection API can provide helpful diagnostic information. For example, you can use the agent introspection API to get the Docker ID for a container in your task. You can use the agent introspection API by connecting to a container instance using SSH. For more information, see Connect to Your Container Instance.

The below example shows two tasks, one that is currently running and one that was stopped.

Note

The command below is piped through the python -mjson.tool for greater readability.

Copy to clipboard
[ec2-user ~]$ curl http://localhost:51678/v1/tasks | python -mjson.tool % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1095 100 1095 0 0 117k 0 --:--:-- --:--:-- --:--:-- 133k { "Tasks": [ { "Arn": "arn:aws:ecs:us-west-2:aws_account_id:task/090eff9b-1ce3-4db6-848a-a8d14064fd24", "Containers": [ { "DockerId": "189a8ff4b5f04affe40e5160a5ffadca395136eb5faf4950c57963c06f82c76d", "DockerName": "ecs-console-sample-app-static-6-simple-app-86caf9bcabe3e9c61600", "Name": "simple-app" }, { "DockerId": "f7f1f8a7a245c5da83aa92729bd28c6bcb004d1f6a35409e4207e1d34030e966", "DockerName": "ecs-console-sample-app-static-6-busybox-ce83ce978a87a890ab01", "Name": "busybox" } ], "Family": "console-sample-app-static", "KnownStatus": "STOPPED", "Version": "6" }, { "Arn": "arn:aws:ecs:us-west-2:aws_account_id:task/1810e302-eaea-4da9-a638-097bea534740", "Containers": [ { "DockerId": "dc7240fe892ab233dbbcee5044d95e1456c120dba9a6b56ec513da45c38e3aeb", "DockerName": "ecs-console-sample-app-static-6-simple-app-f0e5859699a7aecfb101", "Name": "simple-app" }, { "DockerId": "096d685fb85a1ff3e021c8254672ab8497e3c13986b9cf005cbae9460b7b901e", "DockerName": "ecs-console-sample-app-static-6-busybox-92e4b8d0ecd0cce69a01", "Name": "busybox" } ], "DesiredStatus": "RUNNING", "Family": "console-sample-app-static", "KnownStatus": "RUNNING", "Version": "6" } ] }
In the above example, the stopped task (090eff9b-1ce3-4db6-848a-a8d14064fd24) has two containers. You can use docker inspect container-ID to view detailed information on each container. For more information, see Amazon ECS Container Agent Introspection.

Docker Diagnostics

Docker provides several diagnostic tools that can help you troubleshoot problems with your containers and tasks. For more information about all of the available Docker command line utilities, go to the Docker Command Line topic in the Docker documentation. You can access the Docker command line utilities by connecting to a container instance using SSH. For more information, see Connect to Your Container Instance.

The exit codes that Docker containers report can also provide some diagnostic information (for example, exit code 137 means that the container received a SIGKILL signal). For more information, see Exit Status in the Docker documentation.

List Docker Containers

You can use the docker ps command on your container instance to list the running containers. In the below example, only the Amazon ECS container agent is running. For more information, go to docker ps in the Docker documentation.

Copy to clipboard
[ec2-user ~]$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES cee0d6986de0 amazon/amazon-ecs-agent:latest "/agent" 22 hours ago Up 22 hours 127.0.0.1:51678->51678/tcp ecs-agent
You can use the docker ps -a command to see all containers (even stopped or killed containers). This is helpful for listing containers that are unexpectedly stopping. In the following example, container f7f1f8a7a245 exited 9 seconds ago, so it would not show up in a docker ps output without the -a flag.
Copy to clipboard
[ec2-user ~]$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES db4d48e411b1 amazon/ecs-emptyvolume-base:autogenerated "not-applicable" 19 seconds ago ecs-console-sample-app-static-6-internalecs-emptyvolume-source-c09288a6b0cba8a53700 f7f1f8a7a245 busybox:buildroot-2014.02 "\"sh -c '/bin/sh -c 22 hours ago Exited (137) 9 seconds ago ecs-console-sample-app-static-6-busybox-ce83ce978a87a890ab01 189a8ff4b5f0 httpd:2 "httpd-foreground" 22 hours ago Exited (137) 40 seconds ago ecs-console-sample-app-static-6-simple-app-86caf9bcabe3e9c61600 0c7dca9321e3 amazon/ecs-emptyvolume-base:autogenerated "not-applicable" 22 hours ago ecs-console-sample-app-static-6-internalecs-emptyvolume-source-90fefaa68498a8a80700 cee0d6986de0 amazon/amazon-ecs-agent:latest "/agent" 22 hours ago Up 22 hours 127.0.0.1:51678->51678/tcp ecs-agent

View Docker Logs

You can view the STDOUT and STDERR streams for a container with the docker logs command. In this example, the logs are displayed for the dc7240fe892a container and piped through the head command for brevity. For more information, go to docker logs in the Docker documentation.

Copy to clipboard
[ec2-user ~]$ docker logs dc7240fe892a | head AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.11. Set the 'ServerName' directive globally to suppress this message AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.11. Set the 'ServerName' directive globally to suppress this message [Thu Apr 23 19:48:36.956682 2015] [mpm_event:notice] [pid 1:tid 140327115417472] AH00489: Apache/2.4.12 (Unix) configured -- resuming normal operations [Thu Apr 23 19:48:36.956827 2015] [core:notice] [pid 1:tid 140327115417472] AH00094: Command line: 'httpd -D FOREGROUND' 10.0.1.86 - - [23/Apr/2015:19:48:59 +0000] "GET / HTTP/1.1" 200 348 10.0.0.154 - - [23/Apr/2015:19:48:59 +0000] "GET / HTTP/1.1" 200 348 10.0.1.86 - - [23/Apr/2015:19:49:28 +0000] "GET / HTTP/1.1" 200 348 10.0.0.154 - - [23/Apr/2015:19:49:29 +0000] "GET / HTTP/1.1" 200 348 10.0.1.86 - - [23/Apr/2015:19:49:50 +0000] "-" 408 - 10.0.0.154 - - [23/Apr/2015:19:49:50 +0000] "-" 408 - 10.0.1.86 - - [23/Apr/2015:19:49:58 +0000] "GET / HTTP/1.1" 200 348 10.0.0.154 - - [23/Apr/2015:19:49:59 +0000] "GET / HTTP/1.1" 200 348 10.0.1.86 - - [23/Apr/2015:19:50:28 +0000] "GET / HTTP/1.1" 200 348 10.0.0.154 - - [23/Apr/2015:19:50:29 +0000] "GET / HTTP/1.1" 200 348 time="2015-04-23T20:11:20Z" level="fatal" msg="write /dev/stdout: broken pipe"

Inspect Docker Containers

If you have the Docker ID of a container, you can inspect it with the docker inspect command. Inspecting containers provides the most detailed view of the environment in which a container was launched. For more information, go to docker inspect in the Docker documentation.

Copy to clipboard
[ec2-user ~]$ docker inspect dc7240fe892a [{ "AppArmorProfile": "", "Args": [], "Config": { "AttachStderr": false, "AttachStdin": false, "AttachStdout": false, "Cmd": [ "httpd-foreground" ], "CpuShares": 10, "Cpuset": "", "Domainname": "", "Entrypoint": null, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/apache2/bin", "HTTPD_PREFIX=/usr/local/apache2", "HTTPD_VERSION=2.4.12", "HTTPD_BZ2_URL=https://www.apache.org/dist/httpd/httpd-2.4.12.tar.bz2" ], "ExposedPorts": { "80/tcp": {} }, "Hostname": "dc7240fe892a", ...

API failures Error Messages

In some cases, an API call that you have triggered through the Amazon ECS console or the AWS CLI exits with a failures error message. The following possible API failures error messages are explained below for each API call. The failures occur on a particular resource, and the resource in parentheses is the resource associated with the failure.

Many resources are region-specific, so make sure the console is set to the correct region for your resources, or that your AWS CLI commands are being sent to the correct region with the --region region option.

  • DescribeClusters

    MISSING (cluster ID)

    Your cluster was not found. The cluster name may not have been spelled correctly or the wrong region may be specified.

  • DescribeInstances

    MISSING (container instance ID)

    The container instance you are attempting to describe does not exist. Perhaps the wrong cluster or region has been specified, or the container instance ARN or ID is misspelled.

  • DescribeServices

    MISSING (service ID)

    The service you are attempting to describe does not exist. Perhaps the wrong cluster or region has been specified, or the container instance ARN or ID is misspelled.

  • DescribeTasks

    MISSING (task ID)

    The task you are trying to describe does not exist. Perhaps the wrong cluster or region has been specified, or the task ARN or ID is misspelled.

  • RunTask or StartTask

    RESOURCE:* (container instance ID)

    The resource or resources requested by the task are unavailable on the given container instance. If the resource is CPU or memory, you may need to add container instances to your cluster.

    AGENT (container instance ID)

    The container instance that you attempted to launch a task onto has an agent which is currently disconnected. In order to prevent extended wait times for task placement, the request was rejected.

    ATTRIBUTE (container instance ID)

    Your task definition contains a parameter that requires a specific container instance attribute that is not available on your container instances. For more information on which attributes are required for specific task definition parameters and agent configuration variables, see Task Definition Parameters and Amazon ECS Container Agent Configuration.

  • StartTask

    MISSING (container instance ID)

    The container instance you attempted to launch the task onto does not exist. Perhaps the wrong cluster or region has been specified, or the container instance ARN or ID is misspelled.

    INACTIVE (container instance ID)

    The container instance that you attempted to launch a task onto was previously deregistered with Amazon ECS and cannot be used.