Reserved Instances vs. Savings Plans: A Canadian Business Guide to Cloud Commitments

Cloud on-demand pricing is convenient but expensive. AWS, Azure, and GCP all offer substantial discounts for committing to use capacity over 1 or 3 years. For Canadian businesses running stable workloads, these commitments are one of the highest-ROI cloud cost decisions available.

The challenge is choosing the right commitment model and sizing the commitment correctly.

The commitment models

AWS

Reserved Instances (RIs) commit to a specific instance type in a specific region (e.g., m6i.xlarge in ca-central-1). Savings range from 40–60% depending on 1-year vs. 3-year and payment terms (no upfront, partial upfront, all upfront). All-upfront 3-year offers the deepest discount; no-upfront 1-year has the least commitment.

RIs are instance-type specific—an m6i.xlarge RI doesn't apply to an r5.xlarge. This inflexibility has been partially addressed by:

Compute Savings Plans — a newer, more flexible commitment. You commit to a spend level (e.g., $50/hour of compute) rather than a specific instance type. The discount applies across any EC2 instance type, Fargate, and Lambda, regardless of family, size, or region. Flexibility comes at a slightly lower discount than equivalent RIs (roughly 3–5% less).

EC2 Instance Savings Plans — similar to RIs but flexible across instance sizes within a family in a specific region. A good middle ground between RIs and Compute Savings Plans.

Azure

Reserved VM Instances work similarly to AWS RIs—you commit to a VM type and size in a specific region. Azure's reservations apply to the compute portion of the cost (not OS licensing for Windows VMs, which is separate).

Azure Savings Plans — Azure's equivalent to AWS Compute Savings Plans. Commit to a spend level; the discount applies across compute services (VMs, AKS, App Service, Functions). More flexible than Reserved VM Instances.

GCP

Committed Use Discounts (CUDs) — GCP's commitment model. Resource-based CUDs commit to specific resources (vCPUs, memory) for 1 or 3 years. Spend-based CUDs commit to a spend level in a specific service. GCP automatically applies CUDs to matching usage.

How to size a commitment

Over-committing is almost as costly as not committing. Reserved capacity you don't use still costs money.

Rule of thumb: commit only what has run continuously for the past 60 days with at least 90% utilization. This is your "steady state" baseline—the usage that will reliably continue.

Process:

1. Pull utilization data from your cloud provider's cost explorer (AWS Cost Explorer, Azure Cost Analysis, GCP Cost Management)
2. Identify instances and services running at high utilization continuously
3. Start with a 1-year commitment to validate the pattern before committing to 3 years
4. Review commitment coverage quarterly and top up as stable workloads grow

What not to commit: development and test environments (variable usage), workloads that may be migrated or decommissioned, instances supporting time-limited projects.

The reserved capacity decision tree

Databases and other managed services

Reserved capacity extends beyond compute:

• AWS RDS Reserved Instances — 40–60% savings on RDS database instances; highly recommended for production databases
• ElastiCache Reserved Nodes — for Redis and Memcached
• Azure SQL Reserved Capacity — for Azure SQL Database and Managed Instance
• GCP Cloud SQL committed use — for Cloud SQL instances

Database costs are often 30–40% of total cloud spend for data-heavy workloads. Reserved capacity on databases should be evaluated alongside compute commitments.

MicroPro's Cost Optimization service includes reserved capacity analysis and commitment sizing for AWS, Azure, and GCP environments. Most businesses see 30–50% savings on committed workloads within 90 days of optimization.