AWS ECS Fargate in Production: When I Use Serverless Containers Instead of Kubernetes

Why Fargate is attractive

Not every container platform needs Kubernetes.

Fargate lets teams run containers without managing worker nodes.

Conceptually:

ALB
 |
ECS Service
 |
Fargate Tasks
 |
Container

AWS handles the underlying compute capacity.

I use/evaluate this model when the workload is containerized but the organization does not need Kubernetes APIs/ecosystem.

Task definition

{
  "family": "booking-service",
  "networkMode": "awsvpc",
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "cpu": "1024",
  "memory": "2048",
  "containerDefinitions": [
    {
      "name": "booking",
      "image": "123456789.dkr.ecr.ap-south-1.amazonaws.com/booking:2026.09.01",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 8080,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/prod/booking",
          "awslogs-region": "ap-south-1",
          "awslogs-stream-prefix": "service"
        }
      }
    }
  ]
}

Networking

With awsvpc, each task receives network identity inside the VPC.

I normally place application tasks in private subnets and expose only the ALB/API boundary publicly.

Internet
  |
ALB public
  |
private subnets
  |
Fargate tasks
  |
RDS / Redis / services

Secrets

Task execution/runtime IAM roles should allow only required secrets.

Application role:

read specific Secrets Manager path
publish specific SNS/SQS/Kafka resource
access only required S3 bucket

I do not use one broad AWS role for every service.

Autoscaling

Target tracking can scale tasks from CPU or custom metrics.

But CPU is not always the correct metric.

For queue worker:

messages visible / active tasks

is more meaningful.

For APIs:

request count
latency
CPU

can be combined.

Fargate vs EKS

I lean Fargate when:

• workload is straightforward;
• operational simplicity is valuable;
• Kubernetes portability/ecosystem is unnecessary;
• team does not want node/cluster administration.

I lean EKS when:

• many workloads share platform conventions;
• Kubernetes tooling is already standard;
• custom controllers/operators are needed;
• service mesh/advanced scheduling matters;
• multi-cloud/on-prem consistency matters.

Deployment

ECS Service rolling deployment can replace tasks gradually.

For higher-risk changes I can combine CodeDeploy with blue-green.

The same requirements remain:

• readiness/health;
• backward-compatible schema;
• graceful termination;
• monitoring by task definition/version.

Cost

Fargate trades some unit-cost premium for operational simplicity.

I compare:

steady utilization
number of services
node management effort
autoscaling variability
reserved/spot options
platform team cost

not only vCPU price.

Production checklist

• Private subnets.
• ALB health checks.
• Least-privilege task role.
• Secrets Manager/Parameter Store.
• CloudWatch structured logs.
• CPU/memory right-sizing.
• Service autoscaling.
• Graceful SIGTERM.
• Immutable ECR image.
• Deployment alarms.
• VPC egress cost visibility.

FAQ

Is Fargate Kubernetes?

No. ECS Fargate uses ECS APIs. EKS can also run some pods on Fargate profiles, which is a different configuration.

Is Fargate cheaper?

Not always. It can reduce operational cost while compute unit cost may be higher than well-utilized EC2 nodes.

Fargate or Lambda?

Fargate is suitable for long-running container services/workers. Lambda is event/function-oriented with a different execution model.

Related architecture guides

• Amazon EKS

• Kubernetes Primitives

  Architect's final take

  I choose Fargate when removing cluster/node operations creates more value than adopting the full Kubernetes platform.