Chapter 3. Global DNS and Edge Networks (Advanced: Route 53 & Cloudflare)

Learning objectives

• Distinguish the DNS hierarchy and core Route 53 record types (A, AAAA, CNAME, Alias, TXT, CAA), and explain why standard CNAME records are forbidden at the root domain (Zone Apex) and how Alias records solve that constraint.
• Combine Route 53 routing policies (Simple, Weighted, Latency, and Failover) with health checks to design canary rollouts and automated disaster recovery failover.
• Explain why zero-downtime domain or server migrations require lowering the DNS TTL at least one full old-TTL window before the cutover timestamp.
• Contrast Cloudflare DNS-only (grey cloud) and proxied (orange cloud) modes, explain why the Flexible SSL/TLS mode causes infinite redirect loops or plaintext exposure, and configure Full (Strict) with Origin CA certificates.
• Design WAF, rate limiting, and bot control rules with targeted exceptions and cryptographic HMAC signature verification so legitimate payment and authentication webhooks are never blocked by browser challenges.
• Configure CDN cache rules to prevent cache poisoning and response buffering on personalized API responses (/api/*, Authorization, Set-Cookie) and real-time LLM streams (text/event-stream).
• Combine Cloudflare Workers, Queues, and AI Gateway (observability, caching, rate limiting, and multi-provider fallbacks) into a resilient edge architecture for AI applications.

Introduction

Your application code passes every test and your database is healthy, yet users see ERR_TOO_MANY_REDIRECTS in their browsers; or you migrate your application to a new cloud server and half your customers keep hitting the decommissioned old server for the next six hours; or—worst of all—a user signs in and sees a complete stranger's account profile and private AI chat history rendered on their screen. You can read through your application code for days without finding a bug, because the culprit lives outside your codebase: in your DNS and edge network (CDN and reverse proxy) configuration.

From the instant a user types https://aidan.agentcat.app into their browser address bar until your application server returns its first byte, the request first queries authoritative DNS (Amazon Route 53 or Cloudflare DNS) to resolve an IP address, and then passes through a global edge proxy (Cloudflare) that terminates the TLS handshake, evaluates WAF rules, checks the edge cache, and executes edge Workers before finally reaching your Origin server. In AI services, a second edge path flows in the opposite direction: outbound requests from your backend to external LLM providers (OpenAI, Anthropic, Google) pass through an AI Gateway.

This chapter covers the nine essential architectural principles every senior infrastructure engineer must master—spanning from the internet's address book in Route 53 to proxy modes, TLS security, caching, serverless Workers, Queues, and AI Gateway across Cloudflare's global edge network.

Key concepts

The DNS resolution path and core record types: Why you cannot put a CNAME at the Zone Apex

The Domain Name System (DNS) is a hierarchical, distributed database that translates human-readable domain names (aidan.agentcat.app) into IP addresses (192.0.2.1 or 2001:db8::1) that network routers understand. When a user's device (stub resolver) asks an ISP or public Recursive Resolver (such as 1.1.1.1 or 8.8.8.8) for a domain, the recursive resolver walks the hierarchy—from a Root (.) nameserver to the Top-Level Domain (.app) nameserver and finally to the domain's Authoritative Nameserver (such as Route 53 or Cloudflare)—to fetch the final record, and then caches that answer for the duration of the record's TTL (Time To Live, measured in seconds).

The table below summarizes the core DNS record types you work with in production.

The single most frequently tested DNS principle on infrastructure exams is why standard CNAME records are forbidden at the root domain (Zone Apex, such as example.com) under RFC 1034 and RFC 2181.

According to the DNS specification, if a node in the DNS tree has a CNAME record, it is not allowed to have any other resource records of any type alongside that CNAME. However, the root of a DNS zone (the Zone Apex, example.com) must always contain an SOA (Start of Authority) record and NS (Name Server) records that define the zone itself. Because a CNAME cannot coexist with SOA and NS records, you can freely place a standard CNAME on a subdomain like www.example.com or api.example.com, but placing a standard CNAME on example.com violates the DNS protocol and breaks zone resolution(including MX email routing).

Cloud load balancers (such as AWS ALB) and CDNs (such as CloudFront or Vercel) provide dynamic hostnames rather than fixed IP addresses—so how do you point your root domain (example.com) to them if CNAME is illegal there?

• Amazon Route 53 Alias records: A Route 53-specific extension. You configure an Alias record at example.com pointing to your ALB, CloudFront distribution, S3 website endpoint, or another record in the same hosted zone. When an external DNS resolver queries Route 53 for the A record of example.com, Route 53 internally looks up the target's current IP addresses and returns a standard A or AAAA response. This satisfies the DNS specification at the Zone Apex, tracks IP changes automatically, and incurs zero Route 53 query charges when pointing to eligible AWS resources.
• Cloudflare CNAME Flattening: When you enter a CNAME at the Zone Apex in Cloudflare DNS, Cloudflare's authoritative nameservers automatically follow the CNAME chain behind the scenes and return the final resolved A or AAAA IP addresses to querying resolvers.

Route 53 routing policies and health checks for zero-downtime traffic control

Rather than mapping a hostname to a single static IP, Route 53 provides Routing Policies that dynamically steer DNS responses based on traffic weights, network latency, geographic location, or endpoint health.

A critical architectural detail to remember is that a routing policy by itself does not know whether your target server has crashed. For Weighted, Latency, or Failover routing to stop sending users to a dead server, you must create a Route 53 Health Check and attach it to the record (or enable Evaluate Target Health on an Alias record).

How you implement your application's health check endpoint (/api/health) matters just as much. If /api/health is a shallow check that blindly returns 200 OK without checking whether the database connection pool is alive, Route 53 will keep routing traffic to an instance whose database connection is dead and throwing 500 errors on every real user request. Conversely, if /api/health triggers an expensive live LLM API completion every few seconds when global health checkers ping it, your token bill will skyrocket. A well-designed health check verifies local process readiness and lightweight critical dependencies (such as running SELECT 1 against the database pool) and returns 503 Service Unavailable when the node cannot serve traffic.

Zero-downtime domain and server migrations: The law of lowering TTLs in advance

Let's examine one of the most common operational blunders during a server migration. Suppose a team has been running their production A record (pointing to old IP 198.51.100.10) with a standard TTL of 86,400 seconds (24 hours). They schedule a migration to a new server (IP 203.0.113.50) for Sunday at 02:00 a.m. At 02:00 a.m. sharp on Sunday, an engineer logs into the DNS console, lowers the TTL to 60 seconds, changes the IP address to the new server at the same time, and shuts down the old server at 02:10 a.m.

What happens for the rest of Sunday? Over half of the company's customers cannot reach the site at all! Why didn't lowering the TTL to 60 seconds at 02:00 a.m. make the cutover take effect in 60 seconds?

Because ISP and public recursive DNS resolvers around the world that queried the domain at 01:50 a.m. cached the old IP (198.51.100.10) along with the old TTL instructions: "Keep serving this IP from cache for the next 24 hours (86,400 seconds) without asking the authoritative nameserver again!" Until that 24-hour cached timer expires on each recursive resolver, those resolvers never even contact your authoritative nameserver—so they have no way of knowing that you changed the IP or lowered the TTL at 02:00 a.m.

A true zero-downtime DNS migration must therefore follow a strict five-stage timeline:

1. Advance preparation (at least 24–48 hours before cutover—strictly longer than the previous TTL): Keep the record pointing to the old IP address, and lower only the TTL to a short value (such as 60 to 300 seconds).
2. Wait for old caches to expire: If the previous TTL was 24 hours (86,400 seconds), wait at least a full 24 hours. Once that window passes, every recursive resolver on the internet has expired the old 24-hour entry and is now refreshing the record every 60–300 seconds.
3. Run old and new environments in parallel: Bring up the new server environment and verify that both the old server and the new server can safely handle live requests simultaneously (for example, talking to the same primary database).
4. Execute the DNS cutover: Update the DNS record value to point to the new server IP (or new target hostname). Because every resolver is already honoring the 60–300 second TTL, global traffic shifts to the new server within 1 to 5 minutes.
5. Observe traffic drain, decommission the old server, and restore the TTL: Watch the access logs on the old server until incoming requests drop to zero, safely decommission the old server, and finally raise the DNS TTL back to a normal operational value (such as 3,600 seconds) to reduce DNS resolution latency and query volume.

Cloudflare proxied (orange cloud) vs. DNS-only (grey cloud) modes and hiding the origin IP

When you manage a domain in Cloudflare, every DNS record has a cloud toggle switch next to it. Flipping that switch changes the entire network path of your traffic.

When operating with the orange cloud (Proxied) enabled, you must watch out for two practical pitfalls:

1. Third-party CNAME verification records and non-HTTP protocols often require Grey Cloud (DNS Only). When an external email provider (verifying a DKIM CNAME) or an application platform (such as Vercel or AWS Certificate Manager verifying a domain validation CNAME) queries DNS to check whether your CNAME points to their target string, leaving the orange cloud turned on causes Cloudflare to hide the CNAME and respond with Cloudflare A/AAAA IP addresses instead—causing the external provider's verification check to fail. Furthermore, Cloudflare's standard orange-cloud proxy only forwards HTTP and HTTPS traffic (on supported ports such as 80 and 443), so attempting to run raw SSH (port 22) or PostgreSQL (port 5432) directly through a standard orange-cloud hostname will fail (use Cloudflare Tunnel or Spectrum instead, as covered in Chapter 4).
2. Turning on the orange cloud does NOT protect your origin server if its firewall still allows 0.0.0.0/0! If an attacker discovers your origin server's real IP address via historical DNS databases (such as SecurityTrails), a misconfigured DNS-only subdomain, or an IPv4 port scan, they can send HTTP requests with a Host: app.example.com header directly to your origin IP—completely bypassing Cloudflare's WAF and rate limiting. To close this loophole, you must lock down the origin firewall so it accepts port 443 traffic only from Cloudflare's published edge IP ranges, enforce Authenticated Origin Pulls (mTLS client certificate verification), or remove all public inbound ports using Cloudflare Tunnel.

SSL/TLS encryption modes: Why you must never use Flexible and why Full (Strict) is the standard

When Cloudflare's proxy (orange cloud) sits in front of your site, every HTTPS connection is split into two distinct legs: Leg 1 is [User Browser ↔ Cloudflare Edge], and Leg 2 is [Cloudflare Edge ↔ Your Origin Server]. Cloudflare's SSL/TLS encryption mode setting controls how Leg 2 (Edge ↔ Origin) is connected.

One of the most famous incidents on both infrastructure exams and real-world on-call shifts is the infinite redirect loop (ERR_TOO_MANY_REDIRECTS) caused by Cloudflare's Flexible SSL mode.

Why does that loop happen? Trace the steps:

1. A user opens https://app.example.com in their browser over HTTPS.
2. Because Cloudflare is set to Flexible, Cloudflare strips the encryption and forwards the request to your origin server (Vercel, Nginx, AWS ALB, etc.) over plaintext http://app.example.com on port 80 (with X-Forwarded-Proto: http).
3. Your modern origin server or web framework has an automatic security rule enabled: "Whenever a request arrives over plaintext HTTP, redirect the client to HTTPS!" It responds with 301 or 308 Redirect to https://app.example.com.
4. The browser follows the redirect and requests https://app.example.com again → Cloudflare forwards it to the origin over http:// again → the origin replies with a redirect to https:// again—looping endlessly until the browser gives up and displays ERR_TOO_MANY_REDIRECTS!

The rule is simple and absolute: Never use Flexible mode; always use Full (Strict). If you manage your own origin server or load balancer and do not want the overhead of rotating short-lived public Let's Encrypt certificates on the origin, you can generate a free Cloudflare Origin CA certificate (valid for up to 15 years and trusted specifically by Cloudflare's edge), install it on your origin server or ALB, and set the mode to Full (Strict).

WAF, rate limiting, and bot controls while protecting legitimate webhooks

At the Cloudflare edge, three defensive layers filter out malicious traffic before it ever touches your origin server:

• WAF Managed Rules: Inspect incoming HTTP requests to block SQL injection, cross-site scripting (XSS), command injection, and newly disclosed framework CVEs.
• Rate Limiting Rules: Throttle or block clients (429 Too Many Requests) that exceed a safe request threshold within a short window—such as brute-force login attempts against /api/auth/login (more than 10 requests per minute) or abusive calls to an expensive AI generation route /api/chat (more than 20 requests per minute). Because hundreds of legitimate users inside a corporate office, university campus, or mobile carrier NAT gateway often share a single public IPv4 address, rate limiting on authenticated routes should key on session cookies, user IDs, or API tokens rather than raw IP addresses alone to avoid false positives.
• Bot Management (Bot Fight Mode / Super Bot Fight Mode): Presents JavaScript challenges or Turnstile CAPTCHAs to automated scrapers and headless browsers.

A classic production outage occurs when Bot Fight Mode or an overly aggressive WAF challenge rule intercepts legitimate server-to-server webhooks from payment providers (Toss, Stripe, Lemon Squeezy), GitHub, or Slack, flags them as "automated bot traffic," and returns an HTML JavaScript challenge page—causing completed customer payments to be silently dropped! External webhook servers are backend HTTP clients, not web browsers; they cannot execute JavaScript challenges or solve CAPTCHAs.

To protect webhook endpoints (such as /api/payments/webhook) properly, combine two controls:

1. Configure a targeted WAF custom rule / skip rule for the exact webhook path (/api/payments/webhook) so interactive browser challenges (JS Challenge / Managed Challenge) are skipped for that route, while keeping protocol and payload sanity checks active.
2. In your application (or Edge Worker) handler, cryptographically verify the sender's HMAC signature header (such as X-Signature or Stripe-Signature) and timestamp against your webhook signing secret before processing the event, rejecting any unsigned or replayed request with 401 Unauthorized.

CDN cache rules and preventing cache poisoning on dynamic APIs and streams

Edge CDN caching is wonderful for speeding up static assets (/static/*, fonts, and public images) and offloading your origin server. However, misconfiguring Cache Rules so that the CDN caches dynamic, user-specific responses triggers one of the worst data breaches in web engineering: Cache Poisoning / Web Cache Deception.

Imagine what happens if an administrator tries to reduce origin server load by adding a Cloudflare Cache Rule matching URI Path starts with /api/ (or the entire site *) with Cache Everything and Ignore Cache-Control enabled:

1. Alice signs in to her account and fetches /api/me (or a server-side rendered /dashboard page).
2. The origin server responds with Alice's full name, email address, private AI consultation history, and even a Set-Cookie: session=alice_secret response header.
3. Because Cache Everything is active, the Cloudflare edge node saves Alice's entire response under the shared cache key for https://app.example.com/api/me!
4. One second later, Bob (an unrelated user—or even an unauthenticated visitor) requests /api/me. Without even contacting the origin server, Cloudflare serves Alice's private profile JSON and Alice's active session cookie straight from the edge cache into Bob's browser!

To prevent catastrophic cache leaks and broken streams in AI and web services, enforce the four caching rules in the table below without exception.

Cloudflare Workers and Queues: Edge computing and decoupling asynchronous work

Cloudflare provides two serverless building blocks that complement your core application server: Cloudflare Workers, a lightweight edge compute runtime built on V8 isolates, and Cloudflare Queues, an asynchronous message broker.

• Cloudflare Workers: Instead of booting heavy virtual machines or containers, Workers spin up isolated V8 execution contexts in a few milliseconds, achieving near-zero (0 ms) cold starts across hundreds of cities worldwide. They excel at lightweight front-door tasks right at the edge: verifying JWT signatures before invalid requests ever reach your origin, routing users to regional payment currencies or languages based on the CF-IPCountry header, or injecting security headers (Strict-Transport-Security, Content-Security-Policy). Keep in mind that Workers have strict CPU time limits per invocation, and if a Worker has to make multiple sequential queries to a single centralized database on the other side of the world, it faces the exact same network RTT physics discussed in Chapter 1 (unless paired with Smart Placement or edge caches).
• Cloudflare Queues: AI applications frequently perform heavy background work that cannot finish within a 1-second interactive HTTP request—such as chunking and embedding a 100-page PDF, sending bulk notification emails, or reconciling complex billing webhooks. Running those tasks synchronously inside the user's HTTP request leads to timeouts and lost work whenever a downstream API hiccups. Instead, a front-door Producer Worker validates the request, pushes a job message onto Cloudflare Queues, and immediately returns 202 Accepted to the client. Behind the queue, a Consumer Worker pulls messages in controlled batches to process them at a steady pace, smoothing out traffic spikes (buffering). If a batch fails due to a transient error, Queues retries automatically with backoff; messages that still fail after the maximum retry count are routed to a Dead Letter Queue (DLQ) so zero jobs are lost and engineers can inspect and replay them safely.

Cloudflare AI Gateway: Observability, caching, rate limiting, and fallback for LLM traffic

When your backend application calls external LLM APIs—such as OpenAI, Anthropic, or Google Gemini—directly, three operational headaches quickly emerge:

1. Because multiple features and agents call different model providers independently, you lack a unified view of how many tokens and dollars each feature consumes, or what its Time to First Token (TTFT) and error rate look like.
2. Users repeatedly trigger identical deterministic prompts (such as classifying a standard template or translating a fixed UI snippet), burning paid LLM tokens and waiting several seconds every single time.
3. Whenever your primary LLM provider suffers a regional outage (502/503) or hits an organization rate limit (429), your entire AI product goes down with it.

Cloudflare AI Gateway sits between your application backend and external LLM provider APIs as a dedicated LLM reverse proxy and control plane. By changing just the SDK baseURL in your application code to point to your AI Gateway endpoint, you gain five powerful infrastructure controls without rewriting your application logic.

Going deeper

DNS weighted routing vs. HTTP edge routing in zero-downtime blue-green migrations

Suppose you are executing a major platform migration and want to run a canary release that sends 5% of live traffic to the new infrastructure (Green) while keeping 95% on the existing infrastructure (Blue). Should you split traffic using Route 53 Weighted Routing (at the DNS layer) or Cloudflare Workers / Load Balancing (at the HTTP edge proxy layer)? The two layers behave very differently in granularity and rollback speed.

In practice, the two layers complement each other: use the HTTP edge proxy layer (Cloudflare Workers or Load Balancing) for fine-grained canary traffic splitting and instant circuit breaking between application origins, and use DNS routing policies (with pre-lowered TTLs) for macro-level disaster recovery across regions or CDN providers.

Origin IP leak paths and complete Origin Lockdown

Even if you spend thousands of dollars a month on enterprise Cloudflare WAF rules, your WAF is a paper tiger if an attacker can discover your origin server's IP address—or its default platform hostname (such as my-app.vercel.app or an AWS ALB's *.elb.amazonaws.com hostname)—and send HTTP requests straight to the origin around Cloudflare.

In real-world audits, origin addresses leak through a surprising variety of paths:

1. Historical DNS records from before Cloudflare was enabled remain indexed in public DNS history databases.
2. Mail records (MX, mail.example.com) or a forgotten staging subdomain (dev.example.com) point to the same server IP with the grey cloud (DNS Only) enabled.
3. An application feature—such as fetching a user-supplied avatar URL (SSRF) or sending outbound webhook/email traffic directly from the web server—reveals the origin server's public egress IP.
4. A managed platform's default domain (such as aidan-mu.vercel.app) is left publicly reachable without a redirect or Deployment Protection.

True edge security therefore requires completing Origin Lockdown so that "any request that did not pass through our authorized Cloudflare zone is rejected at the origin door":

• Network firewall layer: Restrict inbound port 443 on your origin Security Group from 0.0.0.0/0 to Cloudflare's published IPv4/IPv6 CIDR ranges, or close all inbound firewall ports completely and connect via Cloudflare Tunnel (Chapter 4).
• Mutual TLS layer (Authenticated Origin Pulls, mTLS): To prevent an attacker from creating their own free Cloudflare account, pointing their domain at your origin IP, and piggybacking through Cloudflare's IP ranges, enable Zone-Level or Custom Certificate Authenticated Origin Pulls (mTLS) so your origin server cryptographically verifies that the incoming TLS client certificate belongs specifically to your Cloudflare zone.
• Managed platform domain layer: When using a managed platform like Vercel as your origin, configure default .vercel.app production domains to return a 308 Permanent Redirect to your canonical custom domain (https://aidan.agentcat.app), or verify a signed custom origin secret header before executing expensive routes.

Workplace scenarios

Byeolmuri Commerce: Infinite redirect loops and shopping cart cache poisoning on Cloudflare launch day

To prepare for Black Friday traffic spikes and overseas credential-stuffing bots, AI gift-recommendation store Byeolmuri Commerce decided to place Cloudflare in front of its existing AWS Application Load Balancer (ALB). On Friday evening, an engineer switched the domain's authoritative nameservers to Cloudflare and changed two settings: first, to avoid touching certificates on the origin, they set Cloudflare's SSL/TLS mode to Flexible; second, hoping to slash origin CPU usage, they created a Cache Rule matching * (all URLs) with Cache Level: Cache Everything.

Five minutes after the cutover, the entire store went down. First, half of the shoppers could not even load the home page because their browsers failed with ERR_TOO_MANY_REDIRECTS. The AWS ALB had an existing listener rule redirecting all HTTP (port 80) requests to HTTPS (port 443), which collided head-on with Cloudflare's Flexible mode forwarding every HTTPS request to the ALB over plaintext HTTP port 80.

When the engineer hastily disabled the HTTP-to-HTTPS redirect rule on the ALB, the site loaded—only to trigger a far worse disaster ten minutes later. Customer support was flooded with panicked calls reporting: "When I open my shopping cart and saved shipping addresses, I see a complete stranger's name, phone number, home address, and private AI gift consultation chat!" Because of the blanket Cache Everything rule, the JSON responses for /api/cart and /api/chat/history requested by the first signed-in shopper had been cached at the Cloudflare edge and served verbatim to every subsequent visitor—a textbook cache poisoning data breach. On top of that, the real-time AI chat stream (/api/chat/stream) stopped typing word by word, freezing for 20 seconds before dumping the entire paragraph at once.

An infrastructure architect paged into the incident resolved the crisis within 15 minutes by executing three steps in order:

1. Immediate full cache purge (Purge Everything) and dynamic route bypass: They purged the entire Cloudflare edge cache immediately to wipe out the cached personal data. Next, they replaced the broken cache rule so that /api/*, /auth/*, /checkout/*, and any request carrying a Cookie or Authorization header are strictly set to Bypass Cache at the highest priority. On the origin server, they enforced Cache-Control: private, no-store on all personalized responses and Content-Type: text/event-stream with Cache-Control: no-cache, no-transform on SSE streaming routes.
2. Switching to Full (Strict) and restoring HTTPS redirects: Because the AWS ALB already had a valid AWS Certificate Manager (ACM) TLS certificate attached on port 443, they switched Cloudflare's SSL/TLS mode to Full (Strict) and re-enabled the ALB's HTTPS redirect rule—eliminating the redirect loop while encrypting traffic end to end.
3. Post-incident containment and notification: By cross-referencing 12 minutes of edge access logs, the team identified the 18 user sessions whose shipping details could have been viewed by another visitor, invalidated all active session tokens, and worked with the privacy officer and legal team to complete mandatory breach notifications.

Narae AI Lab: Surviving an OpenAI outage with AI Gateway fallbacks and migrating DNS with advance TTL reduction

Narae AI Lab, which runs an enterprise meeting-minutes summarization platform, faced two high-stakes infrastructure projects: migrating their authoritative DNS and API endpoints from a legacy domestic registrar to Amazon Route 53 with zero downtime, and eliminating the single point of failure (SPOF) that caused their entire summarization pipeline to halt whenever a single LLM vendor had an outage.

For the DNS migration, on Thursday morning—three full days (72 hours) before the scheduled Sunday cutover—the team lowered the TTL on every DNS record at the existing registrar from 36,000 seconds (10 hours) down to 60 seconds. By Sunday at 03:00 a.m., every recursive resolver worldwide had long since expired the old 10-hour cache and was re-querying every 60 seconds. The team configured their Route 53 hosted zone using an Alias record at the Zone Apex (narae.ai) and health-checked Failover records on the API subdomain (api.narae.ai), then executed the cutover. Thanks to the advance TTL reduction, traffic shifted completely to the new infrastructure in under two minutes with zero dropped requests, after which the team restored the TTL to 3,600 seconds.

Next, the team placed Cloudflare AI Gateway and Cloudflare Queues into their LLM summarization pipeline.

Two months later, when their primary LLM provider suffered a 40-minute global API outage, Narae AI Lab's pipeline automatically failed over to the backup model through AI Gateway within two seconds—passing through the entire outage window with zero customer support tickets.

Common mistakes

1. "You can put a standard CNAME record on the root domain (example.com) just like you do on www.example.com." By DNS protocol standards (RFC 1034 and RFC 2181), a CNAME record cannot coexist with any other record type at the same node name. Because the Zone Apex (example.com) must always hold SOA and NS records to define the zone, placing a standard CNAME there is forbidden; you must use an Amazon Route 53 Alias record or Cloudflare CNAME Flattening.
2. "If I lower the DNS TTL to 60 seconds at the exact same moment I change the server IP on migration day, the whole internet will switch within 60 seconds." Recursive DNS resolvers around the world that queried your domain prior to the cutover keep serving the old IP address from cache for the full duration of the previous TTL (for example, 24 hours) without contacting your authoritative nameserver again. You must lower the TTL at least one full old-TTL window before the migration date and wait for old cached entries to expire first.
3. "Setting Cloudflare SSL/TLS mode to Flexible is a safe and convenient way to avoid installing a certificate on my origin server." Flexible forwards traffic between the Cloudflare edge and your origin server over unencrypted plaintext HTTP (port 80), and if your origin server redirects HTTP to HTTPS, it triggers an immediate ERR_TOO_MANY_REDIRECTS infinite loop in users' browsers. Always install an origin certificate (such as a Cloudflare Origin CA certificate) and use Full (Strict).
4. "Once the Cloudflare orange cloud (Proxied) is turned on, leaving my origin server's security group open to 0.0.0.0/0 is completely safe." The orange cloud only changes DNS responses to return Cloudflare edge IP addresses. If an attacker discovers your origin server's real IP address through DNS history logs or scanning, they can send HTTP requests directly to that IP and bypass your WAF completely—unless you enforce Origin Lockdown using a Cloudflare IP allowlist, Authenticated Origin Pulls (mTLS), or Cloudflare Tunnel.
5. "Turning on CDN Cache Everything for /api/* routes is a great way to reduce backend database load." Caching endpoints that return user-specific JSON data or Set-Cookie/Authorization headers in a shared CDN cache causes severe cache poisoning, serving the first authenticated user's personal profile and session tokens to strangers. Personalized APIs and SSE streams (text/event-stream) must always be configured to Bypass Cache.
6. "When an external platform gives me a CNAME record to verify domain ownership or issue a TLS certificate, I should turn on the orange cloud (Proxied) for extra security." Turning on the orange cloud causes Cloudflare to respond with its own A/AAAA IP addresses instead of the target CNAME hostname string, causing the external platform's CNAME verification check to fail. External domain-verification CNAME records must be left on grey cloud (DNS Only).

Summary at a glance

Check the official docs

• AWS Route 53 — Choosing between alias and non-alias records: Zone Apex constraints and how Alias records compare to CNAME records.
• AWS Route 53 — Choosing a routing policy & Health Checks: Simple, Weighted, Latency, and Failover routing policies and integrating health checks.
• Cloudflare — Proxy status (Orange vs Grey Cloud): How orange-cloud proxying works and when CNAME verification requires DNS-only mode.
• Cloudflare — SSL/TLS Encryption modes (Full (Strict)) & Origin CA: Why Flexible causes redirect loops and how to configure Full (Strict) with Origin CA certificates.
• Cloudflare — Cache Rules & Preventing Cache Poisoning: Bypassing cache for dynamic content and designing safe cache keys.
• Cloudflare — AI Gateway Documentation: Unified LLM logging, caching, rate limiting, and Universal Endpoint multi-provider fallback routing.

Self-check

3-1. Explain why the DNS specification permits CNAME records on subdomains (www.example.com) but forbids CNAME records at the root domain (Zone Apex, example.com), and name the record feature used in Amazon Route 53 to connect a root domain to an AWS Application Load Balancer (ALB).

3-2. When planning a zero-downtime server IP migration for a domain whose current DNS TTL is 86,400 seconds (24 hours), explain in terms of recursive DNS resolver caching why you must lower the TTL to 60–300 seconds at least 24 hours in advance rather than on the day of the migration.

3-3. When an origin web server is configured to redirect all plaintext HTTP requests to HTTPS with a 301 status code, explain what browser error occurs (and why) if Cloudflare's SSL/TLS encryption mode is set to Flexible, and state the correct SSL/TLS mode to use instead.

3-4. Even after you enable the orange cloud (Proxied) and configure comprehensive WAF rules in Cloudflare, explain how an attacker who discovers your origin server's real IP address can bypass the WAF completely, and list at least two controls you can implement on the origin side to block direct access.

3-5. For a /api/profile endpoint that returns personalized user data and a /api/chat/stream (text/event-stream) endpoint that streams real-time LLM tokens, describe the specific incidents that occur if a CDN applies blanket caching and response buffering to both routes, and state the correct Cache-Control headers and CDN cache rule settings for each.

3-6. Design task: A customer-support summarization service that relies on a single external LLM API (such as OpenAI) frequently goes down due to transient provider 503 outages and runaway agent loops that spike hourly request counts. Explain how introducing Cloudflare AI Gateway solves both problems by naming three of its core features.

Hands-on tasks