About published services

This document provides an overview of using Private Service Connect to make a service available to service consumers.

As a service producer, you can use Private Service Connect to publish services by using internal IP addresses in your VPC network. Your published services are accessible to service consumers by using internal IP addresses in their VPC networks.

To make a service available to consumers, you create one or more dedicated subnets. You then create a service attachment that refers to those subnets. The service attachment can have different connection preferences.

Service consumer types

There are two types of consumers that can connect to a Private Service Connect service:

• Private Service Connect endpoints
• Private Service Connect backends

Endpoints are based on a forwarding rule.

Figure 1. An endpoint lets service consumers send traffic from the consumer's VPC network to services in the service producer's VPC network (click to enlarge).

Backends are based on a load balancer.

Figure 2. A backend that uses 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).

Private Service Connect service configuration

When you create a Private Service Connect service, you configure a subnet, a service attachment, and a connection preference. You can also optionally configure a DNS domain for the service. These configurations are described in the following sections.

NAT subnets

Private Service Connect service attachments are configured with one or more NAT subnets (also referred to as Private Service Connect subnets). Packets from the consumer VPC network are translated using source NAT (SNAT) so that their original source IP addresses are converted to source IP addresses from the NAT subnet in the producer's VPC network.

Service attachments can have multiple NAT subnets. Additional NAT subnets can be added to the service attachment at any time without interrupting traffic.

While a service attachment can have multiple NAT subnets configured, a NAT subnet cannot be used in more than one service attachment.

Private Service Connect NAT subnets cannot be used for resources such as VM instances or forwarding rules. The subnets are used only to provide IP addresses for SNAT of incoming consumer connections.

NAT subnet sizing

When you publish a service, you create a NAT subnet and choose an IP address range. The size of the subnet determines how many simultaneous Private Service Connect endpoints or backends can connect to the service attachment. IP addresses are consumed from the NAT subnet according to the number of Private Service Connect connections. If all of the IP addresses in the NAT subnet are consumed, any additional Private Service Connect connections will fail. This is why it is important to size the NAT subnet appropriately.

When you choose a subnet size, consider the following:

• There are four unusable IP addresses in a NAT subnet, so the number of available IP addresses is 2^{(32 - PREFIX_LENGTH)} - 4. For example, if you create a NAT subnet with a prefix length of /24, Private Service Connect can use 252 of the IP addresses for SNAT. A /29 subnet with four available IP addresses is the smallest subnet size supported in VPC networks.

• One IP address is consumed from the NAT subnet for each endpoint or backend that is connected to the service attachment.

• When you estimate how many IP addresses you need for endpoints and backends, account for any multi-tenant services or consumers that use multi-point access for Private Service Connect.

• The number of TCP or UDP connections, clients, or consumer VPC networks does not affect the consumption of IP addresses from the NAT subnet.

For example, if there are two endpoints connected to a single service attachment, then two IP addresses are consumed from the NAT subnet. If the number of endpoints doesn't change, you could use a /29 subnet with four usable IP addresses for this service attachment.

NAT subnet monitoring

To help ensure that Private Service Connect connections don't fail due to unavailable IP addresses in a NAT subnet, we recommend the following:

• Monitor the private_service_connect/producer/used_nat_ip_addresses service attachment metric. Ensure that the number of used NAT IP addresses does not exceed the capacity of a service attachment's NAT subnets.
• Monitor the connection status of service attachment connections. If a connection has a status of Needs attention, there might not be any more IP addresses available in the attachment's NAT subnets.
• For multi-tenant services, you can use Connection limits to help ensure that a single consumer doesn't exhaust the capacity of a service attachment's NAT subnets.

If needed, NAT subnets can be added to the service attachment at any time without interrupting traffic.

Maximum connections

