VPC endpoints and private connectivity

When your application in a private subnet talks to an AWS service — reads from S3, pulls an image from ECR, fetches a secret from Secrets Manager — where does that traffic go? By default, out through the NAT gateway and across the public internet to the service's public endpoint. VPC endpoints change that: they let your private resources reach AWS services privately, without the traffic ever leaving the AWS network. This improves security and cuts NAT cost — a rare win on both. This lesson is VPC endpoints and private connectivity.

The problem: private resources still use the public internet for AWS services

AWS services like S3, ECR, DynamoDB, Secrets Manager and CloudWatch have public endpoints. When a server in a private subnet calls one, the request goes: private subnet → NAT gateway → internet gateway → across the public internet → the service. It works, but it has two downsides:

It uses the public internet for what is really internal AWS-to-AWS traffic — a larger exposure than necessary, and it means your private resources depend on internet routing to reach core services.
It costs NAT money. Every byte to those services flows through the NAT gateway and incurs its per-GB data-processing charge (the gateways lesson). Pulling large container images from ECR, or writing lots of data to S3, through NAT, adds up.

VPC endpoints remove both problems by giving you a private path to AWS services.

VPC endpoints: a private door to AWS services

A VPC endpoint connects your VPC directly to an AWS service over AWS's own private network, so traffic to that service never touches the public internet or the NAT gateway. There are two kinds:

Gateway endpoints — for S3 and DynamoDB only. You add a route-table entry that sends traffic for the service through the gateway endpoint. They are free, and there is essentially no reason not to use them — an S3 gateway endpoint is a standard part of any VPC, keeping all S3 traffic private and off the NAT gateway.
Interface endpoints (AWS PrivateLink) — for most other services (ECR, Secrets Manager, CloudWatch, SSM, and many more). They create a private network interface inside your subnet with a private IP, and your resources reach the service through it. Interface endpoints have an hourly and per-GB charge (usually far less than the NAT data cost they replace for heavy traffic), so you add them for the services you use most.

With endpoints in place, a private EKS node pulling an image from ECR, or an app reading a secret from Secrets Manager, does so over a private path — no internet, no NAT charge for that traffic. For AWS-service-heavy workloads (which is most of them), this is a meaningful security and cost improvement, and it is why the gateways lesson pointed at endpoints as the way to keep AWS traffic off NAT.

When to use which

A practical policy:

Always add the S3 (and DynamoDB, if used) gateway endpoint — it is free and there is no downside.
Add interface endpoints for the AWS services your workloads call frequently — commonly ECR (image pulls), Secrets Manager / Parameter Store (config and secrets), CloudWatch (logs and metrics), and SSM (Session Manager access). Weigh their small hourly cost against the NAT data cost they remove and the security benefit; for anything with real volume, they pay off.
You do not need an endpoint for every service — for occasional calls to a rarely-used service, going via NAT is fine. Endpoints are for the services on your hot path.

The design goal is that your private workloads reach the AWS services they depend on privately, keeping that traffic inside AWS and off both the public internet and the NAT gateway — tighter security and a smaller bill.

VPC peering and PrivateLink between VPCs, briefly

Two related private-connectivity tools you should recognise, for connecting your own networks:

VPC peering — a direct private connection between two VPCs, so resources in each can reach the other by private IP (this is why the vpc-design lesson insisted on non-overlapping CIDRs — you cannot peer VPCs with overlapping ranges). Useful for connecting, say, a shared-services VPC to workload VPCs. It does not scale elegantly to many VPCs (peering is one-to-one), where a Transit Gateway (a hub connecting many VPCs and on-premises networks) is the answer.
AWS PrivateLink — the same technology as interface endpoints, used to expose your own service in one VPC privately to another VPC (or another account), without peering the whole networks. Good for offering an internal service to other teams securely.

For a foundation, the key idea is: AWS gives you several ways to connect networks privately — endpoints (to AWS services), peering / Transit Gateway (between your VPCs), and PrivateLink (to expose a service) — so that traffic between your resources and services stays on private paths rather than the public internet. Choosing private connectivity by default is both a security posture and, given NAT and data-transfer costs, often a cheaper one.

Check your work

The problem: private resources calling AWS services (S3, ECR, Secrets Manager) go via NAT → internet by default — uses the public internet for internal traffic, and incurs NAT per-GB charges (heavy on image pulls / S3).

VPC endpoints give a private path to AWS services (traffic never leaves AWS, bypasses NAT): gateway endpoints (S3 + DynamoDB only, free, via a route entry — always add the S3 one) and interface endpoints / PrivateLink (most other services — a private ENI in your subnet; small hourly+GB cost, usually less than the NAT cost they replace). Add interface endpoints for hot-path services (ECR, Secrets Manager, CloudWatch, SSM).

Policy: always add free S3/DynamoDB gateway endpoints; add interface endpoints for frequently-called services; skip endpoints for rarely-used ones (NAT is fine). Goal: private workloads reach AWS services privately — off the internet and off NAT.

Between your networks: VPC peering (private link between two VPCs by private IP — needs non-overlapping CIDRs; one-to-one, use Transit Gateway as a hub for many), PrivateLink (expose your own service to another VPC/account privately). Prefer private connectivity by default — better security, often cheaper.

Practice

Trace how a private server's call to S3 travels by default, and the two downsides (internet + NAT cost).
Explain the difference between gateway and interface VPC endpoints, and which services each covers.
Explain why the free S3 gateway endpoint should be in every VPC.
Decide which interface endpoints to add for a workload that pulls ECR images and reads Secrets Manager, and justify the cost trade-off.
Explain why VPC peering requires non-overlapping CIDRs, connecting it to the VPC-design lesson.
Explain when you would reach for a Transit Gateway instead of VPC peering.

Official documentation

AWS — VPC endpoints — Gateway and interface endpoints (PrivateLink).
AWS — Gateway endpoints for S3 — The free S3/DynamoDB endpoint.
AWS — VPC peering — Private connectivity between VPCs.

Next: site-to-site VPN and hybrid connectivity patterns.