Cloud Networking
Advanced 15 min read Cloud Networking

Private Link and Endpoints

Private access to cloud services — without the internet

Private Link (AWS) / Private Endpoint (Azure) / Private Service Connect (GCP) expose cloud services over private IPs so traffic never leaves the provider backbone. Big security and egress wins, with real design trade-offs.

Private Linkprivate endpointPrivate Service ConnectVPC endpointegressbackbone
Prerequisites: Route Tables and Gateways Security Groups and NACLs
Before we start

What you will learn

  • Explain endpoint types (gateway vs interface)
  • Use Private Link/Endpoint/Service Connect for PaaS and your own services
  • Appreciate the DNS and trust-model trade-offs
In 60 seconds

Gateway endpoints (S3/DynamoDB) are route-table-based. Interface/private endpoints (PrivateLink family) place a private IP in your VPC for a service (RDS, Lambda, your own app). All keep traffic on the backbone.

Introduction

What is this?

AWS: gateway VPC endpoints (free, S3/DynamoDB via route), interface endpoints (private IP + Private DNS), VPC Endpoint Services to expose your own ALB/NLB privately (PrivateLink). Azure: Private Endpoint attaches a private NIC to PaaS (SQL, Storage, App Service) with DNS; Azure Private Link both consumes and publishes. GCP: Private Service Connect (PSC) attaches private endpoints to Google-managed services and your published backends. All achieve: traffic stays inside the provider network, public exposure optional, and you control which VPCs/principals may use it.

Motivation

Why do you need it?

  • Keeping traffic on the backbone is a security, egress and compliance win.
  • Removes the need for NAT egress on high-volume PaaS paths.
  • Lets you offer a SaaS service privately to partner VPCs (PrivateLink/PSC).
  • Audits love it: no public internet in the path.
Think about it

Mental model

Imagine

A private corridor inside a mall

Think of

Private Link

Instead of leaving the mall and walking down the public street (internet) to reach a store, you walk the inside corridor (backbone) directly. Same store, private route, no external exposure.

Mechanics

How it works

  • AWS gateway endpoint: add a route to the endpoint; VPC resolves the service via prefix list; only works from VPCs with the endpoint.
  • AWS interface endpoint / PrivateLink: service (NLB) exposes; consumer creates an interface endpoint; DNS resolution points at the private IP.
  • Azure Private Endpoint: private NIC + integration with private DNS zone; traffic travels via Microsoft backbone.
  • GCP PSC: consumer subnetwork + published service; IP-based access to service attachments.
  • Every flavor encrypts at the transport layer and requires IAM/policy at both ends.

Private Link access path.

Consumer VPC
Interface endpoint
Provider backbone
Service (NLB/ALB owner)
IAM/policies
Real world

In production

  • A fintech routes RDS and S3 access through endpoints/PrivateLink so no traffic egresses.
  • A SaaS publisher exposes its API via VPC Endpoint Service for a handful of partner VPCs.
  • Microsoft-shop: multi-tier apps talk to Azure SQL and Storage via private endpoints with a private DNS zone.
Guidelines

Best practices

  • Prefer endpoints for S3/DynamoDB control-plane and data-plane high-volume access.
  • Use Private DNS so applications don't hardcode public names.
  • Snowflake of overlap: only assign endpoints where the service is genuinely consumed.
  • Combine with security groups to restrict which instances may use an interface endpoint.
Watch out

Common mistakes

  • Endpoint-only for public services that also need internet clients (split-brain DNS).
  • Forgetting to create the endpoint in all consuming subnets/AZs.
  • No private DNS → app resolves the public endpoint and the private path is bypassed.
  • Paying interface-endpoint hourly cost for services accessed rarely — consider gateway or NAT.
Root cause analysis

Common issues

Error
Traffic still egresses via NAT despite an endpoint
Root cause

App uses the public DNS name or wrong region endpoint

Fix

Point the app at the endpoint-specific DNS/private name and confirm resolution.

Error
Endpoint fails with 'Not authorized'
Root cause

Service policy excludes your principal or VPC

Fix

Add the principal/VPC to the service policy and verify the IAM permission set.

Error
PrivateLink consumer sees timeout
Root cause

Service NLB not accepting the VPC's principal, or SG mismatch

Fix

Verify the endpoint is active, NLBs accept, and SGs allow the consumer CIDR.

When things break

Debugging tips

  • Route detective: check the endpoint's prefix list vs the app's destination.
  • DNS: nslookup the service name in the VPC — does it resolve to the private IP?
  • Policies: look for resource policies on the service side denying your principal.
  • If internal traffic egresses anyway, your app probably uses a public endpoint name.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

What distinguishes an interface (PrivateLink) endpoint from a gateway endpoint?

Go deeper

Official documentation

AWS — VPC endpoints / PrivateLink
docs
Azure — Private Link / Private Endpoint
docs
GCP — Private Service Connect
docs