VPC & Network

VPC, SUBNETS, NETWORKING

  • A VPC is a virtual network that closely resembles a traditional network that you’d operate in your own data centre.
  • After you create a VPC, you can add subnets. A subnet is a range of IP addresses in your VPC. After you add subnets, you can deploy AWS resources in your VPC.
  • Use route tables to determine where network traffic from your subnet or gateway is directed. 
  • A gateway connects your VPC to another network. For example, use an internet gateway to connect your VPC to the internet.
  • Use a VPC endpoint to connect to AWS services privately, without the use of an internet gateway or NAT device.
  • Use a VPC peering connection to route traffic between the resources in two VPCs.
  • Use a Transit Gateway, which acts as a central hub, to route traffic between your VPCs, VPN connections, and AWS Direct Connect connections.
  • Connect your VPCs to your on-premises networks using AWS Virtual Private Network (AWS VPN).

Subnets

  • A VPC is housed within a Region, and a subnet maps 1-to-1 with an AZ. Therefore, for high availability, you need at least 2 subnets in your VPC so that you can span 2 AZs.
  • When you create a new subnet, it is automatically associated to the main route table. 
  • Example VPC/subnet configurations recommended by AWS
    • VPC with single public subnet: e.g. for single-tier, public-facing web app such as a blog or a simple website
    • VPC with public and private subnets: e.g. for multi-tier web apps where the web servers are in the public subnet and the DBs in the private subnet

Public Subnet vs. Private Subnet

  • Public Subnets
    • has a route table that routes to an Internet Gateway (note the Internet Gateway is attached to the VPC, not directly to the subnet)
    • When EC2 instances launched in a Public Subnet, they are auto-assigned a public IP address or ENI
    • Security groups and network ACLs on Public Subnet must allow SSH traffic (on port 22) for admin config.
  • Private Subnets
    • outbound traffic is routed to a NAT device. The NAT device is installed in the Public Subnet and connected to an Internet Gateway for outbound access to the internet.
      • NAT Gateway vs. NAT Instance = NAT Gateway is managed for you by AWS and highly available, whereas NAT Instance is a lot more manual work but can be used as a bastion host / jump box​
    • EC2 instances don’t have public IP or ENI
    • You have to use a bastion host (“jump box”) to access instances in the Private Subnet over SSH (port 22)

VPC Endpoints

  • Interface endpoints privately connect your VPC to AWS services, services hosted by other AWS accounts, and supported AWS Marketplace services as if they were in your VPC
    • powered by AWS Privatelink
    • applies to many AWS services (API Gateway, CloudFormation, CloudWatch, S3) 
    • does not go over the internet
    • no need to use an internet gateway, NAT device, DX connection, or VPN
    • Is an ENI with a private IP address, in the subnet that you specify, directing traffic to the service that you specify. Uses DNS to direct traffic to the service. Protected by a Security Group.
  • Gateway endpoints direct traffic to S3 or DynamoDB only, using private IP addresses.
    • Does not enable AWS Privatelink
    • You route traffic from your VPC to the gateway endpoint using route tables. Protected by VPC endpoint policies rather than Security Groups.

3 Types of Network Adapters

  1. ENI – basic type
  2. ENA – for enhanced networking, high bandwidth and low latency
  3. EFA (fabric adapter) – for high performance computing

Security Groups vs. Network ACL (NACL)

  • Security Group is at the instance level, Network ACL is at the subnet level and applies to all instances within that subnet
  • Security Groups don’t have deny rules, Network ACL have accept and deny
  • Security Groups are stateful, Network ACL stateless
  • Security Groups evaluate all rules together, Network ACL processes rules in order
  • Neither can block traffic by country
  • Security Groups have inbound allow rules allowing traffic from within the group, whereas custom security groups don’t allow any inbound traffic by default. All outbound traffic is allowed by default.
  • Security Group default state: outbound rule allows all traffic to all IPs, but inbound has no rules and traffic therefore denied by default
  • NACLs function at the subnet level with separate allow/deny rules for inbound and allow/deny rules for outbound. They are stateless so it’s all about what the rules say each time.  Don’t apply -within- the subnet, only in/iout of the subnet.
  • Default security groups have inbound allow rules (from within the group). Custom security groups do not allow any inbound traffic. All outbound traffic is allowed.
  • VPC automatically comes with a default NACL which allows all inbound/outbound traffic. A custom NACL denies all inbound/outbound traffic by default.

