AWS Networking Guide

Prerequisites

AWS networking builds upon fundamental networking concepts. While this guide explains AWS-specific implementations, familiarity with the following networking basics will help you better understand the content:

1. IP Addressing:

   • Understanding of IP addresses (e.g., 192.168.1.1)
   • Subnet masks and CIDR notation (e.g., /24, /16)
   • Difference between public and private IP ranges

2. Network Fundamentals:

   • Basic network routing concepts
   • Understanding of subnets and network segmentation
   • Familiarity with firewalls and security concepts
   • Basic knowledge of DNS and domain names

3. Common Protocols:

   • HTTP/HTTPS for web traffic
   • SSH for secure connections
   • TCP/UDP and common port numbers

If you're new to networking, it is recommended that you do a little research into these topics before proceeding with this guide although don't worry if you don't understand everything at first - AWS networking can be complex even with networking experience. This guide will explain concepts progressively, starting with core components and moving to more advanced features.

Introduction

Understanding AWS networking is fundamental to building secure, scalable, and highly available cloud infrastructure. AWS networking provides:

• Resource Connectivity: Connect your applications, databases, storage, and compute resources
• Internet Access: Control and manage external communications
• Security Controls: Implement multiple layers of network security
• Hybrid Integration: Connect cloud and on-premises infrastructure
• High Availability: Deploy across multiple data centers
• Cost Management: Optimize network traffic and data transfer

AWS networking components are software-defined, making them flexible and programmable to meet your infrastructure needs.

AWS supports both IPv4 and IPv6 although throughout this guide primarily uses IPv4 addressing in its examples and diagrams for simplicity and familiarity.

Mapping Physical Networks to AWS

If you already have experience with physical network infrastructure, AWS networking concepts will feel very familiar, just virtualized. Here's how some common physical networking components map to AWS:

Physical Network	AWS Equivalent	Description
Data Center	Region/Availability Zone	Physical locations where your resources reside
Network Perimeter	VPC	Your private network space with defined boundaries
Router	Route Tables	Directs traffic between different networks
Firewall	Security Groups	Allow/deny stateful inbound/outbound traffic
Switch/Router ACLs	Network ACLs	Allow/deny stateless network layer traffic
Internet Router	Internet Gateway	Connects your network to the internet
Physical Network Links	VPC Peering/Transit Gateway	Connects different networks together
Dedicated Lines	Direct Connect	Private, dedicated connection to AWS

Just as you would segment a physical network for security and organization (e.g., separate networks for production, development, databases), you can create similar logical separations in AWS using VPCs and subnets. The main difference is that in AWS, these components are software-defined, making them more flexible and easier to modify than their physical counterparts.

Core AWS Networking Components

Here is a diagram showing the core AWS networking components:

AWS Region

An AWS Regions is a group of physical data centers in geographic area. These data centers are in different physical location within that region and run isolated from the others.

An example of a region is us-east-1, this region has multiple data centers in North Virginia.

Virtual Private Cloud (VPC)

A VPC is an isolated section of the AWS cloud where you can deploy your resources in a private network space. It provides:

• Complete control over the network environment
• IP address range management
• Network segmentation
• Multiple security layers
• Support for both IPv4 and IPv6

Availability Zone

Availability Zones are the actual data centers, we may not know exactly where they are located, just the general geographic area (region) but we don't need to any more than this. We do know that each can operate independently and are designed to be isolated from each other.

As illustrated, our VPC operates in a single region and spans multiple Availability Zones data centers within that region.

Subnets

Subnets are network segments within your VPC that help organize and secure resources. Each subnet exists in only one Availability Zone. Subnets can be configured as public or private, public subnets have direct internet access and private subnets are not exposed to the internet.

Network Communications

Looking back at our example, we have two EC2 instances (virtual machines that run on the data centers) and two RDS instances (databases). These are protected by an instance level firewall, AWS calls these security groups.

