![How to build a single-page application deployment using AWS CDK](https://assets.community.aws/a/2gddFELEk31qla9d2lbQYNarPu8/feat.webp)
How to build a single-page application deployment using AWS CDK
Learn how to deploy a single-page application (or any other static assets) using AWS CDK
Published May 18, 2024
All modern applications will require some form of static assets to actually power the functionality for their users, whether it’s media content, supporting scripts or the application content itself.
A super common pattern that I always call upon when deploying single-page applications (SPA) is deploying my static assets into S3 and serving them through CloudFront.
This is incredibly useful when working not only with single-page applications, but also for static assets that need to be served to ensure your applications work as expected.
Let’s take a look at how we can define the infrastructure resources to facilitate serving these assets, using my old favourite AWS CDK.
To give you an idea of what we’re wishing to achieve with this, here is a high-level architecture diagram of what we want to build:
![CloudFront and S3 Architecture Diagram CloudFront and S3 Architecture Diagram](https://assets.community.aws/a/2gddmDvafwrxVbScvRKBRYH75cv/s3-c.webp)
Crafting the CDK for this pattern is extremely straightforward. There are only the two components:
- S3 Bucket
- CloudFront Distribution
To provision the S3 bucket, you can use the L2 construct that already exists within CDK:
With the above, we’re just creating a S3 bucket that has public access denied and encryption at rest enabled.
We’re then going to create our CloudFront distribution and update the bucket to allow the distribution to read from it:
Firstly, we’re creating the
OriginAccessIdentity
construct, this is then used to grant read access to the S3 bucket before assigning it to the CloudFront distribution itself.We’re specifically using the
Distribution
construct here as it’s the newer implementation (replacing the CloudFrontWebDistribution
construct). As part of that, the API has changed slightly and we need to define a CloudFront origin itself - we are using S3 as our origin and can pass our origin identity permission into it to allow the distribution to read from the bucket.We assign that as our default behaviour (as a CloudFront distribution can have multiple behaviours), and finally define our price class.
And that’s it! Deploy those and you’ll have a S3 bucket that you can push your build assets into. By default, the entry point for the CloudFront distribution is
index.html
- so whenever you build your SPA assets, you simply push them into the bucket and you will be good to go!Low cost because all of the assets are stored in S3 and served via CloudFront, so your costs will scale with the requests and the traffic coming inbound. Since CloudFront heavily caches at edge, the requests downstream to your S3 bucket will be fairly low - unless you explicitly invalidate the cache if you have new objects.
- Static assets can be pushed into S3 bucket and served via the global CloudFront CDN network.
- Extremely cost-effective for working with a lot of network requests.
- Can work for SPA static websites or other general static content that might be required to power your applications.