Centralized Cloud Egress: A Practical Design for Inspection and Control

John Burns

Networking

As cloud environments grow, outbound internet traffic often grows with them. Each virtual network gets its own public-facing path, its own translation service, and a slightly different set of firewall rules. That works for a small estate. It becomes difficult to audit when several accounts, subscriptions, regions, and application teams are involved.

A centralized egress design moves outbound traffic through a small number of controlled inspection points. Workload networks remain private, security policy has a clear enforcement location, and the organization can record which networks are allowed to reach the internet. The design does not remove the need for workload-level controls. It gives those controls a network path they can actually rely on.

This guide describes the architecture, routing decisions, provider mappings, and verification checks. It does not depend on a particular application platform or operating system.

The architecture

The basic layout has four parts:

  • Spoke networks: virtual networks containing application, data, and management resources.
  • Transit layer: a managed hub that connects spokes and, where required, on-premises networks.
  • Inspection layer: a cloud firewall or network appliance that evaluates traffic before it leaves the private estate.
  • Egress layer: the service that performs address translation and provides the final route to the public internet.

A request from a private workload follows this path:

workload subnet → spoke route table → transit hub → inspection point → egress service → internet

The return path must be equally deliberate. Stateful firewalls expect both directions of a flow to pass through the same inspection context. If the outbound packet crosses one firewall instance and the response comes back through another path, the session may be dropped even though every individual route looks reasonable.

The transit hub is not automatically a security boundary. It is a routing component. You still need separate route domains or route tables for workload traffic, inspection traffic, and the egress network. A hub that simply propagates every route everywhere can make segmentation harder rather than easier.

Keep the egress VPC or VNet simple

The egress network should contain only the services needed to provide and inspect outbound access. It is a poor place for application workloads because a busy application can compete with security infrastructure for address space, routes, and operational attention.

Use separate subnets or equivalent network segments for:

  • Transit attachments
  • Firewall or inspection endpoints
  • Address translation or outbound gateway services
  • Public-facing load balancers, if the design requires them
  • Management and monitoring interfaces

Place redundant inspection and egress capacity in the failure domains recommended by the provider. A single firewall endpoint in one availability zone is not a centralized design; it is a centralized outage.

The inspection layer should have a defined policy for at least four categories of traffic:

  1. Destinations that are never allowed.
  2. Destinations that require explicit approval.
  3. General web and software-update access.
  4. Approved private services that should never use the public internet.

Do not use a broad “allow internet” rule as the permanent policy. Start with the destinations the workloads actually require, then make exceptions visible. Domain-based controls can be useful, but remember that DNS names, encrypted connections, redirects, and content delivery networks make hostname policy more complicated than a simple list of addresses.

Routing is the design

The most common mistake in centralized egress projects is treating the route tables as implementation detail. They are the architecture.

A spoke route table normally sends its default route, 0.0.0.0/0, to the transit hub rather than to a local internet gateway or NAT service. The transit hub then uses a workload route table to send that default route toward the inspection attachment. The inspection subnet sends approved traffic toward the egress service. The egress service sends it to the public internet.

Private destinations need a different path. Routes for other spokes, corporate networks, and private service endpoints should not be forced through public translation unless there is a specific inspection requirement. In many designs, the transit hub has separate route domains for:

  • Spoke-to-spoke traffic
  • Private hybrid connectivity
  • Internet-bound traffic
  • Inspection return traffic

This separation makes it possible to answer a useful question during an incident: “Which policy and route table allowed this flow?” If every network shares one flat routing domain, that answer is harder to establish.

Watch for asymmetric routing. It appears when the outbound route uses the inspection layer but the return route uses a direct spoke attachment, or when different regions select different inspection points for the same flow. Stateful inspection requires a symmetric design, or an explicitly supported flow-distribution mode that preserves state.

AWS implementation pattern

AWS documents centralized egress patterns using a transit gateway, a dedicated egress VPC, a NAT Gateway, and either AWS Network Firewall or a third-party appliance. The important idea is the route sequence, not the product count.

Spoke VPCs attach to the transit gateway and use a transit gateway route table that sends internet-bound traffic toward the egress VPC. Inside the egress VPC, the attachment subnet, firewall endpoint, and NAT Gateway each need routes that move the packet through the intended inspection sequence. AWS’s centralized egress guidance shows the firewall endpoint as the default-route target in the relevant transit gateway attachment subnet route table.

For traffic inspection between VPCs or between on-premises networks and VPCs, AWS documents appliance mode on the transit gateway to help preserve flow symmetry. That setting is not a substitute for route design. It supports the design after the attachments and route tables have been arranged correctly.

