VPC endpoints for private access in DynamoDB - Mini Project: Build & Apply

VPC Endpoints for Private Access to DynamoDB

📖 Scenario: You work for a company that wants to securely access its DynamoDB tables from within a Virtual Private Cloud (VPC) without using the public internet. To do this, you will set up VPC endpoints that allow private access to DynamoDB.

🎯 Goal: Build a DynamoDB table and configure a VPC endpoint policy that allows private access to the table from your VPC.

📋 What You'll Learn

Create a DynamoDB table named Employees with a primary key EmployeeID of type string.

Define a VPC endpoint policy that allows dynamodb:Query and dynamodb:GetItem actions on the Employees table.

Configure the VPC endpoint policy JSON with the correct resource ARN for the Employees table.

Ensure the policy restricts access only to the Employees table.

💡 Why This Matters

🌍 Real World

Companies use VPC endpoints to securely connect to AWS services like DynamoDB without exposing traffic to the public internet, improving security and reducing latency.

💼 Career

Cloud engineers and database administrators often configure VPC endpoints and policies to control access to cloud databases in enterprise environments.

1

Create the DynamoDB table

Create a DynamoDB table named Employees with a primary key called EmployeeID of type string.

DynamoDB

# Create the DynamoDB table Employees with primary key EmployeeID of type string
# Your code here

Hint

Use the AWS CLI create-table command with the correct attribute definitions and key schema.

2

Define the VPC endpoint policy template

Create a JSON variable called vpc_endpoint_policy that allows dynamodb:Query and dynamodb:GetItem actions on the DynamoDB resource ARN for the Employees table. Use the ARN format arn:aws:dynamodb:region:account-id:table/Employees as a placeholder.

DynamoDB

aws dynamodb create-table \
    --table-name Employees \
    --attribute-definitions AttributeName=EmployeeID,AttributeType=S \
    --key-schema AttributeName=EmployeeID,KeyType=HASH \
    --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

# Define the VPC endpoint policy JSON variable
vpc_endpoint_policy = '''
{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:Query", "dynamodb:GetItem"],
      "Resource": "arn:aws:dynamodb:region:account-id:table/Employees"
    }
  ]
}
'''
# Your code here

Hint

Write the JSON policy as a multiline string assigned to vpc_endpoint_policy.

3

Replace placeholders with actual region and account ID

Update the vpc_endpoint_policy JSON string to replace region with us-east-1 and account-id with 123456789012 in the resource ARN.

DynamoDB

aws dynamodb create-table \
    --table-name Employees \
    --attribute-definitions AttributeName=EmployeeID,AttributeType=S \
    --key-schema AttributeName=EmployeeID,KeyType=HASH \
    --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

# Replace placeholders in vpc_endpoint_policy
vpc_endpoint_policy = '''
{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:Query", "dynamodb:GetItem"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Employees"
    }
  ]
}
'''
# Your code here

Hint

Replace the placeholders exactly as shown in the resource ARN string.

4

Attach the VPC endpoint policy

Use the AWS CLI command to create a VPC endpoint for DynamoDB with the policy document set to the vpc_endpoint_policy JSON string. Use --vpc-id vpc-0abc123def456 and --service-name com.amazonaws.us-east-1.dynamodb in the command.

DynamoDB

aws dynamodb create-table \
    --table-name Employees \
    --attribute-definitions AttributeName=EmployeeID,AttributeType=S \
    --key-schema AttributeName=EmployeeID,KeyType=HASH \
    --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

vpc_endpoint_policy = '''
{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:Query", "dynamodb:GetItem"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Employees"
    }
  ]
}
'''

# Create the VPC endpoint with the policy
aws ec2 create-vpc-endpoint \
    --vpc-id vpc-0abc123def456 \
    --service-name com.amazonaws.us-east-1.dynamodb \
    --policy-document "$vpc_endpoint_policy"
# Your code here

Hint

Use the AWS CLI create-vpc-endpoint command with the correct options and policy document variable.

Practice

1. What is the main benefit of using a VPC endpoint for DynamoDB access?

easy

A. It allows private access to DynamoDB without using the internet.

B. It increases the internet bandwidth for DynamoDB queries.

C. It automatically backs up DynamoDB tables.

D. It enables cross-region replication of DynamoDB data.

Solution

1. Step 1: Understand VPC endpoint purpose

   A VPC endpoint lets you connect to AWS services privately inside your cloud network without internet traffic.

2. Step 2: Identify benefit for DynamoDB

   Using a VPC endpoint for DynamoDB means your data traffic stays inside AWS, improving security and privacy.

3. Final Answer:

   It allows private access to DynamoDB without using the internet. -> Option A

4. Quick Check:

   Private access = VPC endpoint benefit [OK]

Hint: VPC endpoints keep traffic inside AWS, no internet needed [OK]

Common Mistakes:

• Confusing VPC endpoints with internet bandwidth
• Thinking VPC endpoints backup data
• Assuming VPC endpoints replicate data across regions

