We’re going to use SSL because you can’t trust anyone. Make sure your site configuration uses SSL. I also found you need a trailing slash, or many templates create invalid URL’s.
# config.toml baseurl = "https://yoursite.com/"
This really is the easy part. We’ll:
- Build a fresh copy of the blog
- Sync all posts and files, ignoring duplicates in the
- Ensure they’re marked as public-read so folks can read them
- Use S3 encryption because we’re paranoid, and it’s free
Invalidate the root page, and page listings
set -e # Fail fast DISTRIBUTION_ID=K823EJPPN4O2K9O BUCKET_NAME=mysite.com-cdn # Build a fresh copy hugo -v # Copy over pages - not static js/img/css/downloads aws s3 sync --acl "public-read" --sse "AES256" public/ s3://$BUCKET_NAME --exclude 'post' # Invalidate root page and page listings aws cloudfront create-invalidation --distribution-id $DISTRIBUTION_ID --paths /index.html / /page/*
You can turn this into a sheel script like the one that deploys this blog.
Note the CloudFront invalidation pricing. An
InvalidationRequest is when you ask to purge the cache for a given path.
Some examples include:
- purge one file using
- purge all files at a path using
- purge everything using
Though these may purge from one to thousands of files, each counts as a single invalidation request. The first 1K monthly requests are free, but they are
¢0.5 there after, which could rack up if you were invalidating thousands of files individually, or redeploying with a commit hook frequently.
While you could always invalidate the entire distribution with
/*, this will force all 50 worldwide edge locations to reload every file for you site on the next visit (“cache miss”), defeating the purpose of your CDN. As such, it’s often better to invalidate just the affected files, as long as there are not many. This is why I’m only invalidating about 6 files above.
Alternatively, use unique asset names if they will change frequently, or URL fingerprinting and you won’t ever need to invalidate.