How to Configure a Private Network Environment for Amazon DynamoDB Using VPC Endpoints

Gisung Lim is a security solutions architect at Amazon Web Services Korea and Sangpill Kim is an enterprise solutions architect at Amazon Web Services Korea.

This blog post explains how to enhance the privacy and security of data transfers between Amazon DynamoDB and your corporate network using the new Amazon VPC Endpoints for DynamoDB (currently in public preview). With VPC Endpoints for DynamoDB, you can access your DynamoDB tables using private connection endpoints from within your VPC. We also explore how to prevent access to your data from unauthorized locations by using VPC endpoints (for example, preventing use of the AWS Management Console to access your DynamoDB tables from outside of your company network). Although we don’t talk about this in this blog post, you can also use VPC Endpoints for DynamoDB to help resolve regulatory issues regarding authorization and auditability of DynamoDB for confidential user data.

VPC Endpoints for DynamoDB enables Amazon EC2 instances in your VPC to access DynamoDB using their private IP addresses, without any exposure to the public Internet. This new DynamoDB feature ensures that traffic between your VPC and DynamoDB doesn’t leave the Amazon network. In this configuration, your EC2 instances don’t require public IP addresses, and you don’t need an Internet gateway, a NAT device, or a virtual private gateway in your VPC. Furthermore, you can use endpoint policies to control access to VPC endpoints.

Solution overview
Let’s assume that developers’ and administrators’ PCs in your private corporate network don’t have public Internet connectivity, and that you are using either a virtual private network (VPN) connection or AWS Direct Connect to connect between your corporate network and your VPC. This setup helps mitigate the risk of losing or disclosing personally identifiable information (PII) from the PCs. You can use a VPN to route all DynamoDB network traffic through your corporate network infrastructure to help address concerns about the privacy and security of data transfers. However, using a VPN can introduce bandwidth and availability challenges.

To resolve those challenges, we propose a new architecture based on VPC Endpoints for DynamoDB. First, we define the following objectives for our new design:

• All access to DynamoDB should be internal private communications, not using the public Internet.
• Access to DynamoDB using the AWS Management Console should be prohibited.
• All access to DynamoDB should be restricted to the permitted locations or devices, and should be logged.

To satisfy our objectives, we define four control factors, shown in the following architecture diagram.

These are the four control factors:

1. You need to deploy a bastion host and define a security group that has inbound/outbound rules to control access by developers and administrators. In the illustration preceding, the inbound rules allow only access through the IP addresses and ports of the permitted developers’ or administrators’ PCs. The outbound rules allow the AWS Command Line Interface (AWS CLI) access to VPC Endpoints for DynamoDB. For more information on bastion hosts and security groups, see the following webpages:
   1. • Linux Bastion Hosts on the AWS Cloud: Quick Start Reference Deployment
      • Amazon EC2 Security Groups for Linux Instances
2. You need to modify the routing table of the subnet with the bastion host, so that you can enable routing of AWS CLI traffic to VPC Endpoints for DynamoDB. You also need to modify the routing table of the private subnet with the EC2 instances that will access DynamoDB using the VPC endpoint. To learn more about managing routing tables, see Route Tablesin the DynamoDB documentation.
3. To prevent access to DynamoDB from the AWS Management Console, you need to disable DynamoDB console access for AWS Identity and Access Management (IAM) To learn more, see Controlling User Access to the AWS Management Consolein the IAM documentation.
4. You need to prohibit all AWS CLI requests came that come from any unauthorized locations. DynamoDB provides user-based access control using IAM policies. However, DynamoDB doesn’t provide resource-based access control (such as an Amazon S3 bucket policy). For resource control, you create a simple IAM policy to disallow traffic from any location except for the VPC. To learn more, see Overview of IAM Policies in the IAM documentation.To prevent access to DynamoDB from the AWS Management Console, you need to disable DynamoDB console access for AWS Identity and Access Management (IAM) To learn more, see Controlling User Access to the AWS Management Consolein the IAM documentation.

The control factors we’ve described preceding provide secure access control for users who have to handle private data stored in DynamoDB. You can also use another IAM policy to implement fine-grained access control for DynamoDB data, and use AWS CloudTrail to record all events within DynamoDB. To learn more, see What is AWS CloudTrail? in the CloudTrail documentation.

Creating a VPC endpoint for DynamoDB

Here is an example of creating and configuring a VPC endpoint for DynamoDB. To configure the endpoint, you use the AWS Management Console.

1. In the Amazon VPC console, choose the desired region. (In this example, we use the Singapore region: ap-southeast-1.)
2. Choose Endpoints.
   
3. Choose Create Endpoint to begin configuring your VPC endpoint.
   
4. For VPC, choose the VPC where you want to create the endpoint. For Service, choose com.amazonaws.ap-southeast-1.dynamodb. If needed, customize the Endpoint Policy value. To learn more, see read the documentation.
   
5. Choose the Route Table ID for which you want to configure the VPC endpoint for DynamoDB.This step creates additional routing rules to your route table, so network traffic flows from the subnet to DynamoDB using the endpoint you created. You won’t need to change any DynamoDB URLs or Amazon Resource Names (ARNs) in your application code. The endpoint you’re creating will change the network route for traffic between EC2 instances in your VPC and DynamoDB.
6. Choose Create Endpoint.
   
7. Choose View Endpoints. You should see the new endpoint within a few seconds.
   
8. Choose Route Tables to see the route tables for which your endpoint is configured.
   
9. For Route Table ID, choose an ID associated with a subnet to see a routing rule for DynamoDB and the target VPC endpoint. The rule is named pl-xxxxxxxx, where pl stands for “prefix list.” Make a note of this rule name, because you will need it later.

