In an AWS VPC, what is the difference between a gateway VPC endpoint and an interface VPC endpoint, and how do you choose between them?

## The problem both solve A subnet is "private" when its route table has no `0.0.0.0/0` route to an internet gateway. Resources there can still reach AWS service APIs such as S3, Secrets Manager or CloudWatch Logs — but only by being routed out through a NAT gateway to the service's *public* endpoint. That works, yet it has two costs: every byte is billed as NAT data processing, and the traffic technically leaves your VPC's private address space to talk to a public API. VPC endpoints remove both by giving the VPC a private on-ramp to the service. There are two shapes of on-ramp, and they are not variants of one another — they are different mechanisms. ## Gateway endpoints A gateway endpoint is a *routing* construct. You create it, associate it with one or more route tables, and AWS inserts an entry into each of those tables: ``` Destination Target pl-63a5400a (com.amazonaws.us-east-1.s3) vpce-0a1b2c3d4e5f ``` The destination is an AWS-managed **prefix list** — a named, automatically maintained set of the CIDR ranges the service currently answers on — so you never hand-maintain S3's address ranges. Because the entry is more specific than `0.0.0.0/0`, longest-prefix matching sends S3 traffic to the endpoint instead of the NAT gateway. Nothing is provisioned inside the subnet: no ENI, no IP address from your CIDR, and therefore no security group on the endpoint itself. Only **S3 and DynamoDB** offer gateway endpoints. They carry no hourly charge and no per-GB charge, which makes the S3 gateway endpoint the single cheapest optimisation in most VPCs. The defining limitation is that a route table entry only helps things that consult that route table. Traffic arriving from a peered VPC, a Site-to-Site VPN, a Direct Connect link or a Transit Gateway attachment cannot use another VPC's gateway endpoint. If on-premises systems need private S3 access, a gateway endpoint is the wrong tool. ## Interface endpoints (PrivateLink) An interface endpoint is an *addressing* construct built on AWS PrivateLink. You pick subnets — normally one per AZ you care about — and AWS creates an elastic network interface in each, taking a private IP from that subnet's CIDR. Because it is a real ENI, it has security groups, and a common day-one mistake is leaving a group that does not allow inbound TCP 443 from the workload. Each endpoint gets endpoint-specific DNS names, and you can also turn on **private DNS**, which associates a managed private hosted zone with your VPC so the service's ordinary regional hostname (for example `secretsmanager.us-east-1.amazonaws.com`) resolves to the endpoint's private IPs. That is what makes the change invisible to application code and SDKs. Private DNS requires the VPC attributes `enableDnsSupport` and `enableDnsHostnames` to be enabled. Interface endpoints exist for most AWS services, and unlike gateway endpoints they are reachable from anywhere that can route to the ENI's private IP — a peered VPC, a Transit Gateway attachment, or an on-premises network — which is why a shared "endpoint VPC" is a common hub pattern. The price is real: you pay per endpoint-hour for each AZ the endpoint lives in, plus per GB processed. Twenty services times three AZs is sixty billable ENIs before a single byte moves. ## Choosing Use a gateway endpoint for S3 and DynamoDB whenever the consumers live in the same VPC — it is free and it is the largest NAT-bill reduction available. Reach for an S3 *interface* endpoint when access must come from on-premises or from another VPC through a hub, and note that S3 supports both types simultaneously; the gateway endpoint wins for in-VPC traffic while the interface endpoint serves the remote callers. For every other service, an interface endpoint is the only option, so the decision becomes economic: if a VPC's only outbound need is a handful of AWS APIs at low volume, a NAT gateway may still be cheaper than a wall of interface endpoints, whereas high-volume paths and compliance requirements that forbid internet egress justify them. A very common forcing function is running containers or Lambda functions with no internet route at all: pulling from ECR needs the `ecr.api` and `ecr.dkr` interface endpoints *plus* an S3 endpoint for the image layers, and shipping logs needs the `logs` endpoint. ## Where they bite Endpoints change the identity of the request as seen by the service: traffic through an endpoint no longer carries your NAT gateway's Elastic IP, so resource policies written against `aws:SourceIp` stop matching. Both types also accept an endpoint policy that can only *restrict* what passes through them. And endpoints are regional — an endpoint in `us-east-1` does not give you private access to a bucket in another Region.