One point of failure wearing three hats

Spent this week going back and forth on where agent permission scoping should actually live, platform layer or each API's own auth. Still don't love either answer. But the thing that stuck with me came from a cloud outage writeup, so that's where I landed for this issue.

There's a line in the AWS Bahrain/UAE outage report worth sitting with. AWS said the damage "exceeded what our regional and multi-AZ services are designed to withstand." Read that again. The vendor whose whole redundancy pitch is built on availability zones told you, in writing, that some failures are bigger than the design.

Most of us draw disaster recovery like a math problem. Two AZs, maybe three, a region failover if we're feeling responsible. The unspoken assumption is that failures are independent. One zone goes. The others carry the load. That assumption holds right up until the cause of the failure isn't local. A geopolitical event, a fiber cut that takes out correlated paths, a physical incident that hits the region as a unit. Now your three copies fail together and your redundancy math was fiction the whole time.

I've lived the version of this that doesn't make the news. Headquarters caught fire once. The DR plan I'd built actually ran, and we rebuilt infrastructure off it, but the thing I remember is how many of my "redundant" assumptions turned out to share a single physical dependency I'd never mapped. Power, cooling, one closet. On paper it looked resilient. In a fire it was one point of failure wearing three hats.

The honest question isn't "how many AZs do I have." It's "what do my copies share." Same region means same weather, same grid, same politics, same construction crew that might cut the wrong line. If your recovery story depends on two things that share any of those, you don't have two things.

This doesn't mean go multi-cloud on everything. That's expensive and it drags in its own coordination problems. It means know your blast radius honestly. For the workloads that genuinely can't go dark, a copy in a different region or a different provider isn't paranoia. It's the only version of redundancy that survives a correlated event. For everything else, be clear-eyed that your "multi-AZ" line item is protecting against hardware and software faults, not against the building.

The practical move is cheap. Take your DR diagram and, for every redundant pair, write down what they physically share. Not the logical topology, the physical one. Same rack, same room, same region, same power feed. The pairs that share a lot are the ones lying to you.

AWS did the useful thing here by admitting the limit out loud. Take them at their word and check whether your recovery plan was ever designed for the failure they just described.

1. AI agents are outrunning your identity governance
47% of CISOs can't see what their agents can access. I keep circling this from the build side, and the takeaway is the same: treat an agent like an identity with an owner and a revoke button, not like a service account you forget about.

2. Uber capped AI spend because it couldn't measure it
A $1,500/employee/month cap wasn't a cost problem. It was a measurement gap. Nobody was tracking cost per unit of work, so the only lever left was a blunt quota. Instrument the task, not the token.

3. Disk that auto-scales up never scales back down
Token economics is the new version of a lesson I learned on storage. Once a resource scales up under load, you pay for that headroom forever unless you force it back. LLM spend behaves the same way, and FinOps is finally naming it.

How honest is your DR diagram about what your "redundant" copies physically share? Hit reply, I read them all.