The good practice is to have production fully separated from test or development environments, which is best achieved by having separate accounts for them:

Accounts in the SDLC OU host non-production workloads and therefore should not have production dependencies from other accounts.

Since you are not using different account, the closest you can get (if you want to follow the good practice) is to have different VPCs (option 1). What's more, to further separate the environments, the VPCs could be in different regions.

Also I would encourage you to re-think why do you need any common resources (i.e. forth VPC). If you share something (e.g. RDS) between prod and devel through the forth VPC, it is a disaster waiting to happen.

I came across a similar problem.

VPC per environment can create great separation between resources, so I would recommend having at least PROD and nonPROD (dev, test, uat) VPC.

Having one VPC per environment can cause an increase in costs:

• NAT Gateway / NAT Instance per subnet per VPC
• VPC Endpoints (they can be pretty expensive, around 7 USD per endpoint and you often need more than one, but you have to keep in mind you can have only one subnet per AZ attached).
• VPN (inside every VPC)
• CICD (if you are using self-hosted agents [e.g. using Azure DevOps] you need an agent in every VPC)
• Management can be more difficult (more redundant resources etc.).

(Of course, you can solve some issue using VPC Peering, but I do not think this is the proper solution in this case)

On the other side having one VPC per environment can create some benefits:

• Subnet matrix can be the same for all ENVs, so it is easier to debug
• One VPN per environment can lower chance to be "in the wrong environment by accident"
• Minimum the risk of mutual resource affection.

For a Production environment, the clear answer is to isolate it into its own AWS Account (not just a separate VPC). With Control Tower and SSO, the complexity of managing multiple AWS Accounts is not what it used to be.

For NON production environments like Dev, Staging, QA, Demo, etc, the answer is less clear. I would certainly like to hear from others. I can see 3 main ways to do it.

1. Each environment has its own AWS Account. This could used for Demo or UAT environments (beside Prod), but it seems overkill for other types of environments that are typically used internally for development. There is also an added cost to this solution.

2. Each environment has its own VPC, inside one shared AWS Account. This isolate each environment on a network level and ACL level.

   Cons:

   • Limit of 5 VPCs per AWS Account
   • Extra costs as answered by [Filip Niko above.

   Pros:

   • Simplified setup? Since all VPCs can be provisioned identically (through CDK for instance).
   • Better isolation between environments than solution 3 below.

3. Each environment has its own network stack, inside a shared VPC and AWS Account.

   Cons:

   • Harder to "drop and recreate". With CDK, one can easily provision a new "environment" by creating the VPC and its services. I am guessing (please confirm) that this is harder when one VPC contains everything.
   • Not secure for public facing environments.

   Pros:

   • A VPC can have 200 subnets. Even if one allocates 3 subnets per environments (public, private and isolated), this gives ~60 environments.
   • Cheaper overall. Less NAT, Endpoints needed.

I'd love to hear feedback on the above.