[Sevii]

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.

[jsperx]

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.

[thayne]

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.

[nprateem]

https://addons.mozilla.org/en-US/firefox/addon/aws-extend-sw...

[coredog64]

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

[bradknowles]

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

[lostcolony]

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).

[GauntletWizard]

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)

[Spooky23]

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.

[WaxProlix]

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.

[layoric]

"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.

[emodendroket]

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.