The announcement, published by DE-CIX on September 1 and reported by IT Brief Australia the following day, is a service-provider expansion rather than the launch of ExpressRoute Metro itself. Microsoft made the Metro architecture generally available in 2024 and has continued adding cities and carrier partners. The material change here is that DE-CIX now supports the high-resiliency configuration across all five named metros, including Madrid and Singapore alongside its earlier support in Frankfurt, Amsterdam, and New York.
Microsoft’s current ExpressRoute Metro documentation independently lists DE-CIX as an active provider in each of those five metropolitan locations. It also identifies the paired facilities behind the service: Equinix AM5 and Digital Realty AMS8 in Amsterdam; Digital Realty FRA11 and Equinix FR7 in Frankfurt; Equinix MD2 and Digital Realty MAD1 in Madrid; Equinix NY5 and 165 Halsey Street in New York; and Global Switch Tai Seng and Equinix SG1 in Singapore.
For IT teams, the useful distinction is simple: this can remove one major single point of failure at the Azure network edge, but it does not turn one metro circuit into a complete disaster-recovery plan.
The service fixes a specific ExpressRoute weakness
A conventional ExpressRoute circuit already uses redundant links at one ExpressRoute peering location. That protects against individual link, router, or maintenance failures inside that site, but it cannot preserve connectivity when the entire edge location becomes isolated or unavailable.
ExpressRoute Metro moves the two connections for one circuit to two distinct Microsoft peering sites in the same city. Microsoft calls that high resiliency: traffic can fail over across the paired locations when one site fails. DE-CIX is providing the customer-facing connectivity through its DirectCLOUD platform and its neutral exchange footprint, while the two Microsoft Enterprise Edge locations provide the entrance to Azure.
The benefit is most concrete for firms that have built hybrid applications around private Azure connectivity. A bank with trading or fraud-analysis systems in a New York-area colocation facility, a manufacturer running latency-sensitive workloads against Germany West Central, or a Singapore business using private access to Southeast Asia Azure resources can keep its ExpressRoute path alive through a failure that would have taken down a standard circuit attached to only one Microsoft edge site.
Microsoft’s current provisioning guidance makes the strategic direction unusually clear: in locations where a corresponding Metro configuration is available, creation of new standard-resiliency circuits has been disabled for some providers. Microsoft recommends Metro, also described in its documentation as high resiliency, as the minimum configuration for workloads that matter.
That is a meaningful policy shift. ExpressRoute is often purchased precisely to avoid the variability of public-internet paths. A private circuit that is resilient only until one building, one carrier handoff, or one edge location becomes unavailable has never delivered the level of continuity many production teams assumed the word “private” implied.
“Georedundant” needs a narrower reading
DE-CIX describes the five-city service as georedundant. The architecture is geographically diverse at the peering-site level: each circuit spans two physically distinct facilities within a metropolitan area. But the sites are still in the same metro, and in several cases route traffic toward one local Azure region.
That boundary is important when organizations translate network resilience into business-continuity claims. Amsterdam Metro maps to Azure’s West Europe region; Frankfurt Metro maps to Germany West Central; Madrid Metro maps to Spain Central; and Singapore Metro maps to Southeast Asia. New York Metro does not offer ExpressRoute Local to a nearby Azure region, according to Microsoft’s location table, although it remains a Metro peering location and supports ExpressRoute Direct.
A Metro circuit is therefore designed to reduce the impact of a local peering-site failure, not to preserve an application through a regional Azure outage, a broad metropolitan disaster, a shared-provider issue, or a failure in the customer’s own edge network. Microsoft’s own architecture guidance ranks Metro below “maximum resiliency,” which uses two ExpressRoute circuits at different physical locations, each with local redundancy.
For a workload whose recovery objective requires surviving loss of an entire Azure region, an enterprise still needs a second regional architecture: replicated data, a failover plan, application-level routing, and a separate connectivity path that does not depend on the same metro. DE-CIX’s announcement points to remote access through its backbone, but it does not state that customers receive provider diversity, last-mile diversity, or a second Azure-region disaster-recovery circuit as part of the Metro offer.
Those are separate design decisions—and frequently separate bills.
One circuit does not automatically produce a resilient deployment
The new availability changes what DE-CIX customers can order. It does not automatically upgrade existing standard circuits, and neither DE-CIX nor Microsoft’s announcement states how existing customer installations are migrated, whether a new service key is required, what the provider charges for port or cross-connect changes, or which bandwidth tiers DE-CIX offers in each city.
The Azure-side configuration also has to match the circuit’s capabilities. Microsoft’s ExpressRoute Resiliency Guard, currently in preview, lets administrators set a gateway to a multihomed model and assess whether it has the connectivity expected for its selected resilience level. It recognizes an ExpressRoute Metro circuit as a valid way to protect against an edge-location outage, but that does not validate every dependency beyond Azure’s gateway.
Administrators should verify several points before declaring the connection highly available:
- The ExpressRoute circuit must be provisioned as the Metro option for the intended city rather than as a standard circuit at one of the paired locations.
- Customer routers, provider handoffs, cross-connects, and last-mile transport need independent physical paths; Microsoft recommends redundant paths between the enterprise edge and provider or customer-edge equipment.
- BGP advertisements and failover behavior need testing during an approved maintenance period rather than being assumed from a dual-homed diagram.
- Azure workloads need separate regional recovery planning if the business requirement includes surviving an Azure-region outage rather than only an ExpressRoute-site loss.
- Teams should check whether their virtual network gateway SKU, routing design, and active-active configuration avoid introducing a new bottleneck after the circuit itself becomes resilient.
This is the part most likely to be missed in procurement. A carrier’s Metro offering can make the Microsoft edge redundant while leaving both customer connections in the same building, on the same conduit, under the same carrier, or behind the same untested BGP policy. In that design, the new service improves one portion of the path but does not materially change the application’s real failure domain.
Madrid and Singapore complete DE-CIX’s five-city footprint
DE-CIX had already publicly described ExpressRoute Metro support in Frankfurt, Amsterdam, and New York earlier in 2026, with Madrid expected to follow. The September announcement confirms Madrid is live and adds Singapore to the group. The company says it now has 29 Azure on-ramps across 24 cities and more than 160 cloud on-ramps overall, allowing customers to reach Azure as well as AWS, Google Cloud, Oracle Cloud, and IBM Cloud through its network.
That broader footprint explains why this is more than a narrow Azure connectivity announcement. Enterprises that already use DE-CIX for cloud interconnection may be able to make an Azure path more resilient without changing their preferred exchange operator or deploying a separate network platform in each metro. For organizations pursuing hybrid or multicloud designs, that can simplify the physical connectivity layer.
It also concentrates operational responsibility. DE-CIX’s neutral-exchange model gives customers more location choices, but a design that uses one provider’s platform for primary Azure access, backup Azure access, and connectivity to other clouds should be examined for shared dependencies. Microsoft’s own security guidance recommends different providers and physically diverse paths where appropriate, particularly when the consequence of lost connectivity is high.
The five-city rollout is therefore most valuable as an option for customers whose current risk sits at one Azure edge site. It is a practical upgrade for production ExpressRoute deployments in New York, Frankfurt, Madrid, Amsterdam, and Singapore—but only if the rest of the route, the BGP configuration, and the application recovery design are built to take advantage of it.