AWS Compute: EC2, Lambda, ECS and EKS — Which One to Choose?

You have a workload — an API, a batch job, a queue consumer, a website — and AWS gives you at least five credible ways to run it: a raw EC2 instance you own end to end, a Lambda function with no server in sight, an ECS task on AWS’s own orchestrator, an EKS pod on managed Kubernetes, or any of the container options backed by Fargate so you never touch a node. Pick wrong and you pay for it twice: once in the monthly bill, and again every week in the operational toil of patching, scaling and debugging a platform that was never the right shape for the job. The wrong default — “spin up an EC2 instance, it’s what we know” — is the single most expensive habit on AWS, because an idle m5.large costs the same whether it serves a million requests or zero, and someone still has to patch its kernel.

This is the decision guide, written the way a 22-year architect actually reasons about it: not “which is best” (none is best) but “which axis does this workload live on” — how much of the stack you must control, how the traffic arrives (steady, bursty, event-driven, scheduled), how long each unit of work runs, and how much undifferentiated heavy lifting you are willing to hand to AWS. We walk every service option by option: EC2’s instance families and purchase models, Lambda’s runtimes and its hard 15-minute / 10 GB ceilings, ECS’s two launch types and task-definition knobs, EKS’s control-plane-plus-data-plane split and its per-cluster hourly charge, and Fargate’s per-second vCPU/GB billing. Every configuration gets an aws CLI snippet and a Terraform snippet, and because you will come back to this mid-design, every comparison — instance families, runtimes, launch types, limits, failure modes, prices — is a table you can scan in ten seconds.

By the end you will stop treating EC2 as the answer to every question. You will look at a workload and know within a minute whether it wants a function (event-driven, sub-15-minute, spiky), a task (a container with no Kubernetes ambitions), a pod (you already run Kubernetes and want the API and ecosystem), or a real instance (GPU, Windows licensing, a kernel module, sustained 24×7 load where reserved capacity is cheapest). And when the workload is genuinely on the fence, you will know the exact knobs — cold start, SNAT, node-group sizing, Savings Plans — that tip the decision.

What problem this solves

The pain is concrete and recurring. A team ships a service on the compute they’re comfortable with, not the compute that fits, and the mismatch shows up as either a bloated bill or a stream of 2 a.m. pages. A cron job that runs for forty seconds once an hour sits on a 24×7 t3.medium — you pay for ~720 hours a month to do ~12 hours of work. A bursty image-thumbnailer runs on a fixed fleet that’s over-provisioned for the median and still falls over at peak. A five-service product adopts EKS because a conference talk said to, then discovers it now owns a Kubernetes control plane’s worth of upgrades, add-on CVEs and IRSA debugging — for five services that ECS would have run with a fraction of the surface area.

What breaks without a deliberate choice: cost creeps (idle instances, over-provisioned fleets, a $0.10/hour EKS cluster per environment that nobody decommissions); operational load balloons (OS patching, AMI rebuilds, node-group rotations, control-plane version skew); and reliability suffers in the gaps the team didn’t design for (a Lambda that quietly hits its 15-minute timeout on a large input, an ECS service with no health check that ships a crash-looping task, an EKS pod stuck Pending because the cluster autoscaler can’t get capacity in the right AZ). None of these are exotic failures — they’re the default outcome of picking compute by familiarity.

Who hits this: essentially every team that runs more than one kind of workload. It bites hardest on teams migrating a monolith (everything lands on EC2 because that’s the lift-and-shift path, and nothing ever moves off), startups that adopt Kubernetes before they have the headcount to operate it, and cost-sensitive shops that never revisit the first instance they launched. The fix is not a tool — it’s a model: match the lifecycle of the work to the billing and operational model of the service. The rest of this article is that model, enumerated.

To frame the whole field before the deep dive, here is every compute service this article covers, the unit you pay for, what AWS manages versus what you manage, and the workload shape it fits:

Learning objectives

By the end of this article you can:

• Map any workload to EC2, Lambda, ECS, EKS or Fargate using its lifecycle (event-driven, bursty, steady, scheduled, long-running) and your control requirement, not by habit.
• Read the EC2 instance-family taxonomy (the letter/number/suffix scheme) and pick the right family — general purpose, compute, memory, storage, accelerated — and the right purchase model (On-Demand, Reserved, Savings Plan, Spot, Dedicated).
• State Lambda’s hard limits from memory — 15-minute timeout, 10 GB memory, 10 GB ephemeral /tmp, 6 MB synchronous payload, 250 MB unzipped package, 1,000 default concurrency — and design around each.
• Choose between ECS launch types (EC2 vs Fargate) and configure a task definition’s CPU/memory, networking mode, IAM roles and health checks correctly.
• Decide between ECS and EKS honestly (operational surface area vs Kubernetes API/portability) and size an EKS data plane with managed node groups, Fargate profiles or Karpenter.
• Use Fargate where it earns its premium and fall back to EC2-backed compute where bin-packing or reserved pricing wins.
• Right-size and cost-model each option in INR/USD, exploit the relevant free tier, and name the price levers (Graviton, Spot, Savings Plans, memory tuning) that move the bill most.

Prerequisites & where this fits

