How to Create a Secure 3 Tiered Highly Available Network in AWS: Part One

Home/Amazon Web Service, DevOps, Networking/How to Create a Secure 3 Tiered Highly Available Network in AWS: Part One

How to Create a Secure 3 Tiered Highly Available Network in AWS: Part One

Recently I’ve been occupied with launching my application – I’m getting very close! I’ve been spending a lot of time thinking about what network infrastructure I wanted to put it on and what was the appropriate amount of security to use. I’m happy to say that I finally finished the bulk of the work on this solution. My app, on the other hand, needs a little more help. Look to see it soon!

It wasn’t a difficult decision to go with Amazon Web Services as my suite of tools. I’ve had a lot of experience with them on some other projects (getobservatory.com, for example) and it just felt like the right fit. Plus, I wanted to dig into some serious networking strategies to provide the most secure solution to handle my (soon-to-be) users data. AWS gave me the affordability I needed with all the features I could dream of – and then some. It’s for these reasons (and a pinch of favoritism) that I chose to use AWS’ VPC and subnetting solution to host and manage my applications securely and with high availability. This two-part series is going to cover how to create your own highly available and secure network using Amazon’s VPC.

Getting Started: An Overview of your Network

The concepts involved in creating your Virtual Private Network can be a little hard to grasp, so I want to start by getting an understanding of what exactly it is we’re going to be making. It took me a dozen or more tries to get this to work, referencing many other tutorials and ‘real life’ experts, and my biggest complaint was the ambiguity of what it was I was doing.

So to set us on the path to success, let’s look at what a VPC is. VPC stands for ‘Virtual Private Network.’ A VPC allows a user to create an internal network ‘virtually’ through Amazon’s services. This amount of control is important for us because by monitoring our network we can pick and choose what traffic goes where and what it can access. For example, we don’t want just anybody to be able to send internet requests to our database and don’t want threatening individuals to be able to route through whatever port they want into our servers.

Then there’s subnets, a way for us split our network into different layers. In front of these layers, we can define rules grouped into Network Access Control Lists (ACL’s). These rules tell our network what’s allowed into that subnet. Furthermore, we can arrange our subnets into Security Groups, another way to fine tune the inbound and outbound traffic to that subnet.

To ensure our application is always available you want to make sure its split into two data centers, or regions. That way if one goes down you still have access to the other. And lastly, between all of this, we have various routing rules. Don’t worry; we’ll go over this in more detail later. So far, just think of it as a walled city, with guards at every gate.

The image below illustrates this as best as I could. It’s a spinoff of the diagram I use for my network where I keep track of all of my projects. If you’re not already planning on doing so, I highly recommend that you map out your network. It will save you a lot of time and frustration. I use lucidchart.com, but feel free to use whatever you makes you comfortable.

Now let’s get started!

Creating a VPC

The first thing we’re going to want to do is to build the Virtual Private Network. You need to create an AWS account. From the central console navigate to VPC (under the Networking & Content Delivery) section. On the left side of the screen click “Your VPCs.” At the top of the screen click the button “Create VPC”. You’ll need to provide a name tag. I used something like “foo-network.”

The next field is going to be where we define the range of IP addresses that the network will have available to it. A range of addresses is written in CIDR notation and looks like this: 10.0.0.0/16. The details of CIDR notation delves deeply into networking science and other intricate technologies that we won’t address today, but in general what this notation means is our network will have 65,536 (give or take a few reserved IPs) available for use. That’s quite a few, and should be plenty for just about anyone. The first set of digits, 10.0.0.0 is where the IPs start. They then increment like this: 10.0.0.0, 10.0.0.1, 10.0.0.2 … 10.0.0.255. From here it rolls into 10.0.1.0, and the process starts over again. Eventually, you reach 10.0.255.255 the uppermost limit to the network. We’ll talk a bit more about this later on.

For now, fill in 10.0.0.0/16 into the “IPv4 CIDR block*” field, and enable the Amazon provided IPv6 block option. Leave “Tenancy” set to default, and click “Yes, Create.”

Creating the Subnets

