The Cloud Pricing Myth: Why On-Demand Isn't the Default and You Shouldn't Pay Full Price

There's a persistent myth in cloud computing: that On-Demand pricing is the default, the standard, the only sane choice for production workloads. It's wrong. In my years as a practitioner, I've seen teams burn money by reflexively clicking 'Launch instance' without thinking about the purchase option. On-Demand is the most flexible, but it's also the most expensive way to run steady workloads. The real skill is knowing when to break the default.

Why is everyone so quick to use On-Demand when it's the most expensive option?

On-Demand feels safe. No commitment, no risk. You pay per second or hour, and you can stop anytime. That's the pitch, and it's true. But the price you pay for that flexibility is steep. AWS's own documentation is blunt: On-Demand is most flexible but most expensive for steady workloads. Compare that to Savings Plans, which can cut your bill by up to 66% for Compute Savings Plans or 72% for EC2 Instance Savings Plans. Reserved Instances go even higher—up to 75% off—if you're willing to commit to a specific instance type and region. The math is not subtle. If you have a workload that runs 24/7, you're leaving money on the table every minute you stay On-Demand.

Is Spot only for batch jobs or can I use it for real services?

Another myth: Spot is just for test environments or data crunching. While it's true that Spot fits stateless, fault-tolerant workloads like big data, CI/CD, and web servers, that's a wider net than many think. Spot can be interrupted with a two-minute warning, so you need to design for that. But if you're running containerized microservices that can handle a pod restart, Spot can be a workhorse. The discount is up to 90% off On-Demand (AWS EC2 Spot). That's not a rounding error. I've seen teams run entire staging environments on Spot and cut costs by more than half. The key is to mix Spot with On-Demand or Savings Plans for the critical pieces, and let Spot absorb the rest.

Does the processor really matter for cost, or is it all about the instance size?

Yes, the processor matters—a lot. AWS Graviton-based instances cost up to 20% less than comparable x86 instances (AWS Graviton). For example, in the US East (N. Virginia) price list, the m7g.large (Graviton3, 2 vCPU, 8 GiB) runs $0.0816/hour, while the x86 m7i.large (same specs) is $0.1008/hour. That's a 19% difference. Over a year, that adds up. And Graviton isn't just cheaper—it's more efficient. Graviton instances use up to 60% less energy for the same performance. For a sustainability-conscious team, that's a double win. The catch is that not all software is ARM-ready, but most modern stacks are. If you're starting a new project, Graviton should be your default, not an afterthought.

What about the free tier? Can I run a production service on it?

Let's be honest: the free tier is for learning, not production. AWS gives new customers up to $200 in credits for six months and a set of always-free services, but the limits are tight. For example, Lambda's free tier includes 1 million requests and 400,000 GB-seconds per month (AWS Lambda Pricing). That's fine for a hobby project or a low-traffic API, but once you start scaling, you'll blow past it quickly. Azure and Google have similar offers—$200 in Azure credits and $300 in Google credits—but again, these are trial runs. If you're serious about a workload, plan to pay for it. The free tier is a taste, not a meal.

Are serverless and containers mutually exclusive, or can I be pragmatic?

People often frame serverless vs. containers as a binary choice. It's not. Serverless, like Lambda or Fargate, is great for event-driven, intermittent workloads where you don't want to manage servers. Fargate, for instance, lets you run containers without provisioning EC2 instances, and it scales up to 16 vCPU and 120 GB of memory per task (AWS Fargate). But if you have a steady, predictable load, a container on EC2 with a Savings Plan is likely cheaper. The real decision is about operational overhead and traffic patterns. For a small team, Lambda might be the pragmatic choice because you don't want to babysit Kubernetes. For a larger team with existing K8s expertise, EKS (which automates cluster management) might be fine. The point is to match the tool to the job, not to a religion.

How do I decide which purchase option to use for a new service?

Here's a simple mental model: if the workload is truly sporadic and can tolerate cold starts, use serverless (Lambda or Fargate). If it's steady and you know the instance type, buy a Savings Plan or Reserved Instance. If it's flexible and fault-tolerant, use Spot. If you're unsure, start On-Demand but set a calendar reminder to review after 30 days. Don't let On-Demand become the permanent default. And remember, you can combine options. For example, run a baseline of Reserved Instances for your minimum capacity, then use Spot for the rest. That's the kind of hybrid approach that actually moves the needle on your bill.

What I'd actually do

If I were starting a new project today, I'd do this: pick Graviton instances (m7g or similar) for any steady compute, and commit to a 1-year Compute Savings Plan for that baseline. That alone could cut costs by 60-70% compared to On-Demand. For burst capacity, I'd use Spot with a graceful shutdown hook. For anything event-driven or with low, spiky traffic, I'd use Lambda. I'd avoid managing my own Kubernetes unless the team already has deep K8s expertise—EKS is great, but it's still operational overhead. And I'd set up a cost alert from day one. The cloud is not a place where you set and forget. It's a place where you make conscious choices. The myth that On-Demand is the default is just that—a myth. Break it, and your CFO will thank you.

Sources

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