Skip to main content
Welcome. This is the fifth section in the Designing for Reliability series. This lesson explains how to increase reliability for network services. It focuses on core networking elements that most affect availability and resiliency, using concise questions, diagrams, and practical guidance. Read at a brisk pace and refer to the included diagrams for conceptual layouts.

​
Core networking: VPCs and subnets

Core networking refers to Virtual Private Clouds (VPCs) and the components deployed inside them: subnets, gateways, resolvers, route tables, endpoints, and more. The diagram below shows a typical multi‑AZ VPC design with public and private subnets, a load balancer, NAT gateway, VPC endpoints, and connections to external AWS services.
An AWS VPC architecture diagram showing a cloud account and region with two availability zones containing public and private subnets, NACLs, resolvers, NAT gateways, instances, and load balancers. AWS services like Route 53, S3, and VPC endpoints are also illustrated.
Key components to notice:
  • Internet Gateway (IGW): enables public Internet access for public subnets.
  • NAT Gateway(s): placed in public subnets to allow outbound Internet from private subnets.
  • Load Balancers (ALB/NLB): Internet-facing balancers create interfaces in public subnets; internal balancers use private subnets.
  • VPC Endpoints: gateway and interface endpoints allow private access to services like S3 and PrivateLink services.
  • Route Tables & DNS Resolvers: control traffic flows and name resolution at the subnet and VPC/region level.

​
Multi‑VPC connectivity: Transit Gateway vs VPC Peering

When connecting departmental VPCs to shared-services or central networking, choose an approach that balances scalability, isolation, and operational complexity.
An infographic-style question describing an AWS multi‑VPC architecture problem asking how to connect departmental VPCs to a shared service VPC. Four numbered answer options are shown: AWS Transit Gateway, individual VPC peering, Direct Connect per VPC, or VPN per VPC.
Guidance summary:
  • Transit Gateway: scalable hub-and-spoke architecture. Recommended when you have many VPCs and need central routing, segmentation, and simplified management.
  • VPC Peering: simple, low-latency, direct connectivity. Good for a small number of VPCs where transitive routing is not required.
  • Direct Connect / VPN: connect on‑premises to AWS. These do not directly join VPCs unless traffic is routed through on‑premises or a transit hub.
Comparison (quick reference):

​
High availability and fault tolerance in a VPC

Deploy applications across multiple Availability Zones (AZs) inside a region to achieve HA and fault tolerance. Public-facing load balancers typically sit in public subnets while application and database tiers run in private subnets across AZs.
An infographic posing a question about designing an AWS VPC for high availability and fault tolerance, with four numbered answer choices. The options list deploying across multiple Availability Zones, a single-AZ with autoscaling, using AWS Direct Connect to on‑premises, and configuring VPNs to multiple ISPs.
Best practices:
  • Distribute resources across multiple AZs and use separate subnets per AZ and tier to avoid single points of failure.
  • Use load balancers to distribute traffic and support failover between AZs.
  • Replicate control plane and critical services across AZs where supported.

​
Transit VPC (hub model)

A transit or “hub” VPC can act as a central routing layer connecting multiple VPCs via VPNs or other transit technology. It simplifies routing and centralizes shared services (e.g., logging, security appliances).
A network diagram showing four VPCs across the top, each with a VPN gateway icon and arrows pointing inward. Those arrows connect to a central "Transit VPC" box containing router icons.

​
Default VPC vs custom VPC

Default VPCs are convenient for experimentation, but they are not suited as production defaults. Create custom VPCs for production workloads and design addressing and security around organizational needs.
A presentation slide titled "Default VPC" showing a comparison table between Default VPC and Custom/nondefault VPC. The table lists parameters like explanation, created by, IPv4 addressing, internet access/gateway, readiness, and number of VPCs per region.

​
Subnets and AZ distribution

Remember: a single subnet cannot span AZs. Create one subnet per AZ per tier (web, app, db) so workloads can fail over across AZs if an instance or AZ becomes unavailable.

​
Routing and route tables

Segment route tables by tier to control access and minimize blast radius:
  • Assign a route table to each subnet tier (web, app, db).
  • Only the web tier route table should typically reference the IGW; the app tier should not have direct IGW routes.
  • Use this segmentation to tighten security and simplify incident remediation.
A slide showing a scenario about a multinational corporation deploying a multi‑tier web application on AWS and asking how to manage traffic flow between web, application, and database subnets while restricting database internet access. Below the prompt are four numbered multiple‑choice options describing different routing table and subnet routing approaches.

​
Internet Gateways (IGW)

