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.

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.

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).

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 virtual machine (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.

NAT specifications

Consider the following characteristics of Private Service Connect NAT when you design the service that you are publishing:

• 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.

  To avoid issues with client connections timing out, do one of the following:

  • Ensure that all connections live less than 20 minutes.

  • Ensure that some traffic is sent more often than once every 20 minutes. You can use a heartbeat or keepalive in your application, or TCP keepalives. For example, you can configure a keepalive in the target proxy of a Regional internal Application Load Balancer or a Regional internal proxy Network Load Balancer.

• 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.

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.

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 consumers that are created in the same network are still accepted.

Consumer lists control whether an endpoint can connect to a published service, but they don't control who can send requests to that endpoint. For example, say a consumer has a Shared VPC network that has two service projects attached to it. If a published service has service-project1 in the consumer accept list, and service-project2 in the consumer reject list, the following applies:

• A consumer in service-project1 can create an endpoint that connects to the published service.
• A consumer in service-project2 can't create an endpoint that connects to the published service.
• A client in service-project2 can send requests to the endpoint in service-project1, if there are no firewall rules or policies preventing that traffic.

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

Consumer accept list limits

Consumer accept lists have connection limits. These limits set the total number of Private Service Connect endpoint and backend connections that a service attachment can accept from the specified consumer project or VPC network.

Producers can use connection 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.

Propagated connections don't count toward these limits.

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.

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.

Propagated connections

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Consumers that connect to your service attachment by using endpoints can enable connection propagation. Propagated connections let workloads in consumer VPC spokes access managed services in producer VPC networks as if the two VPC networks were directly connected through endpoints. Each propagated connection consumes an IP address from the service attachment's NAT subnet.

You can view the number of propagated connections that are associated with a connected endpoint when you view details for a published service. This count doesn't include propagated connections that are blocked by the producer's propagated connection limit.

Propagated connection limit

Service attachments have a propagated connection limit, which lets service producers limit how many propagated connections can be established to the service attachment from a single consumer. If unspecified, the default propagated connection limit is 250.

• If the connection preference of the service attachment is ACCEPT_MANUAL, the limit applies to each project or VPC network that is listed in the consumer accept list.
• If the connection preference is ACCEPT_AUTOMATIC, the limit applies to each project that contains a connected endpoint.

If a consumer exceeds the propagated connection limit, no further propagated connections are created. To allow the creation of more propagated endpoints, you can increase the propagated connection limit. When you increase this limit, Network Connectivity Center creates propagated connections that were blocked by the limit, as long as the new connections don't exceed the updated limit. Updating this limit does not affect existing propagated connections.

Preventing quota exhaustion

The total number of Private Service Connect endpoints and propagated connections, from any consumer, that can access your producer VPC network is controlled by the PSC ILB consumer forwarding rules per producer VPC network quota. Particularly for multi-tenant services, it's important to protect against exhausting this quota.

You can use the following limits to protect against quota exhaustion:

• Consumer accept list connection limits control the total number of Private Service Connect endpoints that can create connections to a service attachment from a single consumer VPC network or project. Lowering these limits doesn't affect existing connections. These limits don't apply to propagated connections.
• Propagated connection limits control the the total number of propagated connections that can be established to a service attachment from a single consumer. Lowering this limit doesn't affect existing propagated connections.

Example

The following example shows how propagated connection limits and consumer accept list limits work with respect to the PSC ILB consumer forwarding rules per producer VPC network quota.

Consider a case where a consumer has created two endpoints in a spoke VPC network, spoke-vpc-1. Both endpoints connect to service-attachment-1 in producer-vpc-1. The spoke is connected to a Network Connectivity Center hub that has connection propagation enabled, and there are no other spokes connected to that hub.

The service producer has configured service-attachment-1 to have a consumer accept list limit of four for each project in the accept list. The producer has configured a propagated connection limit of two, specifying that a single project can have up to two propagated connections.

This example configuration contains two endpoints and no propagated connections (click to enlarge).

The quota and limit usage for this configuration is the following:

Quota / Limit	Usage	Explanation
PSC ILB consumer forwarding rules per producer VPC network	2	one per endpoint
Service attachment consumer accept list connection limit for consumer-project-1	2	one per endpoint
Service attachment propagated connection limit for consumer-project-1	0	no propagated connections

Suppose consumer-project-1 connects another spoke named spoke-vpc-2 to the same Network Connectivity Center hub as spoke-vpc-1. This creates two propagated connections in consumer-project-1, one for each existing endpoint.

This example configuration contains two endpoints and two propagated connections (click to enlarge).

The quota and limit usage for this configuration is the following:

Quota / Limit	Usage	Explanation
PSC ILB consumer forwarding rules per producer VPC network	4	one per endpoint and one per propagated connection
Service attachment consumer accept list connection limit for consumer-project-1	2	one per endpoint
Service attachment propagated connection limit for consumer-project-1	2	one per propagated connection

Consumer-project-1 has exhausted its propagated connection limit. If the consumer adds another VPC spoke, Private Service Connect doesn't create any new propagated connections.

Suppose another consumer has two VPC spokes in consumer-project-2. The spokes connect to a Network Connectivity Center hub with propagated connections enabled. One of the VPC spokes contains a single endpoint that connects to service-attachment-1.

This example configuration contains three endpoints and three propagated connections (click to enlarge).

The quota and limit usage for this configuration is the following:

Quota / Limit	Usage	Explanation
PSC ILB consumer forwarding rules per producer VPC network	6	four from consumer-project-1 and two from consumer-project-2
Service attachment consumer accept list connection limit for consumer-project-1	2	one per endpoint in consumer-project-1
Service attachment consumer accept list connection limit for consumer-project-2	1	one per endpoint in consumer-project-2
Service attachment propagated connection limit for consumer-project-1	2	one per propagated connection in consumer-project-1
Service attachment propagated connection limit for consumer-project-2	1	one per propagated connection in consumer-project-2

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.

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).

