A VPC is a private virtual network within AWS where you can store all of your AWS services. It will have gateways, route tables, network access control lists (ACL), subnets, and security groups, and will be a logical data centre in AWS.

Things to note:

• Each subnet exists within 1 availability zone.
• Security groups are stateful, ACL’s are stateless
• VPC’s can be peered within the same account and across AWS accounts
• Transitive peering is not allowed, meaning you cant hop from one VPC to another, via another VPC. You must have direct access.

Why use a VPC?

When you open a service on a public cloud, it is effectively open to the world and vulnerable to internet threats. You lock your instances down and secure them from outside threats by putting them in a VPC. The VPC limits the types of traffic, IP addresses, and individuals who have access to your instances.

This stops unauthorised users from gaining access to your resources and protects you from DDOS attacks. Because not all services require an internet connection, they can be safely stored within a private network. You can then only allow particular machines to connect to the internet.

This is a problem if you wished to install software or access the internet from private instances that aren’t connected to the internet. However, there are a few options for dealing with this issue, which I will discuss next.

NAT Instances

The dilemma of “how can I install stuff from the internet on my secured private instances” can be solved with a NAT instance.

In a public subnet with internet access, a NAT instance is built. Your private instance will be able to make requests to the internet once you grant access from your private instance to your NAT. This access is one-way, which means that no one from the internet can get into your instance.

Things to note:

• A NAT instance must be in a public subnet
• It must have an Elastic IP
• There must be a route from your private subnet into the NAT instance
• You can manually create high availability using Autoscaling groups and multiple subnets
• Different to a Bastian because a NAT is used to provide internet access to private instances, a Bastian is used to administer instance using SSH for example.
• They are now sort of deprecated and replaced with NAT Gateways

NAT Gateways

NAT Gateways have replaced NAT instances because they provide the same level of security and access to the internet from a private subnet. They are, however, far easier to set up and scale because Amazon handles everything.

Things to note:

• Scale automatically up to 10Gbps
• No need to manually patch — amazon takes care of this
• Not associate with security groups
• automatically assigned a public IP

Network Access Control Lists (ACL)

A Network ACL is included with a VPC by default, and it allows all inbound and outgoing traffic. If you set a default Network ACL, however, it will block all inbound and outgoing traffic, forcing you to explicitly enable traffic.

A Network ACL must be connected to each subnet within a VPC, but each subnet can only be connected to one VPC at a time. The ACL, on the other hand, can be connected to several subnets.

Things to remember:

• The Network ACL contains an ordered list of rules to allow traffic
• The convention is to start from 100 rules and go up in increments of 100.
• The rules will be considered in order to make sure if you want to allow all ssh access apart from a certain IP address, that you add your block rule before your allow all rule.
• There are separate rules for inbound and outbound traffic, so you must set up rules for each.
• They are stateless meaning responses to inbound traffic are dependent on outbound traffic rules and this applies the other way around.
• Block IP address using Network ACL’s and not Security groups

Resiliency

For resiliency, it is advisable to always have 2 public and 2 private subnets and ensure they are both in different availability zones. The same applies to Elastic Load Balancers.

NAT Instances are a little more difficult to make highly available so it’s advised to use NAT Gateways instead, as all of this is taken care of and requires no manual effort.

You can always monitor traffic within your VPC by turning on VPC flow logs.