Deploy a container to ECS Fargate

Build a small, working image first

If you don't have a Dockerfile yet, here's a reasonable Node starter:

# Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
ENV PORT=8080
EXPOSE 8080
CMD ["node", "server.js"]

Build and test locally:

docker build -t mybrand-api:latest .
docker run -p 8080:8080 mybrand-api:latest
curl http://localhost:8080/health

If it doesn't work locally, it won't work on Fargate. Get the local image healthy before going anywhere near AWS.

One repo per image; private by default

# Create the repo
aws ecr create-repository --repository-name mybrand-api --region us-east-1

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin \
    <ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com

# Tag the local image with the ECR URL
docker tag mybrand-api:latest \
  <ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/mybrand-api:latest

# Push
docker push <ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/mybrand-api:latest

The full image URI — <ACCOUNT_ID>.dkr.ecr.<REGION>.amazonaws.com/<REPO>:<TAG> — is what the task definition will reference. Note the account ID and region; you'll paste them often.

Two roles: execution and task

ECS needs two distinct IAM roles, and confusing them is the #1 first-deploy failure:

• Task execution role (ecsTaskExecutionRole) — used by ECS/Fargate itself to pull the image from ECR and write logs to CloudWatch. AWS provides a managed policy (AmazonECSTaskExecutionRolePolicy) that's exactly what you need.
• Task role — used by your application code when it calls AWS APIs (e.g., reading from S3). Empty by default; add policies as your app needs them.

Create the execution role once per account:

aws iam create-role --role-name ecsTaskExecutionRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]
  }'
aws iam attach-role-policy --role-name ecsTaskExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

The task role is project-specific; for a service that doesn't call AWS APIs, you can omit it.

JSON that describes one running instance

Save as task-definition.json:

{
  "family": "mybrand-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
  "containerDefinitions": [{
    "name": "api",
    "image": "<ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/mybrand-api:latest",
    "portMappings": [{"containerPort": 8080, "protocol": "tcp"}],
    "essential": true,
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/mybrand-api",
        "awslogs-region": "us-east-1",
        "awslogs-stream-prefix": "ecs",
        "awslogs-create-group": "true"
      }
    }
  }]
}

Smallest Fargate task is 256 CPU units (¼ vCPU) + 512 MB RAM. Most APIs run fine at that size. Register the task definition:

aws ecs register-task-definition --cli-input-json file://task-definition.json

The networking layer that puts traffic in front of your tasks

This part is genuinely faster in the console. AWS Console → ECS → Create cluster → name it mybrand-prod → AWS Fargate (serverless) infrastructure → Create.

Then, separately, create the Application Load Balancer: EC2 → Load Balancers → Create load balancer → Application Load Balancer:

• Scheme: internet-facing. IP address type: IPv4.
• VPC: your default VPC. Mappings: at least two subnets in different AZs (Fargate requires this).
• Security groups: create a new one allowing inbound 80 + 443 from anywhere.
• Listeners: HTTP:80 forwarding to a new target group called mybrand-api-tg with target type IP, protocol HTTP, port 8080, health-check path /health (or wherever your app responds with 200).

After creation, the ALB has a DNS name like mybrand-prod-12345.us-east-1.elb.amazonaws.com. Note it; Step 8 points your domain at it.

"Run N tasks, behind this ALB, forever"

ECS console → your cluster → Create service:

• Launch type: FARGATE.
• Task definition: mybrand-api (latest revision).
• Service name: mybrand-api.
• Desired tasks: 2 for redundancy, 1 if you're testing.
• Networking: your default VPC, the same two subnets the ALB uses, the security group you created in Step 5.
• Load balancing: attach to the ALB. Target group: mybrand-api-tg. Container to load balance: api:8080.

Create. Fargate pulls the image, starts the tasks, registers them with the target group. After 2–3 minutes the service shows "ACTIVE" and the target group shows healthy targets. Test:

curl http://<ALB_DNS_NAME>/health
# Expected: ok

Different from CloudFront: ALBs use the cert from their own region

Unlike CloudFront (which only reads certs from us-east-1), the ALB uses the cert from the same region the ALB lives in. If your ALB is in us-east-1, the cert needs to be in us-east-1; if it's in eu-west-2, the cert needs to be there.

aws acm request-certificate \
  --domain-name api.mybrand.com \
  --validation-method DNS \
  --region <SAME_REGION_AS_ALB>

If DNS is at Route 53 in the same account, the console offers "Create records in Route 53" for the validation CNAME. Otherwise add the CNAME at your DNS provider. Wait for ACM to show "Issued" — usually 5–15 minutes.

One ALB listener for HTTPS; one Route 53 Alias

EC2 → Load Balancers → your ALB → Listeners tab → Add listener:

• Protocol: HTTPS. Port: 443.
• Default action: forward to the same target group (mybrand-api-tg).
• SSL/TLS certificate: the ACM cert from Step 7.

Optionally edit the HTTP:80 listener to redirect to HTTPS:443. Save.

Now point DNS at the ALB. In Route 53 → your hosted zone → Create record:

• Name: api.
• Type: A. Alias: on. Route traffic to: Alias to Application and Classic Load Balancer → region → your ALB.

Save. Test: curl -I https://api.mybrand.com/health. You should see HTTP/2 200.

Build, push, force new deployment

After all the setup, every subsequent deploy is three commands:

# Build the new image
docker build -t mybrand-api:latest .

# Push to ECR (auth refresh might be needed first)
docker tag mybrand-api:latest \
  <ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/mybrand-api:latest
docker push <ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/mybrand-api:latest

# Tell ECS to roll out new tasks with the same task definition (which references :latest)
aws ecs update-service \
  --cluster mybrand-prod \
  --service mybrand-api \
  --force-new-deployment

ECS performs a rolling deploy: starts new tasks, waits for them to pass the ALB health check, drains connections from the old tasks, kills them. Zero-downtime by default. Watch the deploy in the ECS console under your service's Deployments tab.

To roll back: ECS keeps prior task-definition revisions forever. Update the service to use the previous revision: aws ecs update-service --cluster mybrand-prod --service mybrand-api --task-definition mybrand-api:<PREVIOUS_REVISION>. Same rolling-deploy mechanics in reverse.