Exploring Cloud Solutions: Implementing Cloud Architecture Patterns for Fictional Companies

Alex’s AWS Adventures - Part 1: Hosting a Static Website Using Amazon S3

Introduction

Welcome to my new blog series, “Exploring Cloud Solutions: Implementing Cloud Architecture Patterns for Fictional Companies.” In this series, we embark on a journey to explore common scenarios faced by businesses venturing into the cloud and guide you in building robust and scalable architecture patterns to address those challenges. Whether you’re a beginner or an experienced cloud enthusiast, this series aims to provide practical insights and step-by-step instructions to help you architect cloud solutions with confidence.

Each blog post in this series will revolve around a fictional company, allowing us to delve into the unique cloud requirements they encounter. Through these scenarios, we’ll not only unlock the mysteries of cloud solutions but also learn how to apply best practices and industry-standard architectural patterns to achieve efficient and resilient cloud architectures.

Scenario:

Let’s meet Alex, a talented freelance web developer who has been gaining significant traction in his field. His portfolio website showcases his impressive projects and skills, attracting an increasing number of visitors each day. As his business grows, Alex realizes the need to scale his website and ensure its availability and performance. He decides to migrate his portfolio site to AWS. He wants the solution to be cost-effective and secure, and he doesn’t want to manage any web servers.

Solution:

Host the portfolio using Amazon S3 and leverage CloudFront for encryption in transit and caching.

AWS has a variety of services that can be used to host a website, but for this scenario, we are given specific requirements:

1. Cost-effective
2. Secure
3. Serverless

In order to meet those requirements, we’ll be using a common architecture that utilizes an S3 bucket configured to host a static website, CloudFormation to secure our site (along with other benefits), and Route53 to create a custom domain.

This solution is simple and inherits its high availability and scalability from the S3 bucket which provides our customer with 11 9’s of durability, and 99.5% — 99.9% availability. S3 has the ability to automatically scale to meet demand, and its pay-for-what-you-use pricing model affords the customer a cost-effective yet reliable solution.

AWS Services Used:

• Amazon S3
• Route53
• CloudFormation
• Certificates Manager

Prerequisites:

• Static site code (HTML, JS, CSS)
• Some working knowledge of AWS
• An active AWS account

Let’s get building!

In this initial post, we are only going to cover Part 1: Hosting a Static Website Using Amazon S3. We will dive into CloudFront and Route53 in Part 2: Securing and Optimizing Your Static Website.

Assuming you have already logged into the AWS Management Console, we are going to navigate to S3 where we will be creating our bucket. From the console, search for “S3”, and then navigate to the S3 service.

From here, click “Create bucket.”

All bucket names in AWS must be globally unique. This means any bucket you create must have a name that is not being used by any other AWS customer. We are going to name this bucket “techco-product-landing-page.”

Give your bucket a unique name, and then scroll down to the “Block public access” section and toggle the “Block all public access” off.

Be sure to acknowledge the warning shown above. This message is letting us know that by turning this off, your bucket may be publicly accessible. This is what we want for this solution, but this would not be wise for buckets that host sensitive data.

We are going to leave all of the other settings as default. Scroll to the bottom of the page and click “Create bucket.”

Once the bucket has finished creating, you’ll be taken to a page that shows all the buckets in your account. By clicking on the bucket you just created, you’ll be taken to that bucket's dashboard where you can now upload your source code for the static website.

In the dashboard, click upload, then select the files and folders that make up your site.

Now that we have all of our files imported, let’s click “Upload.”

This process will take up to a few minutes depending on how many files you have chosen to upload. Once the upload is complete, click “Close” to be taken back to the bucket’s dashboard.

Once you’re back at the dashboard, you’ll want to click the “Properties” tab and then scroll to the bottom of the screen to find the “Static website hosting” settings.

Click “Edit” and then switch the toggle from “Disable” to “Enable.” This will reveal more settings for us to review.

We are going to leave the “Hosting type” as “Host a static website”, and enter “index.html” in the “Index document” field. If your web page’s default page is named something different, enter that in the “Index document” field.

The “Error document” is optional, but feel free to add one if you’ve created one for your site.

Now that we have the necessary properties configured, we’ll scroll down and click “Save changes”, bringing us back to the bucket properties. Scroll down again to see the new URL for your bucket. This will be the endpoint used to access your site.

If we click the link, you’ll see that we get an “Access denied” message. This is because Amazon S3 enforces a security-by-default policy. New objects in a new bucket are private by default. Even though we turned off the “Block all public access” setting, we haven’t configured a bucket policy that states who can access the bucket, the objects they can access, and the action they can take on those objects.

To create the bucket policy, we’ll switch over to the “Permissions” tab in the bucket dashboard, scroll down to “Bucket policy”, and click “Edit.”

Here is the bucket policy we’ll use to grant public access to the bucket:

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

Copy and paste this policy into the policy editor, replace “Bucket-Name” with the name of your bucket, and click “Save changes.”

Without going into too much detail, this policy will allow anyone to get any object from the bucket specified in the policy.

Now that we have updated the buck policy, we can try to access the site again by going back to the “Properties” tab, scrolling to the bottom of the page, and clicking the link to the static website endpoint.

It looks like that worked! We’ve made it to the end of Part 1, and I hope you’ve enjoyed this tutorial.

In the upcoming Part 2: Securing and Optimizing Your Static Website, I’ll show you how to create a CloudFront distribution that will allow you to implement encryption in transit with HTTPS and attach a custom domain name to your distribution.