To follow along, you should have:

• An AWS account.

• A basic understanding of AWS architecture (You can gain insights here.)

• Knowledge of AWS IAM (Identity and Access Management for secure resource access control)

• Familiarity with Git and GitHub

Let’s dive in and set up our static site hosting step by step.

Table of Contents:

1. What is AWS S3?

   • Fine-Grained Access Controls in S3

   • Encryption at Rest in S3

   • How to Upload a Static Website to Amazon S3

2. What is a Bucket?

   • How to Create a Bucket

   • How to Upload Files and Folders to an S3 Bucket

   • How to Set Permissions and Properties in AWS S3

   • What is a Bucket Policy?

   • How to Set Up a Bucket Policy

3. How to Enable Static Hosting

4. Amazon CloudFront

   • Key Features of Amazon CloudFront

   • Why Amazon S3 Alone is Not Enough

   • Why You Should Serve Your Website with CloudFront

   • What is a CloudFront Distribution?

   • Understanding the Amazon Resource Name (ARN)

   • Updated S3 Bucket Policy

5. Conclusion

What is AWS S3?

Amazon Simple Storage Service (Amazon S3) is an object storage service designed to store and retrieve any amount of data from anywhere.

Using Amazon S3 is straightforward. You start by selecting a region, creating a storage container called a "bucket," and then uploading your data. There is no limit to how much data you can store, and you can retrieve it at any time.

Amazon S3 automatically creates backups of your data by storing copies across multiple devices. It also allows you to preserve different versions of your files, helping you recover data if it’s accidentally lost. If you delete a file by mistake, you can restore it using Amazon S3’s versioning feature.

Amazon S3 offers configurable lifecycle policies to help manage data efficiently throughout its lifecycle. Security is a top priority for AWS, ensuring that data uploads and retrievals are protected using SSL encryption for secure transmission. AWS also provides multiple security features to safeguard your data, including fine-grained access controls and encryption at rest. Let’s explore these two features in a bit more detail.

Fine-Grained Access Controls in S3

Amazon S3 provides fine-grained access control, allowing you to define who can access your data and what actions they can perform. This is managed through:

1. AWS Identity and Access Management (IAM): Controls user permissions at the AWS account level. You can grant specific users or roles permissions to access S3.

2. S3 bucket policies: JSON-based policies applied at the bucket level to control access for all objects in a bucket.

3. Access Control Lists (ACLs): Defines permissions for individual objects within a bucket (less commonly used since bucket policies are more powerful).

4. Block public access settings: Prevents accidental public exposure of S3 data by restricting open access.

Encryption at Rest in S3

Encryption at rest ensures that stored data remains secure, even if unauthorized access occurs. S3 supports multiple encryption options:

1. Server-Side Encryption (SSE):

   • SSE-S3: AWS manages encryption keys automatically.

   • SSE-KMS: Uses AWS Key Management Service (KMS) for additional control over encryption keys.

   • SSE-C: Customers provide their own encryption keys.

2. Client-Side Encryption:

   • Data is encrypted before being uploaded to S3 using customer-managed encryption keys.

We could spend endless time researching and exploring the theory behind Amazon S3, but practical application solidifies learning. Now, let’s move on to uploading a static website to Amazon S3.

As mentioned earlier, you should have a basic understanding of how AWS works, including signing up, signing in, and creating IAM users. This is crucial because we will use an IAM user to perform operations securely. Understanding Identity and Access Management is essential in AWS, as it ensures proper access control and security while managing resources.

How to Upload a Static Website to Amazon S3

To upload a static website, you first need a static site. If you do not have one, you can use a free template from Free CSS.

I’ve also provided a ready-to-use template that you can clone from this GitHub repository: Mediplus Free Template.

Now that your static project is ready, let’s go to AWS and upload it to an Amazon S3 bucket.

Login to your AWS account using your IAM user credentials. Once logged in, you will be redirected to the AWS Management Console.

Your AWS Dashboard should look similar to this:

Navigate to the S3 service by clicking on the S3 link in the AWS dashboard. If you don’t see it, which is unlikely, use the search bar at the top of the dashboard. Simply type "S3", and it will appear in the results. Click on it to proceed.

Once you arrive at the Amazon S3 page, you will see the Create Bucket button.

S3 buckets are the backbone for many applications, including content delivery, data backup, archiving, static website hosting, and big data storage for analytics.

What is a Bucket?

Amazon S3 buckets are the fundamental storage containers within AWS Simple Storage Service that provide secure, scalable repositories for digital assets.

Each bucket features a globally unique name, regional deployment, and flat object storage architecture identified by unique keys.

With 99.999999999% durability through built-in redundancy, S3 buckets support crucial infrastructure needs including content distribution, data archiving, and static website hosting. Admins can implement comprehensive data governance through configurable access controls (policies, ACLs, IAM), lifecycle management, versioning capabilities, and encryption protocols to meet organizational security requirements.

How to Create a Bucket

To create a bucket, click on the "Create bucket" button. You will then be redirected to the bucket creation page.

Choose any name you like, as long as it follows AWS bucket naming rules.

You will also see various configuration options, but for now, leave them as default. We will make the necessary adjustments later in the project.

Finally, click on "Create bucket", and just like that your bucket is created! You should now see your bucket, which acts as a container for storing your files or data:

How to Upload Files and Folders to an S3 Bucket

