This chapter covers VPC Gateway Endpoints and Interface Endpoints for Amazon S3 and DynamoDB, which are essential for private, secure access to these services without traversing the public internet. For the DVA-C02 exam, you must understand the differences between Gateway and Interface Endpoints, how they work with route tables and DNS, and when to use each. Approximately 5-8% of exam questions touch on VPC endpoints, often in the context of security, networking, or cost optimization scenarios.
Jump to a section
Imagine a large company campus (your VPC) with a secure, guarded gate (Internet Gateway) that opens to the public street. Employees (EC2 instances) need to access two specific vendors in the city: the S3 warehouse (for bulk storage) and the DynamoDB library (for fast lookup). Normally, they would have to walk out the main gate, exposing themselves to the public street, which is inefficient and risky. Instead, the company builds two private, underground tunnels that connect directly from the basement of each building to the vendor's loading dock, bypassing the public street entirely. The S3 tunnel is a Gateway Endpoint: it appears as a simple door in the basement that any employee can use, and it uses the existing internal phone system (route table) to direct traffic. The DynamoDB tunnel is an Interface Endpoint: it is a dedicated, guarded door with its own security guard (Elastic Network Interface) and a private phone number (private IP) that employees dial to reach the library. Both tunnels keep traffic off the public street, but the S3 tunnel is simpler and cheaper (no per-hour fee), while the DynamoDB tunnel allows more granular control and can connect to other services via the same mechanism. The key mechanic: the tunnels are not attached to the campus's main gate; they are separate, private connections that only work for the specific vendor they are built for. If an employee wants to access a different vendor, they must use the main gate or build another tunnel.
What Are VPC Endpoints and Why Do They Exist?
VPC endpoints enable private connections between your VPC and supported AWS services without requiring an Internet Gateway (IGW), NAT device, VPN connection, or AWS Direct Connect. Traffic between your VPC and the service does not leave the AWS network, reducing exposure to the public internet and improving security. For the DVA-C02 exam, you need to know that there are two types: Gateway Endpoints and Interface Endpoints (powered by AWS PrivateLink). Gateway Endpoints are supported only for Amazon S3 and DynamoDB. Interface Endpoints are supported for many AWS services, including DynamoDB, but NOT for S3 (as of the DVA-C02 exam objectives — note that S3 now also supports Interface Endpoints via PrivateLink, but the exam historically tests Gateway Endpoints for S3; check current exam guide). This distinction is critical.
Gateway Endpoints: How They Work
A Gateway Endpoint is a logical entity that you add to your VPC route table as a prefix list for the service (e.g., the S3 prefix list com.amazonaws.<region>.s3). When an instance in your VPC sends traffic to an S3 bucket, the destination IP resolves to an S3 IP address. The route table entry for the prefix list points to the Gateway Endpoint, which is a horizontally scaled, redundant set of AWS-owned infrastructure. The traffic is routed directly to S3 without leaving AWS's network. There is no change to the IP packets; the route table simply directs traffic to the endpoint. Gateway Endpoints are free of charge (no hourly cost) and support only S3 and DynamoDB. They do not use ENIs or security groups; instead, you attach a bucket policy (for S3) or a DynamoDB resource-based policy to restrict access to the endpoint. Gateway Endpoints also support endpoint policies that allow you to restrict what actions can be performed via the endpoint.
Interface Endpoints: How They Work
An Interface Endpoint is an elastic network interface (ENI) with a private IP address from your VPC subnet that serves as an entry point for traffic destined to a supported AWS service. It uses AWS PrivateLink to provide a private connection. For DynamoDB, you can use either a Gateway Endpoint (free) or an Interface Endpoint (paid per hour + per GB data processed). The Interface Endpoint is attached to a security group, so you can control inbound and outbound traffic at the network level. Traffic to the service is sent to the private IP of the ENI, which then forwards it to the service via the PrivateLink network. Interface Endpoints support DNS resolution: you can use the standard DNS names for the service (e.g., dynamodb.<region>.amazonaws.com) which resolve to the private IP of the ENI when using private DNS (Route 53 Resolver). This allows existing applications to use the same endpoint names without modification.
Key Components, Values, and Defaults
Prefix List: Gateway Endpoints use a prefix list ID (e.g., pl-xxxxxxxx) that you add as a target in route tables. The prefix list contains the IP ranges for the service. You can find the prefix list ID in the VPC console or via AWS CLI: aws ec2 describe-managed-prefix-lists.
Endpoint Policy: Both Gateway and Interface Endpoints support endpoint policies (IAM resource-based policies) that control which resources and actions are allowed via the endpoint. Default policy is full access. Example S3 endpoint policy to restrict access to a specific bucket:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}Security Groups: Only Interface Endpoints use security groups. Gateway Endpoints do not support security groups; you rely on bucket policies and endpoint policies.
DNS Resolution: For Interface Endpoints, enabling private DNS automatically updates the Route 53 private hosted zone for the service, so that the default service DNS name resolves to the private IP of the endpoint. This is a key exam point: private DNS is enabled by default when you create an Interface Endpoint.
Cost: Gateway Endpoints are free. Interface Endpoints incur hourly charges and data processing charges (per GB).
Configuration and Verification
To create a Gateway Endpoint for S3:
1. Open the VPC console, choose Endpoints, Create Endpoint.
2. Select "Gateway" type, choose S3 service (with the prefix list).
3. Select the VPC and the route tables to modify. The endpoint automatically adds a route to the prefix list with target as the endpoint.
4. Verify: Check the route table for a route with destination pl-xxxxxxxx and target vpce-xxxxxxxx.
To create an Interface Endpoint for DynamoDB:
1. Choose "Interface" type, select DynamoDB service.
2. Select subnet(s) where the ENI will be created. You can enable private DNS.
3. Attach a security group.
4. Verify: Check the ENI in EC2 console, note the private IP. Test connectivity from an instance: nslookup dynamodb.<region>.amazonaws.com should resolve to the private IP if private DNS is enabled.
Interaction with Related Technologies
VPC Peering: Gateway Endpoints do not extend across VPC peering connections. Each VPC needs its own Gateway Endpoint. Interface Endpoints can be accessed from peered VPCs if the endpoint's security group allows traffic from the peered VPC CIDR and the route tables are properly configured.
VPN and Direct Connect: Both endpoint types can be accessed from on-premises networks via VPN or Direct Connect, provided the on-premises network can resolve the service DNS name to the private IP (for Interface Endpoints) or the route table directs traffic appropriately.
NAT Gateway / Internet Gateway: If you use Gateway Endpoints, you do not need a NAT Gateway or Internet Gateway for S3/DynamoDB access. This is a common exam scenario: design a private subnet with no internet access but still access S3 via Gateway Endpoint.
Step-by-Step Packet Walkthrough for Gateway Endpoint (S3)
An EC2 instance in a private subnet makes a request to an S3 bucket (e.g., GET /my-bucket/object).
The instance's OS resolves s3.<region>.amazonaws.com to an S3 IP address via DNS (using the VPC DNS resolver).
The instance sends the IP packet to its default gateway (the subnet's route table).
The route table has a more specific route for the prefix list com.amazonaws.<region>.s3 that points to the Gateway Endpoint (target vpce-xxxxxxxx).
The packet is forwarded to the Gateway Endpoint infrastructure, which is a set of AWS-managed routers.
The Gateway Endpoint forwards the packet to the S3 service, but the source IP remains the instance's private IP (not a public IP). S3 sees the request coming from the VPC.
The response follows the reverse path: S3 sends the response to the Gateway Endpoint, which forwards it to the instance based on the route table.
Step-by-Step Packet Walkthrough for Interface Endpoint (DynamoDB)
An EC2 instance in a private subnet makes a request to DynamoDB (e.g., GetItem).
The instance resolves dynamodb.<region>.amazonaws.com to the private IP of the Interface Endpoint's ENI (if private DNS is enabled).
The instance sends the packet to the ENI's private IP. The packet is delivered directly to the ENI in the same subnet.
The ENI (Interface Endpoint) receives the packet and forwards it to the DynamoDB service via the PrivateLink network.
DynamoDB sends the response back to the ENI, which forwards it to the instance.
The security group attached to the ENI controls inbound and outbound traffic. The instance's own security group also applies.
Exam Trap: Gateway Endpoint vs Interface Endpoint for DynamoDB
Many candidates assume that because DynamoDB is a regional service, it must use a Gateway Endpoint like S3. However, DynamoDB supports both Gateway and Interface Endpoints. The exam may ask: "Which type of VPC endpoint should you use to access DynamoDB from a private subnet without internet access?" The answer could be either, but the correct choice depends on cost, security group requirements, and whether you need access from on-premises via VPN. The exam loves to test that Gateway Endpoints are free and do not use security groups, while Interface Endpoints are paid and use security groups.
Key Exam Numbers
Gateway Endpoints are supported only for S3 and DynamoDB.
Interface Endpoints are supported for DynamoDB and many other services (e.g., SNS, SQS, KMS, CloudWatch, API Gateway), but NOT for S3 (as of the current exam guide — verify for updates).
Gateway Endpoints are free; Interface Endpoints cost $0.01 per hour per AZ plus $0.01 per GB data processed (prices may vary by region).
Gateway Endpoints do not require security groups; Interface Endpoints require security groups.
Gateway Endpoints use prefix lists in route tables; Interface Endpoints use ENIs with private IPs.
Private DNS is enabled by default for Interface Endpoints; it is not applicable for Gateway Endpoints.
Edge Cases
Cross-Region Access: VPC endpoints are regional. You cannot use a VPC endpoint in one region to access a service in another region. For S3, you can use a Gateway Endpoint in the same region as the bucket. For cross-region access, you must use an Interface Endpoint (if supported) or go over the internet.
Endpoint Policies: Both types support endpoint policies, but the policy syntax is the same. You can restrict access to specific buckets, tables, or actions.
Multiple Subnets: For Interface Endpoints, you can create endpoints in multiple subnets (different AZs) for high availability. Each ENI gets a private IP from its subnet.
Private DNS and Custom DNS: If you use a custom DNS resolver (e.g., on-premises), you need to ensure that the service DNS names resolve to the endpoint's private IP. For Interface Endpoints, you can use Route 53 private hosted zones or conditional forwarding.
Interaction with AWS Services
AWS KMS: If you use S3 Server-Side Encryption with KMS (SSE-KMS), the S3 Gateway Endpoint still works because KMS calls are separate and may require an Interface Endpoint for KMS if you want to keep KMS traffic private.
VPC Flow Logs: You can capture traffic to/from endpoints in VPC Flow Logs. Note that Gateway Endpoint traffic is logged with the endpoint's prefix list ID as the destination, not the service IP.
AWS CloudTrail: Endpoint events are logged in CloudTrail.
Summary of Differences
| Feature | Gateway Endpoint | Interface Endpoint | |---------|-----------------|-------------------| | Supported services | S3, DynamoDB | Many (including DynamoDB, but not S3 traditionally) | | Cost | Free | Hourly + data processing | | Security | Endpoint policy + resource-based policy | Security group + endpoint policy + resource-based policy | | Network mechanism | Route table prefix list | ENI with private IP | | DNS | No private DNS option | Private DNS (default) | | Access from on-premises | Via VPN/Direct Connect (requires routing) | Via VPN/Direct Connect (with DNS resolution) |
Configuration Example: S3 Gateway Endpoint with Policy
Create a Gateway Endpoint for S3 and attach a policy that allows only GetObject on a specific bucket:
aws ec2 create-vpc-endpoint \
--vpc-id vpc-12345678 \
--service-name com.amazonaws.us-east-1.s3 \
--route-table-ids rtb-12345678 \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}'Verification Commands
List endpoints: aws ec2 describe-vpc-endpoints
Check route tables: aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-12345678
Test connectivity from an instance: aws s3 ls s3://my-bucket (should work if endpoint is configured correctly).
Identify Service and Endpoint Type
Determine which AWS service you need to access privately (S3 or DynamoDB). For S3, you must use a Gateway Endpoint (or an Interface Endpoint if supported, but the exam focuses on Gateway). For DynamoDB, you can choose either Gateway (free) or Interface (paid, with security groups). This decision is based on cost, security requirements, and whether you need to access the service from on-premises via VPN/Direct Connect with private DNS. The exam often presents a scenario where you have a private subnet with no internet access and need to access S3 or DynamoDB; the correct answer is to create a Gateway Endpoint.
Create the VPC Endpoint
Using the AWS Management Console, CLI, or SDK, create the endpoint. For Gateway Endpoint, specify the service name (e.g., `com.amazonaws.us-east-1.s3`), the VPC, and the route tables to be updated. The service automatically adds a route to the prefix list with the endpoint as target. For Interface Endpoint, specify the service name, VPC, subnets (one per AZ for high availability), and optionally enable private DNS. The endpoint creates an ENI in each specified subnet with a private IP. You also attach a security group to control traffic.
Configure Endpoint Policy (Optional)
Attach an IAM resource-based policy to the endpoint to restrict which actions and resources can be accessed via this endpoint. The default policy allows full access. For example, you can restrict S3 access to a specific bucket or limit DynamoDB actions to `GetItem` and `PutItem`. The policy is evaluated in addition to any resource-based policies (bucket policy, table policy) and IAM user/role policies. This is a common exam point: endpoint policies can further restrict access even if the bucket policy allows it.
Update Route Tables (Gateway Only)
For Gateway Endpoints, the route table is automatically updated with a route to the prefix list. However, if you create the endpoint without specifying route tables, you must manually add the route. The route destination is the prefix list ID (e.g., `pl-12345678`) and the target is the endpoint ID (e.g., `vpce-12345678`). This route must be more specific than the default route (0.0.0.0/0) to ensure traffic to S3/DynamoDB is directed to the endpoint. Verify the route table entry using `aws ec2 describe-route-tables`.
Update Security Groups (Interface Only)
For Interface Endpoints, you must configure the security group attached to the ENI. The inbound rules should allow traffic from your VPC CIDR (or specific instance security groups) on the service's port (HTTPS 443 for most services). The outbound rules should allow traffic to the service (typically 443). Additionally, the instances that access the endpoint must have outbound rules allowing traffic to the endpoint's security group or the service's private IP. Misconfigured security groups are a common reason for connectivity failures.
Test and Verify Connectivity
From an instance in the VPC, test access to the service. For S3, use `aws s3 ls s3://bucket-name`. For DynamoDB, use `aws dynamodb list-tables`. If private DNS is enabled for Interface Endpoint, the standard DNS names resolve to the private IP. If not, you may need to use the endpoint-specific DNS name (e.g., `vpce-xxxxxxxx.dynamodb.us-east-1.vpce.amazonaws.com`). Use tools like `nslookup`, `curl`, or the AWS CLI with `--endpoint-url` to verify. Check VPC Flow Logs to see if traffic is passing through the endpoint.
Enterprise Scenario 1: Private S3 Access for Financial Services
A financial institution runs a multi-tier application in a VPC with strict security requirements. The application processes sensitive customer data and must store files in S3. The security team mandates that no traffic should traverse the public internet. The solution is to create a Gateway Endpoint for S3 in each of the three Availability Zones. The application instances are in private subnets with no Internet Gateway. The route tables for those subnets include a route to the S3 prefix list via the Gateway Endpoint. To further restrict access, an endpoint policy is attached that allows only s3:PutObject and s3:GetObject on a specific bucket, and the bucket policy includes a condition that restricts access to the VPC endpoint (using aws:SourceVpce). This ensures that even if credentials are compromised, data can only be accessed from within the VPC. The performance consideration: Gateway Endpoints scale automatically and do not introduce latency beyond normal AWS network. However, the team must ensure that the route table entries do not conflict with other routes (e.g., if a NAT Gateway is also present, the more specific prefix list route takes precedence). A common misconfiguration is forgetting to add the route to all subnets that need access, causing timeouts.
Enterprise Scenario 2: Hybrid Access to DynamoDB for a Retail Platform
A large e-commerce platform uses DynamoDB as its primary database. The application runs both in AWS (EC2 in VPC) and on-premises via AWS Direct Connect. The on-premises application needs low-latency, private access to DynamoDB. The team decides to use an Interface Endpoint for DynamoDB because it supports private DNS and can be accessed from on-premises via Direct Connect with proper DNS resolution (using Route 53 inbound resolver). They create the Interface Endpoint in two subnets (different AZs) for high availability and attach a security group that allows inbound traffic from the on-premises CIDR and the VPC CIDR. They enable private DNS so that the standard dynamodb.us-east-1.amazonaws.com resolves to the endpoint's private IP within the VPC. For on-premises, they configure conditional forwarding to forward queries for dynamodb.us-east-1.amazonaws.com to the VPC's Route 53 resolver. The cost is a consideration: the Interface Endpoint incurs hourly charges and data processing fees. The team monitors usage and finds that the cost is acceptable given the security benefits. A common issue is that the security group for the endpoint must allow inbound HTTPS from the on-premises network; otherwise, requests time out.
Enterprise Scenario 3: Multi-Account S3 Access via Gateway Endpoint
A company uses AWS Organizations with multiple accounts. A central logging account stores logs in an S3 bucket. Other application accounts need to write logs to this central bucket. The application accounts each have a VPC with a Gateway Endpoint for S3. The central bucket policy includes a condition that allows access only from the VPC endpoints of the application accounts (using aws:SourceVpce). This ensures that log data is only accepted from known VPCs. The challenge is managing the endpoint IDs across accounts; the team uses a centralized parameter store to share the endpoint IDs. Performance is not an issue as Gateway Endpoints handle high throughput. A misconfiguration scenario: if the bucket policy does not include the aws:SourceVpce condition, the bucket could be accessed from any VPC with a Gateway Endpoint, violating security.
What the DVA-C02 Tests
The DVA-C02 exam objective 2.1 (Security) includes VPC endpoints as a mechanism to securely access AWS services. The exam expects you to:
Differentiate between Gateway and Interface Endpoints.
Know which services support each type (S3 and DynamoDB for Gateway; DynamoDB and many others for Interface, but NOT S3 traditionally).
Understand how endpoint policies work and how they interact with resource-based policies (bucket policies, table policies).
Recognize scenarios where you would use a Gateway Endpoint vs an Interface Endpoint based on cost, security groups, and on-premises access.
Configure private DNS for Interface Endpoints.
Common Wrong Answers and Why
"Use an Interface Endpoint for S3" – This is often chosen because Interface Endpoints are more flexible. However, as of the DVA-C02 exam, S3 does not support Interface Endpoints (though this may change; check the latest exam guide). The correct answer is Gateway Endpoint for S3.
"Gateway Endpoints require security groups" – Candidates confuse Gateway with Interface. Gateway Endpoints do not use security groups; they use endpoint policies and resource-based policies.
"Interface Endpoints are free" – Gateway Endpoints are free; Interface Endpoints have hourly and data processing costs. The exam tests cost awareness.
"You need an Internet Gateway to use VPC endpoints" – This is false. Endpoints are designed to avoid the internet. Candidates may think endpoints are like NAT devices.
Specific Numbers and Terms
Prefix list: The route table destination for Gateway Endpoints. Exam may ask: "What do you add to the route table for a Gateway Endpoint?" Answer: the prefix list for the service.
Private DNS: For Interface Endpoints, this is enabled by default. Exam may ask: "How do you ensure existing applications use the endpoint without changing code?" Answer: Enable private DNS.
Endpoint policy: A JSON policy document attached to the endpoint. Exam may ask: "How can you restrict which S3 buckets can be accessed via a VPC endpoint?" Answer: Use an endpoint policy.
Edge Cases and Exceptions
Cross-region: Endpoints are regional. You cannot use a VPC endpoint in us-east-1 to access S3 in eu-west-1. The exam might present a scenario where an application in us-east-1 needs to access an S3 bucket in eu-west-1 privately; the answer is to use a Gateway Endpoint in eu-west-1 (or an Interface Endpoint if supported) or use a different approach.
VPC Peering: Gateway Endpoints do not extend across VPC peers. If you have two VPCs peered, each VPC needs its own Gateway Endpoint. Interface Endpoints can be accessed from peered VPCs if the security group allows it and the route tables are set up.
Multiple route tables: If you have multiple route tables, you must add the prefix list route to each route table associated with subnets that need access.
How to Eliminate Wrong Answers
If the question mentions "private subnet with no internet access" and the service is S3, eliminate any answer that includes an Internet Gateway, NAT Gateway, or Interface Endpoint (since S3 uses Gateway).
If the question mentions "on-premises access via Direct Connect" and the service is DynamoDB, the correct answer is an Interface Endpoint because it supports private DNS and security groups.
If the question asks about cost, Gateway Endpoints are free, Interface Endpoints are not.
If the question asks about security groups, only Interface Endpoints use them.
Exam Tip
Memorize the supported services: Gateway Endpoints only for S3 and DynamoDB. Interface Endpoints for DynamoDB, SNS, SQS, KMS, CloudWatch, API Gateway, etc. (but NOT S3). This single fact will answer multiple questions correctly.
VPC Gateway Endpoints are free and support only Amazon S3 and DynamoDB.
VPC Interface Endpoints are paid (hourly + data) and support many services including DynamoDB, but not S3 (as per DVA-C02 exam).
Gateway Endpoints use route table prefix lists; Interface Endpoints use ENIs with private IPs and security groups.
Endpoint policies are JSON documents that control access via the endpoint; they work alongside resource-based policies.
Private DNS for Interface Endpoints is enabled by default, allowing existing applications to use the endpoint without code changes.
VPC endpoints are regional and do not extend across VPC peering or to other regions.
For on-premises access, Interface Endpoints are easier to configure with private DNS and security groups.
Always verify connectivity using AWS CLI commands like `aws s3 ls` or `aws dynamodb list-tables` after configuration.
These come up on the exam all the time. Here's how to tell them apart.
Gateway Endpoint
Supported only for S3 and DynamoDB.
Free of charge.
Uses prefix list in route table; no ENI created.
No security groups; access controlled via endpoint policies and resource-based policies.
Traffic is routed at the network layer; no private DNS option.
Interface Endpoint
Supported for many services including DynamoDB, but NOT S3 (traditionally).
Hourly and data processing charges apply.
Uses an ENI with a private IP in your subnet.
Uses security groups for network access control.
Supports private DNS (enabled by default) so standard service DNS names resolve to the endpoint's private IP.
Mistake
VPC endpoints require an Internet Gateway to function.
Correct
VPC endpoints provide private connectivity without an Internet Gateway. Traffic stays within the AWS network and does not traverse the public internet.
Mistake
Gateway Endpoints support security groups.
Correct
Gateway Endpoints do not use security groups. Access control is achieved via endpoint policies and resource-based policies (bucket policies, table policies). Only Interface Endpoints use security groups.
Mistake
Interface Endpoints are free like Gateway Endpoints.
Correct
Interface Endpoints incur hourly charges (per endpoint per AZ) and data processing charges (per GB). Gateway Endpoints are free of charge.
Mistake
You can use a Gateway Endpoint to access S3 from on-premises via Direct Connect without additional configuration.
Correct
While you can access Gateway Endpoints from on-premises via Direct Connect or VPN, you need to ensure that the on-premises network has a route to the VPC and that DNS resolution works correctly. For Interface Endpoints, private DNS simplifies this.
Mistake
VPC endpoints work across regions.
Correct
VPC endpoints are regional. You cannot use a VPC endpoint in one region to access a service in another region. Each region requires its own endpoint.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can access a Gateway Endpoint from on-premises via Direct Connect or VPN. However, you need to ensure that the on-premises network has a route to the VPC (e.g., via Direct Connect VIF) and that the route table in the VPC includes the prefix list route. The on-premises traffic will enter the VPC and then be routed to the Gateway Endpoint. Note that the source IP of the request will be the on-premises IP, not a VPC IP, so bucket policies that use `aws:SourceVpce` will need to allow the on-premises IP or use a different condition. For better control, consider using an Interface Endpoint with private DNS.
An endpoint policy is attached to the VPC endpoint itself and controls what actions and resources can be accessed via that endpoint. A bucket policy is attached to the S3 bucket and controls access to the bucket from any principal. Both policies are evaluated when a request is made through the endpoint. For example, you can use an endpoint policy to restrict all traffic through the endpoint to only `GetObject` on a specific bucket, while the bucket policy might allow `PutObject` from other sources. The most restrictive policy applies. A common exam scenario is to use both to enforce least privilege.
Enable private DNS on the Interface Endpoint when you create it. This automatically updates the VPC's DNS settings so that the standard DynamoDB endpoint (e.g., `dynamodb.us-east-1.amazonaws.com`) resolves to the private IP of the endpoint's ENI. Your EC2 instance will then connect to DynamoDB using the private IP without any code changes. If you do not enable private DNS, you must use the endpoint-specific DNS name (e.g., `vpce-xxxxxxxx.dynamodb.us-east-1.vpce.amazonaws.com`) or manually update your application's configuration.
Yes, DynamoDB supports both Gateway and Interface Endpoints. Gateway Endpoints are free and do not use security groups, while Interface Endpoints are paid and use security groups. The choice depends on your requirements: if you need security groups or private DNS, use Interface; otherwise, Gateway is simpler and cheaper.
The route table will have a more specific route for the prefix list (Gateway Endpoint) and a default route (0.0.0.0/0) pointing to the Internet Gateway. Traffic to S3 or DynamoDB will match the more specific prefix list route and go through the Gateway Endpoint, not the Internet Gateway. Other internet-bound traffic will use the Internet Gateway. This is a common configuration for private subnets that need internet access for other services but want S3/DynamoDB traffic to stay private.
First, verify that the endpoint is created and in 'Available' state using `aws ec2 describe-vpc-endpoints`. Check the route tables for the prefix list route (Gateway) or the ENI's security group (Interface). Ensure that the instance's security group allows outbound traffic to the service (HTTPS 443). For Interface Endpoints, verify that private DNS is enabled and that the instance resolves the service DNS to the private IP. Use `nslookup` or `dig` to check DNS. Also, check VPC Flow Logs to see if traffic is being sent to the endpoint. Finally, test with the AWS CLI using the `--endpoint-url` parameter for Interface Endpoints.
Yes, if your Lambda function is configured to run in a VPC (using a VPC configuration with subnets and security groups), you can use a VPC Gateway Endpoint for S3 to allow the Lambda function to access S3 privately. The Lambda function must be in a subnet that has a route to the Gateway Endpoint. Note that Lambda functions in a VPC do not have internet access by default, so a Gateway Endpoint is essential for S3 access. Alternatively, you can use an Interface Endpoint if supported, but for S3, Gateway is the standard.
You've just covered VPC Gateway and Interface Endpoints for S3/DynamoDB — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?