Lab: Host a Static Website on AWS

Lab overview and objectives

In this lab, we will use Amazon Simple Storage Service (Amazon S3) to build a static website and apply architectural best practices to protect and manage data. We will explore the following topics step by step:

🌐 Host a static website using Amazon S3 Learn how to configure your S3 bucket to serve HTML, CSS, and image files to users through a static website endpoint.

🔐 Implement one way to protect data in Amazon S3 Discover how to enhance data security with access controls, encryption, and versioning.

💰 Apply cost optimization in Amazon S3 Explore S3 storage classes and lifecycle rules to reduce storage costs while maintaining data availability.

1️⃣ What is a Static Website?

A static website is made up of pre-built files such as HTML, CSS, JavaScript, and media files (like images or videos) that are delivered directly to the user’s browser exactly as stored. There’s no server-side processing or database interaction at runtime.

For a static site on Amazon S3, index.html is expected as the default landing page unless you configure something else. Web browser Automatically look for index.html when loading a folder or root path, without its Users may get a 403 or 404 error if no default page is defined.

2️⃣ In Which Cases Can a Static Website Help?

A static website is ideal in situations where the content remains mostly unchanged and doesn’t require server-side processing or database interactions. It’s a cost-effective, fast, and secure option for many common scenarios, such as:

• Blogs and Personal Sites — Simple articles, posts, and pages that don’t require dynamic content.
• Portfolio or Resume Websites — Great for showcasing your work or CV with static visuals and descriptions.
• Microsites for Marketing Campaigns — Temporary or one-time pages promoting products, services, or events.
• Documentation Sites — Hosting static technical or user documentation for products or APIs.
• Landing Pages — Quick-to-deploy pages focused on collecting leads or presenting key info.

3️⃣ Architectural Design

The goal of this lab is to host a static website using Amazon S3. To achieve this, we will follow a simple and effective architecture that balances security, availability, durability and cost optimization. The minimal architecture would look like the following:

4️⃣ Implementation

We will now go step by step through the implementation.

✅ Task 1: Creating an S3 Bucket to Host Your Static Website

To start, let’s remind that for static website, your files (like index.html, style.css, images) need to be publicly readable, so that anyone on the internet can access them via the browser.

By default, Amazon S3 applies strict security settings

• S3 buckets are private for security.
• “Block all public access” is enabled by default to prevent unintended data exposure.
• ACLs are disabled in most cases, especially if you’re using bucket policies.

1. Uncheck “Block all public access” because

• This setting overrides all permissions, even if you allow public access through a bucket policy or ACL.
• To serve a static website, you must allow public read access to your objects (HTML, images, etc.).
• If “Block all public access” is ON, nothing you configure in policies or ACLs will make the files publicly viewable.

2- Enable ACLs (Access Control Lists) to allow us create policy on the next step. Bellow steps are done to create Amazon S3 Bucket:

a- Select S3 in AWS services list

b- Create Bucket, make sure you are in your desire region

c- Put the bucket name, for instance “mybucket-danlab01”

d- Check “ACLs enabled”

e- Unchecked “Block all public access”

f- Click on “Create bucket”

✅Task 2: Creating a bucket policy to grant public read access

Even after disable “Block all public access”, the site is still no accessible when using bucket URL in the browser, it’s gives a 403 Forbidden or 404 Not Found error.

By default, all S3 buckets are private, and only users who are explicitly granted access to S3 buckets can access those buckets. So, even if you’ve disabled the “Block all public access” setting on your S3 bucket (which allows public access in theory), the bucket still won’t actually be public unless you explicitly tell AWS to allow it. This can be done using a bucket policy.

To create a bucket policy that grants read-only permission to public anonymous users by using the bucket policy editor we will follow below step:

a- Under Buckets, choose the name of your bucket.

b- Choose Permissions.

c- Under Bucket Policy, choose Edit.

d- To grant public read access for your website, copy the following bucket policy, and paste it in the Bucket policy editor.

e- In the preceding example bucket policy, mybucket-danlab01is a placeholder for the bucket name. To use this bucket policy with your own bucket, you must update this name to match your bucket name.

f- Choose Save changes.

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

✅Task 3: Uploading content to your S3 bucket

In this step, you will upload all content files of your static web site in Amazon S3 like below.

a- Under Buckets, choose the name of your bucket.

b- Click on “upload”

c- Dag and drop the file of static website

d- Click on “upload”

✅Task4: Enable static website hosting on your bucket

Enabling static website hosting turns your S3 bucket into a basic web server that is capable of hosting static websites. Without this feature, your files remain stored but not served with the website.

When you enable static website hosting:

· you define the index document (e.g., index.html) and an error document (e.g., error.html) for better navigation and user experience.

