Creating a Virtual Private Cloud in AWS for a Relational Database

Walking through the AWS Console

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

This lesson preview is part of the Serverless Django with Zappa course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to Serverless Django with Zappa, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course Serverless Django with Zappa
  • [00:00 - 00:57] Hey folks, let's get busy creating the network and the database for our secure Lambda environment. This lesson is going to be completely in the AWS console. Our goal for this lesson is to create the secure networking environment, then we can deploy our Zappa project into. I want to talk a little bit about the NAT gateway down here in the right. The NAT gateway enables your Django code to access third-party APIs on the internet. For example, if you need to log into the Spotify API or some other API where you're retrieving data in order to fulfill the web requests, this is not necessary for all Django applications. Many Django applications just need database access to respond to web requests. For completeness, we're going to set up a NAT gateway during our lesson here. I will note, however, that a NAT gateway is not a free service offered by AWS.

    [00:58 - 02:04] At the time of this recording, in the US East one region, a NAT gateway costs four and a half cents per hour per NAT gateway. In addition, it's four and a half cents per gig abyte processed, or the amount of data transferred in either direction. By instantiating a NAT gateway, it's going to cost you four and a half cents per hour. Running a NAT gateway without any network traffic at all will cost around a dollar per day or $32 a month. I wanted to highlight this to prevent any surprises to your AWS bill. All right, let's get started. First, log into the AWS Management Console. Go ahead and find the service VPC or virtual private cloud. The screen may look intimidating, but we'll walk you through it. The easiest way to set up your VPC is to launch the VPC wizard. But before I do that, I have to allocate an elastic IP address that I'm going to use later for my NAT gateway. If you're not using a NAT gateway, you don't have to do this step.

    [02:05 - 02:32] Allocating an elastic IP address is pretty straightforward. Just click on allocate elastic IP address. It's going to ask you a few simple questions. The most important is where is the location of this IP address? We're going to stick to the US East one and just hit allocate. Now that we have this IP address allocated, we're going to be able to use it later in the VPC wizard.

    [02:33 - 02:44] So let's go back to the VPC dashboard. Click on launch VPC wizard. You'll see a lot of different options that you can create here, but we'll want option number two.

    [02:45 - 03:38] We want a VPC with public and private subnets. This is what we want. So let's go ahead and select it. The first text box indicates how big this entire VPC is going to be. Right now, it's set to have 65,000 IP addresses available. That's plenty for our purposes here. For VPC name, we're going to call it serverless with Django and Zappa to make sure we can identify our VPC. For our public subnet, we want a little more than 251 IP addresses. So we're going to bump that up to a slash 21 cider block. Since we've increased the side of a republic subnet, we're going to have to shift our private subnet to a different IP space. So we're going to change that right now.

    [03:39 - 04:36] Okay, now we have a public subnet configured for about 2000 IP addresses. And we have a private subnet also configured to have about 2000 IP addresses. We have no preference for availability zone, but we're going to rename our private subnet to be private one. Do you remember when we allocated an elastic IP, we're going to have to enter that now. But we don't actually have to enter it. If we click on the box, AWS automatically detect that we have an un allocated IP address available for use. So we're going to click on that. And that's pretty much it. Now click on create VPC. Great. Our VPC is successfully created. Let's go and check it out.

    [04:37 - 05:26] Click on your VPCs to see them. You should see at least two VPCs here. Every Amazon account comes with a default VPC, which is shown here. The one we just created serverless with Django and Zappa is up here at the top. We can click on that. We can see some of the details. And everything seems fine . What we're going to do next is check out our subnets. So the default view isn't very helpful. We're going to try to filter it so we can see only our VPC information. Now we're filtering all the subnets to show only the subnets within the VPC that we just created.

    [05:27 - 06:17] Let's go ahead and create a private to subnet. The reason we're creating two private subnets is to make sure they're in different availability zones. Amazon has numerous availability zones within each region. The availability zones provide isolation within the region. If there's compute or network trouble in one AZ or availability zone, other AZs will be less affected. We're going to take advantage of this model because it doesn't add any additional cost and makes our deployments more robust. When we create our private to subnet, we're going to select a different availability zone than our private one subnet. So we can look now and see that private one subnet is in us East 1A.

    [06:18 - 06:25] So when I create the next subnet, I'll make sure to choose a different one. First, we select the VPC that we've created.

    [06:26 - 07:09] And then we're going to call this private to subnet availability zone. We can choose any availability zone we'd like as long as it's different than us East 1A. So we're going to pick one E. And for our cider block, we're going to pick the next available slash 21 block and then scroll down and create subnet. Once again, let's filter by VPC. Now we can see all three of our subnets that we've created. Next, let's move on with our RDS setup.

    [07:10 - 08:01] We're going to follow the same steps as before to create our RDS instance. However, this time, we're going to configure the RDS instance to be accessible only by lambda instances deployed in the private subnet. When we create this RDS instance, we're going to follow a very similar path that we did in our last module. So we'll squeeze through that now. We're going to keep the master username as Postgres. Disable auto scaling since we're not going to be growing this database very big.

    [08:02 - 08:33] Here's where things change. We're going to change the default VPC to be the new VPC that we've created. But we're going to create a new database subnet group. This new database subnet group will be in the VPC for public access. Let's make sure we put no. And for VPC security group, let's create a new VPC security group. We're going to call this one Zappa database security group.

    [08:34 - 08:49] For availability zone, let's select something that's not a or e. Let's call it D for database. The rest of the configuration should be straightforward. Our initial database name should be Z appa course DB.

    [08:50 - 09:12] We don't need automatic backups. We don't need performance insights. And that should be it. So we've used all the same settings from the previous module. We've just changed the network settings for this VPC. Let's go ahead and create the database now.

    [09:13 - 09:46] Great. Now AWS is creating our database for us. While this is happening, we need to configure our new security group that was created by default when AWS creates this RDS instance, it is not accessible by any network traffic. So we're going to have to open it up. But we can open it up just to our private subnets and not to the internet. Let 's do that now.

    [09:47 - 09:55] Go ahead and click on the DB identifier. You'll notice the VPC security group that was created. We need to click on this one.

    [09:56 - 10:26] This security group view controlled in the inbound and outbound rules for network traffic for this database. So we need to change the inbound rules to allow traffic from our subnets. You'll notice there's a rule here right now. This rule was automatically created by AWS.

    [10:27 - 10:39] It enables the IP address of your machine inbound access to the RDS database. You may keep this rule or delete it depending on if you need to configure the database directly.

    [10:40 - 11:07] Let's go ahead and click edit inbound rules. We're going to add a rule. It's going to be post gres database. The source will be custom. When you click on the text box with a magn ifying glass, you can scroll down and you can look at your various security groups within this VPC. You notice this default VPC is here. We're going to click on that.

    [11:08 - 11:30] This subnet group applies to all new Lambda instances running in this VPC. So that means when we spin up a Lambda instance in our private subnets, they will be able to access this database. And let's add a description to remind ourselves in the future and then click on save rules.

    [11:31 - 11:51] Okay, we're all set. There was a lot of work, a lot of configuration in the AWS console. Now we can take this information and go back to our command line and configure our SAP project to deploy properly.