Before we test our private network communications through the VPC endpoint for DynamoDB, we need to finish configuring our architecture. This configuration includes securing a bastion host and user access.

Securing a bastion host using a security group
To secure the bastion host, we must control the inbound and outbound rules for the EC2 security group. Doing this ensures that DynamoDB administrators can only connect from whitelisted hosts. It also prevents administrators from moving data to any storage outside of the VPC, except for DynamoDB tables using the VPC endpoint. To secure the bastion host, use the following procedure:

1. Go to the EC2 console. From the navigation pane, choose Security Group.
2. Choose the security group for the bastion host.
3. Choose Inbound.
4. Choose Edit to configure an inbound rule allowing SSH traffic from your host.
5. For Type, choose SSH. For Source, choose My IP. When the settings are as you want them, choose Save.
   
6. To create a rule to route outbound traffic to the VPC endpoint for DynamoDB, choose Outbound, and then choose Edit.
7. For Type, choose All traffic. For Destination, choose Custom, and then type the prefix list you created previously—for example: pl-xxxxxxxx.Note: If you don’t remember the prefix list for your endpoint, go to the VPC console’s Route tables list. In the list, choose the route table for your bastion host subnet (pl-xxxxxxxx).When the settings are as you want them, choose Save.

Securing user access using an IAM policy
Now, we need to prevent DynamoDB administrators from accessing any hosts except for the bastion host. To do this, we create an IAM policy to deny IAM users access to all resources except for our VPC endpoint for DynamoDB, as shown in the following procedure:

1. Go to IAM console. From the navigation pane, choose Users.
2. Choose an IAM user name to act as the DynamoDB administrator, for example DDB_VPCE_User.
3. From the list of permissions, choose Add inline policy.
4. Choose Custom Policy, and then choose Select.
5. For Policy Name, type a name for your policy, for example Allow_From_VPCE_Only.
6. For Policy document, copy and paste the IAM policy following:

   {
       "Statement": [
           {
               "Action": "dynamodb:*",
               "Effect": "Deny",
               "Resource": "arn:aws:dynamodb:<your_region>:<your_account>:*",
               "Condition": {
                   "StringNotEquals": {
                       "aws:SourceVpce": "<your_endpoint_id>"
                   }
               }
           }
       ]
   }

   Substitute <your_region>, <your_account> and <your_endpoint_id> with appropriate values, as shown in this example:

   {
       "Statement": [
           {
               "Action": "dynamodb:*",
               "Effect": "Deny",
               "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:*",
               "Condition": {
                   "StringNotEquals": {
                       "aws:SourceVpce": "vpce-e2e8118b"
                   }
               }
           }
       ]
   }

7. Choose Validate Policy, and then choose Apply Policy.

Testing the solution
We have created a VPC endpoint for DynamoDB, modified the security group for the bastion host, and created an IAM policy for the DynamoDB administrator. Access to DynamoDB is now allowed through the private network only, using the bastion host and the VPC endpoint.

We will now test the secure access solution using the AWS Management Console, and using the AWS CLI from a laptop and from the bastion host.

Accessing DynamoDB from the AWS Management Console
To test access, go to the DynamoDB console. When you attempt to perform any actions related to DynamoDB tables, you receive authorization errors. In the screenshot following, we attempt to delete a table named vpce_test, but receive an error message. Authorization errors appear for all DynamoDB API calls that don’t come from the VPC endpoint, because they are denied by the IAM policy.

Accessing DynamoDB from a laptop
The IAM policy also prevents access using the AWS CLI. To test this, we will try a Scan operation from the administrator’s laptop.

To begin, we configure the AWS CLI with the IAM user’s access key and secret key.
$ aws configure
AWS Access Key ID [****************KYIQ]:
AWS Secret Access Key [****************ecrr]:
Default region name [ap-southeast-1]:
Default output format [text]:

Next, we attempt the Scan operation.
$ aws dynamodb scan –table-name vpce_test

An error occurred (AccessDeniedException) when calling the Scan operation: User: arn:aws:iam::123456789012:user/DDB_VPCE_User is not authorized to perform: dynamodb:Scan on resource: arn:aws:dynamodb:ap-southeast-1: 123456789012:table/vpce_test

Accessing DynamoDB from the bastion host
If we log in to the bastion host, we should be able to use the AWS CLI to do a Scan operation on the table. We can use the AWS CLI here because network traffic is allowed through the private network using the VPC endpoint for DynamoDB.

To log in to the bastion host, we use the ssh command.
$ ssh -i “key-pair-gisung-Singapore.pem” ec2-user@ec2-54-169-164-143.ap-southeast-1.compute.amazonaws.com
Last login: Tue Jan  3 07:45:39 2017 from 54-240-199-105.amazon.com

__|  __|_  )
_|  (     /   Amazon Linux AMI
___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2016.09-release-notes/

Now we configure the AWS CLI with the IAM user’s access key and secret key.
aws configure
AWS Access Key ID [****************KYIQ]:
AWS Secret Access Key [****************ecrr]:
Default region name [ap-southeast-1]:
Default output format [text]:

Finally, we attempt the Scan operation.
aws dynamodb scan –table-name vpce_test
1  1
ID 001
NAME Gisung Lim

Success!

Summary
In this post, we demonstrated how to securely control access to private data in DynamoDB using the newly released VPC Endpoints for DynamoDB (currently in public preview) and a bastion host. The scenario we’ve described is for a simple environment, to allow access from only a permitted location without any Internet connectivity. You can extend this example with additional security considerations—for example, you can add more granular conditions to the IAM and endpoint policies.

VPC Endpoints of DynamoDB is now available for Public Preview. Please sign up here.