Your organisation moved to the public cloud expecting lower costs and greater agility. Production is running smoothly, but the monthly invoice from your cloud provider tells a different story. Reserved Instance discounts, on-demand rates, blended and unblended pricing, hundreds of thousands of SKU combinations—understanding the bill feels like a second job, let alone acting on it.
The root cause is rarely a single runaway resource. Cloud cost overruns are typically the result of several overlapping problems: unscheduled idle resources, overprovisioned instance types, unchecked storage growth, and purchasing commitments before eliminating waste. Fixing any one of these in isolation rarely produces the savings you expect, and can even make things worse.
A structured approach helps. The six pillars below cover the main levers available to DevOps, finance, and platform engineering teams. Each pillar has its own tools and tactics, but the real value comes from treating them as an integrated system rather than independent checklists.
1. Reserved Instances (RIs) and Committed Use Discounts
AWS Reserved Instances, Azure Reserved VM Instances, and Google Cloud Committed Use Discounts all work on the same principle: commit to using a certain amount of compute capacity over one or three years, and the provider rewards you with a significant discount compared to on-demand pricing.
This is often the first—and unfortunately the last—optimisation step organisations take. Buying RIs without addressing the other five pillars is a common and costly mistake, because you end up locking in discounts for resources that may be overprovisioned, idle, or redundant.
Two critical factors before purchasing RIs
- Risk tolerance. How confident are you in your workload projections? An organisation comfortable with its usage patterns might cover 60–70% of workloads with RIs. One with variable or unpredictable demand might cap RI coverage at 20–30% to avoid paying for unused commitments. Longer terms (three years) offer greater discounts but require greater confidence in future demand.
- Centralised RI management. A single team buying RIs for its own workloads leaves unused capacity stranded when that team’s demand drops. A centralised purchasing model—often run by a Cloud Centre of Excellence or FinOps team—pools commitments across the entire organisation, increasing utilisation and unlocking larger savings. This requires ongoing communication with individual teams about current and planned resource needs.
Third-party tools such as CloudHealth by VMware can analyse historical usage patterns to recommend RI purchases and help manage the RI lifecycle as your environment changes. Cloud providers also offer their own RI recommendation features in their cost management consoles.
2. Auto-Parking: Scheduling Resources Off During Idle Hours
One of the cloud’s selling points is the ability to spin resources up and down instantly. In practice, individual engineers often spin up a development or test environment and forget to terminate it when they’re done. The meter keeps running.
Auto-parking is the practice of automatically stopping or terminating non-production resources on a schedule—evenings, weekends, or any period when the resources are not actively needed. For a development environment that runs eight hours a day, five days a week, auto-parking alone can cut that environment’s compute cost by roughly 75% compared to running it continuously.
Implementing auto-parking
- Tag resources clearly. A consistent tagging strategy (environment, team, owner, schedule) lets automation tools identify which resources are candidates for parking.
- Automate the schedule. Tools such as ParkMyCloud, AWS Instance Scheduler, Azure Automation, and Google Cloud Scheduler can handle start/stop schedules without manual intervention.
- Communicate the policy. Engineers need to know the schedule and understand how to request exceptions, otherwise you create friction and shadow IT.
3. Right-Sizing: Matching Resources to Actual Demand
Right-sizing means selecting the instance type or VM size that best matches an application’s actual CPU, memory, and I/O requirements—not the instance you guessed you’d need at deployment, and not the largest available to be safe.
The challenge is that right-sizing is not a one-time exercise. Application load profiles change as features ship, user bases grow or contract, and architectural decisions evolve. An instance that was appropriately sized at launch may be massively overprovisioned six months later.
Effective right-sizing requires:
- Continuous monitoring of CPU utilisation, memory, network I/O, and disk I/O—not just peak values, but distributions over time.
- Policies and guardrails that prevent teams from defaulting to the largest instance available.
- Chargeback or showback reporting by team or department, so there is a financial incentive to use appropriately sized resources.
- Coordination with auto-parking and RI purchasing, so you are not buying reserved capacity for overprovisioned instances.
Most major cloud providers include basic right-sizing recommendations in their cost management tools. Third-party platforms typically offer more detailed analysis, especially across multi-cloud environments.
4. Family Refresh: Staying Current with Instance Generations
Cloud providers periodically retire older instance types and VM series as the underlying hardware is replaced. When a new instance generation is introduced, it typically offers better price-to-performance ratios than its predecessor. Organisations that fail to migrate to newer instance families end up paying more for less.
This is known as Family Refresh: the process of identifying which instance types in your environment are approaching end-of-life or are already superseded by more cost-effective generations, and migrating workloads accordingly.
Family Refresh is complicated by Reserved Instances. If you have purchased RIs for an older instance family, migrating to a newer family may mean forfeiting or reselling that commitment—or waiting for it to expire. This is precisely why RI purchasing decisions must account for anticipated Family Refresh cycles, and why all six pillars need to be considered together.
With hundreds of thousands of SKU and pricing combinations across a single major cloud provider, tracking Family Refresh manually is impractical at scale. Automation tools that surface these recommendations—and model the financial impact against existing RI portfolios—significantly reduce the manual effort involved.
5. Waste Elimination: Removing Resources That Serve No Purpose
Cloud waste is any resource you are paying for that provides no business value. Because cloud infrastructure can be provisioned in seconds and there is rarely a hard ceiling on consumption, waste accumulates quietly and consistently.
Common examples of cloud waste
- Compute instances (AWS EC2, Azure VMs) that were provisioned for a project or training exercise and never terminated
- Managed database instances (AWS RDS, Azure SQL Database) with no active connections
- Unattached storage volumes left over after an instance was deleted
- Idle or underutilised load balancers
- Old snapshots consuming storage that will never be restored
- Orphaned Elastic IP addresses or static IP reservations
A robust tagging strategy is the foundation of waste identification. When every resource is tagged with its owner, purpose, and environment, it becomes straightforward to identify resources with no recent activity and trace them back to the team responsible.
A critical sequencing note: eliminate waste before purchasing Reserved Instances. Buying RIs while waste remains in your environment means you are locking in spending on resources that should not exist at all—a guaranteed way to overspend for the duration of the commitment term.
6. Storage Optimisation: Controlling an Exponentially Growing Cost
Cloud object, block, and file storage is inexpensive enough per gigabyte that teams rarely think twice before using it. That low per-unit cost, combined with the ease of provisioning, means storage footprints can grow rapidly and unpredictably.
Cloud storage costs are typically driven by four factors:
- Volume (size). How many gigabytes or terabytes are stored at any given time.
- Data transfer (egress/bandwidth). How frequently data moves between regions, availability zones, or out to the internet.
- Retrieval time (storage tier). Frequently accessed data belongs in a hot tier; archival data can be moved to cheaper cold or archive tiers with slower retrieval.
- Retrieval requests. Some storage classes charge per API request in addition to storage volume.
A data lifecycle policy is the most effective tool for managing storage costs. Define rules that automatically transition data to cheaper storage tiers as it ages, and delete data that has exceeded its retention period. Apply these policies consistently across object stores, managed databases, and snapshot repositories.
Storage optimisation intersects with waste elimination (deleting orphaned volumes and outdated snapshots) and right-sizing (choosing the correct storage class for each workload’s access pattern).
Why the Pillars Must Work Together
Each pillar described above has genuine value on its own. But optimising only one while ignoring the others produces suboptimal results—and can actively cause harm. Buying Reserved Instances before eliminating waste locks in spending on unnecessary resources. Right-sizing without accounting for existing RIs may create commitment mismatches. Auto-parking without a tagging strategy is impossible to enforce consistently.
The recommended sequence for most organisations is:
- Establish tagging standards and enforce them across all environments.
- Identify and eliminate waste.
- Right-size remaining resources.
- Implement auto-parking for non-production environments.
- Analyse storage usage and apply lifecycle policies.
- Purchase Reserved Instances based on the stable, right-sized, waste-free baseline that remains.
- Monitor for Family Refresh opportunities on an ongoing basis.
This is not a one-time project. Cloud providers continuously update their service offerings and pricing. Workloads change. Teams grow. Treat cloud cost optimisation as a continuous operational discipline—not a quarterly audit—and assign clear ownership to each pillar.
Beyond the Six Pillars: Advanced Optimisation
Once the six pillars are operating as a coherent system, further savings are available through architectural changes: application refactoring to reduce resource intensity, Spot Instances or Preemptible VMs for fault-tolerant batch workloads, ephemeral environments that exist only for the duration of a pipeline run, and serverless architectures that eliminate idle capacity entirely. These approaches require more engineering investment but can deliver step-change cost reductions for the right workloads.
The foundation for all of these advanced strategies is the same: accurate visibility into what you are running, what it costs, and who owns it. Build that foundation first.