Your Cloud Compute Bill Is a Choice: How to Pick the Right Model

You're staring at a cloud bill that's way higher than you expected, and you're wondering: "Why am I paying so much for compute?" The answer isn't just "cloud is expensive." It's that you're probably using the wrong compute model for your workload. Most people default to on-demand instances because they're flexible, but that's the most expensive way to run steady workloads. You have options—spot, savings plans, serverless—and each fits a different job. Let's walk through a realistic scenario and see how to choose.

The Scenario: A Web App with Spiky Traffic

Imagine you're a developer at a small startup. You run a containerized web app on AWS. It gets steady traffic during business hours, but spikes unpredictably when a blog post goes viral or a marketing campaign hits. You've been running a few m5.large instances on-demand, and the bill is eating your runway. You're about to switch to serverless because "it's cheaper," but you're not sure.

First, Know Your Workload

Before you pick a compute model, you need to answer one question: Is your workload steady, spiky, or truly unpredictable? If it's steady, on-demand is the worst choice—you're paying full price for capacity you know you'll need. If it's spiky but predictable (like business hours), you can use savings plans or reserved instances. If it's truly unpredictable and you can tolerate interruptions, spot instances are your friend. If it's event-driven and short-lived, serverless functions like Lambda might be the ticket.

In our scenario, the web app is steady during the day but has random spikes. That's a mixed pattern. So let's break down the options.

Comparing the Compute Options

Here's a quick comparison of the main AWS compute purchase options and their trade-offs:

Now, let's apply this to our scenario.

The Steady Baseline: Use Savings Plans or Reserved Instances

For the predictable part of your traffic, you don't need on-demand. You know you'll run at least two m5.large instances 24/7. Instead of paying $0.096/hour each (AWS EC2 Price List API), you could commit to a Savings Plan. Compute Savings Plans give you up to 66% off, and EC2 Instance Savings Plans up to 72% (AWS Documentation). That's a huge cut. For our scenario, I'd recommend a 1-year Compute Savings Plan. It gives you flexibility across instance families, so if you need to switch to a Graviton instance later, you can.

But what about the spikes? You don't want to over-provision and pay for idle capacity. That's where spot instances come in.

Handling the Spikes: Spot Instances for the Overflow

When traffic spikes, you can burst out with Spot Instances. They use spare AWS capacity at up to 90% off On-Demand (AWS EC2 Spot). In our scenario, you could launch a fleet of spot instances to handle the extra load. Since your web app is stateless (you can put a load balancer in front), it's a perfect fit. Spot instances are ideal for containerized workloads and web servers (AWS EC2 Spot). Just be prepared for interruptions—you get a two-minute warning, so your app needs to handle graceful shutdowns.

But wait—what if your spikes are too short and unpredictable? Then you might overpay for spot that you don't use. That's where serverless shines.

The Serverless Option: When It Makes Sense

Serverless, like AWS Lambda or Fargate, is great for event-driven, short-lived tasks. Lambda's free tier includes 1 million requests and 400,000 GB-seconds per month (AWS Lambda Pricing). Beyond that, it's $0.20 per million requests and $0.0000166667 per GB-second (AWS Lambda Pricing). For a web app with spiky traffic, you could offload specific endpoints to Lambda—like image processing or webhook handling—and only pay when they run. But for a full web app that needs to be always-on, serverless might not be cost-effective. Fargate, the serverless compute for containers, scales up to 16 vCPU and 120 GB per task (AWS Fargate), but you're still paying for the time your containers run, even if they're idle.

In our scenario, I'd use Lambda for the spike-prone, short-lived functions, but keep the core app on EC2 with a Savings Plan.

What I'd Actually Do

Here's my blunt recommendation: Stop using on-demand for anything that runs more than a few hours a day. For your steady baseline, buy a 1-year Compute Savings Plan—you'll save up to 66% (AWS Documentation). For the spikes, use Spot Instances if your app can handle interruptions—you'll save up to 90% (AWS EC2 Spot). And for the truly intermittent stuff—like image resizing or webhooks—use Lambda and only pay per request.

Let's crunch the numbers for our scenario. Say you run two m5.large instances on-demand for a month. That's 2 × $0.096 × 730 hours = $140.16 (AWS EC2 Price List API). With a Compute Savings Plan at 66% off, you'd pay about $47.65. That's a $92.51 savings per month. Now add spot for the spikes—even if you use 100 spot hours at $0.01/hour (90% off), that's $1 vs $9.60 on-demand. And Lambda for the occasional webhook—a few thousand requests cost pennies. Total monthly compute: under $50. Compare that to your original $150+ on-demand bill, and you've cut it by two-thirds.

This isn't just theory. The cloud market is huge—$443.6 billion in 2024 (MarketLine)—and everyone's paying too much because they don't think about compute models. Don't be that person. Pick the right tool for each job, and you'll save money without sacrificing performance.

Sources

• AWS Documentation - https://docs.aws.amazon.com/ec2/
• AWS EC2 Pricing - https://aws.amazon.com/ec2/pricing/
• AWS EC2 Spot - https://aws.amazon.com/ec2/spot/
• AWS Lambda Pricing - https://aws.amazon.com/lambda/pricing/
• AWS EC2 Price List API - https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/us-east-1/index.json