A serverless NEG can represent one of the following:
- A Cloud Run service or a group of services.
- A Cloud Functions function or a group of functions.
- An App Engine app (Standard or Flex), a specific service within an app, a specific version of an app, or a group of services.
When external HTTP(S) Load Balancing is enabled for serverless apps, you can do the following:
- Configure your serverless app to serve from a dedicated IPv4 and/or IPv6 IP address that is not shared with other services.
- Map a single URL to multiple functionally identical serverless applications. By running the applications in different regions, requests can be routed to the region closest to the user. Mapping a single URL to multiple functionally identical serverless applications is supported only for Cloud Run and Cloud Functions.
- Reuse the same SSL certificates and private keys that you use for Compute Engine, Google Kubernetes Engine, and Cloud Storage. Reusing the same certificates eliminates the need to manage separate certificates for serverless apps.
Setting up external HTTP(S) Load Balancing also enables your serverless apps to integrate with existing Cloud services. You can do the following:
- Share URL space with other Google Cloud technologies. By using multiple backend services, a single external HTTP(S) load balancer can send traffic to multiple backend types. The load balancer selects the correct backend service based on the host or path of the request URL.
- Protect your service with Google Cloud Armor, an edge DDoS defense/WAF security product available to all services accessed through an external HTTP(S) load balancer. There are some limitations associated with this capability, especially for Cloud Run and App Engine.
- Enable your service to optimize delivery using Cloud CDN. Cloud CDN caches content close to your users. Cloud CDN provides capabilities like cache invalidation and Cloud CDN signed URLs.
- Use Google's Edge infrastructure to terminate user's HTTP(S) connections closer to the user, thus decreasing latency.
Serverless network endpoint groups (NEGs) are supported with global external HTTP(S) load balancers. You cannot use serverless NEGs with regional external HTTP(S) load balancers or with any other load balancer types.
For more information about other types of NEGs, see:
Serverless NEGs do not have any network endpoints such as ports or IP addresses. They can only point to an existing Cloud Run, App Engine, or Cloud Functions service residing in the same region as the NEG.
When you create a serverless NEG, you specify the fully qualified domain name
(FQDN) of the Cloud Run, App Engine,
or Cloud Functions service. The endpoint is of type
SERVERLESS. Other endpoint types are not supported in a serverless NEG.
A serverless NEG cannot have more than one endpoint. Because only one endpoint is allowed in each serverless NEG, the load balancer serves as the frontend only, and proxies traffic to the specified serverless endpoint. However, if the backend service contains multiple serverless NEGs, the load balancer balances traffic between these NEGs, thus minimizing request latency.
You can use a serverless NEG in a load balancer using either Standard or Premium Network Service Tiers. The Premium tier is required only if you want to set up serverless NEGs in multiple regions.
Load balancing components
This diagram shows how a serverless NEG fits into the HTTP(S) Load Balancing model.
The forwarding rule is part of the frontend configuration. Each forwarding rule has an external IP address, the IP version (IPv4 or IPv6), a protocol (HTTP or HTTPS (includes HTTP/2), and a port number (80 or 443).
Serverless NEGs can only be used with HTTP and HTTPS target proxies. Services that use serverless NEGs cannot be used with TCP or SSL target proxies.
The forwarding selection for an external HTTP(S) load balancer is based on a URL map. With a URL map, target HTTP(S) proxies determine the backend service to be used by checking the request hostname and path in the URL map. Load balancers can have multiple backend services referenced from the URL map. Each backend service can be associated with a different backend type. For example, you can have a backend service for a serverless NEG and another backend service for Compute Engine instance groups.
Serverless NEGs can be used as backends in a load balancer. A backend service can have several serverless NEGs. Each serverless NEG can point to either of the following:
- The FQDN for a single function or service
- A URL mask that points to multiple functions or services that serve at the same domain
A URL mask is a URL schema template that tells the serverless NEG backend how to map the user request to the correct service. URL masks are useful if you are using a custom domain for your application and have multiple Cloud Run, Cloud Functions, or App Engine services serving at the same domain. Instead of creating a separate serverless NEG for each function or service, you can create the NEG with a generic URL mask for the custom domain. For more information and examples, see URL masks.
For additional restrictions when adding a serverless NEG as a backend, see Limitations.
Optional URL masks make it easier to configure serverless NEGs when your application has multiple Cloud Run, Cloud Functions, or App Engine services. A serverless NEG backend can point to either a single Cloud Run (or App Engine or Cloud Functions) service, or a URL mask that points to multiple services.
A URL mask is a template of your URL schema. The serverless NEG uses this template to map the request to the appropriate service.
URL masks are useful if your serverless app is mapped to a custom domain rather
than the default address that Google Cloud provides.
With a custom domain such as
example.com, you could have multiple
services deployed to different subdomains or paths on the same domain. In such
cases, instead of creating a separate serverless NEG backend for each
service, you can create a single serverless NEG with a generic URL mask for the
custom domain (for example,
example.com/<service>). The NEG extracts the
service name from the request's URL.
The following illustration shows an external HTTP(S) load balancer with a single backend service and serverless NEG, that uses a URL mask to map user requests to different services.
URL masks work best when your application's services use a predictable URL
schema. The advantage of using a URL mask instead of a URL map is that you don't
need to create separate serverless NEGs for the
You also don't need to modify your load balancer configuration each time you add
a new service to your application.
To learn how to construct and configure a URL mask for a serverless NEG, see Setting up an HTTP(S) load balancer with a serverless NEG.
- You cannot use serverless NEGs as backends for Regional external HTTP(S) load balancers.
- A serverless NEG cannot have any network endpoints such as IP address or port.
- Serverless NEGs can point only to Cloud Run, App Engine, or Cloud Functions services residing in the same region where the NEG is created.
- Load balancers using serverless NEG backends must be created in the same project as the Cloud Run, App Engine, or Cloud Functions services pointed to by the NEG.
- An external HTTP(S) load balancer configured with a serverless NEG cannot detect whether the underlying service is working as expected. This means that if your service in one region is returning errors but the overall infrastructure in that region is operating normally, your external HTTP(S) load balancer can't automatically direct traffic away to other regions. Make sure to thoroughly test new versions of your services before routing user traffic to them.
Limitations associated with backend services that have a serverless NEG backend
- A backend service can have one serverless NEG per region. To combine multiple serverless NEGs in a single backend service, all the NEGs must represent functionally equivalent deployments in different regions. For example, the NEGs can point to the same Cloud Run, App Engine, or Cloud Functions service deployed in different regions.
- The backend service timeout
setting does not apply
to backend services with serverless NEG backends. Attempting to modify the
resource.timeoutSecproperty results in the following error:
Timeout sec is not supported for a backend service with Serverless network endpoint groups.
For backend services with serverless NEG backends, the default timeout is 60 minutes. This timeout is not configurable. If your application needs long-running connections, configure your clients to retry requests on failure.
- All serverless NEGs combined in a backend service must also use the same type of backend. This means Cloud Run serverless NEGs can only be combined with other Cloud Run serverless NEGs, App Engine serverless NEGs can only be combined with App Engine serverless NEGs, etc.
- You cannot mix serverless NEGs with other types of NEGs (zonal or internet NEGs) in the same backend service. For example, you cannot route to a GKE cluster and a Cloud Run service from the same backend service.
- When setting up backend services that route to serverless NEGs,
certain fields are restricted:
- You cannot specify a balancing mode. That is, the
CONNECTIONvalues have no effect on the load balancer's traffic distribution.
- Health checks are not supported for serverless backends. Therefore, backend services containing serverless NEG backends cannot be configured with health checks.
- You cannot specify a balancing mode. That is, the
- You cannot use the
gcloud compute backend-services editcommand to modify a backend service with a serverless NEG backend. As a workaround, use the
gcloud compute backend-services updatecommand instead.
Additional limitations might apply depending on the serverless compute platform you are using.
Limitations with Cloud Run
- External HTTP(S) Load Balancing with serverless NEGs is not supported with Cloud Run for Anthos.
Limitations with Cloud Functions
- IAP does not work with Cloud Functions.
Limitations with App Engine
- Multi-region load balancing is not supported with App Engine. This is because App Engine requires 1 region per project.
- Only one IAP policy is allowed on the request path. For example, if you have already set an IAP policy in the backend service, you should not set another IAP policy on the App Engine app.
- We recommend that you use ingress controls so that your app only receives requests sent from the load balancer (and the VPC if you use it). Otherwise, users can use your app's App Engine URL to bypass the load balancer, Google Cloud Armor security policies, SSL certificates, and private keys that are passed through the load balancer.
To see pricing information for external HTTP(S) load balancers with serverless NEGs, see Network Pricing.