VPC is short for Virtual Private Cloud. An analogy is would be something like this in your home network.
In AWS, an AZ (Availability Zone) is a single physical data center, physically separate from other AZs in the region. An AZ is like subnet A and subnet B in the diagram above. Your house network is a VPC (i.e. a region). Your network in another house is another VPC (i.e. a region). In AWS though, you can have multiple VPCs in a region.
AWS creates a default VPC in a region that is ready to use. However, if you create your own VPC, you have control of the IP addresses that are assigned. I find out this quite helpful in identifying which network I’m connected to, which instance I’m connected to etc.
Here are example settings
For each VPC I choose a IPv4 CIDR block, e.g. in Osaka it’s 10.18.0.0/16, in Seoul it’s 10.17.0.0/16, in Singapore 10.19.0.0/16. Make sure each VPC are different networks, this gives you possibility later if you want to “connect” VPCs together with a VPC peering connection.
If you are planning to have applications that are accessible via the internet, then choose public subnets (although you can make them inaccessible from the internet later by removing the IGW and/or modifying the route tables). If you are planning to have applications that are not accessible via the internet, then choose private subnets. Resources inside private subnets can talk to each other but cannot access the internet and the internet cannot access them. If you attach a NAT gateway, then resources inside the private subnets can access the internet but the internet cannot access your resources (similar to how your home network operates where your modem Wi-Fi router acts like as a NAT gateway).
Note that a NAT gateway is pretty pricey, so don’t use it unless you need it.
I also like to customize the subnet CIDR blocks. Here I use /25 (= 128 usable IPs in a subnet) which is plentiful for my needs, which also allows me to use .1, .2, .3 for each subnet A, B, C respectively (10.18.1.0 for subnet a, 10.18.2.0 for subnet b, 10.18.3.0 for subnet c). This way when I’m connecting to an instance, I can immediately know which region and subnet this instance is on (e.g. if an instance’s address is 10.18.1.5 then I know I’m in the Osaka network subnet A)
Here an example of enabling both public and private subnets. Notice that I use 1, 2, 3 to assign to public subnets and 51, 52, 53 for private subnets, this is just easy remembering.
IGW (Internet Gateway)
An IGW only has a name and what VPC it is attached to. AFAIK, you can treat an IGW as a “magical box” that will translate packets on the fly. Imagine if you have an EC2 instance in subnet A in your VPC, which has a public IP of 5.6.7.8 and private IP of 10.17.1.5. The IGW is aware that 5.6.7.8 is in the VPC it is attached to, so when it receives a packet destined to 5.6.7.8, it will forward it to the instance with private IP 10.17.1.5, the IGW rewrites the destination and source address to the private IP address (i.e. from your browser at home with IP of 1.2.5.6 you do a HTTP GET request to 5.6.7.8, the IGW will rewrite the packet to be coming from your home IP address and destination IP of 10.17.1.5. When the EC2 responds, it sends a packet from IP 10.17.1.5 to 5.6.7.8, I believe when the IGW sees this packet, it will rewrite the source address to be 5.6.7.8)
Route table
A route table is simply a routing table, here is a simple one, it states that if packet has destination in the 10.17.0.0/16 network, then it is a local network, else (0.0.0.0/0) send it to the IGW.
You attach the route table to one or more subnets
Note: in my VPC here, you can see that rtb-08c8b29be4dfd8ca0 is not associated to any subnet.
And its routing table is actually already handled by rtb-0076bba304341a5d6, so you can actually delete this. But first make sure it is not a Main table. Make rtb-0076bba304341a5d6 the main route table instead.
Network ACL
While a route table tells a packet how to reach its destination, if you imagine a VPC to be a gated community, a network ACL acts like the security guard at the front gate. It determines which packets are allowed to go inside the VPC (technically which subnets inside the VPC) and which are denied entry.
You can have multiple network ACL items.
A network ACL has subnet associations (which subnets it applies to), inbound and outbound rules. Each rule has a number (to determine order of evaluation).
If I change the rule for HTTP to Deny, like so, then I won’t be able to connect to any web servers inside the VPC.
Subnet
One thing that you probably want to do is to enable “Enable auto-assign public public IPv4 address” setting on each public subnet. This will make any (EC2) instance that are placed in that subnet to be able to acquire a public IP address.
NAT gateway
Egress-only gateway
Observation
I’ve created these instances, 2 “public” instances in public subnet A and B, and 2 “private” instances in private subnet A and B.
In public network
- Can public-A connect to public-B via public-B’s both public and private IP address? Yes
- Can public-B connect to public-A via public-A’s both public and private IP address? Yes
- Can public-A and public-B connect to the internet? Yes
- Can the internet connect to public-A and public-B? Yes
From public subnet to private subnet
- Can public-A connect to private-A via private-A’s private IP address? Yes
- Can public-A connect to private-A via private-A’s public IP address? No
From private subnet to public subnet
- Can private-A connect to public-A via public-A’s private IP address? Yes
- Can private-A connect to public-A via public-A’s public IP address? Yes
In private network
- Can private-A connect to private-B? Yes via private-B’s private IP address, not via private-B’s public IP address
- Can private-B connect to private-A? Yes via private-A’s private IP address, not via private-A’s public IP address
- Can private-A and private-B connect to the internet? Yes
- Can the internet connect to private-A and private-B? No
- Accessing from private-A or private-B to the internet, the internet sees source address is NAT gateway’s IP address (as expected)
Private subnet route tables
After examining the 3 private route tables, I believe we can consolidate them into 1
To become this single route table
Our resource map also becomes slightly simpler
Do we need to create an EC2 instance in a public subnet in order to reach an EC2 instance in a private subnet?
Not necessarily, you can use Connect using EC2 Instance Connect Endpoint (you’ll need to create an EC2 Instance Connect Endpoint first though) (and you need to enable EC2Connect first – described in another guide). Note that you cannot use normal EC2 Instance Connect because that method will connect to the instance’s public IP address (which is not accessible if the EC2 is in a private subnet).
Which instances can you reach from AWS CloudShell?
Can reach public-A and public-B, but only via their public IP addresses. Cannot reach all instances via their private IP addresses.