On March 19, 2023, AWS announced Amazon DynamoDB support for AWS PrivateLink. AWS PrivateLink provides private connectivity between virtual private clouds (VPCs), supported AWS services or partner services, and your on-premises networks without exposing your traffic to the public internet. With AWS PrivateLink, customers now have another way other than VPC Gateway endpoints to privately communicate with their the DynamoDB resources.

In this blog post we will cover the following:

• What are VPC Endpoints
• Why PrivateLink-backed interface VPC endpoints with DynamoDB is important
• How to set up an Interface Endpoint for DynamoDB
• Some caveats

What are VPC Endpoints?

Let’s start first by acknowledging that one of the key tenets of cloud computing is the access to pools of IT resources over the internet. AWS services, especially the first ones, were designed to be accessed by any persons or application with internet access. Then came the need to provide proper segmentation and isolation of different customer workloads, so in 2009 the the Amazon Virtual Private Cloud (VPC) was born.

With VPCs, customers could build and run their workloads more securely with control over what traffic is allowed in and out of them. Public facing resources such as load balancers are placed in public subnets to receive requests from the internet and other servers such as application and database services could be placed in private subnets with no direct access to the internet. If your private servers require internet access to perhaps download updates and security patches or communicate with other public AWS services, you could use a Nat appliance.

What if a customer has workloads that shouldn’t have any access to the public internet perhaps for compliance reasons? The answer is VPC Endpoints.

VPC Endpoints enable customers to privately connect to supported AWS services from with their VPCs. For example, EC2 instances wouldn’t require a public IP, or NAT device to communicate with public AWS Services. But how does this happen from within a VPC?

Firstly, VPC endpoints are fully managed virtual devices that scale horizontally and are highly available within the Availability Zones (AZs) where they are deployed.

There are 2 types of VPC endpoints:

• Gateway Endpoints
• Interface Endpoints

They both achieve the same aim, but differ on how they do so which is very crucial.

Gateway Endpoints

Gateway Endpoints are the first generation of VPC endpoints. They are easy to setup but limited as they were only designed to solve the routing problem of how to reach the IP addresses of the supported services’ API endpoints without using the Internet Gateway or Nat Gateway. The Gateway Endpoint installs an AWS managed prefix-list, and a target (also referred to as destination) in the private route table used by the workloads within your VPC that require access to Amazon S3 and Amazon DynamoDB which are the only supported services. The workloads don’t need public IP addresses or NAT devices as the route table points the traffic destined for the S3 or DynamoDB endpoints IP addresses to the Gateway Endpoint target.

Interface Endpoints

VPC Interface Endpoints was released after Gateway Endpoints and are powered by AWS PrivateLink. They support a broader list of AWS services which keeps growing, as we just saw with the recent support for Amazon DynamoDB. But how are they different from Gateway Endpoints?

Firstly, they are implemented with one or more Elastic Network Interfaces (ENI) in your private subnets. The ENIs are the entry-point into the support service and are assigned private IPs from your private subnet CIDR. Any DNS query to any supported service will resolve to the private IP address of the ENI so no layer 3 routing is required.

Secondly, they support not only AWS Services but other partner services enabling the private connectivity to 3rd party SaaS products.

Thirdly, you can secure access to the Interface Endpoint ENI via security groups to control which resources in your VPC can access the endpoint ENI.

Lastly, Interface Endpoints support both IPv4 and IPv6 while Gateway Endpoints only support IPv4

Why PrivateLink-backed interface VPC endpoints for DynamoDB is important

Though the Gateway Endpoint support for DynamoDB is simpler to setup and manage, it introduced certain limitations due to the nature in which the private connectivity to the supported AWS service was attained. As explained earlier, it installs an AWS-managed prefix-list that contains the public IP addresses of the DynamoDB service’s endpoints with a target or destination in the private route table. The private route table is a resource within the VPC for associated subnets. So for any traffic to use the Gateway Endpoint, it must have originated from a resource within the private subnet. This in and of itself is not a problem but in scenarios where you want to centralize access to your DynamoDB resources either from other VPCs or on-premise, your traffic won’t reach the Gateway Endpoint. As stated in the Amazon VPC Documentation:

