Outline
Before getting to the meat of this clip, I'm going to take a minute or two refreshing your memories on the basics of TCP/IP networking architecture and NAT addressing. But feel free to skip the next bit if you're already dug in on all that. When that's behind us, though, I'll show you what building VPCs in AWS looks like. This time, by the way, I'll be happy to work in the browser console. The way that looks right now at least, I think you'll find the experience particularly intuitive and helpful.
Ok. So TCP stands for Transmission Control Protocol and IP stands for Internet Protocol. If those sound a bit broad - almost as if they're trying to describe the totality of the internet - it's because just about everything we do on the internet is indeed controlled by these half century old TCP/IP protocols.
For our purposes, remember that every network-connected device must have a unique IP address. Given that, mathematically, there can be no more than four billion 32-bit IPv4 addresses, and that there are already far more than four billion network-connected devices on the internet, something had to change. The 128-bit IPv6 protocol was eventually introduced to allow trillions of unique addresses. We'll never run out of those. But before IPv6, another brilliant solution was introduced: NAT networking. NAT stands for Network Address Translation, and the protocol sets aside three network segments for use in private networks only.
Using NAT, your home can have 15 or 20 devices - including laptops, smartphones on WiFi, network printers, routers, and maybe a smart fridge or two - but between them, they'll use up only a single public IP address. How does that work? Well, your internet service provider will assign that one public IP to the modem they send you. But that modem will act as a DHCP server and assign each local device a private IP address from one of those three network segments. The DHCP server will translate all requests moving between your local devices and internet-based services in a way that leaves those internet services thinking that your device's IP is actually the single public one. But incoming network packets are actually delivered right to your device using its local NAT address. The system really is brilliant. And it added decades of life to the IPv4 system.
But once we have NAT in place anyway, it can actually do a whole lot more than just translate local addressing. Which brings us to why we're talking about this stuff in the middle of a course on EC2 instance security in the first place. You see, NAT allows for very sophisticated network segmenting. By carefully configuring addressing and routing rules, you can turn a single local network into a multi-layered, highly-secured environment for mission-critical enterprise deployments. Here's an illustration of a replicated environment using public and private subnets from AWS documentation.
The only connection with the outside world such a private subnet would have flows through a bastion host and a NAT gateway living in an adjacent public subnet. Forcing everything through those two devices lets you precisely control traffic. The bastion host provides a jump box allowing admins to safely open remote SSH sessions on instances running in your private subnets. And the NAT gateway allows services running on your private instances outbound access to, for example, pull software updates. Both bastion hosts and NAT gateways will incur regular usage costs, by the way.
I'm going to show you how all this works. From the VPC dashboard I'll click Create VPC. Right away I've got a decision to make: do I want to build just a simple VPC with where I can host some resources, or something more complicated? If I go with VPC only, I'll just need to give the VPC a name, select my addressing environments and I'm good to go. But we're here to test drive the VPC and more option. As you can see, that'll open up an infrastructure preview to the right that shows us exactly what will be created based on the current selections, and what they'll look like. Right now, as you can see, we'll get one public and one private subnet in each of two availability zones, and appropriate route tables and network connections to make everything work. Note how each object is automatically given a name that properly reflects the naming structure I specified. All this automatically conforms with security and availability best-practices
I can choose to specify a dedicated tenancy for new instances launched into this VPC - although, as I mentioned earlier, that probably won't be relevant for all that many cases.
The number of availability zones you configure will reflect the depth of fault tolerance your application needs. The more zones, the less chance your application goes down. Of course, by that same token, the more zones, the more instances you'll need to run and the more you'll spend. You can see that editing this value will have an instance impact on the subnet settings to the right.
You can similarly control the number of public and private subnets. The options available will reflect the number of availability zones you selected above. Basically, the UI makes it pretty much impossible to do something stupid - which is something I appreciate.