You should be comfortable with the AWS basics: an AWS account and IAM (roles, policies — every compute service assumes an execution role or instance profile to call other services), the VPC model (subnets, security groups, public vs private), and how to run the aws CLI with credentials. You should know what a container image is (a packaged filesystem + entrypoint, built from a Dockerfile, stored in a registry like ECR) and roughly what Kubernetes does (declarative orchestration of pods across nodes), even if you’ve never operated it. Familiarity with Terraform (resource, provider, terraform apply) helps because every example pairs a CLI command with IaC.

This sits at the foundation of the AWS compute track. It’s the decision upstream of the deeper guides: once you’ve chosen containers, the ECS vs EKS vs Fargate container path goes one level deeper on orchestration, and once you’ve chosen serverless, Lambda event-driven patterns covers the integration shapes. The network your compute lands in is VPC subnets and security groups; the placement across Regions and Availability Zones decides your blast radius; the front door is usually an ALB, NLB or API Gateway; and the identity every service assumes comes from Organizations and IAM foundations. The state your compute talks to lives in RDS, DynamoDB or Aurora and S3 storage classes.

A quick map of who owns what during design and operations, so the trade-off is concrete:

Core concepts

Five mental models make every later choice obvious.

Compute is a control-versus-convenience dial, not a ladder. EC2, ECS, EKS and Lambda are not “beginner to advanced” — they’re points on a single axis: how much of the stack do you operate yourself. At one end, EC2 hands you a bare virtual machine and you own everything above the hypervisor (OS, patches, runtime, scaling). At the other, Lambda hands you a function signature and AWS owns everything else. ECS and EKS sit in the middle as container orchestrators — they schedule your containers onto compute and keep the desired count running — with Fargate sliding the same orchestrators toward the Lambda end by removing the servers. You don’t climb this; you pick the point where the control you need meets the convenience you want.

The billing unit encodes the right workload shape. EC2 bills per instance-second (60-second minimum) regardless of utilisation — so it’s cheapest for work that keeps the instance busy, and wasteful for idle. Lambda bills per GB-second of execution plus per request — you pay only while code runs, so it’s cheapest for spiky, intermittent work and ruinous for something that runs flat-out 24×7. Fargate bills per second of provisioned vCPU and GB — between the two. EKS adds a fixed $0.10/hour per cluster for the managed control plane on top of whatever data plane you choose. Match the traffic shape to the meter: steady → instances; spiky/event → functions; in-between containerised → tasks.

A container needs an orchestrator, and the orchestrator needs a data plane. A container image is inert; something must place it on a host, restart it when it dies, scale the count, and wire it to networking. That “something” is the orchestrator — ECS (AWS’s own, simpler) or EKS (managed Kubernetes, richer/portable). Each orchestrator runs your containers on a data plane: either EC2 nodes you own (you patch and scale them, but get bin-packing and EC2/Spot pricing) or Fargate (AWS owns the host; you pay per task/pod, no nodes to manage). “ECS vs EKS” is the control-plane choice; “EC2 vs Fargate” is the data-plane choice — they’re orthogonal, and you make both.

Limits are the design, not the fine print. Lambda’s limits define what it can’t do: a request that takes 16 minutes will never finish (15-minute hard ceiling), a job needing 12 GB RAM can’t run (10 GB max), a sync response over 6 MB will be rejected. These aren’t tunables — they’re walls. EC2 has no such walls (you can run a 24-hour job on a 768 GB instance) but trades that freedom for ownership of the whole machine. Knowing each service’s hard limits up front turns “we’ll figure it out” into “this workload is disqualified from Lambda, so it’s a task or an instance.”

Cold start is the tax on scaling from zero. Anything that can scale to zero — Lambda, Fargate, App Runner, Karpenter-provisioned nodes — pays a startup cost the first time a request lands with no warm capacity: the runtime initialises, the image is pulled, the connection pool primes. Lambda cold starts are tens to hundreds of milliseconds (seconds for large packages or VPC-attached functions historically); a new Fargate task takes tens of seconds to pull and start; a new EC2 node under an autoscaler takes a minute or more. An always-on EC2 instance never pays this — that’s part of what its idle cost buys. Whether cold start matters is a property of your latency budget, and it’s often the knob that decides a borderline case.

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary at the end repeats these for lookup; this table is the mental model side by side:

The decision table — pick from the symptom

When you’re staring at a workload and not sure where it goes, match its dominant characteristic in the left column and read across. This is the whole article compressed into one lookup:

EC2 — the full-control option, option by option

EC2 gives you a virtual machine and gets out of the way. That freedom is the point and the cost: you choose the instance family (the CPU:memory:accelerator ratio), the size within it, the AMI (and thus the patch level you now own), the purchase model (which swings the price by up to ~90%), and the scaling (you write the Auto Scaling Group policy). Reach for EC2 when you need something the managed options can’t give: a specific OS or kernel module, a GPU, BYOL Windows/Oracle licensing, persistent local NVMe, or simply the lowest per-compute cost for a workload that runs flat-out 24×7.

Instance families — read the naming scheme

EC2 instance type names encode everything: m5.large = family m (general purpose), generation 5, size large. Suffixes refine it: g = Graviton (ARM, cheaper per vCPU), n = enhanced networking, d = local NVMe, a = AMD. Pick the family by the workload’s bottleneck (CPU-bound → c, RAM-bound → r/x, GPU → g/p), then the size by how much you need.

