Let's move on to Amazon CloudFront now. This is our content distribution network and edge caching layer. We use this to publish the web app to the internet, and additionally to provide a higher level of routing flexibility. What we need here is a web distribution that routes to our S3 bucket. This is where we might add a route to a traditional hosting pattern if we needed one of those. It would look something like the following, with the /alternative path routing to an origin that is backed by a load balancer.

The following is a screenshot from the CloudFront console showing two routes, one that is the default route going to our S3 bucket, and the other is routing to an application load balancer. The second is only needed if we're building in a traditional server stack to the pattern:

When creating your distribution, it can take around 15 minutes to deploy to all of the CloudFront edge locations. If you make any subsequent changes, these also need to propagate to the edge locations.

It's a good idea to use object versioning in your S3 bucket location if you are often deploying changes to existing objects. This will inform CloudFront to update the copy in the cache and replicate around to the edge locations. If you're not using object versioning, you can also force cache invalidation manually using the following command:

aws cloudfront create-invalidation 
    --distribution E3HCM3F21RZ42L 
    --paths "/*"

There are some specific limits around how many files you can invalidate at once. You also get 1,000 manual invalidation requests for free and, after that, you pay per 1,000 requests.

Once we have the frontend set up, there are some more requirements that our client needs to render the website. Let's explore the backend options next.