Imagine an on-prem network with routers, sub-netting, routing tables, and computing resources… except in the cloud. Yep, that is what a Virtual Private Clouds is… a foundational infrastructure components much like IAM and EC2.

Why use a VPC?

Creating an Amazon Web Services virtual private cloud is about the most amazing systems engineering feat ever. Using a good, yet not great, website anyone with basic technical skills can create computing infrastructure with security that would have cost hundreds of thousands of dollars just years ago - and I know this because I ran the IT group at a SaaS startup some years ago and spents millions of dollars in hardware and software and 4 or 5 months to accomplish what would take zero dollars to setup and way, way less than $100k a year to run.

Types of VPC

  • Default VPC - A default VPC gives users easy access to computing resources with now configuration at all. The default VPC has a default internet gateway, a default private IP and a default public IP. A default VPC can be deleted and can only be restored by contacting AWS.

  • Non-Default VPC - By default, an instance in a non-default VPC is not assigned a public IP addresses; no internet gateway is attached by default

VPC Tenancy

When creating a new VPC and using the default options, all hardware is uses shared tenancy; using the “dedicated” option makes everything, including EC2 instances, on dedicated hardware - think more expensive.

VPC Networking

  • Elastic IP Addresses - A static IP address that can easily be allocated and remapped to another computer resource; 5 per AWS account by default.

  • Internet Gateway - one gateway per VPC; detached upon creation.

  • Elastic Networks Interfaces - a virtual network interface that you can remap and assign to other instances; includes a non-changing MAC address

  • Elastic IP addresses - a public IP address you can map to an ENI; costs money if it is allocated yet not used or more than one is attached to an instance

  • Routing Tables - each subnet has only one routing table but one routing table can be shared by many subnets

  • Customer Gateway - a vpn endpoint inside a VPC that allows computers in the corporate network access the VPC resources

  • DHCP options set - change the VPC DHCP settings; might change to use internal on-prem DNS

Subnets

Subnets cannot span availability zones and can use a block size between /28 and /16 and can’t overlap. 5 IP addresses per subnet are reserved:

  • 10.0.0.0 - network address

  • 10.0.0.1 - router

  • 10.0.0.2 - DNS

  • 10.0.0.3 - Future use

  • 10.0.0.255 - VPC don’t support IP broadcast or multicast; so AWS reserved it

Network Address Translation (NAT)

EC2 instances in a private subnet can’t access the Internet therefore can not access updates via a package manager. Both a NAT instance and NAT gateway can solve this problem.

A NAT instance, which is a special purpose EC2 instances, is one solution but a bit old school. To vertically scale a NAT instance, you can increase the size of the instance or enable enhanced networking. Horizontal scaling is challenging but you can split the traffic between more than one NAT instance but each subnet can only route to a single NAT.

A NAT Gateway is a fully managed AWS service that is way more practical and easier to implement. The service enables 10 Gbps per gateway and many gateways can be used.

DHCP Option Sets

The pool of IP address a client can request is also called a scope; usually a CIDR block. A reservation is for fixed addresses, and, if screwed up, can cause IP conflicts.

DHCP option sets include DNS servers, VOIP servers, leases, subnets, and other configuration information and are associated with a VPC. You can’t modify an options set; you must create a new one and attach it.

VPC Peering

VPC peering - allow you the ability to directly route between two VPC using private IP addresses - this might also be configured to share VPC between AWS accounts. VPC peering is NOT transitive. There are no single points of failure, bandwidth limitations, and does not require any hardware.

Limitations and issues with peering include:

  • 50 peers per VPC soft limit; 125 by request

  • Placement groups CAN span peered VPC, but you won’t get full bandwidth

  • Private DNS values cannot be resolved between instances in peered VPCs

  • Routes must be established for peering to work, and SG must cooperate too

Invalid Peering Configurations include:

  • Overlapping CIDR blocks will not work

  • Transitive Peering

  • Edge to Edge Routing scenarios through a IGW, VPN, Direct Connect, private connection, S3 end-point, NAT

VPC Setup Process

  1. Requester sends request to accepter

  2. Accepter accepts

  3. Both Accepter and Requester must setup routes using private IP address ranges

  4. Both Accepter and Requester must enable SG ingress rules referencing the peered network SG

VPC Security

  • Security Groups - firewall port filtering at the instance level renamed; allows filtering inbound and outbound; return traffic is allowed so it is state-ful; supports allow rules only

  • Network Access Control List - firewall port filtering at the subnet level renamed; allows filtering inbound and outbound; return traffic is not specifically allowed so it is stateless; Each ACL rule has a number and rules are evaluated ascending; Best practice is to create rule numbers by 5 so other rules can be added later; Once rules are added all other traffic is denied by default. A network ACL overrides security groups. Only 1 ACL per subnet and they encompass and over-write the permissions defined there. Rules are evaluated ascending.

NAT Gateway

An instance needs an public IP address in addition to having a route in order to access the Internet. For a NAT instance to route properly you need to disable the “Source/Destination Check” option AND there needs to be a route from the private subnet to the NAT instance.

RDS (DB Subnet Group)

RDS instances in a VPC - There is a mythical sort of subnet, called a DB Subnet Group, that must span multiple availability zones and can house RDS instances.

VPC Specific

By default all instances within a subnet with a VPC can communicate.

To enable access to or from the Internet for instances in a VPC subnet, you must do the following:

  • Attach an Internet gateway to your VPC.

  • Ensure that your subnet’s route table points to the Internet gateway.

  • Ensure that instances in your subnet have public IP addresses or Elastic IP addresses.

  • Ensure that your network access control and security group rules allow the relevant traffic to flow to and from your instance.

Limits per Region

  • 5 VPC per Region

  • 200 subnets per VPC

  • 50 customer gateways

  • 5 internet gateways

  • 5 Elastic IP

  • 50 VPN connections

  • 500 Security Groups

Network Access Control Lists vs Security Groups

  • Security Groups - firewall port filtering at the ENI level; return traffic is allowed so it is state-ful; supports allow rules only

  • Network Access Control List - firewall port filtering at the subnet level renamed; allows filtering inbound and outbound; return traffic is not specifically allowed so it is stateless; Each ACL rule has a number and rules are evaluated ascending; Best practice is to create rule numbers by 5 so other rules can be added later; Once rules are added all other traffic is denied by default. A network ACL overrides security groups. Only 1 ACL per subnet and each subnet MUST have an ACL. Unlike IAM or Security groups in a Network ACL an explicit Deny CAN override an explicit Allow if allow is a higher rule number.

VPC Flow Logs

Flow logs can be enabled at the VPC, subnet, or ENI level; when enabling at the VPC/Subnet level it simply turns flow logs on for the ENIs in that VPC/Subnet. All data is forwarded to CloudWatch logs but does not work in real time; can record all traffic, accepted traffic or rejected traffic.

You can create flow logs for network interfaces that are created by other AWS services; for example, Elastic Load Balancing, Amazon RDS, Amazon ElastiCache, Amazon Redshift, and Amazon WorkSpaces using the EC2 Console or API.

Limits:

  • Cross account flow logs aren’t possible.

  • Can’t tag a flow log

  • Can’t modify a flow log once created

  • No Amazon DNS traffic, windows license activation traffic, DHCP traffic, instance metadata traffic, default VPC router traffic