Skip to content

SYSTEM Cited by 6 sources

Amazon Route 53

Amazon Route 53 is AWS's managed DNS service. In the context of this wiki, the feature of interest is weighted routing records: multiple records for the same name with per-record integer weights, letting Route 53 distribute resolutions across targets proportional to the weights. Adjusting weights over time shifts traffic gradually, which is the canonical DNS-level implementation of the blue/green migration pattern.

Stub page.

Role in blue/green cutovers

The sources/2025-01-18-aws-app-mesh-discontinuation-service-connect-migration post names three edge-level weighted-traffic mechanisms for App Mesh → Service Connect migration:

  1. Route 53 weighted routing records — DNS-level; simplest, widest compatibility, but slow to propagate (TTL-bound cache invalidation).
  2. CloudFront continuous deployment — edge-CDN-level; faster propagation but only covers CloudFront-fronted traffic.
  3. ALB multi-target-group routing — single-ALB-level; tightest control but only within one load balancer's scope.

Route 53 weighted records are the default choice for service-mesh blue/green because they're the only option that works across disjoint mesh environments with no shared networking.

Private hosted zones as a DR indirection layer

Beyond public DNS + weighted routing, Route 53 private hosted zones are the canonical substrate for DR configuration translation: on failover, create a private hosted zone in the recovered VPC that owns the old endpoint name, add a CNAME pointing to the new (restored) endpoint. Applications that still resolve the old name bind transparently to the new resource without config-rewrite + redeploy.

Named in the 2026-03-31 AWS DR post as Arpio's mechanism for keeping application→restored-database connectivity working after cross-Region / cross-account recovery: "Arpio will also create an Amazon Route 53 private hosted zone in the recovered VPC, mapping the early endpoint to the new one using a CNAME record. This way, applications still using the early name still connect to the newly recovered database." (Source: sources/2026-03-31-aws-streamlining-access-to-dr-capabilities)

Seen in

  • sources/2026-09-09-aws-validating-multi-region-dr-for-terraform-enterprise-with-aws-fis — canonical health-check-based failover-routing (data-plane) instance. In Athenahealth's multi-Region Terraform Enterprise DR, a Route 53 failover routing policy with a health check probing TFE's /_health_check endpoint from Route 53's globally-distributed checker fleet detects the unhealthy primary and routes to the DR NLB — "in the Route 53 data plane, with no record modifications at failover time." Explicitly contrasts with the anti-pattern of modifying Route 53 records at failover time, which depends on the Route 53 control plane (single-Region) — a static-stability violation. Alias records to the ELB target use a 60 s TTL, so clients re-resolve to DR within ~1 minute. Detection is independent of the primary Region because the checker fleet is external. This is the failover-routing Route 53 policy — distinct from the weighted-routing and private-hosted-zone uses documented above.
  • sources/2026-05-12-aws-building-hybrid-multi-tenant-architecture-for-stateful-services — canonical wiki instance of Route 53 weighted routing used for horizontal scale-out within a tier, not just migration-phase blue/green. AWS's hybrid multi-tenant ad-serving architecture uses one Route 53 weighted record per infra group (per ALB) and adds records as the tier scales horizontally (add infra group within a cell → new weighted record; add cell (new AWS account) → new weighted record). The tier endpoint (tier-1.us-east-1.example.com) remains stable for tenants through every scaling event — first canonical wiki instance of Route 53 weighted routing as the tier-level traffic- distribution primitive absorbing two horizontal-scale-out levers transparently (infra-group and cell). Datum: up to 10,000 weighted records per hosted zone → practically unbounded for this use case. See tier-cell-infra-group-hierarchy and hybrid-multi-tenant-architecture.
  • sources/2025-01-18-aws-app-mesh-discontinuation-service-connect-migration — weighted records named as the primary traffic-shifting mechanism for cross-mesh migration.
  • sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty — named as a per-partition DNS zone in the sovereign-failover topology ("separate Route 53 DNS zones" per partition); no cross-partition Route 53 health checks.
  • sources/2026-03-31-aws-streamlining-access-to-dr-capabilities — private hosted zone CNAME as the canonical DR config-translation indirection mechanism; the named Arpio implementation for application→restored-database endpoint mapping.
  • sources/2026-07-15-aws-bitdrift-scaled-121-million-grpc-connections-cloudfront — canonical Multi-Value Answer routing production case. Weighted routing (1 IP/response) caused all CloudFront edge nodes to resolve to a single NLB per TTL window, creating a thundering herd that produced 80% 5xx at 121M concurrent gRPC connections. Switching to Multi-Value Answer (up to 8 IPs/response with per-record health checks) → zero errors. The decisive lesson: Weighted routing is for traffic-proportion control (canaries, migrations); Multi-Value Answer is for origin-distribution with persistent-connection protocols at CDN scale. See dns-ttl-concentration, dns-routing-policy-at-scale, and multi-value-answer-routing-for-origin-distribution.

Seen in

Last updated · 766 distilled / 2,225 read