2. Which AWS CLI command is used to create a VPC endpoint for DynamoDB?

easy

A. aws s3 create-vpc-endpoint --service-name com.amazonaws.region.s3

B. aws dynamodb create-endpoint --vpc-id vpc-123456

C. aws ec2 create-vpc-endpoint --service-name com.amazonaws.region.dynamodb

D. aws ec2 create-vpc --service-name dynamodb

Solution

1. Step 1: Identify correct AWS CLI service for VPC endpoints

   VPC endpoints are managed via the EC2 service commands, not DynamoDB or S3 commands.

2. Step 2: Match correct syntax for DynamoDB endpoint

   The command uses 'aws ec2 create-vpc-endpoint' with the service name for DynamoDB in the region.

3. Final Answer:

   aws ec2 create-vpc-endpoint --service-name com.amazonaws.region.dynamodb -> Option C

4. Quick Check:

   EC2 CLI + DynamoDB service name = create VPC endpoint [OK]

Hint: VPC endpoints use EC2 CLI, not DynamoDB CLI [OK]

Common Mistakes:

• Using dynamodb CLI instead of ec2 CLI
• Confusing S3 service name with DynamoDB
• Trying to create VPC instead of VPC endpoint

3. Given this AWS CLI command, what will it do?

aws ec2 create-vpc-endpoint --vpc-id vpc-abc123 --service-name com.amazonaws.us-east-1.dynamodb --subnet-ids subnet-1a2b3c --security-group-ids sg-123abc

medium

A. Creates a new VPC with DynamoDB access enabled.

B. Creates a VPC endpoint for DynamoDB in the specified VPC with subnet and security group.

C. Deletes the specified subnet and security group.

D. Creates a DynamoDB table in the specified subnet.

Solution

1. Step 1: Analyze the command components

   The command uses 'create-vpc-endpoint' with a VPC ID, service name for DynamoDB, subnet IDs, and security group IDs.

2. Step 2: Understand the effect of the command

   This creates a VPC endpoint inside the given VPC, allowing private DynamoDB access through specified subnets and security groups.

3. Final Answer:

   Creates a VPC endpoint for DynamoDB in the specified VPC with subnet and security group. -> Option B

4. Quick Check:

   Create VPC endpoint + DynamoDB service = private access setup [OK]

Hint: Look for 'create-vpc-endpoint' and DynamoDB service name [OK]

Common Mistakes:

• Thinking it creates a new VPC
• Confusing creation with deletion
• Assuming it creates DynamoDB tables

4. You tried to create a VPC endpoint for DynamoDB but got an error: "InvalidSubnetID.NotFound". What is the most likely cause?

medium

A. The security group ID is missing from the command.

B. The DynamoDB table name is incorrect.

C. Your VPC does not have an internet gateway attached.

D. The subnet ID provided does not exist in your AWS account or region.

Solution

1. Step 1: Understand the error message

   "InvalidSubnetID.NotFound" means the subnet ID given is not found or invalid in your AWS environment.

2. Step 2: Identify cause related to subnet

   This usually happens if the subnet ID is mistyped, deleted, or belongs to a different region/account.

3. Final Answer:

   The subnet ID provided does not exist in your AWS account or region. -> Option D

4. Quick Check:

   InvalidSubnetID error = wrong or missing subnet ID [OK]

Hint: Check subnet ID spelling and region first [OK]

Common Mistakes:

• Blaming DynamoDB table name for subnet errors
• Assuming internet gateway is required for VPC endpoint
• Ignoring subnet ID in error diagnosis

5. You want to ensure all DynamoDB traffic from your private subnet uses a VPC endpoint without going through the internet. Which setup is required?

hard

A. Create a DynamoDB VPC endpoint in your VPC, associate it with your private subnet, and update route tables accordingly.

B. Attach an internet gateway to your VPC and enable public IPs on your instances.

C. Create a NAT gateway and route all DynamoDB traffic through it.

D. Enable DynamoDB global tables for cross-region access.

Solution

1. Step 1: Understand private subnet traffic needs

   Private subnets do not have direct internet access, so to reach DynamoDB privately, a VPC endpoint is needed.

2. Step 2: Configure VPC endpoint and routing

   Create a DynamoDB VPC endpoint, associate it with the private subnet, and update route tables so traffic to DynamoDB uses the endpoint.

3. Step 3: Exclude internet gateway or NAT for this traffic

   Internet gateway or NAT gateway routes send traffic outside AWS, which is not desired for private access.

4. Final Answer:

   Create a DynamoDB VPC endpoint in your VPC, associate it with your private subnet, and update route tables accordingly. -> Option A

5. Quick Check:

   VPC endpoint + private subnet + route update = private DynamoDB access [OK]

Hint: Use VPC endpoint and route tables for private subnet access [OK]

Common Mistakes:

• Using internet gateway for private subnet traffic
• Routing DynamoDB traffic through NAT gateway unnecessarily
• Confusing global tables with network setup