One VPC per Application/service v/s One VPC for all the Applications/services

0

Hi,

I am working for a client and we needed to make a decision on VPC design. I have following question

  1. What are the Pro and Cons of One VPC per Application/service v/s One VPC for all the Applications/services

Background

  1. customer will migrate/deploy 100+ Applications/services
asked 2 years ago1.7K views
3 Answers
2
Accepted Answer

In a multi-account architecture using AWS Organizations or ControlTower, the use of multiple accounts acts as a natural security boundary to simplify security administration. This structure also reduces the blast radius in the event of a compromise or other such event. With this in mind, you should be approaching your network design with these principles in mind.

VPCs provide natural networking boundaries which need to be intentionally connected. An AWS TransitGateway can be used to provide connectivity between VPCs with course grain control of traffic between VPCs. Using the TransitGateway along with an AWS NetworkFirewall, you can create a central inspection network with fine grain control between VPCs - down to the IP and/or port level. This patter can also be used to create a centralized egress point where you could easily setup a permit list strategy to tightly control what talks to the Internet.

Taking a step back and looking inside your VPC, it is a great container for creating a secure workload. Using Subnets and NACLs you can provide control of traffic in and out of each container. The use of Security Groups can create flexible rules that allow very narrow communication. For example, a SecurityGroup on the ENIs of your database servers can block access to the DB port to all except the SecurityGroup assigned to the web servers. These Subnets can create a defense in depth for your various resources.

Multi-VPC and Multi-Account comes into play when you need to create HA systems. When you start looking at having connectivity across VPCs you are looking at additional costs to put that connectivity in place. VPC Peering, Transit Gateways, etc. all come with a cost and can increase latency. So you need to understand your objectives and map them onto a design using some of the ideas mentioned above.

Here are some additional links to help you get a little deeper on the subjects:

profile pictureAWS
answered 2 years ago
profile picture
EXPERT
reviewed 4 months ago
2

Hello,

When dealing with this kind of inquire, I like to explore what can be done to limit the impact when applications have non-expected behavior and how it could impact the neighborhood (fault isolation/resilience).

I will share some useful content that can help you to be better prepared to design solutions:

Hope it helps you! :)

AWS
answered 2 years ago
1

There's some great answers here already from @NightCrawler and @Christian Loris, but I'll add a pragmatic note. A pattern we've often used is to look at how to divide the Business into a number of Business Domains based on responsibility and security, and do similarly for technical domains (e.g. deployment environments). Then build your multi-account and multi-VPC structure around that. In general that means you wouldn't go as fine-grained as one VPC per app/service.

EXPERT
answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions