In every cloud architecture, there are some important factors that needs to taken into consideration, these considerations range from security, to reliability, latency and then to quick disaster recover. The implementation of these concerns differs from one cloud provider to another, however, the concepts remain the same. For this post, we will be discussing and configuring the basic Amazon Web Services that takes care of these considerations which includes that amazon Virtual Private Cloud (VPC), Subnet, Security Group, and Internet Gateway.

Let’s briefly discuss each of this services in text, before jumping right into the AWS console to deploy them. However, if you are so eager then, jump right in to the console and deploy them.

A good caution is to take note of all your deployments and delete them just after the demo.

1. VIRTUAL PRIVATE CLOUD (VPC)

According to wikipedia, a virtual private cloud (VPC) is an on-demand configurable pool of shared resources allocated within a public cloud environment, providing a certain level of isolation between the different organizations (denoted as users hereafter) using the resources. So if deploying cloud architecture will be a house, then, we can liken the VPC to be the foundation where all the other architecture rests.
The Amazon Virtual Private Cloud (VPC) is the virtual network which is logically isolated from other virtual network that is assigned to you where you can deploy your AWS cloud resources. The VPC region you choose can be a great determinant to the latency of your application to your customers. The VPC usually comes with default security group, subnet and network interface, however, we will be creating a custom version of these service. Yea, let’s go!!!

2. SUBNETS

The AWS Subnet is a set of public Internet Protocol (IP) addresses in the VPC. It is important to note that each subnet must reside in a single Availability Zones (AZ) in the AWS cloud service. Each Subnet is assigned different Classless Interdomain Routing (CIDR) bloc in the VPC which should not overlap the VPC IP/CIDR address. Your Subnet can be public (with access to public internet using Internet Gateway) or Private Subnet (which does not have access to public internet using Internet Gateway).

3. INTERNET GATEWAY

One very important component for your AWS resources especially for resources that needs access to the internet is the Internet Gateway (IGW). The Internet Gateway allows your resources such as the EC2 instance and CodeDeploy in the Public Subnet have access to the internet. It is a highly available, redundant, and horizontally scaled manage AWS service. This means, unlike the Network Address Translation (NAT) Gateway, your IGW will route traffic between the internet and your VPC. The Internet Gateway support IPv4 and IPv6 address and have no adverse effect on your application latency or availability.

4. SECURITY GROUP

In technology, the slightest security breach could mean a big disaster for the business, that is the backdrop to which AWS pays especial attention to the data security of it services. The AWS Security Group is a set of rules that allows traffic into the specified resources using its respective ports. If the VPC is a building, then the Security Group (SG) will be the door, and the port numbers will be the keys that opens each doors which can be liken to the subnets i.e. CIDR blocs. By default, no inbound traffic is allowed when you create a Security Group, until you add inbound rules to the security group, while all outbound traffics are allowed by default, this is why the Security Groups are said to be stateful. This means that you can only specify ALLOW rules in Security Group but not DENY rule.

5. ROUTE TABLE

The Route Table in simple term will help direct network traffic from the Subnet or Gateways through to the right route. This it does by checking the Route Table for the routing address or IP address of the destination of the request and find the best route to deliver such package. The AWS Route Table does the same thing using the set of rules called routes to direct traffic to the right path.

DEPLOYING THE SERVICES

Whooops!!! That’s some interesting high level overview of the VPC, Subnet, IGW and SG services up there, trust me, they are somewhat needed to establish the foundation of the services we will be working on in a few. I should do a comprehensive article on each of the service sometime soon.

And now, let’s get in to our AWS console and get our hands dirty. I have taken time to attached the screenshots of each steps as we move along. Trust me, I am with you in this.

You ready? I AM!!!

I genuinely assume you are logged in to your console now.

Step 1: VPC

That being said, on the console search bar, type in VPC. In the page presented, click on the orange button to Create VPC.

In next page presented, select the VPC only option. This is because we will be creating each of the other services after now. For now, all we want is the isolated space for our deployments.

Give you VPC name here I named mine demovpc, select the CIDR bloc also called the IP address. Select the default tenancy, then give a tag name to identify the resources.

Once you have added all the above, click the orange button at the right hand side of your page. And that is it, you have created you virtual private cloud for your resources.

Now, let’s move on to the second resources, the subnet.

STEP 2: SUBNET

