ExpressRoute Growth and Business-Unit Isolation
Contoso runs a single ExpressRoute circuit: 1 Gbps, Standard SKU, Microsoft peering not used, private peering established in Amsterdam, currently linked to 6 VNets in West Europe. The roadmap adds 30 business-unit VNets (12 in West Europe, 18 in East US). Regulatory separation requires that each BU VNet cannot route to any other BU VNet; virtual network peering between BU VNets is prohibited, but peering each BU VNet to a shared services hub is allowed. Measured on-premises-to-Azure peak on the circuit is 2.8 Gbps and growing about 20% per quarter. The CIO requires a 99.95% SLA on the hybrid path and wants all regions served from the same private peering.
1. Identify every way the current circuit and configuration fails the requirements.
Read the worked answer
| Requirement | Current state | Gap |
|---|---|---|
| 2.8 Gbps peak, +20%/quarter | 1 Gbps circuit | Bandwidth is already exceeded; plan for ~5 Gbps within two quarters, so size at 10 Gbps |
| 36 VNets linked | Standard SKU | Standard allows 10 VNet links per circuit; Premium is required beyond that |
| East US VNets on the same private peering | Amsterdam only, West Europe | Crossing geopolitical regions on one circuit requires Premium SKU |
| 99.95% SLA | One circuit | A single circuit provides a 99.9% SLA; 99.95% needs two circuits in different peering locations |
| BU isolation | Not yet designed | Must be enforced by topology, not by hoping |
Also check the ExpressRoute gateway SKU: ErGw1AZ cannot carry multi-gigabit throughput, and non-AZ SKUs give no zone redundancy. ErGw2AZ or ErGw3AZ (zone-redundant, up to 10 Gbps) is the realistic target.
2. Propose the target architecture and explain how it satisfies BU isolation without exceeding the circuit's link limits.
Read the worked answer
Two Premium circuits (Amsterdam + London, 10 Gbps each, private peering) terminated on a zone-redundant ErGw3AZ gateway in the shared hub; BU VNets peer to the hub and use gateway transit instead of their own circuit connections.
Why this satisfies isolation:
- VNet peering is non-transitive. A BU spoke peered to the hub learns only the hub's address space plus gateway-propagated on-premises routes - not the other spokes' prefixes. So BU-A cannot reach BU-B by default, which is exactly the property the regulation asks for, and the 'no BU-to-BU peering' rule is respected.
- On-premises reaches each BU VNet through the hub gateway; the hub's circuit connections drop from 36 to 2, so the 10-link limit and Premium cost are both far from binding.
What would silently break isolation (say this explicitly):
- Any UDR in the hub or spokes sending 0.0.0.0/0 to a hub NVA/firewall. Once spokes hairpin through a shared appliance that routes between VNets, BU-A can reach BU-B. If you need central egress, keep it but enforce the separation with firewall policy, not routing.
- Adding a spoke-to-spoke peering 'temporarily' for a migration.
- Route Server or BGP injection that advertises one BU prefix to another.
3. How do you validate the design and influence path preference during circuit maintenance?
Read the worked answer
Validation:
- On a NIC in BU-A, confirm effective routes contain on-premises prefixes via Virtual network gateway and no 10.x prefix belonging to BU-B. Repeat in BU-B.
- Check Get-AzExpressRouteCircuitConnectionConfig / the circuit's connection list to confirm only the hub is linked.
- Use Connection Monitor or Network Watcher next-hop to prove on-premises reachability and prove BU-A -> BU-B drops.
Path preference and maintenance:
- With two circuits in different peering locations attached to the same gateway, Azure prefers the circuit with the shorter AS path; use AS-path prepending or local preference on-premises to make one primary and the other standby.
- Before planned maintenance, verify BGP on the secondary circuit is established and receiving prefixes; draining traffic with prepending is safer than taking the primary down and hoping.
- Keep FastPath out of scope for inspected traffic: FastPath sends data-plane traffic directly to VMs, so any requirement for firewall inspection of hybrid traffic conflicts with it. Confirm which spokes need inspection before enabling it.