Endpoint connections cannot be extended out of a VPC. Resources on the other side of a VPN connection, VPC peering connection, transit gateway, or AWS Direct Connect connection in your VPC cannot use a gateway endpoint to communicate with DynamoDB.

Consequently Gateway Endpoints are not natively compatible with AWS Direct Connect or AWS Virtual Private Network (AWS VPN).

A workaround is to setup a device or firewall in your private subnet to proxy requests from other networks such as on-premise to the Gateway Endpoint. This will work but it introduces an additional device for you to manage, scale and secure. Plus you also need to deploy them in multiple AZs for high availability.

Interface Endpoints for DynamoDB backed by AWS PrivateLink enables the following connectivity scenarios:

Private access from on-premises using AWS hybrid connection solutions like AWS VPN and AWS Direct Connect

Source

Cross-Region DynamoDB Access Using Private IP Addresses

Source

How to Set up an Interface Endpoint for DynamoDB

You can create the Interface Endpoint for DynamoDB with or without DynamoDB tables or resources. Remember an Interface Endpoint is just a door into the Amazon DynamoDB service itself not a specific resource in the service. But at least, there must be a VPC and one or two subnets for workloads that need access to the Interface Endpoint.

Setting it up with an Infrastructure-as-code tool like Hashicorp Terraform can be achieved with just a few lines of code:

  
resource "aws_vpc_endpoint" "ddb_ep" {
  vpc_endpoint_type   = "Interface"
  service_name        = "com.amazonaws.${var.region}.dynamodb"
  vpc_id              = aws_vpc.this.id
  security_group_ids  = [aws_security_group.ddb_ep_sg.id]
  subnet_ids          = [aws_subnet.vpn_sn_az1.id]
  tags = {
    Name = "dynamodb-endpoint"
  }
}
  

• vpc_endpoint_type = "Interface" specifies the type of VPC endpoint being created. In this case, it's an Interface Endpoint, which allows communication between resources inside your VPC and the DynamoDB service over the AWS PrivateLink network.
• service_name = "com.amazonaws.${var.region}.dynamodb" specifies the service name for the VPC endpoint. Pay attention to the service identifier for DynamoDB.
• vpc_id = aws_vpc.this.id specifies the ID of the VPC in which the VPC endpoint will be created.
• security_group_ids = [aws_security_group.ddb_ep_sg.id] specifies the security groups associated with the VPC endpoint. This is an extra layer of security not available for Gateway Endpoints.
• subnet_ids = [aws_subnet.vpn_sn_az1.id] specifies the subnets in which the network interface for the VPC endpoint will be provisioned. This enables the creation of the ENI which will take up one of the IP addresses in the subnet.

The code samples are from this project on GitHub. It is a simple project the demonstrates how DynamoDB development can occur via an AWS Client VPN connection to a VPC with no internet access.

Caveats

Gateway endpoints for DynamoDB have no data processing or hourly charges associated with its usage while Interface Endpoints are charged per AZ, per hour and data processing (depending on your Region).

Conclusion

Both Interface and Gateway Endpoints keep traffic within the AWS network for DynamoDB access. Use Gateway Endpoints for interactions if there are is no need for transitive access to your DynamoDB resources from your on-premise network or another VPC in another Region via a peering connection. Use Interface Endpoints for DynamoDB for private access to DynamoDB from your on-premise network or if you require more security.

References

https://aws.amazon.com/blogs/database/simplify-private-connectivity-to-amazon-dynamodb-with-aws-privatelink/

What are VPC endpoints? - Securely Access Services Over AWS PrivateLink

https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html

‍