Centralizing Internet Egress on Google Cloud with NCC and SWP

When designing cloud network architectures, a common enterprise requirement is to centralize internet egress through a single gateway. The goal is straightforward: enforce unified security controls, increase traffic visibility, and consolidate egress IP addresses. In a hub-and-spoke topology with multiple VPCs, this typically means routing outbound internet traffic through a single VPC where it can be inspected, filtered, and translated (NATed) before reaching the web.

While you can build this centralized egress using third-party network virtual appliances (NVAs), this blog explores a cloud-native solution using only Google Cloud services — specifically, Secure Web Proxy (SWP) and Network Connectivity Center (NCC).

For ingress traffic, I highly recommend a distributed model. Each workload or VPC should host its own external-facing load balancers, protected by WAF rules for robust DDoS mitigation.

Secure Web Proxy (SWP)

Google Cloud’s Secure Web Proxy (SWP) is a fully managed service designed to secure outbound web traffic from your internal networks to the internet. SWP inspects outbound requests and enforces granular security policies to dynamically allow or deny connections based on compliance needs.

Key Features:

• High availability and auto-scaling: built-in high availability across the region and automatically scales to meet throughput demands.
• **TLS inspection:** Deep visibility into encrypted HTTPS traffic to enforce security policies.
• Identity-aware access control: Granular filtering of outbound internet access based on the source user or service account identity.
• Native integrations: Seamless interoperability with Cloud NAT and Certificate Authority Service (CAS).

For a complete and up-to-date list of capabilities, refer to the official Secure Web Proxy documentation.

SWP routing modes

• **Explicit:** Workloads and clients must be explicitly configured to point directly to the proxy server.
• **Next-hop:** Traffic is routed to SWP as a next hop in the network, requiring no client-side configuration.

This post focuses on routing traffic to SWP as a next hop via an NCC hub. You can explore alternative options, like static or policy-based routing that are more appropriate for single or small environments here.

Please be mindful about some limitations with the next-hop SWP apprach outlined here.

Solution Overview

The diagram above shows a standard hub-and-spoke NCC deployment. Whether you configure NCC in a full mesh or star topology, it must route traffic from your Spoke VPCs to the Internet Egress VPC hosting your SWP instance. Practically, this means that in a star topology, your Internet Egress VPC must be part of the “Center” group.

Prep work:

1. Set up Internet Egress VPC subnets

• Private subnet: the SWP instance will use an address from this subnet. This address will be used in the routing rule as a next hop.
• Proxy subnet: SWP uses this range to allocate a dedicated pool of unique IP addresses to proxy traffic.

Note: Cloud NAT is created automatically during SWP deployment

*2. Create certificates (Optional) If you require deep inspection for HTTPS traffic, generate and deploy certificates following guidelines provided here.*

Even without a TLS inspection policy, SWP still checks the hostname against the SNI header in the outbound request, which remains visible even when the rest of the traffic is encrypted.”

*3. *Configure firewall rules Create the necessary rules to allow communication between your workload VMs and the SWP instance.

SWP configuration:

In this section we will get into steps needed to deploy SWP. Commands below are the ones I used for my lab environment. You can review hyperlinks in each step for complete documentation.

1. Create SWP policy

My policy.yaml config file:

description: basic Secure Web Proxy policy
name: projects/<my_project_id>/locations/us-east1/gatewaySecurityPolicies/swp-1

Create the SWP policy (SWP-1)

gcloud network-security gateway-security-policies import swp-1 \
    --source=policy.yaml \
    --location=us-east1

2. Create SWP rules

My rule.yaml config file

name: projects/<my_project_id>/locations/us-east1/gatewaySecurityPolicies/swp-1/rules/allow-dot-com
description: Allow .com sites
enabled: true
priority: 10
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')

Create the SWP rule (allow-dot-com)

gcloud network-security gateway-security-policies rules import allow-dot-com \
    --source=rule.yaml \
    --location=us-east1 \
    --gateway-security-policy=swp-1

Learn more about next-hop rule configuration here.

3. Deploy SWP instance as a next hop

My gateway.yaml file

name: projects/<my_project_id>/locations/us-east1/gateways/swp-gw
type: SECURE_WEB_GATEWAY
addresses: [10.10.10.10]
ports: [80,443]
gatewaySecurityPolicy: projects/<my_project_id>/locations/us-east1/gatewaySecurityPolicies/swp-1
network: projects/<my_project_id>/global/networks/internet-egress-vpc
subnetwork: projects/<my_project_id>/regions/us-east1/subnetworks/east1-subnet
routingMode: EXPLICIT_ROUTING_MODE

Create the SWP instance (swp-instance)

gcloud network-services gateways import swp-instance \
    --source=gateway.yaml \
    --location=us-east1

Route traffic to SWP

Last step is to route traffic from the Spokes/workload VPCs to the egress VPC hosting the SWP instance. This will be achieved using NCC static routes. The NCC static route will point to the IP address of the SWG instance as a next-hop.

gcloud compute routes create internet-egress \
--network=vpc-network-1 \
--destination-range= 0.0.0.0/0 \
 --priority=100 \
 --next-hop-ilb= 10.10.10.10

This command deploy a route to “vpc-network-1”. Each spoke VPC will need a similar route. Make sure to change the network name accordingly.

Testing

Now that we have everything in place, lets run couple of tests for allowed (google.com) and blocked (wikiperdia.org )URLs from a VM in a spoke VPC.

Google.com- allowed

Wikipedia.org — blocked

SWP transaction logs are written to Cloud Logging. You can filter SWP transaction logs by using this query:

logName="projects/<my_project_id>/logs/networksecurity.googleapis.com%2Fswg_policy_event"

Captured logs for my requests:

Sample transaction log for allowed request to .com URL

Sample transaction log for denied request to .org URL

More details about viewing proxy transactions logs can be found here.

Conclusion

Implementing Secure Web Proxy with a next-hop routing model through an NCC hub significantly simplifies your network architecture. By eliminating the need for client-side configurations and centralizing your internet egress, you gain a highly scalable and secure way to manage outbound traffic across your hub-and-spoke topology.