Understanding Proxy-only Subnets in Google Cloud Platform (GCP)
While working on building a new infrastructure project, I came across network feature called Proxy-only Subnet. Let’s break down the purpose of proxy-only subnets in GCP and how they work with Envoy-based load balancers.
What Are Proxy-Only Subnets in GCP?
A proxy-only subnet in GCP is a special kind of subnet designed to host only Google Cloud’s Envoy-based load balancing proxies, like the Google Cloud HTTP(S) Load Balancer. The main purpose of this subnet is to provide a centralized location where the Envoy proxies live and handle traffic for your backend services.
How Proxy-Only Subnets Work
In GCP, the HTTP(S) Load Balancer uses Envoy as its proxy. When you set up such a load balancer, GCP will use a proxy-only subnet as the network location for these Envoy proxies.
Here’s a step-by-step explanation:
1.Traffic enters the VPC: When a request is sent to load balancer, it first reaches the proxy-only subnet where the Envoy-based load balancer resides.
2. The Envoy proxies handle traffic: The traffic is processed by the Envoy proxies in this subnet, applying load-balancing logic, routing rules, and security policies.
3. Traffic is then forwarded: After processing, the traffic is forwarded from the proxy-only subnet to the target backend services or VMs in your other subnets.
This setup helps GCP separate the traffic management (handled by the Envoy proxies) from your backend services, improving scalability, security, and manageability.
Supported load balancers
- Proxy-only subnet with purpose
GLOBAL_MANAGED_PROXY:
2. Proxy-only subnet with purpose REGIONAL_MANAGED_PROXY:
- Regional external Application Load Balancer
- Regional internal Application Load Balancer
- Regional external proxy Network Load Balancer
- Regional internal proxy Network Load Balancer
Key Purposes and Benefits of Proxy-Only Subnets
- Separation of Proxy Layer from Backends: By having a proxy-only subnet, Envoy proxies are kept separate from your actual backend services. This separation helps isolate the traffic management layer from the application logic layer.
- Advanced Traffic Management: You can implement advanced routing features such as traffic splitting, canary deployments, or routing based on header information, all managed centrally through the Envoy proxies.
- Enhanced Security: Proxy-only subnets limit exposure since only the Envoy proxies reside there. Backend VMs or services aren’t directly exposed to the internet or other untrusted networks.
- Controlled Access: You can use firewall rules to control access to and from the proxy-only subnet, ensuring that only allowed traffic reaches your backend services.
Real-World Example in GCP
Imagine you have an internal web application with multiple microservices running in different subnets across a GCP Virtual Private Cloud (VPC). You want to balance traffic between these services using the Internal HTTP(S) Load Balancer.
- You create a proxy-only subnet in your VPC to host the Envoy proxies.
- Incoming requests hit the Envoy-based load balancer, which resides in the proxy-only subnet.
- The load balancer applies the necessary routing logic and distributes traffic to your backend services.
This separation ensures that traffic management happens in the proxy-only subnet, while your backend services remain isolated, scalable, and secure in their respective subnets.
Summary
Proxy-only subnets in GCP serve the following primary purposes:
- Isolate and manage Envoy-based proxies separately from backend services.
- Centralize traffic routing and management through a dedicated subnet for Envoy proxies.
- Improve security and scalability by separating traffic handling logic from application logic.
