Amazon AWS - Creating your own Virtual Private Cloud (VPC)

Introduction

In this blog I plan to provide insight into how we can create a Virtual Private Cloud (VPC) inside Amazon AWS. I plan to create three subnets, one each for the web, application and data tier. The Web tier subnet will be in the public domain (DMZ), the other two subnets will be in private domains (network). I plan to use the private IP subnet 10.0.0.0/16 for creating the three subnets The high level steps to create a VPC are mentioned below 

Logical Architectural Diagram

 Overview of the various elements depicted in the Architectural Diagram

 Step 1 – Create a VPC

Let’s create a new VPC called “MyPrivateVPC” as shown below

Step 2 - Create subnets for the three tier’s (web, app and data)

Let’s create following subnets for the three tiers. In the three tiers, 10.0.1.0/24-web will be the public subnet, 10.0.2.0/24-app and 10.0.3.0/24-data will be the private subnets

• 10.0.1.0/24-web (make sure you enable auto-assign Public IP at this subnet level otherwise your EC2 instances will not have a public IP, you can always override this setting while creating a new EC2 instance) 

• 10.0.2.0/24-app

NOTE: For the blog I am not going to create any EC2 instances for this subnet or separate security groups, I am restricting the remainder of the discussion to be one between only two layers – web and data, but the steps are exactly the same for the app layers)

• 10.0.2.0/24-data

The screen print below shows you how to set up a subnet for the data tier similar steps are needed for the web and app tier subnets

Step 3 - Create Security Groups

Let’s create the following security groups one for web tier, one for db tier and a third one is used for the NAT instance instead of NAT gateways; in production environment use NAT gateways. Security groups in general provide the first line of defense by defining rules that allow inbound/outbound traffic. The Security Groups act at the EC2/RDS instance level unlike the Network ACL which act at the network (subnet) level independent of instances. Network ACL serve as the second line of defense.

• sg_web_access

Access rules for this group are below 

NOTE: outbound rules are similar to inbound rules in this example hence I did not provide a separate screen print

• sg_data_access

Access rules for this group are below 

NOTE: outbound rules are similar to inbound rules in this example hence I did not provide a separate screen print. Also you need to define an inbound rule for access to the database port for the 10.0.1.0/24-web subnet (if you had app tier then it should be 10.0.2.0/24-app subnet)

• sg_nat

This Security Group is used for allowing NAT EC2 instance access to act as a bridge. The NAT instance will remain in the public subnet and will act like a default gateway for the private subnets (the 10.0.2.0/24-app and the 10.0.3.0/24-data) to connect to the outside world (Internet).

The screen prints below show how you can create Security Groups, the example shows how to create “sg_web_access” security group repeat the same for other security groups

Step 4 – Create an Internet Gateway

You need an internet gateway for the VPC network to access the internet. All EC2 instances in the public subnet (10.0.1.0/24-web) will have direct access to the internet via this internet gateway as soon as this internet gateway is associated to this public subnet. All the private subnets 10.0.2.0/24-app and 10.0.3.0/24-data will go through the NAT instance to access the internet and that to only if the “sg_nat” Security group rules define for the NAT instance all the flow of traffic. In my example as I am not configuring the app tier the sg_nat inbound/outbound rules allow traffic from port 80/443 only for data tier (10.0.3.0/24-data subnet). Screen print below shows how an Internet Gateway gets attached to a VPC. 

Step 5 – Create Route Table

Now we need to create a custom route table that allows all traffic destined for internet (0.0.0.0/0) to be routed to the Internet Gateway. As shown below

Let’s now associate this route table to the public subnet 10.0.1.0/24-web as shown below

It’s this association of the custom route table to the Internet Gateway and the Subnet that makes the 10.0.1.0/24-web subnet and in turn all EC2/RDS instances in that subnet have access to the internet, that’s why we refer to this subnet as public as all the instances are exposed to the internet. It’s basically the DMZ zone.

