It may be a 'must' for security but from a UX perspective it is a horrible experience.

Does it make sense for one team to have 10+ AWS accounts per service because 'security'? How about if each team out of 1000s in your company has 10 AWS accounts per service?

We run our service in 3 geographic regions and have a separate AWS account for each region and stage despite each account supporting resources in multiple regions. Considering that we have 4~ services that is roughly 40 AWS accounts for just one team with less than 10 people.

What I'm describing above is the 'best practice' way to manage AWS accounts at scale. It is insane and saying 'security' does not magically make this reasonable.

I was so happy when I finally got cross-account roles working so I could use a nice drop down and seamlessly switch between my accounts. So cool!

Then I learned because they’re saving it all browser-side I had to rebuild the whole menu whenever I first used a new browser or computer? Whaaaat? Of all people, AWS console users have to be highly likely to be using multiple devices/browsers. Having to recreate your own prefs at each new environment is nuts.

Not to mention that the there is a pretty small limit on how many can show up in the drop down (I don't remember how many) so it isn't very scalable if you follow the recommendations to create a lot of accounts.

Plus you have to look up the account id in order to set it up initially.

Second this recommendation. Our TAM suggested it and it works great. You can even install the Chrome plugin in the Edge browser.

This add on is highly recommended inside of Amazon and AWS, too.

The UX issue you're describing...can and should be solved with UX.

While security and UX are oftentimes in tension, in this case they don't have to be. It would not be that hard to be signed into multiple accounts and allow you to switch seamlessly between them (allow the tagging of each account, such that you can say, effectively, "show me dev us-east-1" vs "show me us-east-1" vs "show me dev", slicing and dicing between accounts that way). At that point, separating infra across accounts becomes semantically meaningful, and you can slice/dice in whatever way seems best (so you could have a full account for a single service, sure. Or an environment. Or a region. Or a combination of those, only service-Foo in us-east-1 for dev. Whatever level of granularity you want; trading off instead between the security of isolation with the convenience of colocation, which should be the actual UX cost; infra in the us-east-1 account has a harder time communicating with the infra in the us-west-1 account).

I already set this up. My customers are 5-10 man shops, and they have 5 different AWS Accounts: One for billing, one for Build Infrastructure, one each for Dev/Staging/Prod. Sometimes marketing is treated as a separate product team and their website has it's own staging/prod accounts (No real need for "dev" in that case).

Users login to the Build Infra account and then Assume Role into the others - There's a list of magic links that does the assume role. There's also a list that is added to ~/.aws/config that does the equivalent: They configure one IAM key, and the rest are assumed automatically by the CLI or client libraries (Requires relatively recent client libraries; Java only started supporting this within the last year or two)

Many people shit on GCP, but this is an area where they really shine.

You can set budgets by project and easily allocate costs and address accountability issues across teams or products.

The value depends on how you operate.

I happily use 40+ accounts per service, and don't think it's an undue burden. Accounts are free and represent a convenient natural boundary for data, access, and oopsie-daisy mitigation.

"Undue burden" and good UX is a wide chasm. In the last few months of my last role we went from the 1 account to multiple separating environments and the additional cognitive load and extra work migrating was not trivial (plus trying to keep costs down duplicating things for migration).

I can see how starting with a pattern of "account per X" would create intuitive boundaries. When you say "per service" what kind of service do you mean? Business related web service API? AWS product? Other? Interested in what boundary line made sense for you given the large number of accounts you say you're happy with using.

I would say one account per business-related Web service, per stage, is a sensible way to break it up. That gives you some visibility into what services are talking to what other services, logical cost breakdowns, and access controls pretty much where you'd want them.

With one giant caveat imho — I have a root account, an admin account, a common account (load balancer, database) and then customer-specific accounts. Was working great, using Terraform for consistency, sharing VPC where made sense, etc… until I had an issue and realized that my paid support plan only covered the root account. From what I understand you have to get a separate support plan, with a paid minimum ($100 per for business plan), for each account if you’re gonna need tech support, and you can’t pool until you’re in the $15K+ monthly spend: “AWS Support fees are calculated on a per-account basis for Business and Developer Support plans. For Enterprise Support, you are billed based on the aggregate monthly AWS charges for all your account IDs subscribed to Enterprise Support.”

Really soured me on the setup, tbh.

If you roll them all up into one Organization, then everything should be properly aggregated.

This is true. It does add additional complexity, especially if you have to do cross-account access, but the tooling for that is improving over time.

This seems silly to me. I (personally) think it is much more likely for your computer to be stolen/hacked/ransomed than a single account credential to be leaked. If so, "the blast radius" will be whatever you're logged into ... and if you're logged into everything, what's the point?

For AWS, blast radius includes things like “developer fucked up on using SSM and exceeded the rate limit for the entire account”. Or “developer failed to set API Gateway rate limit on their trivial app and brought down everything else in the account”

Because you should have 2fa set up and your access to AWS accounts should expire after 1 hour. Also, you likely have full disk encryption enabled, and the person stealing your laptop is unlikely to know who you work for and are more interested in selling it.

If someone acquires credentials, they are usually multi use and long term. And it can go unnoticed if an ec2 instance is span up running crypto mining on your dime, only for you to notice at the end of the day that your estimated bill has shot through the roof