Multi-Region Application Design with AKS, Front Door, and Azure PaaS

The Gap Between Diagrams and Reality

I pushed a multi-region design once that absolutely didn't need to be multi-region. The architecture looked gorgeous on the whiteboard, the diagrams were impressive, the stakeholders loved it, and it felt like the responsible thing to do. Then we spent months debugging cross-region replication issues for a workload that could've been perfectly fine in a single region with availability zones. Boy, that was a humbling experience. The moment we tore down the secondary region and simplified everything, the on-call rotation stopped being miserable and the team actually started shipping features again.

The gap between those pretty diagrams and systems that actually work in production is enormous. Multi-region design is hard not because the technology is complex - it's hard because it forces uncomfortable questions with no generic answers. Should your compute be active-active while your database is active-passive? Is a 15-minute RTO acceptable during a regional outage, or do you need five minutes? Do you write to one region and replicate, or just accept eventual consistency? How do you test failover without breaking production? These questions don't have one-size-fits-all answers, so they require honest conversations about business requirements, acceptable complexity, operational capacity, and failure tolerance.

I've had enough of those conversations to know there are no universal answers, only the right ones for your specific situation. Resilience isn't a checkbox you tick once - it's something you build up over time and keep maintaining, which is why the design decisions matter so much.

When Is Multi-Region Actually Justified?

The first honest conversation is whether multi-region is needed at all. Single-region applications with proper Azure availability zones (three fault-isolated zones per region, each with one or more datacenters) achieve substantial durability, so if your requirement is zone-level failure tolerance, you probably don't need multi-region.

In my experience, multi-region is justified when at least one of these applies to your situation:

Geographic distribution with material latency impact: Your users are spread across continents and application latency actually affects user experience or business outcomes (real-time trading, interactive mapping, multiplayer gaming), which makes regionalizing compute and data services defensible.

Regulatory or data-residency mandates: Certain jurisdictions require data to remain in specific regions. The scope of what must be regional is narrower than initially assumed, which matters for implementation.

Hard business requirement for regional outage tolerance: Some workloads just can't tolerate a regional outage - financial services, some healthcare systems, and critical infrastructure fall here. But "could" tolerate outages and "must" tolerate them are different requirements, so be specific.

Recovery targets that require distributed capacity: If your RPO or RTO is tight enough that recovering from backup in another region violates those targets, active-active or warm-standby become necessary. "As low as possible" isn't a requirement though - give me actual numbers.

Customer or regulatory commitments: Your business model or contracts may require regional resilience.

What should not drive multi-region decisions: competitor actions, cloud prestige, or other organizations' examples. Just because someone else went multi-region doesn't mean you should. I know, I know - the FOMO is real, but it's not a valid architecture driver :)

Every region adds deployment complexity, replication concerns, regional-specific failure modes, cross-region observability challenges, testing obligations you may not meet, and cost. If none of the above applies, resist multi-region. Zone-level redundancy within a single region, combined with strong disaster recovery procedures, represents better engineering effort ROI in almost every case.

The Multi-Region Decision Table

Be honest about which category you're in - there's no shame in single-region done well. If you're still here, let's talk about how to build it right.

Active-Passive vs. Active-Active

graph TD
    AFD["Azure Front Door\nGlobal LB + WAF"] --> AKS1["AKS Primary\nWest Europe"]
    AFD --> AKS2["AKS Secondary\nNorth Europe"]
    AKS1 --> SQL1[("SQL Primary")]
    AKS2 --> SQL2[("SQL Secondary")]
    SQL1 -.->|"Failover Group"| SQL2
    AKS1 --> REDIS1[("Redis Primary")]
    AKS2 --> REDIS2[("Redis Replica")]
    REDIS1 -.->|"Geo-Replication"| REDIS2
    AKS1 --> KV1["Key Vault\nPrimary"]
    AKS2 --> KV2["Key Vault\nSecondary"]

Alright, this is where real architecture work begins. I've seen teams jump straight to active-active since it looked better on the slide deck, and the result was basically active-passive with extra infrastructure cost and untested failover paths. Don't do that.

Here's how the two models actually compare:

Active-Passive: Simplicity as Strength

In active-passive, one region handles all traffic while the other stands ready but doesn't serve user traffic until primary fails.

When to use active-passive:

• RTO is measured in minutes, not seconds
• You tolerate brief degradation during failover (database replicas warming up, routes converging, maybe a few dropped connections - the kind of blip users forgive if it's short)
• Capacity requirements are asymmetric, with one primary region and others as contingency
• Your stateful components have a clear primary and read replicas
• The team hasn't yet built the operational muscle for active-active, and there's nothing wrong with admitting that

Operational advantages:

Write models aren't distributed. Primary database receives writes and replicas catch up asynchronously. You can prioritize the primary region for deployments, which reduces coordination complexity, and debugging is straightforward since the active region is the one receiving traffic. Testing is periodic rather than continuous, and your secondary region can run reduced capacity (like smaller database instances for read replicas), so you still pay but not at full primary scale.

Active-Active: Justified Complexity

In active-active, all regions serve traffic concurrently. Traffic is distributed across regions based on latency or geography, and all regions participate in writes or writes are carefully coordinated.

When to use active-active:

• Your RTO requirement is measured in seconds, and you need to handle regional failure without user-visible degradation
• Traffic is naturally distributed geographically, and routing to the nearest region improves user experience
• You have the operational maturity to handle distributed systems problems: write coordination, eventual consistency, or strong consistency at scale
• You test regional failures regularly (monthly or more frequently) as part of normal operations

What active-active requires:

• Write distribution: Every region can accept writes, either independently (eventual consistency) or through coordination
• Replication: Changes in one region must reach other regions with bounded latency, and you need to monitor that lag continuously
• Conflict resolution: When writes happen in different regions concurrently, one wins (last-write-wins) or you detect conflicts and surface them
• Data consistency model: Strong consistency (slower across regions) or eventual consistency (faster, but replication lag is observable by clients)
• Traffic distribution: Front Door and application logic need to be region-aware
• Operational testing: You can't declare "active-active" and never test, so regular and intentional regional outage simulations are non-negotiable

The Honest Choice

I'd recommend starting with active-passive and evolving to active-active only when justified by requirements and operational capacity. Eventual consistency is hard to reason about and introduces failure modes you'll discover in production, write coordination is complex, and testing is mandatory but expensive. In my experience, the complexity doesn't match what the business actually needs more often than not.

Now, a pattern I keep running into: teams declare "active-active" since both regions have infrastructure, but in operations they deploy primary first, secondary later, never test regional failover, and debug as if only one region matters. That's just active-passive with extra cost. When primary fails and secondary doesn't work, they learn the hard way. I've watched this play out at three different organizations, and the post-incident reviews always arrive at the same conclusion - they were never really active-active, they just had two sets of infrastructure with one set collecting dust.

That being said, a useful middle ground is warm-standby: secondary regions have full capacity and can take traffic, but Front Door actively steers traffic toward primary under normal conditions.

Azure Front Door's Actual Role

Azure Front Door is where multi-region discussions start for a lot of teams. Its role is precisely bounded, and misunderstanding that scope creates false confidence.

Front Door is a global reverse proxy, and it:

• Terminates TLS at edge locations nearest your users
• Probes backend health regularly and removes unhealthy backends from the active set
• Routes traffic to backends based on latency, geography, session affinity, priority, or weight
• Caches responses at edge locations, reducing origin load
• Enforces WAF policies at the edge

These are valuable capabilities, and you do need a way to direct user traffic intelligently across regions.

What Front Door Does Not Do

• Make your application stateless. If your app depends on sticky session routing, that's an application problem, which Front Door can't solve for you.
• Coordinate writes across regions. Front Door can't manage database write distribution - that's entirely on your data layer.
• Handle cache coherence. If your distributed cache is out of sync across regions, Front Door can't fix it.
• Solve data consistency. Different regions operating on different versions of truth is a data architecture problem, which no amount of routing logic will address.
• Guarantee zero-downtime failover. If a region fails, in-flight requests to that region fail. Front Door removes the unhealthy region from the active set, but already-routed requests are lost.

I've had to explain this more than once: whatever fancy routing rules you configure, Front Door orchestrates traffic and that's it. It won't fix architectural problems upstream.

Minimal Front Door Setup

Now, let's set it up. Minimal Front Door configuration for active-passive with priority routing:

resource "azurerm_cdn_frontdoor_origin_group" "multi_region" {
  name                     = "primary-secondary-group"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.main.id

  health_probe {
    interval_in_seconds = 60
    path                = "/health"
    protocol            = "Https"
  }

  load_balancing {
    sample_size                = 4
    successful_samples_required = 3
  }

  session_affinity_enabled = false
}

resource "azurerm_cdn_frontdoor_origin" "primary" {
  name                           = "primary-aks"
  cdn_frontdoor_origin_group_id  = azurerm_cdn_frontdoor_origin_group.multi_region.id
  enabled                        = true
  host_name                      = azurerm_kubernetes_cluster.east.fqdn
  origin_host_header             = azurerm_kubernetes_cluster.east.fqdn
  certificate_name_check_enabled = true
  priority                       = 1
  weight                         = 100
  https_port                     = 443
}

resource "azurerm_cdn_frontdoor_origin" "secondary" {
  name                           = "secondary-aks"
  cdn_frontdoor_origin_group_id  = azurerm_cdn_frontdoor_origin_group.multi_region.id
  enabled                        = true
  host_name                      = azurerm_kubernetes_cluster.westeurope.fqdn
  origin_host_header             = azurerm_kubernetes_cluster.westeurope.fqdn
  certificate_name_check_enabled = true
  priority                       = 2
  weight                         = 100
  https_port                     = 443
}

Primary (priority 1) receives all traffic until unhealthy, at which point secondary takes over.

For true active-active, you remove priority ordering and weight both regions equally. But then the entire operational burden moves to your data layer and application consistency logic, which is where the real complexity lives. Right?

Do Your Health Probes Actually Test Anything?

Here's something that tripped me up: health probes detect complete regional failure, but they won't catch degraded application behavior. If your health probe returns 200 OK but your database is failing 99% of requests, the probe sees success and routes traffic to the region. Your health probe must actually test the paths that matter:

GET /api/v1/health/deep
  - Checks that the service is running
  - Attempts a database read
  - Verifies connectivity to critical dependencies
  - Returns 200 OK only if all checks pass
  - Returns 503 Service Unavailable if any check fails

A shallow health probe is pretty much the same as no health probe once things start going sideways. I've seen this one bite teams hard, where everything looks green on the dashboard while users are getting errors.

Data Topology: The Hardest Problem

In every multi-region incident I've been involved with, the root cause wasn't compute - it was data topology. If your compute is active-active but your data is effectively single-region, you have an inconsistent architecture. You're paying for multi-region complexity without the benefits.

Consistency Models and Their Costs

Something I always come back to when evaluating data services: you're always trading consistency against latency and availability.

Strong consistency: Any write is immediately visible to all reads, which means no stale data. You trade latency and availability for correctness.

Eventual consistency: Writes propagate asynchronously, so reads may return stale data. This enables multi-region writes but sacrifices guaranteed freshness.

I've learned that neither model is universally correct - you pick based on what your specific use case can tolerate.

When strong consistency is required:

• Financial transactions, because trading on stale price data is dangerous and regulators won't be sympathetic
• Flight booking - two people can't be booked in the same seat, and the airline's reputation takes a hit every time it happens
• Medical records where stale medication lists cause harm
• Inventory systems where double-selling is expensive

When eventual consistency is acceptable:

• News sites, where a few seconds of delay in article visibility is perfectly fine
• Social media feeds - comment delays are expected and users don't really notice, which is why most major platforms chose this model early on
• User preferences, since nobody's going to file a bug because their theme change took an extra second to propagate
• Analytics dashboards where slightly stale metrics are expected

Azure PaaS Services: Real Tradeoffs

Going further, let me break down the actual PaaS options and what they give you:

Azure Cosmos DB:

Built for multi-region from the ground up. It supports multiple consistency levels, automatic replication, and multi-master writes, which makes it multi-region capable with automatic failover and active-active possible. The catch? It's expensive at scale (and I mean really expensive once you start adding RUs), the learning curve for consistency models is real, it isn't relational, and it's overkill for a lot of applications. Use Cosmos DB when you need true multi-region, multi-master writes and can accept non-relational data modeling.

Azure SQL Database with Failover Groups:

Supports automatic failover groups that replicate to a secondary region. You can direct reads to the secondary (read-only) while writes go only to primary. You get relational with ACID guarantees, automatic failover with configurable RTO, it's cheaper than Cosmos DB, and the secondary stays up-to-date automatically. The downside is that it's active-passive only, failover isn't instantaneous (seconds to minutes), and the secondary is read-only until failover. Use Azure SQL with failover groups when you need relational consistency and can tolerate writes always being in one region. This is the most common pattern, and it's the right one for most teams.

Azure Cache for Redis:

Deployed with geo-replication links across regions, where primary accepts writes and secondary is read-only and kept in sync. It's fast, supports complex data structures, and enables smart cache invalidation. But cache hit rate is paramount, replication is asynchronous (eventually consistent), and it's not a long-term data store. Use Redis for caching data that lives elsewhere, and don't treat it as your primary data store.

Azure Storage (Blob, Queue, File Share):

Supports geo-redundant storage (GRS) or read-access geo-redundant (RA-GRS), where writes go to primary and reads can come from either. It's cheap with built-in durability and works at scale. Not suitable for frequent application queries though, write availability during failover is limited, and replication is asynchronous. Use Azure Storage for long-term, infrequently updated data, and don't use it as your primary application state store.

Design Principles

Don't replicate a single-region design across regions. Instead:

1. Understand your consistency requirement for each piece of data. Does this need strong consistency, or is eventual consistency acceptable?
2. Choose the service matching that requirement. If you need strong consistency across regions, go with Cosmos DB with strong consistency or a read-write primary with read-only replicas. If eventual consistency is acceptable, you have more options to choose from.
3. Design for the regions you have, not the region you wish you had. Secondary regions might not always be responsive, which means your application logic needs to handle that gracefully.
4. Accept that some data won't replicate across regions. Not everything needs to be global - user session caches in the US don't need to be visible in Europe.

Observability Across Regions

I already find single-region observability hard enough, and multi-region adds a geography dimension on top of everything else. You need to know regional latency (which region is slower), cross-region replication lag (how far behind is the secondary), health by region, traffic distribution by region, and errors by region - whether they're concentrated in one region or spread across both. Having all of this visible at once is what lets you handle regional incidents in minutes instead of spending hours just figuring out what's happening.

So proper setup requires:

1. Instrumentation in every region: Application code must emit telemetry with region tags.
2. Distributed tracing: Trace requests end-to-end, even across regions.
3. Region-aware dashboards: Show health, latency, and error rate by region side-by-side.
4. Region-specific alerts: Trigger when a specific region is degraded.

Example - instrumentation that tags all telemetry with region:

public class MultiRegionTelemetry
{
    private readonly TelemetryClient _client;
    private readonly string _region;

    public MultiRegionTelemetry(TelemetryClient client, IConfiguration config)
    {
        _client = client;
        _region = config["Azure:Region"] ?? "unknown";
    }

    public void TrackRequest(string operationName, long durationMs, int statusCode)
    {
        var properties = new Dictionary<string, string>
        {
            { "region", _region },
            { "operationName", operationName }
        };

        var metrics = new Dictionary<string, double>
        {
            { "durationMs", durationMs }
        };

        _client.TrackEvent("request_completed", properties, metrics);
    }
}

Regional failures are progressive: error rate increases, latency increases, specific endpoints fail. Monitor for these signals, not just "region is down." By the time you get a full region failure alert, your users have been suffering for a while already.

How Do You Prove Failover Actually Works?

If you haven't tested that your application survives a regional outage, you don't actually know it will. I learned this the hard way. We had a beautiful active-passive setup, everything looked correct on paper, and the first time we actually needed it the secondary database hadn't finished initial sync from a schema migration two weeks prior. Nobody checked :) So yes, failover testing is expensive in time and carries real risk, but after that experience I can tell you it's the only way to know your multi-region setup actually works.

Failover Test Tiers

Tier 1: Synthetic failover (low risk):

You disable the primary region in your load balancer without taking the region down, so traffic routes to secondary. Then you verify that requests complete successfully, databases are responsive, and observability shows healthy secondary traffic, and revert the change. This answers: "If I had to failover, would secondary actually work?"

Tier 2: Controlled regional shutdown (medium risk):

You actually take the primary region out of service (or simulate it by blocking traffic), which is realistic since it tests the real behavior of the region going offline.

Procedure:

1. Schedule a maintenance window
2. Trigger regional shutdown (pause production traffic)
3. Observe Front Door behavior (how long until it marks primary unhealthy)
4. Verify secondary automatically takes over
5. Test critical paths (login, create, read, delete) in secondary
6. Check data consistency (if using replicas, verify secondary is caught up)
7. Restore primary
8. Verify primary takes back over correctly
9. Document RTO, RPO, and any gotchas

This answers: "What happens when a region actually fails? How long do users notice? Is our observability accurate?"

Tier 3: Simultaneous region failure (high risk, rare):

You simulate both regions being unavailable, which tests your disaster recovery procedures. Only do this if RTO requirements demand it and your backup region is autonomous.

Failover Testing Antipatterns

Not testing at all. If you've never manually triggered a failover, you don't actually know if your architecture works - you're just hoping.

Testing without a rollback plan. If your test reveals a problem, you need to be able to restore the primary quickly. Have a documented rollback procedure before you start, and make sure more than one person on the team knows how to execute it.

Testing too infrequently. Code changes, platform updates, and database configurations all evolve over time, so failover behavior can shift underneath you. Serious multi-region systems test quarterly or monthly. I've seen teams pass a failover test in January and then discover in July that a schema migration broke replication three months earlier - nobody checked because the next drill wasn't scheduled until Q3.

Not automating the test. Manual failover tests are brittle. Automate the procedure and run it via a scheduled job.

Declaring success without understanding the failure. If failover reveals slow recovery or inconsistency, you need to understand why. Was it database replication lag? Front Door taking too long to detect failure? Application slow to start? The root cause matters more than the pass/fail label.

Deploying to both regions simultaneously. You deploy new code to both regions, a subtle bug manifests, and both regions go down at once. Deploy sequentially so a bad deploy only takes down primary while secondary can still failover.

Practical Architecture: Active-Passive Multi-Region

Anyway, to ground this discussion, here's a realistic architecture that many organizations use successfully.

The Setup

• Front Door: Global entry point, routes to regional AKS clusters in active-passive mode
• AKS Clusters: East US (primary) and West Europe (secondary, warm standby)
• Azure SQL: Primary in East US with automatic failover group replicated to West Europe
• Redis: Geo-replication from East US to West Europe
• Key Vault: Replicated across regions, though you should verify secret sync status periodically since it can lag
• Application Insights: Centralized observability across both regions

The Recovery Profile

• RTO: 2 - 5 minutes (Front Door detects failure and shifts traffic)
• RPO: Approximately 5 seconds (database replication lag)
• Complexity: Medium (active-passive is simpler than active-active)

You're looking at a few minutes of degradation during a regional outage, not hours, which for most workloads is more than acceptable.

Failover Procedure

1. Front Door health probes indicate primary region unhealthy
2. Front Door automatically routes new traffic to secondary
3. In-flight requests to primary fail, and clients retry via Front Door, which routes to secondary
4. Azure SQL failover group promotes secondary database to writable. This is automatic only with Microsoft-managed policy (minimum 1-hour grace period), while customer-managed policy (recommended) requires manual initiation via CLI, portal, or API
5. Redis failover is manual (you promote read-only replica to primary)
6. Verify requests completing and databases responsive in secondary
7. Once primary recovers, don't gratuitously fail back. Let it sit as cold backup for stability verification before failing back during a maintenance window

Operational Maturity in Practice

I keep reminding teams that multi-region isn't something you set up once and walk away from. You need:

1. Accurate runbooks: Documented procedures for failover and failback, which you refer to during actual incidents - not as decoration, but as something you actually need under pressure.
2. Regular failover drills: Every quarter, simulate a region failure and walk through failover. Verify secondary works, observability catches the issue, and you can failback without drama.
3. Cross-region observability: Dashboards and alerts showing both regions simultaneously, with replication lag, health status, and error rates by region all in one view.
4. Monitoring of the monitoring: Your health probes must themselves be monitored, since if the health probe is broken you don't get alerts about region failures. Yes, it's turtles all the way down :)
5. Honest communication: Document what your system can and can't survive. If you can tolerate 2 minutes of downtime during regional failure but not seconds, say so.
6. Capacity planning: Your secondary region must have enough capacity to handle primary traffic. If primary handles 10k requests per second, secondary must handle it too - and you should validate this with load testing, not just provisioning similar SKUs.
7. Staged deployments: Deploy across regions sequentially, never all at once. A bad deploy to both regions simultaneously is the fastest way to turn a recoverable issue into a full outage.

Resilience Is a Choice, Not a Feature

I for one have moved from pushing multi-region everywhere to being much more deliberate about when it's justified. The cost savings and operational simplicity of single-region-done-right are underrated. When I do build multi-region now, I start with active-passive every time and only evolve to active-active when the business requirements actually demand it, not because it looks better on an architecture diagram.

If I had to boil this down: require multi-region only when justified, choose active-passive unless active-active is truly required, design data topology intentionally since consistent compute with inconsistent data is a false architecture, test failover regularly, be honest about RTO and RPO, and build operational capability slowly. Start with single-region mastery and zone-level redundancy. Upgrade to active-active only when required and after you've got the operational chops to manage it.

Multi-region systems are capable of real resilience, but they're not simple. Your job is to make them as simple as your requirements allow, and then operate them with care.

That being said, have a good one!