Isolation AWS resources with multiple subnets vs multiple VPCs

Question

I have AWS resources (e.g. EC2s, RDS instances) that I would like to isolate from each other so that if one is compromised, the potential damage is limited. I am most concerned about data leakage / exfiltration. I can group these resources into logical "areas". Some of the resources need access to the public internet. Some of the resources need API access to other resources in different areas. Occasionally, developers will need to make SSH connections to the resources via OpenVPN, so those keys might also be a security risk.

My understanding is that I can split my resources in a few ways:

• A single VPC and a single subnet with communication controlled by security groups (I understand this is not recommended, buy why?)
• A single VPC with multiple subnets and controlled communication between them
• Multiple VPCs each containing multiple subnets, with controlled communication between them

What are the security implications of each approach?

Answer 1

A VPC is a virtual network within your AWS account, and within that VPC you can have multiple subnets.

There's 2 types of subnets, a public subnet and a private subnet.

• A public subnet, is just a subnet that has an internet gateway attached to it -- meaning it has the ability to connect to/from the internet.
• A private subnet is a subnet without an internet gateway attached. No internet access -- at least not directly.

If you have just one subnet across your VPC, you'd effectively have one giant public subnet, which means everything has potential internet access, at that point you'd be relying on Security groups only for your network protection.

Multiple VPCs with multiple subnets are generally more difficult to manage (you'd have to peer the VPCs together), and unless you absolutely need them I'd suggest a single VPC with multiple subnet approach.

Within that construct you can limit access to subnets/instances via both NACLs and Security Groups, which generally speaking is sufficient for most use-cases.