One of the most popular and practical uses of S3 is hosting a website directly, with no need for servers. It’s cheap, simple, and automatically scales to millions of visits. In this subchapter, we wrap up the S3 chapter by seeing how and when to use it.

First, a key distinction:

• Static web: files are served as is to all visitors. The content doesn’t change depending on who visits. These are HTML, CSS, JavaScript files, images… Examples: a corporate website, a blog, a portfolio, product documentation, a landing page.
• Dynamic web: content is generated on the fly depending on the user or data (requires a server to run code and query databases). Examples: your online banking dashboard, a personalized shopping cart.

S3 serves static websites, not dynamic ones. But beware: today, many modern websites (built with React, Vue, Angular…) are static in delivery and get dynamic data by calling an API separately. So “static” doesn’t mean “simple” or “boring.”

Analogy: A static website on S3 is like a bulletin board: you pin up the sheets and everyone who passes by sees the same thing. A dynamic website is like a waiter who prepares something different for each customer.

• No servers to manage: there’s no EC2 to maintain, patch, or monitor. You just upload files.
• Automatically scales: if your website goes viral and millions visit, S3 handles it without you doing anything. There’s no server to get overloaded.
• Cheap: you only pay for storage (just a few files) and for downloads. A small website can cost cents per month.
• Very reliable: you inherit S3’s durability and availability.

Real example: A startup launches its presentation website (the typical landing page with product info and a contact form). Instead of paying for a server running 24/7, they upload it to S3. When they hit the news and get a huge spike in visits, the website holds up perfectly and the cost remains minimal.

The conceptual steps to host a static website on S3 are:

1. Create a bucket (remember: globally unique name, subchapter 5.1).
2. Upload the website files (index.html, style sheets, images, etc.).
3. Enable the "static website hosting" option on the bucket, specifying the start document (usually index.html) and the error document (for example, error.html).
4. Grant public read permission to the files via a bucket policy (remember subchapter 5.4: you must consciously open access and only as needed).

With this, S3 gives you a URL from which your website is accessible.

Hosting directly on S3 has two limitations:

1. The URL S3 gives is long and ugly (something like my-bucket.s3-website-eu-west-1.amazonaws.com), not your nice domain www.mycompany.com.
2. Direct S3 hosting does not offer HTTPS (the secure connection with the padlock) for custom domains.

The professional solution is to put CloudFront in front of the bucket (remember subchapter 3.3). This gives you:

• HTTPS with a free certificate (ACM, which we’ll see in Chapter 16).
• Your own domain (www.mycompany.com) via Route 53 (Chapter 16).
• Global speed thanks to caching at edge locations.
• More security: the bucket can remain private and only CloudFront accesses it (you no longer need to expose it to the public).

Recommended architecture for a professional static website:

User → CloudFront (HTTPS, global cache) → S3 (private files)
            ↑
       Route 53 (your domain)  +  ACM (free SSL certificate)

This combination —S3 + CloudFront + Route 53 + ACM— is one of the most widely used patterns in the world for serving websites and is also Project 1 that you’ll build in Chapter 33.

Use it for:

• Corporate websites, blogs, portfolios, documentation.
• Landing pages and marketing websites.
• Single Page Applications (SPA) built with React, Vue, Angular… that consume a separate API.

Don’t use it (directly) for:

• Websites that need to run code on the server for each request (for that, EC2, containers, or Lambda).
• When you need server logic, sessions, heavy server-side rendering, etc. (though you can often combine S3 for static + Lambda/API for dynamic).

• S3 can host static websites (HTML, CSS, JS, images) without servers: cheap, scalable, and reliable.
• “Static” doesn’t mean simple: modern SPAs (React, Vue…) are served this way and get data from a separate API.
• Direct S3 hosting gives you an ugly URL and no HTTPS for custom domains; the professional solution is to put CloudFront in front (HTTPS, custom domain, speed, and security).
• The S3 + CloudFront + Route 53 + ACM pattern is the standard for static websites and you’ll build it in Chapter 33.
• For per-request server logic, S3 is not enough: combine it with Lambda, containers, or EC2.

With this, you finish Chapter 5 and master object storage. In Chapter 6 we’ll look at networks in AWS with VPC: how your resources connect and are isolated securely.