Hybrid Network Design for Amazon AWS SAP-C02

Hybrid networking is one of the most durable SAP-C02 skills. The official guide’s organizational-complexity domain includes connectivity among VPCs, on-premises sites, co-location facilities, Regions, service endpoints, hybrid DNS, segmentation, routing, and traffic monitoring. The architect is expected to select and troubleshoot a complete path, not merely recognize AWS Direct Connect or VPN by name.

Candidates should also keep the exam transition in view. SAP-C02 can be taken through November 16, 2026, and SAP-C03 begins November 17. The current AWS architecture certifications show the transition timeline; the networking principles remain useful beyond the code change.

Cloud networking fundamentals and AWS VPC design establish the baseline routing, subnet, gateway, and VPC relationships. At the professional level, the hard questions are about scale, transitivity, BGP behavior, DNS, inspection, redundancy, and how a hybrid design recovers when a link, route, resolver, or policy fails.

Start with traffic domains and failure requirements

Which networks must communicate, which must remain isolated, what latency/bandwidth they need, and how long connectivity can be degraded. Service choice is downstream of the traffic and resilience requirement. The implementation should draw source, destination, trust boundary, required ports/protocols, expected route, DNS dependency, and backup path before choosing connectivity services. This keeps the system aligned with intentional connectivity with explicit isolation without adding hidden operational debt.

Adding connectivity iteratively until the route table and trust model are no longer understandable. The evidence that matters most is an end-to-end path map, ownership of every hop, route domains, security controls, and the documented failure path. Use it to distinguish configuration, dependency, and runtime faults, then confirm the chosen fix protects intentional connectivity with explicit isolation.

Direct Connect and VPN solve different parts of the hybrid problem

Dedicated private connectivity, internet-based encrypted tunnels, bandwidth consistency, provisioning lead time, and resilient path strategies. Rather than layering controls blindly, choose primary and backup mechanisms from availability, throughput, encryption, cost, and time-to-deploy requirements. The result should support independent failure paths rather than duplicated labels and remain explainable to the people who operate it.

A “redundant” design whose primary and backup circuits share the same provider, facility, or physical failure point. Its evidence checklist should include circuit/tunnel topology, provider/facility diversity, routing preference, encryption requirement, and failover test results, followed by the narrowest safe correction. The final verification should explicitly include independent failure paths rather than duplicated labels.

Transit Gateway changes transitive routing into a governed service

Central connectivity among many VPCs and hybrid attachments, route-table segmentation, propagation, association, and inspection patterns. Transitivity increases scale but also creates the possibility of accidental reachability across trust boundaries. A sound approach is to separate routing domains and document which attachments can learn or reach which prefixes. That creates a clear dependency chain while protecting central transit with controlled reachability.

Automatic propagation creating a route that bypasses the intended segmentation or inspection path. Gather TGW associations, propagations, effective routes, attachment subnets, return path, and the policy boundary for each segment, isolate the first boundary where expected and observed state diverge, and verify the fix against central transit with controlled reachability.

BGP design determines how paths change during failure

Advertised prefixes, route preference, asymmetric path risk, convergence, and how Direct Connect/VPN/TGW routing interact. A backup link is useful only if routes move to it as intended and the return path remains valid. In practice, define advertisements and preference intentionally, then test convergence instead of assuming it from service diagrams. The design is stronger when predictable convergence with valid forward and return paths can be demonstrated with evidence.

Both sides choosing different preferred paths and producing intermittent or stateful-firewall failures. Check BGP session state, advertised/received routes, effective VPC/TGW routes, path symmetry, and failover timing and identify the first broken dependency. The remediation should be as narrow as possible while preserving predictable convergence with valid forward and return paths.

Hybrid DNS is part of the network architecture

Route 53 Resolver inbound/outbound endpoints, forwarding rules, on-premises resolvers, private hosted zones, and split-horizon behavior. Applications can appear disconnected even when ip routing is healthy if names resolve to the wrong endpoint or resolver path. The most defensible response is to design DNS authority and forwarding together with the network path and account model. That choice should reinforce name resolution that matches the intended private path, not merely satisfy the immediate symptom.

A workload reaching the public endpoint for a service because the private name is not resolved through the intended hybrid rule. Operators should be able to obtain query source, authoritative zone, resolver rule association, returned address, route to that address, and security policy quickly and understand which dependency owns the next action. Recovery must not compromise name resolution that matches the intended private path.

Private service access should reduce exposure without hiding dependencies

