Hosting a Website on Amazon S3

Implementation Process

1 Creating an S3 Bucket

The first step was creating a new S3 bucket with appropriate settings for website hosting:

Created a bucket with a globally unique name
Selected US East (Virginia) region for optimal latency
Unchecked "Block all public access" to allow website visitors
Enabled ACLs for more granular permission control

Key Takeaway: Bucket names must be globally unique across all of AWS, and choosing the right region impacts both performance and cost.

2 Uploading Website Files

Next, I uploaded my portfolio website files to the newly created bucket:

index.html - Main landing page
CSRisk-Project.html - Cybersecurity risk assessment project

The upload process was straightforward using the AWS Management Console, which provides a simple drag-and-drop interface.

3 Configuring Static Website Hosting

To enable website hosting functionality on the S3 bucket:

Selected the bucket in S3 console
Navigated to the "Properties" tab
Located the "Static website hosting" section and clicked "Edit"
Enabled static website hosting
Set "index.html" as the index document
Saved the configuration

After completing this step, AWS provided a bucket endpoint URL - the public address where the website would be accessible.

Success: The configuration was accepted, and AWS generated a public endpoint URL in the format: http://bucket-name.s3-website-region.amazonaws.com

4 Addressing Permission Issues

When first attempting to access the site, I encountered a 403 Forbidden error. Despite disabling "Block all public access" at the bucket level, the individual objects were still private by default.

Error Encountered: 403 Forbidden - Access Denied when trying to access the website URL.

To resolve this issue, I implemented two different approaches:

Option 1: Using ACLs

Selected all website files in the Objects tab
Clicked "Actions" dropdown menu
Selected "Make public using ACL"
Confirmed the action

Option 2: Using Bucket Policy

I also implemented a bucket policy for more comprehensive access control:

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

This policy accomplishes two critical things:

Allows public read access to all objects in the bucket
Prevents anyone from deleting the critical index.html file

Success: After implementing these permission changes, the website became publicly accessible.

5 Testing the Website

Once permissions were correctly configured, I conducted several tests:

Verified the main index.html page loaded correctly
Tested navigation to the CSRisk-Project.html page
Confirmed the bucket policy was working by attempting to delete index.html (received expected "access denied" error)
Tested the site on mobile devices to ensure responsive design

Success: The website was fully functional and securely configured. The portfolio is now accessible to potential employers and showcases my cybersecurity projects.

Comparing ACLs vs. Bucket Policies

Through this project, I gained practical experience with two different approaches to managing S3 permissions:

ACLs (Access Control Lists)

Good for making individual objects public
Simpler to use for basic permissions
Legacy method but still useful in specific cases
More granular control at the object level

Bucket Policies

More powerful and flexible
Can specify complex conditions and actions
Better for setting permissions across the entire bucket
Recommended by AWS for most use cases
Can implement additional security controls (like preventing deletion)

While AWS generally recommends using bucket policies over ACLs for most scenarios, understanding both methods provides valuable flexibility when managing S3 resources.

Key Takeaways and Best Practices

Region Selection Matters: Choose the AWS region closest to your audience to minimize latency.
Bucket Names Are Global: Remember that bucket names must be unique across all of AWS.
Public Access Is Multi-Layered: Both bucket-level and object-level permissions must be configured correctly.
Security Is Essential: Only make objects public that need to be public; use bucket policies to control access precisely.
Test Thoroughly: Always verify that both your content and security measures are working as expected.

Security Note: For production websites, consider implementing additional security measures like CloudFront distribution with HTTPS, Origin Access Identity (OAI), and AWS WAF for enhanced protection.

Jose Felix Cruz

Hosting a Static Website on AWS S3

Project Overview

Key Concepts Learned

Business Value