AWS Networking and Connectivity Selection Playbook (2026)

Scope

This playbook covers AWS networking service decisions that drive application availability, latency, hybrid connectivity, and security boundaries. It maps practical architecture choices for internet ingress, global acceleration, private service exposure, and hybrid network design.

Guidance reflects AWS service positioning and documentation current as of May 18, 2026.

Design principles

1. Separate traffic distribution from network connectivity.
2. Prefer explicit failure domains and failover behavior.
3. Minimize transitive complexity in private connectivity.
4. Keep DNS, routing, and edge caching responsibilities distinct.

1) Application Load Balancer (ALB) and Network Load Balancer (NLB)

Choose ALB when:

• You need L7 HTTP/HTTPS routing logic, path/host rules, and web application behaviors.
• You want request-aware routing controls for modern web/API workloads.

Choose NLB when:

• You need L4 TCP/UDP/TLS traffic handling with very low latency characteristics.
• You require static IP behavior or protocol-level pass-through patterns.

Combined pattern:

• ALB for application-aware web ingress.
• NLB for non-HTTP protocols and specialized transport needs.

CLI checkpoint

aws elbv2 describe-load-balancers
aws elbv2 describe-target-groups

2) ALB and API Gateway

Choose ALB when:

• You primarily need web/container ingress and routing without full API product controls.

Choose API Gateway when:

• You need API lifecycle controls such as auth, throttling, usage plans, and API-stage governance.

Decision guidance:

• ALB is excellent ingress infrastructure.
• API Gateway is an API management platform.

CLI checkpoint

aws elbv2 describe-load-balancers
aws apigatewayv2 get-apis
aws apigatewayv2 get-stages --api-id YOUR_API_ID

3) CloudFront and Global Accelerator

Choose CloudFront when:

• You need CDN and edge caching behavior for content and HTTP delivery optimization.

Choose Global Accelerator when:

• You need global anycast entry points that improve pathing to regional endpoints and increase resilience for non-cache-centric traffic flows.

Complementary use:

• CloudFront for content delivery and edge execution patterns.
• Global Accelerator for resilient global entry to regional applications.

CLI checkpoint

aws cloudfront list-distributions
aws globalaccelerator list-accelerators

4) VPC Peering and Transit Gateway

Choose VPC Peering when:

• Connectivity is limited, direct, and manageable across a small number of VPC relationships.

Choose Transit Gateway when:

• You need scalable hub-and-spoke connectivity across many VPCs and hybrid attachments.
• Centralized routing governance is required.

Architecture warning:

• Mesh peering at scale creates operational complexity and route management risk.
• Transit Gateway usually becomes simpler operationally as environment count grows.

CLI checkpoint

aws ec2 describe-vpc-peering-connections
aws ec2 describe-transit-gateways
aws ec2 describe-transit-gateway-attachments

5) Transit Gateway and AWS PrivateLink

Choose Transit Gateway when:

• You are connecting networks (VPC-to-VPC, VPC-to-on-prem) at routing-fabric level.

Choose PrivateLink when:

• You need private access to specific services without exposing full network transit.
• Service-level private consumption is required across accounts/VPCs.

Pattern:

• Transit Gateway for network connectivity fabric.
• PrivateLink for service endpoint exposure with minimal network blast radius.

CLI checkpoint

aws ec2 describe-transit-gateways
aws ec2 describe-vpc-endpoint-services
aws ec2 describe-vpc-endpoints

6) Direct Connect and Site-to-Site VPN

Choose Direct Connect when:

• Dedicated, consistent private connectivity is required.
• Throughput and latency predictability are strategic.

Choose Site-to-Site VPN when:

• Faster deployment and internet-based encrypted connectivity are acceptable.
• You need rapid hybrid extension with lower setup barrier.

Resilience strategy:

• Many enterprises use both, with VPN as backup path for Direct Connect-linked architectures.

CLI checkpoint

aws directconnect describe-connections
aws ec2 describe-vpn-connections
aws ec2 describe-customer-gateways

7) NAT Gateway and NAT Instance

Choose NAT Gateway when:

• You want managed egress with minimal operational burden and strong scalability behavior.

Choose NAT Instance when:

• You have a narrow, explicit need for custom network appliance behavior and accept operational overhead.

Operational reality in 2026:

• NAT Gateway is the default for most production teams.
• NAT instances are usually exception patterns for specialized needs.

