AWS feels different. Here’s how that changes my approach.

When benevolence becomes legible

For a long time I planned to write about AWS’s “Day One” and “Day Two”, the narratives it uses about itself and how they have aged. The more I outlined it, the more that angle felt unhelpful. Easy critique rarely helps people make better decisions.

Instead I kept circling a quieter unease. AWS no longer behaves the way I instinctively expect it to. Not worse. Not better. Different in where discretion shows up.

Benevolence is not generosity. It is worry removal.

I now think of benevolence less as a value and more as an experience. It is felt when something that should have been painful is not, when a mistake happens and the consequences are softened or absorbed, when a problem that could have become personal quietly disappears.

I once wrote that all customers want someone that takes away their worries and problems, and that sentence still captures the lived experience of infrastructure stress better than most policy language.

This is why benevolence is talked about most by engineers and practitioners. They feel it when an error is erased, when escalation works, when the platform does not punish them for being human. Benevolence, in this sense, is not about kindness. It is about who absorbs the cost of failure.

For a long time, working with Amazon Web Services felt like working with a platform that was willing to absorb some of that cost alongside you, not because the rules were unclear, but because their application was often mediated.

How AWS helped practitioners feel safe and capable

AWS did not just make infrastructure available. It made recovery possible.

When things went wrong, there was often a sense that the platform would help you get back on your feet. That help could take many forms: credits, reversals, exceptions, guidance. The effect was consistent. Engineers could fix things. FinOps practitioners could step in. Teams could tell a story of resolution rather than failure.

This dynamic helps explain why FinOps teams so often operate as individuals saving the day rather than as a stable organisational capability. I explored this earlier when writing about FinOps as a heroic side quest rather than a discipline.

The platform did not just reduce cost or risk. It reduced personal exposure. That is a powerful form of benevolence. It removes worry not only about money or uptime, but about blame.

When discretion moves from people to systems

For a long time, I assumed this benevolence lived in people.

Account managers appeared to have room to manoeuvre. There were escalation paths. There was a sense, real or inferred, that judgement could be applied when intent was clear but outcomes were not.

What I am now less certain of is whether that discretion still sits primarily with people.

Recent behaviour suggests a different shape. Benevolence appears increasingly pre-defined, bounded, and encoded upstream. The limits seem to be set in advance, with people acting as the conduit rather than the source.

In that world, the human does not decide how much benevolence is available. They deliver it.

“I have managed to get you Y.”

The sentence still sounds the same. The difference is where the decision was made.

This matches a broader pattern I have described elsewhere: when systems mature, humans increasingly become the interface rather than the arbiter.

The interaction feels responsive and supportive, but the logic lives elsewhere. This is not malice. It is scale.

What formalisation a system really means

Formalisasing a system does not mean becoming hostile. It means becoming consistent.

Systems are designed to enforce rules. They are not designed to interpret intent. Ambiguity, which is where benevolence often lives, is something systems are built to remove.

In The monster under the bed was always in the contract, I explored how many of the protections people assume exist were never actually written down. The discretion was behavioural, not contractual. The rules were always stricter than the experience suggested.

When systems take over from humans, that gap becomes visible. The contract does not change. The interpretation does.

Benevolence reallocates to where hesitation is costly

This does not mean benevolence disappears. It moves.

More precisely, it follows risk. Not technical risk, but customer risk. It concentrates where the long-term cost of a customer becoming cautious is highest.

There was a time when moving to the cloud at all was the inflection point. Early friction or failure could stall adoption entirely. Benevolence helped remove fear and keep momentum. That inflection point has moved. For many organisations, the cloud is settled. AI is not.

Errors are harder to see, failures propagate faster, and the consequences can be materially larger. Hesitation is easier, and more dangerous. Under that lens, it would be surprising if benevolence were not concentrated there.

This is not about fashion. It is about downside.

Companies routinely set aside capital for legal exposure where the risk is existential. Benevolence works in a similar way. It is deployed where losing confidence would change behaviour at scale.

Everywhere else, the system tightens, not because it is uncaring, but because it assumes the rules are already known.

When the contract becomes the floor, not the backstop

One practical consequence of this evolution is that contracts matter more than past behaviours and assumptions.

The uncomfortable question is not whether AWS is reasonable or unreasonable. It is simpler than that.

What happens to me when the platform follows the contract as written?

AWS contracts are deliberately broad. Service level agreements focus almost entirely on availability. Uptime is defined, measured, and compensated. Performance largely is not.

A system can be technically up and still unusable. Most practitioners know this instinctively. The contract does not.

If my home fibre connection runs at a fraction of its expected throughput, it is effectively broken even if it never goes down. In contractual terms, however, nothing has failed.

When human discretion mediated the gap between those two realities, the difference mattered less. When systems enforce the rules directly, it matters a great deal.

The risk is not that AWS changed the contract. The risk is that many of us never updated our understanding of what actually protects us.

The monster, as it turns out, was always there.

A small but important adjustment

This does not call for outrage, nor for legal theatre. It calls for adjustment.

If systems now resolve situations that humans once handled, it makes sense to look again at where discretion ends. The public AWS and Amazon contracts are one place to do that, not as legal documents in the abstract, but as descriptions of boundary conditions.

With today’s tools, it is possible to analyse those contracts using an LLM. Not for legal certainty. This is not legal advice. The goal is to surface patterns, asymmetries, and edge cases that are easy to miss when reading linearly.

The interesting parts are rarely the steady state. They are what happens when something starts, degrades, is throttled, suspended, or stopped.

I am likely to do this myself and share the result, clearly labelled for what it is. I would also be interested to see how others in the FinOps community read the same documents through this lens. Public contracts only. Shared interpretation, not gotchas.

From comfort to clarity

None of this means AWS has stopped caring about customers.

It does suggest that customer focus no longer operates as the default tie-breaker everywhere. In some domains, especially those now treated as settled, consistency and enforceability appear to take precedence.

The AWS many of us learned to work with absorbed worry through people. The AWS we are interacting with now increasingly absorbs risk through systems.

Once you see that, recent behaviour becomes easier to read.

You start interacting with the platform differently. Not defensively, but deliberately.

That, more than any announcement, is what has changed for me.