Cloud commitment discounts are one of the most reliable ways to cut compute bills, yet many Australian IT teams leave them on the table or, worse, commit to the wrong model. Reserved instances and savings plans both reduce on-demand pricing significantly, but they aren't interchangeable. The right choice depends on how stable your workloads are, how often your architecture changes, and how much flexibility you need to preserve when budgets shift.
What reserved instances actually are
A reserved instance (RI) is a billing contract where you commit to a specific compute configuration for one or three years in exchange for a discount. On AWS, that means a specific instance type, region, operating system, and tenancy. On Azure, the commitment is tied to a virtual machine family and region. On GCP, committed use discounts work similarly, though the mechanics differ slightly from the RI terminology used by AWS and Azure.
The discount is real. AWS standard reserved instances deliver up to 72% off on-demand rates for a three-year, all-upfront payment. That's a meaningful number for any workload running 24 hours a day. The catch is specificity. A m5.4xlarge RI in Sydney doesn't apply to an m6i.4xlarge instance, even though the two are functionally similar. If you resize or replace that instance, the RI keeps billing regardless, and you're either wasting the discount or selling the RI on the AWS Reserved Instance Marketplace at a potential loss.
Convertible reserved instances offer more flexibility. You can exchange them for a different configuration mid-term, but the discount drops to around 54% at maximum. That's still useful, but the gap between standard and convertible RIs is wide enough to matter in a large environment.
What savings plans actually are
Savings plans, introduced by AWS in 2019, flip the model. Instead of committing to a specific instance configuration, you commit to a dollar-per-hour spend level. Compute savings plans apply across any instance family, size, region, and OS. EC2 instance savings plans are more restricted, covering a specific instance family in a specific region, but deliver a deeper discount than compute savings plans in return.
The flexibility benefit is significant for teams that regularly resize, shift regions, or move workloads between instance types. If your architecture is actively evolving, a compute savings plan means the commitment follows your spend rather than your specific resource configuration. That matters when you're migrating between instance generations or refactoring services.
Azure's equivalent is Azure Reservations combined with Azure Savings Plans for Compute, which Microsoft made generally available in 2022. The design closely mirrors AWS: reservations lock to a specific VM size and region; savings plans apply across instance families within a scope. GCP's committed use discounts are resource-based rather than spend-based, so they behave more like AWS reserved instances.
The flexibility trade-off in practice
The core question is simple: how predictable is your compute footprint over the next one to three years?
For workloads that don't change, standard reserved instances win on price. A production database cluster running on fixed instance types, a legacy application with stable resource requirements, or a compliance-sensitive workload that can't be containerised are all candidates. The discount is deeper and the commitment cost is clear.
For teams running containerised microservices, actively migrating between AWS generations, or scaling different instance types in response to AI inference workloads, savings plans offer real protection against commitment waste. You keep the discount without betting on a specific configuration lasting three years.
One practical approach: use savings plans for your baseline compute commitment and leave on-demand capacity for volatile or short-lived workloads. This pairs well with a cloud cost optimisation review that identifies which workloads are genuinely stable versus which ones only appear stable because nobody has re-architected them recently.
Payment options and cash flow
Both models offer three payment options: all upfront, partial upfront, and no upfront. All upfront delivers the largest discount. No upfront trades discount depth for cash flow preservation, which is relevant for Australian organisations operating under quarterly budget constraints or those in regulated sectors where capital expenditure approvals move slowly.
For a three-year standard RI on AWS, the difference between all upfront and no upfront is roughly 7 to 10 percentage points of discount, depending on instance type. That gap is worth calculating explicitly against your cost of capital. For most medium-sized Australian enterprises, the all-upfront option makes sense for stable workloads where the commitment risk is low.
Rightsizing before committing
Committing to the wrong size is worse than not committing at all. An oversized RI locks in both the underutilisation and the commitment. Before purchasing any reserved capacity, run at least 30 days of utilisation data through AWS Cost Explorer, Azure Advisor, or GCP Recommender. These tools surface rightsizing recommendations and, on AWS and Azure, model the coverage impact of different RI or savings plan scenarios before you buy.
This step is especially important in environments where cloud infrastructure decisions have been made reactively. If your team has been provisioning instances based on headroom assumptions rather than measured demand, you may be sizing commitments against inflated baselines. A cloud capacity planning exercise before any commitment purchase will almost always surface instances that can be downsized, eliminating wasted discount spend before it starts.
Multi-cloud and multi-region considerations for Australian teams
Australian organisations using AWS Sydney (ap-southeast-2) alongside Azure Australia East or GCP's Sydney and Melbourne regions need to manage commitments across clouds independently. There's no cross-cloud commitment netting. AWS savings plans don't apply to Azure spend, and vice versa.
For teams running a genuine multicloud architecture, the management overhead of tracking RI and savings plan coverage ratios across three clouds is non-trivial. Specialised tools like CloudHealth by VMware or Apptio Cloudability aggregate multi-cloud commitment utilisation in a single view, which makes the difference between a commitment strategy you can actually monitor and one that quietly drifts into waste.
Savings plan scope also matters in multi-region AWS deployments. Compute savings plans apply across all AWS regions by default. EC2 instance savings plans are scoped to a single region. For Australian teams running workloads in both ap-southeast-2 (Sydney) and ap-southeast-4 (Melbourne), compute savings plans offer broader coverage without requiring separate commitments per region.
When to mix both models
Most mature cloud environments benefit from combining both commitment types rather than picking one. A reasonable starting approach: apply standard reserved instances to the 20% of your fleet that hasn't changed instance type in two or more years, and cover the rest of your compute baseline with compute savings plans. Leave 10 to 20% of capacity on demand to absorb spikes without burning committed spend on headroom.
Review your coverage ratio quarterly. AWS Cost Explorer's savings plans coverage report and the RI utilisation dashboard make it straightforward to identify gaps, flag underutilised commitments, and model whether the next purchase should be an RI or a savings plan top-up.
The commitment discount conversation often gets conflated with broader cloud cost control, but they're separate levers. Commitment discounts reduce the unit rate on resources you're already using. Rightsizing, tagging, and architectural changes reduce the volume of resources you need. Getting the most from reserved instances and savings plans means doing both.