The t family deserves a warning: it runs on CPU credits. You bank credits while below a baseline and spend them to burst above it; run out and you’re throttled to the baseline (e.g. ~20% of a vCPU for t3.medium) — unless you enable T3 Unlimited, which lets you burst beyond credits for a surcharge. A t3 instance that’s busy 24×7 is the wrong choice (it’ll throttle or surcharge); move to m.

Purchase models — the 90% price lever

How you buy the same instance changes the price more than which instance you pick. On-Demand is the flexible default; commit to usage and you save up to ~72%; bid on spare capacity (Spot) and save up to ~90% with the risk of a 2-minute eviction notice.

Launch a basic instance and attach an instance profile:

aws ec2 run-instances \
  --image-id ami-0abcd1234efgh5678 \
  --instance-type m7g.large \
  --iam-instance-profile Name=app-instance-profile \
  --security-group-ids sg-0a1b2c3d \
  --subnet-id subnet-0e1f2a3b \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=app-prod}]'

resource "aws_instance" "app" {
  ami                    = data.aws_ami.al2023.id
  instance_type          = "m7g.large"   # Graviton: ~20% cheaper per vCPU
  iam_instance_profile   = aws_iam_instance_profile.app.name
  vpc_security_group_ids = [aws_security_group.app.id]
  subnet_id              = aws_subnet.private_a.id
  tags                   = { Name = "app-prod" }
}

Auto Scaling — you own the policy

A single instance is a single point of failure. Production EC2 runs in an Auto Scaling Group (ASG) spanning ≥2 AZs, fronted by a load balancer, scaling on a target metric. You write the policy — that’s the cost of control. The scaling-policy choices:

Storage choices — durable vs ephemeral

An instance’s disk is a decision, not a given. Get it wrong and you either lose data on a reboot or pay for IOPS you don’t need.

The trap: instance store looks free and fast, and it is — until someone reboots the instance and the data is gone. Only put reconstructable data on it.

EC2 limits and gotchas that bite

Lambda — serverless functions, and the walls you design around

Lambda runs your code in response to an event with no server to manage: you upload a handler, pick a runtime and a memory size, and AWS executes it on demand, scaling from zero to thousands of concurrent executions automatically. You pay only while code runs (GB-second) plus per request. It is the right answer for event-driven work (an S3 upload, a queue message, an API request, a schedule) that is short (seconds to a few minutes) and spiky — and the wrong answer for anything long-running, steady-state, or needing a fixed environment, because Lambda’s limits are hard walls, not knobs.

The hard limits — memorise these

These define what Lambda cannot do. There is no setting to exceed them; a workload that needs more is disqualified.

Runtimes — managed or your own

Lambda gives you a managed runtime or lets you bring a container image / custom runtime.

Concurrency and cold starts — the two performance knobs

Lambda scales by running more concurrent executions. Two controls shape its behaviour under load and its latency on a cold path.

What actually drives cold-start latency, and how to cut it:

Invocation models — how the event reaches the function

How Lambda is invoked changes retry behaviour, error handling and the payload limit you’re bound by. Three models:

The retry column matters: an async failure silently retries twice and then drops to a dead-letter queue (if you configured one) — no DLQ means lost events. A poll-based SQS failure returns the batch to the queue, so a poison message can loop forever without a redrive policy.

Create a function and wire a trigger:

aws lambda create-function \
  --function-name thumbnailer \
  --runtime python3.12 --architectures arm64 \
  --handler app.handler --timeout 60 --memory-size 1024 \
  --role arn:aws:iam::111122223333:role/thumbnailer-exec \
  --zip-file fileb://function.zip

# Let S3 invoke it on object-created (event-driven, the canonical Lambda shape)
aws lambda add-permission --function-name thumbnailer \
  --statement-id s3invoke --action lambda:InvokeFunction \
  --principal s3.amazonaws.com --source-arn arn:aws:s3:::uploads-bucket

resource "aws_lambda_function" "thumbnailer" {
  function_name = "thumbnailer"
  runtime       = "python3.12"
  architectures = ["arm64"]   # Graviton: cheaper GB-second
  handler       = "app.handler"
  timeout       = 60          # seconds; hard ceiling is 900
  memory_size   = 1024        # MB; also scales vCPU
  role          = aws_iam_role.thumbnailer_exec.arn
  filename      = "function.zip"
}

The cost trap: Lambda is not always cheaper

Lambda’s “pay only when it runs” is a gift for spiky work and a trap for steady work. A function pinned at high concurrency 24×7 can cost far more than the equivalent always-on instance. The break-even reasoning:

ECS — AWS-native containers, two launch types

ECS is AWS’s own container orchestrator: you describe a task (one or more containers, their CPU/memory, ports, IAM role and health check in a task definition), and a service keeps a desired number of those tasks running, replacing failures and integrating with a load balancer. It’s simpler than Kubernetes — fewer concepts, no control-plane upgrades, deep AWS integration — and the control plane is free; you pay only for the data plane. The big fork is the launch type: run tasks on EC2 nodes you own (bin-packing, Spot, GPU, lowest cost at scale) or on Fargate (no nodes; pay per task-second).

EC2 vs Fargate launch type — the data-plane decision

