1

According to the AWS docs,

If a subnet is associated with a route table that has a route to an internet gateway, it's known as a public subnet

However, in my understanding, the subnet routing table only affects outbound traffic from the subnet, is that correct? What about the inbound traffic?

I assume that inbound traffic is enabled by default via the routing table of the internet gateway, but maybe my understanding is wrong. How could I check the hypothesis that inbound traffic is allowed? Commands like ping depend on bi-directional package flow, or?

gebbissimo
  • 2,137
  • 2
  • 25
  • 35
  • 1
    routing table is act as how a routing table should act! With NACL and Security Groups you have the capabilit to allow and restrict traffic – Sándor Bakos Jun 03 '22 at 08:05

2 Answers2

0

Keep in mind that:

A route table contains a set of rules, called routes, that determine where network traffic from your subnet or gateway is directed.

That's what a route table does it routes traffic according to rules.

Each route in a table specifies a destination and a target. That's it.

Your VPC has an implicit router, and you use route tables to control where network traffic is directed. Each subnet in your VPC must be associated with a route table, which controls the routing for the subnet (subnet route table). You can explicitly associate a subnet with a particular route table. Otherwise, the subnet is implicitly associated with the main route table.

Moving on...

A subnet is a range of IP addresses in your VPC. You can launch AWS resources into a specified subnet. Use a public subnet for resources that must be connected to the internet, and a private subnet for resources that won't be connected to the internet.

The part that allows the inbound and outbound traffic is on the subnet level.

To protect the AWS resources in each subnet, you can use multiple layers of security, including security groups and network access control lists (ACL).

From the docs:

By default, each custom network ACL denies all inbound and outbound traffic until you add rules. Each subnet in your VPC must be associated with a network ACL.

In other words, if you have a subnet, you must have a NACL, which supports allow rules and deny rules.

NACL is stateless, its return traffic must be allowed explicitly.

This is already set-up for you in all default VPCs your AWS account comes with. However, if you create a custom VPC, you need to take care of creating your own subnet, routing tables, Internet Gateways, NACLs and Security Groups etc.

baduker
  • 19,152
  • 9
  • 33
  • 56
  • Thanks for the detailed answer! Could you confirm that "A [subnet] route table [...] determines where network traffic FROM your subnet [...] is directed", but it does not affect network traffic TO the subnet? – gebbissimo Jun 06 '22 at 18:41
  • 1
    No. This is not how it works. Route table only *routes* (directs) traffic according to *rules*. A routing table is analogous to a distribution map in package delivery. Whenever a node needs to send data to another node on a network, it must first know where to send it. That's what a route table does. In order to control the ingress (TO) and egress (FROM) traffic you set up security groups and NACLs. That's the layer you need to focus on. – baduker Jun 07 '22 at 19:27
0

Okay, I feel like I get the full picture better now: The problem we are trying to solve is to make some resources "private", that is deny inbound traffic from outside your VPC to them, but still allow those private resouces to access the internet for e.g. updates.

There are a couple of ways to do this:

  • You could try to use Network Access Control Lists (NACL) but these affect inbound- and outbound traffic the same way ("stateless"). Therefore, you cannot deny inbound traffic while allowing outbound traffic. Also, they seem to be rarely recommended anyhow (see second comment of this SO post).
  • You could use security groups associated with each resource. This would work well but seems the less popular solution (maybe because it's easy to forget adding it?)
  • At last, you could setup a separate subnet without a route to the internet gateway but instead a route to a NAT gateway placed in another subnet with a route to the internet gateway. The NAT gateway routes outbound traffic to the IGW but hides the source IP address, thereby effectively denying inbound traffic (?). You'd then call these two subnets private and public, respectively. In other words, the terms "private subnet" and "public subnet" are really just names for this specific concept/solution and do not describe an inherent feature of the subnet.
gebbissimo
  • 2,137
  • 2
  • 25
  • 35
  • The recommended way of accomplishing this is setup your private subnets, create a NAT gateway in a public subnet, route traffic from private subnets to the NAT gateway, and route the public subnet to the internet gateway (IG). This will keep actors from the internet from accessing anything on your private subnet directly, however what's on the private subnet can reach out to the internet. You then use security groups to control everything else. Don't mess with NACLs. Then if you need remote access to what's on the private subnet, you can use client VPN, a jumphost in public subnet, or SSM. – Anthony Miller Jul 14 '23 at 16:22