6. Containers

Container services manage the lifecycle, orchestration, and storage of containerized applications and images.

Amazon ECR

Service Introduction: A fully managed Docker container registry that makes it easy for developers to store, manage, and deploy container images.

Common Usage: Centralizing image management; integrates with IAM for secure access and provides automated vulnerability scanning.

Project Examples:

• Storing versioned Docker images for a Jenkins CI/CD pipeline.
• Scanning production images for known software vulnerabilities before deployment.

Amazon ECS

Service Introduction: A highly scalable container orchestration service designed for deep integration with AWS-native services like IAM and ELB.

Common Usage: Best for customers seeking a simplified container management experience that prioritizes AWS integration. Task Role vs. Task Execution Role (exam-critical distinction):

• Task Role — The IAM role your application code inside the container assumes to call other AWS APIs (e.g., publish to SQS, read from S3). This is what you grant permissions to for app-level access.
• Task Execution Role — The IAM role ECS itself uses to pull the container image from ECR and write logs to CloudWatch — not used by your app code.

Exam Example (SAA-C03 pattern): "A developer is configuring an Amazon ECS task to access an Amazon SQS queue. Which IAM role should be used to grant the application code running inside the container the necessary permissions to call the SQS API?" Answer choices: Task Execution Role, Service-Linked Role, Task Role, Instance Profile Role.

• Correct Answer: Task Role — It's assumed by the containerized application itself, so it's the one that grants permissions for API calls the app code makes (like SQS).
• Why not Task Execution Role? — That role is used by the ECS agent to pull the image and write logs, not by your app code.
• Why not Service-Linked Role? — That's a predefined role tied to a specific AWS service (like ECS itself) for it to perform actions on your behalf, not for custom application permissions.
• Why not Instance Profile Role? — That's for EC2 instances to assume a role directly (e.g., the underlying EC2 host in an EC2 launch type), not for a specific task's application code — irrelevant here and doesn't even apply on Fargate, which has no EC2 instance to attach a profile to.

All four ECS-relevant IAM entities, side by side:

1. Task Role — Assumed by your application code inside the container. Grants app-level permissions (e.g., publish to SQS, read S3, write DynamoDB).
2. Task Execution Role — Assumed by the ECS agent/infrastructure, not your app code. Required for the container lifecycle itself: pulling the image from ECR and sending logs to CloudWatch.
3. AWSServiceRoleForECS (Service-Linked Role) — A predefined role AWS creates and manages so the ECS service itself can call other AWS services on your behalf, e.g. registering/deregistering EC2 instances with a Load Balancer or driving Auto Scaling activities. You don't author or edit its permissions, and Service-Linked Roles are typically not affected by Service Control Policies (SCPs).
4. IAM User — A permanent identity for a human or legacy app with long-term credentials (console password / access keys). Never use a User's access keys inside container app code — the app should get temporary, ephemeral credentials via AWS STS through a Task Role instead.

Role Type	Who/What Uses It?	Key Action Examples
Task Role	Application code in the container	Reading an S3 bucket; writing to DynamoDB.
Task Execution Role	The ECS Agent/Infrastructure	Pulling images from ECR; writing logs to CloudWatch.
Service-Linked Role	The ECS Service itself	Registering targets with a Load Balancer.
IAM User	A human or legacy app	Logging into the AWS Console; manual CLI tasks.

Fargate vs. EC2 Launch Type (exam-critical): Both run the same ECS task definitions — the difference is who manages the underlying compute.

• Fargate (serverless) — No EC2 instances to provision, patch, or scale; you define CPU/memory per task and AWS runs it on managed infrastructure. Correct answer whenever a question emphasizes "least operational overhead," "no server management," or unpredictable/spiky container workloads where you don't want to manage a cluster's capacity.
• EC2 launch type — You provision and manage the underlying EC2 instances (including their Auto Scaling, patching, and instance type selection) that host the tasks. Correct answer when a question needs fine-grained control over the instance type (e.g., GPU instances for ML inference, specific instance families for cost optimization via Reserved Instances/Spot), or higher container density per host to reduce cost at scale — Fargate's per-task pricing generally costs more than tightly-packed EC2 instances at high, steady utilization.

Project Examples:

• Running a microservices application using the Fargate launch type to avoid managing underlying servers.
• Managing a containerized batch-processing application on EC2 instances to use Spot pricing and GPU instance types.

Amazon ECS Anywhere

Service Introduction: An extension of ECS that allows you to manage containers on your own on-premises infrastructure using the AWS console.

Common Usage: Providing a consistent operational model for containers across hybrid environments.

Project Examples:

• Managing containerized applications on local servers for data residency.
• Standardizing container deployments across cloud and local data centers.

Amazon EKS

Service Introduction: A managed service that makes it easy to run Kubernetes on AWS without installing and operating your own Kubernetes control plane.

Common Usage: Best for customers requiring Kubernetes ecosystem compatibility, portability, and extensive open-source tool support.

Project Examples:

• Deploying a complex multi-tenant application using Helm and Kubernetes Operators.
• Migrating an on-premises Kubernetes cluster to a managed AWS environment.

Amazon EKS Anywhere

Service Introduction: A deployment option for EKS that allows you to create and operate Kubernetes clusters on customer-managed infrastructure.

Common Usage: Managing the full lifecycle of on-premises Kubernetes clusters using the EKS experience.

Project Examples:

• Running a local Kubernetes cluster for sensitive data processing.
• Maintaining a unified Kubernetes control plane across AWS and on-premises sites.

Amazon EKS Distro

Service Introduction: The same open-source Kubernetes distribution used by Amazon EKS, available for manual installation.

Common Usage: Ensuring that self-managed Kubernetes clusters on-premises are identical to the EKS version for testing and compatibility.

Project Examples:

• Standardizing Kubernetes versions for air-gapped environments.
• Building custom, EKS-compatible Kubernetes images for bare-metal servers.