CODEWITHSUNDEEP
amazon-web-servicesamazon-vpc
DraegerMTN
DraegerMTN

Reputation: 1131

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

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

Upvotes: 19

Views: 13629

Answers (3)

Bernard
Bernard

Reputation: 17261

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.

Upvotes: 2

FN_
FN_

Reputation: 853

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.

Upvotes: 9

Marcin
Marcin

Reputation: 238081

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.

Upvotes: 18

Related Questions