AWS Networking Basics
AWS Networking Architecture
AWS 160, from Cloud Academy's comprehensive Amazon Web Services learning tracks series, provides a full introduction to AWS networking. You'll get a good first look at some of the key structural elements of AWS traffic control, like Virtual Private Clouds (VPCs), security groups, and IP addressing. We'll also briefly discuss such critical networking services as CloudFront, Route53, Auto Scaling, and Load Balancing.
AWS160 is part of the 100 level course series (the AWS Technical Foundation Track) which, in turn, lays the groundwork for our 200 series (intermediate level skills) and 300 series (advanced skills).
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
In the previous video, we explored the basic structure of VPC, virtual private cloud, and how it works to optimize the work of your instances. Now, we'll discuss the tools you'll need to control both incoming and outgoing network traffic.
Let's start from the outside and our way in towards what should be living safely at the well protected center of RVPC and EC2 virtual machine. Every VPC connects to the outside world through an attached internet gateway. The default VPC that's created with every AWS account and called default, will automatically include a gateway. But if you want external internet access for any new VPCs you might create for your own specialized projects, you'll have to manually create a custom gateway. Once created, you put your new gateway to work by pointing the route table associated to any VPC to your gateway. In this case, by clicking on the routes tab, you can see that the route table used by my default VPC is already associated with an internet gateway, identified by an ID starting with the letters IG. You could click on the edit button to add a new route or to change any of your existing settings.
Route tables direct traffic between subnets and gateways. Each VPC is assigned a route table when it's created, and while you can add your own route tables manually, any subnet that's created and associated with a VPC will automatically have the parent VPCs route table attached to it. Here you can see an additional benefit to using carefully designed subnets. If, say, you want only some of your resources to be accessible from the internet, you can place the devices that will get full connectivity in a subnet whose route table points to the internet gateway, and the the private devices in a subnet whose route table points to only local subnets, but not to the internet. To control traffic moving into and out of a subnet, you have the option of configuring a network ACL, access control lists. ACLs allow you to create filters for both inbound and outbound traffic at the subnet level based on protocol, destination, and source. The rules are numbered and evaluated in ascending order. Whatever traffic is not explicitly permitted by your rules will be denied by the final deny rule identified by the asterisk. To control traffic moving both into and out of a virtual machine, rather than a subnet, you should configure a security group which, by the way, covers a lot of the same ground as network ACLs, but at the instance level. The truth is that security groups are actually used for more than just virtual machines, but are also attached to other objects like load balancers and auto scaling launch configurations. Finally at the root of everything lies your virtual machines, or as they're usually called in Amazon circles, instances. These instances, the crown jewels of your deployment, are protected from attack by your subnet and route table architecture, and by your ACLs and security groups. To illustrate a possible security group configuration, let's briefly see how we can create a new EC2 instance with a basic configuration.
We'll begin on the EC2 page clicking launch instance. We'll select then Ubuntu 1404 server as our AMI, and a T2 micro instance type. We'll accept the default instance details and click next, add storage, where we'll also accept the default configuration. We won't create any tags for this instance, but instead move onto security groups. We could select an existing security group, but let's create something new. This group currently has a single rule, which comes with a friendly warning from your good friends at Amazon to the effect that you'd be crazy to leave things this way, because port 22 currently offers wide open access to anyone with an SSH client in your password. Let's change that by limiting SSH access only to session requests originating from my local IP address, which AWS uses to populate the field for me. Now, let's add another rule.
Let's say we're building a web service so we'll need to provide access to browsers using the HTTP protocol. We'll select HTTP from the type drop down, which automatically opens port 80. We'll leave anywhere as our source, because a web server that doesn't accept traffic from anywhere isn't all that much of a web server. As it stands, the security group is currently controlling traffic only for our new instance, and will have no effect anywhere else. At our next video, we'll explore some other AWS networking tools.
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.