An enterprise is designing a scalable egress architecture in Google Cloud for workloads residing in private subnets without external IP addresses. The security architecture team has established the following operational and security requirements: Enforce granular Layer 7 security policies on outbound HTTP/HTTPS web traffic based on source identities (such as Secure Tags and Service Accounts), request methods, and destination URL lists. Provide an explicit proxy architecture where client applications configure standard proxy variables (HTTP_PROXY and HTTPS_PROXY). Eliminate the administrative overhead of deploying, patching, and maintaining custom virtual machine (VM) proxy clusters. Provide automatic scaling of proxy infrastructure to accommodate fluctuating egress traffic demands with high availability. Integrate alongside existing VPC Service Controls perimeters without disrupting private data boundaries. Which architectural solution should the organization implement?

Deploy Google Cloud Secure Web Proxy (SWP) within the region, allocate a proxy-only subnet for its managed Envoy instances, define modular egress policies using Secure Tags and URL lists, and configure client workloads to direct egress traffic to the proxy's IP endpoint.: What Google Cloud Secure Web Proxy Is Google Cloud Secure Web Proxy (SWP) is a cloud-native, fully managed Layer 7 service designed to inspect, secure, and govern outbound web (HTTP/HTTPS) traffic from Google Cloud workloads. It eliminates the operational complexity of designing, scaling, and maintaining self-managed third-party proxy virtual machines. How It Meets the Enterprise Requirements Granular Layer 7 Policy Enforcement: Secure Web Proxy allows administrators to author modular egress policies that match traffic based on source identities (such as Secure Tags, IAM Service Accounts, or IP ranges) and destination criteria (including hostnames, URL paths, wildcards, and HTTP request methods). Explicit Proxy Architecture: Workloads send web requests explicitly to the proxy's internal IP address and port via standard environment variables (HTTP_PROXY, HTTPS_PROXY) or application proxy settings, using HTTP/S CONNECT tunnels for end-to-end TLS security. No VM Management Overhead: As a fully managed service, Google Cloud handles all underlying infrastructure provisioning, security updates, and software maintenance automatically. Elastic Autoscaling & High Availability: Secure Web Proxy utilizes managed Envoy proxy pools that scale up and down dynamically in response to bandwidth demands, utilizing a reserved proxy-only subnet within the region. VPC Service Controls Integration: Secure Web Proxy complements VPC Service Controls; while VPC Service Controls establishes security perimeters around Google APIs (like Cloud Storage and BigQuery) to prevent data exfiltration, Secure Web Proxy controls and logs general outbound web traffic to external SaaS and internet endpoints. Key Advantages Zero Infrastructure Maintenance: Operates out of the box without requiring custom VM clusters or manual OS patching. Identity-Aware Filtering: Enforces fine-grained egress policies bound directly to Google Cloud resource metadata (Secure Tags) rather than brittle network-level IP addresses. Default-Deny Security Model: Ensures that all outbound connections are blocked unless explicitly permitted by an authorized egress rule. Full Observability: Logs all permitted and denied requests natively to Cloud Logging and integrates with Cloud Audit Logs. Why This Is Optimal Secure Web Proxy provides native Layer 7 inspection and identity-aware egress filtering while completely eliminating the operational complexity and failure domains associated with self-managed proxy VM fleets.

Identity-Aware Egress Without Managing Proxy VMs

Managed Layer 7 Egress With Secure Web Proxy

An enterprise is designing a scalable egress architecture in Google Cloud for workloads residing in private subnets without external IP addresses. The security architecture team has established the following operational and security requirements:

Enforce granular Layer 7 security policies on outbound HTTP/HTTPS web traffic based on source identities (such as Secure Tags and Service Accounts), request methods, and destination URL lists.
Provide an explicit proxy architecture where client applications configure standard proxy variables (HTTP_PROXY and HTTPS_PROXY).
Eliminate the administrative overhead of deploying, patching, and maintaining custom virtual machine (VM) proxy clusters.
Provide automatic scaling of proxy infrastructure to accommodate fluctuating egress traffic demands with high availability.
Integrate alongside existing VPC Service Controls perimeters without disrupting private data boundaries.

Which architectural solution should the organization implement?

Configure Cloud NAT on the VPC network with Cloud Router, define URL-based firewall rules to filter outbound web domains, and attach VPC Service Controls perimeters directly to the Cloud NAT gateway.

Deploy a Cross-Region Internal Proxy Network Load Balancer with Managed Instance Groups (MIGs) running open-source proxy software, configured with Cloud NAT for outbound internet connectivity.

Deploy a Regional External Application Load Balancer with Hybrid Network Endpoint Groups (NEGs) pointing to an on-premises web proxy cluster over Cloud Interconnect.

