Tutorials on Aws

Disclaimer - Please read the first part of this blog post here 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. AWS Relational Database Service (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 12.5-R1 . 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 serverless-django 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 .env.production file ( PG_DB_USER for the master username and PG_DB_PASSWORD for the master password). Leave the database instance class as db.t2.micro , which corresponds to the free tier. Each class tier comes with different memory and CPU specifications, with db.t2.micro offering the lowest specifications. 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 first part 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 serverless-django-db-sg . Keep the availability zone to "No preference." Note : 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. Give the database instance a name of ServerlessDjangoDB . Record this same name within the .env.production file for the environment variable PG_DB . Keep the database parameter group as default.postgres12 . 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. Availability zones 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 use1-az3 ). 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 use1-az3 is already covered by our other private subnet, let's pick US East (N. Virginia) / us-east-1f . Set the private subnet's IPv4 CIDR block to 10.0.16.0/21 . 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. Select the database (identifier serverless-django ) 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 here , which dives into deploying the serverless Django application onto AWS Lambda with Zappa.