Learn Cloud Computing - Content Delivery Network (CDN) & Cloud DNS

#Introduction

In episode 12 we deployed applications with containers and Kubernetes. But a good deployment doesn't mean a good user experience: if all your servers are in Singapore, users in London must travel thousands of network kilometers for every image, file, and script. This is where two complementary network services come in: CDN to shorten the content journey, and cloud DNS to guide domain names to the right destination.

Episode 13 covers why latency is a matter of distance physics, how CDN stores content at edge locations around the world — including dynamic content — and how cloud DNS performs traffic management with latency-based routing, geolocation, and automatic failover based on health checks.

#Why Latency: The Physics of Distance

Latency is the time data takes to travel. Light in optical fiber travels at about two-thirds the speed of light in a vacuum — every 1000 kilometers adds about 5 milliseconds per direction, not counting the network equipment at each hop.

A user in London would feel an application is "slow" not because the server is weak, but because every byte must travel tens of thousands of kilometers. The solution isn't strengthening the server — it's bringing the data closer to the user.

#CDN: Content Waiting at the World's Edge

A CDN (Content Delivery Network) is a network of cache servers spread across edge locations around the world. When a user in Jakarta requests a file, the CDN directs the request to the nearest edge, not to the origin server in London.

How it works is simple:

1. The first request reaches the edge — the edge doesn't have the file yet (cache miss) — the edge fetches it from the origin, stores it, then returns it to the user.
2. The next request from any user in that region reaches the edge — the file is already available (cache hit) — it's served directly without touching the origin.
3. Each file is given a TTL: until it expires, the edge serves from cache; after it expires, the edge checks the origin again.

#Dynamic Content: More Than Just Cache

CDN isn't only for static files. For dynamic content — HTML that differs per user, authentication results, or APIs — the CDN remains useful through two mechanisms:

• Smart routing: traffic is optimized through the best path to the origin, including reused keep-alive connections, thereby reducing network latency.
• Dynamic content acceleration: the connection between edge and origin is optimized so API responses feel faster even though they can't be cached.

Additionally, the CDN becomes the first protection layer against DDoS: thousands of edges absorb attack volume before it reaches the origin. This is also why in episode 14 later, the CDN is described as part of a layered defense.

#Practice: Cache Invalidation in CloudFront

One of the most common operations is cache invalidation: when new content is deployed, the old files at the edge must be removed so users don't get stale versions. On AWS this is done with aws cloudfront create-invalidation:

aws cloudfront create-invalidation \
  --distribution-id E1XYZEXAMPLE \
  --paths "/index.html" "/assets/*"

This command tells CloudFront that index.html and all files in the assets folder must be considered expired across all edges. On GCP, the same operation is done via Cloud CDN by invalidating the cache on the backend service; on Azure, via Azure Front Door with purge content. Same concept — only names and syntax differ.

#Cloud DNS and Traffic Management

Now that content is close to users, the next question: how does the domain toko-kalian.id find the right server? DNS (Domain Name System) is the internet's directory that translates domain names into IP addresses.

Cloud DNS means the domain name is managed by the provider — AWS Route 53, GCP Cloud DNS, Azure Azure DNS — with global reach and a high SLA. Its added value isn't just name resolution, but traffic management: smart decisions about which IP to answer with, based on real-time conditions.

• Latency-based routing: query DNS from Singapore, get a Singapore IP; from London, get a London IP. Every user is directed to the nearest region.
• Geolocation-based routing: answer differently based on country or continent — for example, require Indonesian users to use Indonesian servers for data compliance.
• Health check failover: DNS periodically checks endpoint health; if the primary dies, the answer automatically switches to the secondary. This is address resilience without adding servers.

#Practice: Tracing DNS Resolution with dig

To verify DNS answers, you can use dig or nslookup directly from the terminal. Here's an example of tracing the address answered for a domain:

dig +short toko-kalian.id
54.230.200.10

The result is the IP address answered by DNS. If you run dig +short from two different locations on a latency-based routing configuration, the results can differ — that's proof the DNS is doing traffic management. To see full details including TTL and authoritative nameservers, run dig toko-kalian.id ANY or nslookup toko-kalian.id — both show the same report, just in different formats.

To add a new record in Route 53, AWS provides aws route53 change-resource-record-sets — a command that sends DNS changes in JSON format:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1ABC2DEF3G4H \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.toko-kalian.id.",
          "Type": "A",
          "TTL": 300,
          "ResourceRecords": [
            { "Value": "203.0.113.10" }
          ]
        }
      }
    ]
  }'

Notice the striking TTL difference between CDN and DNS practice: DNS TTL determines how long a resolver may keep an answer. A short TTL (e.g. 300 seconds) means DNS changes — like an IP move due to failover — spread quickly, while a long TTL saves DNS queries.

#Comparing the Big 3 CDN and DNS Services

All three clouds offer equally complete CDN and DNS pairs. Often both are used together: the CDN needs DNS to direct users to the right edge, and smart DNS needs data about user location — they complement each other for one goal: making the application feel local to every user in the world.

#Conclusion

In this episode 13 you understood the two layers that make an application feel fast and reliable globally: CDN, which brings static and dynamic content closer to edge locations so users anywhere are served by the nearest server, and cloud DNS with traffic management — latency-based routing, geolocation, and health check failover — which guides domain names to the best destination. You also practiced cache invalidation via aws cloudfront create-invalidation, reading dig output, and adding records with aws route53 change-resource-record-sets.

The keys to take away:

• CDN brings content closer to users — latency is a matter of distance, and the edge is the answer.
• DNS is both a directory and a traffic manager — health checks turn it into an automatic failover layer.
• The CDN and DNS combination makes an application global — fast for everyone, wherever they are.

Your application is now fast and easy to reach — and precisely because of that, it's more worth attacking. The more popular a service is, the more attractive it becomes to attackers. Episode 14 will build defense on top of the networking foundation you've already mastered: Cloud Security, Firewall & Web Application Firewall (WAF) — layered defense that protects the application you've built so far.