Multi-Region Azure Architecture: Traffic Routing and Data Replication

Global Traffic Routing Services

When you have application instances running in multiple regions, you need a mechanism at the front door to intelligently route incoming user requests. This "global load balancer" must decide which region should handle a given request based on factors like performance, health, or a predefined failover order.

Azure provides a portfolio of load balancing services, which can be broadly categorized along two axes: Global vs. Regional and HTTP(S) vs. Non-HTTP(S). For multi-region architectures, we are primarily interested in the global services.

As the article highlights, our main contenders for global, multi-region routing are Azure Front Door and Azure Traffic Manager. A third, more specialized option is the Cross-Region Load Balancer. Let's compare them.

Azure Traffic Manager: DNS-Based Global Routing

Azure Traffic Manager operates at the DNS layer. When a client requests your domain name (e.g., www.contoso.com), Traffic Manager's DNS servers respond with the IP address of one of your regional endpoints. The "load balancing" is the intelligent selection of which IP address to return.

• How it works: It uses various routing methods:

  • Priority: Directs all traffic to a primary endpoint. If it becomes unhealthy, traffic is routed to a secondary endpoint. This is a perfect match for the active-passive disaster recovery pattern.
  • Performance: Responds with the endpoint that has the lowest network latency for the client. This is ideal for improving responsiveness for a global user base.
  • Weighted: Distributes traffic across endpoints based on assigned weights, useful for gradual rollouts or balancing capacity in an active-active pattern.
  • Geographic: Directs users to specific endpoints based on their geographic location, useful for data sovereignty or localization.

• Strengths:

  • Protocol Agnostic: Since it's just DNS, it can route any type of internet-facing traffic (HTTP, FTP, custom TCP/UDP protocols), as long as the endpoint is accessible via a public IP.
  • Simplicity: It's relatively simple to configure.

• Weaknesses:

  • Failover Speed: Failover is dependent on the DNS Time-to-Live (TTL). Clients and DNS resolvers will cache the IP address for the duration of the TTL. If an endpoint fails, traffic will continue going to the failed endpoint until the TTL expires and clients re-query DNS. This can lead to an RTO of several minutes.
  • No Application-Layer Features: It does not see or process the traffic itself. It provides no features like SSL offload, Web Application Firewall (WAF), or caching.

Azure Front Door: Global Application Delivery Network

Azure Front Door is a modern, global Layer 7 (HTTP/HTTPS) load balancer and content delivery network (CDN). It acts as a global reverse proxy, terminating user connections at one of Microsoft's many points of presence (PoPs) around the world and then forwarding requests to your backend origins over Microsoft's private global network.

• How it works: Front Door uses the same routing methods as Traffic Manager (priority, weighted, latency-based) but at the HTTP request level. Because it terminates the connection, it can fail over almost instantaneously without being subject to DNS TTL delays.

• Strengths:

  • Fast Failover: Failover is typically sub-minute, making it ideal for high-availability scenarios with low RTO requirements.
  • Application Acceleration: By terminating connections close to the user (Anycast) and using Microsoft's backbone network, it can significantly improve application performance.
  • Rich Feature Set: Provides built-in WAF, SSL offload, caching, URL-based routing, and more. It is a comprehensive solution for modern web applications.

• Weaknesses:

  • HTTP/HTTPS Only: It cannot be used for non-HTTP protocols.
  • Higher Cost & Complexity: It is a more sophisticated and generally more expensive service than Traffic Manager.

Cross-Region Load Balancer: Global Layer 4 Routing

What if you need global load balancing for a non-HTTP/S application? This is the niche filled by the Cross-Region Load Balancer. It is a global, public-facing Layer 4 (TCP/UDP) load balancer.

• How it works: It provides a single global static public IP. When a client connects, the service routes the traffic to the backend regional load balancer in the closest Azure region using a geo-proximity algorithm.

• Strengths:

  • Global Layer 4: It's the native Azure solution for global TCP/UDP load balancing.
  • Client IP Preservation: Unlike many proxy services, it preserves the original client IP address, which is often crucial for network logic, logging, and security.

• Weaknesses:

  • Specific Use Case: It's not a general-purpose replacement for Front Door or Traffic Manager. Its purpose is very specific to globally balancing Layer 4 workloads.

Decision Framework for Traffic Routing

Now that we can get traffic to our regions, we must tackle the arguably more complex problem: keeping the data in sync.

Data Replication Services

Synchronizing data across geographically distant regions is a fundamental challenge in distributed systems. The primary trade-offs revolve around consistency, latency, and availability. Azure provides several services with built-in features for cross-region data replication.

Relational Data: Azure SQL Database

For relational workloads, Azure SQL Database provides robust replication capabilities through auto-failover groups.

