Amazon DynamoDB is a serverless, NoSQL, fully-managed database that delivers single-digit millisecond performance at any scale. It’s a multi-Region, multi-active, durable database with built-in security, backup and restore, and in-memory caching for internet-scale applications.
Customers can access DynamoDB from their VPC or from workloads that run on-premises with gateway endpoints. For on-premises private network connectivity to gateway endpoints, customers often set up proxy servers or firewall rules to route and restrict traffic to DynamoDB, as gateway endpoints are not compatible with AWS Direct Connect or AWS Virtual Private Network (AWS VPN). The additional infrastructure setup can increase operational load and complexity, while complicating compliance in some cases. Customers have asked for a solution that enables setting up private network connectivity for on-premises workloads with DynamoDB, without needing additional proxy infrastructure.
We are excited to announce AWS PrivateLink support for DynamoDB. With PrivateLink, you can simplify private network connectivity from on-premises workloads to DynamoDB using interface VPC endpoints and private IP addresses. Interface endpoints are compatible with Direct Connect and AWS VPN for end-to-end private network connectivity. As a result, you can eliminate the need for public IP addresses, proxy infrastructure, or firewall rules for on-premises access to DynamoDB, and maintain compliance. You can drive low-cost private network connectivity by using gateway endpoints for in-VPC network traffic and interface endpoints for on-premises network traffic to DynamoDB.
In this post, we illustrate the use of a PrivateLink-backed interface VPC endpoint with DynamoDB by emulating an on-premises environment. For more examples of using interface endpoints with PrivateLink, refer to use case examples.
On-premises access to DynamoDB using private IP addresses
For this post, let’s assume that an insurance company needs to access the quotes and claims data stored in DynamoDB to re-evaluate their risk scores stored on their on-premises mainframe systems.
The on-premises workload is a local machine that connects to the VPC in the us-west-1 Region through AWS Client VPN, and uses the interface endpoint backed by PrivateLink to interact with DynamoDB using private IP addresses. The following diagram illustrates the architecture of the setup.
The solution contains the following key components:
An AWS Client VPN endpoint is associated with the VPC
OpenVPN-based AWS Client VPN is configured on the local machine to connect to the VPC using the AWS Client VPN endpoint
A PrivateLink-backed interface VPC endpoint for DynamoDB is created and associated with the subnets of the VPC
On-premises applications running on the (local) machine can access DynamoDB tables privately using the interface VPC endpoint
In the following sections, we configure this setup and create a new PrivateLink-backed interface VPC endpoint.
Prerequisites
To get started, make sure that you have a network setup as follows:
A VPC in a Region with AWS Client VPN set up with a local machine
The interface endpoint’s security group is the same as the on-premises environment or includes an inbound rule for receiving traffic from the on-premises environment (AWS Client VPN endpoint)
If using AWS Client VPN, authorization rules of the AWS Client VPN endpoint allow traffic to the Classless Inter-Domain Routing (CIDR) blocks of subnets that the Interface endpoint is associated with
Optionally, Python3 installed on a local machine with the AWS SDK for Python (Boto3) installed
Configure the solution
Complete the following steps using Amazon Virtual Private Cloud (Amazon VPC) to create a PrivateLink-backed interface VPC endpoint for DynamoDB in a VPC in the us-west-1 Region:
Navigate to Amazon VPC and choose Endpoints in the navigation pane.
Choose Create endpoint.
For Name tag, enter an optional tag.
For Service category, select AWS services.
Search for and select the DynamoDB interface type endpoint. This is the PrivateLink-backed interface VPC endpoint for DynamoDB.
Because interface endpoints are associated with VPCs, choose your intended VPC, the subnets within the VPC that you would like to associate the interface endpoint with, and the security group you would like to configure.
Provide a VPC endpoint policy to restrict DynamoDB actions that are allowed for AWS Identity and Access Management (IAM) entities interacting with DynamoDB using the interface VPC endpoint. For this post, select Full access.
It is recommended to narrow down access within this policy based on the principle of least privilege access.
Choose Create endpoint.
The endpoint creation process may take a few minutes.
After the interface endpoint is successfully created, you will see multiple DNS names for the interface VPC endpoint, which will be specific to your VPC. The DNS names may contain a single entry for the Regional endpoint, and individual zonal entries for each Availability Zone that your configured subnets belong to.
Copy the Regional DNS name to use in your application on the local machine connected to the VPC using AWS Client VPN.
Pass the DNS name while initializing Boto3 SDK’s DynamoDB client as endpoint_url along with the appropriate region_name. This may be different for different AWS SDKs.
Cross-Region DynamoDB access using private IP addresses
Similar to the on-premises to VPC using AWS Client VPN scenario, you can also use PrivateLink-backed interface VPC endpoints to privately access cross-Region DynamoDB resources through private IP addresses. You must have the two VPCs peered and route tables update appropriately. The architecture is illustrated below.
In this case, we have a VPC-based AWS Lambda application in the us-east-1 Region that is able to access the DynamoDB table in the us-west-1 Region using the PrivateLink-backed interface VPC endpoint. The Lambda function is able to access cross-Region DynamoDB resources using the PrivateLink-backed interface VPC endpoint.
Access resources using private IP addresses
A key advantage of interface endpoints is that they resolve to private IP addresses within the specific subnets of the associated VPC. For instance, if the VPC has a CIDR range of 172.31.0.0/16 with two subnets, the interface endpoint resolves to IP addresses within this range, so at least one IP address for each subnet associated with the endpoint. See the following code:
Although the DNS name resolves publicly, because it resolves to private IP addresses that belong to the subnets of the VPC, the interface endpoint can’t be used to connect to DynamoDB from the internet, providing private access from end to end. In an on-premises setup, any traffic that gets routed to the VPC using AWS Direct Connect or AWS Client VPN can be configured to route to the interface endpoint seamlessly.
On-premises networks
To set up interface endpoints for DynamoDB when using on-premises applications, you need a Direct Connect or VPN solution to establish connectivity with the VPC. Additionally, make sure that a route is configured to the CIDR of the VPC to which the interface endpoint is associated. Furthermore, configure the security group of the interface endpoint to include an inbound rule from the on-premises network CIDR. Lastly, ensure that DNS configuration is implemented on-premises to resolve the DNS name of the interface endpoint, which is resolvable under the DynamoDB public DNS domain. For further details on network-to-VPC connectivity, refer to Network-to-Amazon VPC connectivity options.
The following diagram illustrates how a PrivateLink-backed interface VPC endpoint can facilitate the connection between on-premises applications and DynamoDB tables in the AWS Cloud. This setup also incorporates the gateway endpoint for routing in-VPC traffic.
Considerations
Consider the following when using PrivateLink-backed interface endpoints:
Whether you opt for gateway endpoints and/or interface endpoints for DynamoDB, your network traffic remains within the AWS network in both scenarios. It is recommended to continue using gateway endpoints for interactions within a single VPC, or between VPCs, while using interface endpoints for interactions from on-premises data centers. As of this writing, interface endpoints support IPv4 addresses exclusively.
PrivateLink can handle up to 100Gbps per Availability Zone per endpoint. If your company’s data transfer load per second from the on-premises data center to the DynamoDB interface endpoint exceeds 100Gbps per AZ, you can configure additional interface endpoints to accommodate your projected data transfer requirements.
There are no data processing or hourly charges associated with using gateway VPC endpoints for DynamoDB. However, standard charges apply when using interface endpoints with PrivateLink. For more information, refer to AWS PrivateLink Pricing.
Clean up
If you followed along and created resources in your AWS account, delete the AWS Client VPN endpoint, interface VPC endpoint, Lambda function, and any other AWS resources created as part of this post.
Conclusion
PrivateLink for DynamoDB enables you to simplify your network architecture by establishing connections to DynamoDB from on-premises data centers or within AWS using private IP addresses within the VPC. PrivateLink also removes the requirement for public IP addresses, configuring firewall rules, or setting up an internet gateway to access DynamoDB from on-premises locations. This new feature is accessible in all AWS Commercial Regions.
Use the PrivateLink-backed interface VPC endpoint for DynamoDB and share your feedback in the comments section.
About the authors
Aman Dhingra is a DynamoDB Specialist Solutions Architect based out of Dublin, Ireland. He is passionate about distributed systems and has a background in big data & analytics technologies. As a DynamoDB Specialist Solutions Architect, Aman helps customers design, evaluate, and optimize their workloads backed by DynamoDB.
Ashwin Venkatesh is a Senior Product Manager for Amazon DynamoDB at Amazon Web Services, and is based out of Santa Clara, California. With 25+ years in product management and technology roles, Ashwin has a passion for engaging with customers to understand business use cases, defining strategy, working backwards to define new features that deliver long-term customer value, and having deep-dive discussions with technology peers. Outside work, Ashwin enjoys travel, sports and family events.
Read MoreAWS Database Blog
