Virtual Private Cloud (VPC)

Regional resource
Soft limit of 5 VPCs per region
Only the Private IPv4 ranges are allowed

New EC2 instances are launched into the default VPC if no subnet is specified

Classless Inter-Domain Routing (CIDR)

Way to define a range of IP addresses
Two parts
- Base IP - 192.168.0.0
- Subnet Mask (defines how many bits are frozen from the left side) - /16
Private IP ranges:
- 10.0.0.0 - 10.255.255.255 (10.0.0.0/8) ⇒ used in big networks (24 bits can change)
- 172.16.0.0 - 172.31.255.255 (172.16.0.0/12) ⇒ AWS default VPC
- 192.168.0.0 - 192.168.255.255 (192.168.0.0/16) ⇒ home networks
Rest of the IP ranges are Public
Max 5 CIDR ver VPC
- Min. size is /28 (16 IP addresses)
- Max. size is /16 (65536 IP addresses)

Subnets

Sub-ranges of IP addresses within the VPC
Each subnet is bound to an AZ
Subnets in a VPC cannot have overlapping CIDRs
Default VPC only has public subnets (1 public subnet per AZ, no private subnet)
AWS reserves 5 IP addresses (first 4 & last 1) in each subnet. These 5 IP addresses are not available for use. Example: if CIDR block 10.0.0.0/24, then reserved IP addresses are 10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3 & 10.0.0.255

note

To make the EC2 instances running in private subnets accessible on the internet, place them behind an internet-facing (running in public subnets) Elastic Load Balancer.

There is no concept of Public and Private subnets. Public subnets are subnets that have: - “Auto-assign public IPv4 address” set to “Yes” - The subnet route table has an attached Internet Gateway

This allows the resources within the subnet to make requests that go to the public internet. A subnet is private by default.

Since the resources in a private subnet don't have public IPs, they need a NAT gateway for address translation to be able to make requests that go to the public internet. NAT gateway also prevents these private resources from being accessed from the internet.

Internet Gateway (IGW)

Allows resources in a VPC to connect to the Internet
Attached to the VPC
Should be used to connect public resources to the internet (use NAT gateway for private resources since they need network address translation)
Route table of the public subnets must be edited to allow requests destined outside the VPC to be routed to the IGW

IGW performs network address translation (NAT) for a public EC2 instance

Bastion Hosts

A EC2 instance running in the public subnet (accessible from public internet), to allow users to SSH into the instances in the private subnet.
Security groups of the private instances should only allow traffic from the bastion host.
Bastion host should only allow port 22 traffic from the IP address you need (small instances are enough)

High Availability

HA options for Bastion Host
- Run 2 Bastion Hosts across 2 AZ
- Run 1 Bastion Host across 2 AZ with ASG 1:1:1
Routing to the bastion host
- If 1 bastion host, use an elastic IP with EC2 user-data script to access it
- If 2 bastion hosts, use a public-facing NLB (layer 4) deployed in multiple AZ. Bastion hosts can live in the private subnet (more secure)
Can’t use ALB as it works in layer 7 (HTTP protocol) and SSH works with TCP
Diagram

Network Address Translation (NAT) Instance

An EC2 instance launched in the public subnet which performs network address translation to enable private instances to use the public IP of the NAT instance to access the internet. This is exactly the same as how routers perform NAT. This also prevents the private instances from being accessed from the public internet.
Must disable EC2 setting: source / destination IP check on the NAT instance as the IPs can change.
Must have an Elastic IP attached to it
Route Tables for private subnets must be configured to route internet-destined traffic to the NAT instance (its elastic IP)
Can be used as a Bastion Host
Disadvantages
- Not highly available or resilient out of the box. Need to create an ASG in multi-AZ + resilient user-data script
- Internet traffic bandwidth depends on EC2 instance type
- You must manage Security Groups & rules:
  - Inbound:
    - Allow HTTP / HTTPS traffic coming from Private Subnets
    - Allow SSH from your home network (access is provided through Internet Gateway)
  - Outbound:
    - Allow HTTP / HTTPS traffic to the Internet
Architecture

NAT Gateway

AWS managed NAT with bandwidth autoscaling (up to 45Gbps)
Preferred over NAT instances
Uses an Elastic IP and Internet Gateway behind the scenes
Created in a public subnet
Bound to an AZ
Cannot be used by EC2 instances in the same subnet (only from other subnets)
Cannot be used as a Bastion Host
Route Tables for private subnets must be configured to route internet-destined traffic to the NAT gateway
No Security Groups to manage
Pay per hour
Architecture
High Availability
- Create NAT gateways in public subnets bound to different AZ all routing outbound connections to the IGW (attached to the VPC)
- No cross-AZ failover needed because if an AZ goes down, all of the instances in that AZ also go down.

