Having sat down to trace through the reason why Cloudfront was giving HTTP 403 errors when trying to load the page a few days ago, I've finally found time to write up what went wrong.

To recap, I found that the Cloudfront Distribution link was working fine when visiting [https://d29wvgb72tkraq.cloudfront.net/] however, when visiting my domain at [https://iainrawlings.com] or [https://www.iainrawlings.com] I was receiving 403 errors. Initially before loading the page I had thought that the error was probably my DNS configuration over at Cloudflare. As with all things, the devil was in the detail.

On closer inspection, the 403 error was served from Cloudfront. Which confirmed that the DNS CNAME records were absolutely fine. Cloudfront appeared to be unable to access the S3 bucket which stores the static website pages. I headed over to S3 to check out permissions, spending a some time reading various AWS documentation to try and point myself in the right direction.

The jewel in the crown of the documentation appeared to be this article. the AWS Knowledge base was a resource I'd missed out on until now. There are very clear points set out on the article as to what can cause the issue of a 403 error between Cloudfront and S3. In my case, the most important one is as follows:

• If clients request the root of your distribution, then you must define a default root object.

Because I had not set a root object in Cloudfront (index.html). The interesting difference here is that if you use the S3 static website host, S3 will default to index.html as the root object. There is, however, no such provision in Cloudfront and you MUST define what the root document is.

Following a quick change and deployment via the AWS console, I checked the site again - Still not working. But it did start to serve correctly over HTTP instead of HTTPS. This points to the certficate being the next issue to solve. A quick check over at the AWS Certificate Manager in the console confirms I had correctly set the DNS entries and validated the certificate for both of my previously mentioned domain names.

I headed over to the Cloudfront config once again and in short order realised I had forgotten to add the certificate to the configuration. Once populated and redeployed the website is now up and running!

During the course of diagnosing these issues, I also realised that when uploading new content from my Pi4 to AWS S3, the standard Pelican S3_upload script complains that ACLs are not active for the bucket and the files cannot be uploaded. The next task to be completed is to modify the makefile and change the s3_upload command to use aws s3 cp ./output/* s3://iainrawlings.com --recurisve instead as this doesn't require ACL's to be set due to already being logged in as my user on the AWS command line.

To Summarize the skills used during this entire exercise: AWS SDK, S3 setup and use, Cloudfront setup and use, DNS setup via cloudfront, Linux command line, pythons Pelican static site generator package, the python venv module to create a virtual env for Pelican on my Pi4 and finally Further use of VSCode for remote access to files on the Pi in an efficent manner.