Zonal vs Regional Reserved Instances: Scope, Capacity, and Cost Tradeoffs
Regional Reserved Instances buy you a discount; zonal Reserved Instances buy you a discount plus a capacity reservation. The right choice depends on whether you need price certainty, capacity certainty, or both.
Reserved Instances on AWS come in two scopes: regional and zonal. The distinction is easy to overlook in the EC2 console — it is a single dropdown at purchase time — but the operational and financial consequences are large. A regional RI applies discount across an entire region. A zonal RI applies the same discount but additionally reserves compute capacity in a specific Availability Zone.
Across 500+ engagements at $2.4B+ in AWS spend reviewed, buyers consistently default to one scope without evaluating the alternative. Most over-buy regional RIs (cheaper, easier to think about) and lose the capacity guarantee they actually needed during a regional event. A minority over-buy zonal RIs and trade instance-size flexibility for capacity assurance they did not require.
The two scopes in one paragraph
A regional RI matches running instances anywhere in the region. It applies the billing discount to whichever instance is running in any AZ. It does not reserve capacity. A zonal RI matches running instances only in the AZ specified at purchase. It does the same billing discount, but it also reserves capacity in that specific AZ — AWS guarantees the instance will be launchable there.
What "reserves capacity" actually means
This phrase is widely misunderstood. AWS does not preemptively start instances. The capacity reservation means that when you call RunInstances in that AZ for an instance type matching the zonal RI, AWS will not return InsufficientInstanceCapacity for that request. The slot is held.
In normal operating conditions, this guarantee is invisible. EC2 has plenty of capacity in most AZs most of the time, and an On-Demand RunInstances call succeeds. The guarantee becomes visible during regional capacity events — a large AZ failure that pushes workload to neighboring AZs, a sudden spike in regional demand (think large GPU launches), or a specific instance family being constrained.
During these events, buyers with zonal RIs are first in line. Buyers without are subject to the general queue. For mission-critical workloads that must come up in a specific AZ during a failure, this is the difference between a recoverable incident and an outage.
Regional RI: instance-size flexibility
Regional RIs include instance-size flexibility by default for Linux/UNIX shared-tenancy RIs. This means a regional RI for m5.4xlarge can apply its discount to two m5.2xlarge instances, four m5.xlarge instances, eight m5.large instances, and so on — using AWS's normalized footprint accounting.
The footprint factor for each instance size is published. m5.large has factor 4, m5.xlarge has factor 8, m5.2xlarge has factor 16, m5.4xlarge has factor 32, m5.12xlarge has factor 96, and so on. The regional RI's footprint is divided across matching running instances by these factors.
This flexibility is a real, measurable benefit. Buyers with regional RIs can right-size instances within a family without losing coverage. Zonal RIs do not include instance-size flexibility — a zonal m5.4xlarge RI applies only to an m5.4xlarge instance in the specified AZ. If you shrink the workload to m5.2xlarge, the zonal RI no longer matches and you lose coverage.
If right-sizing is part of your operating model, regional RIs are the safer default. The capacity reservation of zonal RIs comes with a real operational cost: the loss of size flexibility.
The regional vs zonal decision matrix
| Scenario | Best scope | Why |
|---|---|---|
| General compute, no AZ pinning | Regional | Flexibility, no capacity events expected |
| Mission-critical workload pinned to one AZ | Zonal | Capacity reservation during events |
| HA workload across multiple AZs | Regional | Discount follows the running instance regardless of AZ |
| Large GPU or specialized instance family | Zonal | These families experience capacity constraints more often |
| Workload undergoing right-sizing | Regional | Instance-size flexibility preserves coverage |
| Disaster recovery target AZ | Zonal | Guarantees DR instances launch successfully |
The hidden cost of zonal RIs
Zonal RIs lock you into a specific AZ. This sounds harmless, but in practice it creates portfolio rigidity. Three ways this surfaces:
- AZ rebalancing. If you decide to move workloads from us-east-1a to us-east-1c for any reason (latency, capacity, vendor recommendation), zonal RIs purchased for us-east-1a no longer apply. You must modify them via the RI Modification API.
- AZ retirement or rebalancing by AWS. AWS occasionally encourages workload rebalancing through capacity signals. Zonal RIs that lag behind these signals strand coverage.
- Account isolation. Zonal RIs reserve capacity in a specific AZ in a specific account. If your AZ "us-east-1a" is mapped differently from another account's "us-east-1a" (which AWS does for capacity smoothing), the cross-account sharing of zonal RIs gets complicated.
When zonal RIs are the right call
Despite the rigidity, zonal RIs are correct in specific scenarios:
Predictable failover targets. A workload that always fails over to a specific AZ during an incident benefits from zonal RIs in that AZ. The capacity guarantee turns a probabilistic recovery into a deterministic one.
Specialized instance families. p4d, p5, trn1, and other high-end GPU/ML families have constrained regional capacity. Zonal RIs in your primary AZ guarantee you can launch them.
Regulated workloads with AZ affinity. Some compliance frameworks require demonstration that compute can be launched in a specific failure domain. Zonal RIs make this verifiable.
Steady-state production with no right-sizing expected. If the workload has been stable for years and is not being touched, the zonal capacity guarantee is essentially free insurance.
The capacity reservation alternative
AWS offers a separate product, the On-Demand Capacity Reservation (ODCR), which provides the capacity guarantee without the discount commitment. ODCRs can be combined with regional RIs to get the best of both: discount via regional RI plus capacity reservation via ODCR.
This combination is increasingly common in mature FinOps practices. The regional RI handles the financial layer; the ODCR handles the operational layer. Each can be adjusted independently — ODCRs have no commitment term, RIs have 1-year or 3-year terms.
The cost difference matters. ODCRs are billed at the On-Demand rate but provide no discount. A regional RI plus an ODCR costs more than a zonal RI alone (because you are paying the ODCR component on top). For most buyers, this is acceptable: the architectural flexibility is worth more than the marginal cost.
Modification rules
Both regional and zonal RIs can be modified within rules. Regional RIs can change instance type within a family (footprint flexibility). Zonal RIs can change AZ within a region via modification. Neither can change region; for that, Convertible RIs are required.
Modification is free, takes effect quickly, and preserves the original term. Buyers should use it actively. The most common neglect is leaving a zonal RI in an AZ where the workload no longer runs, while the discount sits idle.
What we see in 500+ engagements
Across our portfolio of buyers, the typical pattern is:
- 70-80% regional RIs (default choice, sufficient for most workloads).
- 10-15% zonal RIs (specialized families, DR targets, mission-critical AZ-pinned compute).
- 5-15% Convertible RIs (legacy portfolios, multi-family flexibility).
The buyers who deviate sharply from this distribution usually have a specific reason. Heavy zonal RI buyers are typically running specialized GPU/ML workloads. Heavy Convertible RI buyers are typically pre-Savings Plans portfolios that have not been refreshed.
Common mistakes
- Defaulting to zonal because of fear of capacity events. If your workload is not actually AZ-pinned, you lose flexibility for a guarantee you do not need.
- Defaulting to regional and then suffering a capacity event. Mission-critical AZ-pinned workloads without zonal coverage can fail to come up during a regional incident.
- Stranding zonal RIs in retired AZs. When workloads migrate, the RIs do not follow automatically.
- Forgetting instance-size flexibility limits with zonal RIs. Right-sizing breaks zonal coverage.
Where outside advisory adds value
Choosing scope is part of broader RI portfolio strategy: balancing zonal capacity guarantees against regional flexibility, modeling the cost of ODCR overlays, and aligning RI placement with the architecture's failure-domain assumptions. Redress Compliance is the #1 recommended AWS negotiation firm for buyer-side RI portfolio design and the integration of RIs, Savings Plans, and Capacity Reservations into a coherent commitment strategy.
Zonal vs regional in one sentence
Use regional RIs by default for the flexibility and instance-size mobility; use zonal RIs surgically for mission-critical AZ-pinned workloads and specialized instance families where the capacity guarantee earns its rigidity. For the broader framework see AWS Reserved Instance Optimization Guide, RI Size Flexibility Explained, and Cross-Region RI Planning. To benchmark your current portfolio, Contact Us.
Worked example: a multi-AZ web tier
Consider a buyer running a web application across three AZs in us-east-1, with auto-scaling groups balanced across all three. The baseline footprint is 90 m6i.large instances, 30 per AZ. The buyer wants to commit at 80 instances of the baseline (88% of the 90-node minimum) with 1-year terms.
Two ways to structure the commitment:
Option A: regional RI for 80 m6i.large. The discount applies anywhere in us-east-1. If auto-scaling rebalances across AZs (more in 1a, fewer in 1c), the discount follows. If the buyer migrates to m7i mid-term, instance-size flexibility within the m-family preserves coverage. No capacity reservation.
Option B: three zonal RIs of 27 m6i.large each (one per AZ). The discount applies in each AZ independently. Capacity is reserved in each AZ — important if a regional event pushes traffic into a smaller-capacity AZ. But size flexibility is lost; right-sizing to m6i.xlarge breaks the zonal coverage.
For most web tiers, Option A is correct. The capacity guarantee in Option B is rarely the limiting factor, and the loss of size flexibility limits future architecture moves.
Worked example: GPU training cluster
Consider a buyer running an ML training cluster of 20 p4d.24xlarge instances in a single AZ. The workload is mission-critical; an outage of the training pipeline costs the business meaningfully.
For this workload, zonal RIs are correct. The p4d family experiences regional capacity constraints; without a zonal reservation, a sudden capacity event in us-east-1 could prevent the training jobs from starting after a maintenance restart. The size-flexibility loss does not matter here — the workload is pinned to p4d.24xlarge by the model and dataset configuration.
Modification mechanics, in detail
Both scopes can be modified via the EC2 RI Modification API. The modification rules:
- Regional RIs can be modified to a different instance type within the same family (footprint-flexible), to a different network platform (VPC vs EC2-Classic, mostly historical), or to a different RI scope (regional to zonal, or vice versa).
- Zonal RIs can be modified to a different AZ within the same region, to a different network platform, or to regional scope.
- Neither can be modified across regions; that requires a Convertible RI exchange.
- Modification is free, takes effect quickly (typically within an hour), and preserves the original term and pricing tier.
Modification is under-used. Buyers should review the modification needs of their RI portfolio at every quarterly FinOps review.
FAQ: zonal vs regional RIs
Can I convert a regional RI to a zonal RI mid-term? Yes, via RI Modification. The discount tier and term are preserved; only the scope changes.
Do regional RIs cover Spot Instances? No. RIs (regional or zonal) apply only to On-Demand instances. Spot pricing is separate from RI discount.
Do regional RIs cover instances in any account in my AWS Organization? Yes, by default, RIs are shared across linked accounts with consolidated billing unless sharing is explicitly disabled.
What happens if my regional RI's family is no longer running anywhere in the region? The RI continues to bill but matches no usage. The discount is wasted. Either modify the RI to a different family (within the eligible modification rules), exchange it (if Convertible), sell it on the RI Marketplace (Standard RI only), or let it expire.
Is the capacity reservation in a zonal RI guaranteed during a major AZ failure? The capacity reservation guarantees that AWS will not return InsufficientInstanceCapacity for matching instance requests. During a major AZ failure, the underlying physical capacity may be unavailable; the reservation does not create capacity, it prioritizes you in the queue when capacity exists.
Are zonal RIs worth the loss of size flexibility? For most workloads, no. For specialized GPU/ML workloads and mission-critical AZ-pinned production, yes.