- Newest
- Most votes
- Most comments
These network interfaces are managed by AWS and are not intended to be directly modified by users.
AWS recommends deploying the transit gateway in a dedicated subnet (ref. this link), and then using Network ACLs to limit access to the Elastic Network Interfaces (ENIs) running within that subnet. This /28 subnet approach allows for more granular control over the traffic flowing through the transit gateway, as Network ACLs can be used to restrict access at the subnet level.
You cannot modify or associate security groups with network interfaces created by AWS Transit Gateway attachments. These interfaces are managed by AWS, and security groups cannot be applied to them.
To secure traffic, you'll need to focus on:
- Security Groups: Apply them to the individual instances or resources within your VPCs.
- Network ACLs: Use them at the subnet level to control traffic at the network boundary.
- Transit Gateway Route Tables: Use these to manage traffic routing between your VPCs and on-premises resources. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html
but why the option is existing and available for editing ! what is bad with NACL is that it is not stateful and if a new subnet in the VPC is created you can not guarantee which NACL is added to it , there should be a security control on the connection between the VPC and the transit gateway. also the transit gateway routing table is a reachability tool not a security one!
You're quite right that NACLs are rarely useful for a variety of reasons and that the Transit Gateway's capabilities are limited to being essentially a massive but ultimately simple router. Security groups don't apply to any routing-based constructs, such as TGW attachments, gateway load balancers, virtual private gateways (VGW), internet gateways (IGW), or NAT gateways, and the reason the graphical console displays the options is that for the EC2 console, all elastic network interfaces (ENIs) in the VPC are just interfaces, without individual differences in capabilities. It's the service that owns the ENI, such as TGW, that controls which operations are supported on its ENIs.
The way in which TGW can be combined with granular, centralised, and scalable access controls is by accompanying the TGW with a firewall, and using the TGW's route tables to force traffic between the networks you specify to pass through the firewall. This allows you to accomplish what you described, centrally controlling which exact traffic each VPC is allowed to send to any destination through the TGW.
There's an overview of the approach in this AWS blog post: https://aws.amazon.com/blogs/networking-and-content-delivery/deploy-centralized-traffic-filtering-using-aws-network-firewall/ and a more in-depth analysis of different deployment models here: https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/
but why the option is existing and available for editing ! what is bad with NACL is that it is not stateful and if a new subnet in the VPC is created you can not guarantee which NACL is added to it , there should be a security control on the connection between the VPC and the transit gateway. also the transit gateway routing table is a reachability tool not a security one!
The transit gateway route table is great for segmenting traffic, for exmaple, one RT for prod, dev, test and so on. What i see many AWS Users do, they introduce for example a next gen firewall (Network firewall, or other 3rd party appliances) when traffic are crossing segment. And the NACL, even though beeing stateless, you can create granular access based on the requirements you have, hence solving your problem imo. Maybe not the best solution to your point, but either that or central inspection with a next gen firewall. as i see it in addition to having Security groups on the target and source network interface as well.
@emnded I'd say NACLs are generally next to useless with niche exceptions. A NACL can only have a maximum of 40 rules and max 20 recommended; it can only inspect either the source CIDR (for inbound NACLs) or destination CIDR (outbound) but not both in combination; and it only deals with IP addresses, as opposed to the dynamic ENI associations that security groups have. NACLs can work fine for e.g. blocking access to the TGW from public subnets while allowing from private subnets, but not for any semblance of granular control that I can recognise.