---
title: Differentiating AWS PrivateLink, Transit Gateway, and Private Endpoints for Secure Private Connectivity in Cloud Environments
created: 2026-04-01
updated: 2026-04-01
type: summary
tags: ["aws", "connectivity", "networking", "notes", "telegram"]
external: http://go/ui/posts/2316/
---

These three are often confused because they all enable private connectivity within AWS, but they solve different problems at different scopes.

## PrivateLink vs Transit Gateway vs Private Endpoints

### AWS PrivateLink
Exposes a **specific service** from one VPC to consumers in another VPC (or on-prem), without peering or routing between the VPCs. Traffic never leaves the AWS backbone.

- **Model:** Service provider → NLB → PrivateLink endpoint service → Interface endpoint (ENI) in consumer VPC
- **Direction:** One-way service exposure (not full network connectivity)
- **Scope:** Single service/port, not whole-VPC access
- **Use case:** "I want VPC-B to call my payment API in VPC-A, without VPC-B having any other access to VPC-A"
- **Cost:** Per-hour + per-GB data processing

### VPC Private Endpoints (Interface & Gateway)
These *are* PrivateLink under the hood (for Interface endpoints), or route-table tricks (for Gateway endpoints). The term "private endpoint" usually means:

| Type | Services | Mechanism |
|---|---|---|
| **Interface endpoint** | Most AWS services (SSM, Secrets Manager, ECR, STS, etc.) | ENI in your subnet via PrivateLink |
| **Gateway endpoint** | S3 and DynamoDB only | Route table entry, no ENI, free |

- **Use case:** "My EKS pods need to reach ECR or Secrets Manager without going over the public internet"
- This is really just *PrivateLink pointed at AWS-managed services* rather than your own services

### Transit Gateway (TGW)
A **regional network hub** that connects multiple VPCs (and VPNs/Direct Connect) together with full IP routing between them.

- **Model:** Hub-and-spoke router — attach VPCs, on-prem connections, and route between them
- **Direction:** Full bidirectional routing (like having a managed router in the middle)
- **Scope:** Whole VPC CIDR ranges, all ports/protocols
- **Use case:** "I have 20 VPCs across accounts and they all need to talk to each other and to on-prem"
- **Cost:** Per attachment-hour + per-GB

---

## Key Mental Model

| | PrivateLink | Private Endpoint | Transit Gateway |
|---|---|---|---|
| **Abstraction** | Service exposure | Service access | Network routing |
| **Granularity** | One service/NLB | One AWS service | Entire VPC |
| **Bidirectional?** | No | No | Yes |
| **Cross-account?** | Yes | Yes (AWS services) | Yes |
| **Overlapping CIDRs OK?** | ✅ Yes | ✅ Yes | ❌ No |
| **Scales to many VPCs?** | Complex | N/A | ✅ Built for it |

---

## How They Compose in Practice

In a real EKS setup like yours, you'd typically use **all three**:

- **TGW** — connects your EKS VPC to your RDS VPC (or on-prem)
- **Interface endpoints** — so pods can reach ECR, SSM, Secrets Manager privately
- **PrivateLink** — if you're exposing an internal service (e.g. a platform API) to other teams' VPCs without full peering

The critical gotcha: TGW requires non-overlapping CIDRs across all attached VPCs. PrivateLink sidesteps this entirely since it's service-level, not network-level.
