AWS Hybrid Networking — SAP-C02 Comprehensive Study Guide
Compiled from in-depth discussion and practice questions covering Direct Connect, Site-to-Site VPN, Transit Gateway, VIFs, and advanced integration patterns.
1. Site-to-Site VPN — All Architectural Placements
1.1 Standalone VPN (Over Internet)
┌──────────────┐ IPsec / Internet ┌──────────────┐
│ On-Prem │◄══════════════════════════════►│ VGW or TGW │
│ Router │ │ (AWS) │
└──────────────┘ └──────┬───────┘
│
┌────▼────┐
│ VPC(s) │
└─────────┘
- Simplest starting point; no dedicated circuit required.
- IPsec/IKE tunnels over the public internet.
1.2 VPN over Direct Connect (Encrypted Private Transport)
┌──────────────┐ DX Circuit (Private) ┌──────────────┐
│ On-Prem │◄═════════════════════════════►│ AWS Edge │
│ Router │ IPsec tunnel INSIDE DX │ │
└──────────────┘ └──────┬───────┘
│
┌────▼────┐
│ VGW/TGW │
└─────────┘
- VPN tunnel rides on top of a DX circuit.
- Adds encryption to a private but natively unencrypted link.
- Provides both reliability and confidentiality.
1.3 VPN as Backup/Failover for Direct Connect
┌─── DX Circuit (Primary) ─────────┐
┌──────────────┐ │ │ ┌──────────┐
│ On-Prem │◄───┤ ├───►│ VGW/TGW │
│ Router │ │ │ │ (AWS) │
└──────────────┘ └─── VPN / Internet (Backup) ──────┘ └──────────┘
BGP MED = higher value
- Key concept: Use BGP MED (Multi-Exit Discriminator) to influence inbound traffic preference.
- Prefer DX when available (lower MED), fall back to VPN (higher MED).
- Cheaper redundancy than a second DX circuit.
1.4 Hub-and-Spoke via Transit Gateway
┌────────┐ VPN ┌─────────┐ ┌───────┐
│ Site A │───────►│ │───►│VPC-1 │
└────────┘ │ TGW │ └───────┘
┌────────┐ VPN │ (Hub) │ ┌───────┐
│ Site B │───────►│ │───►│VPC-2 │
└────────┘ │ │ └───────┘
┌────────┐ VPN │ │ ┌───────┐
│ Site C │───────►│ │───►│VPC-N │
└────────┘ └─────────┘ └───────┘
- TGW aggregates multiple VPN tunnels from several on-prem sites.
- Consolidates routing and policy in one place.
1.5 Multi-Cloud VPN
┌──────────────┐ IPsec ┌──────────────┐
│ AWS TGW │◄════════════════════►│ Azure vWAN │
│ (Region) │ or GCP Cloud Rtr │ / GCP │
└──────────────┘ └──────────────┘
- Connects two different cloud environments when cloud-native interconnect isn't available.
1.6 SD-WAN Overlay
┌──────────────┐ SD-WAN Tunnels ┌──────────────────┐
│ On-Prem │◄═════════════════════►│ SD-WAN Virtual │
│ SD-WAN │ Dynamic path select │ Appliance (AWS) │
│ Appliance │ App-aware routing └────────┬─────────┘
└──────────────┘ │
┌────▼────┐
│ TGW │
└─────────┘
- Enables dynamic path selection, application-aware routing, centralized policy.
1.7 Active-Active VPN with ECMP
┌──────────────┐ Tunnel 1 (BGP) ┌──────────────┐
│ On-Prem │◄════════════════════►│ │
│ Router │ Tunnel 2 (BGP) │ TGW │──► VPCs
│ │◄════════════════════►│ (ECMP) │
└──────────────┘ Equal-cost paths └──────────────┘
- Multiple tunnels with BGP-based ECMP load balancing.
- No single tunnel is a point of failure.
1.8 Policy-Based vs. Route-Based
| Feature | Policy-Based | Route-Based |
|---|---|---|
| Traffic Selection | ACL / selector pairs | Virtual tunnel interface + routing table |
| Use Case | Specific subnet-to-subnet flows | Complex topologies, dynamic routing |
| Scalability | Limited | Scales better |
| Dynamic Routing | No | Yes (BGP supported) |
1.9 Behind a Firewall / NGFW Appliance
┌──────────┐ IPsec ┌────────────────┐ ┌─────────┐
│ On-Prem │◄═══════►│ Virtual FW/NGFW│───────►│ TGW │──► VPCs
│ Router │ │ (Palo Alto, │ └─────────┘
└──────────┘ │ Fortinet etc) │
└────────────────┘
- Deeper inspection and consistent security policy across hybrid sites.
2. Direct Connect (DX) — Core Components
2.1 Physical Connection
┌────────────────┐ Cross-Connect ┌─────────────────┐
│ Customer │ (Physical Fiber) │ AWS DX Router │
│ Router │◄════════════════════►│ at Colo │
│ (On-Prem) │ 802.1Q VLANs │ (DX Location) │
└────────────────┘ └─────────────────┘
| Type | Speed | VIF Limits |
|---|---|---|
| Dedicated | 1, 10, or 100 Gbps | Up to 50 Private/Public VIFs + 1 Transit VIF (up to 4 Transit VIFs with 51 total max) |
| Hosted | 50 Mbps – 10 Gbps | Only 1 VIF total |
2.2 What is a VIF?
A VIF (Virtual Interface) is a VLAN-tagged logical interface created on top of the physical DX circuit. It is:
- Identified by a VLAN tag (802.1Q).
- Has its own BGP session.
- The mechanism that tells AWS: "this VLAN on this physical wire should connect to this AWS resource."
- Spans the boundary — your on-prem router peers with the VIF over BGP, but the VIF itself is an AWS-side resource you create in the console.
2.3 VIF Types — Positions and Attachments
Complete Architecture Diagram — All Three VIF Types
┌───────────────────────────────────────────────┐
│ AWS Cloud │
│ │
│ ┌─────────────┐ │
│ │ AWS Public │◄── Public VIF │
│ │ Endpoints │ (S3, DynamoDB, etc.) │
│ │ (Public IPs)│ │
│ └─────────────┘ │
┌──────────┐ ┌─────────┐ │ │
│ On-Prem │ │ DX │ ┌────────────────┐ │ ┌─────────┐ ┌───────────┐ │
│ Router │◄═══►│ Circuit │═══►│ Private VIF │──┼─►│ VGW │───►│ VPC │ │
│ │ │(Physical│ └────────────────┘ │ └─────────┘ └───────────┘ │
│ │ │ Fiber) │ │ OR │
│ │ │ │ ┌────────────────┐ │ ┌─────────┐ ┌─────┐ ┌───────────┐ │
│ │ │ │═══►│ Private VIF │──┼─►│DX GW │──►│VGW │──►│ VPC │ │
│ │ │ │ └────────────────┘ │ │(Global) │ └─────┘ └───────────┘ │
│ │ │ │ │ └─────────┘ │
│ │ │ │ │ │
│ │ │ │ ┌────────────────┐ │ ┌─────────┐ ┌─────┐ ┌───────────┐ │
│ │ │ │═══►│ Transit VIF │──┼─►│DX GW │──►│ TGW │──►│ VPCs │ │
│ │ │ │ └────────────────┘ │ │(Global) │ └─────┘ └───────────┘ │
└──────────┘ └─────────┘ │ └─────────┘ │
└───────────────────────────────────────────────┘
Private VIF
| Attribute | Detail |
|---|---|
| Purpose | Access VPC resources using private IP addresses |
| Attaches to | VGW (directly) OR DX Gateway → VGW(s) |
| Cannot attach to | Transit Gateway |
| Addressing | Private IPs (RFC 1918) |
Path 1 (Direct to VGW):
On-Prem Router ──► DX Circuit ──► Private VIF ──► VGW ──► VPC
Path 2 (Via DX Gateway — Multi-Region):
On-Prem Router ──► DX Circuit ──► Private VIF ──► DX Gateway ──► VGW(s) ──► VPC(s)
(Global) (Up to 20)
Public VIF
| Attribute | Detail |
|---|---|
| Purpose | Access AWS public services using public IP addresses |
| Attaches to | AWS public service endpoints directly |
| Does NOT attach to | VGW, DX Gateway, or TGW |
| Addressing | Public IPs |
| Also used for | Transport layer for standard (public IP) Site-to-Site VPN tunnels over DX |
Path:
On-Prem Router ──► DX Circuit ──► Public VIF ──► AWS Public Endpoints
(S3, DynamoDB, EC2 public IPs,
VPN public endpoints, etc.)
Transit VIF
| Attribute | Detail |
|---|---|
| Purpose | Access one or more TGWs via DX Gateway |
| Attaches to | DX Gateway (which associates with TGW) |
| Cannot skip | The DX Gateway layer — required intermediary |
| Limit | 1 Transit VIF per DX connection (hosted); up to 4 per dedicated |
Path:
On-Prem Router ──► DX Circuit ──► Transit VIF ──► DX Gateway ──► TGW ──► VPCs
(Global) (Regional)
2.4 DX Gateway — Position and Purpose
┌──────────────────────────────────────┐
│ DX Gateway (GLOBAL) │
│ │
Transit VIF ─────►│ LEFT SIDE RIGHT SIDE │
or Private VIF │ (Faces DX (Faces TGW │
│ Circuit) or VGW) │
│ │
│ • Terminates VIFs • Associates │
│ • BGP peering with TGWs │
│ with on-prem (up to 3) │
│ • Or VGWs │
│ (up to 20) │
└──────────────────────────────────────┘
Key facts:
- Global construct — not tied to any single AWS Region.
- Pure routing/association layer — does NOT inspect, encrypt, or transform traffic.
- Does NOT terminate IPsec tunnels.
- A DX Gateway can associate with either VGWs (Private VIFs) or TGWs (Transit VIFs), but NOT both simultaneously.
- Does NOT route between its own attachments (no transitive routing between two VIFs on the same DXGW, unless SiteLink is enabled).
3. IPsec Termination — What Can and Cannot Terminate Tunnels
Resources That CAN Terminate IPsec
┌─────────────────────────────────────────────────┐
│ IPsec Termination Points │
├──────────────────┬──────────────────────────────┤
│ │ │
│ VGW │ TGW │
│ (VPC-level) │ (Regional) │
│ │ │
│ • 1 VGW per │ • VPN attachment │
│ VPC │ • Two flavors: │
│ • Terminates │ - Public IP VPN │
│ VPN from │ (via internet or │
│ on-prem │ Public VIF) │
│ • Single VPC │ - Private IP VPN │
│ connectivity │ (via Transit VIF + │
│ │ DX Gateway) │
│ │ • Connects to 1000s │
│ │ of VPCs │
└──────────────────┴──────────────────────────────┘
Resources That CANNOT Terminate IPsec
| Resource | What It Actually Does |
|---|---|
| DX Gateway | Routing/association layer only |
| VIFs (Private/Public/Transit) | Logical interfaces for DX, not encryption endpoints |
| NAT Gateway | Address translation only |
| DX Circuit itself | Unencrypted by default (MACsec is Layer 2, not IPsec) |
Mental model: If you need IPsec in AWS, the tunnel always terminates on either a VGW or a TGW. Everything else is just transport.
4. Encryption over Direct Connect
4.1 MACsec (Layer 2)
┌──────────┐ MACsec Encrypted (L2) ┌──────────┐
│ On-Prem │◄══════════════════════════►│ AWS DX │
│ Router │ 10 or 100 Gbps ONLY │ Router │
└──────────┘ Dedicated Conn ONLY └──────────┘
- Layer 2 encryption — not IPsec, not FIPS-compliant IPsec.
- Only available on 10 Gbps and 100 Gbps Dedicated connections.
- NOT available on Hosted connections or 1 Gbps.
4.2 Public VIF + Site-to-Site VPN to TGW (Public IP VPN over DX)
┌──────────┐ IPsec in DX Circuit ┌──────────┐ ┌─────┐
│ On-Prem │◄══════════════════════►│Public VIF │──►│ TGW │──► VPCs
│ Router │ via Public VIF │ │ │ │
└──────────┘ Public VPN endpoints └──────────┘ └─────┘
- Classic pattern for IPsec over DX when Private IP VPN isn't available.
- IPsec packets travel over DX circuit via Public VIF to TGW's public VPN endpoints.
- Satisfies FIPS-compliant IPsec mandates.
4.3 Private IP VPN over DX (Transit VIF + TGW VPN)
┌──────────┐ ┌───────────┐ ┌────────┐ ┌─────┐
│ On-Prem │◄═══DX Circuit═══►│Transit VIF│──►│ DX GW │──►│ TGW │──► VPCs
│ Router │ IPsec inside └───────────┘ └────────┘ │ │
└──────────┘ RFC 1918 addrs │ VPN │
(Private IP │ att │
VPN endpoints) └─────┘
- Preferred modern approach.
- All private addressing — tunnel endpoints are RFC 1918 on the AWS side.
- Two layers of BGP:
- Transit VIF BGP (carries VPN endpoint reachability).
- Inner IPsec tunnel BGP (carries VPC/workload prefixes).
5. Transit Gateway (TGW) — Advanced Patterns
5.1 Cross-Region TGW Peering
Region: us-east-1 Region: eu-west-2
┌──────────┐ ┌────────┐ ┌─────────┐ Peering ┌─────────┐ ┌────────┐ ┌──────────┐
│ NY Data │──►│DX GW │──►│TGW-East │◄═════════►│TGW-West │◄─│DX GW │◄──│ London │
│ Center │ │ │ │ │ Static │ │ │ │ │ Data Ctr │
└──────────┘ └────────┘ │ ┌───┐ │ Routes │ ┌───┐ │ └────────┘ └──────────┘
│ │VPC│ │ Only! │ │VPC│ │
│ └───┘ │ │ └───┘ │
└─────────┘ └────────┘
Critical constraints:
- Only static routes across peering — BGP routes from DX do NOT propagate across the peering link.
- You must manually add static routes on both TGW peering route tables.
- Use unique ASNs for each peered TGW.
- Traffic is encrypted (AES-256) and stays on AWS backbone.
- A single DXGW can associate with up to 3 TGWs — for more than 3 regions, additional DXGWs are required.
5.2 TGW Connect (SD-WAN / GRE Integration)
┌──────────────┐ ┌───────────┐ ┌────────┐ ┌──────────────────┐
│ On-Prem │◄══DX Circuit══►│Transit VIF│──►│ DX GW │──►│ TGW │
│ SD-WAN │ └───────────┘ └────────┘ │ │
│ Appliance │ GRE + BGP inside ════════════════════════►│ Connect │──► VPCs
│ │ (up to 5 Gbps per peer) │ Attachment │
└──────────────┘ │ (GRE tunnels) │
└──────────────────┘
Key facts:
- Purpose-built for SD-WAN integration with TGW.
- Uses GRE tunnels (not IPsec) — with BGP running inside the GRE tunnel.
- Requires an underlying transport attachment: either a VPC attachment or a DX Gateway attachment.
- Single Connect peer = up to 5 Gbps (no ECMP needed).
- Up to 4 Connect peers per Connect attachment = 20 Gbps max.
- Avoids the need to manage multiple IPsec tunnels or ECMP on the customer side.
When to use: Whenever you see "SD-WAN + TGW + native integration" or "avoid IPsec tunnel management" in a question.
6. AWS Direct Connect SiteLink
6.1 What It Does
┌────────────┐ ┌────────────┐
│ NY Data │ ┌──────────┐ AWS Global ┌──────────┐ │ London │
│ Center │◄───►│ NY DX │ Backbone │ London │◄───►│ Data Ctr│
└────────────┘ │ Location │◄═════════════►│ DX Loc │ └────────────┘
└────┬─────┘ (SiteLink) └────┬─────┘
│ Bypasses Regions! │
│ │
└─────────┬─────────────────┘
│
┌─────▼─────┐
│ DX GW │ (Both VIFs must attach
│ (Global) │ to the SAME DX GW)
└───────────┘
- Sends data directly between DX locations via the AWS backbone.
- Bypasses AWS Regions entirely — traffic never enters a Region unless it needs AWS resources.
- Takes the shortest path between DX locations.
6.2 SiteLink Key Facts
| Attribute | Detail |
|---|---|
| VIF types supported | Private VIF and Transit VIF |
| Requirement | All VIFs must attach to the same DX Gateway |
| Connection types | Dedicated and Hosted |
| Enable/disable | On existing VIFs, in minutes |
| Routing | BGP (dynamic) — full end-to-end dynamic routing |
| Pricing | Pay-as-you-go: port hours + data transfer out |
| Limitation | Does NOT work if same route is advertised on multiple VIFs from same router |
6.3 SiteLink Use Cases
Replace or back up MPLS/WAN — Use AWS backbone instead of expensive private WAN. Can be primary or backup path (use BGP communities to influence preference).
Data center to data center — Direct, low-latency connectivity between global offices without traversing AWS Regions.
Network segmentation — Create multiple DXGWs as trust boundaries. Separate production/non-production traffic between sites using different VIFs to different DXGWs.
Transient/ephemeral connectivity — Enable SiteLink temporarily for data replication or partner data exchange, then disable.
Simplify TGW inter-region peering — SiteLink offers reduced latency, dynamic routing, and better route quotas vs. TGW peering. However, use TGW if you need in-region compute (NAT, firewall inspection, transcoding).
SD-WAN integration — Combine SiteLink with SD-WAN for global application-aware routing.
6.4 SiteLink vs. TGW Cross-Region Peering
| Feature | SiteLink | TGW Cross-Region Peering |
|---|---|---|
| Traffic path | Shortest path, bypasses Regions | Through AWS Regions |
| Routing | Dynamic (BGP) | Static routes only |
| Setup complexity | Low (enable on VIFs) | Higher (TGWs, DXGWs, static routes) |
| In-region processing | No (bypasses Regions) | Yes (NAT, firewall, inspection) |
| Use case | Site-to-site over AWS backbone | Region-to-region with compute |
7. Architectures That DO NOT Work (Common Exam Traps)
7.1 Private VIF → TGW (INVALID)
✗ Private VIF ──X──► TGW ← NOT POSSIBLE
✓ Private VIF ──────► VGW ← Correct
✓ Transit VIF ──────► DX GW ──► TGW ← Correct
A Private VIF can only attach to a VGW (or DX Gateway associated with VGWs). To reach a TGW, you must use a Transit VIF through a DX Gateway.
7.2 VGW → IPsec → TGW (INVALID)
✗ VGW ──IPsec──► TGW ← NOT POSSIBLE
VGW and TGW are both termination points. They don't establish IPsec tunnels to each other. You pick one or the other for a given traffic flow.
7.3 IPsec Termination on DX Gateway (INVALID)
✗ On-Prem ──IPsec──► DX GW ← NOT POSSIBLE
A DX Gateway is purely a routing/association construct. It does not terminate IPsec tunnels. Only VGW and TGW can terminate IPsec.
7.4 Private VIF Directly to TGW (Skipping DX GW) (INVALID)
✗ Transit VIF ──► TGW (directly) ← NOT POSSIBLE
There is no way to skip the DX Gateway layer. A Transit VIF must attach to a DX Gateway, which then associates with the TGW.
7.5 MACsec on Hosted or 1 Gbps Connections (INVALID)
✗ MACsec on 1 Gbps Hosted ← NOT POSSIBLE
✓ MACsec on 10 Gbps Dedicated ← Correct
✓ MACsec on 100 Gbps Dedicated ← Correct
MACsec is only supported on 10 Gbps and 100 Gbps Dedicated connections.
7.6 DX Gateway Associates with Both VGWs and TGWs Simultaneously (INVALID)
✗ DX GW ──► VGW + TGW simultaneously ← NOT POSSIBLE
✓ DX GW ──► VGW(s) only ← Correct (up to 20)
✓ DX GW ──► TGW(s) only ← Correct (up to 3, up to 6 newer limit)
A DX Gateway can associate with either VGWs (via Private VIFs) or TGWs (via Transit VIFs), but never both at the same time.
8. Overlapping CIDRs + One-Way Traffic — Private NAT Gateway
8.1 Problem
Your Enterprise: 10.0.0.0/8 Acquired Startup: 10.0.0.0/8
↕ OVERLAP ↕ ↕ OVERLAP ↕
Both networks use the same IP space. Standard routing breaks — routers can't distinguish local vs. remote destinations.
8.2 Solution: Private NAT Gateway
┌──────────────┐ ┌──────────────────────────────┐ ┌──────────────┐
│ Your VPC │ │ Dedicated NAT VPC │ │ Startup │
│ 10.0.0.0/8 │ │ 172.16.0.0/16 │ │ On-Prem │
│ │ │ │ │ 10.0.0.0/8 │
│ EC2 │ TGW │ ┌────────────────────────┐ │ VPN │ │
│ 10.1.1.1 │──────►│ │ Private NAT Gateway │ │──────►│ Server │
│ │ │ │ │ │ │ 10.5.5.5 │
│ │ │ │ SRC: 10.1.1.1 │ │ │ │
│ │ │ │ ──► 172.16.x.x │ │ │ │
│ │ │ │ (No overlap!) │ │ │ │
│ │ │ └────────────────────────┘ │ │ │
└──────────────┘ └──────────────────────────────┘ └──────────────┘
Why it works for both problems:
Overlapping CIDRs: Private NAT Gateway translates source from 10.x.x.x → 172.16.x.x. Startup sees traffic from non-overlapping space.
One-way initiation: NAT is stateful — it only allows return traffic for connections initiated from the AWS side. Startup servers cannot initiate new inbound connections because there's no NAT translation entry for unsolicited traffic. This is a fundamental property of NAT, not a bolt-on security rule.
9. Encrypted DX to TGW — Decision Tree
Need IPsec over DX to TGW?
│
├── Private IP VPN available?
│ │
│ ├── YES ──► Transit VIF → DX GW → TGW
│ │ + Private IP VPN attachment
│ │ (All private addressing, RFC 1918)
│ │
│ └── NO ───► Public VIF → TGW Public VPN Endpoints
│ + Standard Site-to-Site VPN
│ (IPsec over DX via public IPs)
│
└── Only need Layer 2 encryption (not IPsec)?
│
├── 10/100 Gbps Dedicated? ──► MACsec
│
└── Hosted or 1 Gbps? ──► MACsec NOT available
Use VPN instead
10. Key Exam Concepts — Quick Reference
BGP Concepts in Hybrid Networking
| Concept | Use Case |
|---|---|
| BGP MED | Influence inbound traffic preference for DX + VPN failover |
| AS_PATH prepending | Make a path less preferred by lengthening the AS path |
| BGP communities | Influence route preference with SiteLink or DX |
| ECMP | Load balance across multiple equal-cost paths (VPN tunnels) |
TGW Peering Route Propagation Limitation
- TGW inter-Region peering does NOT automatically propagate DX-originated BGP routes.
- Static routes must be configured manually on both sides.
- This is one of the most frequently tested constraints on SAP-C02.
DX Gateway Limits
| Limit | Value |
|---|---|
| TGW associations per DXGW | Up to 3 (newer: up to 6) |
| VGW associations per DXGW | Up to 10 (newer: up to 20) |
| Transit VIFs per DXGW | Up to 30 |
| VIF type mixing | Private OR Transit, never both |
VPN Bandwidth
| Configuration | Max Bandwidth |
|---|---|
| Single VPN tunnel | ~1.25 Gbps |
| VPN with ECMP (2 tunnels) | ~2.5 Gbps |
| TGW Connect (single peer, GRE) | Up to 5 Gbps |
| TGW Connect (4 peers, GRE) | Up to 20 Gbps |
11. Complete Architecture — Everything Connected
AWS Cloud
┌────────────────────────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌──────────┐ Peering ┌──────────┐ │
│ │ DX GW A │───────►│ TGW-East │◄══════════►│ TGW-West │◄──── DX GW B │
│ │ │ │us-east-1 │ (Static) │eu-west-2 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ Transit VIF ┌────┴────┐ ┌────┴────┐ │
│ │ │VPC VPC │ │VPC VPC │ │
│ │ │ A B │ │ C D │ │
│ SiteLink └─────────┘ └─────────┘ │
│ (bypass │ │
│ region) VPN Attachment │
│ │ (IPsec termination) │
│ │ │ │
└────────┼───────────────────┼──────────────────────────────────────────────────┘
│ │
┌────┴─────┐ ┌────┴──────┐
│ NY DX │ │ Internet │
│ Location │ │ │
└────┬─────┘ └────┬──────┘
│ │
┌────┴─────┐ ┌────┴──────┐
│ NY Data │ │ Branch │
│ Center │ │ Office │
└──────────┘ └───────────┘
Last updated: Based on SAP-C02 study discussions covering Site-to-Site VPN placements, VIF types and positions, DX Gateway role, IPsec termination points, encrypted DX patterns, TGW Connect (SD-WAN/GRE), cross-region TGW peering, SiteLink use cases, Private NAT Gateway for overlapping CIDRs, and MACsec limitations.