VPC endpoint questions on the SAA-C03 exam test whether you know which type of endpoint to use, which services each type supports, and why you would use a VPC endpoint instead of going over the internet.
What a VPC Endpoint Is
A VPC endpoint allows resources inside a VPC to communicate with AWS services using the AWS private network — without routing traffic through the internet, a NAT Gateway, or an Internet Gateway. This improves security and can reduce data transfer costs.
Gateway Endpoints
Gateway endpoints are added as a route in your route table. They are free of charge.
Supported services:
- Amazon S3
- Amazon DynamoDB
That is the complete list — only two services. If the question involves S3 or DynamoDB, a gateway endpoint is the answer.
Configuration: add a route to your subnet's route table with the destination being the AWS service prefix list and the target being the VPC endpoint.
Exam scenario: "EC2 instances in a private subnet need to access S3. The company wants to avoid internet traffic and not pay extra for a NAT Gateway to reach S3."
Answer: S3 Gateway Endpoint. No cost, no internet required. Add the route to the private subnet's route table.
Interface Endpoints (PrivateLink)
Interface endpoints use AWS PrivateLink and create an Elastic Network Interface (ENI) with a private IP address in your subnet. The ENI is the entry point into the AWS service.
Supported services: most AWS services — EC2, Systems Manager, CloudWatch, SQS, SNS, Kinesis, API Gateway, and many more. Also supports third-party services sold via AWS Marketplace.
Cost: hourly charge per endpoint per AZ, plus data processing charges.
Exam scenario: "EC2 instances in a private VPC need to call the AWS Systems Manager API without internet access."
Answer: Interface endpoint for Systems Manager. (Systems Manager is not S3 or DynamoDB, so a gateway endpoint is not an option.)
Endpoint Policies
Both gateway and interface endpoints support endpoint policies — resource-based policies that control which IAM principals can access which resources through the endpoint.
Example: restrict an S3 gateway endpoint so only a specific S3 bucket can be accessed through it. This prevents data exfiltration to attacker-controlled S3 buckets.
Private DNS
Interface endpoints support private DNS — when enabled, the standard service DNS name (e.g., ec2.us-east-1.amazonaws.com) resolves to the private endpoint IP address within the VPC. Applications do not need any code changes.
Gateway endpoints do not require DNS changes — they work through route table entries.
When to Use a VPC Endpoint
Use a VPC endpoint when:
- Resources in a private subnet need to access AWS services without a NAT Gateway
- You want to avoid internet traffic for compliance or security
- You need to reduce NAT Gateway data transfer costs for high-volume S3 or DynamoDB traffic
- On-premises systems (connected via VPN or Direct Connect) need to reach AWS services privately
Cost optimisation note: if EC2 instances transfer large amounts of data to/from S3 through a NAT Gateway, you pay both NAT Gateway data charges and S3 data transfer charges. An S3 gateway endpoint eliminates the NAT Gateway path entirely — data goes directly to S3 with no additional charge.
Practice SAA-C03 VPC endpoint questions to build confidence with gateway vs interface endpoint selection.
Gateway Endpoint Policy — Restricting Which S3 Buckets Are Accessible
Gateway endpoints don't just provide access to S3 or DynamoDB — they can restrict which resources are accessible through the endpoint via an endpoint policy.
The endpoint policy is an IAM resource-based policy attached to the endpoint itself. It acts as a filter on top of any existing IAM policies and bucket policies.
Example use case: a company uses a gateway endpoint for S3 but wants to prevent employees from exfiltrating data to their personal S3 buckets. The endpoint policy restricts access to only the company's own buckets:
{
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::company-data-bucket",
"arn:aws:s3:::company-data-bucket/*"
]
}
]
}
With this policy on the endpoint, instances using the endpoint can only access company-data-bucket. Requests to any other S3 bucket are denied at the endpoint — even if the IAM role on the instance would otherwise allow it.
The exam scenario: "A company wants to prevent employees in the VPC from uploading data to any S3 bucket outside of the corporate account. How do they enforce this?" The answer is a gateway endpoint policy that allows access only to specific bucket ARNs. This complements (but doesn't replace) IAM policies and bucket policies — all three layers must allow the access for it to succeed.
Interface Endpoint DNS Resolution — The Exam's Confusing Part
When you create an interface endpoint for a service like com.amazonaws.us-east-1.ssm, AWS creates private DNS names that override the public service DNS within your VPC.
With private DNS enabled on the endpoint (default), the service's standard DNS name — ssm.us-east-1.amazonaws.com — resolves to the endpoint's private IP inside the VPC. Your applications don't need to change their code or configuration; they still call the standard endpoint URL, but DNS now routes them to the private ENI instead of the public AWS endpoint.
For this to work, the VPC needs enableDnsSupport set to true (so DNS resolution happens) and enableDnsHostnames set to true. Without these, the private DNS override doesn't function and the endpoint name resolves to the public IP.
For on-premises access via Direct Connect or VPN: private DNS names only resolve within the VPC. Your on-premises DNS servers can't query Route 53's private resolvers. The solution is to use Route 53 Resolver inbound endpoints — on-premises DNS servers forward queries to the Resolver endpoint's IP, which can then resolve private DNS names. This setup allows on-premises systems to access interface endpoints without going through the internet.
PrivateLink — The Technology Behind Interface Endpoints
AWS PrivateLink is the underlying technology that powers interface endpoints. Every interface endpoint is a PrivateLink connection between your VPC and an AWS service.
PrivateLink also allows you to expose your own services to other VPCs without peering. The setup:
- You run a service behind a Network Load Balancer in your VPC
- You create a VPC Endpoint Service configuration pointing to your NLB
- Other accounts or VPCs create interface endpoints that connect to your service
- Traffic flows from the consumer VPC through the endpoint to your NLB, then to your service
The consumer VPC never has VPC peering with your VPC. There's no route between the VPCs at the network level — only the specific service endpoint is accessible. This is the key difference from VPC peering, which gives full IP-level access between VPCs.
The exam scenario: "Company A runs an analytics service that Company B's VPC needs to access. Company A does not want to expose their entire VPC network. Company B does not want the risk of routing between VPCs." This is PrivateLink — Company A creates a VPC Endpoint Service, Company B creates an interface endpoint. No peering, no full network access, service exposure only.
Cost Comparison — When the Exam Asks for the Cheapest Option
The cost difference between gateway and interface endpoints is significant enough to be exam-relevant:
| Endpoint Type | Hourly Cost | Data Processing Cost |
|---|---|---|
| Gateway endpoint (S3/DynamoDB) | Free | Free |
| Interface endpoint | ~$0.01/hour per AZ | ~$0.01/GB processed |
For S3 and DynamoDB specifically, gateway endpoints are always cheaper than interface endpoints — not just marginally cheaper, but completely free vs. charged. Any exam question that says "private subnet instances need to access S3, what is the most cost-effective approach" has gateway endpoint as the correct answer, not interface endpoint.
The nuance: interface endpoints for S3 do exist and have specific use cases — they support endpoint policies with more flexibility, support private DNS for S3, and can be accessed from on-premises via Direct Connect (gateway endpoints cannot be accessed from on-premises). If the scenario doesn't mention on-premises access or any of these advanced features, gateway endpoint wins on cost.
On-Premises Access to VPC Endpoints
This is one of the most important behavioral differences between gateway and interface endpoints, and the exam tests it directly.
Gateway endpoints use route table entries to direct traffic. The route entry is: S3 prefix list → endpoint ID. This route only exists in VPC route tables. On-premises networks connected via Direct Connect or Site-to-Site VPN don't have VPC route tables — they're outside the VPC. Therefore, on-premises systems cannot use gateway endpoints to reach S3 or DynamoDB.
Interface endpoints create an ENI with a private IP address inside the VPC. On-premises systems can access this private IP via Direct Connect or VPN, just like they'd access any other private IP in the VPC. Combined with Route 53 Resolver forwarding rules (to resolve the private DNS names on-premises), interface endpoints can be reached from on-premises.
The exam scenario: "A company runs on-premises servers that connect to AWS via Direct Connect. They want these servers to access S3 without traversing the internet. What should they configure?" The answer is an interface endpoint for S3 (not a gateway endpoint, because gateway endpoints can't be reached from on-premises) combined with Route 53 Resolver rules so on-premises DNS can resolve the S3 endpoint's private name.
Exam Scenario: Lambda Accessing S3 Without Internet
Lambda functions deployed inside a VPC (VPC-enabled Lambda) follow the same networking rules as EC2 instances. Without a NAT Gateway or VPC endpoint, a VPC-enabled Lambda function has no path to any AWS service — it's isolated in the VPC's private network.
The incorrect solution that candidates often choose: add a NAT Gateway to the VPC so Lambda can call S3 via the internet. This works but costs money (NAT Gateway hourly + per-GB) and routes traffic through the internet unnecessarily.
The correct solution: create a gateway VPC endpoint for S3. Add the endpoint route to the Lambda function's subnet route tables. Now Lambda can reach S3 directly through AWS's internal network — free, no internet, no NAT Gateway.
Configuration steps:
- Create a gateway VPC endpoint for S3 in the VPC
- Associate the endpoint with the route tables of the Lambda function's subnets
- Ensure the Lambda execution role has the necessary S3 permissions
- Optionally, configure an endpoint policy to restrict which S3 buckets the Lambda can access
The exam also tests this for ECS tasks in VPCs — same pattern, same solution. Anytime a compute resource in a private subnet needs S3 or DynamoDB, gateway endpoint is the cheapest, most secure path.
Practice Question Sets
Working through real SAA-C03 questions is the fastest way to lock in how the exam phrases these scenarios. Pick a session that fits your time: