AWS Microservices on ECS Fargate: A Production Reference Architecture

Most teams don’t fail at microservices because they can’t write services — they fail because they can’t run twelve of them: twelve pipelines, twelve scaling policies, twelve things that page you at 2 a.m. Amazon ECS (Elastic Container Service) with the Fargate launch type is AWS’s answer for teams who want orchestration without operating a control plane or patching a node fleet: hand ECS an image and a task size, and AWS finds the compute, wires the networking, and replaces anything that dies.

This is a production reference architecture, not a hello-world: an Application Load Balancer splitting /orders and /catalog traffic to independent Fargate services, ECS Service Connect for east-west calls, a database per service (Aurora PostgreSQL and DynamoDB), an SQS-driven worker scaling on queue depth, images flowing through ECR with immutable tags, secrets injected from Secrets Manager, rolling and blue/green deployments, and Container Insights plus X-Ray watching all of it.

Everything is backed by real aws CLI commands, a complete task-definition JSON, and Terraform — including the two decisions that dominate design reviews: Fargate vs EC2, and ECS vs EKS.

What problem this solves

A monolith on EC2 works — until the payments module needs to scale independently of search, until one team’s deploy takes down another team’s feature, until a memory leak anywhere restarts everything. Microservices fix the coupling but multiply the operational surface. ECS on Fargate is the managed middle path: real orchestration (placement, health-driven replacement, discovery, deployment strategies) with zero servers to patch.

If you run more than two or three services with different scaling profiles and different teams shipping them, you are the target audience. One service, one team? Start simpler — your first container deployment on ECS Fargate — and grow into this reference.

Learning objectives

By the end of this article you can:

• Explain the ECS object model — cluster → service → task → task definition — and what each layer owns, including the task lifecycle states you’ll see during incidents.
• Choose between Fargate and EC2 launch types (and between ECS and EKS) with concrete cost, limit, and operational arguments.
• Design ALB path-based routing to multiple target groups with health checks that don’t lie, and wire one security group per service in awsvpc mode.
• Wire service discovery with Cloud Map and ECS Service Connect, and know exactly when each fails.
• Attach per-service data stores (Aurora + RDS Proxy, DynamoDB) and an async backbone (SQS with DLQs, SNS fan-out, EventBridge routing).
• Ship images through ECR with immutable tags and scan-on-push, and run rolling and blue/green (CodeDeploy) deployments with automatic rollback.
• Configure target-tracking autoscaling on CPU, ALB requests per target, and queue backlog per task.
• Instrument the platform with Container Insights, structured logs, and X-Ray, and troubleshoot the ten most common ECS failure modes from stoppedReason up.

Prerequisites & where this fits

You should already know Docker basics (build/tag/push), VPC fundamentals (subnets, route tables, security groups — refresher: AWS VPC, subnets and security groups explained), and IAM roles versus policies. If ECS itself is new, do the basics lesson first (ECS & Fargate basics); if you’re deciding whether ECS is even the right runtime, read ECS vs EKS vs Fargate: choosing your container path alongside this.

Where this sits: this article owns the middle of the stack — orchestration, Fargate compute, service wiring, deployments, scaling, observability. The edge tier has its own deep-dive in ALB vs NLB vs API Gateway, data-store selection in RDS vs DynamoDB vs Aurora compared, and the async tier connects onward to Lambda event-driven patterns when consumers get bursty enough that an always-on worker stops making sense.

Core concepts

The ECS mental model is four nouns. A cluster is a logical namespace for running tasks — with Fargate, little more than a name, an IAM boundary, and a Container Insights setting. A task definition is the versioned blueprint: image(s), CPU/memory, ports, secrets, log config, IAM roles. A task is a running instantiation of that blueprint — one or more co-scheduled containers sharing an ENI. A service is the supervisor that keeps N copies running, registers them with a load balancer, and orchestrates deployments when you point it at a new revision.

Task lifecycle — what you’ll see during an incident

Knowing the fixed task states turns “it’s not starting” into a precise diagnosis.

The task definition, end to end

A production-shaped task definition for the orders service — awsvpc, ARM64 (cheaper), a named port for Service Connect, secrets from Secrets Manager and SSM, a container health check, and logs:

{
  "family": "orders",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "runtimePlatform": { "cpuArchitecture": "ARM64", "operatingSystemFamily": "LINUX" },
  "executionRoleArn": "arn:aws:iam::111122223333:role/ordersTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::111122223333:role/ordersTaskRole",
  "containerDefinitions": [
    {
      "name": "orders",
      "image": "111122223333.dkr.ecr.ap-south-1.amazonaws.com/orders:2026-07-07.4f9c1e2",
      "essential": true,
      "portMappings": [
        { "name": "orders-http", "containerPort": 8080, "protocol": "tcp", "appProtocol": "http" }
      ],
      "environment": [
        { "name": "SPRING_PROFILES_ACTIVE", "value": "prod" }
      ],
      "secrets": [
        { "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:ap-south-1:111122223333:secret:prod/orders/db-AbCdEf:password::" },
        { "name": "PAYMENT_API_KEY", "valueFrom": "arn:aws:ssm:ap-south-1:111122223333:parameter/prod/orders/payment-api-key" }
      ],
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -sf http://localhost:8080/healthz || exit 1"],
        "interval": 15, "timeout": 5, "retries": 3, "startPeriod": 30
      },
      "stopTimeout": 30,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/orders",
          "awslogs-region": "ap-south-1",
          "awslogs-stream-prefix": "orders"
        }
      }
    }
  ]
}

The fields that decide whether your 2 a.m. is quiet:

Register it, and the cluster around it:

# Cluster with Container Insights and Fargate + Spot capacity providers
aws ecs create-cluster \
  --cluster-name shopfast-prod \
  --capacity-providers FARGATE FARGATE_SPOT \
  --default-capacity-provider-strategy \
      capacityProvider=FARGATE,weight=1,base=2 \
      capacityProvider=FARGATE_SPOT,weight=3 \
  --settings name=containerInsights,value=enhanced

# Register the task definition from the JSON above
aws ecs register-task-definition --cli-input-json file://orders-taskdef.json

# See what revision you got
aws ecs describe-task-definition --task-definition orders \
  --query 'taskDefinition.{family:family,rev:revision,cpu:cpu,mem:memory}'

Fargate or EC2 launch type — and where EKS fits

The launch-type decision is the first fork in every ECS design review. Both run the same task definitions; what changes is who owns the compute.

Rule of thumb: below roughly 50–100 sustained vCPUs, Fargate’s premium is smaller than the salary-time of running node fleets. Above that, measure — a well-packed EC2/Graviton fleet with Savings Plans wins on raw compute, but only if someone owns AMI hygiene, drain logic, and utilization. Mixed estates are normal: Fargate for spiky/low-baseline services, EC2 capacity providers for the big steady ones.

Fargate task size matrix (valid CPU/memory combinations)

Fargate only accepts fixed shapes — this matrix is the sizing vocabulary for the whole platform:

ECS vs EKS — the honest decision table

The trap: choosing EKS “for the hiring signal”, then running it like ECS — no operators, no CRDs, one namespace — while paying the upgrade tax anyway. If the k8s API isn’t a requirement, ECS removes an entire failure domain. Deeper treatment: choose your container path.

Networking: one ENI, one security group per service

Fargate mandates awsvpc network mode: every task gets its own elastic network interface (ENI) with a private IP in your subnet — no port juggling, no bridge-mode NAT. This is the platform’s biggest security win: you write security-group rules between services exactly as you would between EC2 instances.

The reference layout: tasks in private subnets across two AZs with assignPublicIp=DISABLED, ALB in public subnets, and either a NAT gateway or VPC interface endpoints for the AWS APIs Fargate needs at task start (required for zero-egress designs).

Chaining SGs by reference (source = another SG, never a CIDR) means scale-out needs zero rule changes — every new task ENI inherits its service’s SG. What Fargate must reach at task start — miss one in a private subnet and tasks die in PENDING with pull/init errors:

Cost math: interface endpoints run ~$0.01/hr per AZ (two AZs × 5 endpoints ≈ $73/month) vs one NAT gateway at ~$0.045/hr + $0.045/GB processed (≈ $33/month + data). Endpoints win on security (no internet path) and data-heavy pulls; NAT wins on simplicity when you need general egress anyway.

Traffic in: ALB path-based routing to services

One ALB fronts the platform. The HTTPS :443 listener evaluates rules by ascending priority; each rule matches conditions (path, host, header, query, source IP) and forwards to a target group (TG) holding task IPs (target-type: ip — mandatory for awsvpc).

Key ALB numbers to design against: 100 rules per listener (default, adjustable), 5 condition values per rule, 1,000 targets per ALB, idle timeout 60 s default (raise for long polls/SSE) — and WAF associates at the ALB, so one Web ACL protects every service behind it.

Target-group health checks drive ECS task replacement, so tune them deliberately:

# Target group for the orders service (IP targets for awsvpc)
aws elbv2 create-target-group \
  --name orders-tg --protocol HTTP --port 8080 --vpc-id vpc-0ab12cd34ef56gh78 \
  --target-type ip --health-check-path /healthz \
  --health-check-interval-seconds 15 --healthy-threshold-count 2

