Azure Virtual Network routing appliance is now generally available
Modern cloud networks are evolving faster than ever. Organizations are building larger AI platforms, connecting more services through private connectivity, adopting IPv6, and expanding applications across regions and business units. As these environments grow, the network becomes a critical foundation for delivering performance, resiliency, and operational simplicity. Today, we're excited to announce the general availability of Azure Virtual Network routing appliance, a managed, platform-native routing service designed to provide high-performance connectivity across Azure virtual networks at cloud scale. Virtual Network routing appliance brings together Azure-native operations, specialized networking infrastructure, built-in resiliency, and high-bandwidth forwarding to help organizations build the next generation of cloud network architectures. Built for the era of AI infrastructure AI is changing the scale at which networks operate. Training clusters, inference services, analytics platforms, data processing pipelines, and distributed application environments generate unprecedented volumes of east-west traffic. These workloads require high-performance connectivity between services, networks, and regions while maintaining operational simplicity. Virtual Network routing appliance provides a managed routing foundation for these environments, enabling organizations to scale network connectivity alongside their AI investments. Instead of building and operating custom routing infrastructure, teams can focus on accelerating innovation, deploying new services, and delivering business outcomes. Scale hub-and-spoke architectures Hub-and-spoke remains one of the most widely adopted network architectures in Azure because it provides centralized governance, simplified operations, and efficient connectivity. As organizations expand, however, these architectures often grow from a handful of virtual networks into hundreds or even thousands of connected environments. Virtual Network routing appliance enables customers to scale these architectures while maintaining a consistent operational model. By providing a dedicated routing layer within the hub, Virtual Network routing appliance simplifies connectivity between applications, shared services, and business units while supporting the scale required by modern enterprise environments. The result is a network architecture that remains manageable even as organizational growth accelerates. Unlock large-scale private connectivity Private connectivity has become the default connectivity model for modern cloud deployments. Applications, databases, platforms, shared services, and partner solutions increasingly depend on private communication patterns across Azure environments. Virtual Network routing appliance provides a centralized routing foundation that helps customers build and scale these architectures while maintaining a consistent private networking experience across their environments. Virtual Network routing appliance can also help scale Private Endpoint connectivity beyond the current 20,000-endpoint HSPE boundary. Looking ahead, it establishes a foundation for further accelerating private connectivity to on-premises environments, without introducing additional architectural specifics. As organizations continue consolidating services onto private connectivity models, Virtual Network routing appliance provides the performance and scale needed to support long-term growth. Accelerate your IPv6 journey IPv6 adoption continues to grow across enterprise, telecommunications, and cloud environments. Organizations increasingly need network architectures capable of supporting IPv4, IPv6, and dual-stack deployments while maintaining operational consistency. Virtual Network routing appliance supports IPv4, IPv6, and dual-stack virtual networks, enabling customers to modernize network architectures and expand address space without introducing new operational complexity. Whether organizations are beginning their IPv6 transition or building IPv6-first architectures, Virtual Network routing appliance provides a consistent routing foundation across both address families. Simplify multi-region architectures Modern applications rarely live within a single region. Organizations increasingly deploy workloads globally to improve performance, resiliency, business continuity, and regulatory compliance. These architectures require a networking foundation capable of supporting connectivity across regions while remaining simple to operate and govern. Virtual Network routing appliance helps customers build scalable multi-region network architectures by providing a centralized, high-performance routing layer that integrates naturally into Azure networking designs. This allows teams to focus on application architecture and customer experience rather than operational management of routing infrastructure. Built for enterprise scale As organizations continue to grow, networking teams face a common challenge: supporting increasing scale without increasing operational complexity. Virtual Network routing appliance was designed to meet this challenge by combining: High-performance routing using specialized Azure networking infrastructure Built-in resiliency and availability zone support Native Azure management and governance integration Support for IPv4, IPv6, and dual-stack deployments Integrated monitoring and observability through Azure Monitor metrics available Configurable bandwidth tiers for production workloads Future support for scaling Private Endpoints beyond 20,000 These capabilities allow customers to build large-scale networking architectures while maintaining a familiar Azure-native operational experience. Learn more Azure Virtual Network routing appliance is more than a new networking resource. It is a foundational building block for the next generation of Azure networking. Organizations are continuing to build larger AI platforms, expand private connectivity, increase multi-region deployments, and modernize network architectures. These transformations require a routing foundation that can scale alongside them. Virtual Network routing appliance provides that foundation, delivering the performance, scale, resiliency, and operational simplicity required for modern cloud networks. Whether you're building an AI platform, expanding a hub-and-spoke architecture, scaling private connectivity, enabling IPv6, or designing a global application footprint, Azure Virtual Network routing appliance helps simplify networking so you can focus on what matters most: delivering innovation faster. Overview of Routing Appliances - Azure Virtual Network | Microsoft Learn
Simplify secure, zone-resilient outbound connectivity with Azure Firewall and StandardV2 NAT Gateway
As organizations modernize their applications in Azure, secure and resilient outbound connectivity has become just as critical as inbound security. Workloads need reliable access to external APIs, SaaS services, operating system updates, and partner endpoints, while still meeting strong security controls, predictable egress IPs, and high availability. Achieving all of this consistently requires using the right networking services together. To make this easier, we’ve updated the Azure Firewall create experience in the Azure portal to include StandardV2 NAT Gateway directly in the deployment flow. This new experience makes it quick and seamless to adopt a secure, scalable, and zone‑resilient outbound architecture from day one by using Azure Firewall and Azure NAT Gateway together. In this post, we’ll cover: Why pairing Azure Firewall with StandardV2 NAT Gateway is a recommended design How this combination simplifies secure and resilient outbound connectivity What’s new in the Azure Firewall portal experience and how to get started Why Azure Firewall and StandardV2 NAT Gateway? Azure Firewall and Azure NAT Gateway are designed to complement each other, each focusing on what they do best: Azure Firewall provides centralized traffic inspection and policy enforcement, including IP address and FQDN filtering, threat intelligence, and logging. StandardV2 NAT Gateway delivers high‑scale outbound SNAT, static egress IPs, and built‑in zone redundancy. StandardV2 NAT Gateway is zone‑redundant by default, automatically spanning availability zones within a region. This means outbound connectivity remains available even during a zonal failure without requiring multiple zonal NAT gateways or additional routing configurations. Together, this pairing cleanly separates: Security policy and inspection handled by Azure Firewall Outbound scale, resiliency, and IP predictability handled by NAT Gateway This separation is key for modern, large‑scale cloud workloads. A recommended outbound architecture In a typical hub‑and‑spoke design: Workloads in spoke virtual networks route outbound traffic to Azure Firewall in the hub Firewall policies inspect and allow the traffic StandardV2 NAT Gateway is attached to the AzureFirewallSubnet in the Hub Approved traffic flows through StandardV2 NAT Gateway for SNAT Traffic exits Azure using static, predictable public IPs This approach provides several important benefits: Scalable SNAT capacity for high‑connection workloads Static outbound IPs for partner allow‑listing and compliance Zone‑resilient outbound connectivity by default For step-by-step architectural guidance, see Integrate NAT gateway with Azure Firewall in a hub and spoke architecture. Built for secure and resilient Azure environments As customers increasingly adopt availability zones, large‑scale VMSS or AKS deployments, and zero‑trust network models, outbound connectivity must be secure, predictable, and resilient. By pairing Azure Firewall with StandardV2 NAT Gateway—and now surfacing this pairing directly in the portal create experience—customers can start with a production‑ready outbound architecture that scales with their environment. What's new in the Azure Firewall create experience in the portal When creating a new Azure Firewall in the portal, customers can now: Select and associate a StandardV2 NAT Gateway during firewall deployment. Reduce post‑deployment configuration and manual touches. Start with a recommended zone-resilient outbound architecture by default. By bringing NAT Gateway directly into the Firewall create flow, the portal helps guide customers toward a more secure and scalable outbound setup—without requiring them to stitch services together after the fact. Get started You can try the updated experience today by creating a new Azure Firewall in the Azure portal and selecting StandardV2 NAT Gateway during deployment. With just a couple clicks of a button: In the Basics tab, configure your Firewall settings (ex., SKU, policy, virtual network). In the *new* Advanced tab, create a new or add an existing StandardV2 NAT gateway and associate StandardV2 public IP addresses or prefixes. The StandardV2 NAT gateway is automatically attached to the Firewall subnet—no additional routing or configuration required. Review and Create. Note: StandardV2 NAT Gateway is not yet available in all regions. If your selected region does not support StandardV2 NAT Gateway, the option to enable StandardV2 NAT gateway will not appear during Firewall creation. Refer to StandardV2 NAT Gateway limitations for more information. For more details, see: Integrate StandardV2 NAT Gateway with Azure Firewall Integrate NAT Gateway with Azure Firewall in a hub‑and‑spoke network Azure NAT Gateway SKUs
Proactive Reliability Series — Article 2: Regional Distribution Patterns for Azure Workloads
Introduction Public cloud platforms — including Microsoft Azure — are built on three foundational principles that distinguish them from traditional on-premises infrastructure: Elasticity: The platform can automatically expand and contract resource capacity in response to demand. Capacity is not statically provisioned; it is drawn from a shared pool and released when no longer needed. Scaling: Workloads can scale horizontally (adding more instances) or vertically (increasing instance size) on demand, without pre-procurement of physical hardware. Consumption-based billing: Customers pay for what they use, when they use it. Cost is proportional to resource consumption, not to physical capacity reserved in advance. These principles are properties of the platform, not of any single location. Microsoft Azure Cloud is not a single region — it is a globally distributed platform comprising dozens of regions across every major geography, interconnected by a private backbone network. When an organisation deploys to Azure, it is deploying into this global system; the choice of which region or regions to use is based on an organizational strategy and architectural decision. Using a single Azure region is a valid choice in many scenarios, but it has to be a deliberate architecture decision, not an omission. Why multi-region? Microsoft Azure CTO Mark Russinovich summarises the case for multi-region in Achieve agility and scale in a dynamic cloud world: organisations that span multiple regions gain scalability and flexibility (choosing from the full Azure region portfolio, including differentiated pricing, AI capabilities, and deployment options), resilience and availability (reducing the impact of regional disruptions through multiple backup and recovery options), and performance and reduced latency (serving users from infrastructure that is geographically closer to them). The post's closing recommendation — "leverage Azure as a cloud platform, not a datacenter region" — makes explicit what the multi-region decision ultimately is: a choice to treat the platform's global footprint as an asset, not a constraint. Mark Russinovich — Achieve agility and scale in a dynamic cloud world (Microsoft Azure, September 2024) This article also does not argue whether to adopt a multi-region strategy — that is a business and risk decision. It describes what the options are: the available regional distribution patterns, the forces each resolves, and the trade-offs each accepts. Regional workload distribution is not simply an application-level decision — it is an organisational one. It shapes how a company scales its cloud presence, manages cost and operational complexity across a growing portfolio, meets data residency and regulatory obligations, and positions itself to respond to changing conditions. Multi-region is often a necessity, not a free choice: growth ambitions, compliance requirements, or risk obligations may demand it. But necessity does not determine form. These patterns define the decision space: whether operating across multiple regions is warranted at all, and if so, which structural arrangement fits the organisation's scale, objectives, and operational capability. Several patterns are adapted from Gregor Hohpe's multi-cloud strategy patterns, originally described in Multi Cloud Architecture: Decisions and Options and further elaborated in Multi-cloud: From Buzzword to Decision Model. Note: This is an unofficial guide to regional distribution patterns for Azure workloads. It is not an official Microsoft publication and is not officially supported, endorsed, or maintained by Microsoft. All descriptions and recommendations are based on publicly available Azure documentation and general distributed systems principles. Always refer to official Azure documentation and the Azure Well-Architected Framework for authoritative guidance. The risks and opportunities Pattern selection is a direct response to specific risks or solution quality requirements. Before evaluating patterns (options), it is necessary to understand what risks are actually relevant — infrastructure faults, capacity constraints, service coverage gaps, and compliance or business obligations — and what their scope of impact is. Azure infrastructure is complex and distributed. While Microsoft invests heavily in reliability, faults can and do occur across a wide range of blast radii — from a single compute instance at the narrowest end, through Availability Zone and regional failures, to global service disruptions at the widest. The appropriate pattern is the one that reduces unacceptable risks to a tolerable level. The Azure Well-Architected Framework — Reliability pillar recommends Failure Mode Analysis (FMA) as the structured technique for enumerating failure modes, assessing their impact, and identifying mitigations before they are needed in production. The fault types below are the infrastructure-layer inputs to that analysis. For a detailed breakdown of each fault type — including likelihood analysis, real-world incident examples, and detection guidance — see Proactive Reliability Series — Article 1: Fault Types in Azure. Risk catalog (sample) The following is a representative sample of risks relevant to regional workload distribution decisions, not an exhaustive catalogue. Not all entries are infrastructure faults — some represent business and compliance obligations. The Category column identifies the type of each risk. Likelihood values are relative planning heuristics to help prioritise resilience investments — they are not statistical probabilities and do not represent Azure SLA commitments. Risk Category Blast Radius Likelihood Primary Mitigation Service Fault (Region) Infrastructure Fault Single service within a region Medium Region redundancy Region Fault Infrastructure Fault Regional degradation or full regional loss (partial-to-full region impact) Low Region redundancy; cross-region failover Network POP Location Fault Infrastructure Fault Network colocation site (affects connectivity, not compute) Low ExpressRoute Metro (dual peering locations); network path redundancy Service Fault (Global) Infrastructure Fault Worldwide or multiple regions simultaneously Very Low Accept risk; use alternative service if downtime is intolerable Regional Service Capacity Constraint Infrastructure Capacity Single region (required capacity unavailable — whole service or specific SKU — at failover time or sustained shortage) Low Region redundancy; Capacity Reservations; Hot Standby; alternative region Service Regional Unavailability Infrastructure Fault Single region (desired service not offered in that region) Low Deploy to a region where the service is available Geopolitical Risk Compliance One or more regions (regulatory or political mandate to relocate) Low Portable pattern; pre-validated alternative region Sustainability Constraint Compliance One or more regions (sustainability targets unachievable in current region) Low Portable pattern; relocate to region with required sustainability profile The patterns While there could be many ways to distribute workloads across Azure regions, the following patterns represent the most common and widely applicable approaches. Each pattern is a structural topology that defines how workloads are deployed and how they respond to Risks and Quality Requirements. The patterns are not mutually exclusive — they can be combined or layered to meet specific requirements. The following patterns describe the principal ways workloads can be distributed across Azure regions. Patterns 1-3 are described and found very often, while patterns 4-5 are less common but still important to consider. The table below summarises the patterns, their intent, and the primary driver for their adoption. # Pattern Intent Primary Driver 1 Single All resources in one Azure region; AZ redundancy optional Simplicity; cost; data residency constraints 2 Failover Primary region serves traffic; secondary region is a cold or hot standby for DR Business continuity 3 Parallel Same workload deployed to multiple regions simultaneously; all active Continuous availability; zero-downtime failover 4 Segmented Services or service portfolio distributed across regions by BU, LOB, tenant, or data residency Isolation; sovereignty; independent release cadence 5 Portable Full portability; workloads can be relocated between regions without application changes Operational flexibility; on-demand relocation 1. Single region pattern Pattern Name: Single Region Workload Distribution Classification: Regional workload distribution Scope: Workload — applies to a single application or service deployment, Workload (Application) Portfolio Intent: Deploy all workload resources in one Azure region. Context: A workload is being deployed to Azure and must decide how many regions to use. The business impact of a regional outage has been assessed — either as tolerable within the workload’s criticality tier, or as not applicable because data sovereignty constraints prohibit cross-region replication. The team needs to treat Single Region as an explicitly chosen architecture, not an omission. Problem: Every additional Azure region adds infrastructure cost and workload integration complexity due to the network latency it introduces. Not all workloads justify this overhead. The question is not “should I always use multiple regions?” but “when is a single region the correct and explicitly chosen answer, and when does adding a second region produce risk-reduction that justifies the cost?” Forces: The workload’s risk profile does not justify cross-region redundancy: the business impact of a regional outage is tolerable, data sovereignty rules prohibit cross-region replication, or reliability requirements are fully met within a single region with Availability Zone redundancy. The cost of multi-region infrastructure produces no corresponding risk-reduction return for this workload. Solution Place all compute, data, and networking resources in a single Azure region. Apply Availability Zone redundancy within that region for protection against datacenter-level failures. Formally accept region-level risk as within tolerance for this workload’s criticality tier — this is a deliberate architecture decision, not an omission. Implementation: Enable Availability Zones for all production resources where supported. Use Azure Infrastructure Resiliency Manager (AIRM) to validate zone-redundancy posture across the workload. Document the risk-acceptance decision explicitly at the application level. Consequences Benefits: Lowest cost and operational footprint of all patterns. No cross-region routing, replication lag, or failover coordination complexity. Simplest deployment pipeline, observability surface, and incident response. Liabilities: No mitigation for any region-level fault — full workload loss on regional failure. Data concentrated in one geography; no cross-region durability without explicit configuration. No pre-deployed capacity in an alternative region. Risk posture: Risk Assessment Region Fault ❌ Primary unaddressed risk — partial degradation or full regional failure has no cross-region recovery path; accept or upgrade pattern Service Fault (Region) ❌ Regional service failures have no cross-region alternative Regional Service Capacity Constraint ❌ No alternative region available; both on-demand failover provisioning and sustained SKU shortages have no mitigation path Network POP Location Fault ✅ Addressable within this pattern via ExpressRoute Metro (dual peering locations in the same metro); does not require a multi-region distribution change Known uses Development and test environments; Bronze- or Non-Critical-tier workloads; workloads with strict data residency constraints that prohibit cross-region replication; proof-of-concept and time-limited deployments. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping for how individual Azure services implement this pattern. References Azure reliability documentation overview Availability zones overview Azure Well-Architected Framework — Reliability pillar Availability zone support for Azure services Azure Infrastructure Resiliency Manager (AIRM) — Public Preview 2. Failover pattern (primary + standby region) Pattern Name: Failover Workload Distribution Also Known As: Active-Passive, Disaster Recovery (DR), Business Continuity and Disaster Recovery (BCDR) Classification: Regional workload distribution, Application Design, Platform/Infrastructure Design, Disaster Recovery Scope: Workload — an application and infrastructure design pattern that requires both layers to work in tandem; Workload (Application) Portfolio Intent: Recover from a regional disaster or other longer duration region outage by designating a primary region to carry all production traffic and a standby region to absorb that traffic upon primary region failure. The typical quality attribute metrics that govern its design are RTO (Recovery Time Objective — maximum tolerable downtime), RPO (Recovery Point Objective — maximum tolerable data loss), and MTTR (Mean Time To Recovery — the observed average recovery time, measured through drills and real incidents, that validates whether the RTO target is achievable in practice). Context: A workload must survive region-level failures, but the architectural complexity of running two fully active deployments simultaneously — with multi-region write-conflict resolution — is not justified. The business can tolerate a bounded recovery time and, depending on the sub-variant chosen, a bounded data loss window. Problem: A fully active multi-region deployment (Parallel pattern) introduces multi-region write-conflict complexity that the application cannot or need not absorb. The Failover pattern trades continuous availability for single-writer simplicity: one region is active, one is standby, and recovery is bounded by RTO/RPO targets. The sub-variant choice (Cold / Warm / Hot) then determines how much cost is invested in standby readiness — from minimal (~1.1×) to near-full duplication (~2×) — based on how fast recovery must be. Forces: A single active write region is required — multi-region write-conflict resolution adds unacceptable consistency risk or development complexity. RTO and RPO targets must be met, but budget constrains how pre-warmed the standby region can be, driving the Cold / Warm / Hot sub-variant selection. Regional Service Capacity Constraint in the standby region is a residual risk for Cold and Warm sub-variants — the standby may fail to scale at failover time unless capacity is pre-reserved. Solution Designate one region as primary (all production traffic under normal conditions) and a second as standby (no production traffic until failover). The standby’s readiness level — the sub-variant choice — is determined by the RTO/RPO requirements and cost envelope. Replication from primary to standby is continuous; failover is triggered manually or automatically when the primary becomes unavailable. Note on "Active-Passive": This pattern is often called Active-Passive in Microsoft documentation. That framing is accurate at the traffic level (one region active, one passive), but it can obscure the architectural intent. The Failover label here emphasises the capability being purchased: the ability to redirect the entire workload to a pre-designated region when the primary is unavailable. Implementation: The key design decision is how ready the standby is at the moment it is needed. Three sub-variants define this readiness spectrum: Sub-variant Secondary state Cost multiplier Cold Standby No running compute; data either in scheduled backups or continuously replicated ~1.1–1.5× Warm Standby Reduced-scale compute running; data continuously replicated ~1.5–1.8× Hot Standby Full-scale compute running; data continuously replicated ~2× Cold Standby — No compute is running in the standby region under normal conditions. Cold Standby covers two positions within this state, differing in how the data layer is protected: Backup/Restore: Data is backed up or geo-replicated on a scheduled basis. On failover, infrastructure must be deployed from scratch and data restored before traffic can be redirected. RTO is measured in hours; RPO equals the interval between the last backup cycle and the failure event. Data-layer live, compute stopped: Core infrastructure (networking, identity, data tier) is kept running with continuous replication to the standby region; compute is stopped or scaled to zero. On failover, compute is started and scaled up to meet full load. RTO is typically 15–60 minutes; RPO is bounded by async replication lag rather than backup interval. Both positions share the defining characteristic of Cold Standby: no production-equivalent compute running in the secondary region under normal conditions. The difference is the investment in keeping the data layer live, which reduces both RTO and the data loss window at a modestly higher steady-state cost. Warm Standby — The standby region runs a scaled-down but functionally complete version of the workload. Traffic is not routed there under normal conditions. On failover, the secondary scales up and traffic is redirected. A brief scale-out lag occurs before the secondary absorbs full traffic; the running environment eliminates cold-start delay. Hot Standby — The standby region runs a full, production-equivalent deployment — same compute capacity, same configuration — but receives no traffic under normal conditions. Data is continuously and near-synchronously replicated. Failover is fast and often automated because no scale-up is required. Consequences Benefits: Enables recovery from region-level faults at a fraction of Parallel pattern cost. Flexible cost-vs-RTO trade-off across Cold / Warm / Hot sub-variants. No multi-region write-conflict complexity; single active write region throughout normal and recovery operation. Liabilities: Cold and Warm standby introduce meaningful RTO (minutes to hours). Replication lag creates a data loss window (RPO > 0) at the moment of failover. The failover path is the least-exercised code path — untested recovery inflates actual RTO. Failover is often neglected and not properly and regularly tested — this leads to a fear of executing failover when needed (and not only a full-region disaster demands it). Risk posture: Risk Assessment Region Fault ⚠️ Primary driver; standby region absorbs traffic on full regional loss, but partial regional degradation may not trigger automated failover. RTO depends on sub-variant Regional Service Capacity Constraint ⚠️ Cold/Warm Standby are exposed to both on-demand provisioning failure and sustained SKU shortages — mitigated by Capacity Reservations or Hot Standby Service Fault (Region) ✅ Standby region provides an alternative deployment for regional service failures Service Regional Unavailability ⚠️ Secondary region must be verified for full service parity at design time — absent services block failover regardless of compute readiness Known uses Business-critical workloads with defined RTO/RPO targets that cannot accept region-level risk but do not require continuous multi-region availability; workloads with single-writer data models where multi-region write-conflict resolution is unacceptable; regulatory environments where a designated recovery region must be pre-approved. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping. References Business continuity and disaster recovery — Azure reliability WAF Reliability — Disaster recovery Azure Site Recovery overview Azure SQL Database active geo-replication Azure SQL Database auto-failover groups 3. Parallel workload distribution (simultaneous active deployment) Pattern Name: Parallel Workload Distribution (Simultaneous Active Deployment) Also Known As: Active-Active Classification: Regional workload distribution, Application Design Scope: Workload — an application-level design pattern; requires the application and its data layer to be explicitly designed for concurrent multi-region operation, Workload (Application) Portfolio Intent: Deploy the same workload simultaneously to two or more Azure regions, all serving production traffic. Context: Two independent drivers lead to this pattern, often simultaneously: the workload serves geographically distributed users who require regional proximity to meet latency targets, and the availability tier demands zero-downtime through region-level failures. A single deployment point cannot satisfy both. Manual failover timelines, standby region promotion, and RPO windows are incompatible with the required availability tier. This pattern is the mandated baseline for Mission-Critical workloads in the Azure Well-Architected Framework. Problem: Passive standby and failover mechanisms introduce recovery time and data loss windows that are incompatible with high-availability targets (e.g. 99.99%+). Meeting both demands requires all regions to be equal active participants — not a primary and a standby. But this demands that the data layer either supports concurrent writes across regions, relies on continuous cross-region replication with a defined consistency model, or is predominantly read-heavy — and that pre-provisioned capacity is maintained in every active region at all times. Forces: Regional failure must produce zero downtime — manual failover timelines cannot satisfy the availability target. Traffic originates from geographically distributed users who require regional proximity to meet latency SLAs. Availability targets (e.g. 99.99%+) eliminate passive standby as a viable option. The application can tolerate eventual consistency or is read-heavy enough that multi-region write complexity is manageable. Once multi-region data access is solved, every region's compute actively serves production traffic — the capacity that Failover Hot Standby holds idle is fully utilised; the cost multiplier buys active production capacity, not idle insurance. Solution Deploy the workload identically to two or more Azure regions. Route production traffic to all active deployments simultaneously via a global load balancer — under normal conditions, each user is directed to the nearest active region, minimising latency. On regional failure, the load balancer automatically rebalances traffic to the remaining healthy regions — no manual promotion, no scale-up delay. All regions are equal peers; there is no concept of primary and secondary. Implementation: Deployment Stamps are commonly used to implement Parallel at scale — multiple active regional instances behind global routing. See Deployment Stamps pattern — Azure Architecture Center. Stamps are not exclusive to Parallel: the same approach can also support Segmented and, in some designs, Failover. Regions active: 2+ (all serving production traffic simultaneously). Typical cost multiplier: ~2–3×. Microsoft guidance — Mission-Critical workloads: The Azure Well-Architected Framework’s Mission-Critical design methodology explicitly advises active-active multi-region deployment as the baseline for workloads targeting 99.99% availability or higher. The application design guidance states: “The application must be able to withstand regional and zone failures. It must be deployed in an active/active model so that the load is distributed among all regions.” The regions and availability zones guide reinforces this: “Mission-critical workloads should use both multiple availability zones and multiple regions.” The WAF Reliability pillar describes active-active as the mechanism to achieve zero downtime, noting it is “ideal for mission-critical workloads that require uninterrupted availability.” Consequences Benefits: Regional failure triggers automatic traffic rebalancing — no manual failover, no service interruption. Lowest RTO of all patterns; zero-downtime regional failure recovery. On regional failure, remaining regions absorb redirected traffic immediately — if at capacity, the workload degrades under load rather than failing completely; degraded performance is a fundamentally better failure mode than an unavailability window. Serves geographically distributed users within latency bounds simultaneously from the nearest active region. Compute deployed per region actively generates production value under normal conditions — the nominal cost multiplier buys utilised capacity, not idle standby insurance. Liabilities: Highest nominal cost (~2–3×) — though compared to Failover Hot Standby (~2×), the effective cost of resiliency is lower: every unit of deployed capacity actively serves production traffic rather than sitting idle as insurance. Requires the application to support multi-region writes or be predominantly read-heavy; write-conflict resolution is an application responsibility. Multi-region CI/CD, distributed observability, and write-conflict handling add steady-state operational overhead — but eliminate the failure-event burden: no failover procedure, no drill schedule, no risk of untested recovery paths inflating actual RTO. Risk posture: Risk Assessment Region Fault ✅ Primary driver; automatic traffic rebalancing handles both partial regional degradation and full regional loss — no promotion or manual steps required Service Fault (Global) ⚠️ No regional workload distribution pattern mitigates a truly global service disruption — but the impact is often partial: only specific SKUs, tiers, or versions of a service may be affected, leaving workloads on unaffected variants operational. Where the risk is intolerable, the mitigation is service substitution: switching to an alternative Azure service with equivalent functionality, or a third-party / self-hosted equivalent Service Fault (Region) ✅ Automatic rebalancing redirects traffic away from the affected region without manual failover Regional Service Capacity Constraint ✅ All regions are pre-deployed and running; no on-demand capacity provisioning required at failover time — if a region fails and remaining regions reach capacity limits, the result is degraded performance under load, not complete unavailability Known uses Mission-Critical workloads targeting 99.99%+ availability per WAF guidance; globally distributed consumer applications where regional proximity is a primary SLA requirement; financial trading and payment platforms where any recovery window is commercially unacceptable; real-time communication and streaming services where failover lag degrades the user experience. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping. References Mission-critical baseline architecture on Azure WAF Reliability — Mission-critical workloads Azure Cosmos DB — Distribute data globally Azure Cosmos DB — Multi-region writes Azure Front Door — Multi-region load balancing Azure API Management — Multi-region deployment 4. Segmented workload distribution (regional distribution by boundary) Pattern Name: Segmented Workload Distribution Also Known As: Deployment Boundaries, Regional Portfolio Allocation Classification: Regional workload distribution (portfolio scope) Scope: Portfolio / Organisation — a structural pattern for distributing a portfolio of workloads, tenants, or business units across regions; individual workloads within a segment may independently apply any other pattern Intent: Assign each Azure region a distinct, non-overlapping responsibility boundary so that regions are differentiated by ownership and isolation rather than by redundancy. Context: A portfolio of workloads, a multi-tenant application, or a multi-LOB organisation must distribute services or data across regions. The drivers include regulatory boundaries, tenant isolation, blast-radius containment, or operational independence — not simply increasing redundancy. Individual boundaries within the portfolio have materially different criticality tiers, release cadences, and recovery requirements. Problem: Running a second Azure region purely as a Failover standby generates ongoing cost without delivering business value under normal conditions. How can an organisation operate multiple regions so that every region carries real production workload, the cost is justified by utilisation rather than insurance alone, and each region's scope is independent enough that faults and changes in one area do not propagate to others? Forces: Regulatory, sovereignty, or compliance obligations drive geographic boundary placement — but strict data residency that prohibits cross-boundary replication also prevents the cross-region recovery that makes Segmented cost-efficient; a boundary whose data cannot leave its region can only recover within that region (Single Region posture), regardless of what neighbouring segments deploy. Independent release cadences, lifecycle autonomy, and scaling requirements across services, tenants, or business units conflict with coupled shared-infrastructure deployments. Blast-radius containment requirements prevent a single fault or bad deployment from affecting the entire portfolio. This pattern does not answer how each boundary recovers; that choice is made independently per boundary using Single, Failover, or Parallel. Solution Define non-overlapping responsibility boundaries and assign each boundary to a region. Each region owns its boundary exclusively — no region is a replica of another. Each boundary independently selects its own recovery posture (Single, Failover, or Parallel) based on its own criticality and requirements. The key structural advantage is region reuse: because multiple regions are already deployed and carrying real production load, each region can simultaneously serve as the Failover standby or Parallel peer for a neighbouring boundary — the same infrastructure investment delivers both production utilisation and recovery capability. This dual-purpose reuse is only available where cross-boundary data replication is permitted; where strict data residency prohibits it, each boundary must treat itself as isolated and plan recovery within its own region. Implementation: The boundary can be defined at different scopes: Within one application: tenants, markets, release rings, or data partitions assigned to different regions. Across a service portfolio: different applications, domains, or business capabilities intentionally placed in different regions. Segmentation axis Example Geography / data residency EU services and data in West Europe, US services and data in East US Business unit / LOB Finance portfolio in Region A, HR portfolio in Region B Customer tier Premium customer workloads in dedicated region(s), standard in shared region(s) Release ring Ring 0 workloads in Region A, Ring 1 workloads in Region B Scale tier High-volume service groups in larger regions, low-volume groups in smaller regions Segmented is orthogonal to the Single / Failover / Parallel dimension. It answers what is each region responsible for, not how does each responsibility recover? A global organisation might run some boundaries as Single, some as Failover (warm standby), and selected mission-critical boundaries as Parallel — all within one Segmented topology. Consequences Benefits: A fault in one boundary is contained to that region and does not propagate to adjacent boundaries. Each boundary independently selects its own recovery posture, cost level, and compliance configuration. Supports independent release cadences, scaling policies, and lifecycle management per boundary. Region reuse: already-deployed regions carrying production load can simultaneously serve as Failover standby or Parallel peer for neighbouring boundaries — the infrastructure investment delivers both production utilisation and recovery capability without paying for idle standby capacity. Liabilities: Cross-boundary dependencies — shared identity, shared data stores — undermine isolation guarantees and must be minimised by design. Governance overhead scales with the number of active boundaries; requires a formal boundary ownership model to remain manageable. Risk posture: Risk Assessment Service Fault (Region) ⚠️ Fault is contained to the affected boundary; adjacent boundaries continue operating — within-boundary recovery depends on that boundary’s posture Region Fault ⚠️ Only the boundary hosted in the affected region is impacted — RTO/RPO is determined by that boundary's individual recovery posture Regional Service Capacity Constraint ⚠️ Only the boundary in the capacity-constrained region is affected; other boundaries continue operating — mitigation depends on the boundary's own topology (Failover or Parallel provides alternatives; Single does not) Geopolitical Risk ✅ Boundaries can be relocated independently; the rest of the estate continues operating while the affected boundary is relocated Service Regional Unavailability ✅ Each boundary can be independently placed in a region where all required services are available Known uses Geo-distributed enterprise application portfolios; organisations with a federated business model where autonomous business units operate independently with their own release cadence, cost accountability, and compliance obligations; SaaS platforms with tenant-per-region isolation; regulated financial and healthcare services with strict data residency by jurisdiction. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping. 5. Portable workload distribution (full abstraction) Name: Portable Workload Distribution (Full Abstraction) Also Known As: Region-Agnostic Deployment, Cloud-Neutral Deployment Classification: Operational property (applicable to any structural pattern) Scope: Workload — a design property of an individual workload; composable with any structural pattern at either workload or portfolio scope Intent: Fully abstract the workload from the underlying Azure environment so it can be relocated to any Azure region at any time without modifying application code or configuration. Context: A workload is subject to compliance obligations — regulatory, geopolitical, or sustainability — that may require region relocation on short notice. Or the workload's operational requirements include the ability to optimise cost, respond to capacity constraints, or avoid service unavailability across regions. Portability is not the default outcome — it requires an explicit design decision and sustained engineering investment. Without that intent, the default is a workload that is structurally bound to its current region. Problem: Without a portability investment at design time, a relocation trigger forces significant rearchitecting under pressure rather than as a controlled migration. Forces: Compliance obligations — regulatory, geopolitical, or sustainability — may require relocation on short notice; deferring the portability decision converts a design choice into a forced rearchitecting event at the worst possible time. Data portability is the hardest dimension: scheduled backup/restore, continuous replication, and live migration each introduce cost, complexity, and consistency trade-offs that must be accepted at design time. Relocation may be temporary or permanent; the architecture must support both without distinguishing between them at deploy time. A port may be partial (subset of workloads) or full (entire estate); partial porting creates transient cross-region dependencies that must be explicitly designed for and eliminated as the migration progresses. Solution Select and implement a data portability mechanism — continuous replication, backup/restore, or live migration — whose cost, RPO, and operational model are explicitly accepted at design time. The target region is not fixed at design time — it is chosen when a trigger event occurs, and can be any eligible region. The workload stays in its current region under normal conditions and relocates only when a trigger event warrants it. Implementation: Portable is a layered property, not a separate structural topology. The underlying structural topology (Single, Failover, Parallel, or Segmented) determines traffic routing and redundancy; Portable governs whether that topology can be instantiated in a different region without application changes. The cost multiplier adds toolchain and abstraction overhead on top of the chosen structural topology. Data portability — the critical path: Compute portability is straightforward — container images and environment-agnostic configuration are standard practice. Data portability is the harder problem. Two mechanisms make it achievable: Continuous replication: The data layer replicates to the target region at all times, so the data is already present when a relocation is triggered. Azure Cosmos DB with multi-region writes, Azure SQL Database geo-replication, and Azure Storage geo-redundancy (RA-GRS/RA-GZRS) are common implementations. Continuous replication minimises RPO but adds steady-state cost. Automated data migration: A codified and continuously tested migration pipeline moves data to the target region at relocation time. Appropriate when continuous replication cost is not justified, or when the data tier does not support native geo-replication. The migration must be automatable, testable in isolation, and fast enough to satisfy the workload’s RTO for the trigger event. Port modes: Partial vs. Full A port — the act of relocating a workload using the Portable pattern — can be scoped in two ways: Partial port: A subset of workloads is relocated to the target region while others remain in the source region. This creates transient cross-region dependencies — service calls, data access, shared identity — between moved and not-yet-moved workloads. These dependencies must be explicitly designed for, monitored for latency and failure, and eliminated progressively as the migration advances. Partial porting is the natural execution mode for large estates where simultaneous full relocation is operationally infeasible. Full port: All workloads are relocated to the target region, either simultaneously or in a planned sequence that keeps cross-region dependencies only for the duration of each step. A full port is a long-term, intentional change of primary region. It is fundamentally different from a Failover event: Dimension Failover Full Port (Portable) Intent Quick recovery and return to primary region when resolved Permanent change of the region Duration Temporary — primary is restored after the event Long-term or permanent — target becomes the new primary Return Expected — traffic and workloads revert to original region Not expected — no return is planned Driver Region fault, outage, or transient unavailability Compliance, cost, sustainability, or strategic decision Transition Time Aiming for RTO Transition can take weeks or months (but it can be designed to serve the Failover purpose and meet RTO and RPO requirements) Transition disruption Minimal — automated or semi-automated failover Managed — gradual migration with a cross-region dependency period The Portable pattern must support both modes and both scopes. A workload that can only be relocated as an atomic all-or-nothing operation has limited practical utility; a workload designed for incremental partial porting is far more executable at scale. Consequences Benefits: Workload can relocate to any Azure region without application changes — eliminates region lock-in. Target region is determined at the time of the trigger, not at design time — unlike Failover's fixed designated standby, the destination can be any eligible region and can change between port events as requirements evolve. Primary architectural mitigation for compliance-driven relocation risks (Geopolitical Risk, Sustainability Constraint). Relocation can be temporary (workload returns after trigger resolves) or permanent — the architecture supports both without distinguishing between them. Liabilities: Portability is costly to establish and maintain; data portability and the abstraction layer add ongoing engineering and toolchain overhead. Data portability is the hardest and most underestimated engineering challenge — relocating compute is straightforward; relocating live data at acceptable cost, latency, and consistency is not. Introduces dependency on the abstraction toolchain — portability conventions must be actively enforced as engineering standards; without governance, individual implementation decisions erode them over time. Risk posture: Risk Assessment Geopolitical Risk ✅ Primary driver — region-agnostic workload relocates to a compliant region; unportable workloads face forced migration under time pressure Sustainability Constraint ✅ Workload moves to a region with the required sustainability profile without application-level changes Regional Service Capacity Constraint ✅ Workload can be relocated to an alternative region with available capacity — addresses both on-demand provisioning failure and sustained shortages Region Fault ✅ Workload can be relocated to an alternative region; recovery speed depends on data portability readiness Service Regional Unavailability ✅ Workload can be redirected to any region where required services are available — portability removes the fixed-region constraint Known uses Workloads subject to data sovereignty or geopolitical obligations that may require region relocation on regulatory notice; sustainability-committed workloads that may need to move to regions with a lower carbon intensity; workloads in rapidly expanding organisations that need to follow business growth into new geographies without rearchitecting. Several patterns are adapted from Gregor Hohpe's cloud strategy patterns: Multi Cloud Architecture: Decisions and Options — Architect Elevator. See Azure Services - Sample Multi-Region Capabilities Pattern Mapping. Related patterns Portable vs. Failover — Both result in a workload running in a different region, and a full port and a Hot Standby activation look nearly identical at execution time. The distinctions are fundamental: Failover is a topology (one region is permanently designated as standby); Portable is a property that can be layered on top of any topology. Failover requires a fixed secondary region to be designated at design time — the target is known, pre-provisioned, and not interchangeable. Portable has no fixed target: the destination region is chosen at the time of the trigger, can be any eligible region, and can differ between port events as compliance, cost, or operational requirements change. Failover is triggered by an unplanned disruption and is temporary — the expectation is to return to the original primary when the event resolves. A Portable port is triggered by a deliberate decision and is permanent — the destination becomes the new primary with no planned return. A Failover workload can also be Portable, applying both patterns simultaneously: Failover handles unplanned disruptions; Portable handles deliberate relocation decisions. They are orthogonal — not alternatives. Azure service pattern mapping - sample services Each pattern places specific demands on the services that compose the workload. Some services provide native capabilities — zone redundancy, built-in replication, independent deployment per region, parameterised failover targets — that simplify implementation of specific patterns. Others provide fewer native capabilities, requiring the pattern to be constructed at the deployment and application level. The service examples below illustrate how native capabilities map to pattern implementation for four representative services across IaaS and PaaS. Azure Virtual Machines Azure VMs are IaaS compute — the platform provides the virtualisation layer and the building blocks (Availability Zones, proximity placement, VM scale sets) but leaves resilience orchestration to the operator. This makes VMs fully flexible: every pattern is implementable, but none is provided out of the box — the operator constructs the desired topology. Attribute Value Cross-Region Replication Azure Site Recovery (ASR) — continuous replication to any target region; orchestrated failover supported Deployment model Independent — each VM or scale set is deployed per region with no shared control plane; fully independent instances per region are the norm Provisioning guarantee Capacity Reservations: pre-purchase VM SKU and quantity in any region; eliminates capacity risk at failover or scale-up Pattern implications Single: One region plus Availability Zone redundancy is the default deployment model; AIRM can audit zone distribution across VM resources. Failover: ASR makes Cold, Warm, or Hot standby feasible depending on how much compute is pre-provisioned. Parallel: Independent VM deployments per region behind a global load balancer are feasible; write-conflict handling remains an application responsibility. Segmented: VMs can be partitioned by boundary, region, or workload ownership with independent recovery postures. Portable: VMs are redeployed to the target region using ASR (continuous replication already in place) or fresh IaC deployment with capacity reservations pre-secured; the original region's instances are decommissioned once the target is operational. Azure App Service Azure App Service is a fully managed PaaS application platform. An App Service Plan runs in a single region and provides zone redundancy within that region, but no built-in replication or failover beyond it. Any topology beyond Single Region is constructed at the deployment level using independent plans and external traffic routing. Attribute Value Cross-Region Replication No live replication — the platform does not continuously replicate app content or state between regions; cross-region failover is constructed via independent plans and global traffic routing. Custom backup/restore (Basic tier and above) provides scheduled backup of app files and configuration to a storage account, restorable to any region — this supports Cold Standby and Portable scenarios. Deployment model Independent — each App Service Plan is a standalone regional resource; no shared control plane between plans in different regions Provisioning guarantee Not supported — no mechanism to pre-reserve compute in a target region; a Hot Standby (always-running plan) is the only way to guarantee capacity availability Pattern implications Single: A single App Service Plan in one region with zone redundancy is the normal starting point. Failover: Use independent App Service Plans per region with Front Door or Traffic Manager; the application state must live elsewhere. Parallel: Independent plans per region fit active-active traffic routing, but the data tier must support the write/read pattern. Segmented: Separate plans per boundary or tenant group provide clean ownership and isolation. Portable: A new App Service Plan is deployed in the target region and traffic is routed to it; the original plan is decommissioned once the target is serving production. Connected stateful services (databases, storage) must be independently relocated or already replicated to the target. Azure SQL Database (Business Critical) Azure SQL Database Business Critical is a fully managed relational database with extensive built-in resilience at every level: local high availability within a region (Always On replicas), zone redundancy, and native replication to other regions (active geo-replication, auto-failover groups). This breadth of built-in capability means more patterns are natively supported without additional construction. Attribute Value Cross-Region Replication Active geo-replication: continuously synchronised readable secondary in any region (up to 4 secondaries); auto-failover groups: stable read-write and read-only listener endpoints that survive failover without connection string changes Deployment model Managed instance per region — each database or elastic pool is a regional resource; geo-replication creates linked but independently addressable secondaries Provisioning guarantee No explicit provisioning at current tier — the platform manages the underlying infrastructure. Scaling up or changing service tier is subject to regional capacity availability and subscription quota, as with any Azure service. Geo-replicated secondaries are pre-provisioned and running before any failover, so failover itself does not require on-demand capacity provisioning Pattern implications Single: A single database in one region with zone-redundant replicas provides high availability without additional topology. Failover: Geo-replication and auto-failover groups are the built-in path; the service is natively designed for this pattern. Parallel: Readable secondaries can serve read traffic, but fully symmetric writes across regions are not natively supported. Segmented: Each boundary can own its own database instance and replication policy. Portable: A geo-replica is added on demand in the target region; once seeded, it is promoted to primary via planned failover (no data loss); the original region's replica is then removed. This is natively supported as a database relocation scenario. Azure API Management Azure API Management (APIM) is a fully managed API gateway platform. Within a single region it provides zone redundancy for the gateway. Beyond that, APIM offers a native multi-region deployment capability (Premium tier) that places gateway nodes into additional regions while sharing a single management plane. This makes it representative of services with a shared-control-plane architecture where the data plane scales independently per region. Attribute Value Cross-Region Replication Configuration replicated automatically to all regional gateway units; no stateful data plane — backend data replication is the responsibility of connected services Deployment model Shared control plane — a single APIM instance owns the management plane; additional regional gateway units are extensions of the same instance, not independent deployments Provisioning guarantee Not supported — capacity is allocated per gateway unit (scale units); provisioning additional units in a region before a failover event is the closest equivalent to a reservation Pattern implications Single: One APIM instance in one region with zone-redundant gateway units is viable for region-bound APIs. Failover: Secondary APIM capacity or a second instance can be provisioned, but the management plane must stay consistent. Parallel: The multi-region add-on is a strong native fit; gateway units run in multiple regions behind global routing with shared configuration. Segmented: Separate APIM instances per boundary, or boundary-specific gateway units where shared management-plane control is acceptable. Portable: Gateway units are added on demand in the target region while the original continues serving traffic; once the target is operational, the original region's gateway units are removed — completing the relocation without recreating the instance. Note: the APIM control plane (instance state) remains in the original region where the instance was created; unless a fault renders that region wholly inoperable, this is not an implication for the pattern — the control plane does not carry data-plane cost and does not affect request routing once gateway units are active in the target region. From patterns to a cloud growth strategy The patterns in this article show that regional distribution is not a single decision — it is a spectrum of options, each with a different cost, complexity, and risk mitigation profile. The patterns are not mutually exclusive: a portfolio — or even a single workload — may combine multiple patterns to achieve its reliability, compliance, and operational goals. Having the full range of patterns available does not answer the harder question: which patterns are right for your organisation, which applications need them, and what will it take to get there? That is a strategy question — and it requires a deliberate answer. Most organisations today operate their workloads in the Single Region or Failover pattern. Transitioning from that baseline to Parallel, Segmented, or Portable distribution is not an infrastructure change — it is a programme of work that requires investment justification, architectural readiness, and a governed execution plan. A Cloud Growth Strategy based on regional workload distribution starts by defining the organisation's objectives: what reliability targets must be met, which compliance or sovereignty constraints apply, what operational scale is planned, and where the current estate falls short. From those objectives it derives what the regional footprint should look like for this organisation — not as a generic best practice, but as a concrete commitment about which patterns apply to which parts of the portfolio, at what pace, and at what cost. Conclusion Azure's global footprint makes regional workload distribution a choice for every workload — but not a requirement for all of them. The decision starts with risk: the Risk Catalog identifies which fault types and capacity or compliance constraints are actually relevant to the workload, and what blast radius each carries. From that foundation, five patterns emerge — Single Region, Failover, Parallel, Segmented, and Portable — each resolving a distinct set of forces at a different cost and complexity point. Real Azure services rarely fit one pattern cleanly; the service examples in this article illustrate how capability gaps, consistency models, and replication architectures constrain which patterns are structurally achievable. Translating this into organisational practice requires a deliberate Cloud Growth Strategy: classify applications by criticality, assess their suitability for each pattern against their current state, and produce a governed distribution map that is maintained as the portfolio and platform evolve.Azure Front Door edge actions: programmable compute for a secure, resilient, AI-ready edge
The need for secure edge programmability As modern web applications increasingly move decision-making closer to users, programmable compute at the edge is becoming a foundational capability for delivering low-latency, personalized, and intelligent experiences. Azure Front Door edge actions introduces lightweight customer-defined logic that executes close to users at Microsoft's global edge (https://aka.ms/edgeactionsblog). The engineering challenge extends well beyond moving code closer to the request path. It is about enabling edge programmability while preserving the core guarantees customers expect from a global edge platform: hyperscale performance and acceleration, strong security and tenant isolation, resiliency, and fast, controlled recovery. That sets up a much higher engineering bar than simply bringing a serverless runtime to the edge. Programmability introduces customer code, new execution paths, runtime dependencies, and additional failure modes directly into the critical request path. Architecture therefore must make flexibility a first-class capability without compromising the operational characteristics of a hyperscale edge platform. Preserving performance at hyperscale The first architectural challenge was preserving the performance characteristics of Azure Front Door while introducing programmable execution into the request path. Every additional execution step has the potential to increase latency, amplify failures, or reduce throughput at global scale. Edge actions was therefore designed to add programmability without changing the fundamental performance profile customers already expect from Azure Front Door. At request time, Azure Front Door evaluates the request, determines whether an edge action should be executed based on the associated rule, invokes the edge actions runtime, and applies the result inline. Because the runtime sits directly in the request path, every design decision was guided by a common principle: keep execution local whenever possible, bound latency when dependencies degrade, and ensure optional compute never becomes a platform-wide latency amplifier. Performance design principles Node-local execution keeps request processing on the same machine whenever possible, minimizing cross-node communications and preserving low latency. Minimized inter-node hops keep the common path compact while still enabling cluster-level fallback when local dependencies deteriorate. Connection reuse through Edge Action Agent reduces gRPC invocation overhead and improves hot path efficiency. Lightweight Hyperlight isolation provides strong tenant isolation with an execution model suitable for latency-sensitive edge workloads. Fast-fail and circuit-breaker protects latency by bounding waits on degraded dependencies and preventing cascading pressure. Together, these architectural choices introduce programmable compute without turning the Azure Front Door data plane into a distributed orchestration layer. The hot path remains local, predictable, and bounded, with fallback used only when necessary to preserve performance across the global edge. Security and tenant isolation by design Running customer-defined code on a shared global edge fundamentally changes the security model. Unlike traditional request processing, programmable execution introduces untrusted customer code directly into the request path, making strong isolation a foundational architectural requirement rather than an operational safeguard. For Azure Front Door edge actions, every execution is designed to run within a dedicated Hyperlight micro-VM, providing hardware-enforced isolation between customer workloads, the Azure Front Door data plane, and the underlying host environment. Security design principles Hypervisor-backed isolation ensures customer code executes within dedicated Hyperlight micro-VM boundaries rather than shared execution environments. Data plane separation isolates edge actions execution from Azure Front Door's core traffic-processing path. Minimal host surface area reduces the attack surface and limits privileged interactions. Restricted execution context exposes only the request information required to process a request. Reduced operational blast radius helps contain compromised or misbehaving workloads. These architectural boundaries extend beyond workload isolation. Azure Front Door's data plane remains physically separated from the edge actions orchestration service, while each execution receives only the minimum context required to perform its task. This defense-in-depth approach reduces both security risk and operational blast radius without compromising performance. Hyperlight: Security without sacrificing performance A key differentiator of Azure Front Door edge actions is its use of Hyperlight micro-VMs to provide hardware-backed isolation without introducing the traditional performance penalties associated with virtual machines. Hyperlight was designed to make VM-level protection practical for high-throughput function execution, enabling strong tenant isolation while remaining suitable for latency-sensitive edge workloads. Edge actions builds this foundation through the edge action orchestrator, which maintains a pool of warm Hyperlight sandboxes ready to serve requests. By reusing pre-initialized sandboxes instead of creating a new execution environment for every request, edge actions minimizes initialization overhead, reduces request latency, and sustains higher throughput under load. The result is a security model based on VM isolation that remains compatible with the performance expectations of a hyperscale edge platform. Critically, performance optimizations do not weaken isolation guarantees. After each execution, sandbox state is cleaned before reuse, ensuring that subsequent invocations cannot access data from prior executions while preserving the efficiency benefits of warm sandboxing. In internal benchmarking, lightweight edge actions executed in less than 2 ms inside Hyperlight, with approximately 1.27 ms of total sandbox overhead, demonstrating that strong isolation and high-performance edge execution can coexist. Security enables resiliency Security and resiliency are closely related architectural goals. Isolation helps contain malformed inputs, unexpected behavior, and execution failures, preventing individual workloads from affecting the broader platform. In a multitenant edge service, isolation is not only a security requirement; it is also a key resiliency mechanism. Resiliency built into the platform Strong isolation is not only a security property, but also a foundational resiliency mechanism. By containing malformed inputs, unexpected behavior, and execution failures within dedicated execution boundaries, the platform prevents individual workloads from affecting neighboring tenants or the broader service. At hyperscale, robust isolation is essential for maintaining customer trust and predictable platform reliability. Building on that foundation, Azure Front Door edge actions was designed around a simple operating principle: failures are inevitable, but their impact must be predictable, bounded, and recoverable. Because programmable compute introduces additional execution paths and runtime dependencies into the request path, resiliency must be built into the control points that determine when to execute, stop waiting, or fall back. The platform incorporates lessons learned from operating Azure services at a global scale, with a focus on minimizing blast radius, maintaining service continuity, and enabling controlled recovery when dependencies fail, overload, or time out. Resiliency principles Bound failure impact through isolation and containment. Recover predictably using health-aware routing and fallback paths. Protect customer availability first through graceful degradation. Fail fast rather than fail slowly to avoid latency amplification. Continuously validate assumptions through Game Days and fault injections. These principles translate into request-time behavior through deadlines, circuit breakers, fail-open behavior, and health-based fallback. Together, they ensure that optional programmable execution enhances application capabilities without compromising the stability of Azure Front Door's core request-processing pipeline. Continuous validation of resiliency assumptions Resilient architecture is credible only when validation becomes part of the operating model. For edge actions, Game Days and Fault Injections provide recurring opportunities to verify that architectural assumptions continue to hold under production-like stress. Validation includes chaos and failure injections, timeout and dependency-loss exercises, overload and queue-growth scenarios, mixed-workload testing, and interface fuzzing. These exercises answer practical production questions: Does fail-open behavior protect the request path? Do circuit breakers engage early enough? Does fallback routing preserve service continuity? Do malformed inputs remain contained? Repeated validation also strengthens operations. Detection improves, mitigation becomes more predictable, and recovery evolves from architectural intent into demonstrated operational capability. Built for future intelligent & modern workloads Edge actions is designed for lightweight programmable execution today, but the underlying architecture is intended to support increasingly intelligent decision-making over time. The engineering requirement remains unchanged: future intelligence workloads must operate within the same architectural constraints that govern today's request processing - bounded execution, strong isolation, predictable fallback, and protection of the common request path. Architectural implications for intelligence workloads Real-time AI inferencing for request classification and policy evaluation. Intelligent bot, abuse, and fraud detection closer to users. AI-assisted origin selection and traffic-routing decisions. Application-specific SLM-powered decision making at the edge. In that model, the objective is not simply to introduce more intelligence at the edge, but to ensure that intelligence inherits the same platform guarantees as every other component of the request path. Closing thoughts Programmable edge execution is becoming a foundational capability for modern distributed applications. The engineering challenge, however, extends far beyond running customer code closer to users. It is about preserving the system properties that customers already depend on while introducing a new execution surface into the critical request path. Edge actions demonstrates that edge programmability, performance, security, tenant isolation, and resiliency are not independent design goals - they are a single architectural problem that must be solved together. By keeping the common path protected, failures bounded, tenants strongly isolated, and recovery predictable, Azure Front Door edge actions extends the platform's capabilities without compromising the engineering principles that underpin a global hyperscale edge service. Learn more Introducing Hyperlight Edge actions samples: JavaScript request contextAzure Front Door: Resiliency Series – Part 2: Faster recovery (RTO)
Abhishek Tiwari, Vice President of Engineering, Azure Networking Amit Srivastava, Partner Director of PM, Azure Networking Varun Chawla, Partner Director of Engineering, Azure Networking Karthik Uthaman, Principal Engineer, Azure Networking In Part 1 of this blog series, we outlined our four‑pillar strategy for resiliency in Azure Front Door: configuration resiliency, data plane resiliency, tenant isolation, and accelerated Recovery Time Objective (RTO). Together, these pillars help Azure Front Door remain continuously available and resilient at global scale. Part 1 focused on the first two pillars: configuration and data plane resiliency. Our goal is to make configuration propagation safer, so incompatible changes never escape pre‑production environments. We discussed how incompatible configurations are blocked early, and how data plane resiliency ensures the system continues serving traffic from a last‑known‑good (LKG) configuration even if a bad change manages to propagate. We also introduced ‘Food Taster’, a dedicated sacrificial process running in each edge server’s data plane, that pretests every configuration change in isolation, before it ever reaches the live data plane. In this post, we turn to the recovery pillar. We describe how we have made key enhancements to the Azure Front Door recovery path so the system can return to full operation in a predictable and bounded timeframe. For a global service like Azure Front Door, serving hundreds of thousands of tenants across 210+ edge sites worldwide, we set an explicit target: to be able to recover any edge site – or all edge sites – within approximately 10 minutes, even in worst‑case scenarios. In typical data plane crash scenarios, we expect recovery in under a second. Repair status The first blog post in this series mentioned the two Azure Front Door incidents from October 2025 – learn more by watching our Azure Incident Retrospective session recordings for the October 9 th incident and/or the October 29 th incident. Before diving into our platform investments for improving our Recovery Time Objectives (RTO), we wanted to provide a quick update on the overall repair items from these incidents. We are pleased to report that the work on configuration propagation and data plane resiliency is now complete and fully deployed across the platform (in the table below, “Completed” means broadly deployed in production). With this, we have reduced configuration propagation latency from ~45 minutes to ~20 minutes. We anticipate reducing this even further – to ~15 minutes by the end of April 2026, while ensuring that platform stability remains our top priority. Learning category Goal Repairs Status Safe customer configuration deployment Incompatible configuration never propagates beyond ‘EUAP or canary regions’ Control plane and data plane defect fixes Forced synchronous configuration processing Additional stages with extended bake time Early detection of crash state Completed Data plane resiliency Configuration processing cannot impact data plane availability Manage data-plane lifecycle to prevent outages caused by configuration-processing defects. Completed Isolated work-process in every data plane server to process and load the configuration. Completed 100% Azure Front Door resiliency posture for Microsoft internal services Microsoft operates an isolated, independent Active/Active fleet with automatic failover for critical Azure services Phase 1: Onboarded critical services batch impacted on Oct 29 th outage running on a day old configuration Completed Phase 2: Automation & hardening of operations, auto-failover and self-management of Azure Front Door onboarding for additional services March 2026 Recovery improvements Data plane crash recovery in under 10 minutes Data plane boot-up time optimized via local cache (~1 hour) Completed Accelerate recovery time < 10 minutes April 2026 Tenant isolation No configuration or traffic regression can impact other tenants Micro cellular Azure Front Door with ingress layered shards June 2026 Why recovery at edge scale is deceptively hard To understand why recovery took as long as it did, it helps to first understand how the Azure Front Door data plane processes configuration. Azure Front Door operates in 210+ edge sites with multiple servers per site. The data plane of each edge server hosts multiple processes. A master process orchestrates the lifecycle of multiple worker processes, that serve customer traffic. A separate configuration translator process runs alongside the data plane processes, and is responsible for converting customer configuration bundles from the control plane into optimized binary FlatBuffer files. This translation step, covering hundreds of thousands of tenants, represents hours of cumulative computation. A per edge server cache is kept locally at each server level – to enable a fast recovery of the data plane, if needed. Once the configuration translator process produces these FlatBuffer files, each worker processes them independently and memory-maps them for zero-copy access. Configuration updates flow through a two-phase commit: new FlatBuffers are first loaded into a staging area and validated, then atomically swapped into production maps. In-flight requests continue using the old configuration, until the last request referencing them completes. The data process recovery is designed to be resilient to different failure modes. A failure or crash at the worker process level has a typical recovery time of less than one second. Since each server has multiple such worker processes which serve customer traffic, this type of crash has no impact on the data plane. In the case of a master process crash, the system automatically tries to recover using the local cache. When the local cache is reused, the system is able to recover quickly – in approximately 60 minutes – since most of the configurations in the cache were already loaded into the data plane before the crash. However, in certain cases if the cache becomes unavailable or must be invalidated because of corruption, the recovery time increases significantly. During the October 29 th incident, a data plane crash triggered a complete recovery sequence that took approximately 4.5 hours. This was not because restarting a process is slow, it is because a defect in the recovery process invalidated the local cache, which meant that “restart” meant rebuilding everything from scratch. The configuration translator process then had to re-fetch and re-translate every one of the hundreds of thousands of customer configurations, before workers could memory-map them and begin serving traffic. This experience has crystallized three fundamental learnings related to our recovery path: Expensive rework: A subset of crashes discarded all previously translated FlatBuffer artifacts, forcing the configuration translator process to repeat hours of conversion work that had already been validated and stored. High restart costs: Every worker on every node had to wait for the configuration translator process to complete the full translation, before it could memory-map any configuration and begin serving requests. Unbounded recovery time: Recovery time grew linearly with total tenant footprint rather than with active traffic, creating a ‘scale penalty’ as more tenants onboarded to the system. Separately and together, the insight was clear: recovery must stop being proportional to the total configuration size. Persisting ‘validated configurations’ across restarts One of the key recovery improvements was strengthening how validated customer configurations are cached and reused across failures, rather than rebuilding configuration states from scratch during recovery. Azure Front Door already cached customer configurations on host‑mounted storage prior to the October incident. The platform enhancements post outage focused on making the local configuration cache resilient to crashes, partial failures, and bad tenant inputs. Our goal was to ensure that recovery behavior is dominated by serving traffic safely, not by reconstructing configuration state. This led us to two explicit design goals… Design goals No category of crash should invalidate the configuration cache: Configuration cache invalidation must never be the default response to failures. Whether the failure is a worker crash, master crash, data plane restart, or coordinated recovery action, previously validated customer configurations should remain usable—unless there is a proven reason to discard it. Bad tenant configuration must not poison the entire cache: A single faulty or incompatible tenant configuration should result in targeted eviction of that tenant’s configuration only—not wholesale cache invalidation across all tenants. Platform enhancements Previously, customer configurations persisted to host‑mounted storage, but certain failure paths treated the cache as unsafe and invalidated it entirely. In those cases, recovery implicitly meant reloading and reprocessing configuration for hundreds of thousands of tenants before traffic could resume, even though the vast majority of cached data was still valid. We changed the recovery model to avoid invalidating customer configurations, with strict scoping around when and how cached entries are discarded: Cached configurations are no longer invalidated based on crash type. Failures are assumed to be orthogonal to configuration correctness unless explicitly proven otherwise. Cache eviction is granular and tenant‑scoped. If a cached configuration fails validation or load checks, only that tenant’s configuration is discarded and reloaded. All other tenant configurations remain available. This ensures that recovery does not regress into a fleet‑wide rebuild due to localized or unrelated faults. Safety and correctness Durability is paired with strong correctness controls, to prevent unsafe configurations from being served: Per‑tenant validation on load: Each cached tenant configuration is validated during the ‘load and verification’ phase, before being promoted for traffic serving. Therefore, failures are contained to that tenant. Targeted re‑translation: When validation fails, only the affected tenant’s configuration is reloaded or reprocessed. Therefore, the cache for other tenants is left untouched. Operational escape hatch: Operators retain the ability to explicitly instruct a clean rebuild of the configuration cache (with proper authorization), preserving control without compromising the default fast‑recovery path. Resulting behavior With these changes, recovery behavior now aligns with real‑world traffic patterns - configuration defects impact tenants locally and predictably, rather than globally. The system now prefers isolated tenant impact, and continued service using last-known-good over aggressive invalidation, both of which are critical for predictable recovery at the scale of Azure Front Door. Making recovery scale with active traffic, not total tenants Reusing configuration cache solves the problem of rebuilding configuration in its entirety, but even with a warm cache, the original startup path had a second bottleneck: eagerly loading a large volume of tenant configurations into memory before serving any traffic. At our scale, memory-mapping, parsing hundreds of thousands of FlatBuffers, constructing internal lookup maps, adding Transport Layer Security (TLS) certificates and configuration blocks for each tenant, collectively added almost an hour to startup time. This was the case even when a majority of those tenants had no active traffic at that moment. We addressed this by fundamentally changing when configuration is loaded into workers. Rather than eagerly loading most of the tenants at startup across all edge locations, Azure Front Door now uses an Machine Learning (ML)-optimized lazy loading model. In the new architecture, instead of loading a large number of tenant configurations, we only load a small subset of tenants that are known to be historically active in a given site, we call this the “warm tenants” list. The warm tenants list per edge site is created through a sophisticated traffic analysis pipeline that leverages ML. However, loading the warm tenants is not good enough, because when a request arrives and we don’t have the configuration in memory, we need to know two things. Firstly, is this a request from a real Azure Front Door tenant – and, if it is, where can I find the configuration? To answer these questions, each worker maintains a hostmap that tracks the state of each tenant’s configuration. This hostmap is constructed during startup, as we process each tenant configuration – if the tenant is in the warm list, we will process and load their configuration fully; if not, then we will just add an entry into the hostmap where all their domain names are mapped to the configuration path location. When a request arrives for one of these tenants, the worker loads and validates that tenant’s configuration on demand, and immediately begins serving traffic. This allows a node to start serving its busiest tenants within a few minutes of startup, while additional tenants are loaded incrementally only when traffic actually arrives—allowing the system to progressively absorb cold tenants as demand increases. The effect on recovery is transformative. Instead of recovery time scaling with the total number of tenants configured on a server, it scales with the number of tenants actively receiving traffic. In practice, even at our busiest edge sites, the active tenant set is a small fraction of the total. Just as importantly, this modified form of lazy loading provides a natural failure isolation boundary. Most Edge sites won’t ever load a faulty configuration of an inactive tenant. When a request for an inactive tenant with an incompatible configuration arrives, impact is contained to a single worker. The configuration load architecture now prefers serving as many customers as quickly as possible, rather than waiting until everything is ready before serving anyone. The above changes are slated to complete in April 2026 and will bring our RTO from the current ~1 hour to under 10 minutes – for complete recovery from a worst case scenario. Continuous validation through Game Days A critical element of our recovery confidence comes from GameDay fault-injection testing. We don’t simply design recovery mechanisms and assume they work—we break the system deliberately and observe how it responds. Since late 2025, we have conducted recurring GameDay drills that simulate the exact failure scenarios we are defending against: Food Taster crash scenarios: Injecting deliberately faulty tenant configurations, to verify that they are caught and isolated with zero impact on live traffic. In our January 2026 GameDay, the Food Taster process crashed as expected, the system halted the update within approximately 5 seconds, and no customer traffic was affected. Master process crash scenarios: Triggering master process crashes across test environments to verify that workers continue serving traffic, that the Local Config Shield engages within 10 seconds, and that the coordinated recovery tool restores full operation within the expected timeframe. Multi-region failure drills: Simulating simultaneous failures across multiple regions to validate that global Config Shield mechanisms engage correctly, and that recovery procedures scale without requiring manual per-region intervention. Fallback test drills for critical Azure services running behind Azure Front Door: In our February 2026 GameDay, we simulated the complete unavailability of Azure Front Door, and successfully validated failover for critical Azure services with no impact to traffic. These drills have both surfaced corner cases and built operational confidence. They have transformed recovery from a theoretical plan into tested, repeatable muscle memory. As we noted in an internal communication to our team: “Game day testing is a deliberate shift from assuming resilience to actively proving it—turning reliability into an observed and repeatable outcome.” Closing Part 1 of this series emphasized preventing unsafe configurations from reaching the data plane, and data plane resiliency in case an incompatible configuration reaches production. This post has shown that prevention alone is not enough—when failures do occur, recovery must be fast, predictable, and bounded. By ensuring that the FlatBuffer cache is never invalidated, by loading only active tenants, and by building safe coordinated recovery tooling, we have transformed failure handling from a fleet-wide crisis into a controlled operation. These recovery investments work in concert with the prevention mechanisms described in Part 1. Together, they ensure that the path from incident detection to full service restoration is measured in minutes, with customer traffic protected at every step. In the next post of this series, we will cover the third pillar of our resiliency strategy: tenant isolation—how micro-cellular architecture and ingress-layered sharding can reduce the blast radius of any failure to a small subset, ensuring that one customer’s configuration or traffic anomaly never becomes everyone’s problem. We deeply value our customers’ trust in Azure Front Door. We are committed to transparently sharing our progress on these resiliency investments, and to exceed expectations for safety, reliability, and operational readiness.Azure Front Door: Implementing lessons learned following October outages
Abhishek Tiwari, Vice President of Engineering, Azure Networking Amit Srivastava, Principal PM Manager, Azure Networking Varun Chawla, Partner Director of Engineering Link to Part 2 - Azure Front Door Resiliency Series Link to Part 3 - Azure Front Door Resiliency Series Introduction Azure Front Door is Microsoft's advanced edge delivery platform encompassing Content Delivery Network (CDN), global security and traffic distribution into a single unified offering. By using Microsoft's extensive global edge network, Azure Front Door ensures efficient content delivery and advanced security through 210+ global and local points of presence (PoPs) strategically positioned closely to both end users and applications. As the central global entry point from the internet onto customer applications, we power mission critical customer applications as well as many of Microsoft’s internal services. We have a highly distributed resilient architecture, which protects against failures at the server, rack, site and even at the regional level. This resiliency is achieved by the use of our intelligent traffic management layer which monitors failures and load balances traffic at server, rack or edge sites level within the primary ring, supplemented by a secondary-fallback ring which accepts traffic in case of primary traffic overflow or broad regional failures. We also deploy a traffic shield as a terminal safety net to ensure that in the event of a managed or unmanaged edge site going offline, end user traffic continues to flow to the next available edge site. Like any large-scale CDN, we deploy each customer configuration across a globally distributed edge fleet, densely shared with thousands of other tenants. While this architecture enables global scale, it carries the risk that certain incompatible configurations, if not contained, can propagate broadly and quickly which can result in a large blast radius of impact. Here we describe how the two recent service incidents impacting Azure Front Door have reinforced the need to accelerate ongoing investments in hardening our resiliency, and tenant isolation strategy to mitigate likelihood and the scale of impact from this class of risk. October incidents: recap and key learnings Azure Front Door experienced two service incidents; on October 9 th and October 29 th , both with customer-impacting service degradation. On October 9 th : A manual cleanup of stuck tenant metadata bypassed our configuration protection layer, allowing incompatible metadata to propagate beyond our canary edge sites. This metadata was created on October 7 th , from a control-plane defect triggered by a customer configuration change. While the protection system initially blocked the propagation, the manual override operation bypassed our safeguards. This incompatible configuration reached the next stage and activated a latent data-plane defect in a subset of edge sites, causing availability impact primarily across Europe (~6%) and Africa (~16%). You can learn more about this issue in detail at https://aka.ms/AIR/QNBQ-5W8 On October 29 th : A different sequence of configuration changes across two control-plane versions produced incompatible metadata. Because the failure mode in the data-plane was asynchronous, the health checks validations embedded in our protection systems were all passed during the rollout. The incompatible customer configuration metadata successfully propagated globally through a staged rollout and also updated the “last known good” (LKG) snapshot. Following this global rollout, the asynchronous process in data-plane exposed another defect which caused crashes. This impacted connectivity and DNS resolutions for all applications onboarded to our platform. Extended recovery time amplified impact on customer applications and Microsoft services. You can learn more about this issue in detail at https://aka.ms/AIR/YKYN-BWZ We took away a number of clear and actionable lessons from these incidents, which are applicable not just to our service, but to any multi-tenant, high-density, globally distributed system. Configuration resiliency – Valid configuration updates should propagate safely, consistently, and predictably across our global edge, while ensuring that incompatible or erroneous configuration never propagate beyond canary environments. Data plane resiliency - Additionally, configuration processing in the data plane must not cause availability impact to any customer. Tenant isolation – Traditional isolation techniques such as hardware partitioning and virtualization are impractical at edge sites. This requires innovative sharding techniques to ensure single tenant-level isolation – a must-have to reduce potential blast radius. Accelerated and automated recovery time objective (RTO) – System should be able to automatically revert to last known good configuration in an acceptable RTO. In case of a service like Azure Front Door, we deem ~10 mins to be a practical RTO for our hundreds of thousands of customers at every edge site. Post outage, given the severity of impact which allowed an incompatible configuration to propagate globally, we made the difficult decision to temporarily block configuration changes in order to expedite rollout of additional safeguards. Between October 29 th to November 5 th , we prioritized and deployed immediate hardening steps before opening up the configuration change. We are confident that the system is stable, and we are continuing to invest in additional safeguards to further strengthen the platform's resiliency. Learning category Goal Repairs Status Safe customer configuration deployment Incompatible configuration never propagates beyond Canary · Control plane and data plane defect fixes · Forced synchronous configuration processing · Additional stages with extended bake time · Early detection of crash state Completed Data plane resiliency Configuration processing cannot impact data plane availability Manage data-plane lifecycle to prevent outages caused by configuration-processing defects. Completed Isolated work-process in every data plane server to process and load the configuration. January 2026 100% Azure Front Door resiliency posture for Microsoft internal services Microsoft operates an isolated, independent Active/Active fleet with automatic failover for critical Azure services Phase 1: Onboarded critical services batch impacted on Oct 29 th outage running on a day old configuration Completed Phase 2: Automation & hardening of operations, auto-failover and self-management of Azure Front Door onboarding for additional services March 2026 Recovery improvements Data plane crash recovery in under 10 minutes Data plane boot-up time optimized via local cache (~1 hour) Completed Accelerate recovery time < 10 minutes March 2026 Tenant isolation No configuration or traffic regression can impact other tenants Micro cellular Azure Front Door with ingress layered shards June 2026 This blog is the first in a multi-part series on Azure Front Door resiliency. In this blog, we will focus on configuration resiliency—how we are making the configuration pipeline safer and more robust. Subsequent blogs will cover tenant isolation and recovery improvements. How our configuration propagation works Azure Front Door configuration changes can be broadly classified into three distinct categories. Service code & data – these include all aspects of Azure Front Door service like management plane, control plane, data plane, configuration propagation system. Azure Front Door follows a safe deployment practice (SDP) process to roll out newer versions of management, control or data plane over a period of approximately 2-3 weeks. This ensures that any regression in software does not have a global impact. However, latent bugs that escape pre-validation and SDP rollout can remain undetected until a specific combination of customer traffic patterns or configuration changes trigger the issue. Web Application Firewall (WAF) & L7 DDoS platform data – These datasets are used by Azure Front Door to deliver security and load-balancing capabilities. Examples include GeoIP data, malicious attack signatures, and IP reputation signatures. Updates to these datasets occur daily through multiple SDP stages with an extended bake time of over 12 hours to minimize the risk of global impact during rollout. This dataset is shared across all customers and the platform, and it is validated immediately since it does not depend on variations in customer traffic or configuration steps. Customer configuration data – Examples of these are any customer configuration change—whether a routing rule update, backend pool modification, WAF rule change, or security policy change. Due to the nature of these changes, it is expected across the edge delivery / CDN industry to propagate these changes globally in 5-10 mins. Both outages stemmed from issues within this category. All configuration changes, including customer configuration data, are processed through a multi-stage pipeline designed to ensure correctness before global rollout across Azure Front Door’s 200+ edge locations. At a high level, Azure Front Door’s configuration propagation system has two distinct components - Control plane – Accepts customer API/portal changes (create/update/delete for profiles, routes, WAF policies, origins, etc.) and translates them into internal configuration metadata which the data plane can understand. Data plane – Globally distributed edge servers that terminate client traffic, apply routing/WAF logic, and proxy to origins using the configuration produced by the control plane. Between these two halves sits a multi-stage configuration rollout pipeline with a dedicated protection system (known as ConfigShield): Changes flow through multiple stages (pre-canary, canary, expanding waves to production) rather than going global at once. Each stage is health-gated: the data plane must remain within strict error and latency thresholds before proceeding. Each stage’s health check also rechecks previous stage’s health for any regressions. A successfully completed rollout updates a last known good (LKG) snapshot used for automated rollback. Historically, rollout targeted global completion in roughly 5–10 minutes, in line with industry standards. Customer configuration processing in Azure Front Door data plane stack Customer configuration changes in Azure Front Door traverse multiple layers—from the control plane through the deployment system—before being converted into FlatBuffers at each Azure Front Door node. These FlatBuffers are then loaded by the Azure Front Door data plane stack, which runs as Kubernetes pods on every node. FlatBuffer Composition: Each FlatBuffer references several sub-resources such as WAF and Rules Engine schematic files, SSL certificate objects, and URL signing secrets. Data plane architecture: o Master process: Accepts configuration changes (memory-mapped files with references) and manages the lifecycle of worker processes. o Workers: L7 proxy processes that serve customer traffic using the applied configuration. Processing flow for each configuration update: Load and apply in master: The transformed configuration is loaded and applied in the master process. Cleanup of unused references occurs synchronously except for certain categories à October 9 outage occurred during this step due to a crash triggered by incompatible metadata. Apply to workers: Configuration is applied to all worker processes without memory overhead (FlatBuffers are memory-mapped). Serve traffic: Workers start consuming new FlatBuffers for new requests; in-flight requests continue using old buffers. Old buffers are queued for cleanup post-completion. Feedback to deployment service: Positive feedback signals readiness for rollout.Cleanup: FlatBuffers are freed asynchronously by the master process after all workers load updates à October 29 outage occurred during this step due to a latent bug in reference counting logic. The October incidents showed we needed to strengthen key aspects of configuration validation, propagation safeguards, and runtime behavior. During the Azure Front Door incident on October 9 th , that protection system worked as intended but was later bypassed by our engineering team during a manual cleanup operation. During this Azure Front Door incident on October 29 th , the incompatible customer configuration metadata progressed through the protection system, before the delayed asynchronous processing task resulted in the crash. Configuration propagation safeguards Based on learnings from the incidents, we are implementing a comprehensive set of configuration resiliency improvements. These changes aim to guarantee that any sequence of configuration changes cannot trigger instability in the data plane, and to ensure quicker recovery in the event of anomalies. Strengthening configuration generation safety This improvement pivots on a ‘shift-left’ strategy where we want to ensure that we catch regression early before they propagate to production. It also includes fixing the latent defects which were the proximate cause of the outage. Fixing outage specific defects - We have fixed the control-plane defects that could generate incompatible tenant metadata under specific operation sequences. We have also remediated the associated data-plane defects. Stronger cross-version validation - We are expanding our test and validation suite to account for changes across multiple control plane build versions. This is expected to be fully completed by February 2026. Fuzz testing - Automated fuzzing and testing of metadata generation contract between the control plane and the data plane. This allows us to generate an expanded set of invalid/unexpected configuration combinations which might not be achievable by traditional test cases alone. This is expected to be fully completed by February 2026. Preventing incompatible configurations from being propagated This segment of the resiliency strategy strives to ensure that a potentially dangerous configuration change never propagates beyond canary stage. Protection system is “always-on” - Enhancements to operational procedures and tooling prevent bypass in all scenarios (including internal cleanup/maintenance), and any cleanup must flow through the same guarded stages and health checks as standard configuration changes. This is completed. Making rollout behavior more predictable and conservative - Configuration processing in the data plane is now fully synchronous. Every data plane issue due to incompatible meta data can be detected withing 10 seconds at every stage. This is completed. Enhancement to deployment pipeline - Additional stages during roll-out and extended bake time between stages serve as an additional safeguard during configuration propagation. This is completed. Recovery tool improvements now make it easier to revert to any previous version of LKG with a single click. This is completed. These changes significantly improve system safety. Post-outage we have increased the configuration propagation time to approximately 45 minutes. We are working towards reducing configuration propagation time closer to pre-incident levels once additional safeguards covered in the Data plane resiliency section below are completed by mid-January, 2026. Data plane resiliency The data plane recovery was the toughest part of recovery efforts during the October incidents. We must ensure fast recovery as well as resilience to configuration processing related issues for the data plane. To address this, we implemented changes that decouple the data plane from incompatible configuration changes. With these enhancements, the data plane continues operating on the last known good configuration—even if the configuration pipeline safeguards fail to protect as intended. Decoupling data plane from configuration changes Each server’s data plane consists of a master process which accepts configuration changes and manages lifecycle of multiple worker processes which serve customer traffic. One of the critical reasons for the prolonged outage in October was that due to latent defects in the data plane, when presented with a bad configuration the master process crashed. The master is a critical command-and-control process and when it crashes it takes down the entire data plane, in that node. Recovery of the master process involves reloading hundreds of thousands of configurations from scratch and took approximately 4.5 hours. We have since made changes to the system to ensure that even in the event of the master process crash due to any reason - including incompatible configuration data being presented - the workers remain healthy and able to serve traffic. During such an event, the workers would not be able to accept new configuration changes but will continue to serve customer traffic using the last known good configuration. This work is completed. Introducing Food Taster: strengthening config propagation resiliency In our efforts to further strengthen Azure Front Door’s configuration propagation system, we are introducing an additional configuration safeguard known internally as Food Taster which protects the master and worker processes from any configuration change related incidents, thereby ensuring data plane resiliency. The principle is simple: every data-plane server will have a redundant and isolated process – the Food Taster – whose only job is to ingest and process new configuration metadata first and then pass validated configuration changes to active data plane. This redundant worker does not accept any customer traffic. All configuration processing in this Food Taster is fully synchronous. That means we do all parsing, validation, and any expensive or risky work up front, and we do not move on until the Food Taster has either proven the configuration is safe or rejected it. Only when the Food Taster successfully loads the configuration and returns “Config OK” does the master process proceed to load the same config and then instruct the worker processes to do the same. If anything goes wrong in the Food Taster, the failure is contained to that isolated worker; the master and traffic-serving workers never see that invalid configuration. We expect this safeguard to reach production globally in January 2026 timeframe. Introduction of this component will also allow us to return closer to pre-incident level of configuration propagation while ensuring data plane safety. Closing This is the first in a series of planned blogs on Azure Front Door resiliency enhancements. We are continuously improving platform safety and reliability and will transparently share updates through this series. Upcoming posts will cover advancements in tenant isolation and improvements to recovery time objectives (RTO). We deeply value our customers’ trust in Azure Front Door. The October incidents reinforced how critical configuration resiliency is, and we are committed to exceeding industry expectations for safety, reliability, and transparency. By hardening our configuration pipeline, strengthening safety gates, and reinforcing isolation boundaries, we’re making Azure Front Door even more resilient so your applications can be too.Introducing Layered Ingress Sharding: Achieving Single-Tenant Isolation in Multi-Tenant Services
Abhishek Tiwari, Vice President of Engineering, Azure Networking Amit Srivastava, Partner Director of PM, Azure Networking Varun Chawla, Partner Director of Engineering, Azure Networking Links to the three-part AFD blog series: Part 1 Part 2 Part 3 Why Multi‑Tenant Isolation Is Still Hard at Hyperscale Modern cloud platforms thrive on multitenancy. By sharing infrastructure across tenants, services like Azure Front Door (AFD) can deliver massive scale, global reach, and cost efficiency. At hyperscale, however, this efficiency comes with a hard truth: rare failures are inevitable, and their blast radius matters more than their frequency. When hundreds of thousands of tenants share a global data plane, a single misbehaving tenant, configuration regression, or zero-day exploit can turn a low probability event into a high impact outage. Over the years, the industry has developed many protections — rate limiting, circuit breakers, fair share scheduling, crash protection, and various sharding strategies. These techniques dramatically reduce average case risk, but they still struggle to bound worst case impact. In particular, they fall short of delivering what customers intuitively expect: single tenant isolation semantics (the guarantee that one tenant’s failure does not affect another) without requiring dedicated per-tenant infrastructure. At Azure Front Door, we’ve been working on a new architectural approach that directly targets worst case blast radius. Today, I’m excited to introduce Layered Ingress Sharding, a sharding strategy designed to enable single tenant fault isolation for largescale multitenant services. From Traditional Sharding to Ingress Sharding Traditional partitioning assigns each tenant to a fixed shard. This limits blast radius, but tenants in the same shard can still experience complete outages when that shard fails. Shuffle sharding improves on this by assigning each tenant to a subset of instances, where subsets partially overlap, dramatically reducing the probability of widespread impact. However, shuffle sharding still allows 100% availability loss for tenants in the affected shard, relies heavily on client retries, and introduces nontrivial capacity loss in overlapping shards. To address these limitations, we introduced Ingress Sharding. With ingress sharding, an ingress controller, which we call IRIS (Intelligent Routing with Ingress Sharding), sits directly on the data path. Ingress sharding uses shuffle sharding to construct shards from service instances; IRIS operates on top of these shards to perform tenant-aware, capacity-aware routing rather than introducing a new shard construction algorithm. IRIS identifies the tenant for each incoming connection and deterministically maps that tenant to a shard. Instead of relying on clients to retry when a shard is unhealthy, IRIS actively: Monitors the health of service instances Tracks available capacity in real time Retries and reroutes traffic internally Steers traffic away from unhealthy or overloaded instances Dynamically expands the set of service instances used for oversized tenants when sustained load exceeds a single shard’s capacity In effect, IRIS turns shard selection into a real-time, capacity-aware decision that is reevaluated for every new connection. This moves fault resilience and load balancing inside the platform, rather than pushing that burden onto clients. Ingress sharding significantly improves isolation and resilience, but on its own, a tenant can still experience a complete loss of availability if all instances in its shard are affected. Introducing Layers: Isolation Through Independence Layered Sharding adds a new dimension to multitenant isolation. In Layered Sharding, the service is divided into multiple independent layers. A layer represents an independent serving dimension of the system capable of handling tenant traffic independently. This technique was developed to reduce blast radius by changing how tenants are assigned across shards, rather than changing the underlying shard construction within a single layer. A key design goal is that layered sharding is orthogonal to the underlying sharding strategy. It works with existing approaches, whether that is standard partitioning-based sharding, shuffle sharding, or other shard assignment schemes used within a layer. Within each layer: Service instances are grouped into shards using an existing sharding technique (for example, traditional partitioning or shuffle sharding) Each tenant is assigned to a shard independently in that layer Crucially, tenant-to-shard assignments are randomized and independent across layers. This independence is what gives layered sharding its isolation properties, regardless of the specific sharding algorithm used within a single layer. The definition of a layer itself is intentionally flexible and service dependent. In Azure Front Door, each server naturally acts as one layer. In other services, a layer might correspond to a cluster, a scale unit, a fault domain, or even a regional partition — any unit capable of serving tenant traffic independently while preserving uniform load distribution. The result is powerful: even if a tenant’s traffic causes failures in one shard in one layer, it is statistically unlikely that the same tenant will collide with the same peers across many layers. Instead of experiencing a full outage, other tenants see at most a small, transient reduction in capacity, often invisible with standard retry behavior. Layered sharding alone already reduces availability impact across tenants. But when combined with ingress sharding, it enables something fundamentally stronger. Layered Ingress Sharding Layered Ingress Sharding integrates two complementary ideas: Layered Sharding spreads tenants across many independent layers with randomized shard assignments. Ingress Sharding dynamically routes traffic to healthy service instances across layers using real‑time health and capacity signals. The key blast radius reduction that enables single tenant isolation comes from the combination of independent shard randomization across layers with active, intelligent traffic steering. When a tenant misbehaves due to harmful traffic, a bad configuration, or an unknown vulnerability, IRIS detects unhealthy service instances and automatically routes traffic to healthy shards in other layers. Because shard assignments are independent, IRIS can always find unaffected capacity for well-behaved tenants. The resulting behavior is a fundamental shift in multitenant failure dynamics: Outages remain localized to the misbehaving tenant Healthy tenants continue to serve traffic Blast radius shrinks from fleetwide to tenant-local In effect, a shared multi‑tenant system begins to behave like it has single tenant‑ isolation semantics, without abandoning multitenancy. Why the Math Works The guarantees behind layered ingress sharding are not heuristic, they’re statistical. Because tenant-to-shard assignments are randomized independently across layers, the probability that two tenants repeatedly collide in the same shard follows a binomial distribution. With production representative configurations, tens of layers and shuffle-sharded service instances, the probability that an arbitrary tenant experiences a user-visible failure due to another tenant drops below what standard client retries already mask. Instead of asking “Can a noisy neighbor impact me?”, the system answers “What is the probability that a single connection attempt is unlucky across all layers?” and that probability decreases exponentially as the number of layers increases. This allows us to trade catastrophic outages for rare, isolated, and standard retry-mitigated events. A Hidden Benefit: Identifying Bad Tenants Layered ingress sharding provides an additional, powerful side benefit: automated identification of misbehaving tenants. Because shard assignments are computed independently across layers, a tenant that is consistently responsible for failures appears as a common factor across impacted shards and service instances. By correlating signals across layers, the platform can accurately identify the offending tenant and apply targeted mitigations such as isolation, throttling, or traffic steering without relying on coarse-grained circuit breakers that penalize everyone. This dramatically improves response time under high load or adversarial conditions while preserving availability for unaffected tenants. Beyond Azure Front Door While Layered Ingress Sharding was developed in the context of Azure Front Door, the underlying principle is broadly applicable. Any large‑scale multi‑tenant system that: Serves many tenants from shared infrastructure Can distribute traffic uniformly across independent layers Can enforce shard-level isolation within each layer can benefit from this approach. Layers don’t have to be servers they could be clusters, scale units, or regional partitions. The key is independent assignment across layers combined with intelligent ingress routing. We believe this pattern represents a reusable architectural strategy for building resilient, hyperscale, multi‑tenant services. Closing Thoughts Multi‑tenancy doesn’t have to mean shared fate. Layered Ingress Sharding shows that by combining probabilistic isolation with intelligent ingress routing, we can build systems where failures are expected, bounded, and automatically contained, even at hyperscale. Rather than eliminating failure, this approach mathematically constrains its impact. And in large‑scale multi‑tenant platforms, that distinction makes all the difference.Azure Front Door: Resiliency Series – Part 3: Tenant isolation
Abhishek Tiwari, Vice President of Engineering, Azure Networking Amit Srivastava, Partner Director of PM, Azure Networking Varun Chawla, Partner Director of Engineering, Azure Networking Azure Front Door serves hundreds of thousands of tenants from hundreds of edge locations, densely sharing the globally distributed edge fleet. That density is exactly what allows us to deliver global scale, performance, and cost efficiency. It also means that, without strong isolation, a single tenant’s incompatible configuration or anomalous traffic can, in the worst case, affect many other tenants. The October 2025 incidents reinforced how important it is to contain this class of risk. Our goal for this tenant isolation is simple to state and hard to achieve: no single tenant’s configuration or traffic should be able to impact any other tenant. In Part 1 of our three part mini blog series, we outlined our four‑pillar strategy for improving the resiliency of Azure Front Door: configuration resiliency, data plane resiliency, tenant isolation, and accelerated Recovery Time Objective (RTO). Part 1 detailed how we would make configuration propagation safer and how the data plane keeps serving from a ‘last‑known‑good’ (LKG) configuration, even if an incompatible configuration change is propagated to the data plane. Part 2 turned to recovery, showing how we bring the system back to full operation in an accelerated, predictable, and in a bounded timeframe. In this final part, we turn to the tenant isolation pillar that ensures that any single tenant configuration or traffic issues are limited in scope to that tenant alone and do not impact other tenants. We will also show how Azure Front Door achieves single-tenant containment through configuration isolation, lazy loading, and a micro-cellular layered ingress-sharding architecture. Repair status: all outstanding items now complete Before we dive into tenant isolation, here is a final update on the overall repair items from the two October 2025 incidents (you can review the details in our Azure Incident Retrospective sessions for the October 9th and October 29th incidents). We are pleased to report that all outstanding work across every pillar is now complete and fully deployed in production – including the tenant isolation work described in this post. With these safeguards in place, we have also returned configuration propagation latency to pre‑incident levels while keeping platform stability our top priority. In the table below, “Completed” means broadly deployed in production. Learning category Goal Repairs Status Safe customer configuration deployment Incompatible configuration never propagates beyond ‘EUAP or canary regions’ Control plane and data plane defect fixes; forced synchronous configuration processing; additional stages with extended bake time; early detection of crash state Completed Data plane resiliency Configuration processing cannot impact data plane availability Manage data‑plane lifecycle to prevent outages caused by configuration‑processing defects; isolated work‑process in every data plane server to process and load the configuration Completed 100% Azure Front Door resiliency posture for Microsoft internal services Microsoft operates an isolated, independent Active/Active fleet with automatic failover for critical Azure services Phase 1: onboarded critical services batch impacted on Oct 29th outage running on a day‑old configuration; Phase 2: automation & hardening of operations, auto‑failover and self‑management of onboarding for additional services Completed Recovery improvements Data plane crash recovery in under 10 minutes Data plane boot‑up time optimized via local cache; recovery time accelerated to under 10 minutes Completed Tenant isolation No configuration or traffic regression can impact other tenants Micro‑cellular Azure Front Door with ingress layered shards Completed Why isolation at edge scale is deceptively hard Traditional isolation techniques such as dedicating separate hardware to each tenant or running every tenant inside its own virtual machine are impractical at the edge. Edge sites are constrained on space, power, and capacity. The entire premise of a modern, multi-tenant application delivery platform is that any tenant can be served from any site closest to the user. We cannot simply partition hundreds of thousands of tenants onto dedicated machines without giving up either proximity, scale, or the efficiency that make the edge fast and cost efficient. Isolation therefore, must be achieved in software, inside a multi-tenant fleet. What we already do today Azure Front Door already includes several layers of tenant isolation and partitioning. However, the incidents in October clearly highlighted that these techniques were not enough. Prior to the incidents, our protection mechanisms included: Infrastructure partitioning. Edge sites were organized into physically isolated primary and fallback traffic rings. Noisy‑neighbor protection. Fair‑share resource allocation, rate limiting, and anomaly-based load protection kept any single tenant from monopolizing shared resources such as CPU, memory, or network bandwidth on an Azure Front Door server. Circuit breakers. Circuit breakers shed costly work first and can disable a risky per‑tenant feature before it exhausts shared resources on a server. Real‑time crash protection. A crash‑analysis system correlates crash signatures across machines and can pinpoint and block crash patterns caused by tenant IPs or traffic patterns. While these protections are valuable, many of them are reactive and proved insufficient during the October incidents. The next generation of isolation makes single‑tenant containment a fundamental part of the platform which governs how configurations are loaded, and how traffic is served. Configuration isolation: loading only what is needed Part 2 introduced ‘lazy loading’ as a recovery optimization technique. It is also an important configuration‑isolation mechanism. Historically, every worker on every edge server had to be ready to serve any tenant, which meant each worker loaded a large set of tenant configurations. A single incompatible configuration could therefore ripple across many workers. With lazy loading, a worker loads a tenant’s configuration and its TLS certificates only when it actually receives traffic for that tenant. The practical consequence for isolation is powerful: a faulty configuration can only affect the workers that have loaded that specific tenant, never the entire server or fleet. Combined with per‑tenant validation on load, and the Food Taster safeguard from Part 1 (a sacrificial process that pretests every configuration change in isolation), configuration problems are caught early and contained to the smallest possible footprint. Figure 1: With lazy loading, an incompatible configuration is contained to the workers serving that tenant, instead of poisoning the whole server. Tenant isolation: a micro-cellular, layered ingress sharding architecture Configuration isolation limits the blast radius of an incompatible configuration. Traffic isolation addresses the other half of the problem: a tenant whose anomalous traffic incident, like a sudden surge, a pathological request pattern, or malicious activity, could degrade a shared worker. Our approach is a micro‑cellular architecture that combines multiple concepts working together. Worker‑process isolation. Each edge server already runs many independent worker processes. Instead of letting every worker serve every tenant, we assign tenants to specific groups of workers. Those worker group (shards) become the unit of isolation: if a tenant destabilizes its shard, the impact is contained to that shard’s workers while the rest of the server keeps serving normally. Ingress sharding. Rather than a handful of fixed shards, we compose shards from overlapping subsets of a server’s workers. Even a modest number of workers can be combined into an enormous number of distinct, overlapping shards – giving us a very large number of fine‑grained fault domains without dedicating hardware to every tenant. Figure 2: Tenants are randomly assigned to different shards on each server (layer). Even when a good tenant shares the noisy tenant’s shard on one layer, routing steers its traffic to healthy shards on the others. Multi‑layer ingress sharding. This is where ‘layered’ comes in. Each edge server is treated as an independent layer, and each tenant is assigned to a different, randomly chosen shard on every server. Because assignments are independent from one server to the next, two tenants that happen to share a shard on one server are extremely unlikely to share a shard again on another server. The chance of any good tenant repeatedly colliding with a noisy tenant across many servers becomes vanishingly small. Intelligent ingress routing. Tying it together is a routing layer that terminates each incoming connection, identifies the tenant, and steers the request to that tenant’s assigned, healthy shard. If a shard is unhealthy or saturated, traffic is directed to the tenant’s healthy shards on other layers. Figure 3: Intelligent Ingress Routing The combined effect is that when a noisy tenant overwhelms or crashes its shard on one server, only that shard is affected. Because every other tenant is spread across a different, randomized set of shards, they continue to find healthy paths, and the routing layer moves their traffic accordingly. A worst-case availability problem is downgraded to, at most, a small and redistributable capacity problem, that the routing layer smooths over. An in-depth technical analysis of layered ingress sharding is available here for reference. Shrinking the blast radius Taken together, these mechanisms fundamentally change the shape of failure. In a uniform, fully shared fleet, an incompatible tenant can, in the worst case, affect a large share of the tenants on a machine, in an edge location, or beyond. With configuration isolation and layered ingress sharding, the same failure is confined to a subset of workers serving the offending tenant. Our target for this tenant isolation pillar is effectively single‑tenant containment: a configuration or traffic anomaly caused by one tenant should never cause issues to any other tenants. Figure 4: From a shared fleet where a single tenant can affect many, to micro‑cellular shards that confine impact to the offending tenant. Validating isolation in practice As with our recovery work, we don’t simply design these boundaries and assume they hold, we test them. Through deliberate fault‑injections, we have pushed noisy and faulty tenants into the system and confirmed that impact stayed contained to the offending shard, that healthy tenants kept serving, and that the routing layer steered around unhealthy shards as intended. This turns isolation from a design claim into a well-drilled, and repeatable outcome. Closing This post concludes our three-part mini blog series on Azure Front Door resiliency. We have shared how we are making configuration propagation safer (Part 1), recovering faster when failures do occur (Part 2), and containing the blast radius stemming from any single tenant through configuration isolation and a micro‑cellular, layered‑sharding architecture (Part 3). Resiliency, however, is not a project with an end date. It is an ongoing commitment. While this series concludes the blog series of our response to the October 2025 incidents, our investments in Azure Front Door’s resiliency, isolation, and recovery will continue. As we make further improvements, we will keep sharing them with you. We deeply value our customers’ trust in Azure Front Door. We remain committed to exceeding expectations for security, reliability, and transparency.
Azure Retirement Livestream - Please register! Session 2 - Tracking ID: XTKT-BW8
Join our upcoming live webcast for a transparent discussion about this upcoming Azure retirement — led by our engineering teams. General Purpose v1 (GPv1) Storage Accounts Tracking ID: XTKT-BW8 | Retirement Date: 13 October 2026 Same content presented in both sessions — pick the one that works best for your timezone! What to expect 📚 Understand What will happen, the timelines for the change, and how you can manage it 💬 Ask Live Q&A with our engineering experts throughout the session 🛠 Learn How to manage the change smoothly Choose your session Same content presented at both times — pick the one that works best for your timezone: Session 1 14:30 UTC Thursday, 25 June 2026 Register now → Session 2 04:30 UTC Friday, 26 June 2026 Register now → 8:30 AM US Pacific (PDT) 11:30 AM US Eastern (EDT) 4:30 PM London (BST) 12:30 AM +1 Beijing (CST) 3:30 AM +1 Sydney (AEDT) 5:30 AM +1 Auckland (NZDT) 8:30 PM -1 US Pacific (PDT) 11:30 PM US Eastern (EDT) 4:30 AM London (BST) 12:30 PM Beijing (CST) 3:30 PM Sydney (AEDT) 5:30 PM Auckland (NZDT) Our engineering leaders George Trossell Senior Product Manager Azure Networking LinkedIn ↗ ⚠️ Prepare before the livestream Read the Post Incident Review (PIR) ahead of time so you can ask any follow up questions during the live Q&A Helpful resources 🔔 Azure Service Health Alerts Get alerts for relevant incidents by setting up notifications via email, SMS, or webhook 🎥 Past Retrospective Recordings Watch recordings of previous retrospective livestreams 📄 Azure Post Incident Reviews Learn more about PIRs and the retrospective programAzure Retirement Livestream - Please register! Session 1- Tracking ID: XTKT-BW8
Join our upcoming live webcast for a transparent discussion about this upcoming Azure retirement — led by our engineering teams. General Purpose v1 (GPv1) Storage Accounts Tracking ID: XTKT-BW8 | Retirement Date: 13 October 2026 Same content presented in both sessions — pick the one that works best for your timezone! What to expect 📚 Understand What will happen, the timelines for the change, and how you can manage it 💬 Ask Live Q&A with our engineering experts throughout the session 🛠 Learn How to manage the change smoothly Choose your session Same content presented at both times — pick the one that works best for your timezone: Session 1 14:30 UTC Thursday, 25 June 2026 Register now → Session 2 04:30 UTC Friday, 26 June 2026 Register now → 8:30 AM US Pacific (PDT) 11:30 AM US Eastern (EDT) 4:30 PM London (BST) 12:30 AM +1 Beijing (CST) 3:30 AM +1 Sydney (AEDT) 5:30 AM +1 Auckland (NZDT) 8:30 PM -1 US Pacific (PDT) 11:30 PM US Eastern (EDT) 4:30 AM London (BST) 12:30 PM Beijing (CST) 3:30 PM Sydney (AEDT) 5:30 PM Auckland (NZDT) Our engineering leaders George Trossell Senior Product Manager Azure Networking LinkedIn ↗ ⚠️ Prepare before the livestream Read the Post Incident Review (PIR) ahead of time so you can ask any follow up questions during the live Q&A Helpful resources 🔔 Azure Service Health Alerts Get alerts for relevant incidents by setting up notifications via email, SMS, or webhook 🎥 Past Retrospective Recordings Watch recordings of previous retrospective livestreams 📄 Azure Post Incident Reviews Learn more about PIRs and the retrospective program
