Also See Routes in Azure (A poor man's DMZ) and Firewalls (NSGs) in Azure and Azure Security Baseline

Also see - Using Azure Building Blocks to create a Hub Spoke Network in Azure

Hub-and-Spoke Cloud Architecture: Four Principles for Secure Connectivity

A hub-and-spoke architecture separates shared network services from application workloads. The hub provides common connectivity and security services, while the spokes host applications, databases, and other business systems.

The value of this design comes from controlling how traffic moves: where internet access is permitted, how workloads communicate, how public applications are protected, and how on-premises systems reach cloud resources.

For an enterprise design that centralizes internet access and uses Cloudflare to protect public applications, four principles provide a useful foundation:

1. Centralize internet connectivity through the hub.
2. Enforce workload isolation within every spoke.
3. Route public application traffic through Cloudflare before it reaches the cloud ingress layer.
4. Use private hybrid connectivity, with a VPN backup where appropriate, for communication with on-premises systems.

These are architectural policies that must be implemented through routing and security controls. A hub-and-spoke topology alone does not enforce them.

1. Centralize Internet Access Through the Hub

In this design, the hub is the approved internet connectivity boundary. Spoke workloads reach external services through centrally managed egress infrastructure.

For example, an application server might need to download software updates, call an external API, or connect to an approved SaaS platform. Its outbound traffic should follow this path:

Spoke workload → hub egress firewall or proxy → address translation, where required → internet

The hub can apply consistent destination controls, inspect supported traffic, and generate logs for security monitoring. Azure supports this pattern using a hub firewall and user-defined routes; AWS supports centralized egress using Transit Gateway and a dedicated egress VPC.

What This Means for the Spokes

To enforce centralized egress, design the spokes so that workloads cannot create an alternative internet path.

Practical controls include:

• Keeping application and database workloads on private addresses.
• Restricting the creation of public IP addresses and independent internet gateways.
• Routing internet-bound traffic to approved central egress infrastructure.
• Limiting who can modify routes, firewall policies, and public exposure.
• Checking both IPv4 and IPv6 paths for unintended bypasses.
• Documenting approved exceptions.

A private IP address alone does not prove that a workload has no internet access. The effective route and egress configuration determine whether it can reach the internet.

Centralized Egress Requires Explicit Routing

A common mistake is assuming that connecting a spoke to a hub automatically makes the hub its internet gateway.

Connectivity and routing are separate decisions. Each spoke needs an appropriate route to the central egress path, and the hub needs a valid return route to the spoke.

In an AWS centralized IPv4 egress design, spoke traffic reaches an egress VPC through Transit Gateway, then follows routes to a NAT gateway and internet gateway. Return routes must point spoke-bound traffic back to Transit Gateway. NAT provides address translation; firewall inspection requires additional controls, such as AWS Network Firewall.

GCP Requires a Deliberate Implementation

Google Cloud supports hub-and-spoke designs with centralized network appliances. One documented pattern uses appliance VMs behind an internal passthrough Network Load Balancer, with routes directing spoke traffic through those appliances.

The implementation must explicitly provide forwarding, inspection, and any required address translation. Simply creating a hub VPC and connecting spokes does not establish centralized internet egress.

Also distinguish a hub VPC containing appliances from a Network Connectivity Center hub. An NCC hub is a logical connectivity management resource; it is not itself a firewall or NAT appliance.

Allow Private Access to Cloud Services Where Appropriate

The central egress policy should distinguish general internet access from approved private access to cloud services.

A workload accessing storage, secrets, or a managed database through an approved private endpoint may have a different path from a workload calling an external public API.

Define those paths deliberately, including their DNS, access-control, and logging requirements.

2. Isolate Workloads Within Every Spoke

A central firewall controls traffic that crosses it. Workloads within the same spoke may communicate without traversing that firewall.

Each spoke therefore needs its own segmentation controls.

For example, a three-tier application might contain:

• A web tier that receives application requests.
• An application tier that executes business logic.
• A database tier that stores sensitive information.

These tiers should communicate only through approved dependencies.

Example: A Three-Tier Application

The following is an illustrative policy, with ports adjusted to match the application:

Source	Destination	Permitted traffic
Approved ingress proxy	Web tier	HTTPS on TCP 443
Web tier	Application tier	Application service on TCP 8443
Application tier	Database tier	Required database port, such as TCP 5432
Approved management service	Managed workloads	Required administrative protocols
Other sources	Protected tiers	Block unless explicitly authorized

The database should accept connections from the application components that need it. A broad rule allowing an entire spoke address range weakens that isolation.

Equivalent Controls Across Clouds

The products serve similar purposes, but their attachment points and rule semantics differ.

Cloud	Workload segmentation control	Typical application
Azure	Network Security Groups	Subnets, network interfaces, or both
GCP	VPC firewall rules and firewall policies	Applicable workload interfaces, selected through supported targeting mechanisms
AWS	Security Groups	Supported resources and their network interfaces

Azure recommends spoke-level NSGs alongside central hub security. Google Cloud similarly documents firewall rules within spoke VPCs and hierarchical policies for central control.

AWS Security Groups are stateful and support allow rules rather than explicit deny rules. Consequently, an isolation policy must account for all applicable allow rules; it cannot rely on adding a deny rule to a Security Group.

A Subnet Is Not a Complete Security Boundary

Placing web, application, and database servers in separate subnets helps organize the network. It does not, by itself, enforce restricted communication.

Isolation requires rules that define:

• Which sources may connect.
• Which destinations they may reach.
• Which protocols and ports are permitted.
• Which outbound dependencies are allowed.

For sensitive workloads, combine network segmentation with application authentication, workload identity, and least-privilege data access.

Control Communication Between Spokes

The same principle applies across applications and environments.

A development spoke should not automatically reach production databases. Two production applications should communicate only when there is a documented business dependency.

If policy requires central inspection between spokes, routing must send that traffic through the inspection layer. Direct spoke connections can create paths that bypass it. Azure VNet peering is non-transitive, so transit connectivity must be deliberately configured.

3. Use Cloudflare as the First Entry Point for Public Applications

For public websites and supported application APIs in this design, Cloudflare is the first traffic-handling layer.

A typical request follows this path:

Internet client → Cloudflare → hub ingress endpoint → application in a spoke

Cloudflare can apply configured edge protections, including web application firewall rules, DDoS protection, caching, and other application delivery controls before forwarding requests to the origin. Those benefits require traffic to be proxied through Cloudflare; hosting DNS there alone does not place Cloudflare in the request path.

This principle applies to the applications and protocols covered by the selected Cloudflare services. It should not be interpreted as an automatic protection layer for every internet protocol.

Define the Cloud Ingress Layer

The hub ingress layer might contain a reverse proxy, application gateway, or load balancer, with a network firewall included where the chosen architecture requires it.

The responsibilities should be clear:

Layer	Primary responsibility
Cloudflare	Public edge protection and application delivery
Hub ingress services	Approved origin connectivity and routing to applications
Spoke security controls	Restrict access to permitted application components
Application	Authentication, authorization, and business logic

The exact ordering of firewall and load-balancing components depends on the platform and implementation. The objective is an approved, protected route to the application.

Prevent Direct Access to the Origin

An application can remain exposed if an attacker discovers its origin address and connects directly.

Protecting the origin is therefore part of the Cloudflare design. Depending on the deployment, controls can include:

• Restricting origin access to approved Cloudflare connections.
• Using Authenticated Origin Pulls.
• Removing unnecessary public exposure.
• Using Cloudflare Tunnel to reach an origin through outbound-established connections.

Cloudflare documents these approaches as ways to protect origins and reduce bypass opportunities.

Cloudflare Tunnel changes the connection mechanics: Cloudflare reaches the application through a tunnel rather than through a publicly reachable origin listener. The tunnel connector can be placed in the approved ingress environment.

Protect Each Connection Segment

A public application path contains several connection segments: client to Cloudflare, Cloudflare to origin, and ingress service to application.

Define encryption and certificate validation for each segment. Also configure proxies and applications to trust client-address headers only from approved upstream systems.

The public edge should complement application security. It does not remove the need for authentication or authorization.

4. Use Private Hybrid Connectivity for Internal Traffic

Traffic between on-premises systems and private cloud workloads generally does not need to pass through the public Cloudflare application edge.

For Azure, a typical path is:

On-premises network → ExpressRoute private peering → hub connectivity and inspection services → spoke workload

ExpressRoute provides a private connection between the enterprise network and Microsoft cloud services. The hub can share that hybrid connectivity across spokes.

Equivalent services provide the same broad architectural role in other clouds:

Cloud	Dedicated hybrid connectivity	Common VPN backup
Azure	ExpressRoute	Azure VPN Gateway
GCP	Cloud Interconnect	HA VPN
AWS	Direct Connect	AWS Site-to-Site VPN

Cloudflare may separately be used for private access through its Zero Trust or network services, but it is not required in the private hybrid path described here.

Private Connectivity Still Needs Security Controls

A private connection does not make every connected system trustworthy.

For example, if an on-premises application needs access to one cloud database, the policy should allow that dependency specifically. It should not grant the entire corporate network unrestricted access to the database spoke.

Use routing, network controls, authentication, and authorization together.

Private connectivity also does not necessarily mean encrypted connectivity. ExpressRoute traffic is not encrypted by default. Sensitive traffic can require TLS, IPsec, or other supported encryption; ExpressRoute Direct also supports MACsec for its physical links.

Make the Backup VPN Operationally Useful

A backup VPN should be designed and tested as a working recovery path.

Validate:

• Which routes are advertised over each connection.
• How the dedicated connection is preferred.
• How traffic shifts when the primary path fails.
• Whether the VPN has enough capacity for critical workloads.
• Whether inspection and access policies remain effective.
• How traffic returns to the primary connection after recovery.

A failover exercise should verify application behavior, DNS resolution, and return traffic as well as tunnel status.

Designing the Hub for Reliability

Centralizing connectivity increases the hub’s operational importance. Its firewall, DNS, gateways, and egress services become shared dependencies.

Design for availability and capacity from the outset. Consider resilient appliances or managed services, redundant hybrid connectivity, sufficient connection capacity, and regional recovery requirements.

For a geographically distributed organization, several regional hubs may be appropriate. Centralized policy can be maintained across those hubs without forcing every workload through one distant network.

Validate the Traffic Paths

Before declaring the architecture complete, test the intended paths and the restrictions.

Test	Expected result
Spoke workload accesses an approved public API	Uses the approved central egress path
Workload attempts unauthorized direct internet access	Blocked
Public client accesses a published application	Passes through Cloudflare and approved ingress
Client attempts direct origin access	Blocked or requires the approved origin authentication
Web tier attempts a direct database connection	Blocked unless explicitly required
Development workload accesses production	Blocked unless explicitly authorized
On-premises system accesses a private cloud service	Uses the approved hybrid path
Primary hybrid connection fails	Critical traffic uses the tested backup path

A successful hub-and-spoke design makes each allowed connection intentional and observable. The hub governs shared connectivity, the spokes enforce workload isolation, Cloudflare protects published applications, and private hybrid connections support internal business traffic.