ECS Cluster Troubleshooting | Exam SAA-C03 | Amazon Certification

ECS Cluster Troubleshooting

Prev Question Next Question

Question

You have launched an ECS cluster with 5 EC2 instances with its task definitions.

However, ECS is not getting any status information back from the container agent in each ECS instance.

What could be the reason? (choose 3 options)

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D. E.

Answer: A, C, D.

Option A is correct.

The Amazon ECS container agent makes calls to the Amazon ECS API on your behalf.

Container instances that run the agent require an IAM policy and role for the service to know that the agent belongs to you.

Before you can launch container instances and register them into a cluster, you must create an IAM role for those container instances to use when they are launched.

This requirement applies to container instances launched with theAmazonECS-optimizedAMI provided by Amazon or with any other instances that you intend to run the agent on.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/instance_IAM_role.html

Option B is not correct.

Amazon ECS container instance has no password to use for SSH access; you use a key pair to securely log in to your instance.

You specify the name of the key pair when you launch your container instance, then provide the private key when you log in using SSH.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/get-set-up-for-amazon-ecs.html?shortFooter=true#create-a-key-pair

Option C is correct.

Security groups act as a firewall to ECS container instances.

If outbound rules are not allowing any traffic to ECS service endpoints, the container agent will not be able to report the status back to ECS.

For more information on Security Groups, refer to documentation here.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/get-set-up-for-amazon-ecs.html?shortFooter=true#create-a-base-security-group

Option D is correct.ECS supports interface VPC endpoints.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html https://aws.amazon.com/blogs/aws/aws-privatelink-update-vpc-endpoints-for-your-own-applications-services/

Option E is not correct.

T2.micro is supported for container instance.

"Version":
"statement":

"2012-10-17",

[

eregistercontainerInstance",
rPollendpoint™,

egistercontainerInstance",
tartTelemetrySession”,
ecs:Submit*",

ecr :GetAuthorizationToken”,

“ecr :BatchCheckLayerAvailability”,
‘ecr:GetDownloadurlForLayer”,
“ecr:BatchGetImage”,
“logs:CreateLogStream”,

“logs: PutLogEvents”

],
“Resource”: "*"
iG
]
t
Note
The ecs:CreateCluster line in the above policy is optional, provided that the cluster you intend to register
your container instance into already exists. If the cluster does not already exist, the agent must have
permission to create it, or you can create the cluster with the create-cluster command prior to launching
your container instance.
If you omit the ecs:CreateCluster line, the Amazon ECS container agent can not create clusters, including
the default cluster.
The ecs:Po11 lin the above policy is used to grant the agent perm n to connect with the Amazon ECS service to

report status and get commands.

The reason why ECS is not getting any status information back from the container agent in each ECS instance can be due to multiple factors.

A. IAM role used to run ECS instance does not have ecs:Poll action in its policy:

The ECS agent installed on each EC2 instance requires permission to poll the ECS service for task updates. If the IAM role used to launch the EC2 instances does not have the "ecs:Poll" action in its policy, the ECS agent will not be able to poll the ECS service for task updates. Therefore, this could be the reason why ECS is not getting any status information back from the container agent in each ECS instance.

B. Key-pair information is missing in ECS cluster:

Key-pair information is used to securely connect to EC2 instances from the ECS console. If key-pair information is missing in the ECS cluster, it can prevent the ECS console from communicating with the EC2 instances, including the ECS agent. However, this is unlikely to be the root cause of the problem as it would prevent the ECS console from connecting to the instances, but it would not affect the agent's ability to communicate with the ECS service.

C. ECSInstance security groups' outbound rules are not allowing traffic to ECS service endpoint:

If the outbound rules of the ECSInstance security group do not allow traffic to the ECS service endpoint, the ECS agent running on each EC2 instance will not be able to communicate with the ECS service. This could be the reason why ECS is not getting any status information back from the container agent in each ECS instance.

D. Interface VPC endpoint is not configured for ECS service:

The Interface VPC endpoint is used to provide secure and private communication between Amazon ECS and other resources in a VPC. If the Interface VPC endpoint is not configured for the ECS service, the ECS agent running on each EC2 instance will not be able to communicate with the ECS service. This could be the reason why ECS is not getting any status information back from the container agent in each ECS instance.

E. You are running ECS on t2.micro instance type which is not supported:

The t2.micro instance type is supported by ECS, so this is not a valid reason for the problem.

In summary, the three possible reasons why ECS is not getting any status information back from the container agent in each ECS instance are:

  • IAM role used to run ECS instance does not have ecs:Poll action in its policy
  • ECSInstance security groups' outbound rules are not allowing traffic to ECS service endpoint
  • Interface VPC endpoint is not configured for ECS service