Skip to main content

EC2 vs Lambda vs Fargate: Choosing AWS Compute

EC2, Lambda, or Fargate — choosing the wrong AWS compute option costs you money and performance. Here is exactly when to use each one in production.

Three services. One decision that determines your bill, your scaling behaviour, and how many 2 AM pages your team gets. Getting this wrong at Swiggy during the IPL final means dropped orders. Getting it wrong at Razorpay during a payment spike means failed transactions and chargebacks.

This is not a theoretical comparison. It is a practical decision framework built on what actually happens in Indian production environments.

The Core Mental Model

Before comparing numbers, understand what each service actually is:

TEXT
EC2: You rent a virtual machine. The machine runs 24/7.
You manage: OS, patching, scaling, monitoring.
You pay: every hour the instance is running, used or not.
Fargate: You run a Docker container. AWS manages the VM.
You manage: container image, CPU/memory allocation.
You pay: per second the container is active.
Lambda: You run a function. AWS manages everything.
You manage: your code and its trigger.
You pay: per millisecond of actual execution.

The gradient goes from maximum control (EC2) to maximum abstraction (Lambda). Neither extreme is always correct.

When EC2 Is the Right Choice

EC2 wins when your workload is predictable, persistent, and stateful.

Zerodha's trading engine processes millions of orders per day across a 6-hour market window. The load pattern is known: 9:15 AM opens hard, stays high until 3:30 PM, quiet overnight. The application is stateful — in-memory order books that cannot be rebuilt on every cold start. Lambda's 15-minute limit and cold start penalty are disqualifying factors. EC2 Reserved Instances bought for the trading window cost 40-72% less than On-Demand.

EC2 is correct when:

  • The process runs continuously — a background worker, a long-running data pipeline, a stateful service
  • You need specific hardware — GPU instances for ML inference, high-memory instances for in-memory databases
  • The application cannot tolerate cold starts — trading, payment processing, real-time gaming
  • You already hold Reserved Instance or Savings Plan commitments

The mistake engineers make is defaulting to EC2 out of familiarity. If your EC2 instance sits at 3% CPU for 18 hours a day, you are paying for compute you are not using.

When Lambda Is the Right Choice

Lambda wins when work arrives in bursts, runs for seconds, and disappears.

At Hotstar, when a match ends, 50 million users simultaneously trigger a cascade of events — push notifications, watch history updates, recommendation model triggers, analytics writes. Each event takes 200-500 milliseconds. Lambda handles 50,000 of them in parallel without any capacity planning. Five minutes after the match, load drops to near zero. EC2 running 24/7 for that burst workload would cost 20x more and sit idle 95% of the time.

Lambda is correct when:

  • Work is triggered by events — file uploads, API calls, database changes, scheduled tasks
  • Each invocation is short — under 15 minutes
  • Traffic is bursty or unpredictable — spikes without notice
  • You need to scale to zero — no traffic, no cost

The pricing reality check:

TEXT
Function: 256 MB RAM, 300ms per invocation
Traffic: 1 million invocations per day
Lambda cost: ~$3.75/month
Equivalent t3.small EC2 running 24/7: ~$18.72/month
Lambda is roughly 5x cheaper for this pattern.

Lambda is wrong when your function approaches the 15-minute limit, needs GPU, or runs every second without pause.

When Fargate Is the Right Choice

Fargate sits between EC2 and Lambda. You get containers without managing servers, with no time limit and no cold start concerns — but you pay for running containers even when they are idle.

PhonePe runs its payment processing microservices on Fargate. Each service is a Docker container with specific CPU and memory requirements. The services run continuously and need to be responsive instantly when a UPI request arrives. Lambda cold starts are unacceptable for sub-second payment confirmation, but PhonePe does not want to manage EC2 instances, patch operating systems, or size clusters manually.

Fargate is correct when:

  • Your workload is containerised and you want no server management
  • Processes run longer than 15 minutes, ruling out Lambda
  • Traffic is relatively predictable, not extreme bursts from zero to massive
  • You want per-second billing without paying for idle EC2 capacity
  • ECS or EKS is your orchestration layer

Fargate is wrong for extremely spiky workloads. When a Fargate task starts, it takes 20-30 seconds to be ready — for sudden traffic explosions, Lambda scales faster.

The Comparison That Matters in Production

Dimension EC2 Fargate
Startup time Minutes (cold AMI) 20-30 seconds
Max runtime Unlimited Unlimited
Scaling speed Minutes (ASG) 30 seconds
Idle cost Full instance cost Per second idle
Dimension Lambda
Startup time 100ms to 10s
Max runtime 15 minutes
Scaling speed Milliseconds
Idle cost Zero

The Decision You Actually Make in Production

Most production architectures at scale use all three together:

◈ DIAGRAM
API Layer: API Gateway -> Lambda (auth, routing, simple responses)
App Layer: ECS Fargate (long-running microservices, stateful)
Batch/Events: Lambda (S3 triggers, SQS workers, scheduled jobs)
Infra Layer: EC2 Reserved (Redis, Kafka, anything stateful/continuous)

At CRED, the recommendation engine runs on EC2 Reserved Instances because it trains continuously. The notification delivery runs on Lambda because it fires in bursts when reward points are calculated. The API serving users runs on Fargate because it needs instant response without the complexity of EC2 fleet management.

Cost Modelling for Your Workload

Before picking, model your cost across three scenarios.

Scenario A — 10 requests/second, 500ms each: Lambda wins at roughly $0.18/day versus Fargate's $0.24/day and EC2 t3.small's $0.62/day.

Scenario B — 100 requests/second, 500ms each: EC2 Reserved (1yr) wins at roughly $0.36/day, undercutting both Lambda ($1.80/day) and Fargate ($1.94/day) at this sustained volume.

Scenario C — 1,000 requests/second in a 2-hour burst, then zero: Lambda wins by a wide margin — it scales instantly and costs only during the window, while Fargate must pre-provision for peak and EC2 ASG takes minutes to catch up.

Cold Start Realities and Mitigations

Cold starts are Lambda's biggest liability for user-facing APIs:

TEXT
Python / Node.js: 100-500ms (acceptable for most APIs)
Java / .NET: 1-10 seconds (serious problem for payments, trading)
Mitigations:
1. Move all initialisation outside the handler function
(DB connections, SDK clients, config - runs once, reused)
2. Provisioned Concurrency - keep N environments always warm (paid)
3. SnapStart for Java - snapshot at deploy time, restore in under 1s
4. Choose Python or Node.js for latency-sensitive functions

For payment APIs at Razorpay, Provisioned Concurrency with Application Auto Scaling keeps 20 warm environments during business hours and scales down overnight. Cold starts are effectively eliminated. Cost increases by roughly 30% but SLA is met.

Trade-offs and Alternatives

Concern EC2 Fargate
Operational burden High — OS, patching Low — container only
Cost at low traffic Worst — pays for idle Medium
Cost at high continuous traffic Best with Reserved Medium
Concern Lambda
Operational burden Near zero
Cost at low traffic Best — zero at zero
Cost at high continuous traffic Worst — per-request

Production Implementation Guidelines

  • If the process runs more than 20 hours per day continuously, start with EC2 Reserved and check whether containerising makes sense before defaulting to Fargate.
  • If the process is triggered by an event and completes in under 15 minutes, Lambda is almost always the right answer — model the cost before choosing anything else.
  • If the process is a containerised service that must be always-ready but you do not want EC2 fleet management, Fargate is the correct default.
  • Always model three cost scenarios: low traffic, current traffic, 10x peak traffic. The winner changes based on the scenario.
  • Combine all three within the same application. There is no rule that says you must pick one.
Note

References and Further Reading

Frequently Asked Questions

Why is Lambda wrong for a stateful trading engine even if it's technically fast enough per request?

Lambda's 15-minute execution limit and cold-start penalty are disqualifying for workloads with in-memory state — like an order book — that cannot be rebuilt on every cold start; the statefulness, not raw speed, is what rules Lambda out.

How much does Provisioned Concurrency actually reduce Lambda cold starts for payment APIs?

Keeping a fixed number of warm environments through Application Auto Scaling effectively eliminates cold starts during business hours, at roughly a 30% cost increase over on-demand Lambda pricing — a trade many payment teams accept to meet sub-second SLA requirements.

Is Fargate a good fit for extremely spiky, zero-to-massive traffic?

No — a Fargate task takes 20-30 seconds to become ready when it starts, which is too slow for sudden traffic explosions. Lambda scales in milliseconds for that specific pattern; Fargate is better suited to relatively predictable, continuously running containerized services.

Do most production systems pick just one of EC2, Lambda, and Fargate?

No — mature architectures typically use all three together: Lambda for bursty events and simple API routing, Fargate for always-ready containerized services, and EC2 Reserved Instances for continuous, stateful infrastructure like Redis or Kafka.

What's the fastest way to know which compute option is cheapest for a specific workload?

Model cost across at least three traffic scenarios — low/steady traffic, current traffic, and a 10x burst — since the cheapest option changes depending on the scenario; a single "average" cost comparison hides which option wins under the traffic pattern that actually matters to you.

Discussion0