Skip to main content

Command Palette

Search for a command to run...

Day 7: Week 1 Finale — Hosting a Secure Static Website with S3 & CloudFront

Updated
3 min read
Day 7: Week 1 Finale — Hosting a Secure Static Website with S3 & CloudFront
A
🚀 DevOps Engineer | Cloud Enthusiast | Automation Advocate I write about DevOps, Cloud Computing, and Infrastructure Automation, focusing on real-world projects using AWS, Ansible, Docker, Kubernetes, and CI/CD pipelines. My goal is to break down complex concepts into simple, practical, and beginner-friendly explanations that anyone can follow. I actively share hands-on tutorials, deployment strategies, troubleshooting guides, and lessons learned while working on cloud-native applications and automation workflows.

Congratulations! You’ve made it through the first week of the AWS for DevOps journey. We’ve covered the "Big Four": IAM, VPC, EC2, and S3.

Today, we aren't just learning a new service; we are building a production-grade architecture. We will host a static website on S3 and use Amazon CloudFront to deliver it globally with low latency and high security.

1. Why CloudFront?

You could just make an S3 bucket public and host a site there. But in a DevOps environment, we don't do that. Why?

  • Latency: S3 lives in one region. CloudFront has 600+ Edge Locations to serve content closer to your users.

  • Security (OAC): Using Origin Access Control (OAC), we can keep our S3 bucket completely private. Only CloudFront can "see" the files.

  • HTTPS: CloudFront provides SSL/TLS certificates out of the box. S3 static hosting only supports unencrypted HTTP.

2. The Step-by-Step Architecture

Step A: The Storage (S3)

  1. Create a bucket (e.g., my-devops-portfolio-2026).

  2. Upload your index.html and error.html.

  3. Crucial: Keep "Block All Public Access" ENABLED. We want our fortress locked.

Step B: The Distribution (CloudFront)

  1. Create a CloudFront Distribution.

  2. Choose your S3 bucket as the Origin Domain.

  3. Select Origin Access Control (OAC) (Recommended). This creates a secure "handshake" between the services.

  4. AWS will provide a Bucket Policy. Copy this! You need to paste it into your S3 bucket permissions so CloudFront can read your files.

Step C: The Delivery

  1. Once the status is "Deployed," copy your CloudFront Domain Name (e.g., d123abc.cloudfront.net).

  2. Paste it into your browser. 🚀

3. Pro-Tips for the Week 1 Project

  • Invalidations: If you update your index.html in S3, you won't see the changes immediately because CloudFront caches content for 24 hours. Create an Invalidation (path: /*) to force CloudFront to pull the fresh files.

  • Default Root Object: Always set this to index.html in your CloudFront settings. Otherwise, navigating to the main URL might result in an "Access Denied" error.

  • Cost Management: While S3 is cheap, NAT Gateways (from Day 3) and large CloudFront transfers can add up. If you are on the Free Tier, remember to delete resources you aren't using after the lab!

  • Custom Domains: In a real-world scenario, you would use Route 53 to point www.yourname.com to your CloudFront distribution.

🚀 Week 1 Reflection & Challenge

We have moved from "What is a Region?" to "Global Content Delivery."

The Challenge: Try to break your site! Change the S3 bucket policy to deny access and see how CloudFront reacts. Then, fix it using the OAC policy provided by AWS.

DevOps Milestone: You have just built a Serverless Architecture. No EC2 instances were harmed (or managed) in the making of this website!

What’s Next?

Week 2 kicks off tomorrow with Day 8: Relational Databases — Introduction to Amazon RDS. We’re moving from static files to dynamic data management.

Share your website URL (the CloudFront one!) in the comments below and let's celebrate a successful Week 1!

#AWS #CloudFront #S3 #Serverless #WebDevelopment #100DaysOfDevOps #CloudArchitecture #Hashnode #LearningJourney

More from this blog

A

AWS

28 posts