1. AWS Network Overview

AWS operates one of the largest private fiber-optic backbones in the world. This backbone connects Data Centers, groups them into Availability Zones (AZs), and links multiple AZs to form a Region. From there, AWS extends outwards through Points of Presence (PoPs), which connect to the public internet or provide private connectivity via Direct Connect.

1. Data Centers, AZs, and Regions
   • Data Centers are the physical foundation.
   • A group of data centers = an Availability Zone (AZ).
   • Several AZs = a Region, interconnected by the AWS backbone for low-latency, fault-tolerant networking.
2. Points of Presence (PoPs)
   • AWS racks hosted inside third-party colocation sites (e.g., Equinix, Digital Realty).
   • Link the AWS backbone to local ISPs and IXPs.
   • Run edge services such as CloudFront (CDN caching) and Global Accelerator (traffic optimization).
3. Public Internet Connectivity
   • PoPs handle AWS traffic in and out of the public internet.
   • Customers reach AWS services through public endpoints (e.g., S3, EC2 APIs).
4. Direct Connect (DX)
   • A dedicated private link that bypasses the internet.
   • Provisioned at a PoP, giving you a physical port on AWS gear.
   • Delivers lower latency, higher reliability, and consistent bandwidth for hybrid cloud workloads.

🌐 AWS Network Overview

---

2. Service Categories

2.1 Internet Connectivity (Ingress & Egress)

AWS Service	Purpose	OSI Layer	Upstream	Downstream	Limitations	Pricing
Internet Gateway (IGW)	Enables VPC to access the internet.	L3 – Network	Public Subnet	Internet	• One IGW per VPC • No filtering (not a firewall)	Free
NAT Gateway	Allows private subnets to reach the internet.	L3 – Network	Private Subnet	IGW / Internet	• Outbound-only (no inbound) • Not HA by default (deploy per AZ)	Hourly charge + per GB data processing
Virtual Private Gateway (VGW)	AWS VPN tunnel endpoint for Site-to-Site VPN.	L3 – Network	On-prem VPN device (CGW)	VPC Route Tables	• One VGW per VPC • Max ~1.25 Gbps per tunnel • Cannot connect multiple VPCs directly	Hourly VPN + data transfer
Customer Gateway (CGW)	Customer-managed device establishing VPN tunnels to AWS.	L3 – Network	On-prem Router/Firewall	VGW / TGW	• Managed by customer • HA depends on design	N/A (customer hardware cost)
Transit Gateway (TGW)	Central router between VPCs, VPNs, and Direct Connect.	L3 – Network	VPCs / VPN / DX	VPCs / VPN / DX	• One RT per attachment • Propagation optional • Default full mesh • TGW Peering static routes only	Per attachment + per GB data processed
Direct Connect (DX)	Dedicated physical link to AWS, bypassing Internet.	L1 – Physical	On-prem Router/Switch	VPC via TGW / VGW	• Provisioning time weeks • No encryption by default • HA requires multiple DX	Per port-hour + data transfer (lower than internet egress)

---

AWS Service	Purpose	OSI Layer	Upstream	Downstream	Limitations	Pricing
VPC Peering	Connects two VPCs privately.	L2 (abstracted)	VPC A	VPC B	• No transitive routing • Cannot use overlapping CIDRs	Data transfer per GB (intra-Region cheaper, inter-Region higher)
Gateway Endpoints	Route table entry to access S3/DynamoDB via AWS backbone.	L3 – Network	VPC Subnet	S3 / DynamoDB	• Only supports S3 and DynamoDB • One per route table • Supports VPC endpoint policies	Free
Interface Endpoints (PrivateLink)	ENI-based private access to other AWS services or partner services.	L3 / L4	VPC Subnet / ENI	AWS Service ENI	• Does NOT support S3/DynamoDB (use Gateway instead) • One per AZ for HA • Private DNS overrides service DNS • Supports VPC endpoint policies	Hourly ENI cost + per GB data processed
Route 53 Resolver (.2)	Built-in VPC DNS resolver (`.2` address in every subnet) for public zones and associated private zones.	L3 – Network	EC2 / Lambda / ENI	Internal DNS targets (via `.2`)	• VPC-only (not accessible from on-prem) • No customization • Hybrid DNS requires endpoints	Free (included with VPC)
Route 53 Resolver Endpoints	Extend DNS resolution across hybrid networks: • Inbound – On-prem → VPC resolver • Outbound – VPC → on-prem DNS	L3 – Network	On-prem DNS or VPC resources	Route 53 Resolver / On-prem DNS	• Requires ENIs in subnets • One per AZ for HA • Adds query latency vs. .2 • Query-based limits	Hourly ENI cost + query-based pricing

