Why Enterprise Azure Networking Needs to Evolve

Hub-and-spoke remains a common foundation for enterprise Azure networking. The hub provides shared transit, hybrid connectivity, DNS, and security services, while spokes host application and platform workloads.

A conventional design allocates each spoke a non-overlapping enterprise CIDR and propagates the prefix through the enterprise routing domain. This model becomes harder to sustain as the environment expands across:

• Multiple Azure regions and landing zones
• Production, non-production, and disaster-recovery environments
• Existing data centers and branch networks
• Acquired or partner networks
• Other public clouds
• Data, analytics, and AI platforms
• Private endpoints and dedicated platform subnets

At that scale, the constraint is not merely available IPv4 capacity. It is the availability of non-overlapping prefixes that can be safely advertised across all connected routing domains.

Many workload networks also do not require direct routed connectivity from the wider enterprise. Application backends, compute clusters, integration services, and data-processing platforms might require access to specific dependencies or endpoints, rather than full prefix reachability.

The design question is therefore:

Does the enterprise require a route to the complete workload prefix, or only to selected services exposed by that workload?

This separates two architecture decisions:

1. Where is the workload hosted?
2. Which workload endpoints require enterprise-wide reachability?

A spoke can consume governed connectivity through a hub without requiring its complete prefix to be propagated into the wider enterprise network.

Figure 1: An enterprise Azure environment can provide enterprise-routable endpoints while keeping the underlying workload networks outside the wider enterprise routing domain. Connecting a workload to a hub enables governed connectivity, but it does not require the workload’s complete address space to be advertised enterprise-wide.

Routable and Non-Advertised Address Spaces

A private IP address is not automatically enterprise-routable. Reachability depends on the effective route selected by the source, route propagation across connected domains, a valid return path, and the applicable security controls.

Azure creates system routes for each VNet subnet. Custom routes can override selected system routes, and Azure selects an outbound path from the subnet’s effective route table.[1]

For this architecture, address spaces fall into two categories:

A non-advertised workload network is not disconnected. Azure system routes, VNet peering, user-defined routes, or a transit component can still provide connectivity within its approved scope.

Throughout this article, non-advertised workload network means:

A network that is locally routable within its approved Azure topology, but whose prefix is intentionally not propagated across the wider enterprise routing domain.

Routing and authorization remain separate controls. The existence of a route does not imply that NSGs, Azure Firewall, an NVA, identity controls, or the destination application will permit the connection.

Address-Space Strategy at Scale

Most enterprise private networks use the RFC 1918 ranges:[2]

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Enterprise-routable allocations must remain unique across every connected routing domain in which the prefixes are propagated. This includes Azure, on-premises networks, connected partners, acquired networks, and other clouds.

Non-advertised workload ranges still require IPAM governance, but their uniqueness boundary can be limited to the Azure topology in which they are used.

The routing scope should therefore be defined when the CIDR is allocated:

Microsoft recommends planning non-overlapping address spaces across Azure regions and on-premises locations and maintaining an IP address-management strategy for large environments.[3]

Figure 2: Address-space selection begins with the required routing scope, not simply with CIDR availability.

Considering 100.64.0.0/10

Microsoft’s current Azure IP-planning guidance describes 100.64.0.0/10 as RFC 6598 shared address space treated as private address space in Azure and identifies RFC 1918 exhaustion as a scenario in which it may be evaluated.[3]

However, 100.64.0.0/10 is not a universal replacement for RFC 1918. Before using it, validate:

• Existing enterprise, partner, or service-provider allocations
• Azure service and connected-network compatibility
• Security, observability, and IPAM tooling
• Future hybrid or cross-cloud connectivity
• Translation, return-path, and organizational-policy requirements

Azure includes a default system route for 100.64.0.0/10 with the None next-hop type. When an address prefix from this range is assigned to a VNet, Azure creates a route for the configured VNet prefix with the Virtual network next-hop type.[1] The effective route table must therefore be validated as part of the design.

The pattern described in this article does not depend on 100.64.0.0/10. The relevant property is whether the selected prefix is intentionally excluded from the wider enterprise routing domain.

Key principle: Select a CIDR based on the routing domains in which the prefix must remain unique, not merely because the range appears unused.

The Two-Layer Architecture

The addressing model translates into two logical layers.

Enterprise-Routable Layer

This layer contains prefixes and endpoints that require reachability from approved enterprise networks.

Typical components include:

• Hybrid connectivity infrastructure
• DNS and security services
• Application ingress
• Management endpoints
• Selected private endpoints
• Load balancers or proxies

Where ExpressRoute is used, Azure private peering exchanges routes through a redundant pair of BGP sessions between the customer network and Microsoft.[5][6]

Non-Advertised Workload Layer

This layer hosts workload components whose complete prefixes do not require enterprise-wide propagation.

Typical components include:

• Application backends
• Data-processing platforms
• Compute clusters
• Integration services
• Internal platform services

These networks remain routable within their approved Azure topology. Their prefixes are not automatically propagated to on-premises networks, other clouds, or unrelated landing zones.

The Routable Front Door

When an enterprise consumer requires access to a selected workload service, the architecture can expose an endpoint in the enterprise-routable layer. That endpoint acts as a routable front door.

The routable front door is an architectural role, not a specific Azure service. Depending on the protocol and connectivity requirement, enterprise access might be provided through:

• An application ingress service
• A load balancer or reverse proxy
• A private endpoint
• Azure Firewall or an NVA
• Another service-specific access component

The address presented to the enterprise is separated from the address space used to host and scale the workload.

Expose the required service without propagating the complete workload prefix.

