[SOLVED] AWS - Isolating subnets within a VPC

Issue

Say I have a vpc with network 10.130.0.0/16.

Is there anyway to isolate subnets within this /16 so that they cannot be routed between one another?

say I have 10.130.1.0/24 and 10.130.2.0/24 and I don't want them to talk to each other- is this possible?

I see the entire network as "local" when creating these subnets - would I need to move them out of the vpc to have isolation?

Solution

You do not need to move them out of the VPC for isolation. Instead, you can achieve this isolation using the VPC's built-in security features like NACLs and Security Groups.

In AWS, subnets within the same VPC can communicate with each other by default. This is because the main route table of a VPC typically has an entry that allows all subnets in the VPC to communicate with each other. Specifically, you might see a route with a destination of 10.130.0.0/16 (your VPC's CIDR block) and a target of "local", which means all traffic within the VPC is locally routable.

However, if you want to prevent two subnets from communicating with each other, you can do so using Network Access Control Lists (NACLs) or Security Groups (SGs). Here's how you can do it:

1. Using NACLs:

   • Network ACLs are stateless, meaning you need to define rules for both inbound and outbound traffic.
   • Create a NACL for each subnet.
   • For subnet 10.130.1.0/24:
     1. Allow all inbound and outbound traffic.
     2. Add a rule to deny all outbound traffic to 10.130.2.0/24.
     3. Similarly, add a rule to deny all inbound traffic from 10.130.2.0/24.
   • For subnet 10.130.2.0/24, do the opposite:
     1. Allow all inbound and outbound traffic.
     2. Add a rule to deny all outbound traffic to 10.130.1.0/24.
     3. Add a rule to deny all inbound traffic from 10.130.1.0/24.
   • Associate each NACL with its respective subnet.

2. Using Security Groups:

   • Security Groups are stateful, so if you deny outbound traffic, the corresponding inbound response is automatically denied (and vice-versa).
   • For instances in subnet 10.130.1.0/24:
     1. Create a security group (let's call it SG1) and assign it to them.
     2. Ensure there is no rule allowing traffic to or from the CIDR 10.130.2.0/24.
   • For instances in subnet 10.130.2.0/24:
     1. Create another security group (SG2) and assign it to them.
     2. Ensure there is no rule allowing traffic to or from the CIDR 10.130.1.0/24.

If both methods are used together, remember that NACLs are applied first, and then Security Groups. So, traffic would have to pass both to be allowed.

Answered By - Dmitry Kirsanov

Answer Checked By - Timothy Miller (WPSolving Admin)