Rule of thumb: start on Fargate (no node fleet to operate), move specific high-density or GPU workloads to EC2-backed capacity when bin-packing or reserved/Spot pricing demonstrably wins.

Task definition — the knobs that matter

The task definition is the blueprint. Get these right or the task won’t place, won’t reach its dependencies, or won’t be replaced when it crashes.

Register a Fargate task definition and run a service:

aws ecs register-task-definition \
  --family api --network-mode awsvpc \
  --requires-compatibilities FARGATE --cpu 512 --memory 1024 \
  --execution-role-arn arn:aws:iam::111122223333:role/ecsTaskExecutionRole \
  --task-role-arn arn:aws:iam::111122223333:role/api-task-role \
  --container-definitions '[{
    "name":"api","image":"111122223333.dkr.ecr.ap-south-1.amazonaws.com/api:1.4.2",
    "portMappings":[{"containerPort":8080}],
    "healthCheck":{"command":["CMD-SHELL","curl -f http://localhost:8080/healthz || exit 1"],
      "interval":30,"timeout":5,"retries":3},
    "logConfiguration":{"logDriver":"awslogs","options":{
      "awslogs-group":"/ecs/api","awslogs-region":"ap-south-1","awslogs-stream-prefix":"api"}}
  }]'

resource "aws_ecs_service" "api" {
  name            = "api"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 3
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = aws_subnet.private[*].id
    security_groups  = [aws_security_group.api.id]
    assign_public_ip = false
  }
  load_balancer {
    target_group_arn = aws_lb_target_group.api.arn
    container_name   = "api"
    container_port   = 8080
  }
}

Networking modes — and why Fargate forces awsvpc

The networkMode decides how containers get IPs and how they’re reachable. Fargate only supports one of them, which removes the choice but also the foot-guns.

awsvpc is the modern default — a per-task ENI gives each task its own security group and lets the ALB target task IPs directly. The cost is IP consumption: a service running 200 tasks needs 200 IPs in its subnets, so size the CIDR accordingly or you’ll hit the PROVISIONING-stuck failure above.

Service autoscaling and capacity providers

ECS scales the service (task count) via Application Auto Scaling, and on EC2 you also scale the node fleet via a capacity provider. The two layers:

ECS error reference — what blocks a task

EKS — managed Kubernetes when you actually need it

EKS is managed Kubernetes: AWS runs the control plane (the API server, etcd, scheduler — across 3 AZs, patched and highly available) for a flat $0.10/hour per cluster, and you run the data plane (the nodes or Fargate that host your pods). You get the full Kubernetes API, the CNCF ecosystem (Helm, operators, service mesh, the whole tooling universe) and cluster portability across clouds. You also get Kubernetes’ operational surface: version upgrades on both planes, add-on management (CNI, CoreDNS, kube-proxy, CSI drivers), IRSA/Pod Identity for AWS access, and a genuinely steeper learning curve. Choose EKS when you already run Kubernetes, need its API/ecosystem, or require multi-cloud portability — not because it’s fashionable.

ECS vs EKS — the honest comparison

This is the decision that costs teams the most when they get it wrong. EKS is more powerful and more work; ECS is simpler and AWS-only.

EKS data-plane options — how you run pods

EKS pods run on one of three data planes (often mixed in one cluster):

EKS scaling — two independent loops

Kubernetes scales pods and nodes separately; you wire both.

Create a cluster and a managed node group (CLI shown via eksctl-style and Terraform):

# Control plane (AWS manages it across 3 AZs)
aws eks create-cluster --name prod \
  --role-arn arn:aws:iam::111122223333:role/eksClusterRole \
  --resources-vpc-config subnetIds=subnet-a,subnet-b,subnet-c \
  --kubernetes-version 1.30

# A managed node group for the data plane
aws eks create-nodegroup --cluster-name prod --nodegroup-name general \
  --node-role arn:aws:iam::111122223333:role/eksNodeRole \
  --subnets subnet-a subnet-b subnet-c \
  --instance-types m7g.large --scaling-config minSize=2,maxSize=10,desiredSize=3

resource "aws_eks_cluster" "prod" {
  name     = "prod"
  role_arn = aws_iam_role.eks_cluster.arn
  version  = "1.30"
  vpc_config { subnet_ids = aws_subnet.private[*].id }
}

resource "aws_eks_node_group" "general" {
  cluster_name    = aws_eks_cluster.prod.name
  node_group_name = "general"
  node_role_arn   = aws_iam_role.eks_node.arn
  subnet_ids      = aws_subnet.private[*].id
  instance_types  = ["m7g.large"]   # Graviton nodes
  scaling_config { min_size = 2, max_size = 10, desired_size = 3 }
}

EKS failure reference — the classics

Fargate — the serverless data plane

Fargate isn’t a separate orchestrator — it’s a serverless data plane for ECS and EKS. Instead of running and patching EC2 nodes, you ask for a task or pod and AWS provisions an isolated micro-VM sized exactly to your request, billed per-second of vCPU and memory. You never see the host. It removes the entire node-management burden (no AMIs, no patching, no cluster autoscaler for nodes, no SSH) at a per-compute premium over equivalently-utilised EC2. It earns that premium when your load is variable, your team is lean, or your density is low; it loses to EC2 when you can pack a node tightly and buy it reserved or Spot.

