AWS Builder Center

Builder Center

Building a Secure and Scalable Static Website Hosting Architecture with Amazon S3 and CloudFront OAC

Building a Secure and Scalable Static Website Hosting Architecture with Amazon S3 and CloudFront OAC

A hands-on AWS project demonstrating how to deploy a multi-page static website using Amazon S3 and CloudFront. Implements a private S3 origin with Origin Access Control (OAC), SigV4 request signing, HTTPS redirection, AWS WAF integration, global content delivery, and deployment automation using AWS CLI.

Explore the Project

GitHub Repository:  https://github.com/Sandeepa-git/Static-Website-Hosting-with-S3-and-CloudFront 
Feedback and suggestions are welcome!

Introduction

Hosting a static website in the cloud is straightforward, but building a secure and reliable hosting architecture requires more than simply uploading files.
In this project, I built and deployed RegPro, a multi-page business registration website, using Amazon Web Services (AWS).
The main objective was to host the website using Amazon S3 and distribute its content globally through Amazon CloudFront while keeping the S3 bucket completely private.
Instead of traditional public S3 website hosting, I implemented CloudFront Origin Access Control (OAC) with AWS Signature Version 4 (SigV4) signing.
This project demonstrates how AWS storage, content delivery, access management, and web security services can work together in a practical deployment.

1. Architecture Overview

The architecture separates website storage from content delivery.
Request flow:
User Browser → Amazon CloudFront → Origin Access Control (OAC) → Private Amazon S3 Bucket
When a visitor accesses the website:
  1. The browser sends an HTTPS request to CloudFront.
  1. CloudFront receives the request at an edge location.
  1. If the requested content is cached, CloudFront serves it directly.
  1. Otherwise, CloudFront sends a signed request to the S3 origin using OAC.
  1. Amazon S3 evaluates the bucket policy and authorizes the request.
  1. The requested content is returned through CloudFront to the visitor.
This approach allows the website to remain publicly accessible through CloudFront without making the S3 bucket publicly accessible.

2. Creating the Private Amazon S3 Bucket

I created a general-purpose S3 bucket in the Europe (Stockholm) region.
Configuration:
  • Bucket name:  sandeepa-regpro-website-2026 
  • Region:  eu-north-1 
  • Bucket type: General purpose
  • Block all public access: Enabled
  • Default encryption: Enabled
Keeping Block All Public Access enabled was an important security decision.
The bucket acts as a private origin, and CloudFront is granted permission to retrieve website objects through OAC.

3. Uploading Website Files

I uploaded the website files while maintaining the original directory structure.
The project includes:
  •  index.html  – Main landing page.
  •  contact.html  – Contact page.
  •  css/styles.css  – Responsive website styling.
  •  js/main.js  – Client-side interactions and form validation.
Maintaining the directory structure ensures that HTML files can correctly reference their CSS and JavaScript assets.

4. Configuring CloudFront Origin Access Control

One of the most important implementation steps was configuring Origin Access Control.
OAC is the modern approach for securely connecting CloudFront to private S3 origins.
I created an OAC with the following configuration:
  • Name:  regpro-website-oac 
  • Origin type: S3
  • Signing behavior: Sign requests
  • Signing protocol: SigV4

Why OAC?

OAC provides several security advantages:
  • Allows CloudFront to retrieve private S3 objects.
  • Uses AWS Signature Version 4 to sign origin requests.
  • Supports restricting access to a specific CloudFront distribution.
  • Supports additional capabilities such as SSE-KMS encrypted S3 objects.
An important configuration detail is that OAC requires the regular S3 REST endpoint rather than the S3 static website endpoint.

5. Creating the CloudFront Distribution

I created a CloudFront distribution and connected it to the S3 origin.
Origin domain:
 sandeepa-regpro-website-2026.s3.eu-north-1.amazonaws.com 
Default cache behavior:
Setting
Configuration
Viewer protocol policy
Redirect HTTP to HTTPS
Allowed HTTP methods
GET, HEAD
Cache policy
CachingOptimized
Origin access
OAC
Default root object
index.html
The default root object allows visitors to access the homepage without explicitly specifying  index.html .
After deployment, CloudFront provided the distribution domain:
 https://d1frun5ugmhz7e.cloudfront.net 

6. Securing the S3 Bucket with a Bucket Policy

OAC must be supported by an appropriate S3 bucket policy.
I configured the policy to allow the CloudFront service principal to perform  s3:GetObject  requests only when the request originates from my specific CloudFront distribution.
The policy uses:
  • Principal:  cloudfront.amazonaws.com 
  • Action:  s3:GetObject 
  • Resource: Website objects in the S3 bucket
  • Condition:  AWS:SourceArn  matching the CloudFront distribution ARN
