As a frontend developer, you’ve probably faced the need to deploy a web application — whether for a professional assignment, a client demo, or a personal project. Today, there’s no shortage of hosting options. Many platforms provide their own infrastructure or rely on major cloud providers like Amazon Web Services, Google Cloud, or Microsoft Azure behind the scenes.
What often goes unnoticed is that these deployments are powered by automated systems built on infrastructure as code, ensuring consistency and reliability. In this post, I’ll briefly introduce you to an Infrastructure as Code approach using a modernized AWS CloudFormation template that allows you to host static frontend applications in just a few minutes.
Table of Contents
📌Who this solution is for
📌Prerequisites
📌Purpose of this solution
In case you're in a hurry, you can jumpt right into the source code here amazon-cloudfront-secure-static-site-modernized
Who this solution is for?
This solution is useful if you want:
- a secure static website on AWS
- a CloudFormation-based starting point instead of clicking through the console
- a template that reflects recent CloudFront/S3 practices
- a good learning reference for CloudFront, S3, ACM, Route 53, and infrastructure design decisions
Note: this solution is framework agnostic, meaning you can build your React, Svelte, Angular and/or Vue application(s) as a static site and upload the artifacts/assets to the corresponding S3 Bucket.
Prerequisites
- You need a registered domain name, such as
customdomain.com, and point it to a Route 53 hosted zone in the same AWS account in which you deploy this solution. See Configuring Amazon Route 53 as your DNS service to learn more - You need the AWS CLI installed on your machine. Check AWS CLI Docs to learn more.
Purpose of this solution
The original upstream project is useful, but the older v0.5 release implementation used patterns that are now outdated for a fresh deployment, including:
- Origin Access Identity (OAI) instead of Origin Access Control (OAC)
- Node.js 12 for the copy helper Lambda and Lambda layer
- a Lambda@Edge function for response security headers broader IAM access for the asset-copy function
- This solution modernizes that approach by adopting the direction later visible in the upstream v0.12 pre-release and then adding some extra improvements for real-world use.
Modernization Summary
Compared with the older version of the AWS sample, this solution makes the following major changes:
- Replacing OAI with Origin Access Control (OAC) for secure S3 access replaces Node.js 12 with Node.js 20 for the copy helper function
- Removes the Lambda@Edge response-header function in favor of CloudFront Response Headers Policy
- Applying least-privilege IAM for S3 operations
- Keeping the S3 origin private behind CloudFront
- Adding improved logging, encryption, and ownership controls
- Supporting optional apex domains (example.com + www)
- Defining custom Cache Policy and Origin Request Policy
- Enabling SPA-friendly error handling (403/404 → 200)
- adds explicit resource naming parameters
What this project deploys?
- An S3 bucket for static website assets
- An S3 bucket for access logs
- An ACM certificate for the domain
- A CloudFront distribution in front of the S3 origin
- Route 53 alias records for the subdomain and, optionally, the apex domain
- A custom resource that uploads the sample/static assets to the origin bucket
- CloudFront security headers, cache policy, and origin request policy
Follow the deployment steps in Deployment Detail
Diagram of Deployed Resources in your AWS Account
Troubleshotting
- Following the deployment steps should be strightforward, nevertheless in case of any issues, you can always go inspect Cloud Formation Dashboard and double check the logs associated to the stack and nested stacks created.
- Cloud Formation templates may have syntax upgrades from time to time, thus bear that in mind in case of unexpected issues.
Note: If you’re concerned about costs, this setup is generally very affordable. The main upfront expense is your domain name, which typically costs around $12–15 per year and can be reused across projects. Beyond that, services like Amazon CloudFront, storage, and DNS operate on a pay-as-you-go basis. For low-traffic static sites, these costs are usually minimal. — often just a few cents to a couple of dollars per month —
Conclusions
- Leveraging Cloud Formation as your infrastructure as code solution can save you hours of setup with the AWS console.
- The Apex Domain option is useful to reuse your
customdomainto host new static sites.
I hope this article is useful to you!
Checkout these interesting resources about the management of the AWS cli and yml templates:
AWS CLI DEPLOY | AWS Cloudfront Dist Config | AWS CLI - Settings
Happy Coding! 🤓💻
Top comments (0)