Deploy Google Cloud Secure Web Proxy (SWP) within the region, allocate a proxy-only subnet for its managed Envoy instances, define modular egress policies using Secure Tags and URL lists, and configure client workloads to direct egress traffic to the proxy's IP endpoint.

Explanations

Configure Cloud NAT on the VPC network with Cloud Router, define URL-based firewall rules to filter outbound web domains, and attach VPC Service Controls perimeters directly to the Cloud NAT gateway.

What This Architecture Is

This option attempts to use Cloud NAT for outbound connectivity while relying on VPC firewall rules for domain filtering and attaching VPC Service Controls directly to the NAT gateway.

Why It Doesn't Meet the Requirements

No Layer 7 URL/Method Inspection: Cloud NAT is a managed Layer 4 network address translation service. It translates private IP addresses to external IP addresses for UDP and TCP traffic but cannot inspect HTTP request headers, methods, or URL paths.
VPC Firewall Limitations: Standard VPC firewall rules filter traffic based on Layer 3 and Layer 4 attributes (IP CIDRs, protocols, and ports) and cannot filter by destination domain names or URLs.
Misconception of VPC Service Controls: VPC Service Controls cannot be attached to a Cloud NAT gateway; VPC Service Controls perimeters enforce access boundaries around supported Google Cloud APIs (such as Cloud Storage and BigQuery), not outbound internet gateways.
Not an Explicit Proxy: Cloud NAT operates as a transparent Layer 4 gateway, not an explicit proxy service responding to HTTP_PROXY configurations.

Key Characteristics & Limitations

Cloud NAT provides outbound connectivity without assigning external IPs to individual VMs.
Cloud NAT does not perform TLS termination, deep packet inspection, or URL filtering.

This Answer Would Be Correct If

The requirement called only for basic, uninspected Layer 4 outbound internet connectivity for private VMs without requiring Layer 7 URL filtering, explicit proxy configurations, or identity-based rule sets.

View source documentation

Deploy a Cross-Region Internal Proxy Network Load Balancer with Managed Instance Groups (MIGs) running open-source proxy software, configured with Cloud NAT for outbound internet connectivity.

What This Architecture Is

This architecture deploys a Cross-Region Internal Proxy Network Load Balancer that distributes incoming internal TCP connections across backend Compute Engine Managed Instance Groups (MIGs) running self-managed proxy software (such as Squid or Envoy), with Cloud NAT providing IP masquerading for outbound internet egress.

Why It Doesn't Meet the Requirements

Operational Overhead: Managing custom proxy software on Compute Engine VMs requires significant operational effort, including OS patch management, software lifecycle maintenance, image hardening, and custom health check configuration.
Layer 4 vs. Layer 7 Routing: Internal Proxy Network Load Balancers operate at Layer 4 (TCP) and cannot natively interpret Layer 7 web metadata, URL paths, or Google Cloud Secure Tags.
Suboptimal Architecture: Using a reverse proxy load balancer as a frontend for forward proxy instances adds architectural complexity and requires multi-tiered health checking and custom autoscaling policies.

Key Characteristics & Limitations

Internal Proxy Network Load Balancers terminate TCP traffic and establish new TCP connections to backend VMs.
They do not offer built-in identity-aware egress filtering or modular URL list management.
Scaling relies on Compute Engine MIG autoscaling metrics (such as CPU or custom metrics), which is slower to respond to traffic bursts than native managed proxy pools.

This Answer Would Be Correct If

This approach would be appropriate if the organization required custom, proprietary Layer 4 TCP proxy software running on Compute Engine instances that needed cross-region backend failover within a private VPC network.

View source documentation

Deploy a Regional External Application Load Balancer with Hybrid Network Endpoint Groups (NEGs) pointing to an on-premises web proxy cluster over Cloud Interconnect.

What This Architecture Is

This option deploys a Regional External Application Load Balancer with Hybrid NEGs (NON_GCP_PRIVATE_IP_PORT) to backhaul traffic to an on-premises proxy cluster over dedicated Cloud Interconnect or Cloud VPN links.

Why It Doesn't Meet the Requirements

Reverse vs. Forward Proxy Direction: External Application Load Balancers are reverse proxies designed to receive ingress traffic from the public internet and distribute it to backend applications; they cannot function as forward explicit egress proxies for internal VPC VMs.
Unnecessary Latency and Complexity: Backhauling cloud egress traffic to an on-premises data center introduces significant network latency, hairpins traffic over expensive hybrid interconnects, and creates a critical on-premises dependency for cloud workloads.
Fails Operational Requirement: Does not eliminate the operational overhead of managing physical or virtual proxy appliances, merely offloading it back to the on-premises infrastructure team.

