The Challenge
Governance of AWS Identity Center (also known as AWS SSO) access across a 160+ account government environment at Geoscience Australia had, over roughly seven years, fragmented into 21 separate, disconnected tools - each one built to solve a single narrow slice of the problem: granting access, revoking it, listing who belonged to what, notifying an owner. None of them shared a design, an owner, or a way of working with the others.
None of this was a crisis in any single moment. But it left the organisation exposed in a way that only becomes obvious when someone asks a simple question: who has access to this account, and why?
What I Found
A review of the full estate confirmed the sprawl wasn't the result of one bad decision - it was the accumulation of many reasonable ones. Each tool solved a real problem in isolation, but none of them shared a data model, an approval workflow, or an owner, so nothing about the system as a whole was resilient, auditable or reportable. By the time I reviewed it, several tools had fallen out of use entirely, and most hadn't been touched in years.
On accountability: access decisions had no dependable, current link to the person actually responsible for the account, so approvals - where they existed at all - had no real authority behind them.
On visibility: there was no way for an owner to simply ask "who currently has access to my account?" without chasing someone down. That gap mattered more than any individual tool's shortcomings, because it meant revocation always lagged behind grant - access accumulated, and nothing forced it back down.
How I Approached It
I designed and built a single, AWS-native platform to replace the entire fragmented estate outright, rather than patching or extending what already existed.
The new solution is self-service: staff request access directly, it is routed straight to that owner for a decision by email. Revocation follows the same standard, always requiring the owner's approval. Every decision, is captured permanently, so there is a complete record of who approved what, and when.
Reporting was built as an equally self-service capability, not an afterthought someone has to be asked for: any account owner can request, at any time, a full picture of who currently holds access to their account.
What Changed
Twenty-one disconnected tools with no shared audit trail and no accountable approval path became one governed platform. Access requests that used to depend on finding whichever legacy tool still worked are now resolved in hours. Approval authority sits with each account's real, current owner instead of a static list nobody remembered to update. And for the first time, any owner across the 160+ account estate can see exactly who has access to their account, on demand.
These weren't just technical improvements. They translated into materially lower risk of stale or orphaned access sitting on sensitive accounts, an audit posture that can produce evidence on demand rather than being reconstructed after the fact, and meaningfully less ongoing administrative BAU load on the platform support team.
Lessons for Enterprise Cloud Platform Management
Sprawl is a symptom, not a starting point. Twenty-one tools didn't appear from one bad decision - they appeared from twenty-one reasonable ones, each solving an immediate problem without reference to the others. When a domain keeps generating one-off tooling, the fix is rarely "one more tool." It's stepping back and asking what the single system of record should have been from the start.
Self-service only works if the data behind it can be trusted. Automating an approval is only safe when it draws on account ownership information the organisation already keeps current, not a separate record that quietly drifts out of date.
Route accountability to the people who actually hold it. Tying approval to an account's real owners keeps decisions with the people who understand that account's risk, and keeps the platform team as the system's custodian rather than its bottleneck.
Visibility is what makes governance self-sustaining. A grant process without an equally easy way to see current access will always drift toward over-provisioning, because nobody can act on what they can't see. Making reporting self-service, not something someone has to be asked to run, is what actually lets revocation keep pace with grant.