[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?