A single producer VM can accept a maximum concurrent 65,536 TCP connections and 65,536 UDP connections from a single Private Service Connect endpoint. There is no limit on the total number of TCP and UDP connections that a Private Service Connect endpoint can receive in aggregate across all producer backends. Consumer VMs can use all 65,536 ports when initiating TCP or UDP connections to a Private Service Connect endpoint. All network address translation is done locally on the producer host, which does not require a centrally allocated NAT port pool.

Other considerations

Other considerations for NAT subnets include the following:

• The UDP Mapping Idle Timeout is 30 seconds and cannot be configured.

• The TCP Established Connection Idle Timeout is 20 minutes and cannot be configured.

• The TCP Transitory Connection Idle Timeout is 30 seconds and cannot be configured.

• There is a two-minute delay before any 5-tuple (NAT subnet source IP address and source port plus destination protocol, IP address, and destination port) can be reused.

• SNAT for Private Service Connect does not support IP fragments.

Service attachments

Service producers expose their service through a service attachment.

• To expose a service, a service producer creates a service attachment that refers to the service's load balancer forwarding rule.

• To access a service, a service consumer creates an endpoint that refers to the service attachment.

The service attachment URI has this format: projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME

Each load balancer can be referenced only by a single service attachment. You cannot configure multiple service attachments that use the same load balancer.

Connection preferences

Each service attachment has a connection preference that specifies whether connection requests are automatically accepted. There are three options:

• Automatically accept all connections. The service attachment automatically accepts all inbound connection requests from any consumer. Automatic acceptance can be overridden by an organization policy that blocks incoming connections.
• Accept connections for selected networks. The service attachment only accepts inbound connection requests if the consumer VPC network is on the service attachment's consumer accept list.
• Accept connections for selected projects. The service attachment only accepts inbound connection requests if the consumer project is on the service attachment's consumer accept list.

We recommend that you accept connections for selected projects or networks. Automatically accepting all connections might be appropriate if you control consumer access through other means and want to enable permissive access to your service.

Connection statuses

Service attachments have connection statuses that describe the state of their connections. For more information, see Connection statuses.

Consumer accept and reject lists

Consumer accept lists and consumer reject lists are a security feature of service attachments. Accept and reject lists let service producers specify which consumers can establish Private Service Connect connections to their services. Consumer accept lists specify whether a connection is accepted, and consumer reject lists specify whether a connection is rejected. Both lists let you specify consumers by the VPC network or project of the connecting resource. If you add a project or network to both the accept list and the deny list, connection requests from that project or network are rejected. Specifying consumers by folder is not supported.

Consumer accept lists and consumer reject lists let you specify projects or VPC networks, but not both at the same time. You can change a list from one type to the other without interrupting connections, but you must make the change in a single update. Otherwise, some connections might temporarily change to the pending state.

Caution: Consumer accept lists specify VPC networks by name. If a VPC network that's included in an accept list is deleted and recreated with the same name in the same project, connections to endpoint or backends created in the same network are still accepted.

For information about how consumer accept lists interact with organization policies, see Interaction between consumer accept lists and organization policies.

Connection reconciliation

Connection reconciliation determines whether updates to a service attachment's accept or reject lists can affect existing Private Service Connect connections. If connection reconciliation is enabled, updating accept or reject lists can terminate existing connections. Connections that were previously rejected can become accepted. If connection reconciliation is disabled, updating the accept or reject lists only affects new and pending connections.

For example, consider a service attachment that has several accepted connections from Project-A. Project-A is on the service attachment's accept list. The service attachment is updated by removing Project-A from the accept list.

If connection reconciliation is enabled, all existing connections from Project-A transition to PENDING, which terminates network connectivity between the two VPC networks and immediately stops network traffic.

If connection reconciliation is disabled, existing connections from Project-A are not affected. Network traffic can still flow across the existing Private Service Connect connections. However, any new Private Service Connect connections are disallowed.

For information about configuring connection reconciliation for new service attachments, see Publish a service with explicit approval.

For information about configuring connection reconciliation for existing service attachments, see Configure connection reconciliation.

Connection limits