IP version translation

For connections between Private Service Connect endpoints for published services and service attachments, the IP version of the consumer forwarding rule's IP address determines the IP version of the endpoint and traffic that egresses the endpoint. The IP version of the endpoint can be either IPv4 or IPv6, but not both. Consumers can use an IPv4 address if the address's subnet is single-stack. Consumers can use an IPv4 or IPv6 address if the address's subnet is dual-stack. Consumers can connect both IPv4 and IPv6 endpoints to the same service attachment, which can be helpful for migrating services to IPv6.

For connections between Private Service Connect endpoints for published services and service attachments, the IP version of the producer forwarding rule determines the IP version of the service attachment and traffic that egresses the service attachment. The IP version of the service attachment can be either IPv4 or IPv6, but not both. Producers can use an IPv4 address if the address's subnet is single-stack. Producers can use an IPv4 or IPv6 address if the address's subnet is dual-stack.

The IP version of the producer forwarding rule's IP address must be compatible with the stack type of the service attachment's NAT subnet. If the producer forwarding rule is IPv4, the NAT subnet can be single-stack or dual-stack. If the producer forwarding rule is IPv6, the NAT subnet must be dual-stack.

Private Service Connect doesn't support connecting an IPv4 endpoint with an IPv6 service attachment. In this case, the endpoint creation fails with the following error message:

Private Service Connect forwarding rule with an IPv4 address cannot target an IPv6 service attachment.

The following combinations are possible for supported configurations:

• IPv4 endpoint to IPv4 service attachment
• IPv6 endpoint to IPv6 service attachment

• IPv6 endpoint to IPv4 service attachment

  In this configuration, Private Service Connect automatically translates between the two IP versions.

For connections between Private Service Connect backends and service attachments, the consumer and producer forwarding rules must both use IPv4.

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 section summarizes the configuration options that are available for consumers and producers when using endpoints to access publish services.

Consumer configuration

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 before the service attachment is created	Only if global access is enabled on the load balancer before the service attachment is created	Independent of global access setting on load balancer
Interconnect traffic
Cloud VPN traffic
Automatic DNS configuration	IPv4 only	IPv4 only	IPv4 only	IPv4 only
Connection propagation	IPv4 only	IPv4 only	IPv4 only	IPv4 only
IPv4 endpoints	IPv4 producer forwarding rules	IPv4 producer forwarding rules	IPv4 producer forwarding rules	IPv4 producer forwarding rules
IPv6 endpoints	IPv4 producer forwarding rules IPv6 producer forwarding rules	IPv4 producer forwarding rules	IPv4 producer forwarding rules	IPv4 producer forwarding rules IPv6 producer forwarding rules

Producer configuration

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: Network endpoint groups (NEGs) Instance groups	GCE_VM_IP zonal NEGs Instance groups Port mapping NEGs	GCE_VM_IP_PORT zonal NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups	GCE_VM_IP_PORT zonal 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
IP version	IPv4 producer forwarding rules IPv6 producer forwarding rules	IPv4 producer forwarding rules	IPv4 producer forwarding rules	IPv4 producer forwarding rules IPv6 producer forwarding rules

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 section summarizes the configuration options that are available for consumers and producers when using backends to access publish services.

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 on supported producer load balancers.

Consumer load balancer	Protocols	IP version
Global external Application Load Balancer (supports multiple regions) Note: Classic Application Load Balancer is not supported.	HTTP HTTPS HTTP2	IPv4
Regional external Application Load Balancer	HTTP HTTPS HTTP2	IPv4
Regional internal Application Load Balancer	HTTP HTTPS HTTP2	IPv4
Cross-region internal Application Load Balancer	HTTP HTTPS HTTP2	IPv4
Regional internal proxy Network Load Balancer	TCP	IPv4
Cross-region internal proxy Network Load Balancer	TCP	IPv4
Regional external proxy Network Load Balancer	TCP	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