Example:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipal",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::sandeepa-regpro-website-2026/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::972224212800:distribution/E2N274ZOEWOET2"
        }
      }
    }
  ]
}
This restricts the intended origin access to the specified CloudFront distribution while keeping public access blocked.

7. Integrating AWS WAF

I also integrated AWS WAF with the CloudFront distribution.
AWS WAF helps protect web applications by inspecting incoming HTTP and HTTPS requests against configured rules.
It can provide protection against common web exploits and unwanted traffic patterns.
For production deployments, useful considerations include:
  • AWS Managed Rules.
  • Common web application attack protections.
  • Rate-based rules.
  • WAF logging and monitoring.
  • Reviewing false positives.
AWS WAF provides an additional security layer, complementing the private S3 origin and CloudFront OAC configuration.

8. HTTPS and Secure Content Delivery

I configured CloudFront to redirect HTTP requests to HTTPS.
This ensures visitors use an encrypted connection when accessing the website.
For custom-domain deployments, AWS Certificate Manager (ACM) can provision and manage public SSL/TLS certificates.
An important detail is that certificates associated with CloudFront distributions must be requested or imported in the  us-east-1  region.
Amazon Route 53 can also be used to configure DNS records pointing to the CloudFront distribution.
These are optional extensions to the default CloudFront domain deployment.

9. Testing and Verification

After deployment, I verified the website through the CloudFront domain.
Homepage:
 https://d1frun5ugmhz7e.cloudfront.net/ 
Contact page:
 https://d1frun5ugmhz7e.cloudfront.net/contact.html 
I checked that:
  • Both website pages loaded correctly.
  • CSS and JavaScript assets were accessible.
  • The expected website layout was maintained.
  • HTTP requests were redirected to HTTPS.
  • CloudFront could retrieve content from the private S3 origin.
These checks helped validate the complete hosting workflow.

10. Deployment Automation Using AWS CLI

To simplify future updates, I prepared an AWS CLI deployment workflow using  aws s3 sync .
aws s3 sync . s3://sandeepa-regpro-website-2026 \
  --exclude "*.sh" \
  --exclude "*.md" \
  --exclude ".git/*" \
  --exclude "Screenshots/*"
After uploading updated files, I used CloudFront invalidation to refresh cached content.
aws cloudfront create-invalidation \
  --distribution-id E2N274ZOEWOET2 \
  --paths "/*"
This provides a simple deployment process:
  1. Update the website files.
  1. Synchronize the files with S3.
  1. Invalidate the CloudFront cache.
  1. Verify the updated website.
I also documented a GitHub Actions CI/CD workflow blueprint for automating deployments after changes are pushed to the main branch.
For production environments, using GitHub Actions OIDC with a restricted IAM role is preferable to storing long-lived AWS access keys.

11. Resource Cleanup and Cost Management

Managing cloud resources is an important part of any AWS project.
I prepared a cleanup workflow to help remove resources when they are no longer required.
The general cleanup sequence includes:
  1. Disable the CloudFront distribution.
  1. Wait for the configuration update to complete.
  1. Delete the distribution.
  1. Empty the S3 bucket.
  1. Delete the bucket.
  1. Remove optional Route 53 records and ACM certificates if they are no longer needed.
  1. Review any remaining WAF resources and configurations.
It is important to review AWS pricing and billing to avoid unexpected charges.

12. Key Learnings

This project provided practical experience with several AWS concepts:
  • Designing secure cloud architectures.
  • Configuring private S3 storage.
  • Understanding OAC versus legacy OAI.
  • Implementing SigV4 request signing.
  • Writing S3 bucket policies with  AWS:SourceArn  conditions.
  • Configuring CloudFront distributions and caching.
  • Integrating AWS WAF.
  • Enforcing HTTPS.
  • Automating deployments and cache invalidations using AWS CLI.
One of the most important lessons was understanding that a secure architecture should control not only who can access an application, but also how the application accesses its underlying resources.

13. Technologies and AWS Services

Service / Technology
Purpose
Amazon S3
Private website storage
Amazon CloudFront
Global content delivery
CloudFront OAC
Secure origin access
AWS SigV4
Request signing
AWS WAF
Web application protection
AWS IAM
Access management
AWS CLI
Deployment automation
GitHub Actions
CI/CD workflow blueprint
AWS Certificate Manager
Optional SSL/TLS certificates
Amazon Route 53
Optional DNS integration

Conclusion

This project was a valuable hands-on experience in designing and deploying a secure static website hosting architecture using AWS.
Rather than simply uploading files to an S3 bucket, I focused on understanding how different AWS services work together to provide private origin access, secure communication, global content delivery, and deployment automation.
The biggest takeaway is that good cloud architecture is not only about making applications accessible; it is about making them accessible securely, reliably, and efficiently.
I look forward to building more practical AWS projects and continuing to improve my knowledge of cloud infrastructure, security, and DevOps.
# amazon-s3# amazon-cloudfront# architecture
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article