Valid Fargate task sizes are fixed combinations — you can’t ask for arbitrary CPU:memory:

Architecture at a glance

The diagram below traces a single product across all the compute homes it might legitimately use — not “pick one” but “place each workload on the service whose billing and operational model fits its lifecycle.” Follow it left to right as the request and event path. Traffic enters through the edge and routing zone (CloudFront for static/cache, an ALB or API Gateway as the front door). The synchronous, request-shaped work lands in the request compute zone: a containerised API on ECS Fargate (no nodes to run) for the steady microservice, and a thin Lambda behind API Gateway for the spiky, event-shaped endpoints. Heavier or special work sits in the specialised compute zone: an EC2 Auto Scaling fleet for the GPU/Windows/licensed workload that needs a real machine, and an EKS cluster for the platform team that already lives in Kubernetes. Asynchronous work flows through the event & async zone — an SQS queue and EventBridge decoupling producers from a fleet of Lambda consumers and Fargate workers — and everything emits logs and metrics to the observability zone (CloudWatch), which is where every failure below is confirmed.

The numbered badges mark the five places a compute choice most often goes wrong: a Lambda hitting its 15-minute wall, an ECS task that can’t pull its image, an EKS pod stuck Pending with no node, an EC2 fleet bleeding money while idle, and a Fargate task rejected for an invalid CPU:memory pair. The legend narrates each as symptom · how to confirm · fix. Read the picture as the map: arrival path across the top, the compute menu in the middle tiers, and the diagnostic pins on the exact hop where each mistake bites.

Real-world scenario

FreightLink, a logistics SaaS in Pune, ran everything on EC2 — eighteen m5.large and c5.xlarge instances across two AZs, hand-rolled with Ansible, patched on a monthly maintenance window that nobody enjoyed. Their AWS bill was ₹6.8 lakh/month and climbing, and a quarterly review found the embarrassing truth: average fleet CPU was 14%. They were paying for a 24×7 fleet sized for a peak that lasted ninety minutes a day, and the on-call rotation spent most of its energy on OS patching and capacity guesswork rather than the product.

The platform lead ran the workloads through exactly the model in this article — match the lifecycle to the meter — and re-homed them one class at a time. The shipment-label generator, a CPU job that ran for ~40 seconds whenever a label was requested (a few thousand times a day, in bursts), was the worst fit for an always-on instance: it moved to Lambda at 1,024 MB with arm64, triggered by SQS. It now costs about ₹4,000/month and scales to zero between bursts — down from a dedicated c5.xlarge running flat-out 24×7. The customer-facing API and tracking services, six stateless microservices with steady mid-day traffic, moved to ECS on Fargate behind an ALB, sized per service (0.5–1 vCPU each) with service autoscaling on ALB requests-per-target. Deploys that used to mean an Ansible run and a held breath became a terraform apply that rolled tasks with zero downtime, and the team stopped SSHing into anything.

Two workloads stayed close to the metal — correctly. The route-optimisation engine used a GPU and a licensed solver, so it stayed on EC2 (g5.xlarge, now on a 1-year Compute Savings Plan because its load was steady). And the data-science platform the analytics team had already built on Kubernetes stayed on EKS — re-platforming it to ECS would have thrown away their Helm charts and operators for no benefit; instead they moved its node group to Graviton and Spot for the batch pools. The one stumble: the first Lambda cut over with the default 3-second timeout inherited from a copy-pasted template, and large multi-page labels intermittently failed with Task timed out after 3.00 seconds. Confirmed in CloudWatch Logs in two minutes, fixed by raising the timeout to 60 s and the memory (which also raised vCPU, halving the runtime). Six weeks later the bill was ₹3.9 lakh/month — a 43% cut — fleet CPU on the remaining EC2 was a healthy 55%, and the monthly patching window was gone for everything except the two instance-based workloads that genuinely needed it. The lesson FreightLink internalised: EC2 wasn’t wrong, defaulting to it was.

Advantages and disadvantages

Each service is a bundle of trade-offs; the table makes them explicit, then the prose says when each side matters.

Control matters when the workload has a hard requirement the managed options can’t satisfy — a kernel module, a GPU, BYOL licensing, persistent local NVMe, or sustained 24×7 load where Reserved EC2 is simply the cheapest place to run. There, EC2’s “disadvantages” are the price of admission and worth paying. Convenience matters when the workload is ordinary and your scarcest resource is engineering time: a stateless API, a queue consumer, an event handler. There, Lambda or Fargate’s premium buys back the weeks you’d otherwise spend patching and scaling — almost always a good trade for a lean team. Portability (EKS) matters when you genuinely run multi-cloud or have deep Kubernetes investment; it’s a real cost you should only pay for a real need, not a hypothetical one. The failure mode in every direction is the same: choosing the bundle for its headline feature while ignoring the column of costs that comes attached.

Hands-on lab

A free-tier-friendly walk-through that deploys the same trivial container as a Fargate task and the same logic as a Lambda, so you feel the two models side by side. Region ap-south-1. Tear everything down at the end.

1. Set up variables and a log group.

export AWS_REGION=ap-south-1 ACCT=$(aws sts get-caller-identity --query Account --output text)
aws logs create-log-group --log-group-name /lab/compute || true