We have allocated a large block of IP addresses, but now we want to start splitting them into layers so that we can control access into each one. Going with the same castle analogy from earlier, imagine a large circular wall. Outside this wall is the internet, inside it is our network. Inside this wall build another one, and yet another one inside that. You’ll have three completely separate areas within your castle. The center most section we call the “Core,” it’s where we keep our data and most critical information. Outside that is the “Application” layer, where our apps and api’s will reside. Lastly, is the “Presentation” layer, where the internet is welcomed in with open arms.

So let’s go and create these different sections, or subnets, on our network now. In your AWS console click “Subnets” and select “Create Subnet” at the top.

You’ll see a pretty simple screen asking for a name tag. Let’s start with the outermost layer and call it “foo-presentation.” We then want to select our network from the “VPC” dropdown. The next section shows us our current CIDR configuration for this network, and below that we select our Availability Zones. It’s here we can begin introducing high-availability to our network. By creating a second subnet in a different zone for the same layer in our castle, we can ensure we always have one available should the other go down.

 

Finally, we get to defining our CIDR configuration for the subnet. Due to some fancy mathematics, the larger the value following the 10.0.0.0, the smaller pool of IP addresses becomes. So here we want to carve out a single block of 255 IP addresses from our network, so we’ll put in 10.0.1.0/24. What this equates to is all the IP values from 10.0.1.0 through 10.0.1.255. We’re going to create six subnets with the values below:

foo-presentation (zone 2a),  10.0.1.0/24
foo-presentation (zone 2b), 10.0.2.0/24
foo-application (zone 2a), 10.0.10.0/24
foo-application (zone 2b), 10.0.11.0/24
foo-core (zone 2a), 10.0.50.0/24
foo-core (zone 2b), 10.0.51.0/24
foo-nat (zone 2a), 10.0.0.0/24

We leave some space between our CIDR blocks in case we ever need to add new ones to an existing layer. You could create three more subnets for a third zone if you so chose, but we won’t be doing so for this tutorial. Tell Amazon to specify a custom IPv6 CIDR for you in case you need them later. Lastly, you’ll notice we created a seventh subnet for our NAT drive, which we’ll learn about in the following sections.

After their all built, we can move on!

Creating an Internet Gateway

We now have this nicely walled off castle from the rest of the web, but there’s no way to get in or out of the network. For that, we need to provision an Internet Gateway. An IG is super easy to create, and just allows an internet connection to our Network. Think of it as the gatekeeper of our castle, standing guard outside telling travelers where to go.

In AWS, click “Internet Gateway,” and provide a name tag. For this tutorial, I used “foo-gateway.” We still need to assign it our VPC though. Click the IG and at the top select “Attach to VPC.” Pick your network from the drop and attach it.

Creating a Network Address Translation Gateway

The presentation layer of our network should have access to the internet without any complications as its the main entrance into our network. However, our internal subnets will still need to be able to use the internet to function. To do this securely, we will create a NAT (Network Address Translation) gateway. A NAT gateway just remaps the IP address of all of the servers connecting to it to a single IP.

From the same page on AWS select NAT Gateway on the left side and select “Create NAT Gateway” at the top of that new page. You’ll be asked to supply a subnet where the NAT will reside; we’re going to use 10.0.1.0/24, our presentation layer. We also need to assign to what public IP address we’re going to do our translation. Just click “Create New EIP” or chose an existing one from the drop-down list. Finally, click “Create.” You’ll be asked next to assign it to a route table, just exit out of this box; we will do that in the next section.

In Review

So far we’ve created all the infrastructure we’re going to need for our network. You’ve defined the container where all of your layers will go (the VPC), and you’ve also created a three-tiered set of subnets across two datacenters (zones). We’ve built all the walls of the castle, and we have the gatekeeper ready to send and receive internet connections. All we need now is connect everything together and provide the map into our network.

In the next tutorial, we’ll create our Route Tables, define security protocols with ACLs and Security, and make sure everything’s working great by deploying a sample project into our network.

Thanks for reading and happy coding!

By | 2017-06-17T22:02:25+00:00 June 17th, 2017|Amazon Web Service, DevOps, Networking|0 Comments

About the Author:

React.js developer, web designer, devops engineer, and business owner.