Building a CloudFront log parser for Hugo with Kiro CLI.

And some surprise outcomes!

When I started creating content for the AWS Community Builder program, like many people I started with WordPress. However, it was too complex, had a lot of functionality I didn’t need, and more importantly would have needed a server running somewhere to host it.

All of that led me to looking at static web site generators fairly quickly - a great advantage of this is that you can host them in GitHub or something similar; or given I’m an AWS Community Builder, build it on AWS. And that’s what I described in my article Hosting a Static Website on AWS; just S3, CloudFront and not a server to be seen. I could even tie in a really simple pipeline that would regenerate the site as I commited my changes to a git repo (more info here).

But how do you know that this approach works - I could access the site and see the pages, but how could I see what others were doing and that it worked for them? I did setup Google Analytics, thanks to a Hugo integration, but it felt over the top, and it’s been niggling away for well over a year, that I wanted a different, more aligned solution.

Amazon’s new European Sovereign Cloud.

A Strategic Response to US Law and EU Data Privacy

Organisations outside the US considering the use of Cloud services have been faced with a hard choice. All the major providers, including AWS, Azure, and Google, are based in the US and fall under US legal jurisdiction.

Organisations in the EU or EU-adjacent locations (especially the UK) must consider GDPR and other data regulations. Typically, these regulations state that an organisation in one of these locations should limit the use of outside third parties unless those parties can guarantee parity with EU requirements. For simplicity, I’ll refer to EU organisations for the rest of this article.

Chaos in the Cloud

A Introduction to Chaos Engineering and Amazon's Fault Injection Service

This is the first in a series of articles looking at chaos engineering in general, and in particular how we can use Amazon’s Fault Injection Service to test the resilience of our AWS systems.

When I first started developing, we wrote huge, monolithic applications either running locally on our desktops, or in our datacenters. We’d write applications that had tens or even hundreds of thousands of lines of code. However, the applications we wrote usually consisted of a single component, maybe two if we used a database, handling all of the logic and functionality within a single application. Whilst this meant that we usually had complex, hard to navigate, code bases, it did mean that in terms of architecture, our applications were relatively simple.

Now You See Me, Now You Don't - the Mystery of the Vanishing S3 Objects

One of the great things about my role as a consultant at GlobalLogic is that sometimes I’ll be asked to help out on what at first glance can be a simple problem, but as I investigate, I get a chance to uncover some unusual or forgotten features.

Recently, I was working on a project and was asked if I could help solve an issue that had been puzzling a developer. They had deployed a system where some objects uploaded to an S3 bucket seemed to disappear and then reappear; it was time to start digging.