2. Deploy a Lambda (the event/glue model). A tiny function that returns a greeting — stands in for “event-shaped work.”

cat > index.py <<'PY'
def handler(event, context):
    return {"statusCode": 200, "body": "hello from Lambda"}
PY
zip function.zip index.py

# Minimal execution role (trust + basic logging) — created once
aws iam create-role --role-name lab-lambda-exec \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name lab-lambda-exec \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
sleep 10  # let the role propagate

aws lambda create-function --function-name lab-hello \
  --runtime python3.12 --architectures arm64 --handler index.handler \
  --timeout 10 --memory-size 128 \
  --role arn:aws:iam::${ACCT}:role/lab-lambda-exec \
  --zip-file fileb://function.zip

3. Invoke it and watch it scale from zero.

aws lambda invoke --function-name lab-hello out.json && cat out.json
# Expected: {"statusCode": 200, "body": "hello from Lambda"}

4. Deploy the same idea as a Fargate task (the container model). Use a public amazonlinux image that prints and exits — stands in for “container-shaped work.”

aws ecs create-cluster --cluster-name lab-cluster

aws ecs register-task-definition --family lab-hello \
  --requires-compatibilities FARGATE --network-mode awsvpc \
  --cpu 256 --memory 512 \
  --execution-role-arn arn:aws:iam::${ACCT}:role/ecsTaskExecutionRole \
  --container-definitions '[{"name":"hello","image":"public.ecr.aws/amazonlinux/amazonlinux:2023",
    "command":["/bin/sh","-c","echo hello from Fargate"],"essential":true,
    "logConfiguration":{"logDriver":"awslogs","options":{
      "awslogs-group":"/lab/compute","awslogs-region":"ap-south-1","awslogs-stream-prefix":"hello"}}}]'

# Run one task in a public subnet (replace subnet/SG with yours)
aws ecs run-task --cluster lab-cluster --launch-type FARGATE \
  --task-definition lab-hello \
  --network-configuration 'awsvpcConfiguration={subnets=[subnet-xxxx],securityGroups=[sg-xxxx],assignPublicIp=ENABLED}'

5. Confirm the Fargate task ran by reading its log stream in CloudWatch (/lab/compute), where you’ll see hello from Fargate. Notice the difference you just felt: the Lambda returned in milliseconds with nothing to provision; the Fargate task took tens of seconds to pull and start — that’s the cold-start tax of the container path, and the per-task isolation you pay for.

6. Teardown — leave nothing billing.

aws lambda delete-function --function-name lab-hello
aws ecs delete-cluster --cluster lab-cluster
aws logs delete-log-group --log-group-name /lab/compute
aws iam detach-role-policy --role-name lab-lambda-exec \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam delete-role --role-name lab-lambda-exec

Common mistakes & troubleshooting

The real failure modes, each as symptom → root cause → how to confirm → fix. These are the ones that actually page teams.

The meta-mistake behind half of these is choosing the service by familiarity and then fighting its model: forcing long work into Lambda (1, 3), running spiky work on always-on EC2 (10), or adopting EKS without budgeting for its control-plane cost and upgrade toil (12). Re-home the workload and the symptom disappears.

Best practices

• Choose by lifecycle, not by habit. Event-driven & short → Lambda; containerised with no K8s need → ECS; already on Kubernetes → EKS; OS/GPU/licensing/sustained → EC2. Re-derive it per workload.
• Default the data plane to Fargate, move to EC2-backed only when bin-packing or Reserved/Spot pricing demonstrably wins. Don’t run a node fleet you don’t need.
• Prefer Graviton (arm64) for Lambda, Fargate and EC2 wherever your dependencies support it — ~20% cheaper and often faster. Recompile native deps and test.
• Buy commitment for steady spend. Compute Savings Plans cover EC2, Fargate and Lambda; cover your steady baseline and leave the spiky top On-Demand/Spot.
• Make fault-tolerant work run on Spot (batch, CI, stateless workers) with checkpointing/idempotency and a capacity-optimized allocation strategy.
• Always set health checks (ECS container health + ALB target health; EKS readiness/liveness probes). No health check means you ship crash-looping tasks to users.
• Set Lambda timeouts and memory deliberately — never ship the default 3 s; raise memory to raise vCPU for CPU-bound work (it can be cheaper by finishing faster).
• Cap blast radius with reserved concurrency on functions that hit a fragile downstream (a small RDS), so one function can’t exhaust connections.
• Keep one cluster, many namespaces on EKS where isolation allows — each extra cluster is another $0.10/hr plus another upgrade to run.
• Right-size on a schedule. Review fleet/utilisation quarterly; instances outlive their workloads and idle vCPUs are pure waste.
• Push everything to CloudWatch (and X-Ray for traces). The first move in every failure above is reading a log; make sure there is one.

Security notes

