Load Balancing and Cloud Armor

Derived from Application Load Balancer overview and Set up a global external Application Load Balancer with Cloud Run.

Three questions pick the product. First, what protocol: HTTP and HTTPS traffic belongs on an Application Load Balancer, which understands URLs, headers and cookies (layer 7); anything else belongs on a Network Load Balancer (layer 4), which is either a proxy that terminates TCP or SSL connections or a passthrough that forwards packets unchanged, preserves the client IP address and also handles UDP and ESP. Second, who are the clients: the internet (external) or only your VPC and connected networks (internal). Third, where must it run: global (one anycast address serving every region), cross-region (an internal address that fails over across regions) or regional (pinned to one region, for data residency or the Standard network tier).

Derived from Choose a load balancer.

The products behind the leaves are:

The Gateway API on GKE does not add a product: GKE Gateway controllers create the Application Load Balancers above from Kubernetes resources (see The Gateway API on GKE).

Derived from gcloud services enable.

Global load balancer resources take --global; serverless NEGs, internal load balancers and Cloud NAT are regional. The console groups them all under Network services > Load balancing.

A URL map is a YAML document that you can export, edit and import, which is the practical way to express anything beyond simple path rules: header and query-parameter matches, redirects, rewrites, traffic splits, retries, timeouts and header actions.

Derived from gcloud compute url-maps import and gcloud compute url-maps validate.

The following map sends beta testers to a preview backend by header, rewrites a legacy path and redirects a retired host.

Derived from Set up URL rewrite, Set up traffic management and Set up an HTTP-to-HTTPS redirect.

Route rules are evaluated in priority order, lowest number first; the first match wins, so put specific rules first. A path matcher accepts either simple pathRules or routeRules, not both. For an HTTP-to-HTTPS redirect, attach a second URL map that contains only defaultUrlRedirect with httpsRedirect: true to an HTTP target proxy and a forwarding rule on port 80 that shares the IP address bookshelf-ip; the console does this when you tick Enable HTTP to HTTPS redirect.

The load balancer can add headers to requests it forwards to a backend and to responses it returns to clients, with variables that it fills in from the connection. This is the supported way to learn the client’s approximate location or TLS properties without a geolocation library.

Derived from Create custom headers and gcloud compute backend-services update.

Useful variables are {client_region} (the country as an ISO code), {client_region_subdivision}, {client_city}, {client_city_lat_long}, {client_ip_address}, {client_port}, {client_rtt_msec}, {tls_sni_hostname}, {tls_version} and {tls_cipher_suite}. Header names are limited: some well-known and reserved names and prefixes cannot be set, there is a documented cap on the number of custom headers per backend, and the location variables are approximations that can be empty (the header is then sent empty). A custom header is added to the request even if the client sent one with the same name, so check the documented behaviour before relying on a name.

The following Spring Boot controller serves region-specific content from the headers. Treat them as hints, never as an authorization input: set them unconditionally on the load balancer so that clients cannot spoof them, and fall back to a default when they are empty.

Derived from Create custom headers and Spring Framework: @RequestHeader.

Putting Cloud Armor in front of Cloud Run only helps if the service cannot be reached any other way. A Cloud Run service is reachable by default at its run.app URL; restrict it so that only the load balancer can call it.

Derived from Restrict network ingress for Cloud Run, Disabling the default URL and gcloud run services update.

Ingress internal-and-cloud-load-balancing accepts requests from external Application Load Balancers (global or regional), internal Application Load Balancers, VPC networks and a few Google services such as Pub/Sub, but rejects direct calls from the internet to the run.app URL with 404 or 403. The load balancer does not send an identity token, so either allow unauthenticated invocation (the public front end of Bookshelf) or turn on IAP for the backend service; where an organization policy forbids allUsers, Cloud Run’s option to disable the IAM invoker check lets the ingress setting act as the access control. Do not leave the default all ingress in place while a Cloud Armor policy is attached: the policy would then be bypassable by calling the service URL directly. See Cloud Run for the full service configuration.

Cloud Armor is Google’s network edge security service: a web application firewall (WAF), DDoS mitigation and bot defences that run on the same edge fleet as the load balancer, so malicious requests are dropped before they reach a backend. It is configured as security policies that you attach to backends.

A regional internal Application Load Balancer gives orders-api a stable private URL for catalog-api without exposing it to the internet, and the same ingress setting (internal-and-cloud-load-balancing) admits it. It needs a proxy-only subnet in the region, which hosts the Envoy proxies that terminate connections.

Derived from Set up a regional internal Application Load Balancer with Cloud Run, Proxy-only subnets and gcloud compute forwarding-rules create.

