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 Amazon VPCs, virtual private clouds. In this video, we're going to explore creating a simple VPC. Let's dive right in. We'll click on VPC from the Amazon dashboard, and we are given a choice. We could launch an EC2 instance, which will launch the instance specifically into the VPC of our choice.
The VPC, of course, is useless if there aren't devices and computers operating within it. However despite the fact that Amazon accounts come with default VPCs, which are perfectly serviceable and good enough for anything we could throw at them, we'll nonetheless use the Start VPC Wizard to create a new one. We're given the choice of a number of profiles. Let's create a VPC with public and private subnets. That means the VPC we will create will have some subnets, that is, some regions within them, that will have full access both in and out of the Internet, and also another subnet, which will have access out to the Internet but which will not by default allow any traffic in from the Internet. This obviously can have applicability in a company setting where you want some devices, some computers, some users, and some services to remain internal. Let's select. Now, let's, by the way, make sure we're in the region we want. This is important, because if we want to make peer connections to other VPCs, they may only be made within the region that this VPC lives in. So ours is set for US East, North Virginia, which is where we want it. Now, by default, the VPC wizard has given us a name block of 10.0.0.0.
That's an NAT address, an address which is not public but is only accessible to devices and computers within our network.
It is very important to give our VPC a name. Amazon will assign a string of numbers and letters to identify the VPC, an ID, but that's very difficult to distinguish quickly between this ID and that ID. So it's very important, as we'll see later, to give it a unique name, myvpc, which in my account, is quite unique. Availability zone. We prefer to be us-east-1a. The public subnet name will remain. We'll leave as public subnet. The private subnet name we'll leave as private subnet. You'll notice whereas the public subnet, that is the network that the public segment of the VPC lives in, is 10.0.0.0. The private subnet is 10.0.1.0.
This means you can separate traffic going to and from and within either one of these two subnets. If you want to allow traffic back and forth or you'd like to limit or restrict traffic back and forth, putting them on separate subnets is the quickest and most efficient way to do that. Let's make availability zone here the same. It doesn't have to be as long it's in the same region, but we'll leave the availability zones the same. Instance type, we'll just leave this small. That may not be good enough for your use, but it's fine for us. The key pair, we will use an existing key pair called mykey.
And, hardware tendency, we are given a choice either dedicated or default. Dedicated means that all the instances and devices running on this VPC will be isolated in their own physical machine.
Somewhere in the Amazon server farm, there will be one machine or more than one machines dedicated explicitly to your VPC.
We don't need that. It provides an extra level of security and reliability perhaps, but it's nothing that we, for our purpose, need. So we'll leave it as default. Let's create the VPC. We're done. Our VPC now exists. We'll click on okay, and we see the list of VPCs that so far exists. The one without a name associated with it is vpc5a08, etc. That's the default VPC which our system gave us, which Amazon gave us when the account was created. However, we are interested in myvpc. Let's take a look at its configuration. We'll click on subnets. Now we see the existence of five separate subnets, but they're not all associated with myvpc. To make it easier to read through these lists, let's go to the top left, filter by VPC, and we will filter, that is, it will display only those that belong to myvpc. So we see the importance of giving a name to your VPC, because if I hadn't, we would just have two numbers and I would have to distinguish between VPC 420 and VPC 5a0.
But if the name's there, it's easy to distinguish. We have two subnets associated with the VPC. That is public and private. Let's take a look at the public subnet. If we go down to the bottom of the page, we're given a summary. Click on Route Table. Scroll down a little bit.
Actually we can also raise this up to make it easier to see, and we see the route table as it currently exists. Number one, we see the route table has been given an ID, RTB. RTB obviously stands for route table, and then its specific number.
This is unique. There's only one route table with this ID anywhere in the Amazon system, and it's associated specifically with our VPC. Its destinations are 10.0.0.0, which is the public address of our VPC, and 0.0.0 means anywhere, but it heads out towards its ultimate target is Igw74ca1b11. IGW stands for Internet gateway. So this subnet is pointed automatically to the Internet gateway that's been assigned to our VPC.
This is by default. Of course we could if we need to edit this, but we'll leave it there for now. The Network ACL. ACL stands for access control list -- what devices and traffic will be allowed in and out through this network. For our purposes now though, it's important to know that the ACL, the network ACL associated with our VPC is ACL, access control list, d199, etc. Again, we can edit the setting associated with this ACL. The reason however that these two services, route table and network ACL, are listed here under subnets is because a subnet is really only useful if it is pointed to a routing table and an ACL. So this display simply teaches us which route table and which network ACL the subnet is pointed to. Now let's click on route table themselves. There are two routing tables.
Let's take a look at the difference. The first one is RTB, routing table, f36, etc. and it is associated with these two subnets. The two subnets, public subnet and private subnet, that were created for this VPC.
Let's click now on Internet Gateways. You see the ID, IGW, Internet gateway, 74ca. Again, this is the Internet gateway that was created for our VPC. Click on Network ACL, and again there are two. We can filter to myvpc. We can highlight and see the inbound rule, and edit the inbound rules. We'll, of course, talk a lot more about these rules and policies in a different video. Finally, let's click on Security Groups. There is associated with our VPC 1 security group. SG is the beginning of its ID, and SG of course stands for security group. Let's highlight, click on this security group, and again there are the inbound rules and outbound rules associated with the security group, which may be edited. And again later we're going to explore how to edit these rules. Let's go back to the AWS dashboard and click on EC2. Click on instances to see all of the instances we have running right now. There is an instance, an m1 small instance, with this ID, which is currently running, which may seem a little odd because before we began this exercise we didn't actually have an instance running on this account. However, if you look down to the description of this EC2 instance, we will see that it is associated with VPC ID 4205b927, which happens to be myvpc. It doesn't have its tag, its name IBC, for some reason, displayed here, but that is the VPC. So, when we created this new VPC, Amazon, by default, launched an EC2 instance to go with it to be part of it. So within just a few minutes, we've created a VPC, to some degree configured it, certainly identified its main parts, and have an instance already running in the 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.