AWS 101 - Networking Basics
I’m currently working towards the AWS Solutions Architect - Associate exam and thought it would be a great idea to produce some notes on each of the AWS networking services. The process of researching, producing and publishing content on a topic really helps to cement it in my head. It’s also great for quick reference in the future. Hopefully this content is of some use to you.
In this AWS ‘101’ post I’ll be going over the basics of networking in the AWS cloud.
1.0 VPC
Within AWS ‘VPC’ stands for Virtual Private Cloud.
Every AWS account comes with a default VPC which can be deleted. There are no costs for creating or deleting VPCs.
1.1 What is a VPC?
A VPC is a virtual network environment that is logically separate from other AWS customers.
Most, but not all, AWS services are deployed and run within a VPC.
Think of the traditional on-premise network fabric made up of physical switches, routers and firewalls. On that network there may be multiple VLANs, subnets, access control policies, etc. In AWS world a VPC is analogous to the physical fabric of an on-premise network.
1.2 Regions and AZs
VPC is a region specific service.
A VPC spans every AZ (Availability Zone) within a region, but not across multiple regions.
If you wish to deploy resources to two or more regions, say for example ’eu-west-2’ (London) and ‘us-east-2’ (Ohio), you would need to deploy two or more VPCs. If resources needed to communicate with each other, services such as VPC Peering or Transit Gateway could be used.
1.3 IPv4 CIDR Block
When creating a VPC you will need to specify a private IPv4 CIDR address block. The netmask must be between a /16 and /28. E.g. 10.0.0.0/16
This private IPv4 network will then be used by resources within the VPC.
The large VPC network can then be subnetted into smaller networks per AZ which I will go into further detail in section #2.1.
1.3 Default VPC
Every AWS account comes with a default VPC.
For convenience and backwards compatibility with EC2-Classic (more on that later) the default VPC is setup for internet access from the get go. EC2s are given public IP addresses and can route to the internet by default.
It’s easy to identify default VPCs as they have short names E.g. ‘vpc-71371b19’.
1.3 Custom VPC
Custom VPCs don’t have access to the internet by default.
To connect a custom VPC to the internet, first create an Internet Gateway and then update the Route Table so internet bound traffic is routed to the Internet Gateway (more on this later).
They use a longer naming convention than default VPCs. E.g. ‘vpc-0c775fc31c573bead’.
1.3 Quota limitations
AWS places a default limit of 5 VPCs per region, per AWS account.
The quota can be increased up to a maximum of 100 VPCs per region, per account, via the ‘Service Quotas’ section in thr AWS console. See AWS VPC quotas.
You could deploy 4 VPCs in ’eu-west-2’ (London) region and another 5 VPCs in the ‘us-east-2’ (Ohio) region.
However, it wouldn’t be possible to create 7 VPCs in the ’eu-west-2’ region without a Service Quota extension from AWS.
1.4 VPC Peering
It is possible to implement network connectivity between VPCs with VPC Peering.
VPC Peering supports a direct connection between two VPCs only. Once established, network traffic can be routed between both networks using IPv4 or IPv6 private addresses. The service is managed by AWS and as such is highly available. There are no routers, VPNs, etc. to configure or maintain.
Transitive routing is not supported. I.e. ‘VPC A’ cannot talk to ‘VPC B’ via ‘VPC C’. Each VPC must be peered directly to each other to communicate.
Since 2017 Inter-Region VPC Peering has been supported meaning VPCs can be peered with any VPC in any region, subject to subnet overlap constrains.
1.5 Transit Gateway
A drawback of VPC Peering is that the connection is only between two VPCs.
Imagine an organisation deploying 5 VPCs and each of these needing network connectivity to each other. Each VPC would have a VPC peering connection to every other VPC, leading to 4 peers per VPC or 20 peers in total. This would be a mesh network topology design.
In 2018 AWS released the Transit Gateway. It provides a hub-and-spoke network design between multiple VPCs and can also be used to establish VPN connections to customer managed systems. The Transit Gateway can also be configured to support multicast traffic. Multicast delivers a single stream of data to many users simultaneously.
Transit Gateway is a managed AWS service and as such is highly available and requires no maintenance.
1.6 Transit VPC
Prior to the release of the Transit Gateway there was a design pattern called a ’transit VPC’.
A single ’transit’ VPC was used to establish VPC Peering connections to multiple VPCs in a hub-and-spoke network design. As VPC Peering doesn’t support transitive routing, EC2 instances running virtual routers were deployed in the transit VPC to provide network connectivity. As routing was handled by EC2’s, the configuration, management and deployment of connectivity was managed by the customer.
Where possible, I would recommend against using a Transit VPC. Instead use the AWS managed Transit Gateway.
More info on legacy Transit VPC design here.
2.0 Subnets
2.1 What is a subnet?
A VPC network will span all AZs (Availability Zones) in a region. Subnet’s allow us to divide the network up into smaller sub-networks which are then assigned to specific availability zones.
I might create a VPC within the ’eu-west-2’ (London) region with a network of 192.168.0.0/16.
The network could then be divided up as follows:
eu-west-2a - 192.168.1.0/24
eu-west-2b - 192.168.2.0/24
eu-west-2c - 192.168.3.0/24
Compute resources created in an Availability Zone will receive an IP address in the corresponding subnet.
AWS manages DHCP for us. By default no additional configuration is required.
2.2 Special IP addresses
AWS reserves the first four and the last IP address within every subnet. This is to comply with RFC1918 networking protocols, and also to provide automated DNS and routing services.
A 192.168.1.0/24 subnet would have the following reserved addresses:
192.168.1.0 - RFC1918 Network address
192.168.1.1 - AWS VPC Virtual router
192.168.1.2 - AWS VPC DNS server
192.168.1.3 - AWS Reserved for future use
192.168.1.255 - RFC1918 Network broadcast address
For exact guidance see the AWS Docs.
2.3 Route Tables
The Route Table contains instructions (called routes) on where AWS should forward network traffic destined for outside of the subnet.
Route Tables can be created and then associated against multiple subnets.
In many ways it behaves like a virtual router with an interface in each subnet. The interface always has the second IP address of a subnet CIDR range (as we saw #2.2).
An EC2 instance with IP address 192.168.1.35/24 trying to communicate with 192.168.24.33 would send the traffic to its default gateway as the remote host is on a different subnet.
In this instance, the default gateway is the AWS virtual router on 192.168.1.1. See section #2.2.
2.3 Public Subnets
A public subnet is a subnet with a route to an internet gateway.
Resources deployed within a public subnet can receive inbound traffic from the internet (subject to firewall, security group and NACL rules).
2.4 Private Subnets
A private subnet has no direct route to the internet. Resources cannot receive inbound traffic from the internet.
It is possible for resources in a private subnet to initiate outbound connections to the internet (to download security updates, etc.) via a NAT Gateway.
Backend infrastructure such as databases should always be deployed to a private subnet.
Only resources that must be accessed by the public should be in a public subnet.
2.5 Network ACLs
Subnets can have access control lists defined against them to limit outbound traffic only.
See section #5.1 for more information (coming soon).
2.6 Broadcast traffic
AWS supports supports unicast and multicast traffic only. Broadcast frames/packets will be filtered out.
It is possible to deploy large subnets within AWS without worrying about broadcast domain size.
2.6 MTU
The default MTU size for Ethernet devices (including EC2) is 1500 bytes. It specifies the largest permissable frame that can be passed over a network.
Whilst this is usually ample sometimes a larger number is desireable for moving large quantities of data.
Most modern EC2 instance types support Jumbo frames (i.e. an MTU over 1500). It is possible to configure Jumbo frames of up to 9001 MTU within a single VPC.
Jumbo frames outside of a VPC or VPC peering connection are supported.
3.0 External Connectivity
3.1 NAT Gateways
NAT Gateways allow resources deployed within a private subnet to initiate outbound connections to the internet.
Crucially, they do not support inbound connections.
They should be deployed within a public subnet for internet connectivity. Once deployed, update the route table of a private subnet to use the NAT Gateway.
Traffic destined for the internet is first sent to the NAT Gateway. NAT Gateways have a single public IP address, therefore all traffic from the private subnet will undergo Network Address Translation (NAT) and Port Address Translation (PAT). It will then continue on its journey to the public internet.
3.2 Internet Gateways
Internet Gateways allow resources within public subnets to initiate and receive connections to and from the internet.
AWS manages a large pool of public IPv4 addresses that can be used by instances. Resources created within a public subnet are only aware of their internal VPC IPv4 address. The Transit Gateway provides one-to-one NAT between this internal IP and a public IPv4 address.
This service is managed by AWS and therefore highly available.
3.3 Egress Only Internet Gateways
Egress Only Internet Gateways are in essence an IPv6 version of the NAT Gateway.
They do not support inbound connections.
3.3 Elastic Network Interface
Elastic Network Interfaces (ENI) are in essence a virtual NIC.
If you’re familiar with virtualisation, think of the usual vNIC in VMware ESXi or Hyper-V. Tis is the same as an ENI.
An EC2 instance can support multiple ENIs and each ENI can support multiple Elastic IPs.
3.3 Elastic IP
Elastic IPs are static addresses taken from the AWS public IPv4 address pool.
They can be associated associated against services such as EC2s and re-assigned at will to other services.
Once finished with an Elastic IP it can be ‘deleted’. At this point the address is returned to the public AWS IPv4 address pool for use by other customers.
3.4 Public IP
Public IPs are dynamic addresses taken from the AWS public IPv4 address pool.
EC2 instances within a public subnet will automatically assume a Public IP address. The dynamic assignment of this IP persists until the EC2 is stopped.
3.4 VPC Endpoints
VPC Endpoints allow services deployed within a VPC to access external services via a virtual private IP address.
Some AWS services such as S3 and DynamoDB do not run within a VPC. These types of services often require Internet Gateways to be deployed, and for traffic to be sent over the public internet.
When a VPC Endpoint is created, a virtual interface is created (along with a private IP address) within your VPC. Resources such as EC2s can interface with services (such as S3 and DynamoDB) via this virtual IP.
Comments