· AWS creates a website endpoint URL (e.g., http://your-bucket-name.s3-website-region.amazonaws.com).

To enable static website hosting, below step needs to follow:

a- Under Buckets, choose the name of your bucket.

b- Choose “Properties” and scroll down till “Static Website hosting”

c- Click on “Edit”

d- Select “Enable”

e- Set-up the home or default page of the website, her “index.html”

f- Set-up the error page, the one that appearing when an error occurs.

g- Finish by clicking on “Save changes”

5️⃣Security configuration

Now that our static website is publicly accessible, it’s important to ensure it remains secure and follows best practices. Let’s keep in mind the default security configurations of Amazon S3, which are designed to protect your data from unauthorized access and accidental loss.

Amazon S3 Default Security Features:

• All newly created buckets and objects are private, restricting public access unless explicitly allowed.
• S3 applies encryption at rest by default, helping protect stored data.
• SSE-S3 (Server-Side Encryption with Amazon S3 Managed Keys) is the default encryption method, automatically encrypting your data using Amazon-managed keys without requiring additional configuration.
• Amazon S3 is built for extremely high durability, ensuring your data is not lost over time (11 nines — 99.999999999%).
• Amazon S3 is High Availability (4 nines — 99.99%), the service is designed to keep your data readily accessible, minimizing downtime.
• S3 stores your objects redundantly across multiple Availability Zones within the selected Region to protect against hardware failures.
• S3 regularly verifies your data using checksums, automatically detecting and correcting any corruption.

✅Task 5: Enabling versioning on the S3 bucket

Amazon S3 provides a versioning feature to protect objects from accidental overwrites and deletes. You can use versioning to recover from both unintended user actions and application failures.

a- Under Buckets, choose the name of your bucket.

b- Choose “Properties” and scroll down till “Bucket Versioning”

c- Click on “Edit”

d- Select “Enable”

e- Finish by clicking on “Save changes”

At this stage, you can verify if you have access to your static web site through a web browser.

a- Under Buckets, choose the name of your bucket.

b- Choose “Properties” and scroll down till “Static Website hosting”

c- Select under “Bucket website endpoint” the website endpoint URL.

d- Open a browser and paste the URL on research bar. Your static website should appear normally.

✅Task 6: Enabling cross-Region replication

Amazon S3 automatically stores your objects redundantly across multiple Availability Zones (AZs) within the same Region. This provides high durability and availability within that Region. If there’s a Region-wide outage (e.g., due to natural disaster or large-scale failure), your data could be temporarily inaccessible.

Cross-Region Replication (CRR) provides geographic redundancy to help you recover faster from regional outages by having a copy in another Region.

To enable CRR we need to create another bucket (Target bucket) in a region different from our bucket source. We will complete the process with below steps:

a- create a second bucket (destination bucket) In a different Region than the Region for the source bucket and enable versioning on it (myawsbucketinohioregioncrr).

b- in our target bucket, we will enable CRR and create replication rule with below constraints:

· Create and use AWS Identity and Access Management (IAM) role CafeRole , that gives to Amazon S3 the permissions to read objects from the source bucket and replicate them to the destination bucket.

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Action": [
    "s3:ListBucket",
    "s3:ReplicateObject",
    "s3:ReplicateDelete",
    "s3:ReplicateTags",
    "s3:Get*"
   ],
   "Resource": [
    "*"
   ],
   "Effect": "Allow"
  }
 ]
}

· Replicate the entire source bucket.

a- Under Buckets, choose the name of your source bucket.

b- Choose “Management”

c- Go to “Replication rules” and click on “Create replication rule”

d- Add the rule name and check “Apply to all objects in the bucket”

e- Filled Destination part with S3 bucket destination

f- Add IAM role create previously that allow us to copy data from source bucket to target bucket in different region.

g- Click on “Create Rule”

6️⃣Cost optimizing

Now that you have enabled versioning, you realize that the size of the S3 bucket will continue to grow as you upload new objects and versions. To save costs, you decide to implement a strategy to retire some of those older versions.

✅Task 7: Setting lifecycle policies

lifecycle policy is a set of rules that automatically move older versions of the objects in your source bucket to a different storage class (S3 Standard-Infrequent Access (S3 Standard-IA) for instance in this case).

By using lifecycle policies, you can cycle data at regular intervals among different Amazon S3 storage types. This cycling reduces your overall cost because you pay less for data as it becomes less important over time. In addition to being able to set lifecycle rules per object, you can also set lifecycle rules per bucket.

We will Configure two rules in the website bucket’s lifecycle.

1- In one rule, move previous versions of all source bucket objects to S3 Standard-IA after 30 days.

2- In the other rule, delete previous versions of the objects after 365 days.

To complete operation, we will:

a- Under Buckets, choose the name of your bucket.

b- Choose “Management” and scroll down till “Lifecycle configuration”

c- Click on “Create lifecycle rule”

d- Check the “Apply to all objects in the bucket”

e- Click on “Create Rule”

8️⃣Conclusion

Every architecture is unique and depends on various factors such as business needs, budget constraints, and target users. The real challenge lies in identifying which AWS services are the most suitable and cost-effective for the application’s specific requirements.