Producer configuration

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

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 zonal NEGs Instance groups	GCE_VM_IP_PORT zonal NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups	GCE_VM_IP_PORT zonal NEGs Hybrid NEGs Serverless NEGs Private Service Connect NEGs Instance groups
Forwarding rule protocols	TCP	HTTP HTTPS HTTP/2	TCP
Forwarding rule ports	Using a single port is recommended, see Producer port configuration	Supports a single port	Supports a single port
PROXY protocol
IP version	IPv4	IPv4	IPv4

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 before the service attachment is created.

Producer port configuration

When a consumer backend connects to a published service that's hosted on an Internal passthrough Network Load Balancer, Google Cloud chooses a port for the consumer to use. The port is chosen based on the producer's forwarding rule port configuration. Consider the following when you create the forwarding rule for the producer load balancer:

• We recommend that you specify a single port. In this configuration, the consumer backend uses the same port.

• If you specify multiple ports, the following applies:

  • If port 443 is included, the consumer backend uses port 443.
  • If port 443 is not included, the consumer backend uses the first port in the list, after the list is sorted alphabetically. For example, if you specify port 80 and port 1111, the consumer backend uses port 1111.

  • Changing which ports are used by the producer backends might result in a service interruption for consumers.

    For example, say you create a published service with a forwarding rule that uses ports 443 and 8443, and backend VMs that respond on ports 443 and 8443. When a consumer backend connects to this service, it uses port 443 for communication.

    If you change the backend VMs to only respond on port 8443, the consumer backend can no longer reach the published service.

• Don't use --port=ALL. If this configuration is used, the consumer backend uses port 1, which does not work.

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.

Viewing consumer connection information

By default, Private Service Connect translates the consumer's source IP address to an address in one of the Private Service Connect subnets in the service producer's VPC network. If you want to see the consumer's original source IP address, you can enable PROXY protocol when you publish a service. Private Service Connect supports PROXY protocol version 2.

Not all services support PROXY protocol. For more information, see Features and compatibility.

If PROXY protocol is enabled, you can get the consumer's source IP address and PSC connection ID (pscConnectionId) from the PROXY protocol header.

The format of PROXY protocol headers depends on the IP version of the consumer endpoint. If your service attachment's load balancer has an IPv6 address, consumers can connect with both IPv4 and IPv6 addresses. Configure your application to receive and read PROXY protocol headers for the IP version of traffic that it is to receive.

For consumer traffic that flows through a propagated connection, the consumer's source IP address and PSC connection ID refer to the Private Service Connect endpoint that is propagated.

When you enable PROXY protocol for a service attachment, the change applies to new connections only. Existing connections don't include the PROXY protocol header.

If you enable PROXY protocol, check the documentation for your backend web server software for information about parsing and processing incoming PROXY protocol headers in the client connection TCP payloads. If PROXY protocol is enabled on the service attachment, but the backend web server is not configured to process PROXY protocol headers, web requests might be malformed. If requests are malformed, the server can't interpret the request.

Important: Enabling PROXY protocol is not a substitute for application-layer security protocols and does not replace standard encryption and authentication mechanisms, for example, end-to-end protocols like TLS.

The Private Service Connect connection ID (pscConnectionId) is encoded in the PROXY protocol header in Type-Length-Value (TLV) format.

Field	Field length	Field value
Type	1 byte	0xE0 (PP2_TYPE_GCP)
Length	2 bytes	0x8 (8 bytes)
Value	8 bytes	The 8-byte pscConnectionId in network order

You can view the 8-byte pscConnectionId value from the consumer forwarding rule or the producer service attachment.

The pscConnectionId value is globally unique for all active connections at a given point in time. However, over time, a pscConnectionId might be reused in these scenarios:

• Within a given VPC network, if you delete an endpoint (forwarding rule), and create a new endpoint using the same IP address, the same pscConnectionId value might be used.

• If you delete a VPC network that contains endpoints (forwarding rules), after a seven day waiting period, the pscConnectionId value that was used for those endpoints might be used for a different endpoint in another VPC network.

You can use pscConnectionId values for debugging and to trace the sources of packets.

A separate 16-byte Private Service Connect service attachment ID (pscServiceAttachmentId) ID is available from the producer service attachment. The pscServiceAttachmentId value is a globally unique ID that identifies a Private Service Connect service attachment. You can use the pscServiceAttachmentId value for visibility and debugging. This value is not included in the PROXY protocol header.

Pricing

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

Quotas

The total number of Private Service Connect endpoints and propagated connections, from any consumer, that can access your producer VPC network is controlled by the PSC ILB consumer forwarding rules per producer VPC network quota.

Endpoints contribute to this quota until they are deleted, even if the associated service attachment is deleted or configured to reject the connection. Propagated connections contribute to this quota until the associated endpoint is deleted, even if connection propagation is disabled on the Network Connectivity Center hub or the propagated connection's spoke is deleted.

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 don't 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.

For issues and workarounds, see Known issues.