When you want to publish a simple static site lets say a blog, portfolio, documentation page or landing page, you often don’t need a full server. What you do need is secure access (HTTPS), a custom domain, and a system that scales without constant maintenance. In the AWS ecosystem, combining S3, CloudFront, and Route 53 gives you all of that, at minimal cost and almost zero operational overhead. In this post I walk you through how to host a static site on AWS with HTTPS, using only S3 + CloudFront + Route 53, in the cheapest possible way. This blog post is for penny-pinchers.
The central challenge here is that Amazon S3’s “website hosting” capability does not support HTTPS by itself. If you bind your domain directly to the S3 website endpoint, browsers will reject secure connections. To get HTTPS, you insert CloudFront in front, and use AWS’s Certificate Manager (ACM) to issue a TLS certificate. Route 53 then lets you bind your custom domain to the CloudFront distribution via alias records that incur no extra cost per query (beyond the minimal DNS price). The result is a static-only architecture, zero servers, SSL termination, and global CDN distribution.
First, let’s talk domain and DNS. If you don’t already own a domain, you can register one via Route 53 (or buy one elsewhere and delegate DNS). In Route 53 create a hosted zone for your domain. You’ll later add alias records pointing to CloudFront so your domain resolves to the CDN distribution. Because Route 53 supports aliasing to CloudFront, you avoid manually managing IP addresses or load balancers. AWS’s docs on using CloudFront and Route 53 for static site hosting are a good reference here.
First, let’s talk domain and DNS. If you don’t already own a domain, you can register one via Route 53 (or buy one elsewhere and delegate DNS). In Route 53 create a hosted zone for your domain. You’ll later add alias records pointing to CloudFront so your domain resolves to the CDN distribution. Because Route 53 supports aliasing to CloudFront, you avoid manually managing IP addresses or load balancers. AWS’s docs on using CloudFront and Route 53 for static site hosting are a good reference here. See: AWS Documentation
Next, you set up one or two S3 buckets. The canonical pattern is: a bucket named exactly after your root domain (e.g. example.com) in which you host the site contents, and optionally a second bucket (e.g. www.example.com) that simply redirects to the root domain. In the root bucket, enable static website hosting, specify the index and error documents, and allow public read access (or configure it appropriately so that CloudFront can read). This part is straightforward and described in AWS’s S3 documentation. See: AWS Documentation
Then you request a TLS certificate in ACM. Because CloudFront is regional (global) you must request the certificate in the US East (N. Virginia) region. Include both your root domain (example.com) and your www (or any subdomain) in the certificate. Use DNS validation (automated via Route 53) so you don’t have to mess with uploading files manually. Once validated, the certificate becomes usable by CloudFront.
With S3 hosting and the certificate in place, you can now create a CloudFront distribution. Configure the origin to point to your S3 bucket (either via the bucket URL or website endpoint), and set viewer protocol policy to redirect HTTP to HTTPS. In the “Alternate Domain Names (CNAMEs)” section, specify your domain(s) so that CloudFront accepts requests for them, and attach the ACM certificate so it can serve TLS for your custom domain. Optionally, you can prevent direct public access to S3 by using an origin access identity (or origin access control), forcing all reads through CloudFront. AWS’s guide to serving a static site through CloudFront walks you through most of these steps. See: AWS Documentation
After the CloudFront distribution is deployed (which may take several minutes), go to your Route 53 hosted zone and create alias A or AAAA records for your root domain and subdomain. Point them to the CloudFront distribution (using the alias target feature). Since alias records are “free” in the sense that they don’t incur per-query additional cost, this is more efficient than using “normal” CNAME or A records to arbitrary IPs. Once DNS propagates, your domain resolves to the correct CloudFront endpoint.
At that point, accessing http://yourdomain.com should load your static site over TLS. Use tools like dig or nslookup to confirm DNS is pointing to the CloudFront domain. Inspect response headers (e.g. X-Cache) to confirm CloudFront is serving content (cache hits). Also verify that http://yourdomain.com redirects to HTTPS. If something fails, typical culprits are DNS not propagated yet, certificate validation not completed, bucket permissions misconfigured (403 errors), or misconfigured origin settings.
In terms of cost, the main charges you’ll see are S3 storage (very low, particularly for small sites), data transfer out via CloudFront, and Route 53 DNS queries (minuscule). CloudFront has request/transfer costs, but for lightweight traffic the totals are often a few dollars per month or less. In some community reports, people have hosted sites for essentially cents over a year. Reddit on StackOverflow, users often ask “what is the cheapest way to host an HTTPS static site on AWS?” and the common answer is: S3 + CloudFront + Route 53 is about as lean as you can get inside AWS. Stack Overflow
You should be aware of a few pitfalls. DNS changes can take time to propagate, so patience is needed. Certificate issuance and validation may take several minutes (or longer). A 403 error often indicates permission misconfiguration on the S3 bucket or that CloudFront cannot fetch the origin. Caching behavior or incorrect TTLs might serve stale content, so when you update your site, consider invalidating CloudFront cache. Also watch out for large bandwidth spikes (e.g. if your site suddenly gets heavy traffic), since CloudFront egress charges can scale.
Hosting a static site in this way gives you encrypted traffic, global performance, minimal operations overhead, and predictable cost. You avoid running any servers, avoid needing a traditional web host, and you rely purely on managed AWS services. For personal projects, small businesses, documentation sites, or portfolios, this is a robust, future-friendly approach. Once you master this setup, you can even automate deployments (via AWS CLI, GitHub Actions, or Terraform), issue new invalidations, or plug in monitoring/analytics.
Suleyman Cabir Ataman, PhD