Route 53 provides authoritative DNS, domain registration, routing policies, and health checks. CloudFront delivers content through edge locations and shields HTTP origins from direct global traffic.
DNS decides which endpoint a name resolves to; CloudFront decides how viewer requests are cached, secured, and forwarded to an origin.
A typical web path is viewer to Route 53 alias, CloudFront distribution, and then a private S3 origin, load balancer, API endpoint, or custom server.
Use alias records for supported AWS endpoints and choose simple, weighted, latency, failover, or geolocation routing according to the traffic decision you actually need.
A cache behavior selects an origin, allowed methods, viewer protocol policy, and cache/origin request policies. Include only headers, cookies, and query strings that truly change the response.
Attach an ACM certificate in us-east-1 for a CloudFront custom domain. Require HTTPS from viewers and protect S3 with origin access control or restrict a custom origin so users cannot bypass CloudFront controls.
DNS changes depend on resolver caches, while CloudFront configuration deployments take time to reach the edge. Use dig, response headers, access logs, and origin logs to identify which layer served an unexpected response.
A public hosted zone contains authoritative records for internet DNS, while a private hosted zone answers inside associated VPCs through Route 53 Resolver. Creating a hosted zone does not automatically delegate a domain registered elsewhere. The parent zone or registrar must publish the correct name-server records, and duplicate hosted zones can leave operators editing one that receives no traffic.
Use separate public and private records deliberately when split-horizon DNS is required. A private zone association controls which VPCs can resolve it, while resolver rules and endpoints extend resolution to connected networks. Verify the answer from the same network context as the failing client because a laptop, VPC workload, and public resolver may see different data.
Protect domain registration, registrar locks, contact email, DNSSEC decisions, and hosted-zone changes as critical control-plane assets. Losing a compute instance affects one service; losing authoritative DNS can redirect or remove many services at once.
A record name and type must match the client need: A and AAAA return addresses, CNAME points one name to another under DNS rules, and service records or text records carry other protocols and verification data. Route 53 alias records can target supported AWS resources and can be used at the zone apex where a CNAME is not allowed.
TTL controls how long recursive resolvers may cache an answer. Lower it well before a planned migration, wait for old caches to age out, then change the record. A low TTL increases query volume and does not guarantee instant client change because operating systems, applications, and intermediaries may cache separately.
For every record change, capture the old value, new value, owner, rollout time, rollback rule, and resolver evidence. Avoid depending on manually edited records for ephemeral application endpoints; have infrastructure automation create aliases to stable load balancer or CloudFront names.
Simple routing returns the configured value without traffic steering. Weighted routing distributes DNS answers by configured weights and is useful for controlled migration, but it is not a request-perfect percentage. Latency routing selects from measured AWS Region latency, while geolocation and geoproximity make different location-based decisions. Multivalue answers can expose several healthy records.
Failover routing combines primary and secondary records with health evaluation. A health check must test the real dependency needed for service, but it should not create a circular dependency on the same DNS name. Alias targets can use target health for supported resources. Decide what happens when every endpoint is unhealthy instead of assuming DNS can repair an unavailable application.
DNS steering acts at resolver-cache granularity and cannot drain individual connections. For precise per-request shifting, use load balancer, CloudFront, application, or service-mesh controls. Test policy behavior from multiple resolvers and keep rollback records ready before moving user traffic.
CloudFront maps a viewer request to a cache behavior and origin, then builds a cache key from configured path, query, header, and cookie values. Only include values that truly change the response. Including every viewer field fragments the cache; omitting a response-varying identity or language field can serve the wrong content.
Cache policy controls the cache key and cache-facing TTL behavior. Origin request policy controls additional values forwarded to the origin without necessarily adding them to the key. Response headers policy can add security and CORS headers at the edge. Use managed policies only after checking that their included fields match the application contract.
Understand minimum, default, and maximum TTL together with origin cache headers. Personalized and authenticated responses need an explicit no-cache or correctly varied design. Test two users, two query variants, and an uncached error path to prove there is no cross-user content leakage.
Require HTTPS for viewers and use a certificate whose alternate names cover every custom domain. CloudFront certificates are managed through ACM in the required Region for the service. Choose a supported security policy and redirect or reject HTTP according to the application requirement.
For an S3 origin, use origin access control with a bucket policy that permits the intended distribution, leaving the bucket private. For a custom origin, restrict direct access through security controls or a secret origin-verification mechanism appropriate to the service so users cannot bypass WAF, signed access, or edge policy.
AWS WAF filters malicious or unwanted requests, while signed URLs and signed cookies control access to private content. They solve different problems. Keep signing keys protected, use bounded expiration, and validate that cached authorization behavior cannot expose one viewers content to another.
Use content-addressed or versioned filenames for static releases so a new deployment creates a new cache key. Invalidation is useful for exceptional correction but costs time and request capacity and does not fix a poor versioning strategy. HTML entry points can have shorter cache behavior while immutable assets remain long-lived.
When a response is wrong, record the viewer request, DNS answer, distribution domain, behavior path, cache status and age headers, edge request ID, origin response, and deployment time. Distinguish DNS cache, CloudFront cache, browser cache, origin logic, and an error response generated at the edge. Each layer has different evidence and recovery.
Monitor viewer error rate, origin error rate, cache hit ratio, bytes, latency, WAF actions, and origin health. Logs may contain sensitive URLs and cookies, so select fields, storage, access, and retention carefully. Test an origin failure and confirm whether cached content, origin failover, or an error response matches the intended design.
DNS and CDN lessons become practical when learners can see both sides: traffic routing through Route 53 and cache refresh through CloudFront.
aws cloudfront create-invalidation \
--distribution-id E123456789ABC \
--paths "/*"
aws route53 change-resource-record-sets \
--hosted-zone-id Z123456ABCDEFG \
--change-batch file://alias-record.jsonA static site moves to a new private origin while its public hostname must remain stable.
Constraints: DNS TTL is 300 seconds, CloudFront uses an origin access control, and cached objects may outlive the deployment.
Decision: Add and test the new origin, switch the behavior, invalidate only changed paths, then change DNS only if the distribution hostname changes.
Verification: Two regions resolve the expected alias, CloudFront returns the new version, and direct origin access remains denied.
Failure test: Restore the prior behavior and prove rollback does not require waiting for an unrelated DNS cache.Expected evidence: Two regions resolve the expected alias, CloudFront returns the new version, and direct origin access remains denied.Explore 500+ free tutorials across 20+ languages and frameworks.