About the Challenge

I manage the Service Delivery Team at eCloudValley Philippines, and one of the first things I teach them is to understand how AWS networks work. As cloud developers, we deploy our applications in Lambda and connect them with databases and other components inside our AWS VPC (virtual network in AWS). Because of this, it becomes imperative for them to know more about how VPCs work. They need to know how to navigate network issues they will encounter.

In this challenge, we would deploy an application to 2 servers inside a virtual network in AWS. The network will have two tiers: private and public. Our result will be:

Before we begin, here are a few helpful hints:

• This is a series of challenges that get progressively harder. It also meant to state what to do and what you should have learned. This is NOT a step-by-step guide on how to do the challenges.
• I have added links to AWS documentation to help you get started with the challenges.
• I have added guide questions to test your knowledge. It's easy to follow documentation to make this all work. But what we are striving for is a true understanding of how these components work together for a secure, reliable, and working network.

[A] Basic VPC Skeleton

Let's build the backbones of our VPC network. You'll be creating:

• VPC (how)
• 2 Private Subnets (deployed in separate Availability Zones, how
• 2 Public Subnets (deployed in separate Availability Zones)
• 1 Internet Gateway (connected to the VPC we just created)
• 1 NACL for both subnets (with a rule that allows all traffic)
• 1 Route Table (for Private Subnets, how)
• 1 Route Table (for Public Subnets)

In this exercise, you must be able to answer the following guide questions:

1. What makes a subnet private? What makes it public?
2. What is an IPv4 CIDR block? What is the difference between /16, /20 and /24?
3. Why do we deploy subnets in different availability zones?

Architecture Diagram for Exercise A:

[B] Setting up the instances

With the VPC backbone in place, let's add more network components:

• NAT Gateway (deployed in Public Subnet)
• Set up for you to deploy an EC2 instance
• EC2 instance (deployed in Public Subnet) - Getting Started - Best Practices
• EC2 instance (deployed in Private Subnet)
• Security Group that allows all traffic from port 22
• Associate the security group to both EC2 instances
• Private Route Table connected to NAT Gateway

Here are a few guide questions to answer:

1. DEMO: Be able to enter the CLI of the EC2 instance in the public subnet via SSH. Once inside, access the CLI of the EC2 instance in the private subnet.
2. Why do we need a NAT Gateway? How does it operate?
3. What is the difference between a NAT Gateway and an Internet Gateway?
4. What is the difference between a security group and an NACL?
5. Can a computer from the internet access the EC2 instance inside the private subnet? Why or why not?
6. What is the difference between a NAT gateway and a NAT instance? When would you use a NAT instance? NAT gateway?
7. What happens if you don't assign a public IP Address to an EC2 instance?

Architecture Diagram for Exercise B:

What we achieved

We created our private network in the Cloud! We also created two EC2 instances, one in the private subnet and another in the public subnet.

[C] Setting up NGINX and load balancing

We're getting close:

• EC2 instance (deployed in Private Subnet 1)
• EC2 instance (deployed in Private Subnet 2)
• Install Nginx on both. Modify /usr/share/nginx/html/index.html to add "this is server one" for the 1st EC2 and "this is server two" for the second one.
• Create an application load balancer
• Create a listener to receive HTTP traffic
• Create a target group that includes both EC2 instances as instance targets

Here are a few guide questions to answer:

1. DEMO: Once the resources have been created, get the URL from the application load balancer and put it in your browser. It should alternate displaying "this is server one" and "this is server two". This proves that the ALB is alternating sending traffic between the first and second EC2 instances.
2. What is the difference between a NAT Gateway and an Application Load Balancer?
3. Why put the EC2 instances in separate private subnets?
4. Why put the EC2 instances in the private subnet instead of being exposed directly?
5. Why add an application load balancer?

Architecture Diagram for Exercise C:

The result looks like this:

What we achieved

With Activity A-C, you have deployed your first VPC and have successfully deployed a simple app using a two-tier architecture. That’s honestly very close to how we deploy secure applications on the modern web.

There is one thing though. The application you accessed looked like something like this when typed in the browser:

http://jamby-alb-1962899873.ap-southeast-2.elb.amazonaws.com/

Two things come to mind when I see this:

First, the website is deployed on HTTP, not HTTPS, which leaves our end users insecure. As your end user browses your website, the data you send and receive goes across the internet unencrypted. The internet is made of thousands (or maybe millions) of routers connecting everyone in one big interconnected web. From your end user’s Macbook to your EC2 instance, there may be as many as 100 routers in between. if you leave your traffic as HTTP, any one of those 100 routers can see whatever you are sending between one another.

Second, as an e-commerce, I’d like to have a decent website name that my end users can easily remember. Something like:

jambyiscool.ecvphdevs.com

In exercise D, we will do just that.

Resources:

• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html

[D] Securing setup with HTTPS

Let's take it a step further.

• Buy a domain in GoDaddy and associate it with Route 53 (if you haven't). If you have access to an existing Domain Name, no need to do this step.
• Create a public certificate with AWS Certificate Manager. You may have to create DNS records in your domain manager.
• Associate the certificate with the ALB created earlier
• Create a route 53 record for "jambyiscool.yourdomain.com" and point it to the load balancer you just created. If your domain manager is not Route 53, feel free to create the record in your domain manager.

Architecture Diagram for Exercise D:

Here is the end result:

What's next?

Congratulations on completing this exercise! You know have a full view on how VPC works, and have deployed your first application on a best practice version of a private network in AWS.

On the next challenge, we will be doing VPC peering, EC2 auto scaling, VPC endpoints and CI/CD. Stay tuned!

Interested about joining ECV Philippines?

Send us your CV via email to ph.hr@ecloudvalley.com:

Photo by Nastya Dulhiier on Unsplash