[StreamBright]

I work with both style of AWS installations. Having organization is a constant pain for people who access multiple accounts even with something like Okta. 1 browser can access 1 account and if you switch you have to go through the switching process, or use multiple browsers. Quite often people would like to access cross account resources which a whole different level of discomfort. This is why I still think, old school or not, that having a single account and multiple VPCs is a better option.

[scarface74]

If you’re using AWS as a more expensive colo and mostly just using VMs it’s fine. But once you start actually using AWS for anything else it’s s pain. You have to worry about the different service limits and they are all shared.

What’s the process for giving developers access to experiment? When you have different accounts, the development department can have basically unlimited access to the account and moving to production is basically getting a CloudFormation template approved and run by the Devops team.

[StreamBright]

I am not using AWS as a more expensive colo, actually as a much much cheaper colo instead. I have optimized several workloads on AWS to save several hundred thousand / year for companies. In my experience giving unlimited access to anybody is a fairly bad idea since it that credential gets stolen you are going to quickly figure out how much a bitcoin mine costs on AWS. I find it counter productive to have a separate DevOps team and prefer the DevOps resources embedded into teams. I also do not like CloudFormation, it is a horribly verbose and complicated tool there are many alternatives that are better for the use cases for the customers I work with.

I agree that you have to worry about service limits which is exactly the right thing to have, instead of living a wasteful life pretending that we have infinite resources.

[scarface74]

The issue is that you have “shared” service limits between Dev, QA, and production. With separate accounts you can have service limits per environment. If you are worried about limiting dev resources, it’s a lot easier to do it per account using an organization.

How do you propose automating resource creation if not using either CloudFormation or an equivalent tool.

For instance, Parameter Store and Lambda have account level service limits. For lambda it’s 2000 concurrent instances. Do you really want all of your environments sharing that limit.

Parameter Store has a strict unchangeable limit per account. Do you want your dev environment affecting production?