Cloud Private Connectivity: PrivateLink, Private Endpoints

Private connectivity is often treated as a security control in itself, yet a private endpoint only changes the path traffic takes: it does not close the public endpoint, it does not limit which identities can use it, and it can open a private path into your network for whoever is allowed to connect. This guide compares the three main provider implementations, AWS PrivateLink, Azure Private Link (private endpoints and Private Link service) and Google Cloud Private Service Connect, and explains how to secure both sides: the consumer who creates an endpoint and the producer who publishes a service. It covers acceptance and allow lists, endpoint policies and identity condition keys, private DNS, logging and the common mistakes. It is for cloud network architects, platform teams publishing internal or SaaS services, and security reviewers. Provider-specific network design is in the Azure Virtual Network Security Guide and the Google Cloud VPC and Cloud NGFW Security Guide.

Key takeaways

Private path is not private access. Azure states that a private endpoint does not restrict public access by itself; on every provider, disable the public endpoint or deny requests that do not arrive through your endpoints.
Consumers start every connection. In all three models the consumer creates the endpoint and the producer accepts it; a producer has no route back into the consumer network, except with Private Service Connect interfaces, which are bidirectional.
Default acceptance is too open. Use manual acceptance or explicit accept lists, never "anyone with the alias" or a * allowed principal, for services that hold data.
Endpoint policies are a second filter, not a replacement. The AWS default endpoint policy allows all principals and actions; tighten it and pair it with resource policies keyed on aws:SourceVpce or aws:VpceOrgID.
DNS decides whether it works. Each provider relies on private DNS overriding the public name; broken DNS sends clients to the public endpoint or breaks them, and someone then "fixes" it by re-enabling public access.

How identity and access work in private connectivity

Private connectivity services share one pattern. A producer puts a service behind a load balancer (or exposes a provider API), publishes it under a name, and decides which consumers may connect. A consumer creates an endpoint, a network interface or forwarding rule with a private IP in its own network, and points DNS at it. Three separate decisions protect the data: which consumers can connect (provider-level acceptance), which identities can use the endpoint (endpoint policy and resource policy), and whether the service is still reachable some other way (public access).

Provider comparison

Aspect	AWS PrivateLink	Azure Private Link	Google Cloud Private Service Connect
Consumer object	Interface, resource, service network or Gateway Load Balancer endpoint	Private endpoint (a NIC in a subnet)	Endpoint (forwarding rule) or backend (NEG behind a load balancer)
Producer object	Endpoint service behind a Network Load Balancer or Gateway Load Balancer; resource configuration for direct resources	Private Link service behind a Standard Load Balancer	Service attachment targeting a producer load balancer
Provider APIs	Interface endpoints for AWS services; gateway endpoints for S3 and DynamoDB (not PrivateLink)	Private endpoints to PaaS subresources such as blob or vault	Endpoints for Google APIs (bundle or regional)
Who may connect	Allowed principals list; service unavailable to anyone by default	Visibility: RBAC only, restricted by subscription, or anyone with alias	Connection preference automatic or explicit with accept and reject lists
Approval	Acceptance required on or off; manual starts in PendingAcceptance	Auto-approval subscription list; others Pending	Explicit acceptance recommended; lists by project, network or endpoint
Consumer identity at the producer	Endpoint ID and owning account	PROXY protocol v2 LinkID (TLV type 0xEE)	PROXY protocol v2 pscConnectionId (TLV type 0xE0)
Identity filter on the endpoint	VPC endpoint policy (IAM resource policy)	None on the endpoint; target service RBAC and firewall	None on the endpoint; IAM and VPC Service Controls
DNS	Private DNS on the endpoint or private hosted zones (split horizon)	privatelink.* private DNS zones	Automatic Cloud DNS records when the attachment sets a DNS domain

Private connectivity versus peering

Private Service Connect exposes only the service IP to the consumer, not the whole producer network, which is the main reason to prefer endpoint-style connectivity over VPC or VNet peering for cross-organisation services. Peering joins routing domains and relies entirely on firewall rules for isolation; endpoints expose a single service and keep address spaces independent, so overlapping CIDRs are not a problem. Use peering for networks you own and trust equally, and private endpoints for anything shared with another team, business unit, customer or vendor. See the Network Segmentation Guide.

Admin roles and privileged access

Two sets of permissions matter: who can create endpoints (a new path out of or into a network) and who can accept connections or change allow lists on a published service (a new path into your service).

