beginnerintermediateadvanced

AWS · DNS and Network Connectivity

DNS and Network Connectivity

A name has to resolve to the right answer, and that answer still has to be network-reachable

Alias beats CNAME at the apexfree, apex-capable, auto-managed TTL
Public vs private zonessame name, different answer, by design
Each policy answers a different questionproportion, speed, health, or location
Peering does not transitTransit Gateway is the hub that replaces a peering mesh

1.Route 53 vocabulary: zones, records, and TTL

A hosted zone holds the DNS records for a domain. An alias record is Route 53's own extension that points directly at an AWS resource (like a load balancer) without the extra lookup a CNAME needs — and unlike a CNAME, an alias record can be used at a zone apex.

Key features

A hosted zone is a container for the DNS records of one domain
A record maps a name to a value: A, AAAA, CNAME, MX, TXT, and others
An alias record is Route 53-specific — points at an AWS resource, works at the zone apex, no extra charge
A CNAME cannot be used at a zone apex (the bare domain); an alias record can
TTL controls how long a resolver caches an answer before asking again

Alias record vs CNAME

Alias record vs CNAME
Property	Alias record	CNAME
Works at zone apex (example.com)	Yes	No — DNS spec disallows it
Query charge	Free for AWS resource targets	Standard query charge
Target	AWS resources (ALB, CloudFront, S3, ...)	Any hostname
TTL	Managed automatically by Route 53	Set explicitly by you

Alias record vs CNAME, at the zone apex

Alias record

Works at the zone apex (example.com)
Free for AWS resource targets
TTL managed automatically

CNAME

Cannot be used at the zone apex
Standard query charge
TTL set explicitly by you

Command

text

example.com  →  ALIAS  →  my-alb-1234.eu-west-1.elb.amazonaws.com   (apex, free, auto TTL)
www.example.com → CNAME → example.herokuapp.com   (not apex, standard billing)

An alias record is a Route 53-specific A/AAAA record that works at the zone apex, costs nothing extra for AWS targets, and manages its own TTL — a CNAME cannot do any of those three things.

2.Public vs private hosted zones

A public hosted zone answers DNS queries from anywhere on the internet. A private hosted zone only answers queries from the VPCs it is explicitly associated with — the same domain name can resolve differently inside a VPC than it does publicly.

Key features

A public hosted zone is reachable from anywhere and requires no VPC association
A private hosted zone must be explicitly associated with one or more VPCs
The same domain can have both a public and a private hosted zone, resolving differently by context
A private hosted zone is useful for internal service discovery that should never be publicly resolvable
Split-horizon DNS is the general term for this pattern — same name, different answer depending on where you ask

Command

bash

aws route53 create-hosted-zone --name internal.example.com \
  --vpc VPCRegion=eu-west-1,VPCId=vpc-0abc123 --hosted-zone-config PrivateZone=true

A private hosted zone only answers queries from its explicitly associated VPCs — the same domain can have a public zone and a private zone resolving to different answers, entirely by design.

3.Route 53 routing policies

A routing policy decides which of possibly several records Route 53 hands back for the same name — simple returns the one it has, and the others each pick based on a different signal: proportion, latency, health, or the querier's location.

Key features

Simple: one record, no logic — the default when there is nothing to choose between
Weighted: proportional traffic split, e.g. 90/10 for a canary release
Latency-based: returns the record in the Region with the lowest measured latency to the querier
Failover: active/passive — the primary answers unless its health check fails
Geolocation: routes by the querier's geographic location, e.g. serving country-specific content

Route 53 routing policies and what decides the answer

Route 53 routing policies and what decides the answer
Policy	Decided by
Simple	Nothing — a single fixed answer
Weighted	A proportion you assign per record
Latency-based	Measured latency from the querier to each Region
Failover	Health check status — passive record only answers if primary is unhealthy
Geolocation	The querier's geographic location
Multivalue answer	Random selection among up to 8 healthy records

What signal each policy answers on

health/location awareno health awareness

fixed rulereacts to live signal

Simple: a single fixed answer
Weighted: a proportion you assign
Latency-based: measured latency to each Region
Geolocation: the querier's location
Failover: health check status

Command

text

Same name, multiple records, each tagged with a routing policy + SetIdentifier → Route 53 picks one to answer with

Each routing policy answers a different question — simple has nothing to decide, weighted uses a proportion, latency-based uses measured speed, failover uses health, geolocation uses the querier's location.

4.Route 53 Resolver and private DNS

Every VPC has a built-in Resolver (at the base of the VPC's CIDR range plus two) that answers DNS queries for both public names and any private hosted zones associated with that VPC — Resolver endpoints extend that same resolution to and from on-premises networks.

Key features

The VPC Resolver lives at the base of the VPC's CIDR range + 2 (e.g. 10.0.0.2 for 10.0.0.0/16)
It answers both public DNS and any private hosted zones associated with that VPC, from one address
A Resolver outbound endpoint forwards specific domains to on-premises DNS servers
A Resolver inbound endpoint lets on-premises systems query VPC resources' DNS
Conditional forwarding rules decide which queries go where, per domain

Command

text

VPC 10.0.0.0/16 → Resolver at 10.0.0.2
Outbound endpoint: *.corp.internal → forwarded to on-prem DNS server
Inbound endpoint:  on-prem → can query *.internal.example.com in this VPC

The VPC Resolver (at CIDR base + 2) handles public DNS and this VPC's private hosted zones automatically — Resolver endpoints and conditional forwarding rules are what extend resolution to and from on-premises DNS.

5.VPC peering, Transit Gateway, VPN, and Direct Connect

These four connect networks together, but at different scales: peering is one VPC to another, Transit Gateway is a hub for many VPCs and on-prem links at once, VPN goes over the public internet, and Direct Connect is a dedicated private line to AWS.

Key features

VPC peering: direct, non-transitive connection between exactly two VPCs
Transit Gateway: a Regional hub connecting many VPCs and on-prem networks at once
Site-to-Site VPN: encrypted tunnels over the public internet, quick to set up
Direct Connect: a dedicated private network connection to AWS, not over the public internet
Peering does not transit — VPC A peered with B and B peered with C does not let A reach C

Connectivity models and what they scale to

Connectivity models and what they scale to
Model	Connects	Transitive?
VPC peering	Exactly two VPCs	No — each pair needs its own peering connection
Transit Gateway	Many VPCs + on-prem, one hub	Yes — through the gateway
Site-to-Site VPN	AWS to on-premises, over the internet	N/A — one connection to one on-prem network
Direct Connect	AWS to on-premises, dedicated private line	N/A — one physical/logical connection

Peering vs Transit Gateway at scale

VPC peering (few VPCs)

Direct connection per pair
Non-transitive — no hub
N pairs of VPCs need up to N(N−1)/2 connections

Transit Gateway (many VPCs)

One hub, every VPC attaches once
Transitive through the gateway
On-premises networks attach the same way

Command

text

2-3 VPCs, simple    → VPC peering
Many VPCs + on-prem  → Transit Gateway
Quick, over internet → Site-to-Site VPN
Dedicated, low-latency, high-bandwidth → Direct Connect

Peering is a direct, non-transitive link between exactly two VPCs — Transit Gateway is the hub that replaces a growing mesh of peering connections; VPN is quick and over the internet, Direct Connect is dedicated and private.

Spotted a mistake on this page? Tell us.

Read Sheet