• How it works: A failover group contains a primary server (which handles all write operations) and a secondary server in a different region. Data is asynchronously replicated from the primary to the secondary. You are given a single connection string for reads/writes and another for read-only access.
• Active-Passive: In an outage of the primary region, you can initiate a failover (manually or automatically). The secondary server is promoted to primary, and the connection string automatically routes traffic to the new primary. This perfectly implements the active-passive DR pattern for a relational database, providing a low RPO (typically seconds) and an RTO of under an hour.
• Active-Active (for Reads): Even in normal operation, you can use the read-only connection string to direct reporting or analytical workloads to the secondary replica. This offloads the primary server and provides lower-latency reads for users closer to the secondary region.

Globally Distributed NoSQL: Azure Cosmos DB

If your application requires an active-active architecture with low-latency writes from multiple regions, Azure Cosmos DB is the purpose-built solution.

• How it works: Cosmos DB is a globally distributed, multi-model NoSQL database. You can designate multiple regions as writable. When an application writes data to its local Cosmos DB endpoint in any of these regions, Cosmos DB transparently replicates that write to all other regions.
• Multi-Region Writes: This is the key enabler for a true active-active application tier. Users in Europe can be served by an application instance in West Europe that writes to the local West Europe Cosmos DB replica, while users in the US are served by an instance in East US writing to its local replica.
• Configurable Consistency: It offers a spectrum of consistency models, from Strong (reads are guaranteed to see the latest write, but with higher latency) to Eventual (reads may see stale data, but with the lowest latency). This allows you to make a deliberate trade-off between consistency and performance, a critical architectural decision.

Object Storage: Azure Storage

For unstructured data like images, videos, and backups, Azure Storage provides geo-redundancy options.

• GRS (Geo-Redundant Storage): Asynchronously copies your data to a secondary region hundreds of miles away. In the event of a primary region outage, Microsoft executes a failover to the secondary region. You cannot access the data in the secondary region unless this failover occurs. This aligns with a cold/warm spare active-passive model.
• RA-GRS (Read-Access Geo-Redundant Storage): The same as GRS, but it also provides a read-only endpoint for the data in the secondary region. This allows you to design applications that can read data from the secondary region for load balancing or in case of primary region unavailability, fitting a warm spare active-passive or an active-active (for reads) pattern.

Decision Framework: SQL Database vs. Cosmos DB

Choosing between Azure SQL Database and Cosmos DB is a critical architectural decision point for global applications. Your background in software engineering will make the implications of this choice clear, as it deeply influences application design.

Here is a summary of the key decision factors:

Putting It All Together: A Reference Architecture

Let's visualize how these services combine in a well-architected multi-region web application.

Let's break down this architecture:

1. Global Traffic Routing: Azure Front Door is the single entry point for all users. It provides a WAF for security and routes users to the web app in the region with the lowest latency. If one region's App Service becomes unhealthy, Front Door will automatically route all traffic to the other region.
2. Application Tier: The core application logic is hosted in Azure App Service in two separate regions. This is our "deployment stamp."
3. Data Tier (Relational): Azure SQL Database is used for relational data. It is configured with geo-replication, with Region 1 as the primary write region and Region 2 as a readable secondary. The web app in Region 2 can serve reads locally but must send write commands across to Region 1.
4. Data Tier (Cache): Azure Cache for Redis is deployed in each region to provide high-performance, in-memory caching, reducing latency and load on the SQL database.
5. Data Tier (Secrets): Azure Key Vault is used in each region to securely store application secrets like database connection strings.

This architecture represents a common and powerful pattern that balances reliability, performance, and cost. It provides disaster recovery via failover to Region 2 and enhances performance via globally distributed reads and caching.

Conclusion

In this lesson, we bridged the gap from architectural patterns to specific service selection for multi-region designs. You now have a framework for choosing the right tools for global traffic management and data replication based on concrete application requirements.

Key Takeaways:

• For global HTTP/S traffic, Azure Front Door is the premier choice for high-availability web applications, offering fast failover and a rich feature set. Azure Traffic Manager is a simpler, DNS-based alternative suitable for non-web protocols or when a longer RTO is acceptable.
• For global Layer 4 (TCP/UDP) traffic, the Cross-Region Load Balancer provides a unique, native solution.
• For data replication, the choice is driven by your data model and write patterns. Azure SQL Database with failover groups excels for relational data in active-passive or active-active (read) scenarios.
• Azure Cosmos DB is the go-to choice for true active-active applications that require low-latency, multi-region writes for NoSQL data.
• The selection of these services is not independent; the choice of a traffic routing strategy and a data replication strategy must be compatible to achieve the desired RTO and RPO.

In our next lesson, we will pivot to another critical pillar of the Well-Architected Framework: Security. We will apply the shared responsibility model to identify security obligations across IaaS, PaaS, and SaaS service models, an essential concept for operating securely in the cloud.