Now, let’s upload the static site we created or cloned to our S3 bucket.

1. Click on your bucket:

After clicking on your bucket, you will be taken to the bucket details page, where you can manage various settings and configurations. This page provides options to adjust permissions and properties, monitor metrics, manage access points, and upload files using the "Upload" button.

2. Upload project files:

If your static site project is ready, it should contain the essential files needed for deployment. While the structure may vary, it should include an index.html file, along with necessary assets such as images (or an image folder), CSS files (or a CSS folder), and JavaScript files (or a JS folder) to ensure proper functionality and styling.

Let’s start by uploading the necessary files according to our project structure. Start with the root-level files such as index.html, along with any other essential files on the root-level. Ensure you follow your project structure carefully and upload all required files first to maintain proper structure.

Then click on the upload button:

On the Upload page, you will see the "Add files" and "Add folder" buttons. Let's start by uploading individual files. Click on "Add files" to begin selecting and uploading the necessary files.

After successfully uploading your files, ensure you follow your project structure. If your static site only requires individual files, proceed accordingly. But if your project relies on specific folders for assets like images and CSS, you’ll need to upload those as well. In my case, my project structure includes folders for images and CSS e.t.c, so I will be uploading both files and folders.

3. Upload project folders

To upload your folders click on the “Add folder” button.

Now, upload your folders by clicking on the "Add folder" button and selecting the necessary folders, such as those containing images, CSS, or JavaScript files, based on your project structure.

You will notice that as you upload folders, S3 automatically extracts and structures the files by name, type, and size. This can sometimes be confusing for beginners, as the files are displayed in a structured format.

Once you have successfully uploaded your files and folders, scroll down and click the "Upload" button to complete the process.

After clicking on "Upload", AWS S3 will begin uploading your files. You will see a progress indicator showing the status of each file being uploaded in real time.

Upon completing the upload, you will see a confirmation message stating "Upload Succeeded." AWS S3 will then generate a URL which you can find in the Summary section of the bucket’s details page. (Refer to the image below for reference.)

Congratulations! you have successfully uploaded your project into AWS S3. Now let’s make this accessible on the web.

Click on the "Close" button to exit the upload page. Now, while still in your bucket, let's configure the necessary settings and permissions to ensure proper access and functionality for our static website.

How to Set Permissions and Properties in AWS S3

After uploading your files, the next step is to configure permissions and properties to ensure your static website functions correctly.

• Permissions: By default, S3 objects are private. To make your website publicly accessible, you need to adjust the bucket policy and object permissions accordingly.

• Properties: You can configure various settings such as versioning, encryption, and static website hosting under the Properties tab of your bucket, but we won’t be going too deep as we are just going through the basics.

Let’s start with setting up permissions:

Permissions

By default, public access is blocked in S3 for security reasons. But for this tutorial, we will be enabling public access to ensure our static website is accessible to users.

In the image below, you can see that the public access is blocked by default:

To enable public access, click on the "Edit" button in the top-right corner. Then, uncheck the "Block all public access" option. After that, click on "Save changes" to apply the update.

Now you can see that the public access has been blocked:

Public access is now enabled. Click on "Save changes" to confirm and apply the update.

Enabling public access

AWS S3 will prompt you to enter a confirmation text to validate the settings. Input the required text and confirm, and public access will be enabled successfully.

So now that we have enabled public access, let’s set a bucket policy.

What is a Bucket Policy?

A bucket policy is a JSON-based access control policy that defines permissions for your S3 bucket. It allows you to specify who can access your bucket and what actions they can perform.

With a bucket policy, you can:

• Grant or restrict public access to objects in your bucket.

• Allow specific AWS users or services to interact with your bucket.

• Define read, write, or delete permissions for different users.

In this next section, we will configure a bucket policy to make our static website publicly accessible.

How to Set Up a Bucket Policy

Setting up a bucket policy is simple. Click on the "Edit" button in the Bucket Policy section and paste the following JSON policy into the editor:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

Understanding the policy attributes:

• Version: Defines the policy language version. The "2012-10-17" version is the latest and most commonly used for S3 policies.

• Statement: A list of rules that define what actions are allowed or denied.

• Sid (Statement ID): A unique identifier for the policy statement (optional but useful for reference).

• Effect: Specifies whether the rule allows or denies the specified action. In this case, it’s "Allow".

• Principal: Defines who has access. The "*" means anyone (public access).

• Action: Specifies the allowed operation. "s3:GetObject" allows users to retrieve (read) objects from the bucket.

• Resource: Defines the specific bucket and objects the policy applies to. Replace "your-bucket-name" with your actual bucket name. The "/*" means all objects within the bucket.

This policy makes all objects in the bucket publicly readable, allowing users to access your static website files via a browser.

if you followed closely, your bucket policy page should look like this:

Now, click on the "Save changes" button, usually located at the bottom right of the page, to apply your changes.

After following the required steps Bucket policy has been set and public access has been enabled.

Congratulations! You have successfully set up your bucket policy and enabled public access, meaning anyone can now access your website. But wait, where's the URL?

There's one last step: we need to enable static website hosting. To do this, you’ll need to navigate to the Properties tab and configure static website hosting so your site can be accessed on the web. I’ll walk you through the process in the next section.

How to Enable Static Hosting

Enabling static website hosting is simple. Scroll to the bottom of the Properties tab, and you will find the Static website hosting section. By default, this option is disabled. Let's enable it to make our website accessible on the web.