• Least-privilege roles per workload. Every compute service assumes an identity: EC2 → instance profile, Lambda → execution role, ECS → task role, EKS → IRSA/Pod Identity. Scope each to exactly the APIs that workload calls — never a wildcard *. The task role (your app’s identity) is distinct from the execution role (pull image / write logs); don’t conflate them.
• Run compute in private subnets. API/worker tasks, functions touching VPC resources, and nodes belong in private subnets with egress via NAT or, better, VPC endpoints (for ECR, S3, Secrets Manager, CloudWatch) so traffic to AWS APIs never leaves the AWS backbone — which also fixes the most common CannotPullContainerError / ResourceInitializationError.
• Inject secrets, never bake them. Pull from Secrets Manager or SSM Parameter Store at runtime (ECS secrets, Lambda env from Secrets, EKS External Secrets) — never put credentials in an AMI, image layer or environment file in source control.
• Patch what you own. AWS patches the Lambda runtime and the Fargate host; you patch EC2 AMIs and EKS/ECS-EC2 nodes. Automate AMI rebuilds and node rotation, and track EKS add-on and Kubernetes-version CVEs — an unpatched node is your exposure, not AWS’s.
• Encrypt at rest and in transit. EBS volumes and ephemeral storage encrypted with KMS; TLS on every front door (ALB/API Gateway); mTLS inside the mesh where the threat model warrants it.
• Lock down the EKS API. Make the control-plane endpoint private (or tightly IP-restricted), use RBAC and IAM together, and disable anonymous access; the Kubernetes API is a high-value target.
• Isolate Spot/preemptible blast radius. Don’t run security-sensitive, hard-to-checkpoint work on Spot where a 2-minute eviction could interrupt a partial sensitive operation.

Cost & sizing

The bill is driven by what you pay per unit times how much you run idle. The levers that move it most, ordered by impact:

Rough figures (ap-south-1 / Mumbai, On-Demand, indicative — always check the calculator):

Free-tier anchors worth knowing: EC2 750 hours/month of t2.micro/t3.micro for 12 months; Lambda a perpetual 1M requests + 400,000 GB-seconds/month; EKS has no free tier — the $0.10/hr starts immediately, which is exactly why idle non-prod clusters quietly add up. Size by starting small and scaling on a real metric: for EC2/ECS, pick the smallest type that holds your p95 with headroom and let autoscaling handle peaks; for Lambda, set memory by profiling (the cheapest run is often not the smallest memory, because higher memory finishes faster).

Interview & exam questions

1. When would you choose Lambda over ECS Fargate for an HTTP API? When traffic is spiky or low-average and each request is short (well under 15 minutes), so scaling to zero between bursts saves money and you want zero infrastructure to operate. Choose Fargate when the service is steady, needs a long-lived process, has heavy/large dependencies, or you want consistent low latency without cold-start management. (AWS SAA-C03.)

2. What are Lambda’s hard limits, and which is most often hit first? 15-minute max timeout, 10 GB max memory, 10 GB ephemeral /tmp, 6 MB synchronous payload, 250 MB unzipped package (10 GB as a container image), and 1,000 default concurrency per region. In practice the timeout and concurrency limits bite first — long jobs silently fail at 15 minutes, and bursty workloads throttle at 1,000.

3. ECS or EKS for a five-service startup with a three-person platform team? ECS. EKS adds a $0.10/hr-per-cluster cost and, more importantly, the full Kubernetes operational surface — version upgrades, add-on CVEs, CNI/IRSA debugging — which a three-person team servicing five services can’t justify. Choose EKS only if they already have deep Kubernetes investment or a hard portability requirement.

4. Explain the difference between an ECS execution role and a task role. The execution role is used by the ECS agent/Fargate to pull the container image from ECR and write logs to CloudWatch. The task role is the identity your application code assumes to call AWS APIs (S3, DynamoDB, etc.). They’re separate so you can least-privilege the app independently of the platform’s pull/log permissions.

5. How do EC2 purchase models change cost, and when is Spot appropriate? On-Demand is the flexible baseline; Reserved Instances and Savings Plans discount up to ~72% for a 1–3 year commitment to steady usage; Spot discounts up to ~90% for spare capacity that can be reclaimed with a 2-minute notice. Spot suits fault-tolerant, stateless, checkpointed work (batch, CI, stateless workers) — never a stateful single instance that can’t tolerate eviction.

6. What is a cold start and which services pay it? The latency to initialise fresh capacity when a request arrives with nothing warm — runtime init, image pull, connection priming. Lambda (from zero or beyond warm concurrency), Fargate tasks (pull + start), and autoscaler-provisioned EC2/EKS nodes all pay it; an always-on EC2 instance does not. Mitigate with provisioned concurrency, SnapStart, smaller packages, or keeping warm capacity.

7. Fargate vs EC2 launch type for ECS — what decides it? Fargate removes node management and bills per task — best for variable load and lean teams. EC2-backed wins when you can bin-pack a node tightly (≥~70% utilisation), need GPU/special hardware, or want Reserved/Spot EC2 pricing at scale. They’re the data-plane choice; the orchestrator (ECS) is unchanged either way.

8. Why might raising a Lambda’s memory reduce its cost? Memory and vCPU scale together — more memory means more CPU, so a CPU-bound function finishes faster. Because you’re billed per GB-second, a function that runs in half the time at double the memory can cost the same or less, while being far faster. Profile across memory sizes to find the cost/latency sweet spot.

9. A pod is stuck Pending on EKS. Walk through diagnosis. kubectl describe pod and read the events: common causes are no node with enough free CPU/memory (resource requests too high or cluster at capacity), taints with no matching toleration, or an AZ/volume affinity mismatch. Fix by scaling the data plane (Cluster Autoscaler/Karpenter), lowering requests, adding tolerations, or correcting AZ placement.

