Jump to content ↓
Web Developer in London, UK.
Menu

AWS - Setting up a VPC from scratch for a web application

Quick checklist for setting up a VPC on AWS for the purpose of hosting a public web application, bare basics and by no means exhaustive. The aim is to end up with a VPC with both public and private subnets, similar to Scenario 2: VPC with Public and Private Subnets (NAT) from the AWS documentation.

Disclaimer: Provided as is, with no warranty, responsibility or liability implied or otherwise.

Checklist

  • Create VPC:
    • CIDR block size between /16 & /28.
    • Sample address counts based on netmask:
      • /16 address count: 65,536
      • /24 address count: 256
      • /28 address count: 16
      • More @ Wikipedia
    • Take note to create the VPC in the desired region (dropdown in header, easy to miss)
    • Can’t be changed later so be sure to create a big enough range of addresses
  • Create Subnets:
    • Needs to fit within VPC CIDR size and resulting subnets must not overlap
    • Smallest size is /28
    • Can be the same size as the VPC (if only a single subnet is required)
    • Take away 2 from the resulting address count to understand how many usable/assignable addresses there will be within the subnet (2 are required for the subnet and broadcast addresses)
    • Subnets can be configured to automatically assign a public IP address whenever a new instance is launched, it can be useful to designate subnets as “public” (publicly addressable) and “private” (private IP address only). Note this isn’t a strict option and only sets the initial setting when launching a instance (and can be changed).
    • If creating “public” and “private” subnets create a pair for each availability zone, when instances need to communicate across subnets it’s better if they don’t also need to communicate across AZs unnecessarily.
    • Example use case of “public” and “private” subnets, database (e.g. RDS or separate EC2 instance) lives in the “private” subnet and only has a private IP address, web application server is in the “public” subnet and therefore is publically addressable and can communicate with the database.
  • Create Internet Gateway and attach to VPC:
    • Needed for connections to the internet
    • Attach to VPC once created
    • Note that for private instances a NAT Gateway is instead required (see next step)
  • Create NAT Gateways for each private subnet:
    • The previous Internet Gateway is enough for instances (public subnet) with publically addressable IP address to connect to the internet, for instances without (private subnet) a NAT Gateway is required.
    • An Elastic IP address is required for each NAT Gateway, the option to create one is available when creating a NAT Gateway or an existing (unassociated) EIP can be used.
    • Note that a single NAT Gateway can suffice, but ideally there should be one per private subnet (or at the very least per AZ) for redundancy.
  • Update Route Table to enable internet connectivity:
    • On creating a VPC a main route table will automatically have been created for it
    • On the main route table, add a route with destination 0.0.0.0/0 (catch all address) and target the Internet Gateway that was created in a previous step (igw-*), this will give internet connectivity to public instances across the VPC
    • The destination can be scoped to a narrow range of IP addresses if only limited connection is required (e.g. other EC2 instances in another VPC)
    • The main route table will be used by default for all subnets but additional route tables can be created if varying degrees are desired.
    • For each private subnet create a new route table that routes the destination 0.0.0.0/0 to the NAT Gateway in the same subnet (that was created in the previous step) as opposed to the Internet Gateway. Private instances (e.g. no publically addressable IP address) cannot establish an internet connection via the Internet Gateway and require to be routed via a NAT Gateway.
  • Create Security Groups:
    • By default, no inbound traffic is allowed
    • By default, an outbound rule allows all outbound traffic
    • Create a group for SSH connections, whitelist external IPs as needed
    • Create a group for HTTP and HTTPS, that allows connections from everyone
    • When instances in the VPC need to communicate, they will also need to have rules added to a security group that they’re apart of to allow it. e.g. Port 22 on 10.0.0.0/16 to allow all instances to accept SSH connections from instances in the VPC