# Path rule on the HTTPS listener
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:ap-south-1:111122223333:listener/app/shopfast/50dc6c495c0c9188/f2f7dc8efc522ab2 \
  --priority 10 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/orders","/orders/*"]}}]' \
  --actions '[{"Type":"forward","TargetGroupArn":"arn:aws:elasticloadbalancing:ap-south-1:111122223333:targetgroup/orders-tg/943f017f100becff"}]'

Outgrowing path rules (per-team throttling, API keys, edge JWT authorizers) is an API Gateway conversation — see ALB vs NLB vs API Gateway.

East-west traffic: Cloud Map and ECS Service Connect

North-south is the ALB’s job; the harder question is how orders calls catalog. Four options, ascending in capability:

Service Connect is the default answer for ECS microservices in 2026. It piggybacks on a Cloud Map HTTP namespace (no hosted zone needed) and is transparent to the client: your code calls http://catalog:8080, the sidecar resolves and load-balances across healthy catalog tasks, retries transient failures, and publishes RequestCount and per-target latency to CloudWatch with zero code change.

The wiring is three requirements — miss any and names won’t resolve: the port mapping must be named in the task definition ("name": "orders-http" above); both services join the same namespace, the server side declaring an alias (catalog:8080); and the config applies only to tasks launched after it’s set — force a new deployment when enabling it on an existing service.

aws ecs create-service \
  --cluster shopfast-prod \
  --service-name orders \
  --task-definition orders:12 \
  --desired-count 3 \
  --network-configuration 'awsvpcConfiguration={subnets=[subnet-0a1b2c3d,subnet-0e4f5a6b],securityGroups=[sg-0aa11bb22cc33dd44],assignPublicIp=DISABLED}' \
  --load-balancers 'targetGroupArn=arn:aws:elasticloadbalancing:ap-south-1:111122223333:targetgroup/orders-tg/943f017f100becff,containerName=orders,containerPort=8080' \
  --health-check-grace-period-seconds 60 \
  --deployment-configuration 'deploymentCircuitBreaker={enable=true,rollback=true},maximumPercent=200,minimumHealthyPercent=100' \
  --service-connect-configuration 'enabled=true,namespace=shopfast,services=[{portName=orders-http,discoveryName=orders,clientAliases=[{port=8080,dnsName=orders}]}]'

Per-service data: RDS and DynamoDB

The architectural rule that keeps microservices micro: each service owns its data store; no other service connects to it directly. Cross-service data access goes through the owning service’s API or through events — never through a shared schema. In the reference: orders owns Aurora PostgreSQL (Multi-AZ, 5432, reachable only from sg-orders via RDS Proxy) because order state wants transactions and joins; catalog owns a DynamoDB on-demand table because key-based reads at any scale with zero connection pools is exactly DynamoDB’s shape; the billing worker consumes the queue and writes invoices to its own Aurora schema.

The selection heuristic in one pass (full comparison: RDS vs DynamoDB vs Aurora): multi-row transactions and ad-hoc/reporting queries → Aurora, and plan for connection limits under scale-out; known key-based access with spiky, unbounded scale → DynamoDB, and respect the 400 KB item cap and hot-partition-key modelling up front. A service that genuinely needs both patterns is usually two services wearing one name.

The connection-pool trap is the #1 scale-out failure with containers + RDS. Thirty tasks × 20-connection pools = 600 connections marching toward max_connections. Fix it structurally: cap pools per task (5–10 is plenty at 0.5 vCPU) and put RDS Proxy between services and Aurora — it multiplexes thousands of client connections onto a small pinned pool, cuts app-visible failover time sharply, and supports IAM auth so tasks never hold a DB password. Cost ≈ $0.015/hr per vCPU of the target DB — cheap insurance against a 2 a.m. FATAL: too many connections.

DynamoDB pairs beautifully with Fargate — no connections at all; the task role IAM policy is the access control:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:PutItem"],
    "Resource": "arn:aws:dynamodb:ap-south-1:111122223333:table/catalog"
  }]
}

The async backbone: SQS, SNS, EventBridge

Synchronous chains are how microservices reinvent the distributed monolith: checkout → inventory → email, and suddenly checkout’s p99 includes the mail provider’s bad day. The reference keeps the synchronous graph shallow (client → service, at most one east-west hop) and pushes everything else through messages.

The pattern that covers 90% of platforms: orders publishes OrderPlaced to EventBridge; rules route it to the billing queue, the notifications queue, and an archive; each consumer owns its SQS queue (buffer + retry isolation). Queue settings that must not stay on defaults:

The worker service runs no load balancer — just desiredCount pollers scaling on backlog per task (ApproximateNumberOfMessagesVisible ÷ RunningTaskCount as a custom metric): near zero at night, dozens during a sale. For when a Lambda consumer beats a Fargate worker (bursty, short, sub-15-min work), see Lambda event-driven patterns.

Shipping images: ECR and the pipeline

Every running task traces back to an image in Amazon ECR; the difference between a calm platform and incident archaeology is image discipline.

aws ecr create-repository --repository-name orders \
  --image-tag-mutability IMMUTABLE \
  --image-scanning-configuration scanOnPush=true

# Build (multi-arch for our ARM64 tasks), push, and roll the service
aws ecr get-login-password --region ap-south-1 | \
  docker login --username AWS --password-stdin 111122223333.dkr.ecr.ap-south-1.amazonaws.com

docker buildx build --platform linux/arm64 \
  -t 111122223333.dkr.ecr.ap-south-1.amazonaws.com/orders:2026-07-07.4f9c1e2 --push .

The pipeline is boring on purpose: build → scan gate → register-task-definition with the new tag → update-service. Because a revision is immutable, deploy = new revision, rollback = point back at the old one. Never deploy by re-pushing a mutable tag — you lose the audit trail and the rollback lever.

Deployments: rolling by default, blue/green when it hurts

ECS gives you two first-class strategies (a built-in BLUE_GREEN option also landed in deploymentConfiguration mid-2025 — verify regional availability; CodeDeploy remains the battle-tested path).

Rolling behaviour is governed by two percentages: minimumHealthyPercent (default 100) and maximumPercent (default 200) — with 3 tasks: “start up to 3 new ones, never dip below 3 healthy.” Always pair it with the deployment circuit breaker (enable=true,rollback=true): after repeated task-start failures (threshold = half the desired count, min 3, max 200) it marks the deployment failed and auto-rolls back to the last good revision — a bad image costs 4 minutes instead of an evening.

CodeDeploy blue/green shifts traffic with named configs — the real ones you’ll reference: CodeDeployDefault.ECSAllAtOnce (flip 100% at once, still with instant rollback), ECSCanary10Percent5Minutes / ECSCanary10Percent15Minutes (10% first, the rest after the bake), and ECSLinear10PercentEvery1Minutes / ECSLinear10PercentEvery3Minutes (+10% per interval). Attach CloudWatch alarms (5xx rate, p99 latency) to the deployment group and CodeDeploy rolls back automatically when the canary trips them. The deploy artifact is an appspec.yaml:

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:ap-south-1:111122223333:task-definition/orders:13"
        LoadBalancerInfo:
          ContainerName: "orders"
          ContainerPort: 8080

One more deploy-time 502 source: graceful shutdown. On replacement, ECS deregisters the task (ALB stops new sends; in-flight continue up to the deregistration delay), sends SIGTERM, waits stopTimeout (default 30 s), then SIGKILL. Your app must catch SIGTERM and drain — PID-1 shell wrappers that swallow signals are the classic culprit; use exec in entrypoints.

Configuration and secrets

Plain config rides in environment; anything sensitive rides in secrets[] — fetched by the execution role at task start, injected as env vars, never visible in the task definition, console, or describe-tasks.

Two production gotchas: (1) secrets resolve once, at task start — rotation does nothing to running tasks until an update-service --force-new-deployment (bake it into the rotation Lambda); (2) the execution role needs secretsmanager:GetSecretValue plus kms:Decrypt — putting those on the task role is the most common ResourceInitializationError on first deploy.

Autoscaling: track a target, don’t chase alarms

ECS service scaling is Application Auto Scaling on DesiredCount. Target tracking is the default tool: pick a metric and a target value; AWS manages the alarms both directions.

resource "aws_appautoscaling_target" "orders" {
  service_namespace  = "ecs"
  resource_id        = "service/shopfast-prod/orders"
  scalable_dimension = "ecs:service:DesiredCount"
  min_capacity       = 3
  max_capacity       = 30
}

resource "aws_appautoscaling_policy" "orders_cpu" {
  name               = "orders-cpu-60"
  policy_type        = "TargetTrackingScaling"
  service_namespace  = aws_appautoscaling_target.orders.service_namespace
  resource_id        = aws_appautoscaling_target.orders.resource_id
  scalable_dimension = aws_appautoscaling_target.orders.scalable_dimension

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value       = 60
    scale_out_cooldown = 60
    scale_in_cooldown  = 300
  }
}

Rules that keep scaling boring: min_capacity ≥ 2 (one per AZ) for anything user-facing; scale in slower than out (the asymmetric cooldowns above); protect long-running jobs with ECS task scale-in protection ($ECS_AGENT_URI/task-protection/v1/state from inside the task); and remember target tracking never acts on missing data — a worker that crashes and stops emitting backlog metrics won’t scale itself back up.

Observability: Container Insights, logs, X-Ray

Three signals, all native:

Metrics — CloudWatch Container Insights (containerInsights=enhanced on the cluster) publishes task- and service-level CPU, memory, network, and storage plus deployment state. Logs — the awslogs driver ships stdout/stderr to a log group per service (/ecs/orders); log JSON and CloudWatch Logs Insights becomes your grep. Traces — X-Ray stitches the request path (ALB → orders → catalog → Aurora) via an ADOT or amazon/aws-xray-daemon sidecar (UDP 2000); default sampling (1 req/s + 5%) shows structure without paying for every request.

The alarm set that catches 95% of pages before customers do, per service: ALB HTTPCode_Target_5XX_Count above ~1% of requests for two 1-minute periods; TargetResponseTime p99 above 2× its normal level; HealthyHostCount < 2; Container Insights RunningTaskCount short of DesiredTaskCount for 5 minutes (task churn); memory utilization > 85% sustained (OOM kills arrive at 100%); SQS ApproximateAgeOfOldestMessage above the processing SLA plus any message visible on a DLQ; and an EventBridge rule on SERVICE_DEPLOYMENT_FAILED deployment state changes that pages the owning team directly.

Architecture at a glance

Read the diagram left to right, the direction a request travels. A client resolves api.shopfast.in through Route 53 (alias to the ALB) and lands on the ALB behind AWS WAF (managed rule groups plus a 2k/5-min rate limit). Listener rules path-route /orders/* and /catalog/* to separate target groups, each backed by an independent Fargate service — every task with its own ENI and security group, so sg-aurora literally cannot accept a connection that didn’t come from an orders task. East-west, orders calls catalog by its Service Connect name (catalog:8080) through the managed proxy rather than back out through the ALB.

Each service owns its data: orders writes to Aurora PostgreSQL (Multi-AZ, 5432, via RDS Proxy); catalog reads a DynamoDB on-demand table. Order events flow to SQS (maxReceiveCount 3 DLQ) where the billing worker — no load balancer, scaled on backlog-per-task — consumes them. On the ops rail, ECR feeds immutable scan-on-push images to all three services and CloudWatch (Container Insights + X-Ray) watches the whole path. The numbered badges mark the five places this architecture most often breaks; the legend beneath the diagram narrates symptom, confirmation, and fix for each.

Real-world scenario

ShopFast, a Bengaluru D2C electronics retailer, ran a Django monolith on four EC2 m5.large instances behind a classic ELB. Two problems forced the move: flash-sale traffic (baseline ~40 req/s, peaks ~1,100 req/s) meant permanently paying for peak, and the checkout and catalog teams blocked each other’s releases — eleven deploys a month, four rollbacks, every rollback all-or-nothing.

Over eight weeks they carved three services onto a shopfast-prod cluster: orders (0.5 vCPU/1 GB, min 3 tasks, Aurora PG), catalog (0.5 vCPU/1 GB, min 2, DynamoDB on-demand), and a billing worker (0.25 vCPU/512 MB on FARGATE_SPOT) consuming an order-events queue fed by EventBridge. The ALB path-routed /orders and /catalog; everything else still hit the monolith — a strangler pattern, not a big bang.

The first flash sale after cutover exposed two design debts nine minutes apart. At 12:00, catalog autoscaling (CPU target 60%) hadn’t reacted — catalog is I/O-bound, CPU sat at 31% while requests-per-target tripled; p95 went from 210 ms to 2.4 s. At 12:09, orders tasks began failing health checks: Aurora threw FATAL: remaining connection slots are reserved — 24 scaled-out tasks × 25-connection Django pools had blown past max_connections. The on-call switched catalog’s scaling metric to ALBRequestCountPerTarget=700 (five-minute change, immediate relief) and capped the orders pool at 8; RDS Proxy went in the next week and the error class disappeared.

After one quarter: deploys up from 11 to 41/month (three circuit-breaker rollbacks, all automatic, none customer-visible); sale-day capacity scales 5→28 orders tasks and back in under 20 minutes; compute spend down from ₹31,000/month (4× m5.large 24×7 + headroom) to ~₹19,500/month — and zero AMI-patching weekends. Their retro one-liner is this article’s thesis: “The migration was 20% containers and 80% health checks, pools, and metrics.”

Advantages and disadvantages

The disadvantages cluster into two honest costs: money at high sustained scale (revisit EC2 capacity providers past ~100 steady vCPUs) and organizational surface — twelve services means twelve owners; if you don’t have the teams, don’t manufacture the services.

Hands-on lab

Deploys a real path-routed Fargate service behind an ALB in ~30 minutes. Cost: a few rupees if torn down within the hour (ALB + two 0.25 vCPU tasks ≈ $0.05/hr; new accounts get 750 free ALB-hours/month for 12 months). Uses the default VPC’s public subnets with public IPs to avoid NAT/endpoint costs — a lab-only shortcut, never production.

# 0. Variables (adjust region/account)
export AWS_REGION=ap-south-1
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
VPC=$(aws ec2 describe-vpcs --filters Name=is-default,Values=true --query 'Vpcs[0].VpcId' --output text)
SUBNETS=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC --query 'Subnets[0:2].SubnetId' --output text | tr '\t' ',')

# 1. ECR repo + a public demo image pushed into it
aws ecr create-repository --repository-name lab-web --image-tag-mutability IMMUTABLE
aws ecr get-login-password | docker login --username AWS --password-stdin $ACCOUNT.dkr.ecr.$AWS_REGION.amazonaws.com
docker pull public.ecr.aws/nginx/nginx:stable
docker tag public.ecr.aws/nginx/nginx:stable $ACCOUNT.dkr.ecr.$AWS_REGION.amazonaws.com/lab-web:v1
docker push $ACCOUNT.dkr.ecr.$AWS_REGION.amazonaws.com/lab-web:v1

# 2. Cluster + log group + execution role (AmazonECSTaskExecutionRolePolicy)
aws ecs create-cluster --cluster-name lab --settings name=containerInsights,value=enabled
aws logs create-log-group --log-group-name /ecs/lab-web
aws iam create-role --role-name labEcsExecRole --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 labEcsExecRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

# 3. Register the task definition (80 = nginx's port)
cat > taskdef.json <<EOF
{
  "family": "lab-web", "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"], "cpu": "256", "memory": "512",
  "executionRoleArn": "arn:aws:iam::$ACCOUNT:role/labEcsExecRole",
  "containerDefinitions": [{
    "name": "web", "image": "$ACCOUNT.dkr.ecr.$AWS_REGION.amazonaws.com/lab-web:v1",
    "essential": true,
    "portMappings": [{ "name": "web-http", "containerPort": 80, "protocol": "tcp" }],
    "logConfiguration": { "logDriver": "awslogs", "options": {
      "awslogs-group": "/ecs/lab-web", "awslogs-region": "$AWS_REGION", "awslogs-stream-prefix": "web" } }
  }]
}
EOF
aws ecs register-task-definition --cli-input-json file://taskdef.json

# 4. Security groups: ALB open on 80; tasks only from the ALB SG
ALB_SG=$(aws ec2 create-security-group --group-name lab-alb-sg --description "lab alb" --vpc-id $VPC --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $ALB_SG --protocol tcp --port 80 --cidr 0.0.0.0/0
TASK_SG=$(aws ec2 create-security-group --group-name lab-task-sg --description "lab tasks" --vpc-id $VPC --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $TASK_SG --protocol tcp --port 80 --source-group $ALB_SG

# 5. ALB + target group (ip targets) + listener with a path rule
ALB=$(aws elbv2 create-load-balancer --name lab-alb --subnets ${SUBNETS//,/ } --security-groups $ALB_SG --query 'LoadBalancers[0].LoadBalancerArn' --output text)
TG=$(aws elbv2 create-target-group --name lab-web-tg --protocol HTTP --port 80 --vpc-id $VPC --target-type ip --health-check-path / --query 'TargetGroups[0].TargetGroupArn' --output text)
LISTENER=$(aws elbv2 create-listener --load-balancer-arn $ALB --protocol HTTP --port 80 \
  --default-actions '[{"Type":"fixed-response","FixedResponseConfig":{"StatusCode":"404","ContentType":"text/plain","MessageBody":"no route"}}]' \
  --query 'Listeners[0].ListenerArn' --output text)
aws elbv2 create-rule --listener-arn $LISTENER --priority 10 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/","/index.html","/web/*"]}}]' \
  --actions "[{\"Type\":\"forward\",\"TargetGroupArn\":\"$TG\"}]"

# 6. The service: 2 tasks, circuit breaker on
aws ecs create-service --cluster lab --service-name web --task-definition lab-web \
  --desired-count 2 --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[${SUBNETS}],securityGroups=[$TASK_SG],assignPublicIp=ENABLED}" \
  --load-balancers "targetGroupArn=$TG,containerName=web,containerPort=80" \
  --health-check-grace-period-seconds 30 \
  --deployment-configuration 'deploymentCircuitBreaker={enable=true,rollback=true},maximumPercent=200,minimumHealthyPercent=100'

# 7. Watch it come up, then hit it
aws ecs describe-services --cluster lab --services web --query 'services[0].{running:runningCount,desired:desiredCount,events:events[0].message}'
DNS=$(aws elbv2 describe-load-balancers --load-balancer-arns $ALB --query 'LoadBalancers[0].DNSName' --output text)
curl -s http://$DNS/ | head -4        # expect the nginx welcome HTML
curl -s -o /dev/null -w "%{http_code}\n" http://$DNS/nope   # expect 404 (fail-closed default)

Try the platform behaviours: scale with update-service --desired-count 4 (watch two new ENIs register), then a rolling deploy — push :v2, register a new revision, update-service --task-definition lab-web:2, and watch deployments go PRIMARY/ACTIVE and back to one.

# 8. Teardown — order matters
aws ecs update-service --cluster lab --service web --desired-count 0
aws ecs delete-service --cluster lab --service web --force
aws elbv2 delete-load-balancer --load-balancer-arn $ALB && sleep 30
aws elbv2 delete-target-group --target-group-arn $TG
aws ec2 delete-security-group --group-id $TASK_SG && aws ec2 delete-security-group --group-id $ALB_SG
aws ecs delete-cluster --cluster lab
aws ecr delete-repository --repository-name lab-web --force
aws logs delete-log-group --log-group-name /ecs/lab-web
aws iam detach-role-policy --role-name labEcsExecRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
aws iam delete-role --role-name labEcsExecRole

Common mistakes & troubleshooting

First move in any ECS incident: read the stopped task, not the service page.

aws ecs list-tasks --cluster shopfast-prod --service-name orders --desired-status STOPPED
aws ecs describe-tasks --cluster shopfast-prod --tasks <task-arn> \
  --query 'tasks[0].{reason:stoppedReason,code:stopCode,containers:containers[].{name:name,exit:exitCode,reason:reason}}'

The playbook — symptom to fix:

Error strings you’ll meet in stoppedReason, decoded:

Best practices

1. One service = one repo, one task family, one SG, one task role, one dashboard. Uniformity is what makes twelve services operable by three people.
2. Pin images by immutable tag and treat task-definition revisions as the deploy ledger — rollback is update-service --task-definition orders:12, never a rebuild.
3. Always enable the deployment circuit breaker with rollback — one flag that converts bad deploys from incidents into log lines.
4. Health checks must be cheap and honest: /healthz without downstream calls for the ALB; deep dependency checks belong in alarms, not in the thing that kills tasks.
5. Scale asymmetrically (fast out, slow in), keep min_capacity ≥ 2 across AZs, pre-schedule known peaks.
6. Run ARM64 (Graviton) by default — ~20% cheaper for a one-line runtimePlatform change and a multi-arch build.
7. FARGATE_SPOT for workers, with a FARGATE base for the floor — never 100% Spot for anything user-facing.
8. Secrets via secrets[] only, execution role scoped per service, rotation wired to force a new deployment.
9. Every service gets its own log group with retention set (30–90 days) — unbounded log groups are the silent ₹ leak of container platforms.
10. Keep the synchronous call graph ≤ 2 hops; everything else through EventBridge/SQS with DLQs and queue-age alarms.
11. Standardize a golden dashboard per service (RunningVsDesired, CPU/mem p95, TG 5xx, p99, deployment events) and stamp it out via IaC.
12. Load-test the scaling policy, not just the app — the first flash sale is the wrong time to learn your cooldowns.

Security notes

The security model hangs on separating the two IAM roles and treating every service as its own trust boundary:

Fargate itself removes a whole class of concerns — no shared kernel between tenants (per-task micro-VM), no host agents to patch, task roles served from a task-scoped endpoint. The residual risk is almost entirely your image, your IAM scoping, and your egress rules.

Cost & sizing

Fargate bills per second (1-minute minimum) on task-level vCPU and memory. On-demand Linux in us-east-1 (Mumbai runs a few percent higher):

The reference stack priced (on-demand x86, 730 hrs/month):

Switch the APIs to ARM64 and the compute line drops ~20% (≈ $92/₹8,100). Always-on EC2 sized for peak (say 6 × m5.large) would run ~$420/month — Fargate wins not on unit price but because baseline is small and peak is rented by the minute.

Right-sizing rules: read Container Insights p95 CPU/memory after two weeks — CPU p95 < 25% means halve the vCPU tier (tune JVM MaxRAMPercentage before trusting memory graphs). The costs that sneak up: CloudWatch log ingestion ($0.50–0.67/GB dwarfs task cost for chatty debug logging), NAT data processing on image-heavy deploy days, and enhanced Container Insights on high-cardinality clusters.

Interview & exam questions

Mapped to AWS SAA-C03, DVA-C02, and DOP-C02:

1. Q: Task definition vs task vs service — what does each own? A: The task definition is the immutable versioned blueprint (image, CPU/mem, ports, roles, secrets). A task is one running copy with its own ENI. A service is the controller keeping desiredCount tasks healthy, registering them with target groups, and orchestrating deployments between task-definition revisions.

2. Q: Why does Fargate require awsvpc mode, and what’s the practical consequence? A: There’s no host to bridge through — each task gets its own ENI and private IP. Consequences: security groups apply per task (per service), target groups use ip targets, and each task consumes a subnet IP, so subnets must be sized for peak task count.

3. Q: Execution role vs task role — a task fails with ResourceInitializationError: unable to pull secrets. Which role and why? A: The execution role — it’s what the ECS agent uses before your code runs: ECR pull, CloudWatch log delivery, and resolving secrets[]. The task role is assumed by your application code for its AWS calls (S3, SQS, DynamoDB). Secrets-at-start failures are always execution-role (or endpoint/network) issues.

4. Q: When would you pick the EC2 launch type over Fargate? A: GPUs or special instance types, daemon-set-style agents, privileged containers, very large steady-state fleets where high utilization plus Savings Plans beats Fargate’s premium, or >200 GiB local storage. Otherwise Fargate’s zero node-ops usually wins.

5. Q: How does ALB path-based routing decide which microservice gets a request? A: The listener evaluates rules in ascending priority; the first rule whose conditions (path/host/header/query/source-IP, up to 5 values each) all match forwards to its target group. No match hits the default action — which should be a fixed 404, not a real service.

6. Q: What is ECS Service Connect and how does it differ from plain Cloud Map service discovery? A: Cloud Map DNS just publishes task IPs as A/SRV records — clients cache TTLs and get no retries or metrics. Service Connect injects an ECS-managed sidecar proxy that resolves namespace aliases (catalog:8080), load-balances across healthy tasks, retries, drains connections during deploys, and emits per-route CloudWatch metrics.

7. Q: Explain the ECS deployment circuit breaker. A: During a rolling deploy, if newly launched tasks repeatedly fail to reach steady state (threshold = 50% of desired count, min 3 max 200 failures), ECS marks the deployment FAILED and, with rollback=true, automatically redeploys the last steady-state task definition — no human in the loop.

8. Q: How do blue/green ECS deployments with CodeDeploy achieve near-instant rollback? A: CodeDeploy provisions the full green task set on a second target group, optionally exposes it on a test listener, shifts production listener traffic per the deployment config (canary/linear/all-at-once), and keeps blue running through the bake window — rollback is re-pointing the listener at blue, seconds not minutes.

9. Q: Your API is I/O-bound and CPU-based autoscaling never triggers. What do you scale on? A: ALBRequestCountPerTarget target tracking — it measures demand directly. For queue workers, scale on backlog per task (visible messages ÷ running tasks) as a custom metric; for known peaks add scheduled scaling.

10. Q: A secret was rotated in Secrets Manager but tasks still use the old password. Why? A: ECS resolves secrets[] once at task start and injects env vars; running tasks never re-read. You must force a new deployment (or have the app fetch from the API at runtime). Production rotation flows trigger update-service --force-new-deployment from the rotation Lambda.

11. Q: What breaks first when you scale a Fargate service from 3 to 50 tasks? A: In practice: subnet IP capacity (50 ENIs), the Fargate account vCPU quota, downstream DB connections (pools × tasks), and any Docker Hub-based image pulls hitting rate limits — which is why endpoints, RDS Proxy, quota monitoring, and ECR pull-through caches are part of the reference design.

Quick check

1. Which two AWS-managed touchpoints must the execution role reach for a task using Secrets Manager secrets and awslogs?
2. Default minimumHealthyPercent/maximumPercent for a rolling deployment — and what do they mean for a 4-task service?
3. Name the three requirements for http://catalog:8080 to resolve via Service Connect.
4. A task stops with exit code 137. What happened and what are the two standard fixes?
5. Which metric would you use to autoscale (a) an I/O-bound API and (b) an SQS worker?

Answers

1. Secrets Manager (GetSecretValue, plus KMS decrypt) and CloudWatch Logs (CreateLogStream/PutLogEvents) — reachable via NAT or the secretsmanager and logs VPC endpoints.
2. 100% / 200%: ECS may launch up to 4 extra tasks (8 total) during the deploy but never lets healthy count drop below 4.
3. A named portMapping in the task definition, both services attached to the same Cloud Map namespace with the server declaring the catalog:8080 client alias, and tasks (re)launched after Service Connect was enabled.
4. OOM kill — the container hit the task memory hard limit. Fix by right-sizing task memory and making the runtime container-aware (-XX:MaxRAMPercentage, --max-old-space-size).
5. (a) ALBRequestCountPerTarget target tracking; (b) backlog per task — ApproximateNumberOfMessagesVisible divided by running task count, published as a custom metric.

Glossary

• Task definition: Versioned JSON blueprint for a task — images, CPU/memory, ports, roles, secrets, logging.
• Task: A running instantiation of a task definition; one ENI; the unit of failure and billing.
• Service: ECS controller maintaining desiredCount tasks, wiring load balancers, running deployments.
• Fargate: Serverless compute engine for containers — per-task micro-VM, billed vCPU/GB-seconds.
• Capacity provider: Strategy target for where tasks land (FARGATE, FARGATE_SPOT, EC2 ASGs) with base/weight.
• awsvpc mode: Network mode giving each task its own ENI, private IP, and security groups.
• Target group: ALB construct holding registered task IPs and the health checks that gate traffic.
• Cloud Map: AWS service-discovery registry (DNS/HTTP namespaces) underpinning Service Connect.
• Service Connect: ECS-managed sidecar proxy providing stable service names, retries, draining, and traffic metrics.
• Execution role: IAM role the ECS agent uses to pull images, fetch secrets, and write logs before app start.
• Task role: IAM role the application code assumes for its own AWS API calls.
• Deployment circuit breaker: Rolling-deploy guard that fails and optionally auto-rolls-back bad revisions.
• Deregistration delay: Grace window (default 300 s) in which the ALB lets in-flight requests finish before a target fully leaves.
• DLQ (dead-letter queue): SQS queue receiving messages after maxReceiveCount failed processing attempts.

Next steps

• Wire up the hands-on foundation first if you haven’t: Your first container deployment — ECS & Fargate basics, then the production drill-down in ECS Fargate task networking, autoscaling and deployments.
• Still weighing runtimes? Work through ECS vs EKS vs Fargate: choose your container path with this article’s cost tables beside it.
• Go deeper on the edge tier — listener rules, TLS policies, and when API Gateway replaces path routing — in ALB vs NLB vs API Gateway compared.
• Solidify the network substrate (subnet sizing for ENI-per-task, SG referencing) with AWS VPC, subnets and security groups explained.
• Extend the async backbone with Lambda event-driven patterns and pick per-service stores confidently with RDS vs DynamoDB vs Aurora compared.