AWS Cloud WAN is another option when the estate needs a managed global network rather than a regional transit gateway pattern. It can provide a common policy model across regions, but it does not eliminate the need to decide where inspection and internet egress occur. A single global egress point may simplify control while adding latency and cross-region transfer cost. Regional egress points usually reduce those costs but require consistent policy and failover planning in each region.

Azure implementation pattern

Azure Virtual WAN provides a managed hub-and-spoke networking model. Standard Virtual WAN hubs provide transit between connected virtual networks, branches, and remote users. Routing intent adds a declarative way to steer private or internet-bound traffic toward a security solution in the hub.

For centralized internet inspection, configure the internet traffic routing policy so that connected networks send internet-bound traffic to Azure Firewall, an integrated network virtual appliance, or another supported security solution. For private traffic inspection, use the private traffic policy where the security requirement includes spoke-to-spoke or branch-to-spoke flows.

The distinction matters. Sending internet traffic through a firewall does not automatically mean that private traffic is inspected. Conversely, forcing all private traffic through a security appliance can create unnecessary cost and latency if the organization only requires segmentation at the workload boundary.

Use the Virtual WAN effective routes and hub route information to confirm what the hub advertises to each connection. A routing policy is only useful when the connected virtual network receives the expected default or private route and the security solution has a valid return path.

Google Cloud implementation pattern

Google Cloud Network Connectivity Center uses a hub-and-spoke model for connecting VPC networks and hybrid resources. Its topology options determine how routes are exchanged between spokes and how a routing VPC or hybrid connection participates in the design.

For a centralized security architecture, treat the NCC hub as the connectivity control point and the firewall or security service as a separate policy layer. Confirm which spoke routes are advertised, which destinations are reachable through hybrid spokes, and where internet egress is provided. Do not assume that attaching a VPC spoke to an NCC hub automatically gives you the desired inspection behavior.

Google’s documentation also calls out high-availability requirements for spoke resources. Apply the same rule used in the other providers: the hub can be highly available while the attached firewall, interconnect, or appliance remains a single failure point. Test the complete path, not only the hub status page.

Verification checklist

Verify the design from a workload perspective, a routing perspective, and a security-policy perspective.

From a workload network, confirm that:

  • Public internet destinations use the intended egress address.
  • Private destinations remain private and do not leave through public translation.
  • A denied destination is blocked at the expected inspection point.
  • Approved destinations work from every intended region.
  • DNS resolution follows the documented resolver path.

From the transit and inspection layers, confirm that:

  • The spoke has the expected default route.
  • The transit hub selects the inspection route table.
  • The inspection endpoint has a return path to the originating spoke.
  • Logs identify the spoke, destination, action, and reason for denial.
  • Both directions of a stateful flow use the same inspection context.

Run failure tests before calling the design resilient. Disable or isolate one inspection endpoint, one egress capacity unit, and one transit attachment at a time, using the provider’s supported maintenance or test procedure. Confirm that existing flows behave as documented, new flows recover within the expected interval, and monitoring reports the degraded state.

Test a route change as well. Temporarily remove an approved path in a non-production environment and verify that the traffic fails closed rather than silently bypassing inspection. A centralized egress design that recovers by taking an uninspected path has not recovered safely.

Costs and trade-offs

Centralization can reduce duplicated gateway and firewall capacity, but it does not make traffic free. Inter-zone transfer, inter-region transfer, inspection processing, NAT processing, and logging can all contribute to the bill. A design that sends every region’s internet traffic through one distant security VPC may be easy to explain and expensive to operate.

There is also an operational trade-off. Centralized policy is easier to audit, but a change to the shared firewall can affect many application teams. Use staged policy changes, explicit ownership, and a documented emergency path. Keep the route tables, inspection rules, and egress destinations under change control even when the provider exposes them through a portal rather than a configuration file.

The right design is usually regional where latency and cost matter, with a common policy model and a deliberate path for private cross-region traffic. The exact split depends on data residency, inspection requirements, application latency, and the provider services already in use.

Conclusion

Centralized egress works when the route path is explicit: private workload, transit hub, inspection point, and egress service. The provider’s managed networking product can simplify the hub, but it cannot decide which traffic should be private, which traffic needs inspection, or how stateful return traffic will get back to the workload.

Build the route domains first, keep the egress network dedicated, deploy inspection and gateway capacity across failure domains, and verify from the spoke outward. That produces a cloud network that is easier to audit without turning every application network into its own disconnected security project.

Sources

Previous post

Migrate Ingress-NGINX Routes to Gateway API With a Controlled Cutover