Amazon Route 53

  • Geolocation routing is by location of the user, geoproximity routing is by proximity of the resources
  • weighted routing = split traffic by %
  • Health check = check the health of your resources and only return healthy resources in response to DNS queries
  • apply a routing policy such as latency, weighted, failover
  • Configurations
    • active/passive: in case of failure, return backup resource. Requires failover policy. Manual intervention can be required to then cause a fail-back to the active site. 
    • active/active: return >1 resource. Requires latency policy, weighted policy, or some other policy besides failover. In the case of failover, returns only the healthy resource
    • combination: multiple policies are combined into a tree for more complex DNS failover

Routing Records

  • Best practice is to use DNS names/URLs whenever possible rather than IP addresses. Some exceptions include pointing ELBs directly to the IP address of a peered VPC, or an on-prem resource linked via DX or VPN connection.
  • Alias records provide a Route 53–specific extension to DNS functionality.
    • They let you route traffic to selected AWS resources: ELBs, APIs, CloudFront distributions, S3 buckets, Elastic Beanstalk, VPC interface endpoints, etc.
    • Unlike a CNAME record, they also let you route traffic from one record in a hosted zone (usually the zone apex / naked domain name, such as “example.com”) to another record (e.g. “www.example.com”)
    • When Route 53 receives a DNS query for an alias record, it responds with 1 or more IP addresses that the record maps to
  • CNAME records (canonical name records) redirect DNS queries to any DNS record. For example, you can create a CNAME record that redirects queries from acme.example.com to zenith.example.com or acme.example.org.
    • You don’t need to use Route 53.
    • Unlike Alias records, they can’t be used for resolving apex domain names
  • PTR records = reverse lookup where you map an IP address to a DNS name

AWS Services Calling into a VPC

  • To enable AWS serverless services such as Lambda to access resources inside your private VPC, you provide it with VPC-specific info such as your subnet IDs and security group IDs.

Elastic Load Balancers

  • ELBs send traffic to AWS and on-prem resources. Unlike Route 53, they use resource IP addresses and you don’t get to specify policies such as a weighted policy. VPC flow logs show traffic going to/from an ELB
  • An Application Load Balancer (ALB) makes routing decisions at the application layer aka Layer 7 (HTTP/HTTPS)
    • supports path-based routing and host-based routing (i.e. based on the content of the request in the host field)
    • can route requests to one or more ports on each ECS container instance in a cluster
    • supports authentication from OIDC compliant IDPs such as Google and Facebook via an integration with Cognito
    • periodically sends messages to its targets to check their status – health checks. – and routes only to healthy targets
    • enable access logs which can get pushed to S3. They log info on requester, IP, request type, etc.
  • A Network Load Balancer (NLB) make routing decisions at the transport layer aka Layer 4 (TCP/SSL). They can handle millions of requests per second with extremely low latency. They don’t support path-based routing or host-based routing the way ALB does.
  • A Classic Load Balancer (CLB) operates using TCP, SSL, HTTP and HTTPS. Not as good at high throughput / low latency as NLB. Also unlike NLB, it does not support load balancing to multiple ports on an instance.

AWS Direct Connect (DX) Gateway

  • You can use Direct Connect (DX) to connect an on-prem data centre to one or multiple VPCs
  • DX can take > 1 month to setup
  • For resilience, add a 2nd DX connection. As this can take time to setup and is costly, in the short term consider also adding an IPSec VPN connection (with the same BGP prefix) for resiliency. 
  • You must create one of the following virtual interfaces to begin using DX:
    • Private virtual interface (private VIF): access a VPC using private IP addresses
    • Public virtual interface (public VIF): access all AWS public services using public IP addresses
    • Transit virtual interface (transit VIF): access one or more VPC Transit Gateways associated with DX gateways, within a Region.
  • A hosted virtual interface (hosted VIF) allows another AWS account to access your DX
  • Use AWS DataSync to copy large amount of data from on-prem to S3, EFS, FSx, NFS shares, SMB shares, AWS Snowcone (via Direct Connect).  For copying data, use DMS to copy databases. 

AWS Transit Gateway

  • Central Hub connecting on-prem networks and VPCs.
    • Reduces operational complexity as you can easily add more VPCs, VPN capacity, Direct Connect gateways, without complex routing tables. 
    • Provides additional features over-and-above VPC peering
  • A transit virtual interface is used to access VPC Transit Gateways
  • Pattern for connecting 1 DX to multiple VPCs in the same Region is to associate the DX with a transit gateway
    • on-prem -> DX -> DX location -> transit virtual interface -> transit gateway association -> Transit Gateway -> multiple VPCs 

VPN Connection

  • VPN connections go over the internet
  • AWS Managed site-to-site VPN Connection is connected between a Customer Gateway on the customer side and Virtual Private Gateway (VPG, or VPN gateway) that you create at the edge of your VPC.​