---

2.2 Load Balancing and Traffic Distribution

AWS Service	Purpose	OSI Layer	Upstream	Downstream	Limitations	Pricing
ALB (Application Load Balancer)	Routes HTTP/HTTPS traffic.	L7 / L4	Internet / CloudFront	EC2 / Lambda / IPs	• HTTP/HTTPS only • No static IPs (unless behind GA)	Hourly + per LCU + data processed
NLB (Network Load Balancer)	Balances TCP/UDP traffic.	L4 – Transport	Internet / Internal VPC	EC2 / IPs	• No advanced routing (L7) • Health checks limited	Hourly + per LCU + data processed
Gateway Load Balancer (GWLB)	Sends traffic to firewalls/appliances.	L3 / L4	IGW / NLB	Security Appliance	• Appliances must support GENEVE • Adds latency	Hourly + per LCU + data processed
Global Accelerator	Routes global traffic via Anycast IPs.	L4 – Transport	End User	NLB / ALB / IPs	• Not a CDN • No caching	Per accelerator-hour + data transfer

---

2.3 Security and Access Control

AWS Service	Purpose	OSI Layer	Upstream	Downstream	Limitations	Pricing
WAF	Filters HTTP/HTTPS requests.	L7 – Application	CloudFront / ALB	ALB / API Gateway	• L7 only • Rule limits apply	Per WCU (rule capacity unit) + requests
AWS Shield / Advanced	DDoS protection for infra/apps.	L3–L7	Internet / Edge	VPC Entry Points	• Shield Standard auto, Advanced = $$	Shield Std free, Advanced fixed monthly fee
ACM	Manages SSL/TLS certificates.	L6 – Presentation	N/A (integrated)	CloudFront / ALB / API GW	• Only ACM-issued certs auto-renew	Free for ACM-managed certs
Security Groups / NACLs	Allow/deny traffic at instance/subnet.	L3 / L4	Client / Peer Service	EC2 / ENI / Subnet	• SG stateful, NACL stateless • NACL rules limit	Free

---

2.4 Edge Services and DNS

AWS Service	Purpose	OSI Layer	Upstream	Downstream	Limitations	Pricing
CloudFront	Distributes and caches content globally at PoP.	L7 – Application	End Users	ALB / S3 / API GW	• Cache invalidation costs • Regional edge cache not everywhere	Per request + data transfer out
Route 53	DNS resolution with routing policies.	L7 – Application	End Users	IP / ALB / CloudFront	• Query costs • Geo/latency policies add cost	Per hosted zone + per query

---

2.5 API and Microservice Communication

AWS Service	Purpose	OSI Layer	Upstream	Downstream	Limitations	Pricing
API Gateway	Expose/manage REST/HTTP/WebSocket APIs.	L7 – Application	Client / CloudFront	Lambda / Service Backend	• Payload size limits • Latency higher than ALB	Per million requests + data processed
App Mesh	Controls service-to-service traffic in a mesh.	L7 – Application	Microservice A	Microservice B	• Envoy sidecar overhead • Complexity	Per Envoy proxy-hour

---

2.6 Core Networking Components

Component	Purpose	OSI Layer	Upstream	Downstream	Limitations	Pricing
VPC	Isolated virtual network with subnets and routing.	L3 – Network	Internet / VPN	Subnets	• Max 5,000 subnets • CIDR block limits	Free
Elastic Network Interface (ENI)	Virtual NIC attached to resources.	L2 – Data Link	Subnet / VPC	EC2 / Lambda	• Limited ENIs per instance type	Free (included in instance cost)

