DNS and Network Connectivity

What we're doing: Compare an alias record to a CNAME for the exact same target, at the zone apex.

{
  "Name": "example.com",
  "Type": "A",
  "AliasTarget": {
    "HostedZoneId": "Z32O12XQLNTSW2",
    "DNSName": "my-alb-1234.eu-west-1.elb.amazonaws.com",
    "EvaluateTargetHealth": true
  }
}

3

Type A, not CNAME — an alias record is technically an A/AAAA record with an AliasTarget, which is exactly what makes apex usage legal.

5

EvaluateTargetHealth ties this record's answer to the load balancer's own health, without a separate Route 53 health check needed for this common case.

Why this works: A CNAME at "example.com" (no subdomain) violates the DNS specification, because a zone apex must also be able to hold other record types like MX — an alias record sidesteps that limit entirely by being a specially-flagged A record instead.

What we're doing: See the same domain name resolve differently depending on whether the query comes from inside the associated VPC or from the public internet.

# From inside the associated VPC
$ dig db.internal.example.com
db.internal.example.com. 300 IN A 10.0.4.12   # private hosted zone answer

# From the public internet
$ dig db.internal.example.com
;; connection timed out; no servers could be reached   # not publicly resolvable at all

2

Only the VPC associated with the private hosted zone can resolve this name at all.

5

From outside that VPC, the name simply does not resolve — there is no public record for it, by design.

Why this works: This is exactly the intended behavior for internal service names — a private hosted zone never leaks internal naming or addressing to the public internet, because it structurally cannot answer queries from outside its associated VPCs.

What we're doing: See a weighted routing setup for a canary release: 90% of traffic to the stable version, 10% to the new one.

[
  { "Name": "api.example.com", "SetIdentifier": "stable",
    "Weight": 90, "AliasTarget": { "DNSName": "stable-alb..." } },
  { "Name": "api.example.com", "SetIdentifier": "canary",
    "Weight": 10, "AliasTarget": { "DNSName": "canary-alb..." } }
]

3

Weight 90 out of a total of 100 (90+10) — roughly 90% of queries resolve to the stable target.

6

The remaining 10% resolve to the canary target — enough real traffic to validate it without risking the majority.

Why this works: Weighted routing works at the DNS layer, before any request reaches either target — a client that resolves the canary answer sends 100% of its own traffic there for as long as that answer is cached (its TTL), which is why canary rollouts often pair a short TTL with weighted routing.

What we're doing: See a conditional forwarding rule that sends only a specific domain's queries on-premises, letting everything else resolve normally through the VPC Resolver.

{
  "DomainName": "corp.internal.",
  "TargetIps": [{ "Ip": "192.0.2.10", "Port": 53 }],
  "RuleType": "FORWARD"
}

2

This rule only applies to queries for corp.internal and its subdomains — every other query keeps using the VPC Resolver's normal path.

3

The matching queries are forwarded to a specific on-premises DNS server IP, reached over Direct Connect or VPN.

Why this works: Conditional forwarding scopes hybrid DNS to exactly the domains that need it, rather than routing every query through the on-premises link — public AWS service names and any private hosted zone records keep resolving locally through the VPC Resolver, unaffected.

What we're doing: See why peering does not scale the way a hub does, once a third VPC joins.

# 3 VPCs, fully connected via peering — needs 3 separate connections
vpc-a <-peer-> vpc-b
vpc-a <-peer-> vpc-c
vpc-b <-peer-> vpc-c

# 3 VPCs via Transit Gateway — needs 3 attachments, not 3 connections,
# and a 4th VPC needs only 1 more attachment, not 3 more peering links
vpc-a, vpc-b, vpc-c → attached to tgw-0xyz

2

Peering is pairwise — vpc-a and vpc-c need their own direct connection even though both already peer with vpc-b.

8

Every VPC attaches to the same hub once — the number of connections needed grows linearly with VPC count, not quadratically.

Why this works: Peering's non-transitivity is fine for two or three VPCs but becomes an operational burden past that — Transit Gateway exists specifically to replace a growing mesh of pairwise peering connections with one hub every network attaches to exactly once.