Attach NSG to NAT gateway's interface

How can I attach a stateful NSG to a NAT gateway's network interface in AWS? If I try to add it manually, I get the following error: "You do not have permission to access the specified resource." in the portal.

By default, the NAT gateway's interface has no NSG attached, so VPC Flow Logs show inbound internet traffic as accepted. I know the actual traffic isn't accepted by the NAT gateway and is dropped, but this is still very annoying as it clutters logs.

Here, the NAT gateway's private IP is 10.0.1.226 and you can see it's getting probed from the public internet:

version  account-id    interface-id           srcaddr          dstaddr     srcport  dstport  protocol  packets  bytes  start       end         action  log-status
2        770604943877  eni-0d9c6092f69e85b93  162.142.125.159  10.0.1.226  54995    20121    6         1        44     1631843704  1631843705  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  192.241.207.249  10.0.1.226  37490    8098     6         1        40     1631843722  1631843724  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  89.248.165.59    10.0.1.226  52915    5017     6         1        40     1631843709  1631843741  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  45.135.232.119   10.0.1.226  43453    8737     6         1        40     1631843761  1631843762  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  162.142.125.149  10.0.1.226  4078     9010     6         1        44     1631843780  1631843782  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  89.248.165.204   10.0.1.226  53823    5354     6         1        40     1631843789  1631843799  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  192.241.215.86   10.0.1.226  43709    137      17        1        78     1631843789  1631843799  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  162.142.125.146  10.0.1.226  14176    18045    6         1        44     1631843739  1631843790  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  162.142.125.150  10.0.1.226  48059    21381    6         1        44     1631843739  1631843790  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  185.191.34.207   10.0.1.226  59477    36       6         1        40     1631843739  1631843790  ACCEPT  OK
2        770604943877  eni-0d9c6092f69e85b93  91.132.58.183    10.0.1.226  5106     5162     17        1        443    1631843739  1631843790  ACCEPT  OK

If I add network ACLs to deny inbound traffic from the internet, it will prevent VPC-initiated outbound internet access too. Since ACLs are stateless, inbound reply traffic from the internet will be blocked.

I'm finding your question slightly confusing. When you say "NSG" I assume you mean "Security Group". Azure has "Network Security Groups", AWS as Security Groups. Also, you haven't said what you're trying to achieve, you've said what's not working, which makes it difficult to help you. I'll give you some general thoughts, but if these aren't right please edit your question to say what you're trying to achieve, and fix up the abbreviations.

NAT Gateways do not have a security group. A security group is a firewall around an ENI, such as on an EC2 instance. You don't pay for inbound traffic so you shouldn't really care about what is rejected by the NAT gateway other than for security investigations of specific issues / incidents. Nothing comes in a NAT gateway, that's what they're for.

It sounds like your main issue is the deny traffic in the VPC flow logs, for traffic the NAT gateway rejects from the internet. My main advice is to ignore it, as maybe it will be useful one day for forensic purposes in a high security environment, or turn off VPC flow logs if you don't need them. I use VPC flow logs for diagnostics, and only leave them on log term where PCI / CIS / similar compliance is required There's always going to be a lot of reject traffic in those logs. I once spent quite a bit of time trying to track down rejects in an internal subnet with no internet access, but I ran out of time before I got anywhere. I just let it go.

You can change the scope of the VPC flow logs. Instead of creating a flow log for the whole VPC you create a flow log only for only your private subnets, and make sure your NAT gateway is in the public subnet. That way don't log the deny traffic from the internet.

You can also configure flow logs to log ACCEPT, REJECT, or BOTH types of traffic.

To summarize and address your comment:

1. VPC flow logs are a tool that are used for network diagnostics (and rarely turned on), or for compliance logging (always on but deliberately scoped). Not many people turn them on.
2. I only turn VPC Flow Logs on when I have a good reason to. When I do I scope them to the network interfaces and traffic type I need (accept / reject / both).
3. I only look at the VPC flow logs when I'm doing network diagnostics. When I'm looking at them it's for a specific interface / event so I ignore everything I don't need to see.
4. I have the Cloudwatch Log Group set to an appropriate retention period.