Multi-Region, Cost Optimization & Cheat Sheet

Table of Contents#

1. The Closing Chapter — Assembling the Full Picture
2. Multi-Region Architecture — Active-Active vs. Active-Passive
3. The Data Tier in a Multi-Region Design
4. Global Traffic Routing, Assembled
5. The Layered Cost Optimization Strategy
6. Reserved Instances vs. Savings Plans — Choosing
7. The 2026 Legacy VM Series Reservation Deadline
8. Rightsizing and Azure Advisor
9. A Full Worked Multi-Region Bootstrap for Meridian Freight
10. Full-Series Quick-Reference Cheat Sheet
11. Common Mistakes and Interview Traps
12. Worked Practice Problems
13. Summary — the Series in Full

The Closing Chapter — Assembling the Full Picture#

Every prior part built one piece of Meridian Freight's Azure footprint in isolation. This chapter assembles them into a genuine multi-region architecture, and closes with the cost discipline that makes running it sustainably affordable — plus a full quick-reference pulling the series' most load-bearing commands into one place.

Multi-Region Architecture — Active-Active vs. Active-Passive#

Why Meridian Freight's shipment-api justifies active-active while rates-db's DR posture (Part 14) stays active-passive, worth stating the underlying reasoning: shipment-api's customer-facing, high-value traffic justifies the added data-consistency complexity active-active requires, while rates-db's slower-changing pricing data doesn't have a strong enough latency/availability requirement to justify that same complexity — the choice should be made per-workload based on genuine business value, exactly the same discipline Part 14 applied to standby tier selection.

The Data Tier in a Multi-Region Design#

Active-active's hardest problem is the data tier — Cosmos DB (Part 9) with multi-region writes enabled handles this natively; Azure SQL's failover groups (Part 9) are inherently active-passive at the data layer even when the application tier above them runs active-active.

az cosmosdb update --name cosmos-meridian --resource-group rg-shipment-api-prod \
  --enable-multiple-write-locations true

Worth stating a genuine tradeoff explicitly, not glossing over it: multi-region writes in Cosmos DB mean two regions can accept a write to the SAME logical item concurrently — Cosmos DB resolves the resulting conflict automatically (last-writer-wins by default, or a custom conflict resolution policy), but the application needs to be genuinely designed with this possibility in mind, not simply assume conflicts never happen because they're rare in practice.

Global Traffic Routing, Assembled#

This is Part 6's Front Door, Part 9's Cosmos DB, and Part 10's AKS/Container Apps assembled into the actual multi-region topology those chapters were building toward individually — Front Door's health probes automatically stop routing to an unhealthy region, the practical payoff of Part 6's origin health-probe configuration applied at true multi-region scale.

The Layered Cost Optimization Strategy#