Security Groups

By default a security group will deny all inbound traffic to your instance but allows all outbound traffic. This is a stateful firewall, meaning that return traffic is automatically allowed (e.g. if your instance successfully sends a request to an external service as outbound traffic is allowed, the reply from that request will also be allowed to flow back despite the security group being configured to deny inbound traffic).

Security groups:

• Support allow rules only (implicit deny for all other traffic)
• Can reference other security groups as sources or destinations
• Are applied at the network interface level
• Are stateful - return traffic is automatically allowed
• Multiple security groups can be attached to a single resource

Example security group rules:

Type	Protocol/Port	Destination	Description
HTTP	TCP/80	0.0.0.0/0	Allow incoming web traffic
HTTPS	TCP/443	0.0.0.0/0	Allow secure web traffic
SSH	TCP/22	10.0.0.0/16	Allow internal SSH access
PostgreSQL	TCP/5432	sg-database-apps	Allow access from application tier

Network ACLs

Network ACLs provide another layer of security by allowing us to control traffic at the subnet level. The default configuration allows our traffic through so unless anything has been changed in your configuration, we don't actually need to configure anything for our instances to communicate with each other, but that doesn't mean we shouldn't. It is probably wise though to thoroughly understand security groups before learning about Network ACLs to avoid confusion as the rules do not work in the same way. You will need to be familiar with both if managing production environments and taking AWS certification exams.

Network ACLs provide subnet-level traffic filtering:

• Stateless (requires explicit rules for both inbound and outbound traffic)
• Support both allow and deny rules
• Rules are evaluated in numerical order
• Applied at the subnet boundary
• Each subnet must be associated with a NACL

Network ACLs vs Security Groups

Key differences between these two security controls:

Feature	Network ACLs	Security Groups
Scope	Subnet level	Instance/interface level
Rule Types	Allow and deny rules	Allow rules only
State Awareness	Stateless	Stateful
Rule Processing	Processed in order	All rules evaluated
Default Action	Deny unless explicitly allowed	Deny unless explicitly allowed
Rule Limits	Limited to 20 rules per NACL	Up to 60 rules per group

Route Tables

For traffic to flow between subnets, we need to have route tables. AWS creates default route tables for us but there are many circumstances where we may need to create our own.

• Each subnet requires a route table
• Routes specify destinations for network traffic
• More specific routes take precedence
• Support both IPv4 and IPv6 routing

Example route table:

Destination	Target	Purpose
10.0.0.0/16	local	Internal VPC traffic
0.0.0.0/0	igw-id	External internet traffic

External Network Communications

We are now armed with the information we need to communicate between resources within our VPC. What communication to/fro outside of our VPC?

Lets look at the diagram again:

Internet Gateway

An Internet Gateway (IGW) enables communication between your VPC and the internet. A VPC can have only one IGW, this is our single entry and exit point for internet traffic. Each Availability Zone shares the same IGW.

*Note: Remember this is a virtual configuration, AWS does not rely on a single device to route all of our internet traffic from multiple Availability Zones, each has its own infrastructure. You may come across diagrams that show multiple internet gateways, and gateways positioned inside and outside of the VPC and Availability Zones so it can be confusing. Our diagram illustrates the logical setup as it's configured, a single IGW configured for the entire VPC.

The Internet Gateway is:

• Horizontally scaled and highly available without any configuration
• Provides the entry and exit point for internet traffic
• Performs Network Address Translation (NAT) for instances with public IPv4 addresses
• Supports both IPv4 and IPv6 traffic

What the Internet Gateway can't do it route traffic to/from resources on private subnets, or to/from resources in public subnet which don't have a public IP address assigned to them. If a public IPv4 has been assigned in the public subnet, the gateway will translate to/from its private IPv4 address. For IPv6 in the public subnet, there is no translation done, the IPv6 address is assigned to the instance itself.

NAT Gateway

