Introduction

Large Azure hub-and-spoke environments can advertise a significant number of routes toward on-premises networks. By default, Azure VPN Gateway and ExpressRoute Gateway advertise the address spaces of the hub virtual network and the address spaces of peered spoke virtual networks that use gateway transit. As the number of spokes and address spaces grows, the border gateway protocol (BGP) route table grows as well.

Advertised gateway prefixes provide a native way to summarize those Azure-side routes. The feature is configured on the hub virtual network through the summarizedGatewayPrefixes property, which is exposed in the Azure portal as Advertised gateway prefixes.

In this blog we will demonstrate leveraging Advertised gateway prefixes to summarize many Azure advertised prefixes into one.  

What are advertised gateway prefixes?

Advertised gateway prefixes are summarized CIDR blocks that an Azure hybrid gateway advertises toward on-premises instead of advertising every covered hub and spoke address space individually. The configuration belongs on the gateway virtual network, usually the hub VNet that contains GatewaySubnet and the ExpressRoute or VPN gateway.

How the route advertisement changes

When should you use it?

• You use a hub-and-spoke topology with gateway transit and many spoke address spaces.
• You want to advertise a covering prefix, such as a /16, instead of many smaller prefixes, such as multiple /24 networks.
• You are approaching ExpressRoute advertised-prefix limits or want to reduce route-table growth before scale becomes a problem.
• Your Azure address plan is sufficiently structured to create safe, intentional summary ranges.

Note: ExpressRoute scale context: Microsoft documentation lists a maximum of 1,000 IPv4 prefixes and 100 IPv6 prefixes advertised from a virtual network to on-premises on a single ExpressRoute connection through private peering. Exceeding the connection prefix limit can cause the connection between the circuit and gateway to disconnect until the prefix count is reduced.

Prerequisites

• A hub virtual network with GatewaySubnet.
• An ExpressRoute gateway or VPN gateway deployed in the hub virtual network.
• One or more peered spoke virtual networks if you want to demonstrate route summarization across spokes.
• A planned IPv4 and, when applicable, IPv6 summary that covers the intended hub and spoke address spaces.
• Access to the provider or on-premises BGP route view for validation. In this walkthrough, Megaport is used as the external verification point.

Configure advertised gateway prefixes in the Azure portal

The portal configuration is performed on the hub VNet, not on the ExpressRoute circuit and not on each spoke VNet.

1. In the Azure portal, search for Virtual networks and select the hub VNet that contains GatewaySubnet.

• • Open the hub virtual network

2. Under Settings, select Address space.

• • Open Address space

3. In Advertised gateway prefixes, select + Add prefix. Enter the covering CIDR, such as 10.0.0.0/22 for four contiguous /24 networks.

• • Add the summarized prefix

4. For a dual-stack design, add IPv4 and IPv6 summarized prefixes explicitly.

• • Add additional address families if needed

5. Select Save and confirm the summarized prefixes remain listed in the Advertised gateway prefixes section.

• • Save the configuration

Validate the summarized route on routers or provider

After Azure applies the change and BGP converges, I’m using ExpressRoute and Megaport here for my example, you can either log in to your router directly or view the incoming BGP routes via your provider’s interface to confirm what routes are being received from Azure. We want to capture a view that displays the BGP prefixes learned from the Azure side.

1. Capture a baseline screenshot before enabling the feature, showing the individual hub and spoke prefixes.
2. After configuration, refresh the route view and locate the new summarized prefix.
3. Confirm that covered hub and spoke prefixes are no longer advertised individually.
4. Confirm that any address space outside the configured summary remains advertised separately.

Before:

After:

In my demo environment I have a hub and 20 spokes all within the 10.27.0.0/16 address prefix.  We can see a successful implementation as before enabling the feature, I had a total of 21 prefixes being received at Megaport, after enabling the feature I have 1. 

Important design considerations

Configure the hub, not the spokes: Only the virtual network containing the gateway subnet uses the summarizedGatewayPrefixes property for this behavior. A value placed on a spoke VNet is ignored.

Avoid overlap within the prefix list: Do not configure overlapping entries in the advertised gateway prefixes list.

Expect uncovered networks to remain visible: If a hub or spoke address space is not covered by a configured summary, the gateway continues to advertise it individually.

Plan dual-stack explicitly: IPv4 and IPv6 summaries must be added separately.

Removing all entries restores default behavior: When every advertised gateway prefix is removed, Azure returns to advertising hub and peered spoke address spaces individually.

Protect the on-premises edge: Use appropriate route policies so only expected prefixes are accepted. Summarization simplifies advertisements, but it does not replace routing governance.

Conclusion

Advertised gateway prefixes give Azure networking teams a straightforward, native method to control route scale from a gateway-enabled hub VNet. Instead of sending every hub and spoke prefix across ExpressRoute or VPN connections, the gateway can advertise a concise list of summarized prefixes. The result is a smaller and more intentional route advertisement, while uncovered address spaces remain visible for compatibility.

References

• Advertised gateway prefixes in Azure virtual networks
• Configure advertised gateway prefixes using the Azure portal
• Azure ExpressRoute FAQ
• About ExpressRoute virtual network gateways