Consumer accept lists have connection limits. These limits set the total number of connections that a service attachment can accept from the specified consumer project or VPC network. Producers can use these limits to prevent individual consumers from exhausting IP addresses or resource quotas in the producer VPC network. Each accepted Private Service Connect connection subtracts from the configured limit for a consumer project or VPC network. The limits are set when you create or update consumer accept lists. You can view a service attachment's connections when you describe a service attachment.

For example, consider a case where a service attachment has a consumer accept list that includes project-1 and project-2, both with a limit of one connection. The project project-1 requests two connections, project-2 requests one connection, and project-3 requests one connection. Because project-1 has a limit of one connection, the first connection is accepted, and the second remains pending. The connection from project-2 is accepted, and the connection from project-3 remains pending. The second connection from project-1 can be accepted by increasing the limit for project-1. If project-3 is added to the consumer accept list, that connection transitions from pending to accepted.

DNS configuration

For information about DNS configuration for published services and endpoints that connect to published services, see DNS configuration for services.

Multiple region configuration

You can make a service available in multiple regions by creating the following configurations.

Producer configuration:

• Deploy the service in each region. Each regional instance of the service must be configured on a load balancer that supports access by a backend.

• Create a service attachment to publish each regional instance of the service.

Consumer configuration:

• Create a backend to access published services. The backend is based on a global external Application Load Balancer and includes the following configurations:

  • A Private Service Connect NEG in each region that points to that region's service attachment.

  • A backend service that contains the NEG backends.

In this configuration, the endpoint routes traffic by using the default global load balancing policy—first by health, then by closest location to the client.

Figure 3. Using a global external Application Load Balancer lets service consumers with internet access send traffic to services in the service producer's VPC network. Because the service is deployed in multiple regions, the load balancer can route traffic to a NEG in the closest healthy region (click to enlarge).

Features and compatibility

In the following tables, a checkmark indicates that a feature is supported, and a no symbol indicates that a feature isn't supported.

Depending on which producer load balancer is chosen, the producer service can support access by endpoints, backends, or both.

Support for endpoints

This table summarizes the supported configuration options and capabilities of endpoints that access published services.

Consumer configuration (endpoint)	Producer load balancer
	Internal passthrough Network Load Balancer	Regional internal Application Load Balancer	Regional internal proxy Network Load Balancer	Internal protocol forwarding (target instance)
Consumer global access	Independent of global access setting on load balancer	Only if global access is enabled on the load balancer	Only if global access is enabled on the load balancer	Independent of global access setting on load balancer
Interconnect traffic
Cloud VPN traffic
Automatic DNS configuration
IP stack	IPv4	IPv4	IPv4	IPv4

This table summarizes the supported configuration options and capabilities of published services that are accessed by endpoints.

Producer configuration (published service)	Producer load balancer
	Internal passthrough Network Load Balancer	Regional internal Application Load Balancer	Regional internal proxy Network Load Balancer	Internal protocol forwarding (target instance)
Supported producer backends	GCE_VM_IP NEGs Instance groups	GCE_VM_IP_PORT NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups	GCE_VM_IP_PORT NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups	Not applicable
PROXY protocol	TCP traffic only			TCP traffic only
Session affinity modes	NONE (5-tuple) CLIENT_IP_PORT_PROTO	Not applicable	Not applicable	Not applicable

Different load balancers support different port configurations; some load balancers support a single port, some support a range of ports, and some support all ports. For more information, see Port specifications.

Support for backends

A Private Service Connect backend for published services requires two load balancers—a consumer load balancer and a producer load balancer. This table describes the compatibility between different types of consumer and producer load balancers, including which backend service protocols can be used with each consumer load balancer. Each row represents a type of consumer load balancer, and each column represents a type of producer load balancer.

Consumer load balancer and supported consumer backend-service protocols	Producer load balancer
	Internal passthrough Network Load Balancer	Regional internal Application Load Balancer	Regional internal proxy Network Load Balancer