NOTE: After Step 6 is completed you need to update the main route table for the private VPC to include the NAT instance as a getaway for all private subnet EC2 instances to access the internet so they can update their software’s (like do apt-get/yum update/installs). The screen print below shows that associations being done. 

NOTE: The status for the NAT instance says “Black Hole” because I took the screen print before the NAT instance was available for us but it should say “Active” once the NAT instance is available.

Step 6 – Create NAT instance

In order to do OS updates to EC2/RDS instances in the two private subnets 10.0.2.0/24-app and 10.0.3.0/24-data as I explained in the “sg_nat” Security group section, I plan to use a NAT instance instead of NAT gateways (later is a more production ready recommendation). The steps to configure a NAT instance are shown below

1. Choose AMI for NAT instance
2. Choose Instance Type
3. Configure the Instance
4. Add Storage
5. Tag the Instance (add custom tags for cost tracking here)
6. Configure Security Group (associate the “sg_nat” security group with this instance)

The above steps are pretty much the same for configuring any EC2 instance the only difference is that for NAT instance you need to disable Source/Destination Check and you need to disable it as this NAT instance is acting as a gateway for inbound and outbound traffic that is not originating from this instance (basically its analogous to “ip forwarding” in Linux). The screen print below shows where to go to disable this setting 

Step 7 – Create two EC2 web instances

The steps used to create EC2 instances is pretty much the same for the steps used to create NAT instance in “Step 6 – Create NAT instance” section except that the specific step to disable Source/Destination check is not needed. When you are configuring these two EC2 web instances make sure they are assigned to the public 10.0.1.0/24-web subnet and the “sg_web_access” security group.

Step 8 – Create one EC2 database instance

Since I am using EC2 instance instead of RDS for this blog the steps for creating the EC2 database instance is exactly the same as the steps used to create NAT instance in “Step 6 – Create NAT instance” section except that the specific step to disable Source/Destination check is not needed. Also when you are configuring the EC2 database instance make sure you assign it to the private 10.0.3.0/24-data subnet and the “sg_data_access” security group.

Step 9 – Left over things

A few things that I did not mention in this blog and is worth mentioning here

1. You should configure an Elastic Load balancer in front of the two web servers, AWS allows you two types, Classic and Application load balancer; Classic does balancing at Layer 4/7 of the OSI layer and Application does it at Layer 7. For the web server use Application load balancer as its going to do load balancing for HTTP protocol which is at layer 7 of OSI.
2. In my “sg_data_access” security group, I need to create an inbound rule to allow traffic from the public 10.0.1.0/24-web subnet to the port of the database running in the private 10.0.3.0/24-data subnet. NOTE: I am letting the web layer talk to the data layer as I did not create EC2 instances in the private 10.0.2.0/24-app subnet. If I had then that subnet should be allowed to access the database port not the public 10.0.1.0/24-web subnet. So my example in this blog is for a 2-tier infrastructure layer but similar steps can be used to create a 3-tier infrastructure layer, it’s just that the steps are exactly the same and I was quite frankly lazy to do the same.
3. Rules defined in Security Groups are stateful, what it means is any inbound/outbound traffic initiated will allow the corresponding outbound/inbound traffic because of the stateful nature of security groups no matter whether those rules are defined in the respective inbound/outbound rule section of the security group. Network ACL in contract are stateless and you have to explicitly define both inbound and outbound rules. Also you can allow or deny traffic in Network ACL, In security groups you only permit traffic not deny traffic
4. Network ACL are cross cutting in nature and are second line of defense, Security Groups act at the instance level and are first line of defense.
5. In order to update the EC2 instances in your private subnets you will have to first connect to one of your web servers or sometimes connect to a separate EC2 instance called “Bastion” host and then from there connect to the respective private EC2 instances using SSH and your private keys. Basically do a two hop connection.
6. If you have used a hardware VPN or AWS Direct Connect then you will be able to access your EC2 instances like any other servers on your local office network using VPN and multi-factor authentication.

Conclusion

I hope my blog will help you configure your own VPC. Feel free to leave a comment/feedback.