DEV Community

Nurul Ramadhona for AWS Community Builders

Posted on • Edited on

Trying New RDS Feature: Connectivity with EC2 in 1-Click?

Have you noticed that RDS has a new feature? Yup! 3 days ago AWS announced that now RDS supports setting up connectivity between RDS and EC2 only in 1 click. We don't need to prepare VPC, subnets, security groups, etc. Wow! That sounds great, right? But some "T&Cs" are applied to make this feature work properly. How does it work?

RDS EC2 Connectivity

In case you want more information about new features, you can visit this link.

By the way, I did all of these following practices via Console because I still can't find the CLI option for this feature maybe because it just launched (CMIIW and tell me in the comment if you know any information about this). I'm sorry if you will see a bunch of images below :)

Key

The minimum network prefix (CIDR) per subnet is /24 to create the RDS DB instance in the same VPC as the EC2 instance.

For example in this case I'll be creating RDS in the Jakarta region (ap-southeast-3) which has 3 AZs.

RDS TNC

Based on my experience in "trying" this feature 2 days ago, I found some stuff you may need to know. Here we will play some scenarios, so we can be more understanding about this feature.

1. Using Custom VPC With CIDR /22

Here I use /22 because it's enough to create a subnet with /24 for each AZ (total 3). /22 can be divided into 4 pieces of /24.

Below is the diagram when I only created 1 public subnet in 1 AZ for EC2 instance before creating RDS and 2 more AZs don't have subnet yet. From this condition, 3 idle /24 is available and enough to be used by RDS to create one subnet with /24 in each AZ.

Note: In this case, I used the Free Tier template which Multi-AZ is disabled because it's just for personal testing purposes. That's why the automated backup is created in the same AZ and a stand-by instance is not created. You can use Dev/Test or Production to make those options enabled.

RDS + Snapshot

What did RDS create?

  • 1 subnet in each AZ (total 3 subnets for 3 AZs)

3 subnets

  • 2 security groups (allow 3306 from EC2 to RDS) and both are linked to each other

SG 1

SG 2

  • 1 RDS instance and its automated backup successfully created

Instance + Snapshot

Testing

RDS endpoint

RDS EC2 Connected Successfully

2. Using Default VPC

In this case, the connectivity should be successfully established because it has a CIDR that big enough to create a new subnet /24 in each AZ for RDS which is /16.

Default VPC

RDS VPC Default

3. Using Custom VPC With CIDR Smaller Than /22

The result is a failure. Why? Because /23 only can be divided into 2 /24. See the following diagram!

RDS EC2 Failed

RDS Connectivity Failed

In this case, the RDS DB instance is still created but it's using default VPC which is in a different subnet from EC2.

2 new security groups are also created by RDS for the new VPC but only the security group for EC2 is properly attached because RDS is using default subnet group of the default VPC which is a specific rule that is not configured to allow incoming traffic from EC2 port 3306 to RDS.

RDS Default SG

RDS Connectivity Failed

Q: Then, how to make it work?

A: We can't do that because we can't change VPC of both RDS and EC2

but

If you followed my scenario number 2, it created an EC2 instance and RDS in the same VPC which is the default VPC and it already has 2 security groups created by RDS. So in this case, all we can do is:

  1. "Move" EC2 instance to the default VPC where RDS is placed. You can create a new AMI from the existing EC2 instance or create a new instance. At this time, I'll use the EC2 instance that was created in scenario number 2 which is placed in default VPC and the security group created by RDS is already attached to the EC2 instance.

  2. Change the current RDS DB subnet group to other subnet groups in the same VPC. In this case, it's the default VPC that was created in scenario number 2.

Default SG

Change SG

Connected After Change SG

Alright, we are done with all the scenarios!

Clean Up

Scenario 1 (Custom VPC)

  • Delete the RDS DB instance

  • Delete the RDS DB subnet group

  • Terminate the EC2 instance

  • Delete the VPC

Scenario 2 (Default VPC)

  • Delete the RDS DB instance

  • Delete the RDS DB subnet group

  • Terminate the EC2 instance

  • Delete security groups created by RDS (please delete rules that associated with each other before deleting them)

  • Delete the route table for subnets created by RDS

  • Delete the subnets created by RDS

Scenario 3 (same as Scenario 1)

That's it for now! Thank you for coming and I'm looking forward to your feedback. Follow me to get notified when my new post is published!

Top comments (0)

Some comments have been hidden by the post's author - find out more