What Architects Need to Know About Networking on AWS

As an architect, you may not have thought too much about the network management before. At least that’s how it used to be for me. But since I’ve been designing architectures for AWS, network structure has become much more important to me.

With Amazon VPC (Virtual Private Cloud), we have full control over our network and can adapt it to the workload’s needs, which was almost impossible on-premises. Also, the configuration of a VPC has effects on your architecture besides the networking aspect.

In the following, you will learn about all the concepts of a VPC that are important from an architect’s perspective.

This is a cross-post from the Cloudcraft blog.

VPC and Subnets

By default, AWS provisions default VPCs in your AWS account. A default VPC allows you to spin up EC2 instances without thinking about the network at all. However, when deploying production-critical workloads, it is worth creating VPCs tailored to your needs.

To create a VPC, all you need to configure is a private IP address range. You will find some thoughts on that at the end of this blog post. A VPC consists of multiple subnets. The subnets segment the private IP address range of the VPC.

Routing Table

The default VPC routes traffic between all subnets and the Internet.

By defining routing tables per subnet, you are in control of the traffic flow. For example, you could divide your VPC into public and private subnets. Only the public subnets come with a route to the Internet. Therefore, private subnets are neither reachable from the Internet nor can establish connectivity with the Internet.

Additionally, it is common to define a separate zone connected with your on-premises network. For example, your VPC could consist of a public subnet with Internet connectivity, a subnet peered with your on-premises network, as well as a private subnet without a route to the Internet and on-premises network.

Gateways and Endpoints

Usually, a VPC does not exist in isolation but enables connectivity with other networks. The following list summarizes your options.

• An Internet Gateway ensures inbound and outbound Internet connectivity.
• A NAT Gateway enables outbound Internet connectivity.
• A Virtual Private Gateway routes traffic through site-to-site VPN connections or dedicated network connections (AWS Direct Connect).
• A Transit Gateway enables a hub and spoke network topology.
• VPC Endpoints enable connectivity to AWS services that would otherwise require outbound Internet connectivity.

Availability Zone

AWS divides its global infrastructure into Regions and Availability Zones. A region consists of at least three Availability Zones. An Availability Zone itself is made up of at least one data center.

It is essential to know that there is a 1-to-1 relationship between a subnet and an availability zone. For example, if you want to distribute your workload among three availability zones to achieve high availability, you need to plan with at least three subnets.

Keep in mind that you need to create a subnet for each availability zone and network segment. For example, you need six subnets to utilize three availability zones and divide your network into public and private subnets.

Network Access Control List (NACL)

A subnet is not only linked to a routing table but a Network Access Control List (NACL) as well. As mentioned before, traffic is routed between all subnets by default. However, using NACLs allows you to define firewall rules controlling traffic entering and leaving a subnet.

Be aware of the fact that NACLs are stateless firewall rules. Therefore, the granularity for controlling traffic is limited. Also, configuring stateless firewalls is complex.

A modern approach to network segmentation

In former times, subnets and NACLs have been used to isolate workloads from each other and limit the blast radius of a security incident. However, things are different in the cloud. The most crucial difference is that machines are not static anymore and instead your infrastructure grows and shrinks automatically, making firewall rules based on IP addresses no longer sufficient. Segmenting a network into many subnets is getting harder, as you need one of those subnets per availability zone.

Luckily, there is a modern approach to control traffic within your VPC: Security Groups. A Security Group restricts inbound and outbound traffic to EC2 instances, RDS database instances, and many other resources with VPC integration. To define a firewall rule, you no longer need to specify an IP address or IP address range. Instead, it is possible to reference other Security Groups. Doing so allows you to control traffic on a fine-granular level.

In the following example, only the load balancer can connect to the EC2 instances, and only the EC2 instances can access the database—all of that without static IP addresses and IP address-based firewall rules.

Plan ahead

When designing the architecture, make sure to plan ahead from a network perspective. There are two critical questions to consider.

First, estimate the number of private IP addresses the infrastructure will require within the following years. Then, breakdown those numbers per subnet. Compare those numbers with the available IP addresses within your VPC and subnets. Keep in mind that AWS reserves 5 IP addresses per subnet for internal use.

Second, make sure that the IP address range for your VPC does not overlap with any networks that you might need to peer with in the future. If necessary, ask the ones responsible for managing IP address ranges in your organization for help. Even if you are not planning to peer with any networks now, this requirement will likely come up in the future.

Summary

As an architect for cloud infrastructures, it is necessary to know about the networking concepts on AWS. Keep in mind that some of the network-level decisions impact other areas such as Availability Zones, for example.