Tailwind Manufacturing: a hub-spoke network that has outgrown its hub

Diagnose first; the architecture decision is downstream of the measurement.

• Gateway SKU. Standard and HighPerformance ExpressRoute gateways cap around 1 Gbps and 2 Gbps respectively, which alone explains a 1.2 Gbps ceiling. ErGw1AZ/2AZ/3AZ scale to roughly 4/6/10 Gbps, and FastPath bypasses the gateway for the data path entirely.
• Firewall. A single Azure Firewall instance has a documented throughput ceiling; scale out or move to a secured virtual hub, which scales horizontally. But first confirm the traffic profile: hairpinning every spoke-to-spoke flow through one firewall causes both the throughput ceiling and the latency complaints, and no firewall SKU fixes a routing design that sends east-west traffic through a central chokepoint unnecessarily.
• Direction. With 44 spokes across four regions, hand-managed UDRs and per-region hub meshing become the operational bottleneck for a small team. Virtual WAN gives any-to-any transit, hub-to-hub connectivity, and an integrated secured hub, at a higher per-GB cost and with less granular routing control than a hand-built hub. That is the trade: less control, far less operational surface.
• If you stay hub-spoke, you need a hub per region, VNet peering between hubs, and UDR maintenance in every spoke - the load that breaks at this scale.
• Public IPs: the CISO rule is an Azure Policy Deny at the landing-zone management group, including the AKS node resource group, not a process instruction.

Private cluster, overlay networking, and a deliberate egress path.

• API server: private cluster - no public API endpoint; operators reach it through a bastion or an ExpressRoute-connected jump host.
• Pod IPs: Azure CNI assigns VNet IPs per pod, and at 30 new spokes that exhausts address space. Use Azure CNI Overlay so pods come from a private CIDR outside the VNet, or size node and pod subnets explicitly with the 30-spoke growth in mind.
• Egress: a UDR sending 0.0.0.0/0 to the hub firewall (or a NAT Gateway for non-inspected traffic), with FQDN rules on the firewall for registry and package endpoints. Do not leave the default outbound access in place.
• On-prem SQL: resolve the SQL hostname through a conditional forwarder to on-premises DNS, and route the on-prem prefix over ExpressRoute via the hub firewall - with FastPath enabled so the data path skips the gateway. Never expose the SQL Server publicly to work around routing.
• Guardrail: an Azure Policy denying public IPs in the AKS node resource group, because the managed cluster creates resources outside the developer's view.

Private Link service, with an honest caveat about partner reachability.

• Design: put the API behind a Standard internal load balancer in a dedicated spoke, front it with an Azure Private Link service, and have the partner create a private endpoint in their own VNet. Traffic never leaves the Microsoft backbone, the service has no public IP, and the partner approves the connection on their side.
• DNS: publish the API FQDN in a private DNS zone linked to the partner's VNet (or they manage their own zone). Without DNS the private endpoint exists but nothing resolves to it - the most common failure in this pattern.
• Block the alternative: disable public network access on the API host (internal-mode API Management or a private-endpoint App Service), so the private path is the only path.
• If the partner has no Azure VNet or ExpressRoute/VPN, a private endpoint in their Azure tenancy does not reach their datacenter. Then the choices are: partner establishes ExpressRoute/VPN into Azure, or you accept a controlled internet exposure - Application Gateway or Front Door with WAF, mutual TLS client certificates, IP allow-listing, and rate limiting. State that trade-off explicitly rather than pretending Private Link solves a connectivity problem it does not.