About Private Service Connect backends (original) (raw)
You can access Google APIs and published services by creating aPrivate Service Connect endpoint (based on a forwarding rule) or aPrivate Service Connect backend (based on a load balancer). This guide focuses on Private Service Connect backends.
Private Service Connect backends use a load balancer configured with Private Service Connect network endpoint group (NEG) backends. This configuration was previously referred to as a_Private Service Connect endpoint with consumer HTTP(S) service controls_.
Accessing APIs and services through a consumer-managed load balancer provides several benefits. Load balancers can act as a centralized policy enforcement point where security policies (such asGoogle Cloud Armor policiesand SSL policies) or routing policies (such as Google Cloud URL maps) are enforced. They provide centralized metrics and logging that a published service might not provide, and they allow consumers to control their own routing and failover.
Figure 1 shows a load balancer with a Private Service Connect NEG connecting to a published service. Client traffic goes to a load balancer that processes the traffic and then routes it to a Private Service Connect backend that maps to a published service that runs in a different VPC network.
Figure 1. Using a global external Application Load Balancer lets service consumers with internet access send traffic to services in the service producer's VPC network (click to enlarge).
Deployment overview
To access APIs and services through Private Service Connect backends, do the following:
- Identify the service that you want to connect to.
- For published services: Ask the service producer for the service attachment URI.
- For Google APIs, do one of the following:
* Choose a regional service endpoint.
* Choose a global service endpoint.
- **Deploy a load balancer to send traffic to your published service.**Choose a load balancer that fits your requirements, including whether you have internet clients, internal clients, or require regional isolation. You can also reuse an existing load balancer.
- Deploy the Private Service Connect NEGs and add them to your load balancer backend service. Create Private Service Connect NEGs that reference your published service. Then add the NEGs to the load balancer's backend service so that the load balancer can send them traffic.
Supported load balancers and targets
You can use a backend to access a published service or a supported Google API.
See the load balancing documentation for more information about the load balancer that you want to add a Private Service Connect backend to.
- For information about global external Application Load Balancers and regional external Application Load Balancers, see External Application Load Balancer overview.
- For information about internal Application Load Balancers and Cross-region internal Application Load Balancers, see Internal Application Load Balancer overview.
- For information about regional internal proxy Network Load Balancers, see Regional internal proxy Network Load Balancer overview.
- For information about regional external proxy Network Load Balancers, see Regional external proxy Network Load Balancer overview.
- For information about global external proxy Network Load Balancers, seeExternal proxy Network Load Balancer overview.
Published service targets
A Private Service Connect backend for published services requires two load balancers—a consumer load balancer and a producer load balancer.
Consumer configuration
This table describes the consumer load balancers that are supported by Private Service Connect backends for published services, including which backend service protocols can be used with each consumer load balancer. The consumer load balancers can access published services that are hosted onsupported producer load balancers.
| Consumer load balancer | Protocols | IP version | Cross-region failover |
|---|---|---|---|
| Cross-region internal Application Load Balancer | HTTP HTTPS HTTP2 | IPv4 | |
| Cross-region internal proxy Network Load Balancer | TCP | IPv4 | |
| Global external Application Load Balancer Note: Classic Application Load Balancer isn't supported. Connecting to producer regional internal proxy Network Load Balancers isn't supported. | HTTP HTTPS HTTP2 | IPv4 | |
| Global external proxy Network Load Balancer To associate this load balancer with a Private Service Connect NEG, use the Google Cloud CLI or send an API request. Note: Classic proxy Network Load Balancer is not supported. | TCP/SSL | IPv4 | |
| Regional external Application Load Balancer | HTTP HTTPS HTTP2 | IPv4 | |
| Regional external proxy Network Load Balancer | TCP | IPv4 | |
| Regional internal Application Load Balancer | HTTP HTTPS HTTP2 | IPv4 | |
| Regional internal proxy Network Load Balancer | TCP | IPv4 |
Producer configuration
This table describes the configuration for producer load balancers that are supported by Private Service Connect backends for published services.
| Producer type | Producer configuration (published service) | ||||
|---|---|---|---|---|---|
| Supported producer backends | Forwarding rule protocols | Forwarding rule ports | PROXY protocol | IP version | Composite Health support |
| Cross-region internal Application Load Balancer | GCE_VM_IP_PORT zonal NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups | TCP HTTP HTTPS HTTP/2 gRPC | Supports one, multiple, or all ports | IPv4 | |
| Internal passthrough Network Load Balancer | GCE_VM_IP zonal NEGs Instance groups | TCP | See Producer port configuration | IPv4 | |
| Regional internal Application Load Balancer | GCE_VM_IP_PORT zonal NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups | HTTP HTTPS HTTP/2 | Supports a single port | IPv4 | |
| Regional internal proxy Network Load Balancer Note: Connections from consumer global external Application Load Balancers aren't supported. | GCE_VM_IP_PORT zonal NEGs Hybrid NEGs Private Service Connect NEGs Instance groups | TCP | Supports a single port | IPv4 | |
| Secure Web Proxy | Not applicable | Not applicable | Not applicable | IPv4 |
For an example backend configuration that uses a global external Application Load Balancer, seeAccess published services through backends.
Regional Google API targets
This table describes which load balancers can use a Private Service Connect backend to access regional Google APIs.
For an example configuration that uses an internal Application Load Balancer, seeAccess Google APIs through backends.
| Configuration | Details |
|---|---|
| Consumer configuration (Private Service Connect backend) | |
| Supported consumer load balancers | Internal Application Load Balancer Protocols: HTTPS Regional external Application Load Balancer Protocols: HTTPS |
| IP version | IPv4 |
| Producer | |
| Supported services | Supported regional Google APIs |
Global Google API targets
This table describes which load balancers can use a Private Service Connect backend to access a global Google API.
| Configuration | Details |
|---|---|
| Consumer configuration (Private Service Connect backend) | |
| Supported consumer load balancers | Global external Application Load Balancer Note: Classic Application Load Balancer is not supported. Cross-region internal Application Load Balancer |
| IP version | IPv4 |
| Producer | |
| Supported services | Bigtable: bigtable.googleapis.com and bigtableadmin.googleapis.com Cloud Logging: logging.googleapis.com Spanner: spanner.googleapis.com Cloud Storage: storage.googleapis.com Pub/Sub: pubsub.googleapis.com |
Connection statuses
Private Service Connect endpoints, backends, and service attachments have connection statuses that describe the state of their connections. The consumer and producer resources that form the two sides of a connection always have the same status.
You can view connection statuses when youview endpoint details,describe a backend, orview details for a published service.
The following table describes the possible statuses.
| Connection status | Description |
|---|---|
| Accepted | The Private Service Connect connection is accepted by the producer, and the connection is permitted by configuration. However, this status doesn't guarantee that traffic can flow through the connection. |
| Pending | The Private Service Connect connection is not established, and network traffic can't travel between the two networks. A connection might have this status for the following reasons: The service attachment requires explicit approval, and the consumer is not in the consumer accept list. The number of connections exceeds the service attachment's connection limit. Connections that are blocked for these reasons remain in the pending state indefinitely until the underlying issue is resolved. |
| Rejected | The Private Service Connect connection is not established. Network traffic can't travel between the two networks. A connection might have this status for the following reasons: A producerorganization policy rejected the connection. Aconsumer reject list rejected the connection. |
| Needs attention | There is an issue on the producer side of the connection. Some traffic might be able to flow between the two networks, but some connections might not be functional. For example, the producer's NAT subnet might be exhausted and unable to allocate IP addresses for new connections. |
| Closed | The service attachment was deleted, and the Private Service Connect connection is closed. Network traffic can't travel between the two networks. A closed connection is a terminal state. To restore the connection, you must recreate both the service attachment and the endpoint or backend. |
Specifications
All Private Service Connect backends have the following specifications:
- Only the supported load balancers can use Private Service Connect NEGs as backends.
- Private Service Connect NEGs cannot be mixed with other NEG types in the same backend service. However, self-hosted applications and managed services can both be backends of the same load balancer as long as they are part of separate backend services.
- Backend services with Private Service Connect NEGs don't support health checks. Health check resources are not configured with backend services used for Private Service Connect.
- Backend services with Private Service Connect NEGs don't supportsession affinity.
- If a Private Service Connect NEG references a service attachment, the service attachment must be in a different VPC network from the NEG and the load balancer.
- Private Service Connect NEGs can't reference service attachments that are configured forport mapping services.
Private Service Connect backends that are used in global backend services have additional specifications:
- Multiple Private Service Connect NEGs can be in the same backend service as long as they are from different regions. You can't add multiple Private Service Connect NEGs from the same region to the same backend service.
- You can take advantage of automatic cross-region failover by associating multiple Private Service Connect NEGs with the same backend service. For more information, see the following section.
Automatic cross-region failover
Accessing published services using Private Service Connect backends that are based on global or cross-regional load balancers lets you take advantage of automatic cross-region failover.
With automatic failover, if an instance of a published service in one region becomes unhealthy, your consumer load balancer stops routing traffic to the unhealthy service and instead routes traffic to a healthy instance of the service in an alternate region.
To support automatic failover, both the service producer and the service consumer must configure their resources for a multi-region deployment, as described in this section. For information about additional producer requirements for failover with Composite Health, seeComposite Health specifications.
Producer configuration:
- Deploy the service in each region. Each regional instance of the service must be configured on a regional load balancer thatsupports access by a backend.
- Create a service attachment to publish each regional instance of the service.
Consumer configuration:
- Create a Private Service Connect backend to access published services. The backend must be based on aload balancer that supports cross-region failover and includes the following configuration:
- A Private Service Connect NEG in each region that points to that region's service attachment
- A global backend service that contains the Private Service Connect NEG backends
The following diagram shows a multi-region deployment:
A global external Application Load Balancer with multiple Private Service Connect NEGs connects to a service that is published in multiple regions. This multi-region deployment lets the consumer load balancer fail over when an instance of the service becomes unhealthy, routing traffic to a healthy instance of the service that is in an alternate region (click to enlarge).
Automatic failover can be triggered in two ways:
- Failover with outlier detection: The load balancer's standard failover mechanism, which is enabled by default in multi-region deployments. Traffic is directed away from Private Service Connect NEGs that receive a high rate of errors from the published service.
- Enhanced failover with Composite Health: Service producers can configure Composite Health to provide more detailed health signals for their services.
Failover through outlier detection
When multiple Private Service Connect NEGs are configured in a global backend service, outlier detectionis automatically enabled on the backend service.
When outlier detection identifies failures in responses sent by a published service, such as 5xx response codes, the consumer load balancer fails over, temporarily redirecting traffic to a healthy instance of the service that is in an alternate region.
You can replace the default outlier detection policy by applying your ownoutlier detection configuration to the backend service, or you can disable the feature by configuring a single Private Service Connect NEG in the backend service and routing 100% of your traffic to this NEG.
Enhanced failover through Composite Health
With Composite Health, a consumer load balancer can fail over based on a direct health signal that is configured by the service producer.
The producer defines conditions that create a single composite health state for each instance of the regional published service. The composite health state is based on the health of the service's backends, such as VM instances or network endpoints. For example, a producer can specify that their service is considered healthy only when a certain percentage of its backend instances are healthy.
For supported load balancers in multi-region deployments, no additional configuration is required from consumers to use health signals from Composite Health.
You can view logsthat record health state transitions (for example, from HEALTHY to UNHEALTHY) for published services that connect to your Private Service Connect backends.
For information about how service producers can configure Composite Health, seeAbout Composite Health.
Pricing
For pricing information, see the following sections of the VPC pricing page:
- Using a Private Service Connect backend to access a published service.
- Using a Private Service Connect backend to access Google APIs.