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 AWS VPCs, virtual private clouds. In this video, we're going to talk about VPC security, security groups, ACL, that is access control list, and other security features. Perhaps the first line of security of a well-protected VPC is its subnets. As we discussed in a previous video, VPCs can be divided into multiple subnets. A subnet is simply a network whose addresses allow you to restrict access between them and from them to the Internet and from the Internet to them with great precision. Beyond subnets, however, there are two specific features that AWS offers to secure your VPCs. And of course they overlap with security measures you'd use in any network situation. So let's click on VPCs. And go right to security groups. You are no doubt familiar with security groups.
Let's, however, narrow down the displayed security groups in this page to those associated with myvpc. There is one security group. It was the default security group that was created when I created the VPC itself. And as you can see in the bottom, it is made up of inbound rules and outbound rules. By default, a VPC security group will allow all traffic using any protocol and any port range coming from this source. This source SG stands for security group, means any other Instance in my account that shares this security group. Besides the Instances that share this security group, this particular profile will allow no other inbound traffic. We could, of course, edit profile and add a rule.
Let's say we might want to add HTTP traffic using TCP protocol, Port 80 as default HTTP traffic would use.
And then we might add another security group or a specific IP or 0.0.0.0, anything. Well, as you can see, we missed one step. We should also, to complete the CIDR, add a net mass of zero, which means that any traffic using the HTTP TCP protocol, Port 80 will get through. We don't want that though.
That doesn't attract me particularly for this particular VPC. We could save, of course, the new rules that we added. Or in this case, since we've added no rules, we'll just cancel. Outbound rules by default allow any traffic going out, that is all traffic using any protocol, any port range going anywhere. Going 0.0.0.0/0 means any destination is accepted. Those are the default. You could, of course, edit this profile and add another rule to restrict external outgoing access to users in this security group. I don't particularly want to right now, but this does illustrate one of the basic features of a security group that it operates as a blacklist. That is all access, both inbound and outbound is restricted unless you explicitly allow it.
That's how a blacklist works. Normally an AWS security group is created with a default restricting instances, sharing an SG, a security group, from talking to each other. It's only the VPC security group that has this default tunnel between Instances using the same security group.
Let's now take a look at network ACLs. And ACL is an access control list. It contains, as we'll see in a second . .
let's click on Our ACL. It contains inbound and outbound rules that look, superficially very similar to the security group rules we just had before.
You might ask, as I did when I was first exposed to ACLs, in this context, is "What's the difference between a security group and an ACL? They seem to cover pretty much the same ground." In fact, they seem to have the potential first stepping on each other's feet. There are a number of very, very important differences. Security group is associated with an instance, not a subnet. That means there is the theoretical possibility that a particular instance could be created without a security group at all. It would be an improper practice. I don't recommend it but it could happen. Because that could happen, ACLs can act as a second layer of defense. Because an ACL is associated with a subnet and automatically any rule that you've set as part of an ACL in your subnet will apply to all the instances of that subnet. So in case there's more than one administrator controlling your VPC and this particular subnet, you may not trust all of them to remember to create proper security groups on their Instances. To protect against that, you can create an overarching network ACL at the subnet level, which at least will catch what should've been covered at the instance level. That's one important difference.
ACLs are also different in that they work as both black lists and white lists. You could create a rule that will restrict all traffic except what's explicitly included or allowed. But you could also create a rule the other way that will allow all traffic except what's exclusively restricted. Let's take a quick look at how the inbound rules of an ACL appear. This first rule, for instance, allows all traffic using any protocol on any port, coming from any source, any IP address, it will allow it. The next rule, however, takes all traffic using any protocol, any port range, from any source, and denies it. Why would you make two rules that seem to contradict each other? The first rule sets up, in effect, the white list, but the second rule, when it's formulated this way, is simply a reminder of how we could edit to make it useful.
Outbound rules have the same internally contradicting pair of rules that have been created that, again, are simply placeholders to point us to the right place to start when creating a set of useful rules. Finally, the subnet association's tab displays for us which subnets are currently associated with and controlled by this network ACL.
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.