# Network Routing and DNS Guide

Use this reference for AWS network architecture reviews involving VPCs, subnets, route tables, Transit Gateway, Direct Connect, Site-to-Site VPN, Cloud WAN, Route 53 Resolver, private endpoints, ingress, egress, and inspection paths.

## What people get wrong

The lazy story is:

> If packets route in the diagram, the network design is fine.

Wrong. AWS networking fails at the boundaries: overlapping CIDRs, asymmetric routing, DNS resolver loops, endpoint policy gaps, inspection bypass, quota limits, and failover paths nobody tested.

Common bad assumptions:

- Transit Gateway centralization automatically simplifies routing.
- Security groups and NACLs are interchangeable controls.
- Private subnets are private if they lack public IPs.
- Route 53 private DNS works the same across VPCs, accounts, and hybrid networks.
- Direct Connect or VPN redundancy exists because two links are drawn.
- VPC endpoints remove all egress and data-exfiltration risk.

## Network-specific failure modes

- Overlapping or exhausted CIDR ranges block peering, TGW attachments, or future account expansion.
- Asymmetric routing breaks stateful firewalls, NAT, inspection appliances, or hybrid return paths.
- Route propagation leaks reachability across environments or bypasses inspection VPCs.
- Resolver forwarding rules create split-horizon surprises, loops, or missing conditional forwarding.
- Interface endpoint policies, private DNS, security groups, or shared services accounts are mis-scoped.
- Failover path lacks BGP, health checks, route priority, DNS TTL, or operational runbook evidence.

## Minimum safe workflow

1. Identify scope: VPCs, accounts, Regions, CIDRs, routing domains, DNS zones, and hybrid links.
2. Draw actual traffic flows for ingress, east-west, egress, service endpoints, and management access.
3. Verify route-table, TGW route-table, propagation, association, DNS resolver, and endpoint-policy boundaries.
4. Classify exposure: public internet, partner network, on-premises, shared services, workload VPC, and control plane.
5. Check availability and failover: AZ independence, NAT/endpoint placement, DX/VPN redundancy, DNS TTL, and runbook.
6. Identify least risky next actions; do not mutate routes, DNS, or firewall rules without change approval.
7. State what evidence is live, documented, user-provided, or inferred.

## Verification targets

- VPC/subnet CIDRs, route tables, NAT gateways, internet gateways, egress-only gateways, and NACL/security group intent
- Transit Gateway attachments, route tables, propagation, associations, appliance mode, and blackhole/static routes
- Direct Connect gateway/VIF, Site-to-Site VPN tunnels, BGP routes, and failover test evidence
- Route 53 Resolver inbound/outbound endpoints, forwarding rules, private hosted zones, DHCP options, and split-horizon behavior
- VPC interface/gateway endpoints, private DNS, endpoint policies, and service control boundaries
- flow logs, reachability analyzer output, packet path evidence, and recent network-change timeline

## When to push back

Push back if the user asks to:

- add broad routes such as `0.0.0.0/0` or propagated access without blast-radius proof
- bypass inspection to fix latency or connectivity quickly
- accept overlapping CIDRs as a temporary problem
- change DNS forwarding without rollback and test queries
- claim private connectivity prevents exfiltration without endpoint/resource policy evidence
- treat a diagram as proof of live routing state

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html
- https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html
- https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html
- https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- VPC security best practices include security groups, network ACLs, VPC Flow Logs, Network Firewall, and GuardDuty threat detection.
- Transit Gateway acts as a hub to interconnect VPCs and on-premises networks using attachments and route tables.

Sampled live evidence:
- Read-only regional availability sampling reported VPC, Transit Gateway, and PrivateLink as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `EC2+DescribeVpcs`, `EC2+DescribeTransitGateways`, and `EC2+DescribeVpcEndpoints` were reported `isAvailableIn` in those regions.

Review implications:
- Network design review needs CIDR/IPAM, routing, segmentation, DNS, ingress/egress, endpoint policies, inspection path, logs, and failure-domain evidence.
- Service availability does not prove route-table correctness, asymmetric path safety, or blast-radius control.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- CIDR plan, account/VPC segmentation, subnet tiers, and route table ownership
- Transit Gateway attachments, route-table associations/propagations, appliance mode, and inter-Region patterns
- Security groups, NACLs, Network Firewall/WAF, ingress and egress controls
- Flow logs, reachability evidence, DNS resolution, endpoint policy, and rollback path

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS Network Architect: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```