Articles

What Is a VPC Endpoint?

A VPC endpoint gives a private network direct access to a cloud service without routing traffic through the public internet or a NAT gateway.

Chisato Chisato · · 5 min read
Abstract blue network mesh

A VPC endpoint is a private connection between a virtual private cloud and a supported cloud service that keeps traffic entirely inside the cloud provider’s network, instead of routing it out through an internet gateway or NAT gateway and back in. Resources inside the VPC can reach the service using private IP addresses, without the service ever being exposed to, or reached over, the public internet.

The motivation is straightforward: a lot of traffic that looks like it needs to leave your private network — calls to an object storage service, a managed database, or another provider-hosted service — doesn’t actually need to touch the internet at all. It just needs a path to a service the cloud provider runs on the same underlying network. A VPC endpoint is that path.

Why not just use a NAT gateway?

Without a VPC endpoint, an instance in a private subnet that needs to reach an external cloud service typically routes through a NAT gateway and an internet gateway, then back into the provider’s network to reach the service, even though the request never actually needed to touch the public internet. This works, but it has real costs:

  • Security surface. Traffic transits infrastructure designed for general internet egress, and the request technically leaves the private network boundary, which complicates network-based compliance arguments even if the traffic never reaches a public destination.
  • NAT gateway cost and throughput limits. NAT gateways typically charge per gigabyte processed and have bandwidth ceilings; high-volume traffic to a frequently used service can become a meaningful and avoidable cost line.
  • Latency. An extra hop through a NAT gateway and internet gateway adds latency compared to a direct private path, though usually a small amount.

A VPC endpoint removes the NAT gateway and internet gateway from the path entirely for the specific service it targets, addressing all three points for that traffic.

Two kinds of endpoints

Most cloud providers that offer VPC endpoints split them into two categories, though the exact naming varies by provider:

Gateway endpoints work by adding a target to your subnet’s route table. When traffic destined for the supported service matches that route, it’s directed to the endpoint instead of to a NAT gateway or internet gateway. Gateway endpoints are typically limited to a small number of foundational services — usually object storage and a managed key-value or document database — and are free to use in most providers, since they’re implemented as a routing rule rather than a running network appliance.

Interface endpoints work differently: they provision an actual network interface, with a private IP address, inside your subnet. Traffic to the service is sent directly to that private IP, using DNS resolution that’s typically overridden so that the service’s normal public hostname resolves to the private interface address instead. Interface endpoints support a much broader range of services — messaging queues, secrets managers, container registries, and most other managed services — but they run as billed resources and usually charge both an hourly rate and a per-gigabyte data processing fee.

Gateway endpointInterface endpoint
MechanismRoute table entryPrivate network interface (ENI) with a private IP
Service coverageA small set of foundational servicesMost managed services
CostUsually freeHourly charge plus data processing fee
DNS behaviorUses existing service DNS via routingTypically requires private DNS resolution override
ScopePer VPC route tablePer subnet, per availability zone

How the private connection actually works

The specific underlying technology differs by provider, but the pattern is the same: the endpoint creates a private path that terminates inside the provider’s own network fabric rather than traversing the public internet, using a mechanism conceptually similar to what’s often marketed as “private link” style connectivity. From the perspective of a resource inside the VPC, this is functionally close to VPC peering in that it enables private cross-network communication, but the models differ: peering connects two customer VPCs to each other directly, while an endpoint connects your VPC to a specific service, without your traffic entering that service’s own VPC (if it even has one) or requiring any peering relationship to be established.

Where endpoints fit in a network design

VPC endpoints are especially relevant in security-conscious architectures where private subnets are intentionally denied a route to the internet at all — no NAT gateway, no internet gateway. In that design, any service reachable only over the public internet becomes unreachable from those subnets by default, and VPC endpoints are the mechanism for punching a specific, auditable hole for exactly the services that are actually needed, without opening general internet access. This pairs naturally with the private-subnet layout described in cloud landing zone designs, where a baseline network template deliberately limits what private workloads can reach outside their own VPC.

Because interface endpoints are provisioned per subnet within a specific availability zone, a multi-AZ deployment typically needs an interface endpoint in each zone it uses, to avoid cross-zone data transfer charges and to keep the private path available if one zone has an issue. This is a smaller-scale version of the same redundancy thinking that goes into placing a load balancer across multiple zones — private connectivity needs to be resilient in the same way public-facing infrastructure does.

The takeaway

A VPC endpoint lets resources in a private network reach a specific cloud service over a private path, instead of routing through a NAT gateway and the public internet. Gateway endpoints handle a small set of foundational services for free via routing rules; interface endpoints cover a much broader range of services by provisioning a billed private network interface with its own DNS behavior. Either way, the result is the same: traffic to that service never has to leave the provider’s private network, which tightens the security boundary and often cuts NAT gateway costs for anything that talks to that service frequently.

The Lycoris Team The Lycoris Team · · 4 min read

Network Ingress vs. Egress: What's the Difference?

Ingress is traffic entering a network or system; egress is traffic leaving it. The distinction shapes firewall rules, cloud billing, and security posture.

#Cloud #Networking #DevOps
Chisato Chisato · · 4 min read

IPv4 vs IPv6: What's Actually Different

IPv4's 32-bit address space is exhausted; IPv6 fixes that with 128-bit addresses plus routing and header changes. Here's what differs in practice.

#Networking #Cloud #Security
Chisato Chisato · · 4 min read

CIDR Notation and Subnetting, Explained

CIDR notation like 10.0.0.0/24 packs an IP range and its mask into one string. How prefix length maps to host count, and how subnetting splits a network.

#Networking #Cloud #Security