Nlb associated to ecs service is not accessible with public ip address

The NLB config is using 172.31.23.46:444 as a Target. Note that it's sending the traffic to port 444, not 443.

Note: best practice is to allow clients to send traffic to your targets through your load balancer, but prevent them from sending traffic directly to your targets. Here is the article on how to do this: Security groups for your Network Load Balancer.

Also, you can use the SecurityGroupBlockedFlowCount_Inbound and SecurityGroupBlockedFlowCount_Outbound CloudWatch metrics to monitor the count of flows that are blocked by the load balancer security groups. Blocked traffic is not reflected in other metrics.

This isn't a Security Group issue. It's a port mismatch. It looks like your NLB is configure to send traffic to port 444 on your target, instead of port 80.

The flow logs show traffic originating from 184.105.139.70 trying to connect to 172.31.23.46 on port 444. are you trying to use port 444 or 443 on your target server? above you state "My task does not use ssl, the nlb is handling the ssl and terminating it." and I see in the RA that you're entering port 80 as the destination. so, I would expect the see VPC Flow Logs show traffic destined for port 80.

Are you using client IP preservation?

You need to use a security group to allow traffic from the public internet to the NLB and from the NLB to the targets servers. (You can Only associate security groups with a Network Load Balancer when you create it. If you created the NLB without associating any security groups, you can't associate them later on.)

Best practice is to add a rule to the security groups associated with your targets that references the security group associated with your Network Load Balancer. This allows clients to send traffic to your targets through your load balancer, but prevents them from sending traffic directly to your targets. Referencing the security group associated with your Network Load Balancer in the security groups associated with your targets ensures that your targets accept traffic from your load balancer even if you enable client IP preservation for your load balancer.

Do the route tables that are attached to the subnets hosting the NLB have the IPv4 default route 0.0.0.0/0 pointed at the VPC's IGW?

Is it the TCP connection to port 443 that is failing, or are you perhaps receiving an error about the TLS certificate on the NLB when trying to connect with a web browser?

Is the NLB's security group configured on the NLB?

That shows the attempt arriving on port tcp/444, not tcp/443. What's the target for the listener on port 444? Which type of health check does the target group have and is it showing as healthy?

I just ran the reachability analyzer on the igw to the private ip of the service and got this but I don't understand it

As input I entered this

Ok I've run it again with the public ip as the destination. I guess its getting stopped at the first eni. Can you tell me what this means: ENI_SG_RULES_MISMATCH: None of the ingress rules in the following security groups apply: sg-0d44cd5165049a640

I tried many variations but this one which is open to all does not work either

Yes the ra works with the all open sg for the nlb. What can I try next to get to my actual ecs service?

Could you show a screenshot of the inbound rules in sg-0d44cd5165049a640? You should have a rule permitting tcp/443 from 0.0.0.0/0 there.

Just took a look at the logs from the nlb and get this: tls 2.0 2024-08-01T13:54:13 net/smnlb1/fabc7bd295e05943 7bce7635ca3f0674 184.105.139.70:36646 172.31.23.46:444 179 177 0 0 - arn:aws:acm:us-east-2:201558611471:certificate/eaf9dc1f-86ed-4840-be43-afa842d0fc09 - ECDHE-RSA-AES128-GCM-SHA256 tlsv12 - - - - - 2024-08-01T13:54:13 tls 2.0 2024-08-01T13:54:20 net/smnlb1/fabc7bd295e05943 7bce7635ca3f0674 184.105.139.70:36652 172.31.23.46:444 371 369 0 0 - arn:aws:acm:us-east-2:201558611471:certificate/eaf9dc1f-86ed-4840-be43-afa842d0fc09 - TLS_AES_128_GCM_SHA256 tlsv13 - - - - - 2024-08-01T13:54:20

172.31.23.46 is the IP of the NLB, so it shouldn't be a target on any port. The target group should point to the IP 172.31.30.190 (or the corresponding instance ID) on the TCP (non-TLS) port 80 where the service is expected to listen.