The same model can be applied to traditional hub-and-spoke, multi-region landing zones, or Azure Virtual WAN. Azure Virtual WAN provides managed transit between connected VNets, branches, and remote users, but the decision to propagate a workload prefix should remain explicit.[7]

Figure 3: The routable front door exposes selected services while the underlying workload prefix remains outside the wider enterprise routing domain.

Architecture Review Checks

Before allocating a workload address range, validate:

1. Does the complete workload prefix require enterprise-wide propagation?
2. Which exact services, FQDNs, ports, and protocols require access?
3. Is the CIDR unique across every routing domain it must directly reach?
4. Can a routable front door satisfy the requirement?
5. Which routes will be advertised in each direction?

6. Is the return path valid, and does it traverse the same stateful inspection or translation boundary where required?

7. Which team owns IPAM, route policy, DNS, security policy, and monitoring?
8. What happens if future connectivity expands the routing scope?

Conclusion

Enterprise Azure network design should treat workload hosting and enterprise reachability as separate decisions.

Enterprise-routable space should be reserved for prefixes and endpoints that require broader reachability. Workload networks can remain locally routable within Azure without propagating their complete prefixes across the organization.

The core principle is:

A workload can consume governed hub connectivity without requiring its complete address space to become enterprise-routable.

Up Next: Part 2

Part 2: Implementing Routable Front Doors for Non-Advertised Azure Workloads

Part 2 will implement the architecture using BGP and ExpressRoute, effective routes and UDRs, Azure Firewall and NVA patterns, SNAT, DNAT and double NAT, Private Link, hybrid DNS, return-path validation, failure handling, observability, and pattern selection.

References

1. Azure virtual network traffic routing [learn.microsoft.com]
2. https://datatracker.ietf.org/doc/html/rfc1918
3. IP address planning for Azure virtual networks [learn.microsoft.com]
4. RFC 6598: Shared Address Space Request
5. Azure ExpressRoute routing requirements [learn.microsoft.com]
6. Azure ExpressRoute circuits and peering [learn.microsoft.com]
7. Cross-region and multicloud connectivity in Azure [learn.microsoft.com]

Shipping is no longer just about deploying code.

Consider a team introducing a new checkout experience. The code is already in production, but the team wants to expose it to a small audience, gradually increase availability, monitor the results, and retain the ability to turn it off if something goes wrong.

Feature flags make that possible without requiring another deployment.

As feature flags become increasingly central to how software is released and operated, we saw an opportunity to evolve how they’re represented in Azure App Configuration.

Enhanced Feature Flags are available in public preview, with a dedicated resource model designed specifically for feature management.

Why rethink the feature flag resource model?

Consider a team preparing to launch a new check out experience. The release manager needs to control when the feature becomes available but shouldn’t necessarily have permission to modify payment settings or other application configuration.  

With traditional feature flags sharing the same key-value resource and permission model as application configuration, separating these responsibilities isn’t possible. Similarly existing SDKS and tooling simplify feature flag management; the underlying APIs still treat flags as specially formatted configuration entries rather than resources with their own defined structure.

These are not challenges with feature evaluation itself. They're challenges with how feature flags are represented, managed, and governed.

Enhanced Feature Flags address this by introducing a purpose-built resource model, with dedicated APIs and separate access control.

What changes with Enhanced Feature Flags?

The new model introduces several important improvements.

1. Feature management gets its own security boundary

Feature flags often change application behavior in production, and the people responsible for those changes may not be the same people responsible for application configuration.

With Enhanced Feature Flags, organizations can grant access to feature flag resources independently of configuration key-values. A team responsible for feature rollout, for example, can manage flags without also receiving permission to modify unrelated application settings.

This creates a clearer security boundary for applying least privilege access to feature management.

2. Feature flags get a dedicated API surface

Previously, managing feature flags through configuration APIs required clients and automation to understand specific naming conventions, content types, and serialized feature definitions.

Enhanced Feature Flags expose dedicated APIs for creating, querying, updating, and deleting flags.

The benefit isn't simply another API. Tools and deployment workflows can now work directly with a resource designed for feature management instead of interpreting a feature flag stored as configuration.

3. Validation moves closer to the source

Enhanced Feature Flags have a defined resource schema that Azure App Configuration can validate when a flag is created or updated. Malformed definitions can be rejected before they are stored, providing consistent validation across clients and tooling.

Existing feature management capabilities continue to work

Enhanced Feature Flags build on the feature management capabilities already available in Azure App Configuration, including targeting, variants, allocation, and telemetry.

Applications can continue using their existing feature evaluation logic with supported versions of the App Configuration provider libraries.

And importantly, existing key-value-based feature flags remain supported. Teams can evaluate the new model alongside their current flags, rather than treating this preview as a mandatory migration.

See Enhanced Feature Flags in action

Watch this short demo to learn how granular role-based access control enables teams to manage feature releases independently while keeping application configuration protected.

A foundation for what comes next

Enhanced Feature Flags solve concrete management and governance challenges today, but the opportunity goes further.

Giving feature flags their own resource model creates room for feature management to evolve independently from general application configuration, with deeper investments in areas such as automation, governance, targeting, and connecting feature delivery to application outcomes.

The longer-term opportunity is to make managing a feature throughout its lifecycle as natural as developing and deploying it.

Enhanced Feature Flags are available now in public preview in Azure App Configuration. If you're building a new application or evolving your feature management workflows, explore the new resource model and let us know what you think.

We want Enhanced Feature Flags to provide the foundation for the next generation of feature management in Azure App Configuration, and your feedback will help shape where we take it next.

• Learn about Enhanced Feature Flags
• Explore the Enhanced Feature Flags REST API
• Share feedback with the Azure App Configuration team

#Azure #AzureAppConfiguration #FeatureFlags #FeatureManagement #DeveloperExperience