Setting up a simple Content Delivery Network

Content Delivery Networks (CDNs) have become essential in the way we handle the delivery of web content today. They are used to optimize websites and applications by delivering static files like HTML, CSS, JavaScript, images, and videos from servers that are geographically closer to users, instead of relying on origin servers alone (which could be continents away) to do so. 

‍

By giving an example of how to configure a simple CDN from scratch, we hope to equip you with the context needed to set one up for your next project. Even if you’re not setting up your own CDN, this tutorial will help demystify how hosting servers and data retrieval work to deliver content via the internet.

Throughout the tutorial, we will:

‍

• Explain what a content delivery network is, its purpose, and why it is useful for modern applications.
• Give step by step instructions for setting up a CDN by:
  

• Adding static files to an Amazon S3 bucket to store our website content.
• Purchasing a domain (if necessary) to provide a unique address for our website.
• Taking control of our domain settings using Amazon Route 53.
• Verifying domain ownership and enabling HTTPS for encryption and security with AWS Certificate Manager (ACM).
• Configuring Amazon CloudFront to deliver our site’s content efficiently through a global network of edge servers.
• Linking our domain to CloudFront (our CDN) so our website can be quickly accessed worldwide. 

‍

Whether you’re looking to gain experience with CDN configuration or gain a deeper understanding of how internet infrastructure works, this guide will provide you with a strong foundation to move forward. 

‍

Before we set up our Content Delivery Network, let’s review how requesting and serving websites work.

‍

1. URL to IP Conversion

