VPC Endpoint

What VPC Endpoint is

A VPC endpoint gives resources inside your VPC a private path to a supported AWS service, so the traffic never touches the public internet, an internet gateway, or a NAT gateway. There are two forms. An interface endpoint is an elastic network interface with a private IP placed in your subnet, powered by AWS PrivateLink, and it covers most services. A gateway endpoint is a target you add to a subnet’s route table — available for S3 and DynamoDB only, not PrivateLink, and free.

Design Beaver models a VPC endpoint as a VPC-resident resource that lives inside a subnet, and validates as you draw which services it can front and how each connection has to be set up to be correct.

When to use VPC Endpoint (and when not to)

Reach for a VPC endpoint when a private subnet needs to reach a specific set of AWS services and you want that traffic to stay on the AWS backbone rather than route out through a NAT gateway. It’s the right tool for removing a NAT gateway’s per-GB data-processing cost on high-volume S3 or DynamoDB traffic — use a gateway endpoint there. It’s also the answer when security or compliance requires access to a given service over a private IP that never traverses the public internet.

Don’t reach for it when the resource needs general outbound access to arbitrary external hosts — that’s a NAT gateway, and an endpoint only reaches the service it fronts. It’s also the wrong choice when the target service offers neither a gateway endpoint nor an interface endpoint, since not every AWS service has one. And for very low-volume access where a shared NAT gateway already exists, a single interface endpoint’s per-AZ hourly cost may not be worth it.

Variants: gateway vs. interface

The gateway-vs-interface choice is the defining decision here, and it’s the one Design Beaver’s private-subnet-egress rule reads. The short version: for in-VPC access to S3 or DynamoDB use the free gateway endpoint; everything else — and cross-network S3 or DynamoDB access — uses an interface endpoint.

VPC Endpoint pricing

The two forms sit at opposite ends of the cost picture: gateway endpoints are free, and interface endpoints bill per AZ-hour plus per GB processed. That’s why the endpoint type you pick matters as much for the bill as for the network path.

How VPC Endpoint connects to other services

An endpoint’s whole job is to be the private path to a specific AWS service, so its connections are the services it fronts — a gateway endpoint for S3 and DynamoDB, an interface endpoint for SQS, SNS, SES, and Lambda. Each edge has a requirement that makes it actually work, and Design Beaver models them so it knows what belongs on each connection.

• →S3

  A gateway VPC endpoint gives private-subnet resources backbone access to Amazon S3 with no NAT gateway and no per-GB data-processing charge

• →DynamoDB

  A gateway VPC endpoint gives private-subnet resources backbone access to DynamoDB with no NAT gateway and no per-GB charge

• →SQS

  An interface VPC endpoint (PrivateLink) lets a private-subnet producer/consumer reach Amazon SQS privately, without a NAT gateway

• →SNS

  An interface VPC endpoint lets a private-subnet publisher reach Amazon SNS privately

• →SES

  An interface VPC endpoint lets a private-subnet application call Amazon SES privately instead of over a NAT gateway

• →Lambda

  An interface VPC endpoint lets a private-subnet resource invoke the Lambda API privately

What VPC Endpoint can’t connect to

Some edges look reasonable on a canvas but don’t exist in AWS. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕Internet

  A VPC endpoint provides private connectivity to a specific supported AWS service (or PrivateLink service), not general egress to arbitrary internet destinations. For outbound access to the public internet, use a NAT gateway — an endpoint can't reach hosts it doesn't front.

• ✕RDS

  RDS is reached over ordinary same-VPC private networking (security-group rules from the app tier), not through a VPC endpoint — there's no interface/gateway endpoint that fronts a customer RDS instance.

Anti-patterns Design Beaver catches

These are the endpoint mistakes that pass a diagram review but cost you money or silently fail in production — the ones the validation engine flags as you draw.

Gotchas that bite in production

• S3 and DynamoDB support both endpoint types. The free gateway endpoint is the usual choice for in-VPC access, but an interface endpoint also exists for them — needed when access comes from on-premises, a peered VPC in another Region, or through a transit gateway, which a gateway endpoint can’t serve.
• An endpoint reaches one service, not the internet. It’s not a NAT-gateway replacement for a tier that also calls third-party APIs or downloads OS packages.
• An interface endpoint needs Private DNS and inbound 443. Without Private DNS, the service’s normal hostname still resolves to the public endpoint and your traffic quietly ignores the endpoint you’re paying for. Without an inbound TCP 443 rule from your clients, they can’t reach the endpoint’s network interface at all.
• A gateway endpoint’s “connection” is a route-table entry. If the subnet’s route table doesn’t reference it, nothing uses it. It also isn’t PrivateLink, so it doesn’t get a private IP or ENI the way an interface endpoint does.

Further reading

• Official AWS documentation
• Gateway endpoints (AWS docs)
• Why we built a validation engine