Why layering all four, rather than picking just one, is worth stating as the actual current best practice: reserve the predictable baseline for Reserved Instances' deepest discount, cover load that shifts across VM families/regions with Savings Plans' added flexibility, leave genuinely unpredictable bursts on pay-as-you-go, and route fault-tolerant batch work (Part 3's Spot VM recommendation) to Spot — a single strategy applied uniformly leaves real savings on the table for at least one of these four traffic shapes.

Reserved Instances vs. Savings Plans — Choosing#

Why choosing based on genuine footprint STABILITY, not discount percentage alone, matters concretely: a 7-point deeper discount from a Reserved Instance is worth meaningfully more in absolute terms at real scale (a real, quantifiable annual difference on high spend) — but only if the reservation actually gets used as committed; a reservation for a VM family the workload later migrates away from wastes the committed spend entirely, which Savings Plans' cross-family flexibility avoids.

The 2026 Legacy VM Series Reservation Deadline#

A genuinely important, current, time-sensitive fact worth stating explicitly: new or extended reservations for certain legacy VM series remain available only through June 30, 2026 — a 3-year term taken before that deadline locks in current discount conditions until roughly 2029, but after the deadline, the only paths forward are migrating to current-generation VM sizes (v5/v6, referenced throughout Part 3) or switching to the more flexible Savings Plan model instead.

Why this deserves a concrete decision NOW rather than being deferred, worth stating plainly: an organization still running meaningful workloads on a legacy VM series has a genuinely closing window to either lock in a final long-term reservation or commit to a migration plan — waiting past the deadline forecloses the reservation option entirely, not just making it slightly less advantageous.

Rightsizing and Azure Advisor#

az advisor recommendation list --category Cost --output table

Revisiting Part 1's Azure Advisor introduction with cost specifically in focus: Advisor's rightsizing recommendations (a VM consistently running at 10% CPU utilization, an underutilized Premium SSD) are worth reviewing on a recurring cadence — the same "living document, not a one-time snapshot" discipline Part 14 recommended for migration assessments applies identically to cost rightsizing.

A Full Worked Multi-Region Bootstrap for Meridian Freight#

# 1. Cosmos DB with multi-region writes for shipment-api's active-active data tier
az cosmosdb update --name cosmos-meridian --resource-group rg-shipment-api-prod \
  --enable-multiple-write-locations true

# 2. Container Apps/AKS deployed identically in both regions
az containerapp create --name shipment-api --resource-group rg-shipment-api-prod \
  --environment env-meridian-eastus --image acrmeridianfreight.azurecr.io/shipment-api:1.0
az containerapp create --name shipment-api --resource-group rg-shipment-api-westeurope \
  --environment env-meridian-westeurope --image acrmeridianfreight.azurecr.io/shipment-api:1.0

# 3. Front Door with both regional origins, health-probe-driven routing
az afd origin create --origin-group-name og-shipment-api --profile-name fd-meridian \
  --resource-group rg-networking-prod --origin-name origin-eastus --priority 1
az afd origin create --origin-group-name og-shipment-api --profile-name fd-meridian \
  --resource-group rg-networking-prod --origin-name origin-westeurope --priority 1

# 4. A layered Reserved Instance + Savings Plan purchase for the predictable baseline
az reservations reservation-order calculate --reservation-order-id "<order-id>" \
  --sku "Standard_D4s_v5" --location eastus --term "P3Y"

Full-Series Quick-Reference Cheat Sheet#

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: Meridian Freight adopts Cosmos DB multi-region writes for shipment-api's order data without any explicit conflict-resolution design, assuming "concurrent writes to the same order are basically impossible in practice." Months later, a rare but real incident occurs: a customer service rep and an automated system both update the same order's status within milliseconds, from different regions, and the resulting state is inconsistent with what either update intended. What was the design gap?

Answer: The gap was treating "rare" as equivalent to "safe to ignore" rather than designing explicit handling for it — multi-region writes make concurrent updates to the same logical item a genuine, if infrequent, possibility, and Cosmos DB's default last-writer-wins conflict resolution silently picks one write over the other with no application-level awareness that a conflict even occurred. The fix is designing conflict handling deliberately: either a custom conflict resolution policy encoding actual business logic (e.g., certain status transitions should never be overwritten by an earlier-intent update) or restructuring the write pattern to avoid the same item being concurrently writable from multiple regions in the first place. The underlying lesson generalizes: enabling a powerful capability like multi-region writes without engaging with what it actually changes about failure modes is exactly the kind of gap that surfaces during a real incident rather than during design review.

Problem 2: Meridian Freight considers Reserved Instances for its stable AKS node pool footprint (Part 10), which has been running on the same VM family and region for over a year with genuinely predictable size and utilization. A team member argues for Savings Plans instead, "for the flexibility, just in case." Evaluate this reasoning.

Answer: The reasoning undersells a footprint that's already demonstrated genuine stability — a workload that's run on the same VM family and region for over a year with predictable utilization is precisely the profile Reserved Instances are designed for, and Reserved Instances offer a meaningfully deeper discount (up to 72% vs. Savings Plans' up to 65%) specifically because they don't need to hedge against footprint change. "Flexibility just in case" has a real, quantifiable cost — the roughly 7-point discount difference this chapter's research surfaces amounts to real money at scale — and paying that premium for flexibility the workload's own history suggests it won't need isn't a sound default. Reserved Instances are the better choice here; Savings Plans remain the right tool for a workload whose service mix genuinely might shift, which this one, based on its actual track record, does not appear to be.

Summary — the Series in Full#

This series has built Meridian Freight's Azure footprint end to end: governance and identity (Parts 1-2) as the foundation everything else depends on; compute and four full parts of networking (Parts 3-7) establishing how workloads run and connect; storage and databases (Parts 8-9) as the data layer; containers, serverless, and messaging (Parts 10-11) as the modern application architecture; security, observability, and business continuity (Parts 12-14) as the operational discipline wrapping all of it; and CI/CD, multi-region design, and cost optimization (Parts 15-16) as how it all actually gets deployed, scaled globally, and paid for sustainably.

• Every Azure mechanism in this series maps back to a general principle already covered elsewhere in this course, and to its AWS/GCP equivalent where one exists — the goal throughout has never been memorizing Azure trivia in isolation.
• Layer cost optimization strategies rather than picking one — Reserved Instances for the stable baseline, Savings Plans for shifting load, Spot for interruptible batch work, pay-as-you-go for genuine bursts.
• Multi-region architecture decisions (active-active vs. active-passive) should be made per-workload based on genuine business value, exactly the same discipline this series applied to every other design decision — subscription structure, standby tiers, migration strategy.
• This series' own repeated pattern — research the current state, don't assume training-data familiarity is still accurate — matters especially in a platform that changes as continuously as Azure does, evidenced by the real, current 2026 facts woven throughout: private-subnets-by-default, Key Vault's RBAC default, Basic Load Balancer's retirement, and more.

This concludes the Azure Cloud Architecture series. For hands-on practice against everything covered here, see this topic's questions.md companion, and the cross-links to the AWS and GCP Cloud Architecture series for the same concepts implemented by the other two major cloud providers.