1.1 Architect Network Connectivity Strategies
Official task mapping
SAP-C02 task 1.1: Address planning and hybrid DNS knowledge; connectivity selection and traffic diagnosis. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review VPC routing, hybrid connectivity and DNS. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Connectivity decisions
Use peering for a small, non-transitive mesh; Transit Gateway for controlled transitive routing; PrivateLink for service exposure rather than broad network reachability. None eliminates IP, quota, security or transfer-cost planning. Resolve overlapping CIDRs before assuming a peering/TGW attachment will work.
Direct Connect provides a dedicated connectivity path, not default end-to-end encryption. MACsec supports selected connection configurations; VPN can add IPsec, including supported private-IP VPN designs over a transit VIF. Public, private and transit VIFs serve different targets. Design independent devices/locations and verify failover paths instead of treating one dedicated link as resilient.
For hybrid DNS, inbound Resolver endpoints accept queries from on-premises; outbound endpoints and rules forward selected domains outward. Avoid forwarding loops and unintended public/private split-horizon answers. Global Accelerator routes traffic; CloudFront caches eligible content.
Global infrastructure and hybrid connectivity comparison
An AZ contains one or more data centers; it is not an edge location. Choose Regions for data residency, service availability, user latency and cost, then choose AZ placement for the actual failure model. “Always two AZs” is a useful HA prompt, not proof every service exposes the same multi-AZ configuration. IPv6 public/private addressing and routing must be assessed under current VPC support, not an assumption that all IPv6 is internet-public.
| Choice | Path and provisioning | Security/resilience consideration |
|---|---|---|
| Direct Connect private VIF | Supported VPC access through VGW/DX gateway | Dedicated link; design backup locations/devices |
| Direct Connect public VIF | Supported public AWS endpoints | Not a general VPC-transitive network |
| Direct Connect transit VIF | DX gateway/TGW integration | Supported connectivity and gateway associations |
| Site-to-Site VPN | CGW to VGW/TGW; supported public/private paths | IPsec, tunnel/link redundancy and route behavior |
| Accelerated VPN | Supported VPN path enters AWS network sooner | Eligibility and additional charges; not a dedicated circuit |
Published speed/throughput quotas depend on connection/tunnel type and current feature support. Do not assume universal 1.25-Gbps VPN or 50-Gbps TGW ceilings. Establish BGP/failover and capacity behavior with both provider and AWS; provisioning time is not universally minutes versus months.
Inter-VPC and DNS worksheet
| Pattern | Routing | Good fit | Constraint |
|---|---|---|---|
| Peering | Pairwise, non-transitive | Small direct connectivity set | Overlap, mesh operations and endpoint/instance limits |
| Transit Gateway | Routed/transitive where route tables permit | Many networks and segmented hybrid access | Attachment/processing charges and routes |
| PrivateLink | Service endpoint exposure | Producer/consumer isolation | Not broad bidirectional transitive connectivity |
Peering does not create an unlimited-throughput application path. EC2 ENI, placement and service limits still bound performance. PrivateLink can be suitable even with overlapping producer/consumer addresses because it exposes a service, not arbitrary network routes; assess actual endpoint requirements.
Trace hybrid DNS separately from IP reachability:
on-premises resolver → approved VPN/DX path → inbound Resolver → private zone
VPC query → associated forwarding rule → outbound Resolver → on-premises DNSConfirm domain rules, shared-rule ownership, security groups and redundant endpoint placement. A successful ping cannot prove DNS or service authorization.
For a CIDR change, distinguish adding supported secondary VPC ranges from resizing a subnet. Plan new subnets and migration where needed. A route matrix should specify source/destination ranges, return path, DNS and inspection requirements. Test one route-domain failure without opening all routes as a shortcut.
Scenario and rationale
A manufacturer has twelve VPCs, two factories and overlapping acquired-company address space. Production and research must be isolated, while both reach shared ERP. Use separate TGW route domains for non-overlapping networks, redundant hybrid links, and service-level exposure or an address-remediation plan for the overlap. Central Resolver rules provide consistent private names.
Reject a full peering mesh: it adds many connections and cannot provide transitive factory routing. Reject one Direct Connect circuit with no backup: dedicated does not mean redundant. Do not blindly attach overlapping VPCs.
Practice drill
Given a CIDR inventory and traffic matrix, draw permitted paths and a TGW route table per trust domain. Trace DNS and packet routing from a factory to ERP, then remove one link and one AZ from the diagram. Identify missing routes, return-path asymmetry, resolver dependencies and per-hop charges. Use Reachability Analyzer only in an authorized lab; this design exercise needs no deployment.
References
- Official Domain 1 task guide
- Transit Gateway route tables
- Private-IP VPN over Direct Connect
- Hybrid Resolver architecture
Return to Domain 1. The drill is proposed study work, not a claim of a completed deployment.
Across the wiki
- GCP Cloud Interconnect & HA VPN — hybrid connectivity (GCP)
- EKS Hybrid Nodes — hybrid connectivity (Kubernetes)