AWS IAM Identity Center

Substrate was inspired by an ambitious AWS network architectural migration the Melbourne-based Cloud Engineering team at Slack took on circa 2018, which they inexplicably called Project White Castle. The high points of that project were lots of AWS accounts, shared VPCs, private subnets, HTTP proxies for outbound Internet access, and command-line tools for moving between accounts. Sound familiar?

This work began after AWS Organizations launched but before AWS SSO gained enough useful features to be renamed AWS IAM Identity Center. That change came in the summer of 2022, a full two years after Substrate had been pounding the pavement telling folks they should have lots of AWS accounts. With the name change came a new intensity of AWS pushing customers large and small to adopt IAM Identity Center and, yes, have lots of AWS accounts.

On that highest-level point — encouraging folks to have lots of AWS accounts — both AWS IAM Identity Center and Substrate receive high marks. Yet we always saw (and explained) IAM Identity Center as a great way to create lots of AWS accounts but Substrate was a great way to accomplish something with lots of AWS accounts.

On the adoption front, however, AWS IAM Identity Center won and it wasn’t even close. I’m going to use this last reflection on Source & Binary to offer my (more than a little bitter) thoughts about IAM Identity Center. In short, I don’t think this is AWS’ best work.

When the conventional wisdom became to have lots of AWS accounts, it also became to do as little as possible in the management account. Access to the management account usually implies access to the rest of the accounts, which partially defeats the purpose of separation. Plus Service Controls Policies don’t apply to the management account. This is the flag that captures all flags. And yet the canonical way to configure AWS IAM Identity Center is to drop it in the management account. It boggles the mind.

It won’t do to allow folks to assume IAM roles in the management account, though, so AWS IAM Identity Center, running in the management account, had to invent a new almost-but-not-quite-an-IAM-role primitive. They call these permission sets and they would honestly be fine if they weren’t completely unnecessary. Permission sets, account assignments, provisioning permission sets into accounts. It’s nothing that can’t be done with IAM roles and policies, but to avoid starting folks out with an IAM role in the management account there’s a whole parallel universe of nouns and verbs.

Finally, disappointingly, AWS IAM Identity Center relies on private APIs to implement seamless(ish) AWS Console access. Outsiders like me can’t straightforwardly logout, and the AWS Console rejects login attempts if you don’t logout first. I eventually found a pretty hacky way around this for Substrate using a few nested window.open(url, target) and setTimeout calls like it’s 1999.

But if you can’t beat ’em, join ’em. You should still have lots of AWS accounts and nowadays you should probably access them via IAM Identity Center.

This article is part of a series on Source & Binary, my company that operated from 2020 through 2024.