Moving a live AWS organisation off standalone IAM is one of those projects that’s easy to justify and harder to execute than it looks on paper. This post covers why we did it, how we approached it, and the parts that didn’t go as cleanly as the AWS documentation implies. Or that I thought it would go.
The before state
The org started with two separate AWS accounts, a prod account and a dev account, with a singular admin responsible for deployment and configuration. This quickly grew, and by the time this project surfaced we were at just shy of 16 AWS accounts, four full-time Senior Engineers (one of them being lucky me). We had also onboarded and deployed roles to some of our Ops team and our Technologists, with a mixture of AWS roles behind Okta for SSO or standalone IAM users with long-term access keys.
None of it was catastrophic. All of it was wrong.
Why Identity Centre, why now
The decision to move to Identity Centre wasn’t driven by a security incident. It was driven by a review of the AWS estate that made it obvious we were managing permissions in a way that didn’t scale. We had 16 accounts in the org at that point, with more being onboarded as subsidiary companies came into scope. The thought of continuing to manage access account-by-account, user-by-user, was not a viable path forward. Nor was working with the outdated Okta integration helping the situation, as that required us to manually create the roles and then push them into the accounts. All of this was bogging us down and just made any changes we wanted to make more complex and slower than it needed to be.
Identity Centre solves the fundamental problem: one place to manage who can access what, across every account in the organisation. Permission sets replace per-account IAM policies. Okta handles the identity source. Temporary credentials replace long-lived access keys. Console access goes through a single SSO portal.
The other factor was Okta. We were already using Okta for everything else. Having AWS access live outside that ecosystem, with separate users, separate lifecycle and separate offboarding risk, was an inconsistency we wanted to close.
How it’s structured
Identity source
Identity Centre is configured to use Okta as the external identity provider via SCIM provisioning. Groups in Okta map to assignment groups in Identity Centre.
We leveraged the inbuilt OIN integration provided. Provisioning of users was straightforward for us. The grouping of users was a fairly logical one for us as we already had broken out most of our users for other app deployments. But we tried to group roles to a group, i.e. if title is Senior Engineer > you’re in Group Senior Engineer. The push groups were doing double duty, logically grouping users in Okta for our own sanity, while also landing directly into the correct Identity Centre assignment groups on the AWS side.
Permission sets
This was the trickiest part for us: how do you land on a permission set that works without breaking and stopping users from working. But at the same time you know you want to trim those permissions.
We hedged our bets on this one. We transplanted our main roles over from our accounts into new permission sets. The initial goal here was to get users off IAM users and get everyone into Identity Centre first, then tweak permission sets after the initial shock of people having a new way of doing things. Get people off long-lived access keys first, then tighten permission scope in the next pass. Trying to do both at once would have stalled the project.
| Permission set | Scope | Who gets it |
|---|---|---|
| ReadOnly | Full ReadOnly access to all of AWS services | All engineers |
| Billing | Billing, Cost Explorer | Finance and other stakeholders |
| Route53 | Access to Route53 console to purchase domains and modify DNS records | Engineers |
| Administrator | Full access | Senior engineers |
| PowerUsers | Limited full access to certain parts of the AWS tools, i.e. Lambda deployments etc | Devs |
There were a handful of additional sets beyond these covering more specific use cases, but these five represent the access tiers that most users landed in. We separated this further as our deployment grew more mature. An example was splitting our PowerUsers into more granular roles once we had a cleaner picture of what developers actually needed versus what the developers thought they needed when we first asked them.
Okta integration
We tried to streamline the process where possible, especially for users only needing access to one account and one role. Frankly the UI you land on in Identity Centre as a user isn’t the nicest for a finance person. We used bookmark apps for those singular roles/accounts, and published them alongside the group that was providing the access in the Identity Centre app.
From the user’s perspective it’s one login. From the access management perspective, adding or removing access is a group membership change in Okta, not a per-account IAM operation. Adding a new account is just onboarding the AWS account into the org and pushing permission sets you already have into that account.
The rollout
Sequencing
We didn’t try to migrate every account at once. The approach was:
- Stand up Identity Centre in the management account and connect Okta
- Build out permission sets
- Onboard a small pilot group across the various roles we were standing up
- Roll out account by account, decommissioning IAM users as we went
A word on step 4: as good as your documentation is, you’re going to miss something in your audit. Don’t delete the IAM users and roles at the same time. Delete the users but keep the roles, and rename them so you know what you’ve done and can revert cleanly. You will find out that an IAM user was being used for something critical that only runs once every three months.
The rinse and repeat part got easier as it went. Once people had been through it once and understood the new flow, the resistance dropped off and the subsequent rollouts got quicker. Overall, the initial rollout took just shy of three months and covered off our 16 accounts. Though we were still fine-tuning permissions and adding and splitting roles for a further six months, we were also battling the fun part of vendors requiring IAM users with long-term access keys (but that’s a blog post for another time).
What didn’t go cleanly
The SCIM provisioning lag.
This did cause me a bit of a nightmare initially, after we had onboarded our main users, i.e. the engineers who are in AWS every day. We went to integrate our QuickSight (or Quick, if anyone from AWS ever reads this please stop name changing that product) app into Identity Centre as well, as it was a better fit for users and group management than the previous Okta integration (if you know the pain of users not being manageable till they first logged in…). There was a delay between users showing in the QuickSight users list, even after everything had, according to the logs, gone correctly. This thankfully was a completely transparent issue and everything was still honoured in terms of group permissions etc. After a couple of calls with AWS support, they acknowledged the issue, and to this day we occasionally run into it.
Accounts that had been running on root. A few subsidiary accounts that came into the org had never had proper IAM users set up. They’d been accessed via root credentials. Getting those into a state where Identity Centre could take over required cleaning up the account first, which added time.
The “just check the console” habit. Operationally, the bigger friction was cultural. Engineers used to reaching for an access key to run a one-off CLI command had to shift to aws sso login and temporary credentials. Not difficult, but it takes a few weeks to become the default.
Where it sits now
All accounts are now provisioned through Identity Centre. The engineers who were previously on standalone IAM users now access AWS through the portal. A handful of accounts are still pending, either because they have service integrations that need untangling from IAM user credentials, or they simply don’t support IAM roles. Yes, in the year 2026 that is still a thing.
What it actually changed
- The operational difference is noticeable. Offboarding a user is one Okta group removal. Onboarding is the same. Auditing who has access to what is a single view in Identity Centre rather than a per-account exercise across 16 separate IAM user lists.
- The access key problem is largely gone for human access. No more keys sitting in
~/.aws/credentialsthat predate the last two engineers who left. - Onboarding of new AWS accounts became a lot simpler, which allowed us to create more accounts and break out into smaller contained accounts.
- Permission changes became just a matter of changing a permission set in a single place instead of across multiple accounts.
It’s not a glamorous project. Nobody asks for a demo of your SSO portal. But it’s the kind of foundational work that makes everything else easier to manage and harder to get wrong.