Global external Application Load Balancer (supports multiple regions) Protocols: HTTPS, HTTP2 Note: Classic Application Load Balancer is not supported.
Regional external Application Load Balancer Protocols: HTTP, HTTPS, HTTP2
Regional internal Application Load Balancer Protocols: HTTP, HTTPS, HTTP2
Cross-region internal Application Load Balancer (Preview) Protocols: HTTPS, HTTP2
Regional internal proxy Network Load Balancer Protocol: TCP
Cross-region internal proxy Network Load Balancer Protocol: TCP
Regional external proxy Network Load Balancer Protocol: TCP
Global external proxy Network Load Balancer (Preview) Protocol: TCP/SSL Note: Classic proxy Network Load Balancer is not supported.

This table describes the configuration for the producer load balancers that are supported by Private Service Connect backends.

Configuration	Producer load balancer
	Internal passthrough Network Load Balancer	Regional internal Application Load Balancer	Regional internal proxy Network Load Balancer
Supported producer backends	GCE_VM_IP NEGs Instance groups	GCE_VM_IP_PORT NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups	GCE_VM_IP_PORT NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups
Forwarding rule protocols	TCP	HTTP HTTPS HTTP/2	TCP
Forwarding rule ports	The forwarding rule must refer to a single port.	The forwarding rule must refer to a single port.	The forwarding rule must refer to a single port.
PROXY protocol

Note: To support access by a Private Service Connect backend in a global or cross-regional load balancer, the producer load balancer must have global access turned on.

Shared VPC

Service Project Admins can create service attachments in Shared VPC service projects that connect to resources in Shared VPC networks.

The configuration is the same as for a regular service attachment, except for the following:

• The forwarding rule of the producer load balancer is associated with an IP address from the Shared VPC network. The forwarding rule's subnet must be shared with the service project.
• The service attachment uses a Private Service Connect subnet from the Shared VPC network. This subnet must be shared with the service project.

Logging

You can enable VPC Flow Logs on the subnets that contain the backend VMs. The logs show flows between the backend VMs and IP addresses in the Private Service Connect subnet.

Note: It is possible to enable VPC Flow Logs for the Private Service Connect subnet. However, because there are no VMs connected to that subnet, no flows are logged.

VPC Service Controls

VPC Service Controls and Private Service Connect are compatible with each other. If the VPC network where the Private Service Connect endpoint is deployed is in a VPC Service Controls perimeter, the endpoint is part of the same perimeter. Any VPC Service Controls-supported services that are accessed through the endpoint are subject to the policies of that VPC Service Controls perimeter.

When you create an endpoint, control-plane API calls are made between the consumer and producer projects to establish a Private Service Connect connection. Establishing a Private Service Connect connection between consumer and producer projects that are not in the same VPC Service Controls perimeter does not require explicit authorization with egress policies. Communication to VPC Service Controls-supported services through the endpoint is protected by the VPC Service Controls perimeter.

Pricing

Pricing for Private Service Connect is described in the VPC pricing page.

Quotas

The number of endpoints that you can create for accessing published services is controlled by the PSC Internal LB Forwarding Rules quota. For more information, see quotas.

On-premises access

Private Service Connect services are made available by using endpoints. These endpoints can be accessed from supported connected on-premises hosts. For more information, see Access the endpoint from on-premises hosts.

Limitations

Published services have the following limitations:

• Producer load balancers do not support the following features:
• Multiple forwarding rules that use a shared IP address (SHARED_LOADBALANCER_VIP)
• Backend subsetting
• Packet Mirroring can't mirror packets for Private Service Connect published services traffic.
• You must use the Google Cloud CLI or the API to create a service attachment that points to a forwarding rule that is used for internal protocol forwarding.
• The following load balancer types do not provide values for BETA metrics—the values are 0 or missing:
  • Regional internal Application Load Balancer
  • Regional internal proxy Network Load Balancer
• For issues and workarounds, see Known issues.