In the same window where you created your VPC, on the left hand menu, you will find the Subnet menu, click on it to reveal the Subnet window. In the window that appear, click on the Create Subnet orange button.

Once you clicked that button, you will be presented with the window below, here you will create the Subnet in the VPC we created in the step above, so, click the dropdown to reveal the ID VPC you just created.

On the next section that is revealed, enter the name of your Subnet, here I have named mine demo-subnet. Choose the Availability Zone AZ where your subnet will be deployed. Remember that this has somewhat effect on you application latency even though a CDN can help address this issue.

Enter the IPv4 CIDR block, here I am masking it to the /24 address. To know the subnet address range from your VPC IP, you can use the subnet calculator.

Enter the tag for your subnet and click the orange button to Create Subnet.

STEP 3: ROUTE TABLE

Next we create the Route Table for the deployments. In the same VPC window, you will find the Route Table option jsut below the Subnet.

Click the orange button to Create Route Table.

Give a name to the Route Table, here I named mine demo-RT. Click the dropdown menu to reveal the VPC we created earlier, select it.

Also, give a name tag to the Route Table and click the orange button to create your Route Table.

Now, there is one more step to making the Route Table configuration complete, and that is to connect or associate it to a subnet.

Therefore, navigate to the newly created Subnet earlier, click on the checkbox beside the newly created Subnet to reveal some information below in the window. Select the Route table option on the third row, at the right hand side of the page, find and click on the Edit Route Table Association.

In the next window, click the dropdown arrow to reveal the ID of the newly demo-RT created Route Table. Once selected, click the Save button.

STEP 4: INTERNET GATEWAY

Hey pal, well done so far, you are doing amazing well in this journey. Just a gentle reminder that you can confidently add this handson to your resume and post it to that job you have been tracking. Cheers!!!

Now, let’s allow internet connectivity into our resources.

In the same VPC window, on the same pane where the Subnet and Route Table is located, find the Internet Gateway resources. Once you click on it, you will be presented with the screen like below. Click the orange Create Internet Gateway button.

In the next screen, give your IGW a name, I also named mine demo-IGW. Once that is done, enter your key name and value for the tag option.

Done? That is it, you have created your Internet Gateway. However, one more step to give it optimal functionality…

…and that is to attach the IGW to a VPC.

Click checkbox beside the newly create IGW, then, click on the Action dropdown to reveal some set of options. Under these options, select Attach to VPC.

You should be presented with the screen below, click the dropdown to select a VPC, then select the VPC created earlier. Once that is done, click the orange button to Attach Internet Gateway.

Below is the message for a successful attachment of the IGW to my VPC. Hurray!!!

STEP 5: SECURITY GROUP

I must commend you for coming this far, you really deserves some accolades. We are at the final step to complete the ‘foundation’ setup of our application deployment.

We will create the Security Group here to allow specific traffic into our application. Let us allow port 80 (for our webserver), port 443 (for https) and port 22 (for ssh) into our applications. We will for this demo allow these traffic from every protocol source, that is the general 0.0.0.0/0.

In the same pane with Subnet and Route Table, scroll down to find the Security Group option. It will bring you to the window below. Click the orange button to create Security Group.

In the next window, enter a name for your Security Group resources, here I entered demo-SG. You can optionally add a description too.

Once that is done, click the select VPC to reveal the one create earlier where we will be adding our Security Group.

Then, in the next Inbound section, you should enter the ports and protocols that will be allowed. Like stated earlier, I have allowed port 80,443, and 22 from 0.0.0.0/0. Other AWS default ports are 3306 for MySQL, 5432 for Postgresql, etc. You can also add custom port if your used case is not in the listed default AWS port option.

The next section is the Outbound Rules, which should be left to All Traffic for All Ports range and Protocols.

Click the orange button once again to Create Security Group.

CONGRATULATIONS!!!

You have successfully created the foundation of your AWS architecture deployments. Now, your resources like EC2, CodeDeploy, SNS, etc can be deployed in your AWS Virtual Private Cloud (VPC)

In closing, although the resources we created today will not incur any expense when left to run except services that are not free tier eligible are deployed into them such as some EC2 instance, or an unattached Elastic IP address, I still strongly recommend that you terminate each of them. You can always redeploy them again and again. This will help you master the act of deploying them, and also, lessen the possibility of confusion of what was deployed for what purpose when you begin to work in production.

Also, take note of your naming conventions too.

Remember to share this publication and also leave a comment on any question you have.