A NAT Gateway enables our private subnet resources to access the internet while preventing inbound connections:

• Managed AWS service that handles outbound internet connectivity
• Uses an Elastic IP address for consistent outbound traffic source
• Scales automatically based on demand
• Recommended for production workloads over NAT instances

As illustrated, the NAT Gateway is configured in a public subnet.

There is a cost associated with the NAT Gateway, it is a managed service and scales automatically based on demand.

*Note: If you a here as a hobby user or just learning and have good Linux skills, there's nothing stopping you from creating your own NAT Gateway using a Linux instance on your public subnet. It may be a good way to learn about setting up various components and configuring the network. This is certainly not recommended for production workloads though and will definitely be the incorrect answer if asked how to set up a reliable and scalable solution in an AWS certification exam!

VPC Endpoints

It is likely you'll have backend services which don't need to be exposed to the internet and shouldn't be for security reasons. Within the VPC, we have already discussed how resources on our subnets can communicate with each other. But what about communication with other AWS services? Resources on public subnets with public IPs can use the internet gateway and we could set up a NAT gateways for others, although there is a much more secure way to do this, VPC endpoints:

Interface Endpoints:

An AWS Interface Endpoint is a virtual device that allows you to privately connect your VPC resources to supported AWS services without requiring an internet gateway, NAT device, or public IP address. It uses AWS PrivateLink technology to create an Elastic Network Interface (ENI) within your VPC, enabling secure and efficient communication between your instances and AWS services.

There is a cost associated with the Interface Endpoint, it is a managed service and scales automatically based on demand.

Gateway Endpoints:

Line Interface Endpoints, an AWS Gateway Endpoint allows you to privately connect your VPC to AWS products, unfortunately only two services are supported though, S3 and DynamoDB. However a big benefit of using Gateway Endpoints is that there is nothing to manage and there are no additional costs so is difficult to find a reason not to use it if using S3 and/or DynamoDB.

Benefits of either of these VPC endpoint types:

• Improved security by keeping traffic within AWS network
• Reduced data transfer costs (no internet gateway charges)
• Better network performance with lower latency
• No need to manage NAT gateways or internet gateways
• Simplified security group and routing configurations

Common Network Patterns

Three-Tier Architecture

A production-grade architecture pattern that separates application components into distinct network layers:

• Web Layer:

  • Application/Network Load Balancer
  • SSL/TLS termination
  • WebSocket support
  • HTTP/2 and gRPC support
  • WAF integration

• Application Layer:

  • Auto Scaling Groups
  • Container orchestration
  • Service discovery
  • Application security groups

• Data Layer:

  • Automated backups
  • Read replicas
  • Encryption at rest
  • Point-in-time recovery

Key security considerations:

• Web layer in public subnets
• Application and data layers in private subnets
• Security groups restrict access between layers
• Network ACLs provide subnet-level security

Multi-AZ Design

A high-availability infrastructure pattern implementing redundancy across Availability Zones:

Technical implementation details:

• Compute Layer:

  • Auto Scaling Groups span AZs
  • Instance health checks
  • Automated instance replacement
  • Cross-AZ load balancing

• Database Layer:

  • Synchronous replication
  • Automatic failover (typically 1-2 minutes)
  • Automated backups from secondary
  • Independent storage in each AZ

• Network Layer:

  • Route tables per AZ
  • NAT Gateway per AZ
  • Cross-AZ data transfer
  • Zonal DNS resolution

Performance considerations:

• Cross-AZ latency: typically < 2ms
• Data transfer costs between AZs
• Read replica placement strategy
• Load balancer response times

IPv6 in AWS

AWS provides native IPv6 support across its networking components. Here's what you need to know:

Key Differences from IPv4

• IPv6 addresses are automatically assigned from Amazon's pool of IPv6 addresses
• No need for NAT - all IPv6 addresses are publicly routable
• IPv6 CIDR blocks are fixed at /56 for VPCs and /64 for subnets
• You can't bring your own IPv6 addresses to AWS

