VPC peering fails to allow DynamoDB access from private subnet

Cloud Platforms Amazon Web Services (AWS)
, , , , , , , ,
1

We’ve set up VPC peering between two VPCs to enable our application in VPC-A (private subnet) to access DynamoDB tables in VPC-B. The peering connection shows as active, route tables are updated, and security groups allow all traffic between the VPCs. However, our application consistently fails with access denied errors when trying to reach DynamoDB.

Here’s our connection attempt:

import boto3
dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
table = dynamodb.Table('ProductCatalog')
response = table.get_item(Key={'ProductID': '123'})
# Error: Unable to reach DynamoDB endpoint

The application works fine when we test from a public subnet with an internet gateway, but fails completely through the VPC peering connection. We’ve verified the peering connection is active and routes are propagated. Security groups allow port 443 for HTTPS. What are we missing in our VPC peering configuration for DynamoDB access?

2

Let me provide the complete solution addressing all three aspects of your issue: VPC peering limitations, DynamoDB access requirements, and VPC endpoint configuration.

Understanding VPC Peering Limitations: VPC peering only routes traffic between resources that exist within the peered VPCs themselves. DynamoDB is a managed AWS service with endpoints outside your VPC, so peering connections cannot route to it. This is why your connection fails through peering but works from public subnets with internet gateway access.

Setting Up VPC Endpoints for DynamoDB: The proper solution is to create a Gateway VPC Endpoint for DynamoDB in VPC-A. Here’s the configuration:

  1. Navigate to VPC Console → Endpoints → Create Endpoint
  2. Select Service: com.amazonaws.us-east-1.dynamodb (Gateway type)
  3. Choose VPC-A and select the route tables associated with your private subnets
  4. The endpoint automatically adds routes to the selected route tables

Endpoint Configuration:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "dynamodb:*",
      "Resource": "*"
    }
  ]
}

Verification Steps: After creating the endpoint, verify your route tables contain entries like:

  • Destination: pl-xxxxx (DynamoDB prefix list)
  • Target: vpce-xxxxx (your endpoint ID)

Your security groups need outbound rules allowing HTTPS (port 443) to the DynamoDB service. The application code you shared will work without changes once the endpoint is active.

Important Notes:

  • Gateway endpoints for DynamoDB are free (no hourly charges)
  • Endpoints are region-specific; us-east-1 endpoint only accesses us-east-1 tables
  • For cross-region DynamoDB access, you’d need NAT Gateway or Internet Gateway routing
  • VPC endpoint policies default to full access but can be restricted for security

This setup provides private, secure connectivity from your private subnet to DynamoDB without traversing the internet or requiring VPC peering.

3

I had a similar setup fail even after creating the endpoint because of endpoint policies. By default, Gateway endpoints allow full access, but if someone modified the policy, it might be blocking your specific DynamoDB tables or actions. Check the endpoint policy in the VPC console to ensure it allows the dynamodb:GetItem and other actions your application needs.

4

VPC peering doesn’t work the way you expect for DynamoDB access. DynamoDB is an AWS managed service that exists outside your VPC infrastructure, so VPC peering connections cannot route traffic to it. The peering only works for resources that actually reside within the peered VPCs themselves, like EC2 instances or RDS databases. When you’re accessing DynamoDB from a public subnet with an internet gateway, you’re routing through AWS’s public endpoints, which is why that works.

5

I ran into this exact issue last year. The key insight is that DynamoDB traffic always goes to AWS service endpoints, not through VPC peering. Your private subnet needs a way to reach those endpoints. You have two main options: add a NAT Gateway to route through the internet gateway (costs money for NAT and data transfer), or use VPC endpoints which is the better approach. VPC endpoints create a private connection from your VPC directly to DynamoDB without going through the internet.

6

Thanks for clarifying that VPC peering limitation. So if I understand correctly, I need to create a VPC endpoint in VPC-A specifically for DynamoDB? Will this endpoint automatically work for tables that are accessed across regions, or does it only work for tables in the same region as the VPC?

7

VPC endpoints are region-specific, so your endpoint in us-east-1 will only route to DynamoDB tables in us-east-1. If you need cross-region access, you’d need to route through an internet gateway or NAT gateway. For your current setup, create a Gateway VPC Endpoint for DynamoDB in VPC-A. This is free (no hourly charges like Interface endpoints) and provides private connectivity. Make sure to associate it with the route tables of your private subnets so traffic destined for DynamoDB gets routed through the endpoint instead of trying to go through the peering connection.