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 caters to a vast number of tenants from numerous edge locations, utilising a globally distributed network. This extensive network allows us to offer impressive scale, performance, and cost-effectiveness. However, it also poses a risk: if strong isolation isn’t in place, one tenant’s problematic configuration or unusual traffic can potentially disrupt other tenants. The incidents from October 2025 underscored the necessity of managing this risk effectively. Our clear goal for tenant isolation is that no single tenant’s configuration or traffic should impact any other tenant.

In the first part of our three-part mini blog series, we discussed our four-pillar strategy aimed at bolstering the resilience of Azure Front Door: configuration resiliency, data plane resiliency, tenant isolation, and an accelerated Recovery Time Objective (RTO). Part 1 explained how we intend to enhance the safety of configuration propagation and how the data plane operates using a ‘last-known-good’ (LKG) setup, even if an incompatible configuration is received. In the second part, we centred on recovery, demonstrating how we aim to restore full system functionality swiftly, predictably, and within a set timeframe. Now, in this final segment, we focus on the tenant isolation element, ensuring any issues stemming from a single tenant’s configuration or traffic are confined solely to that tenant, without impact on others. We’ll also explore how Azure Front Door achieves this isolation using configuration separation, lazy loading, and a micro-cellular layered ingress-sharding design.

Repair Status: All Tasks Now Completed

Before diving into tenant isolation, let’s give you an update on the overall repairs from the two incidents in October 2025 (details can be found in our Azure Incident Retrospective sessions for the events of October 9th and October 29th). We’re pleased to announce that all outstanding repairs across every pillar have been completed and deployed into production. This includes the tenant isolation work discussed in this article. With these protective measures now in place, we’ve successfully returned configuration propagation latency to levels seen before the incidents, while maintaining our focus on platform stability. In the table below, “Completed” signifies our deployments across production.

Why Isolation at Edge Scale is Surprisingly Difficult

Traditional methods for maintaining isolation, such as assigning dedicated hardware for each tenant or running each tenant in its own virtual machine, aren’t practical at the edge. Edge locations face limitations in space, power, and capacity. The essence of modern, multi-tenant application delivery is that any tenant can be served from the site closest to them. We can’t simply set aside dedicated machines for hundreds of thousands of tenants without sacrificing proximity, scale, or the efficiency that make edge computing both fast and cost-effective. Thus, software-based isolation within a multi-tenant framework is essential.

What We Already Do

Azure Front Door already incorporates various layers of tenant isolation and division. However, the October incidents clearly showed that these safeguards weren’t sufficient. Prior to the incidents, our protective measures included:

• Infrastructure Partitioning. Edge locations were structured into physically separated primary and fallback traffic rings.
• Noisy-Neighbor Protection. Resource allocation based on fair sharing, rate limiting, and anomaly detection prevented any single tenant from monopolising shared resources like CPU, memory, or network bandwidth on an Azure Front Door server.
• Circuit Breakers. Circuit breakers helped manage workloads more efficiently and could disable risky tenant features before draining shared resources.
• Real-Time Crash Protection. A crash analysis system tracks crash signatures across machines, enabling the identification and blocking of patterns linked to specific tenant IPs or traffic patterns.

While these protective layers are beneficial, many are reactive, and they proved inadequate during the October incidents. The new approach to isolation aims to embed single-tenant containment as a fundamental aspect of how configurations are processed and traffic is managed.

Configuration Isolation: Loading Only What’s Necessary

Part 2 introduced ‘lazy loading’ as an optimisation for recovery, and it also serves as a vital mechanism for configuration isolation. Traditionally, every worker on every edge server needed to be prepared to handle any tenant, which required each to load a wide array of configurations. Consequently, an incompatible configuration could disrupt multiple workers.

With lazy loading, a worker retrieves a tenant’s configuration and TLS certificates only when it starts receiving traffic for that specific tenant. This significantly enhances isolation: if an improper configuration occurs, it only impacts the workers that have loaded that particular tenant, rather than the entire server or fleet. Coupled with per-tenant validation and the ‘Food Taster’ safeguard (a process that tests each configuration change beforehand in isolation), issues can be detected early and contained to the smallest possible scope.

