Amazon SAP-C02: Networking & Hybrid Connectivity — Study Guide
Part of the AWS Solutions Architect Professional SAP-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
VPC architecture and segmentation patterns
Designing VPC topology begins with blast-radius management and predictable routing. For small deployments a single VPC with multiple subnets and strict security groups can be efficient, but as teams and applications grow the single-VPC pattern becomes brittle: resource quotas, inter-team governance, and noisy neighbors increase operational risk. The multi-VPC-per-team or account-per-team model improves isolation and IAM boundaries; use AWS Organizations with separate accounts for teams and a shared-services account for DNS, logging, and identity. For inter-VPC connectivity, VPC peering is simple and low-latency but non-transitive and operationally heavy at scale. Transit Gateway (TGW) replaces the “transit VPC” pattern: it supports thousands of attachments, centralizes route tables, and simplifies multicast or hub-and-spoke patterns. PrivateLink (Interface VPC Endpoints) enables service-level isolation without exposing services to the internet, critical for cross-account microservices. Common traps include relying solely on security groups for segmentation (they are stateful and coarse for east-west filtering), forgetting NACL stateless behavior, and not planning CIDR allocation (overlaps hobble peering and DX). Decisions hinge on cost versus manageability: TGW has attachment costs but reduces per-peering complexity; multi-account isolation increases landing zone overhead but lowers blast radius. Always document CIDR plan, route propagation rules, and ownership of shared services to avoid drift.
Hybrid connectivity, routing, and resilience
Hybrid connectivity choices hinge on throughput, jitter, latency and consistent public egress addressing. AWS Direct Connect (DX) private VIFs provide deterministic bandwidth and lower egress costs compared to Internet VPN for large steady flows; use a Direct Connect Gateway to span multiple Regions or attach to a Transit Gateway for centralized routing. Site-to-Site VPN (managed IPsec with BGP) is used for quick setup or as a resilient backup to DX; configure BGP with appropriate ASNs and route priorities to avoid asymmetric routing. Key routing traps are overlapping on-prem and cloud CIDRs, improper route propagation in TGW, and assuming transitive routing across peered VPCs. MTU and fragmentation can break VPN traffic—test path MTU and tune MSS on devices. For multi-region, consider active/active DX at multiple locations or DX combined with VPN failover. Trade-offs: dedicated DX links cost more but reduce jitter and egress charges; VPN is cheaper and simpler but less stable at high throughput. Architect for predictable failover with two independent tunnels, redundant DX connections in separate locations, and explicit TGW route tables to control path selection and limits.
DNS, PrivateLink, and service connectivity patterns
DNS is central to hybrid and multi-account networking. Use Route 53 Private Hosted Zones for VPC-scoped resolution and Route 53 Resolver inbound/outbound endpoints to enable conditional forwarding between on-prem and AWS DNS. This supports split-horizon DNS where internal names resolve to private IPs while public records remain global. PrivateLink (interface endpoints) provides private, ENI-backed connectivity to AWS services or SaaS partners without routing traffic over the public internet; contrast this with Gateway Endpoints for S3 and DynamoDB which are cheaper and use route tables rather than ENIs. PrivateLink avoids exposing services to VPC CIDR conflicts and supports cross-account consumers with service acceptance policies. Common pitfalls include forgetting to associate private hosted zones to all consumer VPCs, not creating Route 53 Resolver rules for on-prem domains, and underestimating per-endpoint ENI IP consumption. Decision criteria: prefer Gateway endpoints for high-throughput S3/DynamoDB access to avoid NAT costs; use Interface endpoints when you need private access to API endpoints or third-party services with stricter security. Monitor DNS latency and set TTLs with change control to manage failover behavior.
Egress, NAT design, security controls and operational practices
Egress architecture affects cost, auditability, and third-party integrations. NAT Gateway provides managed, highly available IPv4 egress for private subnets with automatic scaling per AZ; NAT Instances are cheaper for low-throughput use but demand operational maintenance and failover scripting. Centralizing egress via a dedicated egress VPC attached to a Transit Gateway enforces consistent outbound IPs, inspection points, and simplified policies, but introduces hairpin routing and potential bandwidth bottlenecks. For IPv6, use Egress-Only Internet Gateway. Replace SSH bastions with AWS Systems Manager Session Manager for auditing and to eliminate public inbound credentials; Session Manager works over the SSM agent without opening SSH ports. For advanced filtering and DPI, deploy AWS Network Firewall or third-party appliances behind TGW. Cost vs. performance trade-offs: NAT Gateways are easy but add per-GB charges—use VPC endpoints to reduce S3 egress and NAT costs. Operational traps include not enabling VPC Flow Logs for traffic troubleshooting, leaving broad egress rules that enable data exfil, and using SCPs or IAM policies that unintentionally block lifecycle operations; enforce least privilege and log everything to a central account for analysis.
Practical Problem: Acme Financial Services — Centralized Predictable Egress for Third-Party Whitelisting
Scenario: Acme Financial Services runs multiple application VPCs across two AWS Regions, connected with a Transit Gateway and with on-premises data centers via Direct Connect and VPN. Several applications in separate accounts must call a partner API that accepts requests only from a single public CIDR block.
Challenge: Provide a highly available, auditable egress path with a predictable single public CIDR block for all application VPCs across Regions, while minimizing latency and operational overhead.
Recommended Approach:
- Bring a public IPv4 CIDR to AWS using BYOIP (Bring Your Own IP) and allocate Elastic IPs from that CIDR for use as the egress addresses.
- Build a centralized egress VPC in each Region with NAT Gateways in multiple AZs; associate the BYOIP Elastic IPs with those NAT Gateways and attach the egress VPCs to the Transit Gateway.
- Update TGW route tables so all application VPCs route 0.0.0.0/0 to the egress VPC attachment, enable route propagation and health-checked failover across AZs; configure on-prem routing to prefer local egress where required.
- Deploy Network Firewall or managed IDS in the egress VPC for outbound filtering, enable VPC Flow Logs and CloudWatch alarms, and use Route 53 Resolver for any DNS forwarding needs.
Rationale: Centralizing egress via TGW and NAT Gateways with BYOIP-provided IP space gives a predictable CIDR for whitelisting while preserving high availability and centralized monitoring. This balances operational simplicity, security controls, and the partner requirement for a single public CIDR.
← Organizational Complexity · All domains · Security →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →