Containers on a Budget: How I Cut My AWS Bill by 70%

How do I run containers in production without losing my shirt on the cloud bill? That's the question I typed into a search bar more times than I'd like to admit. The answer isn't in some magic dashboard or a single pricing trick. It's a combination of the right compute choices, a willingness to be flexible, and a hard rule about never paying On-Demand for steady workloads.

This is for anyone who's already using containers—maybe you're on ECS or Kubernetes—and feels that monthly bill creeping up. You don't need to be a cloud architect to pull this off. You just need to know where the savings are and be willing to change how you think about capacity.

1. Start with Spot, Not On-Demand

My first move is to make Spot Instances the default for any container that can tolerate interruption. The AWS documentation is blunt about it: Spot can get you up to a 90% discount compared to On-Demand (AWS EC2 Spot). That's not a rounding error. For a typical 2-vCPU container running 24/7, that could mean the difference between paying $70 a month and $7.

Now, I know what you're thinking: "But Spot gets interrupted." Yes, it does—with a two-minute warning (AWS EC2 Spot). But for stateless, fault-tolerant workloads—which most containerized microservices should be—that's acceptable. I run my CI/CD pipelines, batch jobs, and even some web servers on Spot. They're designed to handle a node disappearing now and then.

Here's the practical advice: don't use Spot for your database or any stateful component. But for the rest, it's free money.

2. Switch to Graviton for the Steady Stuff

For the workloads that can't be on Spot—say, your primary API or a long-running job—I go Graviton. AWS's own numbers show that Graviton instances cost up to 20% less than comparable x86 instances (AWS Graviton). And they're not just cheaper; they use less energy too, which might matter for your sustainability goals (AWS Graviton).

Let me give you a concrete example. In the official AWS price list, the m7g.large (Graviton3, 2 vCPU, 8 GiB) runs $0.0816 an hour, while the x86 m7i.large, same specs, is $0.1008 (AWS EC2 Price List API). That's about a 19% difference. On a fleet of 50 containers, that's a meaningful chunk.

Migrating to Graviton is usually a no-brainer for containerized apps. Since you're already using containers, you just need to rebuild your images for ARM. Most modern runtimes and libraries support it. I've done it for Node.js, Python, and Go services with zero issues.

3. Use Fargate for the Yet-Steadier Stuff

There's a layer of my architecture that I don't want to manage at all. That's where Fargate comes in. It's serverless compute for containers, so I don't worry about instances or scaling groups (AWS Fargate). It's not the cheapest option, but it's not as expensive as people think, especially if you use it correctly.

Fargate bills you per vCPU and memory, and it scales down to zero. If you have a service that's only used during business hours, you can set it to scale to zero at night and save 60% of the cost. Plus, you don't pay for idle capacity.

One trick: combine Fargate with Spot. Fargate Spot can save you up to 70% on Fargate costs, but it's not always available. So I use Fargate for the critical stuff and Fargate Spot for the rest.

What about Kubernetes? If you're on EKS, you're paying for the control plane. On Azure, AKS cluster management is free—you just pay for the nodes (Azure Free Account). That's a consideration if you're multi-cloud.

4. Commit to Savings Plans, But Only for the Baseline

After I've moved everything possible to Spot and Graviton, I look at what's left: the steady-state, always-on capacity. That's where Savings Plans come in. They're the modern version of Reserved Instances, and they can save you up to 66% with Compute Savings Plans or 72% with EC2 Instance Savings Plans (AWS Documentation).

So, my rule is: Spot for the flexible, Graviton for the steady, and Savings Plans for the baseline. I don't use On-Demand for anything that runs more than a few hours a day. It's the most expensive option (AWS Documentation). The only exception is for short-lived spikes or testing.

Now, a warning: don't commit to a Savings Plan before you've optimized your workload. If you commit to a 3-year plan and then realize you can move half your stuff to Spot, you've locked yourself into a higher bill. Start with Spot and Graviton, then commit.

Here's what can go wrong: you ignore Spot interruptions and run a stateful app on it, then lose data. I've seen it happen. Or you commit to a Savings Plan for a specific instance type and then want to switch to a Graviton instance—that's a mistake. That's why I only use Compute Savings Plans, which are flexible, not the instance-specific ones.

Bottom line

The single best move you can make today is to turn on Spot for your container workloads. It's the easiest, highest-impact change. Then, when you have steady state, move to Graviton and commit to Savings Plans. You'll cut your bill by 70% without losing sleep.

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 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
• Azure Free Account - https://azure.microsoft.com/en-us/free/