Figure 1: Thanks to lazy loading, an incompatible configuration is only contained to the workers serving that tenant, preventing wider impact on the server.

Tenant Isolation: A Micro-Cellular, Layered Ingress Sharding Design

While configuration isolation limits the potential fallout from a faulty configuration, traffic isolation addresses another concern: a tenant’s unusual traffic patterns, such as sudden spikes, problematic requests, or malicious actions, could disrupt shared workers. Our solution is a micro-cellular architecture that unites various concepts.

• Worker-Process Isolation. Each edge server operates multiple independent worker processes. Instead of allowing every worker to serve every tenant, we group tenants with specific worker groups (shards). This segregation acts as a unit of isolation: if a tenant destabilises its shard, the consequences are limited to those workers, while the rest of the server continues functioning normally.
• Ingress Sharding. Rather than using a handful of set shards, we build shards from overlapping worker subsets. Even a limited number of workers can form a vast array of distinct overlapping shards, resulting in a large number of fine-grained fault domains without needing dedicated hardware for each tenant.

Figure 2: Each server layer features randomly assigned tenants to different shards, minimising the chances of interference between good and noisy tenants.

• Multi-Layer Ingress Sharding. This is where the ‘layered’ strategy comes into play. Each edge server functions as an independent layer, and tenants are assigned to different, randomly chosen shards across every server. Because the assignments occur independently from server to server, two tenants sharing a shard on one server are highly unlikely to do the same on a different server. This substantially reduces the odds of a good tenant being impacted by a noisy tenant across multiple servers.
• Intelligent Ingress Routing. This layer ties everything together by managing each incoming connection, identifying the tenant, and directing the request to its corresponding, healthy shard. If a shard is facing issues or is overloaded, traffic is rerouted to the healthy shards of that tenant on other layers.

Figure 3: Intelligent Ingress Routing directing traffic to optimal paths.

These combined layers mean that when a noisy tenant overwhelms or crashes its shard on one server, only that shard experiences the disruption. As all other tenants are spread across various, randomized shards, they consistently have access to healthy options, and the routing layer adjusts their traffic accordingly. A potential availability issue is lessened to a small, manageable capacity challenge, which the routing layer addresses effectively.

For an in-depth technical review of layered ingress sharding, click here for reference.

Minimising the Impact

Collectively, these mechanisms fundamentally reshape potential failures. In a fully shared fleet, an incompatible tenant could, at worst, affect numerous tenants on one machine, a single edge location, or beyond. With configuration isolation and layered ingress sharding, the same hiccup is contained within a select group of workers that cater to the problematic tenant. Our aim with tenant isolation is to achieve effective single-tenant containment: the impact of a configuration or traffic issue caused by one tenant should never ripple out to affect others.

Figure 4: Shifting from a shared fleet where one tenant can disrupt many, to micro-cellular shards that limit disruptions to the offending tenant.

Validating Isolation in Action

Much like our recovery efforts, we don’t just design these boundaries and take them at face value; we rigorously test them. Through careful fault injections, we’ve intentionally introduced noisy and faulty tenants into the system, confirming that disruptions remained confined to the problematic shards, that healthy tenants continued to operate effectively, and that the routing layer successfully diverted traffic away from any unhealthy shards as planned. This turns isolation from a theoretical promise into a proven, reproducible outcome.

Conclusion

This article wraps up our three-part mini blog series focusing on the resilience of Azure Front Door. We’ve covered how we enhance configuration propagation safety (Part 1), expedite recovery when challenges arise (Part 2), and contain unforeseen consequences from a single tenant through configuration isolation and a micro-cellular layered sharding design (Part 3).

However, building resilience is not merely a project with a definitive end; it’s an ongoing commitment. While this series summarises our response to the October 2025 incidents, our dedication to enhancing Azure Front Door’s durability, isolation, and recovery capabilities will persist. As we implement further improvements, we will ensure to keep you informed.

We greatly appreciate our customers’ trust in Azure Front Door, and we remain dedicated to exceeding expectations in security, reliability, and transparency.