Proxy-only Subnet
A proxy only subnet is a dedicated IP range reserved for cloud load balancers. You set one up by assigning a private CIDR block to regional load balancers. Teams use this network slice to route traffic to internal apps and databases. Standard virtual machines cannot run inside this reserved space. Instead, the cloud provider runs Envoy-based load balancers in those IP addresses. If teams grant broad firewall rules to this range, any user can reach backend databases. Network teams often open ever
Database Proxy (ProxySQL, PgBouncer) + Read-Only Root Filesystem: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A proxy only subnet is a dedicated IP range reserved for cloud load balancers. You set one up by assigning a private CIDR block to regional load balancers. Teams use this network slice to route traffic to internal apps and databases. Standard virtual machines cannot run inside this reserved space. Instead, the cloud provider runs Envoy-based load balancers in those IP addresses. If teams grant broad firewall rules to this range, any user can reach backend databases. Network teams often open every port from this range to speed up work. That choice exposes sensitive data to anyone who can reach the load balancer.
How a proxy only subnet routes internal traffic
When you set up an internal load balancer, it needs its own IP addresses. The cloud provider pulls these addresses from your proxy only subnet. A client sends a request to the main forwarding rule IP address. The load balancer ends that first connection at its own local IP address. Next, it opens a brand new connection to your backend virtual machine. Your backend server sees traffic coming from the reserved subnet range. It does not see the original client IP address in the network packet. You must add a firewall rule that lets the reserved range reach your backends. Each region in your virtual network needs one active subnet for this purpose. You also need enough free IP addresses to handle peak traffic spikes. If the subnet runs out of addresses, the cloud cannot scale your load balancers.
What network rules solve and what they miss
A reserved subnet solves IP address exhaustion and keeps load balancer traffic organized. It gives network teams one source IP range to allow in firewall rules. You do not need to update firewall rules when client IP addresses change. Still, network subnets and firewall rules only check where packets come from. They cannot check who the user is or what command they run. Once the firewall allows the subnet range, the network path stays wide open. A developer or app with network routing can log in with shared database keys. The subnet cannot stop someone from running a drop table command in production. It also cannot rewrite sensitive fields like emails or card numbers in query results. Network segments control packet routing, not what individual statements or requests do in flight.
Sizing and managing your reserved IP range
Planning your IP address space early saves your team from painful network migrations later. Cloud providers need a broad block of addresses to spin up new load balancer nodes. During high traffic events, the platform adds more nodes in the background. If your IP block is too small, new load balancers will fail to start. You cannot delete or shrink this reserved range while load balancers still run. Instead, you must add a backup range and migrate traffic over to it. Keep your firewall rules tight by opening only the exact ports your app needs. Never allow all ports from the reserved range to reach every database server. Pair your network layout with strong controls that check every query and command.
Database Proxy (ProxySQL, PgBouncer) + Read-Only Root Filesystem: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can I put normal virtual machines in a proxy only subnet?
No, you cannot place your own virtual machines or containers in this subnet. The cloud provider locks this IP range for its own managed load balancers.
How many proxy only subnets do I need per region?
You only need one active reserved subnet per region in a virtual network. All regional load balancers in that same network share that single IP pool.
Why do my backend logs show the subnet IP instead of the client IP?
The load balancer stops the client connection and starts a new one to your server. You must read HTTP headers to find the original client IP address.