Click on the "Edit" button on the right side of the Static website hosting section. By default, this option is disabled, so change it to Enabled. Once enabled, you will see several configuration options, most of which are optional for this tutorial.

The most important setting here is the Index document, which specifies the default file that loads when someone accesses your site. The placeholder text indicates that it expects an index.html file. Simply type index.html in the Index document field to proceed.

After entering index.html in the Index document field, scroll down and click on "Save changes" to apply the configuration.

After successfully applying the changes, you should find your Static Website URL at the bottom of the Static website hosting section in the Properties tab of your bucket.

Congratulations! You have just hosted your website on AWS S3. That’s a solid step into the world of DevOps.

Your URL should look something like this: http://your-bucket-name.s3-website.your-region.amazonaws.com/.

Simply copy and paste your Static Website URL into your browser to see your hosted site live.

Now, you have the skills to host a static website for a client and share the URL with them.

So go grab some coffee and banana bread, you have earned it. Then we’ll move on to the next part of the tutorial.

Amazon CloudFront

Amazon CloudFront is a fast, highly secure, and programmable content delivery network (CDN) that improves website performance and security.

Our static website is hosted on S3(http://your-bucket-name.s3-website.your-region.amazonaws.com/) – but you might notice that the site is accessible via HTTP but lacks proper security measures such as SSL/TLS encryption. CloudFront addresses these limitations by providing a secure and scalable way to serve both static and dynamic content globally.

It delivers content to users with low latency by caching copies of your website at edge locations worldwide. When a user requests a resource, CloudFront serves it from the nearest edge location, significantly improving speed and availability.

Key Features of Amazon CloudFront

1. Secure content delivery: CloudFront supports SSL/TLS encryption, ensuring data is transferred securely between clients and servers.

2. DDoS protection: Integrated with AWS Shield, CloudFront helps mitigate Distributed Denial of Service (DDoS) attacks.

3. Global content caching: CloudFront caches content at multiple edge locations, reducing server load and latency.

4. Customizable distribution: Users can configure cache behavior, origin settings, and security policies.

5. Seamless integration with AWS tools: CloudFront integrates with AWS Lambda@Edge, S3, EC2, and API Gateway, supporting both static and dynamic content delivery.

6. Cost optimization: Reduces data transfer costs by caching and serving content from edge locations instead of directly from the origin.

Why Amazon S3 Alone is Not Enough

Amazon S3 is a scalable and durable object storage service, but it lacks key features required for securely serving web content.

First of all, it doesn’t have HTTPS by default. When hosting a site on S3, it is only accessible over HTTP unless additional configurations are made.

Second, it has higher latency. S3 buckets are hosted in a specific AWS region, which may result in slower content delivery for users in different locations.

It also doesn’t have built-in caching, which means that every request is served from S3, increasing response time and potential costs.

And finally, there’s no DDoS protection – unlike CloudFront, S3 does not provide native protection against cyberattacks.

Why You Should Serve Your Website with CloudFront

While Amazon S3 is a great storage solution, it lacks the security and performance optimizations needed for web hosting. Amazon CloudFront enhances security with SSL/TLS encryption, improves performance with global caching, and provides robust security features like DDoS protection.

By leveraging CloudFront, you can ensure your website is not only fast but also secure, scalable, and cost-effective.

To get started with hosting your site on CloudFront, navigate to the CloudFront service page in AWS. You can do this by going to your AWS Management Console homepage or dashboard and searching for “CloudFront” using the search bar in the top left corner. Click on “CloudFront” from the search results to proceed.

Once you navigate to the AWS CloudFront page, you will see a Create Distribution button. Click on it to begin setting up CloudFront for your website.

What is a CloudFront Distribution?

A CloudFront distribution is the configuration that defines how CloudFront delivers content to users. It acts as a link between your origin server (such as an S3 bucket) and CloudFront’s global network of edge locations. When a user requests your site, CloudFront retrieves content from the nearest edge location instead of always fetching it from the origin, ensuring faster load times, reduced latency, and improved security.

There are two types of distributions in CloudFront:

1. Web Distribution: Used for websites, APIs, and dynamic or static content.

2. RTMP Distribution (Deprecated): Previously used for streaming media (now replaced by modern streaming services).

For our S3-hosted website, we will be creating a Web Distribution to securely serve content over HTTPS while improving speed and reliability.

After clicking the Create Distribution button, you will be directed to the Create Distribution page, where you can configure various settings. In this tutorial, we will focus on the essential options.

1. Under the Origin section, select your S3 bucket as the origin domain.

2. If your S3 bucket has static website hosting enabled, AWS recommends using the S3 website endpoint instead of the default bucket endpoint.

3. Enter the correct S3 website endpoint in the Origin domain field. For example:

    freecodecampbuckettutorial.s3-website.ca-central-1.amazonaws.com
   

4. Ensure you use the S3 website endpoint rather than the standard S3 bucket URL to avoid issues with accessing your site.

By following these steps, you ensure that CloudFront correctly serves your static website from the S3 bucket.

Make sure that you use the S3 website endpoint rather than the standard S3 bucket URL to avoid issues with accessing your site. This will be suggested to you descriptively while filling in the origin name. Click on “Use website endpoint” and it will populate the field with the S3 bucket website endpoint instead of the bucket URL.

Next, scroll down to the Web Application Firewall (WAF) section at the bottom of the page and enable security protections to safeguard your website from common web threats. Select “Create Distribution” to deploy your CloudFront distribution.

Your CloudFront Distributions page should now display the newly created distribution. The page will include key details such as:

• Distribution ID: A unique identifier for your CloudFront distribution.

• Domain Name: The CloudFront-provided URL (for example, d1234abcd.cloudfront.net), which you can use to access your site.

After creating your CloudFront distribution, navigate to your Distributions page and check the Last Modified section for its status. If the status shows Deploying, you will need to wait until it changes, which may take several minutes.

Once the deployment is complete, the status will typically update to a timestamp, indicating that the distribution is ready for use. Ensure the status has changed before proceeding with further configurations or accessing your CloudFront distribution.

Your website is now successfully hosted on CloudFront!

We now have our CloudFront Domain Name (for example, d1234abcd.cloudfront.net), which you can find in the Details section of your distribution. Before making any further changes, let’s preview the site by copying and pasting the domain name into a web browser.

At this stage, when you try to access your website using the CloudFront Domain Name, you’ll notice that the site cannot be reached. This happens because CloudFront does not yet have permission to fetch content from your S3 bucket.

To fix this, you need to update your S3 bucket policy to explicitly allow CloudFront to access your objects. You can do this by adding a condition that grants access to requests coming specifically from your CloudFront distribution.

Understanding the Amazon Resource Name (ARN)

An Amazon Resource Name (ARN) is a unique identifier assigned to AWS resources. Every CloudFront distribution has its own ARN, which you can find at the top of the CloudFront distribution details page. It looks like something like this:

arn:aws:cloudfront::123456789012:distribution/E2ABC3XYZ456

This ARN is crucial because we use it in our bucket policy to restrict access to only our CloudFront distribution, ensuring no other services or users can retrieve data directly from our S3 bucket.

Updated S3 Bucket Policy

To allow CloudFront to serve content from our S3 bucket, we update the S3 bucket policy as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::[ACCOUNT_ID]:distribution/[DISTRIBUTION_ID]"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

Breaking down the bucket policy:

1. First statement that grants CloudFront access:

   • “Effect”: “Allow”: This permits access to the specified resource.

   • "Principal": { "Service": "cloudfront.amazonaws.com" }: Grants access specifically to CloudFront.

   • "Action": "s3:GetObject": Allows CloudFront to retrieve objects from the S3 bucket.

   • "Resource": "arn:aws:s3:::your-bucket-name/*": Grants access to all objects in the S3 bucket.

   • “Condition”: Ensures that only requests originating from our CloudFront distribution are allowed using:

       AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E2ABC3XYZ456
     

2. Second statement (optional, and grants public access)

   • This statement allows all users (Principal: "*") to access the S3 objects.

   • If you want to restrict access only to CloudFront, you can remove this second statement.

After editing and updating your S3 bucket policy to allow CloudFront access, you can refresh the page where you preview your CloudFront domain name (for example, d1234abcd.cloudfront.net). Open it in a browser, and if you have carefully followed all the instructions, you have successfully hosted a static site on S3 and CloudFront.

Your website is now fully protected, well done! Congratulations, DevOps pro!

FIST BUMPS!

Conclusion

In this guide, we’ve only scratched the surface of what AWS can do. S3 and CloudFront are powerful services, but there’s still so much more you can explore, from advanced security settings to automation and performance optimizations.

As you continue your AWS journey, you can dive deeper into topics like caching strategies, custom domain configurations, and integrating AWS Lambda@Edge for dynamic content. The possibilities are endless.

This is just the beginning, and you’re off to a great start. Keep experimenting, keep learning, and soon we will be mastering even more advanced AWS capabilities. Happy building! 🚀

• A little about AWS
• What are the benefits of serving from S3 and CloudFront?
• Before we start, you’ll need an AWS account
• Storing your website on S3
• Serving your website on S3
• Distributing your website on CloudFront
• Custom domain names
• Advanced AWS Usage
• Resources

A little about AWS

If you’re not familiar, AWS (Amazon Web Services) is a cloud service provider that gives developers opportunities to build pretty much anything they can imagine in the cloud.

Though their services extend beyond the likes of machine learning and artificial intelligence, we’re going to stick with the entry level services for the purpose of this guide that will allow us to easily host an HTML website.

Types of AWS services available

Building a site with S3 and CloudFront is a common recipe that small and high scale companies across the web use, but let’s break down what each service actually does.

Object storage with S3

S3 (Simple Storage Service) acts as your hosting for your static website. Think of it like a hard drive in the cloud which we’re not able to use it for processing purposes, but rather for simple file storage and access.

List of files from a static site in an AWS S3 bucket

When an app or website is compiled in static form, this is all we need to serve it to the people visiting our site. The HTML is sent in the initial request “as is” (unless there’s processing with your provider) and any additional work occurs after the page loads in the browser usually by JavaScript. This allows us to take this simple (and cheap) approach by serving these files from S3.

Content Delivery Network with CloudFront

CloudFront works as a CDN (Content Delivery Network) that sits in front of your website, caching the files, and serving them directly to the people visiting your site.

CDN Diagram

Where you host and serve your website from, typically called the origin, is the main source of your files and can serve the website itself. But putting a CDN in front of it provides the people accessing your content a shorter and faster way to make their request.

What are the benefits of serving from S3 and CloudFront?

Given the rise in the JAMstack era, many services are popping up that provide similar services for static sites that make it really easy to deploy. Some even come with a generous free tier like Netlify and Zeit!

But sometimes developers need a little bit more control over their services or they need to integrate into a larger cloud pipeline that’s already 99% percent in AWS, which is exactly where S3 shines. Also, chances are, during your first year you might still qualify for AWS’s free tier.

Fitting in to the AWS Well-Architected Framework

As a lead provider in cloud services, AWS has published many guides to help developers and teams strive for excellence in their solutions in terms of performance, cost, and security.

One particular guideline is their 5 pillars of what they describe as a “well-architected" infrastructure.

AWS Well-Architected Framework

By default, we check all of these boxes with our hosting solution by using S3 and CloudFront. Out of the box, the HTML and assets you serve will be fast, cheap, secure, and reliable.

The beauty of static and JAMstack sites

Building on top of the pillars, what you’re actually serving is a static HTML file and group of assets that won’t require any type of rendering resources on the initial request. Before this, a common problem was having to worry about a site crashing due to heavy load. But with S3 and CloudFront, your website is infinitely scalable.

On a similar note, when that server scales up as it's trying to serve millions of hits on your post that went viral, so will your costs. Serving a static site is cheap and can greatly reduce the cost associated with running a web server.

Before we start, you’ll need an AWS account

To work through this guide, you’ll need an AWS account. Luckily, it's free to create an account – you’ll only pay for the services used.

On top of that, AWS provides a generous free tier for some of its services. Some services provide only 12 months of a free tier (like S3) where others are always eligible for the free tier (like Lambda), so make sure to do your homework so you don’t rack up an unexpectedly high bill.

To create your account, head over to the AWS website and then continue on to get started: https://aws.amazon.com/.

Storing your website on S3

To get started, we’re going to begin with a simple HTML file that will serve as our website. This will allow us to focus more on the process of hosting rather than the intricacies of the website itself.

Creating our website file

Begin by creating a new folder called my-static-site. Inside that folder, let's create a new file called index.html and add the following to the file:

<!DOCTYPE html>
<html lang=“en”>
<head>
  <meta charset=“UTF-8”>
  <meta name=“viewport” content=“width=device-width, initial-scale=1.0”>
  <title>My Static Website</title>
</head>
<body>
  <h1>Hello World!</h1>
  <p>This is my static website. ?</p>
</body>
</html>

If you open this file from your computer in your favorite browser, you should now be seeing this.

Hello World! Opening a local webpage

Creating a new bucket

Head on over to your AWS account, log in, and navigate to your S3 console.

Once there, let’s create our bucket by clicking on the blue Create bucket button:

Creating a bucket in AWS S3

The first thing AWS wants us to do is enter a Bucket name. The bucket name must be globally unique, meaning, the name you use can be the only one in the world, so let’s try something like [yourname]-static-website, where I’ll use colbyfayock-static-website.

Naming a bucket in AWS S3

Next, let’s set the Region. This is the geographic location where AWS will host the bucket and your website. You’re probably fine with the default, but if you’d like, you can select the location closest to you if it’s permitted. Since I’m in Virginia, I’m going to stick with my default of US East (N. Virginia).

Setting the region of a bucket in AWS S3

Finally, hit the Create button on the bottom left of the page.

Note: even if you use the [yourname]-static-website pattern, there’s a chance the name will be taken. If it’s taken, AWS will show an error stating “Bucket name already exists,” at which point you’ll want to try a new name of your choosing.

Alternatively, you can hit Next for advanced usage, but for this guide, we’re okay with all of the defaults S3 provides.

If successful, you should now see your bucket in the list on the S3 console dashboard.

New bucket in AWS S3

Uploading your website to the bucket

Let’s navigate to our new bucket by clicking the row of our bucket. You’ll be greeted with a message stating “This bucket is empty. Upload new objects to get started,” so that’s what we’ll do.

Click the Upload button to get started.

Uploading files to AWS S3

You’ll then see a popup that will ask you to upload a file. Click on the Add files button and select your index.html file we created earlier.

Once selected, click the Upload button on the bottom left.

Selecting files to upload in AWS S3

And now your file is uploaded to S3!

Serving your website on S3

If you try to navigate to your index.html file and open it, you’ll notice a big ugly "Access Denied" message.

Access Denied to bucket file

This is because your file doesn’t currently have the permissions and settings necessary to serve the file to the public, so let’s fix that.

Setting up your bucket as a website

Navigate to the Properties tab inside of your bucket, then click Static website hosting.

Setting up an AWS S3 bucket for statice website hosting

Once there, we want to do a few things:

• Note down the Endpoint at the top of the block. We’ll use this to access our site later (you can always find this here again)
• Select the “Use this bucket to host a website” option
• Enter index.html in the Index document field
• Finally hit Save

Configuring an AWS S3 bucket for static website hosting

Setting up your bucket policy and permissions

Next, navigate to the Permissions tab. Here we’ll want to do 2 things: unblock all public access and add a Bucket Policy.

First, on the main page, let’s click Edit to unblock all access.

Configuring an AWS S3 bucket permissions

Then, uncheck the “Block all public access” checkbox and hit Save.

Allowing public access to an AWS S3 bucket

AWS will ask you to confirm these settings, as this may not always be what you want to do with your bucket. But for the purposes of hosting a website, we want the whole world to see, so type in the word “confirm” and hit the Confirm button.

After confirming, click the Bucket policy button and you’ll be taken to a text editor.

In this text box, we’ll want to paste the following snippet. Within this snippet, make sure to replace [your-bucket-name] with the name of your bucket, otherwise you will not be able to save this file.

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"PublicReadGetObject",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::[your-bucket-name]/*”
      ]
    }
  ]
}

This policy states that it’s allowing the public to perform a GetObject request on the S3 resource, which is your S3 bucket.

Setting up a public policy for an AWS S3 bucket

After you add the policy, click the Save button. Your should now see a message stating "This bucket has public access.”

Previewing your new bucket website

If you noted down the Endpoint from your Properties page, you can now visit that address to see your website. The endpoint should look like this:

http://[your-bucket-name].s3-website-[region-id].amazonaws.com

If you didn’t, jump back up a few steps to remind yourself how to find it or look under the Properties tab.

Hello World! Opening an AWS S3 website

Congrats, you're halfway there! ?

Distributing your website on CloudFront

Now that we have our static website being served from a bucket on S3, let’s take it up another level and serve it across the world using CloudFront.

Creating a CloudFront distribution

Navigate to your CloudFront dashboard and click the Create Distribution button.

Creating a new distribution in AWS CloudFront

Next, select Get Started under the Web delivery method.

Getting started with an AWS CloudFront distribution with Web delivery

Here, we’ll enter a few custom parameters to get our distribution set up.

Click into the Origin Domain Name field. Once selected, a dropdown list should appear where you can select the S3 bucket you just created. Go ahead and select your S3 bucket.

Setting the origin domain name in AWS CloudFront to your bucket

While you can customize most of the settings to your liking, for our purposes, we’re going to leave all as their default values except for one.

Scroll down to the Default Root Object field and type index.html.

Setting the Default Root Object for a distribution in AWS CloudFront

After, scroll down to the bottom and click Create Distribution in the bottom right.

Creating an AWS CloudFront distribution

Previewing your new CloudFront distribution

After hitting the Create button, it will take some time for your distribution to be created and set up. You’ll notice on the CloudFront Distributions list page that the Status of your new distribution is In Progress.

AWS CloudFront distribution deployment is In Progress

Once this completes, it will say Deployed. Then you can find your Domain Name in the same row.

AWS CloudFront distribution is Deployed

Using the value in the Domain Name column, open your distribution in your browser and success! You now are viewing your S3 bucket through CloudFront’s distribution network.

Hello World! Opening an AWS CloudFront website

Custom domain names

While most of us will probably want to use a custom domain name with our website, we’re not going to dive too deep into that this guide, as there are many ways to set that up depending on where you purchase your domain name.

However, here are a few things to consider.

HTTPS / SSL Certificate

If you’re creating your CloudFront distribution to use with a custom domain name, you'll most likely want to configure your distribution with an SSL certificate using AWS’s Certificate Manager. Alternatively you can provide your own certificate with tools like Let's Encrypt, but by using ACM, AWS makes it easy to pull in the records for use with your distribution.

Once in ACM, you’ll want to configure the certificate, map what domains and subdomains should match (typically *.domain.com), and then create your certificate to use with your distribution.

To get started, you can check out the AWS guide for requesting a public certificate.

CNAMEs and Aliases

A common approach to setting up a custom domain is to use a CNAME. CloudFront makes this pretty painless, as you’ll add it as a configuration option when you’re configuring your distribution.

To get started with setting up a CNAME in CloudFront, see the AWS guide.

If you’re using Route53 to manage your DNS, you can then set up an A record (alias) to point to your distribution. You can learn more using this guide.

Advanced AWS Usage

For this guide, we walked you through setting up a new static website and app using the AWS console. But whether you want to learn more, improve your deploy efficiency, or want to automate this process, you’ll want to take a it a step further with the AWS CLI or CloudFormation.

While we won’t walk you through how to use these tools here, we’ll get you started with a little bit of an idea of what you’re up against.

AWS CLI

The AWS CLI allows someone to perform AWS operations from the command line. This can be incredibly powerful when you want to script out your resource creation or if you simply prefer to do all of your work from the terminal.

Once set up locally, you’ll be able to perform actions like creating a bucket using the following command:

aws s3api create-bucket —-bucket [your-bucket-name] —-region [bucket-region]

To get started, check out the AWS CLI Github page or the AWS CLI User Guide .

AWS CloudFormation

AWS preaches “infrastructure as code.” It’s the idea that you can spin up your infrastructure using something that’s written in a file, where in this particular case, it would be a CloudFormation template. This allows you to have a repeatable process that will be the same each time you perform the deploy.

CloudFormation allows you to set up a configuration file that will deploy the services and resources of your choosing by pointing to that file with the CLI or by uploading it in the console.

Here’s an example from AWS of what that looks like for a static S3 bucket that could serve as a website.

AWS CloudFront template example

To get started, check out AWS’s CloudFormation example templates or their Get Started guide.

Resources

If you’re interested in getting deeper into the AWS ecosystem, here are a few resources to get started:

• AWS Certified Cloud Practitioner Training 2019 - A Free 4-hour Video Course (freeCodeCamp.org)
• Introducing The #AWSCertified Challenge: A Path to Your First AWS Certifications (freeCodeCamp.org)
• 10-Minute Tutorials (AWS)
• A Cloud Guru (Paid courses)
• AWS Case Studies (AWS)

I recently set-up my self-hosted personal blog and I underestimated the effort I had to put in to make it exactly as I wanted. So I decided to write a tutorial to help others do it with less overhead.

This article will go into fine details on how to tick all the boxes below, with a focus on the backend components.

1. Pay-as-you-go hosting
2. SSL certificate
3. Functional www subdomain
4. Highly customisable but minimalistic design
5. Markdown-powered articles

For 4 and 5 above, I used Hugo with the Minimal theme.

Caveat

Do note that this is a verbose tutorial, aimed at those who value flexibility and interoperability with other AWS services more than anything else. If you’re just looking for something light and quick, you may want to use Netlify or Amplify.

Prerequisites

I will further assume that:

1. You designed and coded your website or at least have a mockup.
2. You have an AWS account (if not, go register one. AWS Accounts include one year of free tier access).
3. You are familiar with DNS and how it works, at least at a high level.

Regarding DNS, a quick explanation is that it’s sort of the directory of the Internet and, just like Google owns google.com, you can own your own domain such as example.com as well. To do it, you have to go a DNS registrar and purchase your the domain you want. I strongly recommend using Namecheap as your registrar, as they have an awesome UI and low prices. As an alternative, you could choose GoDaddy.

In case your “.com” domain is taken and you want some clever mashups, the following sites would be helpful:

• LeanDomainSearch
• Wordoid
• Domainr

After you purchase it, don’t set any DNS records yet. We’ll do that later once we get to Route53.

Hosting with Amazon AWS

As mentioned above, the goal is to use a pay-as-you-go service because it’s by far the most cost-effective option out there. I used to pay a fixed cost in the range of tens of USD per month for a server even if I had periods when there was hardly any activity on it.

However, from my experience, I would recommend that you go modular and go with a pay-as-you-go service such as AWS.

Before jumping in, it’s important to grasp the nomenclature:

• AWS: Amazon Web Services
• S3: Simple Storage Service, for storing files
• Route53: A service for handling DNS records
• CloudFront: content delivery network (CDN) for speeding up your website, also required to generate the SSL certificate

Here’s a neat Mindmap designed with Cloudcraft for what you’re going to build:

We’ll first focus on the path on the right-hand side, so the normal configuration (with Route53, CloudFront and S3), not the one for the www subdomain. Importantly, using this modular configuration, you won’t run any backend Linux server at all, so you don’t have to worry about updating or patching anything. How convenient is that?

Amazon Simple Stoarage Service (S3)

This is where you’ll store your static files (HTML, CSS, JavaScript). If you used Create React App or some other frontend development framework, look for your generated “build” or “public” folder.

Here’s what you have to do:

1. Set up an S3 bucket named “example.com”. Notice that S3 bucket names are global and, just like with domains, you’ll have to find another name if someone has taken example.com before you. Based on your needs, you can enable or disable the options AWS provides you: versioning, server access logging, encryption, etc.
2. Make sure to uncheck the boxes that mention blocking and removing public access ACLs and policies. Many times, S3 buckets are used to store private data, so AWS optimises the configuration for highly secure configurations. In your case though, you want to have the bucket publicly accessible.
3. Make sure to set a policy, here’s an example.
4. Activate “Static website hosting” for your bucket and check “Use this bucket to host a website”
5. Upload your files, making sure “index.html” is at the root of your bucket

All the operations above can be done using either the AWS Management Web Console or the AWS CLI. Specifically for step 4 though, I’d recommend doing it in the console so that you can get the endpoint for your new hosted website (I hid mine for privacy reasons):

Test it out in the browser to make sure you set up your S3 bucket correctly. It should like this:

example.com.s3-website.your-region.amazonaws.com

CloudFront

To host a static website, you don’t actually need CloudFront or any other CDN, because there’s not much data to store and the gains in efficiency and UX are little. However, one of the original goals was to have a website secured by an SSL certificate so we’ll be using CloudFront.

Now, you might’ve heard about CloudFlare, which is arguably the easiest way to get up and running with a CDN and it also provides the benefit of some SSL security. I say “some” because they have this misleading feature called “Flexible SSL”, which doesn’t have the security guarantees a self-signed SSL certificate has.

Therefore, you’re not going to use that, but instead make use of a similar service in AWS called CloudFront. You can think of it as having your own content distribution servers, as data is cached in multiple locations around the world to provide your users fast response times. More important for the static website, it also makes using an SSL certificate possible.

Again, you can create your CloudFront distribution using the AWS administrator interface or the CLI tool. Here’s an example configuration.

Caveats:

1. The origin name should be the endpoint you got after activating “Static website hosting” on your S3 bucket.
2. Do NOT set any “DefaultRootObject”. Leave it empty.
3. Allow both HTTP and HTTPS. You’ll be able to automatically redirect users from HTTP to HTTPS after the certificate is signed and installed.

Make sure to wait a while for the distribution to properly boot (can take up to 15 minutes). Test it by opening the endpoint you receive, your S3 static website should pop up. The endpoint should look like this:

13fb4knzujxq0b.cloudfront.net

Note down your CloudFront endpoint somewhere because we’ll use it with Route53 in a sec.

Route53

It’s time to connect the domain you bought on your DNS registrar with CloudFront and S3. Route53 acts as the bridge for that.

Here is what you’ll have to do configure Route53 and connect the domain with CloudFront:

1. Create a Route53 hosted zone and set your domain. Make it public.
2. You’ll be given 4 NS records. Copy and paste the nameservers in your external domain administration page. If you’re using Namecheap, here’s how you can update your nameservers. Within Namecheap, Go to Account -> Dashboard -> Manage -> Nameservers -> Custom DNS and put your 4 nameservers in there:

3. Create a record set and leave the name empty (it will default to example.com). Then you’d need to:

4. Set the type to “A — IPv4 address”

5. Respond with “Yes” to “Alias” and set the alias target to your CloudFront distribution URL.

6. Keep the routing policy as “Simple” and, based on your budget and needs, enable or disable “Evaluate Target Health”.

7. Repeat step 3 for type “AAAA - IPv6 address” if you enabled your CloudFront distribution to be IPv6 compatible. If you followed this tutorial, IPv6 was enabled by default.

Note that DNS propagation can take up to 72 hours, although it should be normally updated within a few hours or faster. If you previously set any other DNS records (like MX for work emails), you’ll have to reset them in Route53.

Setting up your WWW subdomain

Congrats for getting this far! I’m sorry to let you know that now you have to repeat all the previous three steps. Yes, you heard that right, because of the elusive way the Internet works, www is not something included as a holistic component of HTTP.

It is important to point out that it’s really not mandatory to add a www subdomain to your website and you can safely proceed to the next step if you’re fine with your end users not being able to access your website via www.example.com. I was a bit pedantic about it and I simply had to add the www subdomain.

Notes:

1. Redo only the steps for S3, CloudFront and Route53, you don’t have to (and can’t) go to Namecheap to buy www.example.com.
2. For all the fields where you were asked to put example.com, now put www.example.com.

If you wonder whether by creating S3 buckets, it means you are required to deploy your static files to both of them, the answer is no, you don’t have to do that. When you activate “Static website hosting” for your second S3 bucket, select “Redirect requests” instead of “Use this bucket to host a website”:

SSL Certificate

LetsEncrypt is one of the best things that happened to the Internet in the last couple of years. They have democratised access to SSL certificates and this is a huge accomplishment, kudos to them! If LetsEncrypt was so helpful to you, consider making a donation.

This step is crucial and also the hardest in the whole tutorial, so proceed carefully. You could use either your own machine or a Linux server to generate the certificate, but I chose the former option, it’s simpler and less expensive.

1. Head to the certbot-s3front repo and install the tool. You need to have Python and pip installed.
2. Follow their instructions, but (1) skip the S3 and CloudFront parts, you had already done that and (2) set “example.com,www.example.com" as the value for the “-d” (domain) parameter. Read more about this on the LE forum.
3. After you successfully generate your SSL certificate, you could optionally enable “Redirect HTTP to HTTPS” on your naked domain (that is, “example.com”) CloudFront distribution. Don’t do this for “www”, as it’ll redirect to your naked domain anyway.
4. Make sure to backup your /etc/letsencrypt/live/example.com certificate(s).

Notes:

1. Due to mysterious reasons, I couldn’t make certbot’s authentication work by setting the “AWS_ACCESS_KEY_ID” and “AWS_SECRET_ACCESS_KEY” environment variables. This might be caused by the fact that I have several different profiles in my ~/.aws/credentials, but I'm not sure. To avoid a "NoCredentialsError", just temporarily set a "default" profile and certbot will pick that up.
2. If you’re unlucky like me and you get a further “IAMCertificateId” error, check out this solution.

ACM

Shortly after this article was published, a lot of people jumped in to say that it’d be much easier to use the AWS Certificate Manager (ACM) for generating certificates. No need to think about renewals, but it means you’re locked in with AWS.

Bottlenecks

1. No server logic: This tutorial is only applicable to static websites, so you cannot run any backend logic using a Node.js module like ExpressJS. For that, you can either spin up an EC2 instance, write Lambda functions or use Docker via ECS/ Kubernetes.
2. LetsEncrypt certificates expire in 90 days: You can solve this in two ways. Firstly, you could set a reminder in your calendar, which I admit is suboptimal, but I’m in an experimentation phase so I'm not bothered by a bit of manual work. Secondly, you could set a cron job, but you need a Linux server and use the “ — renew-by-default — text” options when interacting with certbot.
3. Rich link previews can be a mess: This could be a problem specific to my Hugo theme, but I also think everyone wants to have a proper preview image and description when sharing their website links. Here’s how I managed to do it.

Wrap-Up

Congrats, you now have a really cheap but still highly flexible static website! Billing stats for 100 - 1000 monthly active visitors and fairly frequent S3 deployments are between $1 and $2, so this is a steal! For usage way beyond that, you may need to upgrade your AWS components, but this is outside the scope of this tutorial.

If you’re an experienced developer interested to replicate this tutorial on multiple AWS accounts, you may want to check out Terraform. It’s a super duper cool Infrastructure-as-a-Service tool which you can use to define your S3, CloudFront and Route53 as code snippets. Isn’t technology so dang amazing?

Hope you find this tutorial helpful! Find me on Twitter or Keybase if you want to chat.

Credits

• Amazon for the AWS, S3, CloudFront and Route53 logos

Originally published on paulrberg.com