• When a user enters the URL of the website they would like to visit (ie: https://codesmith.io), the web browser converts that URL into an IP address (like 199.60.103.131). This IP address points to the server hosting the website. Remember, hosting a website just means storing and serving the files of that website so that users can access them via the internet.
• To convert that URL into an IP address, the browser uses a Domain Name System (DNS). In our walk through, the DNS we will be using is Amazon Web Services’ Route 53. A DNS takes in a URL, finds the IP address associated with it, and returns that IP address to the browser.

2. Requesting files from the server

• Once a browser knows the IP address of the server hosting the website (codesmith.io - 199.60.103.131), it can send an HTTP or HTTPS request to the server asking for the website’s files. 

3. Serving the files to the client

• The server then processes the request and (if there are no errors) responds with the website’s files (such as the HTML, CSS, JavaScript, etc).
• Finally, the browser can render (display) those files to the screen.  

‍

‍

What is a CDN and how does it work?

Now that we know how our browser makes requests to a server for static files (like the codesmith.io homepage above) we can explore how a content delivery network can be used to optimize this process.

‍

Most websites consist of a frontend with static files like we mentioned above (JavaScript, HTML, CSS, images, and videos). These files are frequently requested, and remain the same for all users. The backend of a website would contain dynamic files with logic for database queries, authentication, user session data, etc. (think Express.js). The outputs of these backend files can have wide variations based on the requests your website receives. Both frontend and backend need to be hosted on a server in order for a user to access them. What if that server is thousands of miles away from the user requesting those files? Not only might it take too long to access those files, but the server could get overloaded with requests if too many users try to access it at the same time.

‍

This is where content delivery networks come in. A CDN can be leveraged to cache (temporarily store) static files of your website (the front end). For example, in the image above, static files were requested from an origin server for the JavaScript, HTML and CSS for codesmith.io. 

‍

A CDN would cache those static files on a network of edge servers which are distributed around the globe. These servers deliver the static content to users based on proximity, many of which are much closer to a user than the origin server. The origin server will still need to be accessed for most of its dynamic files (the backend), but the use of a network of edge servers (CDN) speeds up the process of retrieving static files (the frontend) so that users don’t have to wait longer than necessary to start using your website. Here’s how it works:

‍

• When a user visits codesmith.io, the browser will make a request for the static files. The CDN will step in to search for these files in the nearest edge server.
• If the files are found in the edge server (called a cache hit) they can be delivered to the browser immediately, which reduces the time it takes to load the page.
• If the files are not found in the edge server (a cache miss), the CDN will fetch them from the origin server and then cache them so that subsequent users won’t have to wait as long for the content to load.

‍

‍

Below is a step by step process of how a content delivery network works.

‍

‍

Nearly everyone who accesses the internet interacts with content delivery networks as they:

‍

• Boost performance: Take streaming a TV show for example. When a user wants to watch a show, if the media file is cached on an edge server near the user (instead of only existing on a far away origin server), it will load much faster.

‍

• Ensure availability: Because CDN’s are distributed throughout massive regions (as seen on the map above) their contents remain available, even through periods of high traffic and during server outages. 

‍

• Offload traffic: This has proven to be of paramount importance in the modern era of online streaming. Instead of overstressing origin servers to deliver content, CDN’s spread the workload among a team (or network) of edge servers. 

‍

• Improve user experience: By ensuring the availability of content as well as decreasing latencies for retrieving it, content delivery networks help businesses keep their customers happy. Companies use CDN’s to lower abandonment rates, increase ad impressions, and improve customer loyalty.

‍

Content delivery networks can also help businesses improve security for their users, gather useful insights on their users, and reduce the costs associated with bandwidth consumption (meaning less data needs to be transferred from the origin server all at once).

‍

Now, we’ll begin our tutorial on setting up your very own content delivery network! We will be using Amazon Web Services (AWS) for this tutorial as it is widely used and will make setting up/managing our CDN straight forward. 

‍

If you’re already feeling a bit unnerved, don’t worry! We’ll explain as we go.

‍

Setting up a simple CDN

Since CDN’s are almost exclusively used for distributing static files, we have set up a basic front-end-only example site, codesmith.click for this tutorial. This website contains two static files (an image and our index.html) that will need to be hosted so they can be served via the internet. 

‍

1. Setting up an AWS S3 bucket 

In order for files to be accessed via the internet, they need to be hosted or served from somewhere. We will be using the AWS Simple Storage Service (S3) to act as our origin server for our two static files. S3 is a highly scalable service used for uploading and managing static files. The files will be placed in an S3 bucket, which is like a folder.

1. Log into the AWS console, navigate to S3, and click "Create bucket".

2. Give your bucket a name. For example, we used "codesmith-example-site"

3. You can leave all of the default options as they are, and click "Create bucket".

4. In General purpose buckets, click your newly created bucket.

5. Click "Upload".

6. Click "Add files" and select your static website files (like index.html, styles.css, images, fonts, media files, etc.) If you're deploying a site built with a framework like React, you'll need to upload the contents of the build folder here. The build folder (usually called "dist" or "build") includes the minified and optimized versions of your website's files, including your index.html, CSS, JavaScript and other static assets.

‍

‍

7. Confirm that necessary files have been added to your bucket, and click “upload”.

8. You should receive this notification that the upload has succeeded. Click “Close”.

9. Click "Permissions".

10. Make sure public access is blocked.

11. Click the "Properties" tab.

12. Make sure static website hosting is disabled for your S3 bucket. Once we set it up, CloudFront (our CDN) will handle all content delivery, including caching and serving files to users. The files for your website will still be stored in S3 as the origin, but users will only access them through CloudFront, not directly from S3.

‍

2. Purchase a domain name

If you don’t already have a domain name, you’ll need to purchase one. We used Namecheap to create codesmith.click but you can use any domain registrar of your choice. If you already own a domain, you can simply use that. Just ensure that you have access to your website’s nameservers in your domain registrar (namecheap, google domains, etc.) as you’ll need to change these in order to connect your site to a CDN. 

3. Setting up a Domain name system (DNS) 

A Domain name system is like a giant phone book that links URLs to IP addresses (ie: 52.85.61.5). The IP address is the number (or address) of the server where a website is hosted. Much like CDN’s, these DNS servers are spread all across the globe. When you type in a URL (like codesmith.click) into your browser:

‍

• Your computer asks a DNS server for the IP address associated with the domain codesmith.click.
• The DNS server looks up the domain and responds with the corresponding IP address.
• Your browser uses the IP address to load codesmith.click.

‍

To make our newly purchased domain name accessible to users through a DNS, we’ll set one up using AWS Route 53.

1. Navigate to Route 53 in AWS, and click "Get started".

‍

2. Click "Create hosted zones", and then click "Get started".

What is a Hosted zone? When we create a hosted zone in Route 53, we’re setting up a dedicated space to manage the DNS records for our domain. The hosted zone is like the control center for your domain where you add records to point your domain to things like a website, email servers, or other AWS services like CloudFront (our CDN).

3. Type your new/existing domain name into the field, then click "Create hosted zone".

4. In the Hosted zones list, click your domain name to view its DNS records.

What is DNS? A DNS (Domain Name System) acts like an internet address book that connects a domain name to an IP address. Each DNS record configures how traffic is routed to your domain. We’ll go into more detail in a bit.

5. Route 53 will automatically create NS (nameserver) records for your domain. Click the checkbox to view the record details.

‍

What Are NS Records? Nameserver (NS) records tell the DNS system which server or service is responsible for managing your domain’s DNS settings. Think of them as a signpost that tells the internet, “Hey, Route 53 is handling everything for the domain ‘codesmith.click’ from now on.” These records will be essential for pointing our domain to AWS CloudFront (our CDN).

6. Copy the first value in the list. You’ll repeat this process for each nameserver value.

7. Log into your domain registrar. (like Namecheap, GoDaddy, Google Domains). Navigate to the DNS settings or Nameservers section for your domain and replace the default nameservers with the ones provided by Route 53 (ie: ns-592.awsdns-10.net above).

Why is this step important? By copying and updating your domain’s Nameserver records to those provided by Route 53, you are delegating Route 53 control of queries made to your domain. Without these, we wouldn’t be able to connect our domain (like codesmith.click) to CloudFront (our CDN) or AWS Certificate Manager (which will verify that we own the domain). 

8. (Steps 8-10 are optional but recommended): Confirm the propagation using a tool like DNS Checker.

9. Enter your domain name in the field. Click the dropdown and select NS for Name Service, then click "Search".

10. Confirm propagation is resolved in all locations. In this DNS checker, each check mark is a group of AWS DNS servers (also known as Route 53 servers). We are checking that Route 53 servers are updated ready to handle requests for your domain name and send back the correct IP addresses (which point to where your website is hosted) to the user's browsers.

4. Request an SSL certificate

Sensitive information like passwords, credit card numbers, and personal data can be intercepted by attackers if the connection between users and your website is not secure. A Secure Sockets Layer (SSL) certificate provides encryption for data exchanged between users and your servers, ensuring their information stays protected. These certificates also enhance trust, which improves rankings from search engines (like Google) that prioritize security.

Once requested, AWS will verify that you control the domain's DNS settings before issuing the SSL certificate, which will also serve as proof of domain ownership—This will be important later when configuring CloudFront to manage your website's traffic.

1. Navigate to AWS Certificate Manager (ACM) and Click "Request a certificate".

2. The default public certificate is fine, click "Next".

3. Add your domain name to the "Fully qualified domain name" field, then click "add another name...". In the second field, type www.[your domain name] (i.e. “www.codesmith.click”) for the subdomain. Many users access websites using the www subdomain and we want to ensure both the root domain (codesmith.click) and the www subdomain are secure and functional.

4. Keep DNS validation and the rest of the default options. Click "Request".

5.  Requesting and Validating the SSL Certificate

After we request the SSL certificate, it will be in pending validation as ACM needs to confirm that we actually own the domain before issuing the certificate.

How AWS Certificate Manager (ACM) verifies ownership of a domain:

• ACM gives you two CNAME records (nicknames for codesmith.click and www.codesmith.click).
• To prove ownership, you’ll need to add these CNAME records to your Route 53 DNS settings.
• ACM will then check if the CNAMEs match the ones on the certificate request.
• Once ACM confirms the match, the SSL certificate will be issued.

Click "Create records in Route 53". This will automatically add the CNAME records to our Route 53 DNS settings.

6. Leave both Domains selected and "Create Records".

7. You should see this notification that DNS records have been created in Route 53.

8. Once the certificate has been validated (which can take a minute or two), the certificate status will update to "Issued", and the status for the domains will update to "Success". We can now use this certificate to set up secure connections between our users and our content delivery network’s edge servers!

5. Set up your CloudFront distribution (your CDN)

In this section we will finally set up our actual content delivery network through AWS CloudFront! CloudFront allows us to cache and serve the static files of our website (which is currently all codesmith.click is composed of) as close as possible to users across the globe. Instead of serving these files from our origin server (Amazon S3), CloudFront will use its network of edge servers to do the work.

1. Navigate to Amazon CloudFront and click "Create a CloudFront distribution"

2. Click your previously created S3 bucket from the "Origin domain" dropdown.

3. Click the "Origin access control settings" button, then click "Create new OAC"

4. Enter a unique name for your Origin access control policy, keep the default settings for "Sign requests", and click "Create".

What is Origin Access Control (OAC)? This sets up a secure way for CloudFront to access our website’s files in our S3 bucket (their origin). This ensures that the content in our S3 bucket can only be retrieved through CloudFront. This prevents anyone from bypassing our CDN and accessing our files directly from S3. 

Think of CloudFront as the gatekeeper for our S3 bucket - only requests made to CloudFront can access the S3 bucket. This keeps origin content secure and enables CloudFront to cache and deliver it safely.

To be certain that a request has been made to access our files through CloudFront we are defining a policy that literally requires CloudFront to sign off on legitimate requests.

5. Under "Default cache behavior", leave "Compress objects automatically" enabled to improve performance.

Under "Viewer Protocol Policy", choose Redirect HTTP to HTTPS to force secure connections.

And under Allowed "HTTP methods", choose the HTTP methods needed for your site. For our purposes with a static (non-interactive) website, only the "GET, HEAD" methods are necessary.

6. Choose your security protections. For our example website (codesmith.click), extra Firewall security isn’t necessary, but it's worth considering if your own application contains sensitive information.

7. Under "Price class" choose how far of a reach you would like your cached content to have. "Use all edge locations" will cache your files on all possible edge servers globally. Use this option for the best performance!

8. Under "Alternate domain name", click "add item" twice, then input your root domain and www subdomain into the fields. This tells CloudFront it will be handling requests for the root domain (codesmith.click) as well as the subdomain (www.codesmith.click).

9. In the "Custom SSL certificate" dropdown, choose the SSL certificate that we created earlier. This will prove our domain ownership to CloudFront and allow it to use the SSL certificate to secure and encrypt connections to our custom domains.

10. For the Default root object, you can type index.html into the field. This will tell CloudFront which file to serve when a user visits our website’s root URL (codesmith.click). This is typically the default behavior for CloudFront, but we'll be specific just in case. Then click "Create distribution".

All of these settings can be updated later if you find it necessary to change anything.

11. You should see a notification that you've successfully created a new distribution, and an alert that your S3 bucket policy needs to be updated. Click "Copy policy" first.

Then click "Go to S3 bucket permissions to update policy"

12. In "Bucket policy" click "Edit"

13. Paste the copied OAC policy from CloudFront into the field. Then click "Save changes"

14. You should see a notification that your policy has been successfully edited.

At this point your distribution should be deploying which can take up to 30 minutes. Let’s wrap things up with the final step!

6. Route traffic to your CloudFront Distribution

The final step is to send any requests for our domain to our content delivery network. To route traffic to our CloudFront CDN, we will configure our DNS records in Route 53 to:

• Point codesmith.click (the root domain) to our CDN by creating an A Name (Alias) record.
• Redirect www.codesmith.click (the subdomain) to codesmith.click through a CNAME record.

These DNS records ensure that all requests to our domain are directed to CloudFront, allowing users to access codesmith.click. By including both the root domain and the subdomain, we confirm that visitors can access our site whether they type the URL with or without the www.

1. Return to "Hosted Zones" in Route 53, and click your domain name.

2. Here, you should see the four records that were automatically created earlier:

• The NS and SOA records created by Route 53.
• Two CNAME records created by AWS Certificate Manager.
  
  

For this step we will need to manually create records. Click "Create record".

3. Leave the "Record name" field blank to create a record for the root domain, and the default A record for "Record type". Click the "Alias" toggle.

What is an A Name (Alias) record? We’re creating an A Name record that maps codesmith.click to our CloudFront CDN. This makes sure that when a user types “codesmith.click” into their browser, they are routed to the nearest edge server in our CDN.

4. Click the dropdown for "Route traffic to", and select "Alias to CloudFront distribution".

5. Click the "Choose distribution" field and select your CloudFront distribution.

6. Click "Add another record"

7. Input "www" in the "Record name" field.

8. In the "Record type" dropdown, select "CNAME – Routes traffic to another domain name and to some AWS resources".

What is a CNAME? A CNAME acts as a nick-name for a domain name. We are creating a CNAME record that tells DNS to redirect traffic from www.codesmith.click to codesmith.click. 

We do this because many users still type www before a domain name out of habit. We want to make sure that, if they do so, they can still reach our site. This basically tells Route 53, “treat www.codesmith.click like a nick-name for codesmith.click. If someone types www, just send them to the root domain.”

9. In the "value" field, input your root domain name. Then click "Create records".

10. You should see a notification that records were successfully created. Click "View status" to confirm.

11. Wait for the status to update to "INSYNC". (If it updates to Backstreet Boys, there might be a problem.)

‍

12. Optional step: If you would like to confirm propagation of your new records, you can use the DNS checker tool we used earlier. Select A record from the dropdown for the root domain, and CNAME for the www subdomain.

13. Confirm that CloudFront is deployed and delivering our Website!

Type your domain into the browser. Test the domain, and www subdomain to confirm the https redirection. (Verify HTTPS is automatically applied to the URL)

14. Confirm delivery of your Website from the CloudFront CDN!

Setting up a content delivery network of your own is fairly involved but the benefits are well worth the effort. Leveraging the power of edge servers to deliver your files will keep your users happy by ensuring consistency and speed in delivering content. Doing so also takes a massive load off of your origin servers so they can operate as efficiently as possible as well. As you’ve seen in this article, there are fantastic resources like Amazon Web Services that work together seamlessly to help you and your team set one up using just one platform. Happy edge serving!