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?
answer
- one is a route, one is an ENI
- free versus per-hour plus per-GB
- only two services get the free kind
- route tables do not cross a VPC boundary
- private DNS makes the swap invisible
basics
~20 sGateway endpoints add a route-table entry for S3 or DynamoDB only and cost nothing. Interface endpoints put a PrivateLink network interface with a private IP into your subnets, cover most AWS services, and bill per endpoint-hour plus per gigabyte processed.
solid answer
~60 sBoth keep traffic to an AWS service off the public internet, but they work differently. A **gateway endpoint** exists only for S3 and DynamoDB: you attach it to route tables, and AWS installs a route whose destination is the service's managed prefix list and whose target is the `vpce-` id. Nothing is created inside your subnets, there is no security group, and there is no charge. Its limit is that only resources inside that VPC can use it — a peered VPC, a VPN, or Direct Connect cannot route to it. An **interface endpoint** is PrivateLink: AWS creates an elastic network interface with a private IP in each subnet you select, you attach security groups to it, and with private DNS enabled the service's normal hostname resolves to that private IP. It works for most AWS services and is reachable from on-premises, but you pay hourly per endpoint per AZ plus per GB. Practically: S3 and DynamoDB get gateway endpoints unless on-premises or a shared-services VPC must reach them; everything else gets an interface endpoint.
code
bash · 15 lines# Gateway endpoint: attaches to route tables, no ENI, no charge
aws ec2 create-vpc-endpoint \
--vpc-id vpc-0a1b2c3d \
--vpc-endpoint-type Gateway \
--service-name com.amazonaws.us-east-1.s3 \
--route-table-ids rtb-0aaa1111 rtb-0bbb2222
# Interface endpoint: creates an ENI per subnet, billed hourly + per GB
aws ec2 create-vpc-endpoint \
--vpc-id vpc-0a1b2c3d \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.us-east-1.secretsmanager \
--subnet-ids subnet-0aaa subnet-0bbb \
--security-group-ids sg-0endpoint \
--private-dns-enabledgo deeper
Be able to say that a VPC endpoint lets resources in a private subnet reach an AWS service without going through a NAT gateway or the public internet, and that S3 is the classic example.
Explain the two mechanisms concretely: a route-table entry pointing at a managed prefix list for gateway endpoints, versus an elastic network interface with a private IP and optional private DNS for interface endpoints. Name S3 and DynamoDB as the only gateway-endpoint services.
Show you have operated these: know that gateway endpoints do not serve peered or on-premises callers, that interface endpoints need per-AZ ENIs and a security group that permits 443, and that a container platform with no internet route needs ECR, S3 and logs endpoints together.
Own the economics and the standard. Decide when a fleet of interface endpoints beats a NAT gateway, whether endpoints are duplicated per VPC or centralised in a shared endpoint VPC, and how that choice interacts with account isolation and the data perimeter you want to enforce.
## 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.
- Why can't a peered VPC use your S3 gateway endpoint, and what would you deploy instead?A gateway endpoint works by inserting a route into route tables in its own VPC, and route table entries are not transitive across peering, VPN or Transit Gateway attachments — the remote VPC has no way to select that target. To give remote or on-premises callers private S3 access you deploy an S3 interface endpoint, whose ENI has a private IP that any routed network can reach.
- You enabled an interface endpoint but connections from the application time out rather than failing fast. What is the likely cause?A timeout points at the endpoint ENI's security group. Unlike a gateway endpoint, an interface endpoint is a real network interface, and its security group must allow inbound TCP 443 from the workload's source — usually the application's security group. A DNS or routing failure typically surfaces as an unresolved name or a connection refusal instead.
- How many interface endpoint ENIs should you create for a service in a three-AZ VPC, and what is the tradeoff?One per AZ you serve, so three. Fewer saves hourly cost but means workloads in an AZ without an ENI cross an availability-zone boundary to reach the endpoint, adding latency, cross-AZ data cost and a dependency on another AZ staying healthy. Single-AZ endpoints are acceptable only for non-critical or dev workloads.
saying these in an interview costs you the question
- Says every AWS service offers a gateway endpoint
- Thinks interface endpoints are also free of charge
- Believes a peered VPC can use your gateway endpoint
- Assumes an endpoint grants access, not just a private path
- Forgets the interface endpoint ENI has a security group