DynamoDB VPC endpoints: gateway, PrivateLink and setup

DynamoDB supports both gateway VPC endpoints and interface endpoints powered by AWS PrivateLink. Use a gateway endpoint for same-Region access from your VPC without a NAT gateway or additional endpoint charge. Use an interface endpoint when you need private IP connectivity from on-premises or connected networks; DynamoDB Streams supports interface endpoints only.

DynamoDB is a regional service outside your VPC

A VPC is your virtual network, with address ranges, subnets, routes and network controls. EC2 instances and VPC-connected Lambda functions use that network. A DynamoDB table does not occupy one of its subnets, and you do not attach a security group directly to the table.

Without an endpoint, an IPv4 application in a private subnet commonly needs a NAT path to reach DynamoDB's public endpoint. With a gateway endpoint, a route sends the matching DynamoDB traffic through the endpoint instead. Public IP addressing does not mean plaintext traffic: normal AWS SDK requests use HTTPS on either path.

A VPC endpoint solves connectivity and adds a policy boundary. It does not give the caller DynamoDB permissions, put the table inside your VPC, or make every service integration use your endpoint. Continue to authorize API requests with IAM policies.

Gateway vs interface endpoints

Gateway and interface endpoints can coexist. For example, use a gateway endpoint for local EC2 access and an interface endpoint for on-premises applications. AWS describes the available paths in PrivateLink for DynamoDB.

Choose based on the required network path and cost. Avoid promising that an endpoint always lowers query latency: DynamoDB operation latency, client connection reuse, retries and the rest of the network still matter. Removing a NAT dependency can simplify the path, but measure your workload before claiming a performance improvement.

Create a DynamoDB gateway endpoint

You need a VPC, the route tables used by the application's subnets and an authenticated role allowed to configure endpoints. The test client also needs permission for the specific DynamoDB operation you use to verify access.

1. Identify the VPC and route tables

Use the application's existing VPC rather than selecting a default VPC blindly:

aws ec2 describe-vpcs --region us-east-1 \
  --query 'Vpcs[].{Id:VpcId,Cidr:CidrBlock}'

aws ec2 describe-route-tables --region us-east-1 \
  --filters Name=vpc-id,Values=vpc-REPLACE \
  --query 'RouteTables[].{Id:RouteTableId,Associations:Associations}'
aws ec2 describe-vpcs --region us-east-1 \
  --query 'Vpcs[].{Id:VpcId,Cidr:CidrBlock}'

aws ec2 describe-route-tables --region us-east-1 \
  --filters Name=vpc-id,Values=vpc-REPLACE \
  --query 'RouteTables[].{Id:RouteTableId,Associations:Associations}'

Check subnet associations, including any subnet using the main route table. An endpoint associated with an unrelated route table will not help the function or instance you are testing.

2. Check the endpoint service

aws ec2 describe-vpc-endpoint-services \
  --region us-east-1 \
  --service-names com.amazonaws.us-east-1.dynamodb
aws ec2 describe-vpc-endpoint-services \
  --region us-east-1 \
  --service-names com.amazonaws.us-east-1.dynamodb

Keep the table, request Region and gateway endpoint Region aligned. A gateway endpoint does not become a route to every DynamoDB Region.

3. Create the endpoint with a scoped policy

Save the policy in the next section as dynamodb-endpoint-policy.json, replace the VPC and route-table IDs, then create the endpoint:

aws ec2 create-vpc-endpoint \
  --region us-east-1 \
  --vpc-id vpc-REPLACE \
  --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.us-east-1.dynamodb \
  --route-table-ids rtb-REPLACE \
  --policy-document file://dynamodb-endpoint-policy.json
aws ec2 create-vpc-endpoint \
  --region us-east-1 \
  --vpc-id vpc-REPLACE \
  --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.us-east-1.dynamodb \
  --route-table-ids rtb-REPLACE \
  --policy-document file://dynamodb-endpoint-policy.json

The endpoint creates the relevant service route in the associated route tables. Follow the gateway endpoint documentation for DNS, address-family and network-rule requirements.

This diagram illustrates the gateway path; an interface endpoint adds network interfaces and security groups instead.

4. Verify from the actual workload subnet

For an Orders table with a string partition key pk, test an allowed read using the application's role:

aws dynamodb get-item \
  --region us-east-1 \
  --table-name Orders \
  --key '{"pk":{"S":"ORDER#123"}}'
aws dynamodb get-item \
  --region us-east-1 \
  --table-name Orders \
  --key '{"pk":{"S":"ORDER#123"}}'

A successful response with no item can still establish that the request was authorized and reached the service. ListTables is not a suitable test for a policy that intentionally omits table discovery. Confirm the route association and endpoint policy as well; a successful request alone might have used another available route.

Write an endpoint policy that actually permits reads

