Connecting Serverless Django to an Amazon RDS Instance (Part 2)

 - Please read the first part of this blog post 

 before proceeding. It walkthrough the initial steps of creating a VPC with two subnets, one private and one public, to restrict access of the RDS database to the deployed Lambda function within the same network.

 (RDS) is an AWS cloud computing solution that enables developers to quickly provision, deploy and scale popular relational databases, such as PostgreSQL, on reliable infrastructure. 

To create an RDS instance, visit the Amazon RDS console and click on the "Create database" button.

Select "Standard create" as the database creation method. This gives us control over the configuration options, such as whether backups should be performed. Then, select "PostgreSQL" as the engine type. You can choose a specific version within the proceeding dropdown, but for this tutorial, let's stick with already pre-selected version 

Under templates, choose the "Free tier" to avoid being billed for RDS-related costs while following this tutorial. For larger, commercial projects, you would create, at minimum, two separate RDS instances: one for a production environment and one for a development environment.  

Label the instance with a unique, valid identifier. For this tutorial, let's name it 

 to indicate its connection to the serverless Django application. Then, set superuser credentials for the instance. Remember to use a strong password!

Once you set these credentials, add them to the 

, which corresponds to the free tier. Each class tier comes with different memory and CPU specifications, with 

Leave the storage settings as is, but uncheck storage autoscaling since our database will never exceed its maximum storage capacity.

The "Availability & durability" section is automatically disabled because of our earlier selection of the free tier. Multi-AZ deployment should be enabled in the production environment of a large, commercial project to ensure the database is durable and highly available.

Under the "Connectivity" section, select the VPC created in 

 of this tutorial. For subnet group, select the option "Create new DB Subnet Group" and disallow public access. We do not want to assign a public IP address to the database, otherwise, anyone from the public Internet can access the database and its contents if they correctly guess your superuser credentials or exploit a known vulnerability of the database. The database should only accept connections from our Lambda function within the same VPC. 

For the VPC security group, create a new VPC security group for this database and name it 

. Keep the availability zone to "No preference."

: You can choose an existing VPC security group, which would be the VPC's default security group named "default," which is listed under the "Security Groups" table in the AWS VPC console.

Keep the database authentication method as password authentication.

Uncheck automatic backups and performance insights. These features are useful for the production environment of a large, commercial project. Keep the remaining settings the same.

Click the "Create database" button to create the database instance.

However, an error message appears when you try to create the database instance. Our VPC requires at least two private subnets to cover at least two availability zones to satisfy the database's availability zone coverage requirement. 

 provide isolation within a region. When an availability zone experiences anytime network issues of downtime, other availability zones are highly unlikely to experience the same issues. Subnets covering these availability zones will be available while issues are being resolved in the affected availability zones. Therefore, we need to revisit the AWS VPC console and add another private subnet that covers a different zone than the current private subnet.

Open the AWS VPC console in a new browser tab/window. Select the VPC's private subnet from the table of subnets. Within its details, take note of the subnet's availability zone ID (in the below screenshot, it is 

). When we create another private subnet, its availability zone cannot have the same availability zone ID.

Let's create a new private subnet. Select the VPC in the dropdown. Under the "Subnet settings" section, you can assign any name to the subnet, but for this tutorial, it will simply be named "Private subnet." When you choose an availability zone for this subnet, pick one that is different from the one already covered. In the below screenshot, since 

 is already covered by our other private subnet, let's pick 

Set the private subnet's IPv4 CIDR block to 

. Then, click the "Create subnet" button to create the private subnet. 

Once the private subnet is successfully created, close out the browser tab/window 

Toggle back to the previous tab/window with the database creation wizard and click the "Create database" button. The error message disappears, and you should now be able to successfully create the database instance.

Currently, the database is publicly accessible from the public Internet. Let's limit this access to only resources within the same VPC.

) within the table of databases in the Amazon RDS console. 

Scroll down to the "Security group rules" section. Since the database's inbound traffic is being restricted, click on the first security group with the type "CIDR/IP - Inbound" to modify the inbound traffic rules. 

Under the "Inbound rules" section, click on the "Edit inbound rules" button.

Delete the default inbound rule and add a new inbound rule. Set this rule's type to "PostgreSQL" and source to "Custom."

If you created a new VPC security group for the database, then select that security group from the field with the magnifying glass. However, if you chose to use an existing VPC security group, then select that security group from the field with the magnifying glass. Click the "Save rules" button.

You can now find this new security group rule inside of the security group rules' table with type "EC2 Security Group - Inbound."

Continue on to the last part of this tutorial 

, which dives into deploying the serverless Django application onto AWS Lambda with Zappa.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Tutorials on Aws

Connecting Serverless Django to an Amazon RDS Instance (Part 2)

Email Newsletter

Popular Topics

Masterclasses

Tutorials

Fullstack React with TypeScript