10. What does the EKS control-plane charge buy you, and how do you avoid wasting it? $0.10/hr per cluster pays for a managed, 3-AZ, highly-available, AWS-patched Kubernetes control plane (API server + etcd). Avoid waste by consolidating environments into fewer clusters (namespaces and RBAC for isolation) instead of spinning up a cluster per team/env that then sits mostly idle.

11. Which compute service for a 4-hour nightly ETL batch job? Not Lambda (15-minute wall). A Batch-managed or scheduled ECS task (Fargate for simplicity, EC2/Spot for cost) running the container to completion, or an EC2 Spot fleet if it’s large and checkpointable. The job’s >15-minute duration disqualifies functions outright.

12. How do Savings Plans differ from Reserved Instances? Reserved Instances commit to a specific instance family (Standard) or a swappable set (Convertible) in a region. Compute Savings Plans commit to a dollars-per-hour spend and apply flexibly across instance family, size, region, OS and across EC2, Fargate and Lambda — more flexible, slightly lower max discount than an exact-match Standard RI.

Quick check

1. A job runs for 18 minutes per execution. Can it run on Lambda? Why or why not?
2. You have six stateless microservices, a lean team, and no Kubernetes experience. ECS or EKS — and on what data plane?
3. Name two EC2 purchase models that discount steady 24×7 usage and one that suits fault-tolerant batch.
4. What’s the difference between an ECS execution role and a task role?
5. Your EC2 fleet’s average CPU is 12% and the bill is high. What’s the likely problem and the first fix?

Answers

1. No. Lambda’s hard maximum timeout is 15 minutes (900 s); an 18-minute job will be killed with Task timed out. Run it as an ECS task (Fargate or EC2) or on EC2/Batch where there’s no duration wall.
2. ECS on Fargate. ECS avoids the Kubernetes operational surface and the $0.10/hr-per-cluster cost a lean, non-K8s team can’t justify; Fargate removes node management so they ship without running a fleet.
3. Steady: Reserved Instances and Savings Plans (up to ~72%). Fault-tolerant batch: Spot (up to ~90%, with 2-minute interruption).
4. The execution role lets the platform pull the image from ECR and write logs; the task role is the identity your application assumes to call AWS APIs. Keep them separate and least-privilege each.
5. The fleet is over-provisioned / idle — paying for always-on capacity it doesn’t use. First fix: re-home spiky/intermittent work to Lambda or Fargate (scale to zero), right-size what remains, and cover the steady baseline with a Savings Plan.

Glossary

• Instance — a virtual machine rented from EC2; the maximum-control compute unit.
• Instance family — an EC2 class (t, m, c, r, g, …) tuned to a CPU:memory:accelerator ratio.
• AMI (Amazon Machine Image) — the disk image an EC2 instance boots from; you own its patch level.
• Auto Scaling Group (ASG) — keeps a target number of EC2 instances running and scales them on a policy.
• CPU credits — the burst budget for t-family instances; exhaust them and you throttle to a baseline (unless Unlimited).
• Lambda — function-as-a-service; runs your handler per event, scaling automatically, billed per GB-second + request.
• Cold start — the latency to initialise fresh capacity (runtime/image/connection) when nothing is warm.
• Concurrency — simultaneous executions (Lambda) or tasks (ECS); Lambda’s default account limit is 1,000.
• Provisioned concurrency — pre-warmed Lambda execution environments that eliminate cold start for N invocations.
• Task (ECS) — a running group of one or more containers; the ECS unit of work.
• Task definition — the blueprint declaring a task’s containers, CPU/memory, roles, ports and health check.
• Service (ECS) — keeps a desired number of tasks running and integrates with a load balancer.
• Launch type — whether ECS tasks run on EC2 nodes you own or on Fargate (serverless).
• Pod (EKS) — the smallest deployable Kubernetes unit; one or more containers scheduled together.
• Node group (EKS) — a managed set of EC2 nodes that host pods; the data plane you may own.
• Control plane — the orchestrator’s API/scheduler; free on ECS, $0.10/hr per cluster on EKS.
• Fargate — the serverless data plane for ECS and EKS; per-second vCPU/GB billing, no nodes to manage.
• Execution role — the IAM identity the platform uses to pull images and write logs.
• Task role / IRSA — the IAM identity the application assumes to call AWS APIs (IRSA = IAM Roles for Service Accounts on EKS).
• Savings Plan — a commitment to $/hour spend that discounts EC2, Fargate and Lambda flexibly.
• Spot — spare-capacity pricing up to ~90% off, reclaimable with a 2-minute notice.
• Graviton (arm64) — AWS’s ARM processors; ~20% cheaper per vCPU, often faster, across EC2/Lambda/Fargate.

Next steps

• Go one level deeper on containers with ECS vs EKS vs Fargate: choosing your container path.
• Master the serverless integration shapes in AWS Lambda event-driven patterns.
• Put a front door on your compute with ALB vs NLB vs API Gateway compared.
• Land it in the right network and blast radius via VPC, subnets and security groups and Regions and Availability Zones explained.
• Connect it to state with RDS vs DynamoDB vs Aurora compared and the identity it assumes via AWS Organizations and IAM foundations.