Callers inside the VPC address the forwarding rule’s internal IP, or a private DNS name that points at it (see Cloud DNS and Certificate Manager); use an HTTPS proxy with a Certificate Manager or regional certificate for TLS between services. For orders-api on Cloud Run, attach the service to the VPC with Direct VPC egress (see VPC Networking on Google Cloud) so that the call goes to the internal address.

Load balancers handle inbound traffic. Cloud NAT is the managed network address translation service for outbound connections from resources that have no external IP address: VMs, GKE nodes and Pods, and Cloud Run services or jobs that use Direct VPC egress or a Serverless VPC Access connector. It provides a stable, predictable set of source addresses so that a partner can allow-list Bookshelf, and it is not a load balancer and does not accept inbound connections from the internet.

Derived from Set up and manage network address translation with Cloud NAT and gcloud compute routers nats create.

To send all Cloud Run egress through the NAT, deploy with Direct VPC egress and --vpc-egress=all-traffic; to leave Google API traffic on the private path, enable Private Google Access on the subnet. With reserved addresses the egress IPs never change, with --auto-allocate-nat-external-ips they can. Each external IP address provides about 64,512 NAT ports and each connection to the same destination IP, port and protocol consumes one, so allocate more ports per VM (--min-ports-per-vm) or enable dynamic port allocation for chatty workloads; "Out of resources" drops show up as OUT_OF_RESOURCES in the NAT logs. Private NAT translates between private networks (for example overlapping on-premises ranges) and needs no external addresses. The gateway, port allocation and monitoring are explained further on VPC Networking on Google Cloud.

There are three ways to serve a Cloud Run service under your own hostname.

The domain mapping route requires verifying domain ownership first (gcloud domains verify), described with the other verification mechanisms on Cloud DNS and Certificate Manager. For the load-balancer route, no domain verification is needed beyond the DNS authorization of the certificate.

Service Extensions let you insert your own code into the data path of an Application Load Balancer. Plugins run WebAssembly modules inside the load balancer’s proxy, for lightweight header and body manipulation or custom filtering. Callouts send request and response events to a gRPC service that you operate on Cloud Run, GKE or Compute Engine and that may modify them, for example for a custom authorization decision, content filtering or an AI inference gateway. Use them sparingly because every callout adds latency to the request, and prefer URL maps, Cloud Armor expressions and custom headers when they are enough.

Derived from Service Extensions overview.

On GKE, Gateway resources create and manage the load balancers described above. A Gateway with gatewayClassName: gke-l7-global-external-managed provisions a global external Application Load Balancer, HTTPRoute resources fill its URL map, and a GCPBackendPolicy attaches Cloud Armor, custom headers, IAP and timeouts to the Services behind it.

Derived from Gateway API on GKE and Configure Gateway resources.

Routes, canary traffic splits and the rest of the Gateway workflow are on Deploying Microservices on GKE; choose the Gateway API over the older Ingress for new clusters.

Derived from Architecture Center: application development and Application Load Balancer overview.

Topology 1 is the Bookshelf production setup. Topology 2 puts the global load balancer in front of API Gateway or Apigee (through a serverless NEG for API Gateway, or an Apigee network integration) when you need API keys, quotas and a developer portal, as covered on API Gateway, Apigee and Cloud Endpoints; Cloud Armor then protects the gateway as well. Topology 3 keeps service-to-service traffic off the internet.

Derived from Cloud Load Balancing IAM and gcloud projects add-iam-policy-binding.

Prices change; the dated pages linked below are authoritative and no figure is repeated here.

There is no permanent free tier for the load balancer itself, so a forgotten test load balancer costs money every hour.

Derived from Network pricing, Cloud Armor pricing and Cloud NAT pricing; pricing pages checked 2026-10-01.

Derived from Load balancing quotas and limits, Cloud Armor quotas and Cloud Load Balancing release notes.

Enable request logging on every backend service you care about; it is off by default for backend services created with the CLI and has a sampling rate that you set.

Derived from External Application Load Balancer logging and monitoring.

Derived from Troubleshooting external Application Load Balancers, Troubleshooting Certificate Manager and Troubleshooting Cloud Armor.

Delete in reverse order of creation. The forwarding rules, Cloud NAT gateways and reserved addresses cost money even with no traffic.

Derived from Clean up the load balancer and gcloud compute forwarding-rules delete.

Skip the commands for pieces you did not create. A backend service must be detached from any URL map before it can be deleted, and a security policy cannot be deleted while a backend still references it (run gcloud compute backend-services update catalog-backend --global --security-policy= first if the order above fails). Remove the A and CNAME records from your DNS zone. The bucket and the Cloud Run service belong to their own pages' clean up steps. For a throwaway project, deleting the project removes everything, with the usual 30-day recovery window (see Resource Hierarchy and Projects).