Gateway vs. Interface VPC Endpoints: The Private AWS Access Exam Trap You Need to Nail
Gateway and Interface VPC endpoints both let you access AWS services privately, but they work completely differently, cost completely different amounts, and the SAA-C03 loves to offer one as a trap answer to a question about the other. Here's the complete guide.
Here's a scenario you will see on the SAA-C03:
A company runs EC2 instances in a private subnet with no internet access. A security audit finds that all S3 traffic is being routed through a NAT Gateway, adding cost and creating a potential data exposure path. What is the most cost-effective solution to allow the EC2 instances to access S3 without any internet connectivity?
If you immediately thought "VPC endpoint" — good, you're in the right territory. But if you can't instantly say which kind and why, you're going to pick the wrong answer. The SAA-C03 will offer both Gateway and Interface endpoints in the same question and the difference isn't cosmetic: one is free, one costs money; one works from on-premises, one doesn't; one modifies your route table, one creates a network card.
This question is also a perfect mirror of the security/networking questions many candidates stumble on — if you haven't nailed Security Groups and NACLs yet, that's a worthwhile companion read.
Let's dig into everything you need.
Why VPC Endpoints Exist: The Problem They Solve
By default, every AWS managed service — S3, DynamoDB, Secrets Manager, KMS, SSM, and dozens of others — has a public endpoint. An address like s3.amazonaws.com resolves to a public IP. When an EC2 instance in a private subnet needs to talk to S3, it has two unappealing options without VPC endpoints:
- NAT Gateway: Send traffic out through a NAT Gateway in a public subnet, which routes it over the internet (even though it stays on AWS infrastructure). Cost: ~$0.045/hour for the gateway plus $0.045/GB of data processed. For a workload moving terabytes, this adds up fast.
- Internet Gateway + public subnet: Move your instances to a public subnet and assign public IPs. That widens your attack surface and defeats the purpose of private subnets.
VPC endpoints solve this by creating a private path from your VPC directly to the AWS service, entirely on AWS's backbone — no internet gateway, no NAT, no public IPs in your traffic flow. Traffic never leaves the AWS network.
There are two fundamentally different ways AWS implements this private path, and they have almost nothing else in common.
Gateway Endpoints: The Free Route-Table Trick
A Gateway Endpoint works by injecting a route into one or more of your VPC's route tables. When traffic from your subnet is destined for the service's IP range, the route table says "send this to the endpoint" instead of sending it to the internet or NAT gateway.
Key facts:
- Supported services: S3 and DynamoDB only. That's it. No other services support gateway endpoints.
- Cost: completely free. There is no hourly charge, no per-GB data processing fee.
- Mechanism: route table entry. The endpoint installs a prefix list route like
pl-63a5400a(the prefix list for S3 in your region) into the route tables you designate. - No ENI, no private IP. A gateway endpoint does not create any network interface inside your VPC. There is no IP address to manage.
- Region-scoped. A gateway endpoint connects your VPC to S3 or DynamoDB in the same region only. You cannot use a single gateway endpoint to reach S3 in us-east-1 from a VPC in eu-west-1.
- Access control via endpoint policy. You can attach a resource-based policy to the endpoint that limits which S3 buckets or DynamoDB tables can be accessed through it.
The critical limitation: gateway endpoints cannot be extended outside the VPC. Traffic from on-premises networks connected via AWS Direct Connect or Site-to-Site VPN cannot use a gateway endpoint. Traffic from a peered VPC also cannot use your VPC's gateway endpoint. This is the limitation that generates the most exam traps.
How it looks in practice
Before a gateway endpoint, your private subnet route table might look like this:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | nat-gateway-id |
After you create an S3 gateway endpoint and associate it with that route table:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| pl-63a5400a (S3 IPs) | vpce-xxxxxxxx |
| 0.0.0.0/0 | nat-gateway-id |
Now any S3 request from instances in this subnet hits the endpoint route first, bypasses the NAT Gateway entirely, and flows directly to S3 over AWS's internal network.
Interface Endpoints (AWS PrivateLink): The Full-Featured Private Channel
An Interface Endpoint works completely differently. It provisions one or more Elastic Network Interfaces (ENIs) inside your VPC — actual network interfaces with private IP addresses drawn from your subnet's CIDR. When your instances connect to the service's DNS name, the name resolves to these private IPs, and traffic flows through your VPC's own network fabric.
This technology is called AWS PrivateLink. AWS uses it internally to expose its own services, and third-party SaaS providers use it to offer their services to your VPC without requiring VPC peering or public exposure.
Key facts:
- Supported services: 100+. Virtually every AWS managed service supports interface endpoints: EC2 API, KMS, Secrets Manager, Systems Manager (SSM), CloudWatch, STS, Lambda, SNS, SQS, Kinesis, CodePipeline, and many more. S3 and DynamoDB also support interface endpoints (in addition to gateway endpoints).
- Cost: not free. You pay an hourly rate per endpoint per Availability Zone (approximately $0.01/hour per AZ) plus a per-GB data processing fee ($0.01/GB). Deploying across 3 AZs for high availability costs roughly $21.60/month in endpoint fees alone, before data charges.
- Mechanism: ENI with private IP. The endpoint creates real network interfaces in your designated subnets. These ENIs show up in your EC2 console like any other network interface.
- Private DNS integration. Optionally, enabling private DNS makes the service's standard public hostname (e.g.,
kms.us-east-1.amazonaws.com) resolve to the endpoint's private IPs within your VPC. This means your application code doesn't need to change — it keeps using the standard endpoint URL. - Cross-environment accessibility. Unlike gateway endpoints, interface endpoints can be reached from on-premises networks via Direct Connect or VPN. They can also be accessed from peered VPCs (with the right DNS resolution settings).
- Security group support. An interface endpoint has an associated security group, giving you fine-grained inbound traffic control at the network level in addition to endpoint policies.
Head-to-Head Comparison Table
| Dimension | Gateway Endpoint | Interface Endpoint |
|---|---|---|
| Services supported | S3, DynamoDB only | 100+ AWS services |
| Mechanism | Route table entry (prefix list) | ENI with private IP in your subnet |
| Cost | Free | ~$0.01/hr/AZ + $0.01/GB data |
| Private IP in VPC | No | Yes |
| Security group | No | Yes (required) |
| Endpoint policy | Yes | Yes |
| On-premises access | No (cannot extend outside VPC) | Yes (via Direct Connect / VPN) |
| Peered VPC access | No | Yes |
| Private DNS | Not applicable | Optional (resolves public DNS to private IP) |
| Cross-region | No | No (endpoints are regional) |
| High availability | Built-in (AWS-managed) | Deploy ENI per AZ for redundancy |
| Route table change required | Yes | No |
Three Realistic Exam Scenario Walkthroughs
Exam questions in this domain are almost always "which endpoint type should the solutions architect use?" The scenarios vary the constraint to force the right answer.
Scenario 1 — The Cost Optimization Classic
A company stores large data science datasets in S3. EC2 instances in a private subnet perform batch analysis nightly, transferring several terabytes per run through a NAT Gateway. A solutions architect is asked to eliminate the NAT Gateway cost for S3 traffic while maintaining security. What should they do?
Answer: Create an S3 Gateway Endpoint and update the private subnet's route table.
Why: This is the textbook gateway endpoint use case. The traffic is S3-only, the instances are in the same region, there's no on-premises access requirement, and the goal is cost elimination. Gateway endpoints are free and require no architecture changes beyond adding a route entry. An interface endpoint would also work technically, but it introduces an ongoing hourly fee and per-GB charge — the question says "most cost-effective," so the free option wins.
Distractor trap: Some questions offer "configure the NAT Gateway with an elastic IP" or "move instances to a public subnet." Both increase cost or risk. Others offer the interface endpoint — don't pick it if the scenario is cost-focused and on-premises access isn't mentioned.
Scenario 2 — The On-Premises Reach
A financial services company has an on-premises data center connected to AWS via AWS Direct Connect. Applications running on-premises need to access Amazon S3 and AWS Secrets Manager without any traffic traversing the internet. What combination of VPC endpoints should the solutions architect configure?
Answer: Interface Endpoint for both S3 and Secrets Manager.
Why: The key constraint is "from on-premises via Direct Connect." Gateway endpoints cannot be reached from outside the VPC — they are only usable by resources inside the VPC itself. Since the traffic originates on-premises and enters the VPC over Direct Connect, the endpoint must have a private IP that on-premises hosts can route to. Interface endpoints have exactly that. Also, Secrets Manager has no gateway endpoint — it only supports interface endpoints — so an interface endpoint is mandatory for that service regardless.
Why not gateway for S3? Even though S3 supports a gateway endpoint, it won't help here. On-premises DNS queries will resolve s3.amazonaws.com to public S3 IPs, and the gateway endpoint's route table entry is only visible to the VPC's routing, not to on-premises routers. The interface endpoint, with private DNS enabled, lets on-premises resolvers see the private S3 endpoint IPs via the Direct Connect-connected VPC's DNS server.
Scenario 3 — The Multi-VPC Hub
A company uses a hub-and-spoke VPC architecture. A central "shared services" VPC is peered with 12 spoke VPCs. The company wants EC2 instances in all spoke VPCs to access AWS Systems Manager (SSM) without internet connectivity. The solution must minimize the number of VPC endpoints created.
Answer: Create Interface Endpoints for SSM in the hub VPC and enable DNS resolution for VPC peering.
Why: Interface endpoints — unlike gateway endpoints — can be accessed from peered VPCs. By creating the endpoints once in the hub VPC and configuring the peering connections to allow DNS resolution from spoke VPCs to hub VPC, all 12 spoke VPCs can route SSM traffic through a single set of endpoints. SSM has no gateway endpoint option, so interface is the only choice. Creating endpoints in all 12 spoke VPCs (the alternative) would work but dramatically increases endpoint costs and management overhead.
Why not gateway? Gateway endpoints cannot be shared across peered VPCs, and SSM doesn't support them anyway.
The Mental Model: Route Table vs. Network Card
The easiest way to keep gateway and interface endpoints permanently separated in your memory is this:
Gateway endpoint = a routing instruction. Interface endpoint = a network card.
A gateway endpoint changes where packets go by modifying the route table. There's no AWS-managed device inside your VPC — it's just a routing rule. Because it's just a routing rule local to your VPC, it cannot be seen by other VPCs or by on-premises networks. It's like a road sign that only exists inside your city.
An interface endpoint creates a real network interface — an ENI with a private IP — inside your subnet. It behaves like any other ENI: other systems can connect to that private IP directly, DNS can resolve to it, on-premises hosts can route TCP connections to it over Direct Connect. It's like installing a private door directly between your VPC and AWS's service, rather than redirecting the public road.
Pair that with the services: "Two services, no charge" = Gateway (S3 + DynamoDB). "Everything else + on-prem = Interface."
Common Exam Traps and Mistakes
Trap 1: Assuming gateway endpoints work from on-premises
This is the most-tested trap. Any question that mentions Direct Connect, Site-to-Site VPN, or "on-premises applications accessing AWS services" while requiring private connectivity is pointing at interface endpoints. Gateway endpoints are invisible outside the VPC — full stop.
Trap 2: Forgetting that gateway endpoints are free
Many candidates over-engineer the answer by choosing interface endpoints for S3 or DynamoDB in a simple intra-VPC scenario. If the instances are in the same VPC as the endpoint, the service is S3 or DynamoDB, there's no on-prem requirement, and the question asks for the most cost-effective solution — the gateway endpoint is the right answer and the interface endpoint is the trap.
Trap 3: Assuming interface endpoints are always better
Interface endpoints are more capable, but "more capable" doesn't mean "more correct." A question about a startup wanting to "securely and cheaply connect EC2 to S3" is not asking for a $0.01/hr-per-AZ solution. Read the constraints: if it's cheap, simple, same-region, same-VPC — gateway wins.
Trap 4: Mixing up private DNS behavior
Interface endpoints have a private DNS option that makes the service's standard public hostname resolve to private IPs inside your VPC. This matters for applications that hardcode service hostnames. Exam questions may ask whether application code changes are needed — if private DNS is enabled on the interface endpoint, the answer is usually no.
Trap 5: Thinking endpoints are cross-region
Both endpoint types are regional. An S3 gateway endpoint in us-east-1 cannot be used to access a bucket in eu-west-1 via private routing. Cross-region S3 access always goes through the internet or requires separate routing arrangements. This is a rare trap but worth knowing.
Trap 6: Believing gateway endpoints eliminate all NAT Gateway cost
A gateway endpoint removes NAT Gateway costs for S3 and DynamoDB traffic specifically. If your instances also access other public endpoints (like a third-party API, or EC2 metadata service from outside the instance), a NAT Gateway may still be needed. The gateway endpoint only covers S3 and DynamoDB routing.
Endpoint Policies: The Often-Forgotten Security Layer
Both endpoint types support endpoint policies — JSON resource-based policies that restrict what actions can be taken through the endpoint and on which resources. This is independent of bucket policies or IAM policies; it's a third layer of control.
A gateway endpoint policy might look like:
{
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-company-data-bucket",
"arn:aws:s3:::my-company-data-bucket/*"
]
}]
}
This restricts all traffic through the endpoint to only the my-company-data-bucket bucket — even if the IAM policy would allow broader access. For the SAA-C03, remember: endpoint policy + bucket policy + IAM policy all apply simultaneously. A request must satisfy all three.
This pattern appears in exam questions about data exfiltration prevention: a company wants to ensure EC2 instances can only access company-owned buckets and cannot be used to exfiltrate data to an attacker's bucket. The answer is an endpoint policy that restricts the endpoint to specific bucket ARNs.
Cost Deep-Dive: When the Interface Endpoint Math Changes
Interface endpoints aren't always expensive relative to the alternative. If you're paying for a NAT Gateway to route traffic to services like Secrets Manager or SSM, compare:
- NAT Gateway for SSM traffic: $0.045/hour + $0.045/GB processed. For a VPC running 24/7 with even moderate SSM traffic, this is real spend.
- Interface Endpoint for SSM (1 AZ): ~$0.01/hour + $0.01/GB. Roughly 4-5x cheaper per data unit than NAT.
The interface endpoint also eliminates the security exposure of routing service traffic through a NAT Gateway that may also route traffic to the public internet. For compliance-driven workloads (PCI DSS, HIPAA), that path isolation can be a requirement, not just a cost optimization.
The inflection point: if you have many services to privatize across many AZs, interface endpoint hourly costs multiply quickly. A VPC with 10 services, each with endpoints in 3 AZs = 30 endpoint-hours per hour = ~$650/month in endpoint fees before data charges. At that scale, a Transit Gateway with centralized interface endpoints (the hub-and-spoke scenario from the exam walkthroughs above) becomes the architecturally correct and cost-effective design.
Exam-Day Checklist
Before marking your answer on any VPC endpoint question, run through these checks in 20 seconds:
- Which service? S3 or DynamoDB → gateway eligible. Anything else → must be interface.
- Where does traffic originate? Same VPC → either type works. On-premises (Direct Connect / VPN) → must be interface. Peered VPC → must be interface.
- Is cost the primary constraint? If free is required and S3/DynamoDB is the service → gateway wins.
- Is private DNS mentioned? That's interface endpoint territory.
- Is data exfiltration prevention mentioned? Endpoint policy on either type is the tool.
- Is the hub-and-spoke architecture mentioned? Interface endpoints are shareable across peered VPCs; gateways are not — a centralized interface endpoint model is optimal.
- Does the question ask for least management overhead? Gateway endpoints require no ongoing management (no security groups, no ENIs, no AZ deployments). Interface endpoints require multi-AZ planning.
Putting It Together
The SAA-C03 tests VPC endpoints in two distinct flavors: pure-play cost optimization questions (private subnet + S3 + free = gateway) and more complex networking questions that introduce on-premises access, peered VPCs, or non-S3 services (where interface is the only or best answer). The trap is always to blur these two buckets.
The mental model holds up under every variant:
- Route table change = gateway. Simple, free, VPC-local. Only S3 and DynamoDB.
- ENI with private IP = interface. Costs money, but reachable from anywhere that can route to the VPC.
If a question gives you on-premises access plus S3 plus "most cost-effective," that's a deliberate tension the exam is testing: the cheapest option that works is an interface endpoint (because the gateway option literally cannot work). Read the constraint carefully.
Keep Practicing
VPC endpoints show up in multiple SAA-C03 domains — Design Secure Architectures (private access, endpoint policies), Design Cost-Optimized Architectures (eliminating NAT Gateway charges), and Design Resilient Architectures (centralized endpoint models). One mental model, multiple payoffs.
Want to find out where you stand right now? Take the free 10-question diagnostic at CertCoach — no signup required, instant results, tells you exactly which domains need the most work.
Ready to go all in? The CertCoach Pass gets you full access to the question bank, timed mocks, and detailed explanations — $29 one-time, no subscription, with a 7-day refund promise. A passing score is worth considerably more than that.
Good luck. Private access, private IPs, private networks — you've got this.