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:SourceVpceoraws: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:CreateVpcEndpointto 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/actionon the target resource. Network Contributor includes it throughMicrosoft.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:SourceIpin requests that arrive through a VPC endpoint; useaws:VpcSourceIpor 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:SourceVpcedeny 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:SourceIpallow 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:SourceVpcoraws:VpceOrgID, and no policy still depends onaws:SourceIpfor 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.
Standards and references
- AWS: AWS PrivateLink concepts
- AWS: Control access to VPC endpoints using endpoint policies
- AWS: IAM global condition context keys
- Microsoft Learn: What is a private endpoint?
- Microsoft Learn: What is Azure Private Link service?
- Google Cloud: Private Service Connect
- Google Cloud: Manage access to published services
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Cloud Network Security Guide · Cloud Data Perimeter Guide · Amazon VPC Security Guide · VPC Service Controls Guide · DNS Security Guide