---

3. VPN

Note VPN builds on top of IPSec, for details on how IPSec works, see 3.4 Layer 3 & 5–6 - IPsec

3.1 Site-to-Site VPN

• Purpose:
  • Site-to-Site VPN = Network ↔ Network
  • Connects an entire on-premises network (via a CGW) to an AWS VPC network (via a VGW or TGW).
  • Used for hybrid cloud connectivity, extending datacenter or branch office networks into AWS.
  • Example: Your office LAN can securely reach EC2 instances inside VPCs.

🔐 Site-to-Site VPN – Communication Sequence

3.1.1 Connectivity Types

Keep in mind, VPN connections traverse the public Internet before reaching AWS’s network. Because of this, the routing path and how routes are exchanged are critical.

• Static VPN
  • Route: Static routes in route tables (manual setup).
  • Pros: Simple setup.
  • Cons: No load balancing or failover.
• Dynamic VPN
  • Route: Uses BGP for automatic route exchange.
  • Pros: High availability, automatic failover, and load balancing.
  • Cons: More complex setup.

3.1.2 Deployment Workflow

• Step 1: Create TGW and Attachments
  • Create TGW (default RT = Route Table A).
  • Attach: VPC1, VPC2, and On-premises (via VPN or Direct Connect).
  • Notes on VPN connectivity:
    • Uses the AWS Global Network, but tunnels still traverse the public Internet.
    • Provides 2 resilient public endpoints with 2 IPSec tunnels for redundancy.
    • Performance, latency, and consistency vary due to Internet hops.
• Step 2: Configure TGW Route Table & Associations
  • By default, all attachments are associated with the TGW’s default route table (Route Table A).
  • You can create custom TGW route tables and associate attachments to them for segmentation (e.g., Dev vs Prod).
  • For this setup, keep VPC1, VPC2, and On-premises associated to Route Table A, but remove cross-VPC routes so VPC1 ↔ VPC2 traffic is blocked.
• Step 3: Configure VPC Route Tables
  • VPC1 RT: Add 0.0.0.0/0 → TGW Attachment (for On-prem). No route to VPC2.
  • VPC2 RT: Add 0.0.0.0/0 → TGW Attachment (for On-prem). No route to VPC1.
• Step 4: On-premises Integration (Propagation)
  • Enable propagation from On-prem → TGW RT so both VPCs can learn routes automatically.
  • Ensure On-prem routes are advertised back to TGW.
  • Options to connect:
    1. VGW → CGW (1:1 VPC)
    2. TGW → CGW (1:M VPCs)
    3. Accelerated Site-to-Site VPN (TGW only)
    4. Direct Connect (DX):
       • Private VIF → For VPC connectivity via TGW/VGW.
       • Public VIF → For AWS public services (not VPC routing).
       • Transit VIF → For scaling via TGW to multiple VPCs (enterprise-scale option).
• Step 5: BGP Exchange Sequence (Dynamic VPN)
  1. On-Prem Router Configures BGP ASN → prepares to exchange routes.
  2. Advertises Internal Routes → on-prem router sends subnets (e.g., 192.168.1.0/24).
  3. AWS VPN Gateway Setup → VPN tunnels established.
  4. BGP Peering → session formed between on-prem router and AWS VPN Gateway.
  5. Route Advertisement → AWS advertises VPC subnets to the on-prem router.
  6. Route Learning → on-prem router learns AWS subnets via BGP.
  7. Traffic to AWS → routed to TGW using BGP-learned paths.
  8. TGW Forwarding → TGW routes traffic to the correct VPC.
  9. Return Traffic from AWS → VPC → TGW → VPN tunnels → back to on-prem router.
• Resulting Traffic Flows
  • VPC1 → TGW → On-premises ✅
  • VPC2 → TGW → On-premises ✅
  • VPC1 ↔ VPC2 ❌ (blocked by TGW RT config)

3.1.3 Operational Considerations

• Speed: Maximum throughput is 1.25 Gbps per VPN tunnel.
• Latency: Varies and can be inconsistent, as traffic traverses the public Internet.
• Cost: Hourly charges per VPN connection, plus standard AWS data transfer fees (outbound GB).
• Provisioning Speed: Quick to set up, as VPNs are software-based and do not require physical circuits.
• High Availability:
  • Each VPN connection can support two tunnels for redundancy.
  • HA depends on having multiple on-premises customer gateways (e.g., in different locations).
• Integration with Direct Connect:
  • VPNs can serve as a backup for DX (failover).
  • VPN and DX can be used together for hybrid redundancy.

---

3.2 Client VPN

AWS Client VPN is a fully managed OpenVPN-based service that allows individual users (laptops, developers, admins, remote workers) to securely connect to AWS resources and on-premises networks.

• Purpose:
  • Client VPN = User ↔ Network
  • Unlike Site-to-Site VPN (which connects entire networks), Client VPN provides user-level access into AWS.
• Architecture:
  • Users connect to a Client VPN Endpoint deployed in a VPC.
  • The endpoint is associated with one or more subnets (ENIs) across AZs for high availability.
  • Billed based on the number of network associations and connected clients.
• Use Cases:
  • Remote workforce access to AWS resources in a VPC.
  • Secure developer/admin access without requiring a full corporate VPN.
  • Extending access into on-premises networks if Client VPN is associated with a TGW or VGW.
• VPN Types:
  • Full Tunnel: All traffic (AWS + Internet) routes through the VPN.
  • Split Tunnel (not default): Only AWS/VPC traffic routes through the VPN; Internet-bound traffic goes out locally.
• Authentication:
  • Certificate-based (via ACM).
  • Identity-based (Active Directory, SAML, or federated IdPs).
• Setup Workflow:
  1. Create Certificates in ACM
     • Server certificate for the VPN endpoint.
     • Client certificates for users.
     • Certificates are used to establish trust between client and server.
  2. Create Client VPN Endpoint in AWS.
  3. Associate Subnets (ENIs) across AZs for HA.
  4. Configure Authorization Rules (which clients can access which networks).
  5. Add a DNS Server IP (so clients can resolve hostnames inside the VPC).
  6. Download/OpenVPN configuration file and distribute to clients.
  7. Clients connect using an OpenVPN-compatible client.

3.2.1 Connection Sequence

🔐 Client VPN – Authentication & Connection Flow

---

4. Route Tables

• VPC Route Tables: Decide routing inside each VPC.
• TGW Route Tables: Decide routing between VPCs, VPNs, and On-prem.
• Association: Each attachment (VPC, VPN, DX) can only be linked to one TGW RT.

• Propagation: Routes can automatically flow into TGW RTs (e.g., from VPN or On-prem).

• Routing Priority:
  • Inside VPC → VPC RT applies.
  • Across attachments → TGW RT applies.
  • Longest prefix match always wins.
  • Static routes take precedence over propagated routes.
  • If multiple propagated routes exist, AWS evaluates in this order:
    1. Direct Connect (DX)
    2. VPN Static
    3. VPN BGP
    4. AS_PATH length (shortest wins)

• Subnet Association: Each subnet can only be associated with one RT (main or custom).

• CIDR Overlap:
  • Use separate RTs per subnet to send traffic to different VPCs with the same CIDR.
  • Or rely on more specific prefixes, since routing favors specificity.
• Ingress Routing (Gateway Route Tables):
  • Enables inspection/control of inbound traffic flows.
  • Previously, RTs only controlled outbound traffic; ingress routing extends this capability for security appliances.

---

5. Direct Connect

AWS Direct Connect (DX) provides a dedicated, private network connection between your on-premises environment and AWS. Unlike VPN (which traverses the Internet), DX offers consistent latency, predictable bandwidth, and enterprise-grade reliability.

5.1 Direct Connect Physical Architecture

