Cloud Load Balancing supports proxying traffic to external backends outside Google Cloud. To define an external backend for a load balancer, you use a resource called an internet network endpoint group (NEG).
You can use this type of deployment when you want to serve content from an external backend, but you want your Google Cloud load balancer to be the frontend. This lets you do the following:
Figure 1 shows an external Application Load Balancer with multiple backend types, one of which is an external backend configured with an internet NEG.
Internet NEG backends are supported with various global and regional load balancers. Depending on your load balancer (global or regional), internet NEG support differs with respect to DNS, health checking, available number of endpoints, server certificate validation, and traffic routing behaviors.
The sections that follow explain how external backends are used with Cloud Load Balancing. If you want to use an external backend with Cloud Service Mesh, see Cloud Service Mesh with internet network endpoint groups.
The following terms are sometimes used interchangeably because they have the same or similar meanings:
This document uses the term external backend except when referring to the internet NEG API resource.
This section describes the load balancing architecture and resources required to configure a load balancer with an external backend. The load balancer requires special configuration only for the backend service. The frontend configuration is the same as any other load balancer.
The following figures show the Google Cloud resources required to set up a load balancer with an external backend.
This figure shows the Google Cloud resources required to set up a global external Application Load Balancer with an external backend.
This figure shows the Google Cloud resources required to set up a regional external Application Load Balancer with an external backend.
This figure shows the Google Cloud resources required to set up a regional internal Application Load Balancer with an external backend.
This figure shows the Google Cloud resources required to set up a regional internal proxy Network Load Balancer with an external backend.
You can only use internet NEGs on the Premium network service tier.
No special frontend configuration is required for creating a load balancer with an internet NEG backend. Forwarding rules are used to route traffic by IP address, port, and protocol to a target proxy. The target proxy then terminates connections from clients. Additionally, Envoy-based load balancers require a proxy-only subnet.
Application Load Balancers also use URL maps to set up URL-based routing of requests to the appropriate backend services.
For more details about each of these components, refer to the architecture sections of the respective load balancer:
An internet NEG is a resource used to define an external backend for the
load balancer. There are two types of internet NEGs: global internet NEG and
regional internet NEG. They differ in the scope (global versus regional) and
behavior. The external backend referenced by a global internet NEG must be
reachable exclusively over the internet; it can't be reachable over
Cloud VPN or Cloud Interconnect. If the external backend
references a Google API or service, the service must be reachable through
TCP port 80 or 443 by using the HTTP, HTTPS, or HTTP/2 protocol.
There are two ways to configure the external endpoint referenced by the NEG:
INTERNET_FQDN_PORT or INTERNET_IP_PORT. If the INTERNET_IP_PORT format is
chosen, only a public internet routable IP address can be used; if the
INTERNET_FQDN_PORT format is chosen the FQDN can be resolved to either a
public internet routable IP address or to a private IP address depending on the
scope of the endpoint: regional or global.
Global internet NEGs are powered by Google Front End (GFE) technologies. They use a fixed set of fixed IP addresses for egress traffic to all clients. They support only one endpoint per NEG and one internet NEG per backend service.
The following table describes how different load balancers support global internet NEGs.
| Load balancers | Endpoint type | Endpoint definition | Scope | Health checks | Server certificate validation |
|---|---|---|---|---|---|
|
|
A publicly resolvable fully qualified
domain name and an optional port. For example,
The domain name must be resolvable by Google's public DNS infrastructure. Only one endpoint per NEG is allowed. |
Global | Not supported | Always validated against public CA certificates. |
|
A publicly routable IP address and an optional port. For example,
The IP address can't be an RFC 1918 address. Only one endpoint per NEG is allowed. |
Not validated. |
† If you don't specify a port while adding the endpoint, the
default port of the NEG is used. If you didn't specify a default port for the
NEG, the well-known port for your backend protocol is used (80 for
HTTP and 443 for HTTPS and HTTP/2).
Regional internet NEGs are powered by managed Envoy proxies. Each NEG can have multiple endpoints, and a backend service can include multiple internet NEGs.
For egress traffic, you can configure Cloud NAT gateways to set the source IP addresses. Alternatively, you can route traffic using learned routes within your VPC network. While Cloud NAT isn't required for this routing method, it is supported.
The following table describes how different load balancers support regional internet NEGs.
| Load balancers | Endpoint type | Endpoint definition | Scope | Health checks | Server certificate validation |
|---|---|---|---|---|---|
|
|
Either a publicly or privately resolvable fully qualified
domain name and an optional port. For example,
The domain name resolution process follows the Cloud DNS name resolution order process. A maximum of 256 endpoints per NEG are allowed. |
Regional | Envoy distributed health checks | Not validated. Set up Backend Authenticated TLS to perform certificate validation. |
|
Only a publicly routable IP address and an optional port. For example,
The IP address can't be an RFC 1918 address. A maximum of 256 endpoints per NEG are allowed. |
Not validated. Set up Backend Authenticated TLS to perform certificate validation. |
* With regional internet NEGs, you are required to specify a port. You can specify a default port while creating the NEG, or you can specify a port each time you add an endpoint to the NEG, or you can do both. If you don't specify a port while adding an endpoint, the default port of the NEG is used.
INTERNET_FQDN_PORT endpointsIf your domain is resolvable over the internet, no other configuration is needed to set up DNS. However, if you're resolving private FQDNs, you'll need to configure Cloud DNS to facilitate DNS resolution. The name must be hosted on Cloud DNS or be resolvable using DNS forwarding from Cloud DNS to an on-premises DNS or DNS peering if referencing a Private DNS zone in another VPC network.
Start by creating a Cloud DNS zone to host the DNS records in your project. Then add the DNS records to it. For specific configuration steps, see the Cloud DNS documentation. The Cloud DNS resolution order is detailed at Name resolution order.
If you're using Shared VPC, note the specific network requirements. You can also use other features of Cloud DNS, such as forwarding zones, to fetch records from an on-premises DNS server.
INTERNET_FQDN_PORT endpointsWhen an INTERNET_FQDN_PORT endpoint points to a DNS record that returns
multiple IP addresses, the IP address is resolved in the following way:
The load balancer uses a DNS resolver in a Google Cloud region that is
closest to its client on the internet. If the DNS record for your
INTERNET_FQDN_PORT endpoint returns different IP addresses based on the
location of the client, make sure that each of those IP addresses can be
reached by the load balancer.
The load balancer attempts to connect to the first IP
address in the DNS response. If that IP address isn't reachable, the load
balancer returns an HTTP 502 (Bad Gateway) response. This is true even if
other IP addresses from the DNS response are available.
For more information about the IP ranges and locations used by Google's DNS resolver infrastructure, see the Google public DNS documentation. Names that can't be resolved by the public DNS system aren't usable as external backends.
INTERNET_FQDN_PORT endpointsRegional internet NEGs support domain name resolution using both Cloud DNS and Google's public DNS.
If the DNS server returns multiple IP addresses, Envoy load balances traffic among the returned IP addresses based on the configured load balancing algorithm (round robin, least request, and so on). The list of endpoints is periodically refreshed based on DNS TTL. You can configure retry policies to force Envoy to attempt to connect to another IP address if one fails.
Backend services provide configuration information to the load balancer. Load balancers use the information in a backend service to direct incoming traffic to one or more attached backends.
To set up a load balancer with an external backend, you configure the backend service with an internet NEG backend. When you add an internet NEG to a backend service, the following considerations apply, depending on the scope of the NEG:
The backend service can't also use other backend types (such as zonal NEGs or instance groups) as backends.
Number of NEGs per backend service
Number of endpoints per NEG
Global NEGs. You can add only one endpoint to an internet NEG.
Because only one endpoint is allowed in each global internet NEG, load balancing isn't actually performed. The load balancer serves as the frontend only, and it proxies traffic to the specified external backend. This means that you can't use any of the load balancing modes, such as rate, connection, or utilization.
Regional NEGs don't support load balancing modes, such as rate, connection,
or utilization. All the endpoints of all the NEGs attached to a backend
service are pooled into a single group. Load balancing traffic among this
pool of endpoints is handled using Envoy load balancing algorithms. For the
load balancing policy algorithms supported, see
localityLbPolicy in the regional
backend service API documentation.
Health checks
The backend service's load balancing scheme must match the scheme required by the load balancer you are deploying. For the complete list, see Backend services.
The backend service protocol must be one of HTTP, HTTPS, or HTTP2.
We strongly recommend you use either HTTPS or HTTP/2 as the protocol when configuring a backend service with an internet NEG so that communication between the load balancer and the backend is encrypted and authenticated when transiting the public internet.
Server certificate validation
Server certificate validation depends on the type of endpoint
(INTERNET_FQDN_PORTor INTERNET_IP_PORT) and the scope of the endpoint:
regional or global.
Global NEGs. Load balancer validates the server certificate for INTERNET_FQDN_PORT.
When an external backend is created by using INTERNET_FQDN_PORT, the
load balancer validates the SSL server certificate presented by the
external backend and verifies that the following information is true:
If you create the external backend by using an INTERNET_IP_PORT endpoint,
SSL server certificate validation isn't performed.
Regional NEGs. Load balancer does not validate the SSL server certificate by default.
By default server certificate validation is not performed for regional
internal or external backends created with either INTERNET_FQDN_PORT or
INTERNET_IP_PORT. If server certificate validation is required, it can
be configured with backend authenticated TLS.
SSL Server Name Indication (SNI) extension handling
The SSL Server Name Indication (SNI) extension is only supported with
INTERNET_FQDN_PORT endpoints. The configured FQDN is sent an SNI in the
client hello during the SSL handshake between the load balancer and the
external endpoint. The SNI isn't sent when you use an INTERNET_IP_PORT
endpoint because IP address literals aren't allowed in the HostName field
of an SNI payload.
Your health check configuration varies depending on the type of load balancer:
Global external Application Load Balancer and classic Application Load Balancer. A backend service with a global internet NEG doesn't support health checks.
If your external backend becomes unreachable or if the configured hostname
(FQDN) cannot be resolved, the load balancer returns an HTTP 502 (Bad
Gateway) response to its clients.
Regional external Application Load Balancer, regional internal Application Load Balancer, regional external proxy Network Load Balancer, and regional internal proxy Network Load Balancer. Health checks are optional. Health check probes for these load balancers originate from the proxy-only subnet and are then NAT-translated (by using Cloud NAT) to either pre-reserved IP addresses or auto-allocated NAT IP addresses. For details, see Regional NEGs: Use a Cloud NAT gateway.
Distributed Envoy health checks are created by using the same Google Cloud console, gcloud CLI, and API processes as centralized health checks. No other configuration is required.
Points to note:
Because the Envoy data plane handles health checks, you cannot use the
Google Cloud console, the API, or the gcloud CLI to check the
health status of these external endpoints. For hybrid NEGs with Envoy-based
load balancers, the Google Cloud console shows the health check status as
N/A. This is expected.
Every Envoy proxy assigned to the proxy-only subnet in the region in the
VPC network initiates health checks independently. Therefore,
you might see an increase in network traffic because of health checking. The
increase depends on the number of Envoy proxies assigned to your
VPC network in a region, the amount of traffic received by
these proxies, and the number of endpoints that each Envoy proxy needs to
health check. In the worst case scenario, network traffic because of health
checks increases at a quadratic (O(n^2)) rate.
Health check logs for distributed Envoy health checks don't include detailed health states. For details about what is logged, see Health check logging. To further troubleshoot connectivity from Envoy proxies to your NEG endpoints, you should also check the respective load balancer logs.
Configure your external backend to allow traffic from Google Cloud.
This procedure depends on the scope of the NEG: global or regional.
If you're using a global internet NEG, you
must add the IP address ranges that Google uses to send requests to
external backends to an allowlist. To look up the IP addresses to be added to an
allowlist, query the _cloud-eoips.googleusercontent.com DNS TXT record by
using a tool like dig or nslookup.
For an example, see Allow the external backend to receive traffic from Google Cloud.
If you're using a regional internet NEG, you'll first set up a Cloud NAT gateway to allocate a set of IP address ranges from where Google Cloud traffic should originate.
The gateway endpoint should be of type ENDPOINT_TYPE_MANAGED_PROXY_LB.
The Cloud NAT gateway can be configured to either automatically allocate external IP addresses based on demand or use a manually pre-reserved set of external IP addresses.
Automatically allocated IP addresses
Use automatically allocated IP addresses if your external backend environment doesn't require you to add specific Google Cloud IP addresses that can send traffic to the external backend to an allowlist.
Manually allocated IP addresses
Use manually allocated IP addresses only if your external backend environment requires you to add specific Google Cloud IP addresses to an allowlist. Because each Envoy assigned to your proxy subnet consumes an entire IP address, make sure that the pool of reserved IP addresses is big enough to accommodate all Envoys.
If you experience connectivity issues at scale, check whether you've reached the Cloud NAT limits. By default, you are limited to 50 manually allocated NAT IP addresses per gateway.
Dynamic port allocation is supported for regional internet NEGs. IP addresses can be shared by proxies, thus fully utilized.
This Cloud NAT configuration applies to the entire proxy-only subnet. Internet traffic associated with all the regional Envoy-based load balancers in the region share the same NAT gateway.
NAT gateways configured on proxy-only subnets don't support logging and
monitoring. That is, the --enable-logging and --log-filter flags aren't
supported.
This section applies only to Application Load Balancers.
To authenticate requests sent to your external backend, you can do one of the following:
Set a custom header to indicate that the request came from a Google Cloud load balancer by using a custom request header. For example, you can use 16 or more cryptographically random bytes as a shared key.
Implementing custom header transformations depends on the type of load balancer you're using:
Global external Application Load Balancer and classic Application Load Balancer. Custom header transformations can be configured on either the backend service or the URL map.
For example, you can configure the external backend to expect a particular
value for the HTTP request's Host header, and you can configure the load
balancer to set the Host header to that expected value. If you don't
configure a custom request header, the load balancer preserves the headers
that the client used to connect to the load balancer and includes the same
header in its response. However, note that modifying the Host header is
not supported in the URL map.
There are additional limitations associated with configuring the
Host header. For details, see Create custom headers in backend
services. For a specific
example, see Set up a global external Application Load Balancer with an external
backend.
Regional external Application Load Balancer and regional internal Application Load Balancer. Custom header transformations can only be configured on the URL map.
For these Envoy-based load balancers, Host and authority are special
keywords reserved by Google Cloud. You can't modify these headers for
these load balancers. Instead, we recommend that you create other custom
headers (for example, MyHost) so that you don't interfere with the
reserved header names.
Enable IAP and
verify that the signed JWT
in the request header is signed by Google, and that the
aud (audience) claim
contains the project number where your load balancer is
defined.
Note the following:
Requests proxied to an external backend are logged to Cloud Logging in the same way that requests for other backends are logged.
For more information, see the following:
Different load balancers might handle header processing in different ways when they proxy requests to an external backend. Review the following information to understand how your load balancer type might process HTTP headers.
When a global external Application Load Balancer or a classic Application Load Balancer proxies requests to an external backend, it adjusts HTTP headers in the following ways:
Some headers are coalesced. When there are multiple instances of the same
header key (for example, Via), the load balancer combines their values
into a single comma-separated list for a single header key. Only the headers
whose values can be represented as a comma-separated list are coalesced. Other
headers, such as Set-Cookie, are never coalesced.
Headers are proper-cased when the backend service's protocol is HTTP or
HTTPS:
The first letter of the header's key and every letter following a hyphen
(-) is capitalized to preserve compatibility with HTTP/1.1 clients. For
example, user-agent is changed to User-Agent, and content-encoding
is changed to Content-Encoding.
Certain headers, such as Accept-CH (client
hints),
are converted to match standard mixed letter representation.
Some headers are added, or values are appended to them. The external Application Load Balancers
always add or modify certain headers
such as Via and X-Forwarded-For.
There is no special header processing for Envoy-based load balancers using internet NEGs. To learn how Envoy typically processes headers, see HTTP header manipulation.
502 errors with the error code
failed_to_connect_to_backend. This is expected behavior.For information about quotas and limits, see the NEG backends quota table and the Endpoints per NEG quota table.
For information about internet egress rates to internet NEG endpoints, see Premium Tier pricing.
If you configured a Cloud NAT gateway to map your regional Envoy-based load balancer's proxy-only subnet, see Network pricing: Cloud NAT.
For any other information about Cloud Load Balancing pricing and regional internet NEG charges, see Network pricing: Cloud Load Balancing.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-06-09 UTC.