AWS VPC per environment, or single VPC with multiple subnets for different environments?

Question

Let's say I have three environments - Development, Test and Production. I believe I have two options on how to set them up in AWS:

1. Create a VPC per environment, so three VPCs in total. Then within each VPC add subnets in different availibility zones for availibility/redundancy. Create a fourth 'shared services' VPC that contains the services that all the different environments require.
2. Create a single VPC with multiple subnets. I would create the subnets in different availability zones and spread the different environment resoures evenly across the subnets, so that should one zone go down I don't lose an environment

Which one of these approaches is considered best practice? What are the advantages or disadvantages of each, if any? I'm new to AWS and so far have been unable to find a definitive answer for which is best

Answer 1

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.

Answer 2

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.