AWS VPC Notes

VPCs allow you to logically isolate your instances for security and controlling traffice.

One of the things you need to consider when creating a VPC is the CIDR range that you will apply to it.

Classes for choosing private IPs

You can use the IPAM tool to help you plan the CIDR ranges you apply to VPCs. You provide the number of IPs you need now (for servers, databases, load balancers, containers, etc.) AND the number of IPs you forsee needing within the next few years, and it will tell you the CIDR range to set when creating a VPC.

It's very important to work with the network admins at your job, or client, to figure out the IP ranges that should be used so that there are no conflicts

You can have up to 5 VPCs per region.

VPCs are contained within a region, subnets are contained by an AZ.

When you create a VPC in a region, you must specify:

  1. A tag (name)
  2. A CIDR range (you can go with the default though)
  3. A number of AZs
    • you specify the CIDR ranges for each subnet
  4. A number of public subnets
  5. A number of private subnets
  6. NAT Gateway ($ - costs money)
    • in only 1 AZ OR
    • 1 per AZ
  7. VPC endpoints (which can reduce NAT costs) - None or S3
  8. DNS hostnames and DNS resolution are checked by default, but you could disable them

Your default VPC comes with a route table already set up, it's called 'main'. It also has a default internet gateway set up.

The default (main) route table has two routes:

Destination     Target
172.31.0.0/16   local
0.0.0.0/0       some internet gateway ARN

Outgoing traffic will have it's destination IP looked up in the table an directed. The local rule directs all traffic where the destination IP starts with 172.31 to the router for the VPC (every VPC has an 'implicit' router that routes traffic between subnets)

So local = send to your VPC router

0.0.0.0/0 is a catch all, so any destination IP that doesn't match the other routes will be directed to an internet gateway.

Subnets

A subnet is limited to an AZ

Route tables control where outgoing traffic is directed from a subnet.

You are not allowed to delete a route table if there are any subnets are assigned to it.

Gateways

Internet gateway

Controls traffic to and from the internet.

Allows you to expose AWS resources to the public.

NAT gateway If you have a resource that needs to access the internect, but you don't want the internet to access the resource, use a NAT gateway

NAT allows you to hide the ip of an instance in a private subnet so that when it communicates with the internet, the internet won't know it's IP.

There are two ways you can do this:

  1. Creating an instance as a 'NAT instance' in a public subnet
  2. Configure a NAT gateway in a public subnet (the public subnet must also have an internet gateway) Then, set up a rule in the route table of the private subnet like so:
Destination    Target
10.10.0.0/16   local
0.0.0.0/0      the-nat-gateway

Network Access Control Lists

NACLs allow you to control the incoming and outgoing traffic for a subnet.

The default NACL for inbound rules looks like this:

Rule#  Type  Protocol PortRange  Source     Allow/Deny
100    all   all      all        0.0.0.0/0  Allow
*      all   all      all        0.0.0.0/0  Deny

Rules get routed in order, so you can put rules before rule 100 which will get evaluated before they match 100 If you remove the 100 rule, then the * will be the catchall (last rule) which denies all traffic

The default outbound rules are similar:

Rule#  Type  Protocol PortRange  Destination     Allow/Deny
100    all   all      all        0.0.0.0/0       Allow
*      all   all      all        0.0.0.0/0       Deny

Unlike SGs, NACLs are 'stateless' which means that if you wanted to truly isolate an IP you would have to set an outbound rule to deny traffic to it, and an inbound rule that would deny traffic from it.

Security Groups

Security groups are stateful and can only allow inbound or outbound traffic (no traffic gets through an SG unless it is allowed.)

Network access control lists (nacls) are stateless so you can control both inbound and outbound separately.

When configuring an SG, you can create a rule that specifies another SG as the source or destination. For example, you create an SG for a MySQL server and create an inbound rule to allow traffic from the web server's SG on port 3306. This would allow the web server to run queries on the db server

Security groups have a default outbound rule that allows all protocols on all ports, but you can remove this (but if you do, you should make sure to add rules to allow instances to get updates)