IPv6 Support by Component

• VPC: Can be dual-stack (IPv4 + IPv6) or IPv6-only
• Subnets: Can enable automatic IPv6 addressing
• EC2 Instances: Can receive both IPv4 and IPv6 addresses
• Internet Gateway: Works with both IPv4 and IPv6
• Security Groups: Can have separate rules for IPv4 and IPv6
• Route Tables: Support distinct routes for IPv6 traffic

IPv6 Route Table Example

Destination	Target
2600:1f16:409:6700::/56	local
::/0	igw-id

This guide focuses on IPv4 for clarity and familiarity, but as the internet continues to evolve, understanding AWS's IPv6 capabilities becomes increasingly important for network architects and administrators.

Advanced Networking Features

1. VPC Peering

Technical Implementation: Direct network connection between two VPCs
Use Cases:

• Inter-VPC resource access
• Cross-account service sharing
• Regional application deployment

2. AWS Transit Gateway

Technical Implementation: Central network hub for connecting multiple networks
Use Cases:

• Multi-VPC architectures
• Hybrid cloud deployments
• Centralized network management
• Complex routing requirements

3. VPN Connections

Technical Implementation: Encrypted IPsec tunnels over the internet
Types:

1. Site-to-Site VPN:

   • IPsec VPN connection to on-premises network
   • BGP routing support
   • Redundant tunnels for high availability

2. Client VPN:

   • OpenVPN-based remote access
   • Integration with identity services
   • Split-tunnel configuration options

4. Direct Connect

Technical Implementation: Dedicated physical network connection to AWS
Technical Specifications:

• Bandwidth options: 1Gbps to 100Gbps
• BGP routing protocol support
• LAG (Link Aggregation Groups) support
• Optional encryption with MACSec

Performance Considerations:

• Consistent network latency
• Guaranteed bandwidth
• Bypass internet congestion
• Support for jumbo frames

Best Practices

Network architecture recommendations for optimal performance and security:

1. Network Design

• IP Address Management:

  • Plan non-overlapping CIDR blocks for VPCs
  • Reserve IP ranges for future expansion
  • Document IP allocation strategy
  • Consider IPv6 requirements early

• Subnet Design:

  • Size subnets according to workload requirements
  • Reserve at least two /24 subnets per AZ
  • Implement separate subnets for different tiers
  • Plan for subnet IP consumption growth

2. Security Architecture

• Defense in Depth:

  • Layer security controls (NACLs, Security Groups, WAF)
  • Implement least-privilege access
  • Use VPC endpoints for AWS service access
  • Enable encryption in transit

• Access Controls:

  • Implement both NACLs and Security Groups
  • Use Security Groups for application-level controls
  • Use NACLs for subnet-level controls
  • Keep rule numbers spaced for easy additions

3. High Availability

• Multi-AZ Design:

  • Deploy resources across multiple AZs
  • Implement redundant NAT Gateways
  • Use Auto Scaling Groups for compute resources
  • Configure automatic failover for databases

• Resilient Connectivity:

  • Plan for component failures
  • Implement redundant network paths
  • Use health checks and automatic failover
  • Monitor connection status

4. Operations

• Monitoring:

  • Enable VPC Flow Logs with full metadata
  • Set up CloudWatch metrics for network interfaces
  • Configure alerts for network anomalies
  • Implement packet-level monitoring where needed

• Documentation:

  • Maintain current network diagrams
  • Document IP address allocation
  • Keep security group rules documented
  • Track changes to network configuration

5. Infrastructure as Code

• Resource Management:

  • Use resource tagging for network components
  • Implement automated backup procedures
  • Document network architecture
  • Maintain configuration in Infrastructure as Code

• Automation:

  • Automate security group updates
  • Use automated compliance checks
  • Implement automated failover testing
  • Configure automated backup verification