Key Characteristics & Limitations

Hybrid NEGs allow Cloud Load Balancing to route ingress traffic to non-Google Cloud private IP endpoints reached via Cloud Interconnect or Cloud VPN.
External Application Load Balancers listen on external public IP addresses and do not provide internal forward-proxy endpoints for private VPC workloads.

This Answer Would Be Correct If

The enterprise needed to expose an on-premises web application to external internet clients using Google's global edge network and Cloud Armor security policies.

View source documentation

Deploy Google Cloud Secure Web Proxy (SWP) within the region, allocate a proxy-only subnet for its managed Envoy instances, define modular egress policies using Secure Tags and URL lists, and configure client workloads to direct egress traffic to the proxy's IP endpoint.

What Google Cloud Secure Web Proxy Is

Google Cloud Secure Web Proxy (SWP) is a cloud-native, fully managed Layer 7 service designed to inspect, secure, and govern outbound web (HTTP/HTTPS) traffic from Google Cloud workloads. It eliminates the operational complexity of designing, scaling, and maintaining self-managed third-party proxy virtual machines.

How It Meets the Enterprise Requirements

Granular Layer 7 Policy Enforcement: Secure Web Proxy allows administrators to author modular egress policies that match traffic based on source identities (such as Secure Tags, IAM Service Accounts, or IP ranges) and destination criteria (including hostnames, URL paths, wildcards, and HTTP request methods).
Explicit Proxy Architecture: Workloads send web requests explicitly to the proxy's internal IP address and port via standard environment variables (HTTP_PROXY, HTTPS_PROXY) or application proxy settings, using HTTP/S CONNECT tunnels for end-to-end TLS security.
No VM Management Overhead: As a fully managed service, Google Cloud handles all underlying infrastructure provisioning, security updates, and software maintenance automatically.
Elastic Autoscaling & High Availability: Secure Web Proxy utilizes managed Envoy proxy pools that scale up and down dynamically in response to bandwidth demands, utilizing a reserved proxy-only subnet within the region.
VPC Service Controls Integration: Secure Web Proxy complements VPC Service Controls; while VPC Service Controls establishes security perimeters around Google APIs (like Cloud Storage and BigQuery) to prevent data exfiltration, Secure Web Proxy controls and logs general outbound web traffic to external SaaS and internet endpoints.

Key Advantages

Zero Infrastructure Maintenance: Operates out of the box without requiring custom VM clusters or manual OS patching.
Identity-Aware Filtering: Enforces fine-grained egress policies bound directly to Google Cloud resource metadata (Secure Tags) rather than brittle network-level IP addresses.
Default-Deny Security Model: Ensures that all outbound connections are blocked unless explicitly permitted by an authorized egress rule.
Full Observability: Logs all permitted and denied requests natively to Cloud Logging and integrates with Cloud Audit Logs.

Why This Is Optimal

Secure Web Proxy provides native Layer 7 inspection and identity-aware egress filtering while completely eliminating the operational complexity and failure domains associated with self-managed proxy VM fleets.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Managed Layer 7 Egress With Secure Web Proxy

Enforce granular Layer 7 security policies on outbound HTTP/HTTPS web traffic based on source identities (such as Secure Tags and Service Accounts), request methods, and destination URL lists.
Provide an explicit proxy architecture where client applications configure standard proxy variables (HTTP_PROXY and HTTPS_PROXY).
Eliminate the administrative overhead of deploying, patching, and maintaining custom virtual machine (VM) proxy clusters.
Provide automatic scaling of proxy infrastructure to accommodate fluctuating egress traffic demands with high availability.
Integrate alongside existing VPC Service Controls perimeters without disrupting private data boundaries.

Which architectural solution should the organization implement?

Configure Cloud NAT on the VPC network with Cloud Router, define URL-based firewall rules to filter outbound web domains, and attach VPC Service Controls perimeters directly to the Cloud NAT gateway.

Deploy a Cross-Region Internal Proxy Network Load Balancer with Managed Instance Groups (MIGs) running open-source proxy software, configured with Cloud NAT for outbound internet connectivity.

Deploy a Regional External Application Load Balancer with Hybrid Network Endpoint Groups (NEGs) pointing to an on-premises web proxy cluster over Cloud Interconnect.

Explanations

Configure Cloud NAT on the VPC network with Cloud Router, define URL-based firewall rules to filter outbound web domains, and attach VPC Service Controls perimeters directly to the Cloud NAT gateway.

What This Architecture Is