AWS: restrict ec2:CreateVpcEndpoint to network teams through SCPs, and restrict changes to endpoint service permissions and acceptance (ModifyVpcEndpointServicePermissions, AcceptVpcEndpointConnections) to the service owner. Removing a principal from the allowed list does not disconnect connections already accepted: reject them explicitly. See the AWS Organizations and SCPs Guide.
Azure: connections auto-approve only when the requester holds privateEndpointConnectionsApproval/action on the target resource. Network Contributor includes it through Microsoft.Network/* on network resources, and Owner or Contributor on a PaaS resource can approve. Keep approval on sensitive resources with the data owner. For a Private Link service, visibility "anyone with your alias" lets any subscription request a connection.
Google Cloud: creating endpoints and editing service attachments are compute network permissions held by Network Admin roles. Accept lists match VPC networks by name, so a network deleted and recreated with the same name in an accepted project is accepted again; prefer project-level entries you control or review the list after network changes.
Private DNS administrators: whoever can edit the private zone or hosted zone can redirect a service name to a different endpoint. Treat zone write access as privileged and log changes.

Integrations, API tokens and service accounts

Most private endpoint traffic is machine to machine: workloads calling provider APIs, vendor SaaS connectors and internal APIs. The endpoint is where you can bind those non-human identities to a network path.

Identity-aware conditions by provider

Goal	AWS	Azure	Google Cloud
Only accept requests that came through my endpoints	Resource policy deny unless `aws:SourceVpce` or `aws:SourceVpc` matches	Public network access Disabled on the resource	VPC Service Controls perimeter with the consumer network inside it
Only endpoints owned by my organisation	`aws:VpceOrgID` or `aws:VpceAccount` (supported services only)	Manual approval; reject unknown subscriptions	Explicit accept list of projects
Only my identities may use my endpoint	Endpoint policy with `aws:PrincipalOrgID` or `aws:PrincipalArn`	Entra ID RBAC on the target; no endpoint policy	IAM on the API; restricted.googleapis.com for VPC SC services
Identify the consumer at the producer	Endpoint ID in the connection	PROXY v2 LinkID matched to linkIdentifier	PROXY v2 pscConnectionId

Source IP conditions stop working: AWS does not include aws:SourceIp in requests that arrive through a VPC endpoint; use aws:VpcSourceIp or the endpoint keys instead. A policy built only on public IP ranges silently stops matching after you add endpoints.
Exfiltration through your own endpoint: an interface endpoint for S3 with the default policy lets a compromised workload write to any bucket in any account, including the attacker's. Restrict the endpoint policy to your organisation's resources. The same applies to Azure service endpoints without service endpoint policies (MITRE ATT&CK T1567, Exfiltration Over Web Service).
Vendor connectors: a SaaS vendor reaching your database over PrivateLink still authenticates with a credential you issued. Private connectivity reduces exposure of that credential; it does not reduce what the credential can do. Scope and rotate it. See the Third-Party Access Guide.
PROXY protocol is not authentication: Google states that PROXY protocol is not a substitute for TLS or application-layer security. Use the connection ID for tenant mapping and logging, and keep mutual TLS or token authentication in the application.
Workload credentials: combine private endpoints with role-based, short-lived credentials (instance roles, managed identities, attached service accounts) so a stolen static key used from outside fails the endpoint condition. See the AWS Resource Control Policies and Data Perimeter Guide.

Logging and detection

Event	Where to find it	Why it matters
Endpoint created in a workload account	AWS CloudTrail `CreateVpcEndpoint`; Azure Activity Log on private endpoints; Google Cloud Admin Activity audit log on forwarding rules	New path to an external or unknown service
Connection accepted on a published service	CloudTrail `AcceptVpcEndpointConnections`; Activity Log on the Private Link service; service attachment connection status	New consumer inside your service
Allowed principals or accept list changed	CloudTrail `ModifyVpcEndpointServicePermissions`; Activity Log; Admin Activity log on service attachments	Widens who can connect
Endpoint policy changed to full access	CloudTrail `ModifyVpcEndpoint` with PolicyDocument	Reopens exfiltration through the endpoint
Public access re-enabled on a PaaS resource	Azure Activity Log; AWS bucket policy changes; Google Cloud perimeter changes	Undoes the private-only design
Private DNS record or zone changed	Route 53, Azure Private DNS and Cloud DNS change logs	Redirects clients
Data plane calls without the expected endpoint	CloudTrail data events (vpcEndpointId field), storage logs, VPC SC violation logs	Credentials used from outside the network (T1078.004)

Configure AWS endpoint service connection notifications so service owners are told about accepted and rejected requests. Endpoint traffic appears in the consumer's flow logs as traffic to the endpoint IP; Azure NSG flow logs do not capture inbound traffic to a private endpoint, so use virtual network flow logs there. See the Cloud Logging and Audit Trail Guide.

Metrics

Private-only coverage: share of sensitive data stores reachable only through endpoints (public access disabled or denied by policy).
Open endpoint policies: AWS interface and gateway endpoints still using the default full-access policy. Target zero for S3, KMS and STS.
Open published services: endpoint services with * principals, Azure services visible to anyone with the alias, or PSC attachments set to automatic acceptance.
Unreviewed consumers: accepted connections with no recorded owner or business purpose.
DNS health: failed resolutions or public-IP answers for privatelink names from internal resolvers.

Hardening baseline

Consumer side

Inventory endpoints: list every endpoint, target service, owning account and policy across all accounts, subscriptions and projects.
Centralise shared endpoints: host provider API endpoints in a shared services network and share DNS, rather than letting every account create its own with default policies.
Tighten policies in audit first: for AWS, add endpoint policy conditions while watching CloudTrail for denied calls (look for errors with the endpoint ID); for resource policies, start with a Deny scoped to one non-production bucket or key.
Fix DNS before cutting public access: confirm every client, including on-premises resolvers forwarding privatelink zones, resolves the service name to the private IP.
Close the public path: set public access to Disabled (Azure), add aws:SourceVpce deny statements or an RCP (AWS), and enforce VPC Service Controls with restricted.googleapis.com (Google Cloud).
Roll back: keep policies in infrastructure as code; rollback is removing the deny statement or re-enabling public access for the one resource, which takes minutes. Record every rollback as an exception with an end date.

Producer side

Require acceptance: AWS acceptance required on, Azure visibility restricted by subscription with a short auto-approval list, Google Cloud explicit acceptance with project-level accept lists.
Name allowed principals precisely: AWS allowed principals as specific account or role ARNs, never *.
Verify private DNS names: AWS requires domain ownership verification before consumers can use a provider's private DNS name; keep the verification record in place.
Limit per-consumer capacity: PSC connection limits per accept-list entry and NAT IP sizing stop one consumer exhausting capacity.
Parse consumer identity: enable PROXY protocol v2 where you need per-tenant authorisation or logging, and make sure backends and health probes handle it.
Reject on offboarding: when a customer or partner leaves, reject the connection; on AWS, removing permissions alone does not drop accepted endpoints.

Decision guidance

Small organisations with one provider can start with provider API endpoints for the few services that hold sensitive data (object storage, key management, secrets) and disable public access on those. Large estates benefit from a hub or shared services network that owns endpoints and private DNS, organisation-wide identity conditions (aws:VpceOrgID, VPC Service Controls) and a central catalogue of published services with named owners. Choose PrivateLink or Private Service Connect over peering for any cross-tenant or vendor connection; choose peering only inside one trust domain. For multi-cloud links, private endpoints do not span providers: you still need VPN or interconnect between clouds, with endpoints at each end.

Framework mapping

Control	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022
Private endpoints, public access disabled	SC-7, SC-7(5), AC-4	PR.IR-01	12	A.8.20, A.8.22
Acceptance, allow lists, endpoint policies	AC-4, AC-6	PR.AA-05	6	A.8.3
Private DNS integrity	SC-20, SC-21	PR.PS-01	9	A.8.21
Endpoint and connection logging	AU-12, SI-4	DE.CM-01	8, 13	A.8.15, A.8.16

Common misconfigurations

Endpoint added, public endpoint untouched: the design diagram shows private access, but the storage account, bucket or database still accepts internet requests with a valid credential.
Default endpoint policy: the AWS default allows every principal and action, so the endpoint becomes an unmonitored exfiltration route to any account's buckets.
Published service open to everyone: * allowed principals, "anyone with your alias" or automatic acceptance on a service that fronts customer data.
IP-based policies left in place: aws:SourceIp allow statements no longer match endpoint traffic, so teams widen them or remove them during troubleshooting.
One private DNS zone for several services: in Azure, linking one zone to private endpoints of different services can delete records and break resolution; on every provider, on-premises resolvers that do not forward privatelink names send clients to public IPs.
Stale consumers: partners or former customers still connected because nobody rejected the connection when the contract ended.

Practitioner checklist

Every sensitive data store reachable through an endpoint also has its public path disabled or denied by policy.
AWS endpoint policies for S3, KMS, STS and Secrets Manager restrict principals and resources to your organisation.
Resource policies or RCPs use aws:SourceVpce, aws:SourceVpc or aws:VpceOrgID, and no policy still depends on aws:SourceIp for endpoint traffic.
Published services require acceptance and list allowed consumers explicitly, with a named owner per consumer.
Endpoint creation and acceptance permissions are restricted to network and service owners, with SCPs or equivalent guardrails.
Private DNS zones are centralised, one per service, and hybrid forwarding is tested from on-premises.
Alerts exist for endpoint creation, acceptance, allow list changes, endpoint policy changes and public access re-enabled.
Offboarding a partner or customer includes rejecting their endpoint connections.

Cloud Private Connectivity Guide: PrivateLink, Private Endpoints and Private Service Connect