CLI checkpoint

aws ec2 describe-nat-gateways
aws ec2 describe-instances --filters "Name=tag:Role,Values=nat-instance"

8) Security Groups and Network ACLs

Choose Security Groups for:

• Stateful allow rules attached to instances/ENIs.
• Primary workload-level traffic control.

Choose Network ACLs for:

• Stateless subnet-level allow/deny boundaries.
• Additional coarse-grained subnet boundary controls.

Best practice:

• Use security groups as primary application boundary.
• Use NACLs as supplementary network boundary controls where policy requires them.

CLI checkpoint

aws ec2 describe-security-groups
aws ec2 describe-network-acls

9) Route 53 and CloudFront

Choose Route 53 when:

• You need DNS hosting and routing policy control.

Choose CloudFront when:

• You need edge caching and content delivery optimization.

These services are typically complementary, not substitutes.

CLI checkpoint

aws route53 list-hosted-zones
aws cloudfront list-distributions

Tutorial: network baseline inventory

#!/usr/bin/env bash
set -euo pipefail

aws elbv2 describe-load-balancers >/tmp/lb.json
aws cloudfront list-distributions >/tmp/cf.json
aws globalaccelerator list-accelerators >/tmp/ga.json
aws ec2 describe-vpc-peering-connections >/tmp/peering.json
aws ec2 describe-transit-gateways >/tmp/tgw.json
aws ec2 describe-vpc-endpoints >/tmp/vpce.json
aws directconnect describe-connections >/tmp/dx.json
aws ec2 describe-vpn-connections >/tmp/vpn.json
aws ec2 describe-nat-gateways >/tmp/natgw.json
aws route53 list-hosted-zones >/tmp/r53.json

echo "Network inventory snapshots written to /tmp"

Deep-dive scenario A: multi-region web platform

A global web platform needs edge delivery, low latency, and regional failover.

Typical design:

• CloudFront for content and edge optimization.
• Route 53 for DNS steering policies.
• ALB per region for HTTP traffic distribution.
• Optional Global Accelerator for resilient anycast entry when required.

Deep-dive scenario B: enterprise multi-account network hub

An enterprise with many AWS accounts and hybrid links often outgrows peering meshes quickly.

Pattern:

• Transit Gateway as central routing fabric.
• PrivateLink for private service exposure across account boundaries.
• Direct Connect primary + VPN backup for hybrid resilience.

This model usually improves governance and reduces routing complexity.

Deep-dive scenario C: private service publishing

A platform team wants to expose internal services to many consuming VPCs without opening broad network transit.

Pattern:

• Publish services via PrivateLink endpoint services.
• Keep broad connectivity decisions separate (Transit Gateway only where required).

Benefit:

• Smaller blast radius and clearer service-level access boundaries.

Security and governance controls

• Define clear ownership for DNS, load balancing, and route domains.
• Enforce least-privilege IAM for network changes.
• Use config and audit monitoring for route and policy drift.
• Document failover paths and drill them regularly.

Cost and performance controls

1. Track egress and data-processing costs by traffic domain.
2. Review idle and duplicate network constructs quarterly.
3. Keep edge caching policies aligned to actual content behavior.
4. Validate NAT and interconnect architecture against real throughput and availability needs.

Anti-patterns to avoid

• Using VPC peering meshes at large scale instead of hub models.
• Treating CloudFront as DNS replacement.
• Using only VPN for critical hybrid workloads without resilience planning.
• Choosing NAT instances by habit rather than explicit requirement.
• Mixing service publishing and network transit boundaries without governance.

Final recommendations

For many organizations in 2026:

• ALB for HTTP ingress, NLB for protocol-focused L4 use cases.
• API Gateway for governed API products.
• CloudFront for edge caching and content delivery.
• Transit Gateway for scalable network fabrics; PrivateLink for private service exposure.
• Direct Connect + VPN for resilient hybrid design.
• Route 53 for DNS/routing policy and CloudFront as complementary edge delivery layer.

References

• https://docs.aws.amazon.com/decision-guides/latest/networking-on-aws-how-to-choose/choosing-networking-and-content-delivery-service.html
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
• https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html
• https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html
• https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html
• https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
• https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
• https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat.html
• https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html

Extended operations guide

Network change management discipline

Networking changes can cause broad blast radius quickly. Adopt a strict but lightweight process:

