Concepts | Deep Dive | Integrations | Best Practices | FAQs
Azure's global infrastructure is built on a hierarchical model of Geographies → Regions → Availability Zones → Data Centers. This design provides disaster recovery, compliance, performance optimization, and high availability across the globe.
Geography: A discrete market containing two or more regions that preserves data residency and compliance boundaries. Examples: United States, Europe, Asia Pacific.
Region: A set of data centers deployed within a latency-defined perimeter (typically <2ms round-trip) and connected through a dedicated regional low-latency network. Each region is paired with another region within the same geography for disaster recovery.
Availability Zone (AZ): Unique physical locations within a region, each made up of one or more data centers with independent power, cooling, and networking. AZs are connected via high-speed, private fiber-optic networks.
Data Center: Physical facilities housing compute, storage, and networking infrastructure.
Every Azure region is paired with another region within the same geography, at least 300 miles apart. This enables:
Understanding the nuances of Azure's global infrastructure is critical for designing resilient, compliant, and performant solutions.
Zone-Redundant Services: Automatically replicate across all AZs in a region
Zonal Services: Pinned to specific availability zones
Non-Zonal Services: Deployed at region level, no AZ awareness
| Connection Type | Typical Latency | Use Case |
|---|---|---|
| Same AZ | <1ms | High-performance computing clusters |
| Cross-AZ (Same Region) | 1-4ms | Database replication, load balancing |
| Regional Pairs | 25-150ms | Disaster recovery, backup |
| Cross-Geography | 150ms+ | Global distribution, CDN |
99.9% SLA: Single-instance VMs with Premium SSD
99.95% SLA: Multiple VMs in same Availability Set
99.99% SLA: Multiple VMs across Availability Zones
99.999% SLA: Multi-region deployments with Traffic Manager
Scenario: Global e-commerce platform requiring <100ms response times worldwide
Architecture Decisions:
Trade-offs:
Scenario: Financial services application requiring RPO=15min, RTO=4hours
Design Considerations:
Pitfalls to Avoid:
| Consideration | Decision Factor | Example |
|---|---|---|
| Data Residency | Legal/Regulatory requirements | GDPR → Europe regions only |
| Latency | User/application proximity | US users → US regions |
| Service Availability | Required services available | AI services → limited regions |
| Pricing | Regional price variations | Storage 10-20% variance |
| Capacity | Resource availability | GPU instances → specific regions |
| Disaster Recovery | Regional pair strategy | East/West US pairing |
High Availability Design:
Multi-Region Strategy:
Cost Optimization:
Security and Compliance:
Essential questions for senior Azure architect interviews focusing on regional architecture decisions.
Q: How do you design a globally distributed application that meets both performance and compliance requirements?
A: Start with geography selection based on data residency laws, then choose regions within each geography based on user proximity. Implement Azure Front Door for global load balancing, deploy application tiers in multiple regions, use Cosmos DB for globally distributed data with appropriate consistency levels, and ensure compliance through Azure Policy and region-specific configurations.
Q: What's the difference between Availability Sets, Availability Zones, and Regional Pairs?
A: Availability Sets protect against rack-level failures within a single data center (99.95% SLA). Availability Zones protect against data center failures within a region (99.99% SLA). Regional Pairs protect against region-wide disasters and ensure business continuity (required for 99.999% SLA across geographies). Each provides a different level of fault tolerance with corresponding complexity and cost implications.
Q: How do you handle data synchronization in a multi-region deployment?
A: Depends on consistency requirements. For strong consistency, use Azure SQL with Always On Availability Groups or Cosmos DB with strong consistency (performance impact). For eventual consistency, use Cosmos DB with session or eventual consistency levels, or implement custom replication with Service Bus/Event Grid. Consider using read replicas for read-heavy workloads and implement conflict resolution strategies for multi-master scenarios.
Q: What factors influence regional selection for a new Azure deployment?
A: Data sovereignty and compliance requirements (GDPR, industry regulations), user proximity for latency optimization, service availability (not all services available in all regions), pricing variations (10-30% difference), disaster recovery requirements (regional pairing), capacity constraints (GPU availability), and network connectivity options (ExpressRoute locations).
Q: How do Availability Zones impact network design and cost?
A: AZ-redundant deployments require load balancers (Standard SKU) for traffic distribution, increasing base costs. Cross-AZ traffic within a region is typically free, but some services charge for zone-redundant storage. Network design must account for 1-4ms latency between AZs and implement proper health checks. Security groups and routing must accommodate multiple subnets across zones.
Q: Explain the trade-offs between active-active and active-passive multi-region architectures.
A: Active-active provides better resource utilization and performance but requires complex data synchronization, conflict resolution, and higher costs. Active-passive is simpler with lower costs but has unused capacity and longer recovery times. Choose active-active for globally distributed users requiring low latency everywhere, active-passive for disaster recovery scenarios with acceptable RTO/RPO requirements.
AZ Availability: Not all regions have Availability Zones. Some regions have only 2 AZs instead of the standard 3, affecting high availability designs.
Service Deployment Constraints: Some services can't span AZs (like Basic Load Balancer) while others are automatically zone-redundant (like Azure DNS).
Cross-Geography Restrictions: Certain services (like Azure DevOps organizations) cannot be moved between geographies after creation.
Regional Capacity Limits: Popular regions may have capacity constraints for specific VM sizes or services, especially during high-demand periods.
Data Transfer Costs:
Latency Optimization Strategies:
Service-Specific Regional Behaviors:
Over-Engineering: Implementing multi-region architecture when single-region with AZs meets requirements, leading to unnecessary complexity and costs.
Under-Engineering: Deploying single-instance resources without considering availability requirements, resulting in poor SLA performance.
Data Gravity Neglect: Not considering data transfer costs and latency when distributing compute away from data sources.
Compliance Assumptions: Assuming data residency requirements without proper legal review, potentially causing regulatory violations.
This documentation serves as a comprehensive guide for senior Azure architects preparing for technical interviews. Focus on understanding the interconnections between concepts rather than memorizing individual facts.