Overview
Today, I'll run a hands-on lab on databases (DynamoDB, RDS).
Recreate a private EC2 instance and the SSM interface endpoints as in Day4 hands-on if you deleted them.
Hands-on
1. RDS
1. Create a DB subnet group
VPC : the VPC created in Day1 hands-on
Subnets : 2 private subnets (AZa/AZb)
2. Create a security group for the DB
Inbound : TCP3306 (source : SG attached to the EC2 instance)
Outbound : All traffic (default)
※only open for application layer! (important for the test)
3.Create DB
Engine : MySQL
Template : Free tier (If you can't use free tier, choose Dev/Test)
DB instance class : db.t3.micro
Multi-AZ : Off
Storage : gp3
VPC : Day1 VPC
Subnet group : the subnet group created in the previous step
Public accessible : No
VPC security group : the security group created in the previous step
Authentication : password authentication
Check the endpoint!(xxxxx.rds.amazonaws.com)
4. Connection verification
Execute the following commands and ensure that the EC2 instance can access the DB
DB_ENDPOINT=<your-db-endpoint>
timeout 5 bash -c "cat < /dev/null > /dev/tcp/${DB_ENDPOINT}/3306" && echo "TCP OK" || echo "TCP NG"
If you receive "TCP OK", the instance could access to the DB!
2. DynamoDB
DynamoDB is not deployed inside your VPC. You need to call the DynamoDB API endpoints, so you need NAT or DynamoDB Gateway Endpoint to reach the DB.
1. Create DynamoDB Gateway Endpoint
Service : com.amazonaws..dynamodb(Gateway)
Route tables : Private route table
Policy : Full access
2. Create DynamoDB table
Partition key : pk (string)
Capacity mode : On-demand
3. Attach the permissions to the EC2 instance
the IAM role attached to the EC2 instance → Add permissions → Create inline policy → Add following policy to allow EC2 instance to access to the DynamoDB
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DynamoRWForOneTable",
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:GetItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource": "arn:aws:dynamodb:<your-region>:<your-account-id>:table/<your-table-name>"
}
]
}
4. Access to the DB from the EC2 instance
Set variables.
REGION=<your-region>
TABLE=<your-table-name>
Put a sample item into the table (partition key = user#001, name = sora, age = 27)
※DynamoDB is the KVS (=key/value + Attributes) DB, so use key (= A key for uniquely identifying an item) and attributes (= Data other than keys). If you use the same key with the previous data, the old data is overwritten.
aws dynamodb put-item \
--region $REGION \
--table-name $TABLE \
--item '{"pk":{"S":"user#001"},"name":{"S":"sora"},"age":{"N":"27"}}'
Get the item from the DB using the partition key "user#001".
aws dynamodb get-item \
--region $REGION \
--table-name $TABLE \
--key '{"pk":{"S":"user#001"}}'
If you can receive the date put in the previous step, you can correctly use DB!
3. Tidying-up
- Delete RDS
- Delete DynamoDB table
- Delete DynamoDB gateway endpoint
- Delete EC2 instance
For test
Key exam points related to today's services.
RDS/Aurora
- use Multi AZ for the HA (not for improvement of reading performance)
- use Read Replica for improvement of the reading performance
- create DB in the private subnets and attach SG allow application SG → DB port
- use SCT when migrate to the different types of DB (ex. Oracle → Aurora)
- use DMS when you want to minimize the downtime during the migration.
DynamoDB
- When searching for data using queries, use keys (it's not good at searching for attributes).
- Use correct type Unpredictable, spikes needed → On-demand Cost optimization with stable traffic → Provisioned
- DynamoDB is not created in the VPC! The EC2 instances should access to the DB using NAT or DynamoDB gateway endpoint!
See you soon in Day6 hands-on!











Top comments (0)