Blog
Level 5 Autonomy Needs Level 5 Guardrails
Operating at Level 5 AI autonomy without guardrails is how you lose a production database. Here’s what I put in place to prevent that.
Apr 6, 2026
Operating at Level 5 AI autonomy without guardrails is how you lose a production database. Here’s what I put in place to prevent that.
I have very strong feelings when it comes to IAM Access Keys which I can sum up rather quickly - never - ever - provide Access Keys to your users - end of story.
Let me explain why I take this stance - in my experience 99% of the time the user doesn’t actually require them. Sure you have power users within the organization who want to interact with AWS via the CLI or maybe a script or two (more on that later), but in my experience the vast majority of AWS users interact with the platform via the AWS Management Console and these users do not need keys.
Increased flexibility - sometimes referred to as ‘elasticity’ - is one of the major reasons organizations decide to leverage the AWS Platform. Elasticity is the flexibility to use only the resources you require, with the ability to scale out and in as needed, where needed. But what happens when a workload grows beyond its provisioned resources? Sometimes an application will grow to need more RAM or processing power, and simply adding more nodes isn’t a viable solution.
There are quite a few decisions you need to make when you’re first getting started on the Amazon Web Services (AWS) platform. One of those decisions that are often overlooked in the thrill of getting started is AWS Account Strategy.
There are two options when it comes to deciding on an AWS Account Strategy:
In this article, I’ll outline both options and why I almost exclusively use a Multi-Account strategy over the single AWS account option.
Lately, I’ve had this question come up quite often, so I figured an article about the most common ways to scale RDS would be helpful.
My most preferred method of ‘scaling’ a Relation Database (RDS) instance is to offload as much as possible from the master instance. I’ve listed how I commonly do that in order of my preference.
Before making any decisions (or changes), please ensure that you have setup both the maintenance and backup windows using the most appropriate time. In the past, I have seen misconfiguration here affect performance. For example, AWS performs a backup of your RDS instance during business hours - probably not what you wanted to happen.
The simplest definition that I can think of is modifying your AWS infrastructure to match actual demand.
Although there are numerous services in AWS which can be ‘right-sized’ most commonly when someone refers to ‘right-sizing’ they are probably talking about the Elastic Compute Cloud (EC2) or Relational Database Service (RDS). Why? Because in the majority of cases the majority of your monthly costs associated with AWS will be in one of these services.
Given the recent AWS Availability Zone (AZ) failure in the Sydney region I thought now was as good of a time as any to reiterate the importance of designing your AWS infrastructure to survive failures.
First, it’s important to understand that just because you’ve decided to move all (or some of) your IT infrastructure to AWS doesn’t mean that you no longer have to design for failures.
Cloud Computing regardless of your chosen platform is not a silver bullet.
Send a paragraph about what you're trying to do on AWS. I'll come back with how I'd approach it, or a pointer to someone better suited.