Deploy a Static Website

By Pulumi Team
Published
Updated

The Challenge

You need a fast, secure way to serve a static website globally. Whether it is a marketing site, documentation portal, or single-page application, the pattern is the same: object storage for files, a CDN for performance, and HTTPS for security.

What You'll Build

  • S3 bucket configured for static hosting
  • CloudFront CDN for global delivery
  • HTTPS enabled automatically
  • Caching configured for performance
  • Origin access controls for security

Neo Try This Prompt in Pulumi Neo

Run this prompt in Neo to deploy your infrastructure, or edit it to customize.

Best For

Use this prompt when you need to host a static site (HTML/CSS/JS, a compiled React or Vue app, documentation) with global CDN delivery and HTTPS. This is one of the most common AWS patterns and a good starting point for learning infrastructure as code.

Architecture Overview

This architecture uses the standard AWS pattern for serving static content at scale. An S3 bucket stores your website files, and a CloudFront distribution caches and serves them from edge locations around the world. CloudFront also handles HTTPS termination, so visitors always connect over a secure channel without any additional certificate management.

The important design choice here is keeping the S3 bucket private. Rather than enabling S3’s static website hosting with public access, the bucket is only accessible through CloudFront via origin access controls. This means all traffic flows through the CDN, giving you consistent caching behavior, HTTPS enforcement, and a single access point to monitor and secure.

This is one of the most widely deployed patterns on AWS. It scales from a personal blog to a high-traffic marketing site without any changes to the architecture. CloudFront automatically absorbs traffic spikes, and S3 provides eleven nines of durability for your stored files.

S3 Bucket

The S3 bucket holds your HTML, CSS, JavaScript, images, and any other static assets. It is configured with an index document (typically index.html) and a custom error document for handling 404 responses. Because the bucket is not publicly accessible, all requests must come through CloudFront.

CloudFront Distribution

The CloudFront distribution is the public-facing layer. It caches content at edge locations globally, terminates TLS, and routes requests back to S3 when the cache misses. Custom error responses let you return friendly error pages instead of raw XML errors from S3.

HTTPS and Caching

CloudFront can use its default certificate for HTTPS, or you can attach an ACM certificate for a custom domain. Caching headers control how long content stays at edge locations before CloudFront checks S3 for updates. For most static sites, a cache TTL of a few hours strikes a good balance between freshness and performance.

Common Customizations

  • Add a custom domain: Extend the prompt to include an ACM certificate and Route53 DNS records so visitors access the site through your own domain.
  • Configure cache invalidation: Request a deployment step that invalidates the CloudFront cache after uploading new files, so changes propagate immediately.
  • Add a www redirect: Include a redirect from www.example.com to the apex domain (or vice versa) using CloudFront Functions or a second distribution.
  • Enable access logging: Ask for CloudFront access logs to be written to a separate S3 bucket for traffic analysis.