Although diagrams show an IGW as a single device, AWS implements the IGW as a managed, highly available service. Only one IGW is attached to a VPC, but it is not a single physical point of failure. Common design question: grant a developer controlled access to a test app without exposing it broadly. Options include:
  • Use an IGW but restrict ingress with security groups and NACLs (quick but public-facing).
  • Use VPN or Direct Connect for private access (more secure). If an IGW must be used, strictly lock down security groups and NACLs to the developer’s IP addresses.
An infographic showing an AWS/VPC scenario question: a software company wants developer access to a test application over the internet while maintaining reliability, followed by four numbered multiple-choice options describing different approaches (Internet Gateway with security groups/NACLs, route table changes, VPC peering, etc.).

​
NAT gateways and egress-only gateways

NAT gateways provide outbound IPv4 NAT for private subnets and are scoped per AZ. To avoid cross‑AZ data charges and maintain resiliency:
  • Deploy a NAT gateway in each AZ and configure private-subnet route tables to use the NAT gateway that is local to their AZ.
  • For IPv6 outbound-only traffic, use an egress-only internet gateway.
Common exam point: “NAT gateway” refers to the managed AWS NAT service; “NAT instance” is an EC2-based NAT implementation.
A network architecture diagram titled "Egress-Only Gateway" showing an AWS VPC with public, private, and Lambda subnets across two availability zones and IPv6 addressing. It highlights an egress-only internet gateway and a private subnet route table with IPv4/IPv6 routes.
Deploy NAT gateways per AZ and point each private-subnet route table to the NAT gateway in the same AZ to avoid cross‑AZ data charges and improve failover behavior.

​
DNS resolution and Route 53 Resolver

Route 53 Resolver endpoints (inbound and outbound) and the VPC-provided DNS service are managed, redundant services. You cannot “scale up” the AWS resolver — it is already highly available.
A network architecture diagram illustrating DNS resolution between an on-premises data center and an AWS VPC using a customer gateway/virtual private gateway, Route 53 Resolver, and inbound/outbound resolver endpoints. It shows traffic flows to an EC2 instance and a private hosted zone inside the VPC.

​
IP addressing and Elastic IPs

  • Choose a sufficiently large VPC CIDR block to avoid address exhaustion and to allow future growth (allocate subnet sizes by expected load and expansion).
  • Use IP Address Management practices to prevent overlapping addresses when connecting networks.
  • Elastic IPs (EIPs) provide a static public IPv4 address that can be remapped quickly between ENIs for failover scenarios in legacy or single‑point designs.
A simplified AWS architecture diagram showing an EC2 instance inside a VPC/subnet connected via a primary ENI and security group. An Elastic IP is mapped through the Internet Gateway to the instance.

​
Network interface and placement strategies

Options to increase throughput and resilience:
  • ENI (Elastic Network Interface): the standard virtual NIC attached to instances.
  • ENA (Elastic Network Adapter): enhanced networking driver for higher throughput and lower latency.
  • EFA (Elastic Fabric Adapter): OS‑bypass, low‑latency networking for HPC and tightly coupled workloads (supports MPI).
  • Secondary private IPs: useful for IP failover patterns for legacy apps.
  • Placement groups (cluster, partition, spread): control EC2 instance placement for performance or fault isolation.
A quiz slide asking which network interface options best support high-throughput, low-latency EC2 workloads and resilience against interface failures. It lists five choices: Elastic Network Interface (ENI), Elastic Network Adapter (ENA), Elastic Fabric Adapter (EFA), secondary private IP addresses, and placement groups.

​
Quick scenario: real‑time gaming or HPC

For multiplayer game servers or HPC workloads with strict latency:
  • Use ENA for high throughput and low latency.
  • Consider EFA where OS‑bypass and minimal latency between instances are required (e.g., MPI workloads).
An AWS-themed infographic posing a question about ensuring high-performance, low-latency networking for a multiplayer game backend on an EC2 instance. It shows four numbered answer options (e.g., attach an Elastic Network Adapter and configure security groups/NACLs, attach multiple standard interfaces, attach ENA without security, or use the default interface and optimize code).

​
Network ACLs and Security Groups

Network ACLs and security groups are distributed, managed AWS features and are highly available by design. Focus on correct policy design rather than trying to scale these constructs. Use AZ distribution for the resources protected by these controls.
An AWS architecture diagram showing a Virtual Private Cloud (VPC) inside a region with two Availability Zones. It depicts public/private subnets, NACLs, resolvers, NAT gateways, load balancers, VPC endpoints and services like Route 53 and S3.

