Amazon ECS

What ECS is

ECS runs your containers and keeps them running. You describe a workload in a task definition — which image, how much CPU and memory, which ports, which IAM roles — and ECS launches it as one or more tasks. Group those into a long-running service and ECS holds the desired count steady, rescheduling any task that dies.

Where those containers actually land is the launch type: serverless Fargate, or EC2 instances in a cluster you own and patch. Same ECS either way, same task definitions and services. It sits between raw EC2, where you manage the whole server, and Lambda, where you manage nothing but a function.

Design Beaver models ECS as a container workload with its own ENI, security group, and two separate IAM roles, so it validates as you draw which edges are real and what each one needs.

When to use ECS (and when not to)

Reach for ECS when the work is containerized and runs continuously: a web or API tier behind a load balancer, background workers, queue consumers, or a handful of microservices sharing one cluster. It’s the straightforward answer when you want containers on AWS and don’t want to operate a Kubernetes control plane.

Don’t reach for it for short event-driven request/response logic — Lambda handles that without a cluster and without paying for idle tasks. For a single container with the simplest possible setup, App Runner or a plain EC2 instance is less work. If you need portable Kubernetes APIs or you already live in Helm, that’s EKS, not ECS. And purely static content belongs on S3 behind CloudFront.

Variants: where the containers run

The launch type is the one architectural choice that changes your operational surface. Everything else about ECS stays the same.

Pick Fargate when you don’t want to manage servers at all. Pick the EC2 launch type when you need instance-level control — GPUs, a specific instance family — or when high, steady utilization makes owning the instances cheaper than paying per task.

ECS pricing in plain English

ECS itself is free. You pay for whatever compute the tasks sit on, and the launch type decides which meter runs.

How ECS connects to other services

Boxes and arrows hide the part that actually decides whether an ECS architecture works: which role carries which permission, and which network path the traffic takes.

• →RDS

  The containerized application running in an ECS task connects to an RDS database as its data layer (e.g. a task running a web API talking to PostgreSQL)

• →ECR

  ECS pulls the container image for the task from a private ECR repository when the task starts

• →S3security

  The application in the ECS task reads/writes S3 objects via the AWS SDK (e.g. serving user uploads, reading config/assets, writing logs or exports)

  IAM:s3:GetObjects3:PutObjects3:ListBucket

• →DynamoDBsecurity

  The application in the ECS task reads/writes a DynamoDB table via the AWS SDK

  IAM:dynamodb:GetItemdynamodb:PutItemdynamodb:Querydynamodb:UpdateItemdynamodb:DeleteItem

• →SQSsecurity

  The application in the ECS task sends or polls SQS messages via the AWS SDK to decouple components (e.g. a worker service draining a queue)

  IAM:sqs:SendMessagesqs:ReceiveMessagesqs:DeleteMessagesqs:GetQueueAttributes

• →SNSsecurity

  The application in the ECS task publishes messages to an SNS topic via the AWS SDK to fan an event out to multiple subscribers

  IAM:sns:Publish

• ←Application Load Balancer

  An Application Load Balancer routes incoming HTTP(S) requests to the ECS service's tasks through a target group — the standard way to put a container web/app tier behind a public entry point without giving each task a public IP

• ←API Gateway

  API Gateway exposes the ECS service over a managed public HTTPS API using a private integration, so an internal container tier in private subnets can be reached without being made publicly routable

• →Secrets Managersecurity

  The containerized app reads a secret (typically the database credentials for its RDS/RDS Proxy connection, or third-party API keys) from Secrets Manager instead of baking it into the image or a plain environment variable

  IAM:secretsmanager:GetSecretValuesecretsmanager:DescribeSecret

• →RDS Proxy

  The containerized app connects to an RDS Proxy endpoint instead of directly to the DB instance, so a bursty or autoscaling task count doesn't exhaust the database's connection limit and failover is faster

The IAM point deserves saying twice, because it’s the mistake that costs the most debugging time. ECS gives a task two roles that run at different moments:

• The task execution role belongs to the ECS agent and runs before your code does, pulling the image from ECR and wiring up logging. ECR pull permissions live here.
• The task role belongs to your application code, and it’s what the AWS SDK inside the container uses to call S3, DynamoDB, SQS, or SNS. The SDK picks up its temporary credentials automatically, so there are never access keys baked into the image.

So an ECS → ECR edge is an execution-role concern, while an ECS → S3 edge is a task-role concern. Get them backwards and you get one of two confusing failures: a task that never starts because it can’t pull its image, or a running app that gets AccessDenied on its first API call.

Reaching RDS works differently again — it’s not an IAM question at all. It’s the same VPC, database credentials, and a security-group rule on the DB port. Because tasks use the awsvpc network mode, each task gets its own ENI and security group, so the RDS inbound rule references the task’s security group.

What ECS can’t connect to

Some ECS edges look reasonable on a canvas but don’t exist in AWS. Design Beaver flags them rather than letting you draw an architecture nobody can build.

• ✕Route 53

  An ECS service is not a Route 53 alias target and nothing resolves a domain straight to it — Route 53 points a domain at the internet-facing thing in front of the tasks (an ALB, or CloudFront), which then routes to the ECS service. There is no direct DNS-to-service edge.

Anti-patterns Design Beaver catches

These are the ECS mistakes that survive a diagram review and then show up as a surprise bill or an exposed database.

Gotchas that bite in production

• Two roles, not one. The execution role pulls the image; the task role is for your app’s AWS calls. Splitting them correctly the first time saves an afternoon.
• Target type must be ip, not instance. A Fargate task — any awsvpc task — is reached at its ENI’s IP, not by an EC2 instance ID. Register the service against an ip target group and ECS keeps task IPs added and drained automatically as tasks cycle.
• API Gateway can’t target ECS directly. There is no ECS integration. Front the service with an internal ALB or NLB and connect through a VPC Link private integration.
• Private tasks can’t reach ECR by default. Add the ecr.dkr and ecr.api interface endpoints plus the S3 gateway endpoint. Routing pulls through a NAT Gateway works, but you pay data processing on every layer download forever.
• A lone internet-facing task is not a web tier. Task replacements change IPs, so clients have nothing stable to point at and no health-checked entry point. Put a load balancer in front.

Further reading

• Official AWS documentation
• Amazon ECS on AWS Fargate
• Task execution IAM role vs task IAM role
• Why we built a validation engine