This option attempts to use Cloud NAT for outbound connectivity while relying on VPC firewall rules for domain filtering and attaching VPC Service Controls directly to the NAT gateway.

Why It Doesn't Meet the Requirements

No Layer 7 URL/Method Inspection: Cloud NAT is a managed Layer 4 network address translation service. It translates private IP addresses to external IP addresses for UDP and TCP traffic but cannot inspect HTTP request headers, methods, or URL paths.
VPC Firewall Limitations: Standard VPC firewall rules filter traffic based on Layer 3 and Layer 4 attributes (IP CIDRs, protocols, and ports) and cannot filter by destination domain names or URLs.
Misconception of VPC Service Controls: VPC Service Controls cannot be attached to a Cloud NAT gateway; VPC Service Controls perimeters enforce access boundaries around supported Google Cloud APIs (such as Cloud Storage and BigQuery), not outbound internet gateways.
Not an Explicit Proxy: Cloud NAT operates as a transparent Layer 4 gateway, not an explicit proxy service responding to HTTP_PROXY configurations.

Key Characteristics & Limitations

Cloud NAT provides outbound connectivity without assigning external IPs to individual VMs.
Cloud NAT does not perform TLS termination, deep packet inspection, or URL filtering.

This Answer Would Be Correct If

View source documentation

Deploy a Cross-Region Internal Proxy Network Load Balancer with Managed Instance Groups (MIGs) running open-source proxy software, configured with Cloud NAT for outbound internet connectivity.

What This Architecture Is

Why It Doesn't Meet the Requirements

Operational Overhead: Managing custom proxy software on Compute Engine VMs requires significant operational effort, including OS patch management, software lifecycle maintenance, image hardening, and custom health check configuration.
Layer 4 vs. Layer 7 Routing: Internal Proxy Network Load Balancers operate at Layer 4 (TCP) and cannot natively interpret Layer 7 web metadata, URL paths, or Google Cloud Secure Tags.
Suboptimal Architecture: Using a reverse proxy load balancer as a frontend for forward proxy instances adds architectural complexity and requires multi-tiered health checking and custom autoscaling policies.

Key Characteristics & Limitations

Internal Proxy Network Load Balancers terminate TCP traffic and establish new TCP connections to backend VMs.
They do not offer built-in identity-aware egress filtering or modular URL list management.
Scaling relies on Compute Engine MIG autoscaling metrics (such as CPU or custom metrics), which is slower to respond to traffic bursts than native managed proxy pools.

This Answer Would Be Correct If

View source documentation

Deploy a Regional External Application Load Balancer with Hybrid Network Endpoint Groups (NEGs) pointing to an on-premises web proxy cluster over Cloud Interconnect.

What This Architecture Is

Why It Doesn't Meet the Requirements

Reverse vs. Forward Proxy Direction: External Application Load Balancers are reverse proxies designed to receive ingress traffic from the public internet and distribute it to backend applications; they cannot function as forward explicit egress proxies for internal VPC VMs.
Unnecessary Latency and Complexity: Backhauling cloud egress traffic to an on-premises data center introduces significant network latency, hairpins traffic over expensive hybrid interconnects, and creates a critical on-premises dependency for cloud workloads.
Fails Operational Requirement: Does not eliminate the operational overhead of managing physical or virtual proxy appliances, merely offloading it back to the on-premises infrastructure team.

Key Characteristics & Limitations

Hybrid NEGs allow Cloud Load Balancing to route ingress traffic to non-Google Cloud private IP endpoints reached via Cloud Interconnect or Cloud VPN.
External Application Load Balancers listen on external public IP addresses and do not provide internal forward-proxy endpoints for private VPC workloads.

This Answer Would Be Correct If

The enterprise needed to expose an on-premises web application to external internet clients using Google's global edge network and Cloud Armor security policies.

View source documentation

Deploy Google Cloud Secure Web Proxy (SWP) within the region, allocate a proxy-only subnet for its managed Envoy instances, define modular egress policies using Secure Tags and URL lists, and configure client workloads to direct egress traffic to the proxy's IP endpoint.

What Google Cloud Secure Web Proxy Is

How It Meets the Enterprise Requirements