DNS Resolution in VPC

Two settings need to be enabled to allow DNS resolution within a VPC:
- DNS Support (enableDnsSupport)
  - Allows the resources within the VPC to query the DNS provided by Route 53 Resolver
  - Enabled by default
  - If disabled, we need to provide a custom DNS server otherwise we won’t be able to reach hostnames
  - Diagram
- DNS Hostnames (enableDnsHostnames)
  - Assigns public hostname to EC2 instances in our VPC if they have a public IPv4
  - Doesn't work until enableDnsSupport=true
  - By default
    - Default VPC - Enabled
    - Custom VPC - Disabled
  - When disabled, instances in the VPC will have a public IP but no public DNS
If you use custom domain names in a Private Hosted Zone in Route 53, you must enable both of these settings

Network Access Control List (NACL)

NACL is a firewall at the subnet level
One NACL per subnet but a NACL can be attached to multiple subnets
New subnets are assigned the Default NACL
Default NACL allows all inbound & outbound requests
NACL Rules
- Based only on IP addresses
- Rules number: 1-32766 (lower number has higher precedence)
- First rule match will drive the decision
- The last rule denies the request (only when no previous rule matches)
NACL vs Security Group
- NACL
  - Firewall for subnets
  - Supports both Allow and Deny rules
  - Stateless (both request and response will be evaluated against the NACL rules)
  - Only the first matched rule is considered
- Security Group:
  - Firewall for EC2 instances
  - Supports only Allow rules
  - Stateful (only request will be evaluated against the SG rules)
  - All rules are evaluated
NACL with Ephemeral Ports
- In the example below, the client EC2 instance needs to connect to DB instance. Since the ephemeral port can be randomly assigned from a range of ports, the Web Subnets’s NACL must allow inbound traffic from that range of ports and similarly DB Subnet’s NACL must allow outbound traffic on the same range of ports.

VPC Peering

Connect two VPCs (could be in different region or account) using the AWS private network
Participating VPCs must have non-overlapping CIDR
VPC Peering connection is non-transitive (A - B, B - C != A - C) because it works based on route-table rules.
Must update route tables in each VPC’s subnets to ensure requests destined to the peered VPC can be routed through the peering connection
You can reference a security group in a peered VPC across account or region. This allows us to use SG instead of CIDR when configuring rules.

VPC Peering does not facilitate centrally-managed VPC like VPC Sharing

VPC Endpoints

Private endpoints within your VPC that allow AWS services to privately connect to resources within your VPC without traversing the public internet (cheaper)
Powered by AWS PrivateLink
Route table is updated automatically
Bound to a region (do not support inter-region communication)
Two types:
- Interface Endpoint
  - Provisions an ENI (private IP) as an entry point per subnet
  - Need to attach a security group to the interface endpoint to control access
  - Supports most AWS services
- Gateway Endpoint
  - Provisions a gateway
  - Must be used as a target in a route table
  - Supports only S3 and DynamoDB

VPC Flow Logs

Captures information about IP traffic going into your interfaces
Three levels:
- VPC Flow Logs
- Subnet Flow Logs
- ENI Flow Logs
Can be configured to show accepted, rejected or all traffic
Flow logs data can be sent to S3 (bulk analytics) or CloudWatch Logs (near real-time decision making)
Query VPC flow logs using Athena in S3 or CloudWatch Logs Insights

IPv6 Support

IPv4 cannot be disabled for your VPC
Enable IPv6 to operate in dual-stack mode in which your EC2 instances will get at least a private IPv4 and a public IPv6. They can communicate using either IPv4 or IPv6 to the internet through an Internet Gateway.
If you cannot launch an EC2 instance in your subnet, It’s not because it cannot acquire an IPv6 (the space is very large). It’s because there are no available IPv4 in your subnet. Solution: Create a larger IPv4 CIDR for the subnet

Egress-only Internet Gateway

Allows instances in your VPC to initiate outbound connections over IPv6 while preventing inbound IPv6 connections to your private instances.
Similar to NAT Gateway but for IPv6
Must update Route Tables

VPC Console Wizard

note

Supported Configurations:
VPC with a single public subnet
VPC with public and private subnets (NAT)
VPC with public and private subnets and AWS Site-to-Site VPN access
VPC with a private subnet only and AWS Site-to-Site VPN access

Classless Inter-Domain Routing (CIDR)​

Subnets​

Internet Gateway (IGW)​

Bastion Hosts​

High Availability​

Network Address Translation (NAT) Instance​

NAT Gateway​

DNS Resolution in VPC​

Network Access Control List (NACL)​

VPC Peering​

VPC Endpoints​

VPC Flow Logs​

IPv6 Support​

Egress-only Internet Gateway​

VPC Console Wizard​