Virtual Private Cloud is a full data center within the AWS cloud. Amazon now makes it possible for you to rent a piece of the AWS infrastructure to build and manage your own ecosystem. You have full control of your servers, storage and networking.
Within this ecosystem, you can create a series of public and private subnets and within there, a collection of EC2 instances for web servers, database servers, devops, etc.
For example, suppose you want to create a Wordpress blog but you want your MySQL database to live on a private server. By creating a private subnet, you can install an AWS Relational Database (RDS) that is separate from your public Wordpress server. The benefit from this structure is that it's slightly more defensible from a DDoS attack, hopefully. ;-).
Anatomy of a VPC
At its very core, Virtual Private Cloud's consist of:
To briefly explain what this means, IPv4 addresses are broken into 4 sets of 8 bits (octets) like this:
Each octet represents 8 bits which means that there's a total of 32 bits.
10 . 0 . 0 . 0 / 16
+++ = 32 bits
The /16 is saying that the first two octets (or 16 bits) 10.0. will be your Network Address.
The next .0 represents your Subnet.
The final octet .0 represents your Device Address.
This diagram shows the relationship between a VPC, a subnet and a device.
What can I do with this knowledge?
This is helpful as you begin assigning new subnets and devices to your VPC. For example, if you want to create two new database servers that are not directly linked to the Internet, you might want to assign them to a subnet 10.0.1.x and provide them with a device id of 10.0.1.0 and 10.0.1.1.
Other Helpful Facts
How many addresses does AWS reserve by default? Each subnet is given 3 addresses.
Subnet Availability Zones
When you create a subnet, you must assign it to an Availability Zone (i.e. us-east-1, us-west-1, etc). It's a one-to-one ratio.
Network Address Translation (NAT)
Underneath the hood, a NAT is a special kind of EC2 instance and here are a few unique characteristics:
NAT's are specialized EC2 instances so you will be charged accordingly.
NAT's technically live in a Public Subnet but have access to a private subnet server.
NAT's allow EC2 instances within our Private Subnet to talk to the outside world.
NAT's have their own public IP address.
What can I do with this knowledge?
Simple, if you have a private server but you want it to have access to the outside world, you'll need to use a NAT.
When you are creating a VPC, you'll want to say yes to Enable DNS Hostnames. This will allow you to create endpoints that resolve internally and the public internet.
Firewalls allow you, the administrator, to control how your trafffic flows inward and outward. When it comes to managing firewalls within your VPC, you have two tools to work with:
Security Groups help you declare what type of access you want to provide to your servers. In general, you assign Ports to Security Groups so for example, if you want to provide access to a Wordpress website, you may need to allow Port 80 (HTTP), Port 443 (HTTPS), and Port 22 (SSL) to your Security Group.
Access Control Lists
ACL's are similar to Security Groups but with more fine grained control. For example, if you want to block a specific set of IP addresses, you can input that information, into an ACL.
In many ways, the ACL is the second line of defense if your Security Group fails you.
Managing Internet Gateways
The Internet Gateway is a routing table that enables your EC2 instances (within your Public Subnet) to feel like they have their own IP addresses.
Internet Gateway Facts
You cannot attach multiple Internet Gateways to a VPC.
Managing Route Tables
This is where you patch things from the outside world to your EC2 instances.
Create a route table
Create an out for the route table by assigning 0.0.0.0/0.
The reason why you want to create a new route table that faces the public internet (instead of using your default main) is because if you create a subnet, it will then automatically be assigned to the outside world.
There's a lot to learn about VPC's. It's especially hard for web developers, like me, who traditionally work on apps and leave the infrastructure stuff to the DevOps people. That said, times are changing and it's probably important for every developer to become full-stack.
Besides, if you really think about it. If you mess something up, you can just delete it and start all over again. Yes, it's easy and cheap enough for all of us to mess up. So keep trying and over time, it will all start to make sense.