Getting Started with VPC
Amazon VPCs - virtual networks allowing you to to provision a logically isolated section of your cloud where you can deploy AWS resources and have full control over your virtual networking environment - are a cornerstone of AWS computing. VPCs provide unique and customizable IP address ranges, subnets, route tables, and network gateways. They play an important role in a wide range of scenarios, from the complex to the relatively straightforward.
Mastering VPC concepts is not easy, so our expert Linux System Administrator David Clinton created this course to help you to get started. When you're done, you should be able to intelligently integrate VPC configuration into your cloud architecture. You learn about basic VPC usage, how to create a subnet, and how to deploy a whole virtual intranet in your cloud.
Who should take this course
As this is an intermediate to advanced course, you will need some previous experience with AWS to fully understand it. Basic knowledge about EC2 and IAM will be taken for granted, and in particular you should have a good knowledge of the TCP/IP stack to fully appreciate some course elements.
If you'd like to improve your EC2 and general AWS knowledge, check out our other courses. Also, you may want to challenge yourself with our questions if you want to test your knowledge after taking this course.
Hi and welcome to CloudAcademy.com's video series on VPCs, Amazon's virtual private clouds. In this video, we're going to demonstrate how to create a company intranet, that is, computers and servers and other resources spread across an entire region, that can operate as though they are all connected, while maintaining a high level of security against access from outside this intranet. We are going to peer together two VPCs. We already have two VPCs on our system. We created them previously, one of them as part of a previous video. Let's take a quick look.
We'll select My VPC, and we'll note that it uses a 1000016 subnet. Let's highlight default, the other VPC, and we will note that it uses 172.30.0.0/16 as a subnet.
It's very important. If you're going to connect two VPCs in a peered network, they must be on different CIDR networks. They also must be in the same Amazon region.
They can be in different access zones, but they must be in the same region. We also have two EC2 instances running. One on each of our two VPCs. This one, My VPC instance, is running on the VPC 4205B927.
That's the one, that's the VPC we call My VPC. You will note that it has a private IP address of 10.0.3.171. That fits in the 10000 range. And you'll note that its public IP is 54.165.182/58. I don't expect you to remember that. I haven't got a clue or a chance myself.
Let's select the other instance, cloud academy, and its VPC is 5A08B931, which is the one we call default. Its private IP address is 172.30.0.93 which is within the 172.30.0.0 range. And its public IP is made available to us here. Now, let's create a peer connection between these two VPCs. You'll notice on the screen already is a connection called my connection, which existed, but I have since deleted.
Let's create a new VPC peering connection. Let's call it new connect. We will connect from the local VPC, My VPC, 4205, and we will connect to another VPC on my account.
It doesn't have to be on my Amazon account, but this one will. And we will connect to the VPC called default. Click create. And the connection has not yet been made. It has been requested. We will have to now, putting on our other hats, the hat which controls the default VPC, accept the connection. Let's click okay for now, and let us specifically display only the default connections. And at the top, next to new connect, a VPC peering connection called new connect, we see pending acceptance by us. We can either accept or reject the request. Let us accept the request. Yes, accept.
We now have a VPC connection. We're not done. We still have to make sure that there is network access between the two VPCs. The first thing we'll do is set our route table rules. Let's go to route tables, and select any one of the route tables associated with my VPC. And let's add a new route rule. Let's bring this up a little bit so we can see it a bit better. We want any traffic coming from 172-30-0-.0.0/16, which is targeted to PCX, 4A44AD23, which is our VPC peer group, called new connect. AWS knows what we're likely to want to do with traffic from this address, and that is route it through the peer group. So this rule is really set for us almost. We just have to go through the motions. And we'll save.
We'll now have to do the same thing to the route table in the default group. Let's edit. We'll add a group, this time going from 10.0.0/16. And again, we'll select new connect as our peer group. We'll save this one. We now have routing tables at the VPC level. Let's set the VPC security groups so we can allow traffic, the right sort of traffic through, while refusing access to the wrong sort of traffic.
Let's select this launch wizard one security group, and we see that the second inbound rule, that is HTTP port 80, allows any traffic coming in from 1000/16, which is exactly what we want. Outbound rules allow all traffic out. Let's now switch to the my VPC security group. Let's take a look at the inbound rules for this security group. We'll have to add a rule.
We'll allow all HTTP traffic coming from 172.30.0.0/16. Click outside the box and save. And we now have the traffic we want allowed in from 172.30.0.0/16. One more step. Let's go back to our instances, and let's make sure the security groups associated with our instances are also what we want. Let's click on launch wizard two, which is a security group being used by the my VPC instance, and http, we see is allowed in from anywhere in the internet. Now let's check the same thing with our other instance, cloud academy on the other VPC. Let's click on launch wizard five, which is the security group they use. And again, we have the same rule already. HTTP is allowed from any source.
But again, that is protected from above by the VPC security group. Now all that's left is to test this connectivity. This is an SSH session in the instance running in the default VPC, and I'm going to test connectivity with a service provided by the instance running into my VPC VPC. Specifically, we're going to test curl. There's a lamp stack that's been installed on that server, and I've created a small html page. That should answer to that IP address. This IP address, of course is a private IP address, within 172.30.0.0 range. So it definitely would not be accessible from the outside. But let's see if it's accessible from our VPC.
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.