AWS: limitations of using VPCs to manage environments? [closed] - amazon-web-services

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I've seen some companies manage multiple environments in AWS by using more accounts.
If a VPC is sorta like a virtual datacenter, it seems to me that using VPCs and IAM permissions should be enough to manage different environments.
What are some objective limitations of using a single AWS Account together with VPCs + IAM permissions for managing environments (dev, test, staging, prod)?
Example: another SO user has pointed out, AWS sets certain limits/quotas on an account basis, so excessive use of resources by one environment (VPC) would effectively impact another environment. To me this is as objective as you can get.
From personal experience, I have seen some times it's easier for people to figure out billing for big organizations if the environments are in different accounts. Whereas these limitations have more to do with the way the company operates, the company certainly feels it's an objective limitation.
So I'm trying to gather a list of these objective limitations why a company would decide to manage environments in other ways than simply through IAM + VPCs.
Another way of looking at the question would be, think of the recurrent environment management tasks/processes that you perform on a regular basis and then list those you could not do if you were only using VPCs + IAM.

Answer 1

From a network perspective: no
From a permissions model perspective: yes
Using an account per environment is the AWS-recommended approach for larger organizations because it enforces strict boundaries between environments. Doing a cross-environment call in a normal environment can be done easily (e.g. messing up the DynamoDB of prod instead of dev) whereas in a multiple-account setup you need to have different credentials.
Apart from the permissions model there is also an advantage in having limits per account (= per environment) instead of for your company. E.g. the Lambda concurrency limit is enforced on account level. Your dev environment can mess up your prod account in this situation.
Last but not least naming could also be a good reason to have an account per environment. E.g. variables in the Parameter Store have to be unique per account. Using multiple accounts you can use the same parameters for every environment without clashing. A similar thing is true for many resources, e.g. Cloudformation stacks.