- Newest
- Most votes
- Most comments
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:
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:
- How AWS Minimizes the Blast Radius of Failures
- Reduce Blast Radius by Using Multiple AWS Accounts Per Region & Service
- How do you use fault isolation to protect your workload?
Hope it helps you! :)
Relevant content
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 2 years ago