• Port Speeds: 1 / 10 / 100 Gbps
  • 1 Gbps → 1000BASE-LX (1310 nm)
  • 10 Gbps → 10GBASE-LR (1310 nm)
  • 100 Gbps → 100GBASE-LR4
• Medium: Single-mode fiber only (no copper).
• Configuration: Auto-negotiation disabled → both ends must manually set speed and full-duplex.
• Routing: Uses BGP with MD5 authentication.
• Optional:
  • MACsec (802.1AE) for Layer 2 encryption.
  • Bidirectional Forwarding Detection (BFD) for fast failure detection.

5.2 MACsec Security Layer

DX traffic is not encrypted by default. MACsec secures the physical hop between your router and AWS’s DX router at the PoP.

• Scope: Frame-level encryption (Layer 2).
• Guarantees: Confidentiality, integrity, origin authentication, replay protection.
• Performance: Hardware-accelerated, minimal overhead at 10/100 Gbps.
• Mechanism: Secure Channels, Secure Associations, SCI identifiers, 16B tag + 16B ICV.
• Limitations: Not end-to-end; only protects between directly connected devices. Use IPsec over DX if end-to-end encryption is required.

5.3 Direct Connect Provisioning Workflow

1. LOA-CFA (Letter of Authorization – Connecting Facility Assignment)
   • AWS allocates a port inside their cage at the DX location (PoP).
   • You receive LOA-CFA to hand to your provider or colo staff.
2. Physical Cross-Connect
   • Fiber is patched between your cage/router and the AWS DX router at the PoP.
   • Ports are set with matching speed/duplex.

5.4 Direct Connect Virtual Interfaces

DX is a Layer 2 link. To run multiple logical networks, DX uses 802.1Q VLANs, each mapping to a Virtual Interface (VIF) on the AWS side.

• Each VIF = one VLAN + one BGP session.
• On the customer side: configure sub-interfaces (per VLAN) with BGP.

Types of VIFs:

1. Private VIF
   • Connects to VGW (1 VPC) or TGW (multiple VPCs).
   • Used for private VPC IP ranges.
   • Region-specific (per DX location).
   • 1 VIF = 1 VGW = 1 VPC (unless TGW is used).
   • No built-in encryption.
2. Public VIF
   • Connects to AWS public endpoints (e.g., S3, DynamoDB, STS).
   • AWS advertises all public IP prefixes; you advertise your public IPs.
   • Global scope (all AWS regions).
   • Not transitive: your prefixes are not re-shared by AWS.
   • Can combine with VPN for DX + VPN (low latency + encryption).
3. Transit VIF
   • Connects via DX Gateway (DXGW) → TGW.
   • Scales to multiple VPCs across accounts/regions.
   • Requires BGP.
   • Enterprise-scale hub-and-spoke hybrid connectivity.

5.5 Direct Connect Gateway

• DX is per-region, but DXGW allows sharing across accounts and regions.
• Public VIFs: Can access all AWS regions (since public IPs are global).
• Private VIFs: Normally regional, but DXGW extends them to multiple regions via VGWs or TGWs.
• Enables multi-account, multi-region hybrid architectures.

5.6 Operational Considerations

• Speed: Up to 100 Gbps, depending on DX location/provider.
• Encryption: Not built-in → use MACsec (L2 hop-by-hop) or VPN over DX (end-to-end).
• Resiliency: Use redundant DX links at different PoPs for HA.
• Cost: Port-hour charges + data transfer (cheaper than Internet egress).
• Provisioning: Weeks (physical cabling) vs minutes for VPN.
• Routing Priority:
  • Longest prefix match always wins.
  • Static > propagated.
  • Typically, DX > VPN for the same prefix.
• Best Practice: DX + VPN (over DX Public VIF) = encrypted, resilient connectivity.

5.7 Connection Sequence

🔌 Direct Connect – Physical + VIF Sequence

---

6. Domain Name System (DNS)

DNS (Domain Name System) resolves human-readable domain names (e.g., example.com) into IP addresses or service endpoints. In AWS, Route 53 provides DNS hosting, routing policies, and integration with AWS resources (via Alias records).