​
Load balancers (ALB, NLB, Gateway Load Balancer)

Application Load Balancer (ALB) and Network Load Balancer (NLB) are managed services that distribute traffic across AZs and automatically create interfaces in each registered subnet. To maximize availability:
  • Register targets across multiple AZs.
  • Enable cross‑zone load balancing as appropriate (ALB default; NLB configurable).
  • For inter-region failover, use DNS-based failover with Route 53 health checks and routing policies.
Gateway Load Balancer (GWLB) scales third‑party appliances (firewalls, IDS/IPS). Place appliances behind GWLB and use Auto Scaling groups to increase appliance availability.

​
Transit networking: VPN and Direct Connect

Hybrid connections require redundancy:
  • Site-to-site VPN: each AWS VPN connection provides two tunnels for resilience. Increase resiliency by creating multiple VPN connections to different customer gateways or by using Transit Gateway attachments.
  • Direct Connect: a single Direct Connect is a single physical path. Achieve higher availability with multiple Direct Connects in different locations, or combine Direct Connect with a VPN backup.
A network architecture diagram showing AWS Direct Connect linking an AWS VPC (with public/private subnets, EC2, RDS, S3, DynamoDB) to a corporate data center via a virtual private gateway (VGW), Direct Connect location, and customer/gateway routers. It illustrates routing and cross-connect components between the cloud and on‑premises HQ.

​
VPC Peering and Transit Gateway resiliency

AWS implements VPC peering and Transit Gateway on a highly available backbone. Logical diagrams may show a single connection but the infrastructure includes redundant paths. At network edges (VPN/Direct Connect) you need multiple external connections for extra resilience.
A diagram titled "VPC Peering" showing two virtual private clouds (VPC A and VPC B), each containing a subnet and a compute instance, linked by a central VPC peering connection icon. Arrows indicate bidirectional network traffic between the two VPCs.
A network diagram titled "Transit Gateway" showing a corporate data center (clients, servers, and a customer gateway) connecting over the Internet via a site-to-site VPN to an AWS Transit Gateway. The Transit Gateway then links to multiple VPCs labeled Production, Test, Development, and Infrastructure/Shared Services.
VPC endpoints enable private connectivity to AWS services and partner/customer services:
  • Gateway endpoints (S3, DynamoDB) are route-table backed and are highly available without ENIs.
  • Interface endpoints (PrivateLink) create ENIs in subnets to route traffic privately to endpoint services.
An AWS architecture diagram titled "VPC Endpoints and PrivateLink" showing Direct Connect/VPN connectivity to a Transit Gateway and multiple VPCs using gateway/interface endpoints and PrivateLink to access Amazon S3.

​
Edge networking: CloudFront, Functions, and Lambda@Edge

CloudFront is a globally distributed CDN and is highly redundant by design. A single CloudFront distribution provides low-latency, resilient delivery through many edge locations and regional caches.
A quiz-style slide asking how to deliver web content globally with low latency and redundancy. The highlighted answer is "A CloudFront distribution with multiple edge locations."
Edge compute options:
  • CloudFront Functions: lightweight JS functions at edge locations for request/response manipulation.
  • Lambda@Edge: runs functions tied to viewer or origin events; executes at regional edge caches as required.
No user action is required to improve CloudFront redundancy — AWS manages its global deployment.
A multiple-choice slide asking which solution to use for scalable dynamic content optimization of media files delivered through CloudFront. The five options listed are Lambda@Edge, EC2 behind Auto Scaling, AWS WAF header rewrites, S3 event-triggered Lambdas, and Elastic Transcoder.
A diagram of AWS CloudFront showing client requests flowing through CloudFront Edge Caches and CloudFront Regional Edge Caches to an origin server. It marks where CloudFront Functions run at 218+ edge locations and Lambda@Edge runs at 13 regional edge caches, with arrows for viewer/origin requests and responses.

​
Closing notes

  • Many core AWS networking components are managed and highly available by default (IGW, route tables, NACLs, security groups, load balancers, endpoints).
  • Anything that represents a single external physical path (Direct Connect, a single VPN endpoint) needs additional redundant connections to achieve higher availability.
  • Distribute compute and stateful services across multiple AZs and prefer managed services (ALB/NLB, Transit Gateway, CloudFront) to reduce operational overhead and improve reliability.
Design networks for both isolation and redundancy: use per‑tier route tables and per‑AZ resources (NAT gateways, instances, endpoints) to avoid single points of failure while keeping security boundaries clear.
Further reading and references

Watch Video