Cargando...
Cargando...
Run, scale, and secure containerized workloads on AWS without managing orchestration infrastructure
Amazon Elastic Container Service (ECS) is a fully managed container orchestration service that lets you deploy, manage, and scale Docker containers on AWS. It integrates natively with AWS services like IAM, VPC, ALB, CloudWatch, and ECR, and supports two launch modes: EC2 (you manage the instances) and Fargate (serverless, AWS manages the infrastructure). ECS is AWS's proprietary orchestration platform — not Kubernetes — making it distinct from EKS in architecture, API, and migration path.
Orchestrate Docker containers at scale on AWS with deep native service integrations, without operating a control plane
Use When
Avoid When
Fargate (serverless) launch type
AWS manages EC2 infrastructure; you define CPU/memory at task level and pay per task second
EC2 launch type
You manage EC2 instances running the ECS agent; allows GPU instances, custom AMIs, and higher resource limits
ECS Anywhere (on-premises)
Run ECS tasks on your own servers or VMs outside AWS using the ECS agent and SSM — requires outbound internet or VPC connectivity to ECS control plane
Task IAM Roles (fine-grained permissions)
Each task can have its own IAM role — critical for least-privilege security; do NOT use EC2 instance profile for task-level permissions
Service Auto Scaling
Integrates with Application Auto Scaling; supports target tracking, step scaling, and scheduled scaling
Blue/Green Deployments via CodeDeploy
Shifts traffic between blue (current) and green (new) task sets using ALB weighted target groups; enables instant rollback
Rolling Updates
Default ECS deployment strategy; minimumHealthyPercent and maximumPercent control rolling behavior
Service Discovery (Cloud Map)
Automatic DNS registration for ECS tasks via AWS Cloud Map; enables microservice-to-microservice communication
ECS Service Connect
Newer alternative to Cloud Map for service-to-service communication with built-in observability metrics and traffic management
Container Insights (CloudWatch)
Collects, aggregates, and summarizes metrics and logs from containerized applications; must be explicitly enabled per cluster
Secrets Manager / SSM Parameter Store integration
Inject secrets as environment variables or mounted files at task launch time without baking secrets into images
EFS (Elastic File System) integration
Persistent shared storage across tasks; works with both EC2 and Fargate launch types — critical for stateful containers
GPU support
Only available on EC2 launch type with GPU-enabled instance types (p3, g4dn, etc.) — Fargate does NOT support GPUs
Spot Instances (EC2 launch type)
Use Spot capacity providers for cost savings; combine with On-Demand capacity providers for resilience
Fargate Spot
Interruptible Fargate capacity at up to 70% discount; suitable for fault-tolerant batch workloads
Task placement strategies (EC2 only)
Spread, binpack, random — control how tasks are placed across EC2 instances and Availability Zones
Capacity Providers
Abstract the underlying infrastructure; define managed scaling for Auto Scaling Groups or use Fargate/Fargate Spot capacity providers
ECS Exec (interactive shell)
Run commands inside running containers via SSM Session Manager without SSH; requires task role with SSM permissions
Windows containers
Supported on EC2 launch type only; Fargate supports Windows containers in select regions
IPv6 support
Supported in dual-stack VPC configurations
Graviton (ARM) support
Fargate supports Graviton2 (arm64) for up to 20% cost savings on compatible workloads
Serverless Container Execution
high freqUse Fargate as the ECS launch type to eliminate EC2 instance management. AWS provisions, scales, and patches the underlying compute. Ideal for variable workloads, microservices, and teams without infrastructure expertise. Task-level CPU/memory must match valid Fargate combinations.
Private Container Registry Integration
high freqStore Docker images in ECR and reference them in ECS task definitions. ECR provides image scanning, lifecycle policies, and cross-account access. The ECS task execution role must have ecr:GetAuthorizationToken and ecr:BatchGetImage permissions. ECR is the recommended registry for ECS workloads.
Dynamic Port Mapping with ALB
high freqALB integrates with ECS service to dynamically register/deregister tasks as target group members. Supports path-based and host-based routing to different ECS services. Essential for blue/green deployments. ALB security group must allow traffic from the ECS task security group.
Blue/Green Container Deployment
high freqCodeDeploy manages traffic shifting between ECS task sets using ALB weighted target groups. Supports canary, linear, and all-at-once strategies. Enables automatic rollback on CloudWatch alarm breach. Requires an appspec.yaml file and CodeDeploy ECS deployment group.
Container Observability and Auto Scaling Triggers
high freqCloudWatch collects ECS service metrics (CPUUtilization, MemoryUtilization) and Container Insights metrics. Application Auto Scaling uses CloudWatch alarms to scale ECS service desired count. Custom metrics from containers can also trigger scaling via CloudWatch.
Task-Level IAM Roles (Least Privilege)
high freqAssign a unique IAM role to each ECS task definition via taskRoleArn. Credentials are delivered via the ECS credential provider (169.254.170.2 metadata endpoint) — NOT the EC2 instance metadata. This is the correct way to grant AWS API permissions to containers without sharing instance-level credentials.
Persistent Shared Storage for Stateful Containers
high freqMount EFS file systems into ECS tasks for persistent, shared storage across multiple tasks and AZs. Supported on both EC2 and Fargate. Use cases include CMS, shared configuration, ML model storage. EFS access points provide per-task directory isolation with POSIX permissions.
Secure Secret Injection at Task Launch
high freqReference Secrets Manager ARNs or SSM Parameter Store paths in ECS task definitions. Secrets are injected as environment variables or mounted files when the task starts. The task execution role needs secretsmanager:GetSecretValue permission. Avoids hardcoding credentials in images or environment variables.
Queue-Based Batch Processing with Auto Scaling
high freqECS tasks consume messages from SQS queues. Application Auto Scaling scales ECS service desired count based on SQS ApproximateNumberOfMessagesVisible metric via CloudWatch. Combine with Fargate Spot for cost-optimized batch processing. EventBridge Pipes can also trigger ECS tasks from SQS.
Hybrid Serverless Architecture
high freqLambda handles lightweight event-driven functions while ECS handles longer-running, memory-intensive, or containerized workloads. Lambda can invoke ECS RunTask API to launch containers on-demand. Use Step Functions to orchestrate both Lambda and ECS tasks in a workflow.
Parallel Container Platforms (Choose One)
high freqECS and EKS are NOT interchangeable. ECS uses AWS-proprietary task definitions and service APIs. EKS uses standard Kubernetes manifests, kubectl, and Helm. Migrating FROM Kubernetes to ECS requires complete rewriting of deployment configurations. Choose EKS when Kubernetes portability or ecosystem matters.
Service Discovery for Microservices
high freqECS automatically registers task IPs/ports in Cloud Map DNS namespaces when service discovery is enabled. Other services resolve container endpoints via DNS (e.g., myservice.local). Supports both DNS-based and API-based discovery. ECS Service Connect is the newer, preferred approach with built-in observability.
EC2 Capacity Provider with Managed Scaling
high freqAttach an Auto Scaling Group to an ECS capacity provider with managed scaling enabled. ECS automatically scales the ASG based on task demand, targeting a specific capacity utilization percentage. Eliminates manual EC2 scaling and ensures tasks always have available compute.
awsvpc Network Mode for Task-Level Security Groups
high freqWith awsvpc network mode, each ECS task gets its own ENI and private IP address. Security groups are applied at the task level (not instance level), enabling fine-grained network isolation between microservices. Required for Fargate; recommended for EC2. Enables VPC Flow Logs per task.
ECS and EKS are NOT interchangeable. ECS uses AWS-proprietary task definitions; EKS uses Kubernetes-native manifests. A question asking how to 'lift and shift an existing Kubernetes application' always points to EKS, never ECS. If the word 'Kubernetes' appears in the scenario, the answer is EKS.
Task IAM Role (taskRoleArn) vs Task Execution Role (executionRoleArn) — know the difference cold: Task Role = permissions your application code needs (S3, DynamoDB, etc.). Execution Role = permissions ECS needs to launch your task (pull ECR image, write CloudWatch logs, fetch secrets). Both can exist on the same task definition.
Fargate does NOT support GPU instances, Windows containers in all regions, or placement strategies. If an exam scenario requires GPU compute in containers, the answer is EC2 launch type with a GPU instance type (p3, g4dn), not Fargate.
awsvpc network mode gives each task its own ENI and security group — this is the ONLY network mode supported by Fargate and the recommended mode for EC2. In exam scenarios about isolating database-tier containers or applying task-level firewall rules, awsvpc is the answer.
ECS Anywhere lets you run ECS tasks on on-premises servers. The registered instances appear in your ECS cluster but are outside AWS. This is the answer for 'extend ECS to on-premises' or 'hybrid container orchestration' scenarios — NOT EKS Anywhere (which is Kubernetes-based).
ECS ≠ EKS. 'Kubernetes migration' always means EKS. ECS uses AWS-proprietary APIs and task definitions that are incompatible with Kubernetes manifests, Helm, and kubectl.
Task IAM Role (taskRoleArn) = permissions your app code needs. Task Execution Role (executionRoleArn) = permissions ECS needs to LAUNCH the task (pull image, fetch secrets, write logs). Both can and often should exist on the same task definition.
Fargate = no GPU, no placement strategies, no instance management. EC2 launch type = GPU support, custom placement strategies, and you manage/pay for instances even when idle. Match the launch type to the workload requirements.
For Blue/Green deployments on ECS, the answer is ECS + CodeDeploy (not just rolling updates). CodeDeploy creates a new task set (green), shifts ALB traffic, and keeps the old task set (blue) available for rollback. Rolling updates replace tasks in-place and don't support instant traffic rollback.
ECS Service Auto Scaling scales the NUMBER OF TASKS (desired count). It does NOT scale EC2 instances. To scale EC2 instances on EC2 launch type, you need a separate Capacity Provider with managed scaling or an Auto Scaling Group policy. Confusing these two layers is a common exam trap.
Secrets in ECS task definitions: reference Secrets Manager ARNs or SSM Parameter Store paths in the 'secrets' field of container definitions. The EXECUTION ROLE (not task role) needs permission to read the secret. Secrets are injected at task launch — not at image build time.
Container Insights must be explicitly enabled per cluster — it is NOT on by default. Exam questions about 'detailed container-level metrics' or 'per-container memory and CPU monitoring' require enabling Container Insights. Standard ECS metrics (service-level CPU/memory) are available without it.
EFS + ECS = persistent stateful storage. If an exam scenario describes containers needing to share files, persist data across task restarts, or access a shared filesystem, the answer is EFS (not EBS, which is single-instance block storage). EFS works with both EC2 and Fargate launch types.
Fargate Spot can be interrupted with a 2-minute warning. Design Fargate Spot workloads to handle interruptions gracefully (checkpoint progress, idempotent processing). Use mixed capacity provider strategies: Fargate Spot for batch, Fargate On-Demand for production services.
Task placement strategies (spread, binpack, random) only apply to EC2 launch type — NOT Fargate. AWS manages placement on Fargate. For HA on EC2, use 'spread' across AZs. For cost efficiency on EC2, use 'binpack' to maximize instance utilization before launching new instances.
ECS Service Connect vs Cloud Map: Service Connect is the newer, AWS-managed approach that adds built-in metrics (request count, response time) and automatic retry logic. Cloud Map is lower-level DNS/API service discovery. For new microservices architectures, exam answers increasingly favor Service Connect.
Common Mistake
ECS and EKS are interchangeable — you can migrate a Kubernetes application to ECS without significant rework
Correct
ECS uses a completely different, AWS-proprietary API and task definition format. Kubernetes manifests, Helm charts, kubectl commands, and Kubernetes-native features (CRDs, operators, PodDisruptionBudgets) do not exist in ECS. Migrating FROM Kubernetes to ECS requires completely rewriting all deployment configurations. If Kubernetes portability matters, use EKS.
This is the #1 most tested misconception about ECS. Exam questions deliberately present ECS as an option for Kubernetes migrations — it is always wrong. The keyword 'Kubernetes' in any scenario locks in EKS as the answer.
Common Mistake
The EC2 instance role provides AWS permissions to containers running on ECS EC2 instances
Correct
Containers should use the ECS Task IAM Role (taskRoleArn), NOT the EC2 instance profile. The task role delivers credentials via the ECS credential provider endpoint (169.254.170.2), which is scoped to the specific task. Using the instance role means ALL tasks on that instance share the same permissions — violating least privilege and creating security risk.
This is a critical security misconception. Exam questions about 'granting an ECS task access to S3 with least privilege' always require a task IAM role, not an instance profile. Remember: Task Role = task permissions, Execution Role = ECS launch permissions.
Common Mistake
Fargate automatically scales EC2 instances under the hood, so you don't need to worry about capacity
Correct
Fargate is truly serverless — there are NO EC2 instances to manage or scale. AWS handles all infrastructure. However, you still need to configure ECS Service Auto Scaling to scale the NUMBER OF TASKS. Fargate handles the compute provisioning per task; Application Auto Scaling handles how many tasks are running.
Candidates confuse Fargate's infrastructure abstraction with automatic task scaling. Fargate removes EC2 management but does NOT automatically scale your service. You must still define scaling policies to increase/decrease task count based on metrics.
Common Mistake
Security groups on a public subnet provide the same isolation as placing ECS tasks in a private subnet
Correct
Security groups control traffic at the ENI level but tasks in a public subnet can receive a public IP and are directly routable from the internet. Tasks in a private subnet have no direct internet exposure — traffic must flow through a load balancer or NAT gateway. For database-tier containers and sensitive services, private subnets provide defense-in-depth that security groups alone cannot replicate.
This is a recurring exam trap across multiple services. The correct architecture for multi-tier ECS applications: ALB in public subnets, ECS tasks in private subnets, RDS in isolated subnets — with security groups as an additional layer, not the only layer.
Common Mistake
ECS tasks on Fargate can use GPU instances for ML inference workloads
Correct
Fargate does NOT support GPU instances. GPU-enabled container workloads (ML inference, video transcoding, scientific computing) must use the EC2 launch type with GPU instance types such as p3, g4dn, or g5. This is a hard architectural constraint, not a configuration option.
Exam scenarios about containerized ML inference or GPU workloads on ECS always require EC2 launch type. If the question mentions Fargate + GPU, it is a distractor. Remember: Fargate = serverless CPU/memory only.
Common Mistake
ECS rolling deployments and ECS blue/green deployments via CodeDeploy achieve the same result
Correct
Rolling deployments replace tasks incrementally (controlled by minimumHealthyPercent and maximumPercent) with no ability to instantly roll back — you must re-deploy. Blue/green deployments via CodeDeploy maintain TWO complete task sets simultaneously, shift ALB traffic between them, and can instantly roll back by shifting traffic back to the original task set. Blue/green is safer for production but costs more (double tasks during deployment).
Exam questions about 'zero-downtime deployments with instant rollback capability' always point to CodeDeploy blue/green, not ECS rolling updates. Rolling updates are simpler but cannot instantly revert without a new deployment.
Common Mistake
ECS Service Auto Scaling scales both the number of tasks AND the underlying EC2 instances
Correct
ECS Service Auto Scaling (via Application Auto Scaling) ONLY scales the desired task count. Scaling EC2 instances is a separate concern handled by EC2 Auto Scaling Groups with Capacity Providers. You need BOTH layers configured for EC2 launch type: task scaling (Application Auto Scaling) + instance scaling (EC2 ASG with Capacity Provider managed scaling).
This two-layer scaling architecture is heavily tested. Fargate eliminates the instance scaling layer entirely. For EC2 launch type, forgetting to configure Capacity Provider managed scaling means tasks may fail to launch when all instances are full.
TERE = Task Execution Role for ECR/logs; Task Role for Everything else (your app's AWS API calls)
ECS = Elastic Container Service (AWS-proprietary). EKS = Elastic Kubernetes Service (Kubernetes-native). K in EKS = K8s = Keep your Kubernetes manifests
Fargate = FANG (Fargate Abstracts Nothing GPU) — no GPU, no placement strategies, no instance management
Blue/Green = Both exist simultaneously (double cost, instant rollback). Rolling = Replace gradually (single cost, no instant rollback)
awsvpc = A task gets its own VPC ENI (task-level security groups). bridge/host = shared instance networking (instance-level security groups)
CertAI Tutor · SAA-C03, DOP-C02, SAP-C02, DEA-C01, CLF-C02, DVA-C02 · 2026-02-21