Granular Layer 7 Policy Enforcement: Secure Web Proxy allows administrators to author modular egress policies that match traffic based on source identities (such as Secure Tags, IAM Service Accounts, or IP ranges) and destination criteria (including hostnames, URL paths, wildcards, and HTTP request methods).
Explicit Proxy Architecture: Workloads send web requests explicitly to the proxy's internal IP address and port via standard environment variables (HTTP_PROXY, HTTPS_PROXY) or application proxy settings, using HTTP/S CONNECT tunnels for end-to-end TLS security.
No VM Management Overhead: As a fully managed service, Google Cloud handles all underlying infrastructure provisioning, security updates, and software maintenance automatically.
Elastic Autoscaling & High Availability: Secure Web Proxy utilizes managed Envoy proxy pools that scale up and down dynamically in response to bandwidth demands, utilizing a reserved proxy-only subnet within the region.
VPC Service Controls Integration: Secure Web Proxy complements VPC Service Controls; while VPC Service Controls establishes security perimeters around Google APIs (like Cloud Storage and BigQuery) to prevent data exfiltration, Secure Web Proxy controls and logs general outbound web traffic to external SaaS and internet endpoints.

Key Advantages

Zero Infrastructure Maintenance: Operates out of the box without requiring custom VM clusters or manual OS patching.
Identity-Aware Filtering: Enforces fine-grained egress policies bound directly to Google Cloud resource metadata (Secure Tags) rather than brittle network-level IP addresses.
Default-Deny Security Model: Ensures that all outbound connections are blocked unless explicitly permitted by an authorized egress rule.
Full Observability: Logs all permitted and denied requests natively to Cloud Logging and integrates with Cloud Audit Logs.

Why This Is Optimal

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Managed Layer 7 Egress With Secure Web Proxy

Explanations

Configure Cloud NAT on the VPC network with Cloud Router, define URL-based firewall rules to filter outbound web domains, and attach VPC Service Controls perimeters directly to the Cloud NAT gateway.

What This Architecture Is

Why It Doesn't Meet the Requirements

Key Characteristics & Limitations

This Answer Would Be Correct If

Deploy a Cross-Region Internal Proxy Network Load Balancer with Managed Instance Groups (MIGs) running open-source proxy software, configured with Cloud NAT for outbound internet connectivity.

What This Architecture Is

Why It Doesn't Meet the Requirements

Key Characteristics & Limitations

This Answer Would Be Correct If

Deploy a Regional External Application Load Balancer with Hybrid Network Endpoint Groups (NEGs) pointing to an on-premises web proxy cluster over Cloud Interconnect.

What This Architecture Is

Why It Doesn't Meet the Requirements

Key Characteristics & Limitations

This Answer Would Be Correct If

Deploy Google Cloud Secure Web Proxy (SWP) within the region, allocate a proxy-only subnet for its managed Envoy instances, define modular egress policies using Secure Tags and URL lists, and configure client workloads to direct egress traffic to the proxy's IP endpoint.

What Google Cloud Secure Web Proxy Is

How It Meets the Enterprise Requirements

Key Advantages

Why This Is Optimal

Try 10 interactive questions like this one, free

Related questions

Cloud NGFW URL Filtering

Cloud Logging Sinks to Chronicle UDM

Shared Responsibility Model by Service Tier

Super Admin OU Security Key 2SV Enforcement

Secret Manager Automated Rotation via Pub/Sub

BigQuery Partition Expiration

Managed Layer 7 Egress With Secure Web Proxy

Explanations

Configure Cloud NAT on the VPC network with Cloud Router, define URL-based firewall rules to filter outbound web domains, and attach VPC Service Controls perimeters directly to the Cloud NAT gateway.

What This Architecture Is

Why It Doesn't Meet the Requirements

Key Characteristics & Limitations

This Answer Would Be Correct If

Deploy a Cross-Region Internal Proxy Network Load Balancer with Managed Instance Groups (MIGs) running open-source proxy software, configured with Cloud NAT for outbound internet connectivity.

What This Architecture Is

Why It Doesn't Meet the Requirements

Key Characteristics & Limitations

This Answer Would Be Correct If

Deploy a Regional External Application Load Balancer with Hybrid Network Endpoint Groups (NEGs) pointing to an on-premises web proxy cluster over Cloud Interconnect.

What This Architecture Is

Why It Doesn't Meet the Requirements

Key Characteristics & Limitations

This Answer Would Be Correct If

Deploy Google Cloud Secure Web Proxy (SWP) within the region, allocate a proxy-only subnet for its managed Envoy instances, define modular egress policies using Secure Tags and URL lists, and configure client workloads to direct egress traffic to the proxy's IP endpoint.

What Google Cloud Secure Web Proxy Is

How It Meets the Enterprise Requirements

Key Advantages

Why This Is Optimal

Try 10 interactive questions like this one, free

Related questions

Cloud NGFW URL Filtering

Cloud Logging Sinks to Chronicle UDM

Shared Responsibility Model by Service Tier

Super Admin OU Security Key 2SV Enforcement

Secret Manager Automated Rotation via Pub/Sub

BigQuery Partition Expiration