Last week I was asked to create a 3 tier VPC (Virtual Private Cloud) from scratch and demo it to the company. This is what I learned.
Using tools like AWS (Amazon Web Services) CloudFormation or Terraform can build a VPC quicker — like a microwaveable meal. However, if you’d like to learn the intricacies of a VPC like how a chef learns how to prepare a meal — you’ll have a better understanding and appreciation for your cloud infrastructure.
In our development environment, I clicked over to VPC in the console and followed the instructions to create a VPC — using 10.0.0.0/16 as the network to make available the largest number of IP addresses, allowing me to have 65,536 IP addresses.
I found CIDR.xyz helpful in understanding CIDR notation.
Now create 6 subnets, 2 public, 2 private, and 2 data (1 of each will be in their own availability zones). Using multiple availability zones allows for redundancy.
Instead of 5 more screenshots, the Name tag with the appropriate naming convention will look as follows:
Private — 10.0.2.0 — us-east-2a
Data — 10.0.3.0 — us-east-2a
Public — 10.0.4.0 — us-east-2b
Private — 10.0.5.0 — us-east-2b
Data — 10.0.6.0 — us-east-2b
Next, create an Internet Gateway to attach to your VPC so that your Public Subnets have access to the internet, and the internet has access to your Public Subnet.
Next, create a NAT Gateway for your Private Subnets to access the internet (1 per availability zone). However, NAT Gateways need to be created in the Public Subnet.
To finish creating the NAT Gateway you need to select an Elastic IP from the drop-down or click Create a New EIP.
Next, create Route Tables and associate them to our Subnets. Route tables direct traffic within the VPC.
I’m going to edit the route and add access to the internet by adding a 0.0.0.0/0 Destination Targeted at the Internet Gateway.
Next to the Routes tab is Subnet Associations, select it, then click the Edit subnet associations button.
You’ll select the Public Subnets — this will give them internet access.
Next, you’ll create a route table for the Private Subnet — edit the routes like the public with 0.0.0.0/0 as the Destination Targeted at the Nat Gateway.
You’ll want to add the Subnet Associations.
We can create a final route table for the Data Subnet. Associate the Data Route Table with Data Subnet.
Adding a flow log will help capture the IP traffic.
The filter will specify the type of traffic to be logged. Choose All to log accepted and rejected traffic, Rejected to record only rejected traffic, or Accepted to record only accepted traffic.
This data gets sent to either CloudWatch or an S3 Bucket.
An S3 service endpoint will allow your VPC to access data in an S3 bucket (maybe your data subnet wants to connect to it).
We can help you navigate the world of AWS VPC’s — we’re also hiring, check out our open positions on our Careers page.
There’s been a ton of coverage of the recently discovered Capital One breach. I’m generally very skeptical when AWS security makes the news; so far, most “breaches” have been a result of the customer implementing AWS services in an insecure manner, usually by allowing unrestricted internet access and often overriding defaults to remove safeguards (I’m looking at you, NICE and Accenture and Dow Jones!). Occasionally, a discovered “AWS vulnerability” impacts a large number of applications in AWS – and it also impacts any similarly-configured applications that are *not* in AWS (see, for example, this PR piece…um,…Read More