I’ve been doing some AWS study over the past week, primarily with a focus on networking and external connectivity. Below are some notes, this is not a how to or a tutorial, but rather architecture fundamentals.
Regions and Availability Zones
AWS is broken up into several Regions, which are separate geographic areas. Within each region are several Availability Zones which are isolated failure domains within the region.
Some services such as EC2 (virtual machines) can be deployed in specific availability zones, and with other services such as S3 (object storage), Amazon guarantees that data will be stored in several zones within the region.
One interesting note is that availability zones names are randomised per account. For example, Zone A in one account may be mapped as Zone B in another account. This is done to help AWS distribute the load evenly as many customers would dump their workloads in the first zone by default.
For High Availability, it would be ideal for workloads to span several regions.
Virtual Private Cloud (VPC)
The VPC is the primary building block of AWS networking, it provides a set of tools and services to help you define and create a virtual datacenter. Some of what they provide include creating subnets, routing, security, NAT, DNS, DHCP, and VPNs.
VPCs are created per region, and span all the availability zones in that region. VPCs do not span regions, but connectivity between VPCs in different regions is possible via VPC Peering.
Some VPC caveats include
- No multicast (HSRP and similar protocols will not work)
- IPv6 must be enabled if needed (it is off by default)
Each VPC is assigned a supernet, typically we want to make this as large as possible (/16). We can then carve this into multiple smaller subnets.
- Each subnet is tied to an availability zone within the region
- Routing between VPC subnets is enabled by default
- The internal subnets can range between /16 and /28 in size
On the topic of subnets and VPCs, AWS provides each account a default VPC per region as this allows customers to provision services without worrying about networking, but there is a catch to be wary of here. Every default VPC uses the same prefix: 172.31.0.0/16 - which means we cannot peer two default VPCs due to overlapping addressing.
Public IP Addressing
Subnets can be configured to have public IP addressing, and the VPC handles 1:1 NAT between your EC2 instances and an IP from Amazons public IP pool.
A key caveat is that these IP addresses are dynamic, once the instance release the address there is no guarantee that it will ever have the same public IP reassigned.
For static IP addressing, AWS provides the Elastic IP Address service.
Elastic IP Address
One great feature of Elastic IPs is that they can be moved between EC2 interfaces. This can be used to provide simple (though sometimes a bit slow) failover in the case of EC2 instance failure.
A key limitation of AWS is that Amazon enforce a limit of 5 Elastic IPs per region.
Network Services within a VPC
AWS provides several basic network services inside each VPC.
AWS DHCP is able to provide
- IP addressing
- DHCP should always be used to assign IPs to EC2 instances, even if those IPs are static. Simply changing the IP inside the VM will not work as AWS needs to know about the changed IP.
- DNS Servers (if not using those provided by AWs)
- Custom domain names
- NTP Servers
Each VPC has an AWS DNS server supplied by AWS. This server contains the private and public IP addresses in the VPC.
An alternative to this is to use Route 53.
That’s it for now. In future posts we’ll cover network security as well as Internet and VPN connectivity.