• design review with explicit rollback path
• staged rollout by environment/account
• maintenance window for high-impact route or ingress changes
• post-change verification checklist

Track who owns each control plane:

• DNS policy owner
• load balancer owner
• transit routing owner
• hybrid link owner

Ownership clarity dramatically reduces outage duration.

Route hygiene and drift prevention

Route drift is a common source of intermittent failures. Add controls:

• periodic route-table diff reviews
• centralized route documentation per domain
• policy checks for forbidden transitive paths
• alarms for unexpected route changes

For Transit Gateway environments, review attachments and route propagation rules routinely.

Edge and ingress observability baseline

For ALB/NLB/API Gateway/CloudFront paths, monitor:

• request rate and error classes
• latency by percentile
• backend target health
• TLS errors and certificate status
• regional traffic distribution

Define SLOs per ingress path so incident response has clear thresholds.

Advanced CLI lab: path-by-path verification

#!/usr/bin/env bash
set -euo pipefail

# Ingress and edge
aws elbv2 describe-load-balancers
aws elbv2 describe-target-health --target-group-arn YOUR_TARGET_GROUP_ARN
aws apigatewayv2 get-apis
aws cloudfront list-distributions
aws globalaccelerator list-accelerators

# Private connectivity fabric
aws ec2 describe-transit-gateways
aws ec2 describe-transit-gateway-route-tables
aws ec2 describe-vpc-endpoints
aws ec2 describe-vpc-peering-connections

# Hybrid links
aws directconnect describe-connections
aws ec2 describe-vpn-connections

# Egress controls
aws ec2 describe-nat-gateways

Hybrid resilience strategy

For business-critical hybrid connectivity, use layered resilience:

• primary deterministic path via Direct Connect
• backup encrypted path via Site-to-Site VPN
• clear failover triggers and recovery runbook
• periodic failover drills and latency validation

Without rehearsed failover, backup links become theoretical rather than operational.

Security boundary patterns

Pattern A: public ingress + private application tiers

• Public entry through ALB/API Gateway.
• Private application services in restricted subnets.
• Security groups as workload perimeter.
• NACLs as additional subnet boundary controls where needed.

Pattern B: private service exposure across accounts

• Use PrivateLink for targeted private service access.
• Avoid exposing broad VPC-level transit unless business requirements demand it.

Pattern C: segmented network domains with centralized transit

• Transit Gateway hub for controlled connectivity.
• Route domains segmented by environment and sensitivity.
• Explicit policy checks for east-west communication.

Cost and architecture trade-off guidance

Network cost optimization should consider:

• data transfer paths
• edge cache hit ratio
• inter-AZ/inter-region traffic patterns
• NAT and egress architecture behavior
• duplicate ingress constructs

Avoid local optimization that increases incident risk.

Examples:

• Reducing edge caching too aggressively can increase origin cost and latency.
• Over-consolidating load balancers may save small cost but increase blast radius.

Scenario walkthrough D: SaaS control plane and data plane split

A SaaS platform has control-plane APIs and data-plane traffic with different risk profiles.

Suggested network pattern:

• API Gateway or ALB for control-plane ingress depending on API governance needs.
• NLB or ALB for data-plane services based on protocol and routing needs.
• Route 53 policy for controlled regional routing.
• CloudFront where edge delivery benefits user experience.

Benefits:

• isolation between control and data traffic
• clearer security controls
• targeted scaling and incident handling

Scenario walkthrough E: enterprise merger integration

During mergers, teams often need temporary connectivity among multiple AWS estates and on-prem networks.

Practical path:

• establish central Transit Gateway model
• use selective peering only for transitional dependencies
• publish shared internal services with PrivateLink
• map migration timeline to decommission temporary routes safely

This avoids long-term accumulation of fragile transitional networking.

Scenario walkthrough F: latency-sensitive global API

A globally distributed API requires stable entry and regional failover behavior.

Pattern:

• evaluate Global Accelerator for stable anycast entry and improved pathing.
• combine with regional load balancers and health-checked endpoints.
• keep DNS strategy explicit for fallback and operational control.

Measure before and after latency/availability results to validate value.

Network policy review checklist

1. Are route ownership and approval boundaries documented?
2. Are ingress services mapped to workload types intentionally?
3. Are hybrid fallback paths tested and timed?
4. Is private service exposure using least-privilege patterns?
5. Are DNS and edge caching policies aligned with traffic behavior?
6. Are logging and audit controls enabled for network changes?

Anti-fragility practices

• Run failure injection drills for ingress and hybrid links.
• Keep automated validation tests for route, endpoint, and security policy assumptions.
• Build dashboards that map user-facing symptoms to networking components quickly.
• Maintain high-signal runbooks with escalation contacts and rollback commands.

These practices turn networking from a hidden risk area into a predictable platform capability.

Organizational operating model

High-performing network platforms usually have:

• central standards with domain autonomy
• clear interface contracts between platform and product teams
• monthly architecture review for risk and cost hotspots
• incident postmortems that produce concrete network policy improvements

This operating model scales better than ad hoc ticket-driven network evolution.

Final readiness gate

Before launching major networking changes:

• path simulation and validation complete
• fallback and rollback tested
• observability dashboards active
• ownership and on-call escalation documented
• security review completed

If any item is missing, postpone release.

Decision workbook for architecture boards

Use this structured workbook to make networking decisions explicit.

Section A: traffic shape

• Peak requests per second by region.
• Protocol mix (HTTP, gRPC, TCP, UDP).
• Latency sensitivity by user journey.
• Tolerance for brief rerouting during failover.

Section B: connectivity scope

• Number of VPCs/accounts needing connectivity.
• On-prem dependency and expected throughput.
• Service-level private exposure requirements.
• Compliance boundaries requiring segmentation.

Section C: resiliency and recovery

• Maximum tolerable outage per path.
• Recovery runbook ownership.
• Failover automation versus manual decision points.
• Drill cadence and evidence retention.

Section D: governance and security

• Change approval paths.
• IAM boundary design for network updates.
• Logging/audit requirements.
• Incident escalation model.

Complete this workbook before final service selection. It reveals hidden assumptions early.

Quick validation commands for change windows

# Validate hosted zones and key records
aws route53 list-hosted-zones
aws route53 list-resource-record-sets --hosted-zone-id YOUR_ZONE_ID --max-items 20

# Validate ALB/NLB health quickly
aws elbv2 describe-target-health --target-group-arn YOUR_TARGET_GROUP_ARN

# Validate Transit Gateway routes
aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id YOUR_TGW_RT --filters Name=state,Values=active

# Validate VPN tunnel status
aws ec2 describe-vpn-connections --query "VpnConnections[*].[VpnConnectionId,State,VgwTelemetry]"

Final executive summary

• Use ALB for HTTP-aware routing and application ingress.
• Use NLB for protocol-focused L4 traffic and static-IP-oriented patterns.
• Use API Gateway when API governance controls are required.
• Use CloudFront for edge delivery and content acceleration.
• Use Global Accelerator for resilient global entry where anycast path benefits are needed.
• Use Transit Gateway for scalable connectivity fabrics.
• Use PrivateLink for private service exposure with minimal network blast radius.
• Use Direct Connect with VPN backup for resilient hybrid design.
• Use NAT Gateway as default managed egress model.
• Use security groups as primary workload boundary and NACLs as supplementary subnet controls.
• Use Route 53 as DNS/routing policy control, usually alongside CloudFront.

Closing note

Networking architecture succeeds when responsibilities are explicit, failover is rehearsed, and service boundaries are intentionally chosen. Keep decisions measurable, testable, and periodically reviewed against real production behavior.

Post-implementation review prompts

After deployment, ask:

• Did latency improve in the user journeys we targeted?
• Did operational complexity increase or decrease?
• Are failover events behaving as expected in drills?
• Are network costs aligned with forecast?
• Did any unplanned trust boundaries appear?

Use findings to refine route policy, ingress segmentation, and observability coverage. Continuous review is essential because traffic patterns and dependency maps evolve quickly in growing platforms. Document DNS, ingress, and private connectivity as separate architecture layers in diagrams and runbooks. Teams that collapse these layers into one mental model struggle during incidents because symptoms and ownership become unclear. Layered documentation shortens triage and reduces handoff errors. Keep architecture diagrams versioned with the same rigor as code. Outdated network diagrams are a major source of troubleshooting delay in distributed systems. Review inter-region and inter-AZ traffic patterns monthly; silent growth here can erode both latency objectives and budget targets. Small routing errors can create large outages, so automate verification after every network policy change. Practice failover regularly.