EC2 vs Lambda vs Fargate - How to Choose the Right AWS Compute

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:

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. That is where the other two options become relevant.

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. Lambda scales to zero automatically. 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 Lambda pricing reality check:

Lambda is wrong when your function approaches the 15-minute limit, needs GPU, or runs every second without pause. At that point the abstraction costs more than the infrastructure.

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 — they 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 gives them containers-as-infrastructure with AWS handling everything underneath.

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 — which scales in milliseconds — is faster.

The Comparison That Matters in Production

The Decision You Actually Make in Production

Most production architectures at scale use all three together:

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 per second, 500ms each:

Scenario B — 100 requests per second, 500ms each:

Scenario C — 1,000 requests per second in a 2-hour burst, then zero:

Cold Start Realities and Mitigations

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

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

Trade-offs and Alternatives

Production Implementation Guidelines

Follow these rules before finalising your compute choice:

• 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.

REMEMBER THIS

**References and Further Reading** * [AWS Lambda pricing calculator](https://aws.amazon.com/lambda/pricing/) — model your exact workload cost * [AWS Fargate pricing](https://aws.amazon.com/fargate/pricing/) — per-vCPU and per-GB-memory pricing * [EC2 Savings Plans](https://aws.amazon.com/savingsplans/) — how to reduce EC2 cost for steady workloads