👉 Important distinction:

• DNS Hosting: Runs authoritative DNS servers that store and answer queries for your domain’s records.
  • Stores zone files (the authoritative set of DNS records for your domain).
  • Uses name servers (NS records), which are basically the servers that host and respond with your zone file data.
  • Examples: Route 53, Cloudflare, GoDaddy DNS.
• TLD Registry / Registrar: Manages ownership of domain names under a top-level domain (TLD), like .com or .org.
  • The registry (e.g., Verisign for .com, PIR for .org) maintains the authoritative database of who owns each domain.
  • The registrar (e.g., GoDaddy, Namecheap) is where you register, renew, or transfer domains.
• These can be provided by the same company (e.g., GoDaddy = registrar + DNS host) or by different ones (e.g., register with Namecheap, host DNS with Route 53).

6.1 Common DNS Record Types

Record Type	Purpose	Example
A	Maps domain → IPv4 address	example.com. IN A 192.0.2.1
AAAA	Maps domain → IPv6 address	example.com. IN AAAA 2001:db8::1
CNAME	Alias to another domain (not IP)	www.example.com. IN CNAME example.globalcdn.com.
Alias	AWS-only alias to ELB, CloudFront, S3, etc. Works at root domain.	example.com. IN A Alias abc123.cloudfront.net
MX	Mail routing	example.com. IN MX 10 mail1.google.com.
TXT	Metadata (SPF, DKIM, domain verification)	example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
NS	Authoritative nameservers for zone	example.com. IN NS ns1.dnsprovider.com.
SOA	Zone info (serial, refresh, retry)	example.com. IN SOA ns1 hostmaster 2025010101 3600 1800 1209600 86400
PTR	Reverse DNS (IP → domain)	1.2.0.192.in-addr.arpa. IN PTR example.com.
CAA	Restricts which CAs can issue certificates	example.com. IN CAA 0 issue "letsencrypt.org"
SRV	Service-specific record (e.g., SIP, LDAP)	_sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.

6.2 Apex (Naked) Domains

• A naked domain = root (e.g., example.com) without subdomain.
• CNAMEs cannot be used at the root.
• In AWS → use Alias records to map apex domains to AWS resources (e.g., ELB, CloudFront).
• For non-apex domains (www.example.com), use CNAME.

6.3 Route 53 Routing Policies

Routing Policy	Purpose	Example
Simple	Single record → single resource	example.com → 192.0.2.1
Weighted	Split traffic by % between resources	80% → server1, 20% → server2
Latency	Route to lowest-latency region	US users → us-east-1, EU users → eu-west-1
Failover	Primary resource + backup on failure	Main site → backup site
Geolocation	Route by user’s country/region	US → 192.0.2.1, UK → 192.0.2.2
Geoproximity	Route by distance + optional bias	East Coast users → NJ DC, West Coast → CA DC
Multi-Value	Return multiple IPs for LB/HA	example.com → 192.0.2 .1, 192.0.2.2
IP-based	Route by client IP blocks	Corp IP range → private endpoint

6.4 DNS Resolution Flow

1. You create a Hosted Zone in Route 53 for your domain (example.com).
2. Route 53 assigns 4 authoritative name servers (NS records) for the domain.
3. You add DNS records (A, CNAME, MX, TXT, etc.) inside the hosted zone.
4. When a client queries example.com, the DNS resolver follows the chain:
   • Root → TLD → Route 53 authoritative NS (Amazon-managed).
5. Route 53 authoritative servers return the DNS record (e.g., A record with an IP).
6. Resolver caches and returns result to user → user connects to the target resource.

🌐 DNS Resolution – Query to Answer

6.5 DNSSEC Overview

DNSSEC (Domain Name System Security Extensions) adds a security layer to DNS. Normal DNS just maps names → IPs, but DNSSEC ensures responses are authentic and untampered by digitally signing DNS records.

🔑 Why we need DNSSEC: Without it, DNS is vulnerable to cache poisoning, spoofing, and MITM attacks.
✅ DNSSEC prevents this by providing a cryptographic chain of trust from the Root → TLD → Authoritative server.
⚠️ Note: DNSSEC does not encrypt traffic (unlike HTTPS). It only guarantees authenticity + integrity, not confidentiality.

6.5.1 Key Concepts

• Digital Signatures:
  • Authoritative servers sign records with a private key.
  • Resolvers validate them with the public key.
• DNSSEC Records:
  • DNSKEY → Public key of a DNS zone.
  • DS (Delegation Signer) → Stored in the parent zone, links child zone’s key.
  • RRSIG → Digital signature attached to DNS records.
• Chain of Trust:
  • Starts at the Root zone (trust anchor),
  • Delegates to TLD (.com),
  • Passes down to the Authoritative DNS (e.g., Route 53).

6.5.2 Roles and Responsibilities

• Root & TLD Operators (ICANN, Verisign, etc.) → Maintain signed root/TLD zones.
• Domain Owners → Enable DNSSEC in their DNS service (e.g., Route 53), publish DS record at registrar.
• Resolvers (e.g., ISP, Google DNS, Cloudflare) → Validate signatures automatically.
• End Users → Do nothing; they just benefit from secure DNS responses.

6.5.3 DNSSEC Resolution Flow

🔐 DNSSEC Resolution – Validating DNS records with chain of trust

6.6 Route 53 Resolver and Endpoints

By default, every VPC has an Amazon-managed DNS resolver at the reserved IP VPC-CIDR+.2 (e.g., 10.0.0.2).

• Accessible from all subnets in the VPC.
• Resolves public DNS records and private hosted zones linked to the VPC.
• No setup required — it’s built-in.

👉 Limitation: The default .2 resolver only works inside the VPC. It cannot be queried from on-premises networks or other VPCs directly.

To integrate DNS across hybrid or multi-VPC environments, AWS provides Route 53 Resolver Endpoints:

• Inbound Endpoint:
  • On-premises DNS servers → query AWS .2 resolver via an ENI in the VPC.
• Outbound Endpoint:
  • VPC resources → forward queries to on-premises DNS servers.

These endpoints solve the DNS boundary problem where VPC and on-prem DNS could not previously resolve each other.

🔄 Route 53 Resolver – Inbound & Outbound Endpoint Flow

---

7. IPv6 in AWS

AWS VPCs support dual-stack networking (IPv4 + IPv6). Unlike IPv4, IPv6 is globally unique and publicly routable, which removes the need for NAT but requires careful access control.

7.1 Key Points

• CIDR Allocation:
  • Each VPC gets an Amazon-provided /56 IPv6 block.
  • Each subnet automatically receives a /64 range (one per subnet, up to 256 subnets per VPC).
• Routing:
  • IPv6 routes appear separately in route tables alongside IPv4 routes.
  • Works with the same routing constructs (IGW, TGW, VGW, etc.), but must be explicitly added.
• Gateways:
  • Internet Gateway (IGW) → allows bidirectional IPv4 + IPv6.
  • Egress-Only IGW → outbound-only for IPv6 (blocks unsolicited inbound).
• Service Support:
  • Must be enabled per VPC, subnet, and ENI.
  • Not all AWS services support IPv6 (check service docs before enabling).
• No NAT Needed:
  • NAT Gateway is not required for IPv6 since all IPv6 addresses are globally routable. For IPv4, a NAT Gateway is needed because of address space limitations and the use of address masquerading (NAT) to share public IPs.
  • Security relies on Security Groups / NACLs instead of NAT hiding.

7.2 Considerations

• Plan dual-stack carefully: some workloads may remain IPv4-only.
• Use Egress-Only IGW to protect IPv6 workloads from unsolicited inbound traffic.
• Validate which AWS services support IPv6 before rollout (e.g., some managed services may lag behind).
• IPv6 helps with address exhaustion but introduces new security + monitoring challenges.

⚡ Takeaway:
IPv6 in AWS = globally routable addresses, no NAT, /56 per VPC, /64 per subnet, explicit routing, and egress-only IGW for outbound-only control.