VPC endpoints and PrivateLink-style service access, endpoint policies, DNS, and which service traffic should avoid public routes. Private reachability still depends on iam, endpoint policy, name resolution, routing, and service configuration. To keep the design supportable, use endpoints where the security and routing model benefits, then verify both authorization and DNS behavior. This preserves private connectivity with explicit authorization while making dependencies easier to reason about.

An endpoint existing but clients continuing to resolve or route to a public service address. Use endpoint state, private DNS, route/security path, endpoint policy, IAM decision, and service-side access controls to confirm the failure mode and the recovery sequence, then document whether private connectivity with explicit authorization survived the exercise.

Inspection must preserve routing symmetry and failure behavior

Centralized firewalls or inspection VPCs, routing through them, stateful traffic, scale, and fail-open/fail-closed expectations. An inspection design can become a network outage mechanism if routes or appliances fail asymmetrically. Then document the enforced path and the expected outcome when inspection capacity or connectivity is impaired. The selected pattern should make security enforcement that remains valid during network failure clear to both builders and operators.

Return traffic bypassing the stateful inspection point after a route change. Validate forward/return routes, inspection attachment health, flow logs, firewall session evidence, and the failover route before assuming the root cause. Recovery should correct the underlying condition without trading away security enforcement that remains valid during network failure.

Observability should follow the packet path

VPC Flow Logs, Transit Gateway evidence, VPN/Direct Connect metrics, DNS query logs, CloudWatch signals, and change records. A hybrid outage crosses services and administrative teams, so one dashboard rarely contains the entire answer. A mature implementation will collect evidence at each boundary and correlate it by time, address, route, and change event. That prevents convenience from eroding layered troubleshooting from path intent to observed traffic over time.

Escalating between network teams without identifying the first hop where expected state diverges. Keep interface/link state, BGP, route tables, DNS, security controls, flow records, and recent changes in sequence available to operators, use it to bound the problem, and validate recovery against layered troubleshooting from path intent to observed traffic.

Migration needs coexistence, not just final-state design

Temporary connectivity, overlapping addresses, DNS cutover, routing preference, data transfer, and rollback while workloads move between environments. The highest network risk often occurs during transition when old and new paths both exist. Teams can reduce ambiguity when they design the migration network as a temporary architecture with its own security, observability, and decommission plan. The design should still hold to controlled transition with explicit removal of temporary connectivity after deployment and during recovery.

Leaving temporary routes, VPNs, resolver rules, or broad firewall exceptions in place after migration. Observe cutover checklist, route/DNS state, rollback path, temporary exception inventory, and final cleanup evidence, identify where the intended state breaks, and prove that the recovery path restores service without undermining controlled transition with explicit removal of temporary connectivity.

SAP-C02 answers should optimize the whole hybrid system

Balancing reliability, security, scale, cost, operational complexity, and migration needs across the network design. The most feature-rich topology may be harder to support and less reliable than a simpler one that meets the stated requirement. The next step is to compare options against measurable constraints and explain what operational burden each introduces. The resulting design should make requirement-led architecture rather than service prestige intentional rather than accidental.

Choosing a service because it is considered “enterprise” without showing how it satisfies the route, DNS, availability, or security requirement. Compare requirements matrix, failure tests, route/DNS evidence, cost/operational owner, and documented trade-offs with the expected behavior for requirement-led architecture rather than service prestige before changing the system. If choosing a service because it is considered “enterprise” without showing how it satisfies the route, DNS, availability, or security requirement clears, confirm requirement-led architecture rather than service prestige explicitly; recovery from choosing a service because it is considered “enterprise” without showing how it satisfies the route, DNS, availability, or security requirement should not create a different weakness elsewhere.

Address management is a strategic hybrid constraint. CIDR overlap is one of the most expensive hybrid networking problems to discover late. Acquisitions, partner networks, labs, and historical RFC1918 use can collide with planned VPC ranges. Maintain an address-management process, reserve growth space, and test migration connectivity before committing application dependencies. When overlap cannot be removed immediately, document the translation or isolation workaround and its operational limits.

Bandwidth and latency should be measured by application behavior. A network path with sufficient aggregate bandwidth can still fail the workload requirement when latency, jitter, packet loss, or per-flow behavior is wrong. Validate the applications that matter under normal and failover paths. Large data transfers, synchronous database calls, interactive administration, and latency-sensitive services have different tolerance. This keeps hybrid design tied to business traffic rather than circuit specifications alone.