Cloud bills grow quietly — a forgotten test instance, an over-provisioned database, storage that was never moved to a cheaper tier. None of it looks dramatic individually, and all of it compounds. Here's where the real leverage is.
Right-sizing: the single biggest lever
Most workloads are provisioned generously "to be safe" and never revisited once running. Cloud providers' own cost tools (AWS Cost Explorer, Azure Advisor, GCP Recommender) surface instances running consistently under 20-30% CPU/memory utilization — these are near-guaranteed candidates for a smaller instance size at meaningfully lower cost with no performance impact.
Before: m5.2xlarge running at 15% average CPU utilization
After: m5.large — same workload, quarter of the cost
This alone is usually the highest-leverage change available, and it requires no architectural work — just resizing based on data you likely already have.
Reserved / committed-use pricing for predictable workloads
On-demand pricing carries a real premium for flexibility you may not need. For workloads you know will run continuously for a year or more (a production database, a baseline of always-on application servers), committing to reserved instances (AWS), reserved VM instances (Azure), or committed-use discounts (GCP) typically cuts 30-60% off the on-demand rate for that exact same resource — you're just pre-paying for capacity you were going to use anyway.
The key qualifier: only commit for genuinely predictable, steady-state workloads. Committing on capacity you might scale down or migrate away from locks in cost without the corresponding flexibility.
Storage tiers — the "set and forget" waste
Object storage (S3, Azure Blob, GCS) defaults to its most expensive, most-available tier. Data that's rarely accessed after creation — logs older than 90 days, backups, archived reports — belongs in a cheaper tier (S3 Glacier, Azure Archive, GCS Coldline), often at a fraction of standard storage cost.
Lifecycle rule: after 30 days → move to Infrequent Access tier
after 90 days → move to Archive tier
after 365 days → delete
Setting this up once as a lifecycle policy means it happens automatically going forward — no one has to remember to do it manually, which is exactly why it's so commonly left undone without automation.
Autoscaling instead of static over-provisioning
Provisioning for peak load 24/7, when peak only happens for a few hours a day, means paying peak-capacity prices around the clock. Autoscaling (scaling compute up during high demand, down during low demand) matches spend to actual usage instead of worst-case usage — genuinely useful for workloads with real daily/weekly traffic patterns, less useful for workloads that are already flat and constant.
The habit that actually prevents waste: tagging and attribution
Cost optimization efforts stall when nobody can tell which team or project a given cost belongs to — a large, unattributed bill is hard to act on. Consistently tagging resources (by team, environment, project) turns a single opaque number into a breakdown you can actually investigate and assign ownership to.
Tag: team=payments, environment=production, project=checkout-service
The practical order of operations
1
Turn on cost tagging/attribution
2
Right-size based on actual utilization
3
Move eligible storage to cheaper tiers
4
Commit to reserved capacity
5
Revisit regularly
Spot/preemptible instances for interruptible workloads
Beyond reserved capacity for steady workloads, spot instances (AWS), spot VMs (Azure), and preemptible VMs (GCP) offer substantial discounts — often 60-90% off on-demand pricing — in exchange for the provider being able to reclaim the capacity with limited notice. This is a real, separate lever from reserved/committed pricing, and it applies to a different category of workload: not "steady and predictable" but "interruptible and fault-tolerant" — batch data processing, CI/CD build runners, non-time-critical background jobs, or any workload architected to handle a node disappearing and resuming elsewhere. Mixing spot capacity into a workload that can genuinely tolerate interruption, alongside on-demand or reserved capacity for the parts that can't, captures savings without risking availability for anything that actually needs it.
Multi-cloud and cross-provider egress
For any architecture spanning more than one cloud provider (or a cloud provider plus a separate CDN or SaaS service), egress between providers is billed at each provider's public internet transfer rate — there's no "internal" discount just because both ends happen to be cloud infrastructure. This is a frequently underestimated cost in multi-cloud setups specifically, and it's a real factor worth weighing against the vendor-lock-in concerns that usually motivate going multi-cloud in the first place — see the multi-cloud tradeoffs discussion for the fuller picture on when that tradeoff is actually worth it.
Common mistakes
- Right-sizing based on a single day or week of utilization data instead of a representative window that includes peak periods — a quiet week makes everything look over-provisioned.
- Committing to reserved capacity for a workload that's actually still finding its shape (a new product, a team still iterating on architecture) — the discount isn't worth the lock-in if you're likely to migrate or resize before the commitment term ends.
- Setting up lifecycle storage rules once and never revisiting them as access patterns change — data that used to be "rarely accessed" can become frequently accessed again after a feature change, and a stale lifecycle rule can now be actively hurting performance, not just costing nothing extra.
- Treating cost tagging as optional busywork. Without it, cost conversations stay abstract ("the bill went up") instead of actionable ("team X's staging environment tripled") — it's the prerequisite for every other optimization on this list being possible to act on with confidence.
Related reading
- AWS vs. Azure vs. GCP: Choosing the Right Cloud for Your Project — shares tags: cloud, devops (same category).
- CI/CD Pipelines Explained: From Commit to Production — shares tags: devops, cloud.
- Git Hooks Explained: Automate Your Workflow — shares tags: devops, productivity.
- Infrastructure as Code: Why Terraform Won — shares tags: devops, cloud.
- AWS Cost Optimization: A Service-by-Service Playbook — shares tags: devops, cloud.
