Networking is arguably the most technically demanding topic on the AWS Certified Solutions Architect Professional (SAP-C02) exam. You will encounter questions on advanced VPC design, Transit Gateway architectures, hybrid connectivity with Direct Connect and VPN, PrivateLink, VPC endpoints, Route 53 routing policies, CloudFront, and Global Accelerator — often combined in complex multi-account, multi-region scenarios.
This guide covers each networking topic at the depth required for SAP-C02 success. If you are looking for a broader exam overview, start with our SAP-C02 exam guide.
Advanced VPC Design
VPC Fundamentals for SAP-C02
The exam assumes you know VPC basics. What it tests is your ability to design VPCs for enterprise scenarios:
- CIDR planning: Choosing CIDR blocks that do not overlap across multiple VPCs, on-premises networks, and partner networks. You can associate up to 5 CIDR blocks with a VPC (including the primary). IPv6 CIDR blocks can be added alongside IPv4.
- Subnet strategy: Deciding between public, private, and isolated subnets. Using separate subnets for different tiers (web, application, database). Reserving CIDR space for future growth.
- Route table design: Custom route tables for each subnet tier. Understanding the order of route evaluation (most specific route wins).
Multi-VPC Architectures
Enterprise environments typically use multiple VPCs. The SAP-C02 tests your ability to choose the right connectivity model:
| Connectivity Model | Max Connections | Transitive Routing | Bandwidth | Cost | Use Case |
|---|---|---|---|---|---|
| VPC Peering | 125 per VPC | No | No bottleneck (AWS backbone) | Low (data transfer only) | Point-to-point between 2-3 VPCs |
| Transit Gateway | 5,000 attachments | Yes | Up to 50 Gbps per attachment | Moderate (hourly + data) | Hub-and-spoke for many VPCs |
| PrivateLink | N/A | No | Scales with endpoints | Per endpoint + data | Service-to-service connectivity |
| Shared VPC (RAM) | N/A | N/A | N/A | No additional cost | Shared networking within Organization |
VPC Peering
VPC Peering creates a direct network connection between two VPCs using AWS private infrastructure. Key characteristics:
- Non-transitive: If VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot reach VPC C through VPC B
- Cross-region support: Peering works across regions (inter-region peering) with encryption in transit
- No single point of failure or bandwidth bottleneck
- CIDR blocks must not overlap
- Security groups can reference peered VPC security groups (same region only)
When to use: Small number of VPCs (2-5) that need full network connectivity. Once you exceed a handful of VPCs, the number of peering connections becomes unmanageable (N * (N-1) / 2 connections for full mesh).
When NOT to use: When you need transitive routing, centralized egress, or are connecting more than a few VPCs.
Transit Gateway
Transit Gateway is the most heavily tested networking service on the SAP-C02. It acts as a regional network hub that connects VPCs, VPN connections, Direct Connect gateways, and other Transit Gateways.
Transit Gateway Architecture
A Transit Gateway supports up to 5,000 attachments and routes traffic between them. Attachment types include:
- VPC attachments — Connect a VPC to the Transit Gateway (one subnet per AZ)
- VPN attachments — Site-to-Site VPN connections
- Direct Connect Gateway attachments — Connect to on-premises via Direct Connect
- Peering attachments — Connect Transit Gateways across regions (inter-region peering)
Route Tables and Segmentation
Transit Gateway uses route tables to control traffic flow. Each attachment is associated with one route table, but a route table can have many attachments. This enables network segmentation:
Shared Services Pattern:
- All VPCs can reach the shared services VPC (DNS, Active Directory, CI/CD)
- Production VPCs cannot reach development VPCs
- Implemented using separate route tables with selective route propagation
Inspection Pattern:
- All traffic between VPCs routes through a centralized inspection VPC (running AWS Network Firewall or third-party appliances)
- Implemented using Transit Gateway route tables that direct all traffic to the inspection VPC attachment
- The inspection VPC routes clean traffic to the correct destination
Transit Gateway and Multi-Account
Transit Gateway can be shared across accounts using AWS Resource Access Manager (RAM). The typical pattern:
- Networking account owns the Transit Gateway
- Transit Gateway is shared via RAM to the Organization or specific OUs
- Workload accounts create VPC attachments to the shared Transit Gateway
- The networking account manages route tables and segmentation
This pattern is central to the multi-account landing zone architecture tested on SAP-C02.
Transit Gateway Inter-Region Peering
For multi-region architectures, Transit Gateways in different regions can be peered:
- Traffic between peered Transit Gateways is encrypted and traverses the AWS global backbone
- Peering is non-transitive between Transit Gateways (TGW A <-> TGW B and TGW B <-> TGW C does not mean TGW A can reach TGW C through TGW B)
- Each Transit Gateway maintains its own route table for peering attachments
- Bandwidth is limited by the inter-region peering connection (not published, but tested for awareness)
Hybrid Connectivity
AWS Direct Connect
Direct Connect provides a dedicated private network connection between your on-premises data center and AWS. It is the preferred option for production hybrid connectivity.
Connection Types:
| Type | Bandwidth | Lead Time | Use Case |
|---|---|---|---|
| Dedicated Connection | 1 Gbps, 10 Gbps, 100 Gbps | Weeks to months | High-throughput, consistent performance |
| Hosted Connection | 50 Mbps to 10 Gbps | Days to weeks (via partner) | Flexible bandwidth, faster provisioning |
Virtual Interfaces (VIFs):
| VIF Type | Purpose | Routing |
|---|---|---|
| Private VIF | Access VPCs via private IP | BGP to VGW or Direct Connect Gateway |
| Public VIF | Access AWS public services (S3, DynamoDB) via public IP | BGP with AWS public prefixes |
| Transit VIF | Access VPCs via Transit Gateway | BGP to Direct Connect Gateway to Transit Gateway |
Key architectural concepts:
- Direct Connect Gateway: A globally available resource that enables a single Direct Connect connection to access VPCs in multiple regions. Does not enable VPC-to-VPC routing (only on-premises to VPC).
- LAG (Link Aggregation Group): Combines multiple Direct Connect connections into a single logical connection for increased bandwidth and redundancy.
Direct Connect Resiliency
AWS recommends different resiliency levels based on requirements:
Maximum resiliency (critical workloads):
- Separate connections at separate Direct Connect locations
- Each connection terminates on separate devices at separate locations
High resiliency:
- Minimum two connections at the same Direct Connect location, terminating on separate devices
Development/test:
- Single connection (no redundancy)
Exam tip: When the question specifies “highly available” or “resilient” Direct Connect, the answer requires at least two connections. For maximum resiliency, the connections must be at different Direct Connect locations.
Direct Connect + VPN Backup
A common architecture pattern for the SAP-C02:
- Primary path: Direct Connect for consistent, low-latency connectivity
- Backup path: Site-to-Site VPN over the internet as a failover
- Both terminate on the same Transit Gateway (or Virtual Private Gateway)
- BGP routing priorities determine which path is active (Direct Connect preferred via shorter AS path or higher local preference)
- Failover is automatic when Direct Connect health checks fail
Site-to-Site VPN
Site-to-Site VPN creates an encrypted tunnel over the public internet between your on-premises network and AWS.
Key characteristics:
- Two tunnels per VPN connection for redundancy (each to a different AZ endpoint)
- IPsec encryption with IKEv2 support
- Up to 1.25 Gbps per tunnel (use ECMP with Transit Gateway for higher aggregate throughput)
- Accelerated VPN: Routes VPN traffic over the AWS global backbone using Global Accelerator endpoints — reduces jitter and improves performance for geographically distant connections
ECMP (Equal-Cost Multi-Path) with Transit Gateway:
- Attach multiple VPN connections to Transit Gateway
- Enable ECMP to distribute traffic across all tunnels
- Each VPN has 2 tunnels at 1.25 Gbps = 2.5 Gbps per VPN
- 4 VPN connections with ECMP = up to 10 Gbps aggregate
Exam tip: ECMP is only supported with Transit Gateway, not with Virtual Private Gateway. If the question asks for high-throughput VPN, Transit Gateway + ECMP is the answer.
VPC Endpoints and PrivateLink
Gateway Endpoints
Gateway endpoints are free and provide private access to S3 and DynamoDB from within a VPC. They are implemented as route table entries.
- No charge for the endpoint itself
- Traffic does not traverse the internet or NAT Gateway
- Controlled via endpoint policies (JSON policy documents)
- Only accessible within the VPC (not across peering or VPN)
Exam tip: When the question asks about reducing NAT Gateway costs for S3 or DynamoDB traffic, Gateway endpoints are the answer.
Interface Endpoints (PrivateLink)
Interface endpoints create elastic network interfaces (ENIs) in your subnets, providing private connectivity to AWS services and custom services.
- Powered by AWS PrivateLink
- Supports most AWS services (CloudWatch, KMS, STS, SSM, ECR, etc.)
- Creates ENIs in specified subnets with private IP addresses
- Accessible across VPC peering, Transit Gateway, VPN, and Direct Connect
- DNS resolution via private hosted zones (optional)
- Per-AZ hourly charge + data processing charge
PrivateLink for Custom Services
PrivateLink enables you to expose your services to other VPCs and accounts without using public IPs, VPC peering, or Transit Gateway:
Service provider side:
- Deploy service behind a Network Load Balancer (NLB) or Gateway Load Balancer (GWLB)
- Create a VPC Endpoint Service pointing to the NLB/GWLB
- Optionally require acceptance of connection requests
Consumer side:
- Create an Interface Endpoint targeting the endpoint service
- Access the service via the endpoint’s private DNS name
When to use: SaaS providers offering services to customers, shared service architectures within an Organization, connecting services without exposing network topology.
Exam tip: PrivateLink is the answer when the question describes unidirectional service access (consumer to provider) that should not expose the provider’s VPC network. It is not for general network connectivity — that is Transit Gateway or VPC Peering.
Route 53 Routing Policies
Route 53 is central to traffic management and disaster recovery architectures on the SAP-C02.
Routing Policy Comparison
| Policy | Description | Health Check Integration | Use Case |
|---|---|---|---|
| Simple | Single resource, no health checks | No (but alias can use Evaluate Target Health) | Single endpoint |
| Weighted | Distribute traffic by weight percentage | Yes | Canary deployments, gradual migration |
| Latency-based | Route to lowest-latency region | Yes | Multi-region active-active |
| Failover | Primary/secondary with automatic failover | Yes (required for primary) | Active-passive DR |
| Geolocation | Route based on user’s geographic location | Yes | Compliance, localized content |
| Geoproximity | Route based on geographic distance with bias | Yes | Traffic shifting between regions |
| Multivalue Answer | Return multiple healthy records (up to 8) | Yes | Simple load distribution |
| IP-based | Route based on client IP CIDR | Yes | ISP or enterprise-specific routing |
Complex Routing with Alias Records
Alias records can chain routing policies. For example:
- Geolocation record (top level) routes European users to eu-west-1 and US users to us-east-1
- Each geolocation record points to a weighted alias that distributes traffic between blue/green deployments
- Each weighted record points to an ALB with health checks
This chained routing is a common exam pattern.
CloudFront and Global Accelerator
Amazon CloudFront
CloudFront is the global CDN that caches content at edge locations worldwide. SAP-C02 tests advanced CloudFront topics:
Origin types: S3 buckets, ALB, EC2, custom HTTP origins, MediaStore, Lambda function URLs
Key features for the exam:
- Origin Access Control (OAC): Restricts S3 bucket access to CloudFront only (replaces the older Origin Access Identity)
- Lambda@Edge and CloudFront Functions: Run code at edge locations for request/response manipulation, A/B testing, URL rewriting, and authentication
- Field-level encryption: Encrypt specific POST fields at the edge, only decryptable by the application
- Geographic restrictions: Block or allow requests from specific countries
- Cache behaviors: Different caching rules based on URL path patterns
AWS Global Accelerator
Global Accelerator provides static anycast IP addresses that route traffic over the AWS global backbone to the optimal regional endpoint.
Key differences from CloudFront:
| Feature | CloudFront | Global Accelerator |
|---|---|---|
| Protocol | HTTP/HTTPS (and WebSocket) | TCP, UDP |
| Caching | Yes | No |
| IP addresses | Dynamic (edge locations) | Static anycast IPs |
| Best for | Cacheable content, API acceleration | Non-HTTP protocols, TCP-based apps, gaming, IoT |
| Health checks | Origin health checks | Endpoint health checks with instant failover |
Exam tip: If the question involves non-HTTP traffic (TCP, UDP), or requires static IP addresses for whitelisting, Global Accelerator is the answer. If it involves cacheable web content, CloudFront is the answer.
Network Security
AWS Network Firewall
A managed network firewall service for VPC-level traffic filtering:
- Stateful and stateless rule groups
- Deep packet inspection
- Intrusion detection and prevention (IDS/IPS)
- Deployed in a dedicated firewall subnet
- Integrates with Transit Gateway for centralized inspection
Architecture pattern: Centralized inspection VPC connected to Transit Gateway. All inter-VPC and egress traffic routes through the inspection VPC where Network Firewall evaluates traffic.
Security Groups vs. NACLs
| Feature | Security Group | Network ACL |
|---|---|---|
| Level | Instance (ENI) level | Subnet level |
| State | Stateful (return traffic automatic) | Stateless (must allow return traffic explicitly) |
| Rules | Allow only | Allow and Deny |
| Evaluation | All rules evaluated | Rules evaluated in order (lowest number first) |
| Default | Deny all inbound, allow all outbound | Allow all inbound and outbound |
DNS Firewall
Route 53 Resolver DNS Firewall allows you to filter DNS queries made from your VPCs:
- Block queries to known malicious domains
- Allow only approved domains (allowlist mode)
- Associate firewall rule groups with VPCs across accounts via RAM
Real-World Exam Scenarios
Scenario 1: Hub-and-Spoke with Centralized Egress
Requirements: 50 VPCs across 10 accounts need internet access through a centralized inspection point. All outbound traffic must be logged and filtered.
Architecture:
- Transit Gateway in the networking account, shared via RAM
- All VPC route tables send 0.0.0.0/0 to Transit Gateway
- Transit Gateway routes 0.0.0.0/0 to a centralized egress VPC
- Egress VPC contains Network Firewall for inspection and NAT Gateways for internet access
- Network Firewall logs to S3 and CloudWatch
Scenario 2: Multi-Region Active-Active with Hybrid Connectivity
Requirements: Application must be active in us-east-1 and eu-west-1. On-premises data center needs connectivity to both regions. Latency-sensitive traffic.
Architecture:
- Transit Gateway in each region with inter-region peering
- Direct Connect with Transit VIF in the primary region
- Direct Connect Gateway for multi-region on-premises connectivity
- Route 53 latency-based routing for application traffic
- Aurora Global Database for cross-region data replication
Frequently Asked Questions
When should I use VPC Peering vs. Transit Gateway?
Use VPC Peering for a small number of VPCs (2-5) that need direct, high-bandwidth connectivity without transitive routing. Use Transit Gateway when you have many VPCs, need transitive routing, centralized egress, or integration with VPN and Direct Connect.
What is the maximum bandwidth of a Transit Gateway attachment?
Each VPC attachment to Transit Gateway supports up to 50 Gbps of aggregate bandwidth across all Availability Zones. VPN attachments support up to 1.25 Gbps per tunnel (2.5 Gbps per VPN connection, scalable with ECMP).
Can Direct Connect Gateway provide VPC-to-VPC connectivity?
No. Direct Connect Gateway only provides on-premises to VPC connectivity. It does not enable routing between VPCs attached to the same Direct Connect Gateway. For VPC-to-VPC routing, use Transit Gateway.
What is the difference between Gateway Endpoints and Interface Endpoints?
Gateway Endpoints are free, work only for S3 and DynamoDB, are implemented as route table entries, and are only accessible within the VPC. Interface Endpoints cost money (hourly + data), work with most AWS services, create ENIs with private IPs, and are accessible across peering, VPN, and Direct Connect.
How does PrivateLink differ from VPC Peering?
PrivateLink provides unidirectional access from a consumer to a specific service, without exposing the entire VPC network. VPC Peering creates bidirectional full network connectivity between two VPCs. PrivateLink is for service access; VPC Peering is for network connectivity.
Can I use ECMP with Site-to-Site VPN on a Virtual Private Gateway?
No. ECMP for VPN connections is only supported with Transit Gateway. A Virtual Private Gateway supports only one active tunnel per VPN connection and does not aggregate bandwidth across multiple VPN connections.
How does Route 53 geoproximity routing differ from geolocation routing?
Geolocation routes based on the user’s country, continent, or state — it is a fixed geographic mapping. Geoproximity routes based on the physical distance between the user and the resource, and you can apply a bias to shift traffic toward or away from a resource. Geoproximity is more flexible for gradual traffic shifting.
What is the failover time for Direct Connect?
Direct Connect failover time depends on your architecture. If you use BGP with a VPN backup, failover typically takes 1-3 minutes for BGP to converge. Using BFD (Bidirectional Forwarding Detection) can reduce failover detection to sub-second. The exam expects you to know that Direct Connect alone has no built-in redundancy — you must design for it.
Conclusion
Networking is the connective tissue of every SAP-C02 exam question. Whether the scenario involves multi-account architecture, disaster recovery, or migration, networking design is always part of the answer. Mastering Transit Gateway, Direct Connect, PrivateLink, and Route 53 routing policies gives you a strong foundation for the majority of exam questions.
Put your networking knowledge to the test with Sailor.sh’s SAP-C02 mock exams. The exam presents complex multi-service networking scenarios that require you to evaluate trade-offs between performance, cost, security, and operational complexity — and realistic practice is the best way to prepare.