DescribeTable and ListTables inspect metadata; they do not read item data. This endpoint policy allows item reads and queries on one table and its indexes:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ReadOrders",
    "Effect": "Allow",
    "Principal": "*",
    "Action": [
      "dynamodb:GetItem",
      "dynamodb:BatchGetItem",
      "dynamodb:Query"
    ],
    "Resource": [
      "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
      "arn:aws:dynamodb:us-east-1:123456789012:table/Orders/index/*"
    ]
  }]
}
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ReadOrders",
    "Effect": "Allow",
    "Principal": "*",
    "Action": [
      "dynamodb:GetItem",
      "dynamodb:BatchGetItem",
      "dynamodb:Query"
    ],
    "Resource": [
      "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
      "arn:aws:dynamodb:us-east-1:123456789012:table/Orders/index/*"
    ]
  }]
}

Principal: "*" here does not make the table publicly readable. Each request still needs authorization from applicable IAM and resource policies. Narrow the endpoint's principal scope too when multiple workloads share it.

An endpoint policy limits requests through that endpoint; it does not prohibit requests over other endpoints. If the requirement is “access only through approved endpoints,” enforce that in the relevant identity or resource policies using the appropriate VPC endpoint condition. Test administrative access and AWS service integrations before adding broad explicit denies.

Interface endpoints and endpoint-specific DNS

For PrivateLink, create an interface endpoint for the DynamoDB service in selected subnets, and allow HTTPS from the client network in the endpoint security group. Use the endpoint-specific DNS name returned by AWS. Do not assume a private hosted zone can transparently replace every regional or account-based DynamoDB hostname.

For example, with AWS SDK for JavaScript v3:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({
  region: "us-east-1",
  endpoint: process.env.DYNAMODB_INTERFACE_ENDPOINT_URL,
})
import { DynamoDBClient } from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({
  region: "us-east-1",
  endpoint: process.env.DYNAMODB_INTERFACE_ENDPOINT_URL,
})

Set that variable to the full HTTPS endpoint URL, not a guessed hostname. The signing Region remains the table's Region. From on-premises, verify the VPN or Direct Connect route, return routing, DNS resolution and security group rules. A private IP that resolves correctly still needs a reachable network path.

DynamoDB Streams needs its own interface endpoint

The service name for Streams is com.amazonaws.us-east-1.dynamodb-streams in this example Region. A gateway endpoint for table APIs does not carry Streams API calls. Custom stream readers should use a Streams SDK client configured for the endpoint returned for that service.

The Streams PrivateLink documentation covers its endpoint policy and DNS names. A Lambda event source mapping is a managed poller; do not assume its polling originates from the function's subnet merely because the function has VPC configuration. Distinguish managed polling from direct Streams API calls made by your own code.

Lambda, AppSync and DAX use different paths

A Lambda function does not need VPC configuration merely to call DynamoDB. If it also needs private resources, configure its subnets and give those subnets a working DynamoDB route. For permission failures, use the Lambda IAM guide; for connection timeouts, inspect routes, DNS and network rules first.

An AppSync private API uses an AppSync interface endpoint for clients calling GraphQL. That is different from a DynamoDB endpoint. A direct DynamoDB data source uses its configured service role; creating a DynamoDB gateway endpoint in the client's VPC does not force the resolver's service-side request through it. See AppSync private APIs.

DAX clusters run inside a VPC and have their own network interfaces, subnet groups and security groups. Applications connect to the DAX cluster endpoint using a DAX client. DAX PrivateLink covers management APIs; it does not replace the cluster's data endpoint. Review DynamoDB and DAX encryption separately from connectivity.

IPv6 and dual-stack access

DynamoDB supports dual-stack endpoints, including table and Streams endpoints, with IPv6 support for gateway and interface access where available. A regional table hostname is dynamodb.us-east-1.api.aws; Streams uses streams-dynamodb.us-east-1.api.aws. Do not assume an older IPv4 endpoint or route automatically provides the same path for IPv6.

Before enabling dual-stack clients, check the Region's current endpoint support, subnet addressing, endpoint IP-address configuration and security rules. Update IP-based IAM conditions to include intended IPv6 ranges, or previously authorized clients may be denied. The DynamoDB endpoint documentation explains the address families; availability should be checked for the actual Region.

Data pipelines and troubleshooting

For new scheduled analytics or copy workflows, prefer native exports or current ETL tooling rather than beginning with AWS Data Pipeline, which is unavailable to new customers. An EC2 or Glue worker that calls DynamoDB directly needs its own network path and role. A managed export to S3 is a different service operation, covered by the table-copy guide.

When a request fails, classify it before changing the network:

• Timeout or connection error: check the workload's subnet route table, endpoint state, DNS, security groups, network ACLs and address family.
• Access denied: check the execution identity, IAM policy, endpoint policy, table policy and encryption-key access.
• Table not found: confirm Region, account and table name or ARN.
• Throttling: inspect capacity and retry behavior; a new endpoint does not automatically solve table-level throttling.