Memory hook: Separate the container image, application task, compute capacity and permissions before choosing an orchestrator.
Must remember
Understand what each resource represents
- A Docker image packages application layers; a container is a running instance. Rebuilding an image and replacing running containers are separate operations.
- ECR stores images and versions/tags. Immutable tags prevent accidental tag replacement; digests identify specific content. Lifecycle rules remove old registry artifacts, but stopping tasks does not clean the registry.
- ECS task definitions describe containers, CPU/memory, roles, networking and logging. A task is an execution; a service maintains desired running tasks and replaces failures.
- ECS on EC2 leaves host capacity/patching and placement choices to your design. Fargate removes server provisioning while still requiring task sizing, subnets, security groups and suitable network access.
- An empty cluster or registered task definition is not running compute. Conversely, an idle-looking service with desired tasks can keep billing.
Learn the three ECS role boundaries
- Task role: permissions used by application code, such as reading S3 or DynamoDB. Give each workload only its required data/API scope.
- Execution role: actions the ECS/Fargate agent performs for the task, such as pulling a private ECR image and delivering configured logs.
- EC2 instance role: host/agent permissions for EC2-backed capacity. Do not use the host role as a substitute for per-task application permissions.
- A successful image pull does not prove the application can reach its database. IAM, routing, DNS, security groups and the data service's policies are separate checks. ECS IAM roles
Match scaling and storage to the workload
- ALB routes HTTP(S) to tasks and evaluates target health. Tasks using
awsvpcnetworking register as IP targets, not host instance targets. - Service auto scaling changes desired task count. Capacity scaling adds/removes EC2 hosts where needed. More desired tasks do not help if the cluster lacks capacity to place them.
- Fargate manages underlying capacity, but tasks still need valid CPU/memory combinations, quotas and reachable image/log endpoints. A private subnet may need NAT or appropriate service endpoints.
- EventBridge/Scheduler can start standalone tasks for a schedule or event. Choose this for intermittent work rather than an always-running service; target execution permissions and
iam:PassRolematter. - EFS supplies shared persistent files outside disposable containers. Mount targets, access points, permissions and NFS security-group paths matter. Container-local writable storage is not a shared persistent database.
- Separate application scaling from downstream limits: scaling containers can overload a fixed-capacity database. Service scaling
Recognize Kubernetes and hybrid variants
- EKS provides a managed Kubernetes control plane. It fits requirements for Kubernetes APIs, controllers and ecosystem compatibility, rather than merely “we have a container image.”
- Compute options include managed node groups, self-managed EC2, supported Fargate profiles and current managed options such as EKS Auto Mode. Responsibility and feature support differ.
- CSI storage drivers connect Kubernetes storage to AWS services. EBS is AZ-scoped block storage; EFS supports shared file access. Check the chosen compute/storage combination rather than assuming every volume works with every node type.
- ECS Anywhere runs registered external machines under the regional ECS control plane; you still manage those machines and connectivity.
- EKS Anywhere is customer-managed Kubernetes for supported on-premises/edge environments, including disconnected designs. EKS Distro is the Kubernetes component distribution, not a hosted control plane. EKS Hybrid Nodes instead connect customer-managed nodes to an AWS-managed regional control plane. EKS deployment choices, ECS external instances
- Remove controller-managed load balancers and persistent storage appropriately before removing Kubernetes controllers/cluster infrastructure, or external resources may be orphaned.
- App Runner historically simplified managed web-container deployment; App2Container analyzed/containerized existing applications. They are restricted for new customers as documented in the availability record; recognize their purposes without treating them as new sandbox defaults.
Choose under exam pressure
| Requirement in the question | Best direction |
|---|---|
| Containers with minimal host management | Fargate |
| Kubernetes compatibility | EKS |
| Specialized EC2 hosts or detailed capacity control | EC2-backed orchestration |
| Container code needs S3 access | Task role |
| ECS must pull a private image | Execution role |
| Occasional scheduled container job | Event-driven standalone task |
| Existing external machines under ECS control | ECS Anywhere |
| Customer-managed disconnected Kubernetes | EKS Anywhere |
Traps
- Task count, host count and Kubernetes control-plane availability are separate decisions.
- Giving a role permissions does not create a route or open a security-group path.
- Container-local state can disappear during replacement; scaling makes that weakness more visible.
- A distribution of Kubernetes software is not the same product as an AWS-managed Kubernetes cluster.
Active recall
1. A task starts from private ECR but cannot read DynamoDB. Which role usually needs the application permission?
The task role. Image pulling belongs to the execution role, while the application uses its own credentials. Confirm networking and table policies as additional independent boundaries.
2. ECS desired count rises, but EC2-backed tasks remain pending. Why might service scaling be insufficient?
The service requested more tasks without sufficient host capacity or placement compatibility. Scale or correct the capacity layer as well as the application layer.
3. A nightly import runs for a short period. Why not keep an idle service running all day?
An event-driven standalone task matches the intermittent execution model and avoids idle desired tasks. The scheduler still needs permission to start the task and pass its roles.
4. Several replicas must see the same uploaded files. Is each container's writable layer a shared store?
No. Use appropriate shared persistent storage, such as EFS for an NFS workload, or change the application to use object storage. Local container storage belongs to that execution environment.
5. A disconnected data center needs Kubernetes lifecycle tooling. Why distinguish EKS Anywhere from EKS Hybrid Nodes?
EKS Anywhere provides customer-managed cluster operation suited to supported disconnected environments. Hybrid Nodes depend on an AWS-managed regional control plane and reliable connectivity.
Terraform anchor: Review task-definition revisions, desired task count and optional compute creation separately; a new definition does not itself run paid tasks.