Are you publishing a web application / API? If so you should probably use an application load balancer rather than a network load balancer. NLBs are usually used for non-http(s) applications, you can use them with http(s) but ALBs tend to be better suited.
Design Considerations
I suggest you think about whether you really need a static IP. Some legacy or embedded systems might need it, but most are ok with a DNS address. If you really need a static IP you can use one of these techniques (or others you find on Google) to give an ALB a static IP, AWS Global Accelerator would do it but I'm not sure it's a good solution for you. You'd also have to consider high availability.
Regarding static IPs for whitelisting, you could consider doing authentication either with AWS Cognito integrated with the ALB (best) or inside your container. We usually federate with Azure AD, but you can define users / groups in Cognito. Users traffic to the ALB only gets to the target container / server if Cognito authorises the traffic.
Primary recommendation: AWS ALB integrated with AWS Cognito for authentication, security group around the ALB if you like but no whitelisting required.
Original Question
ALBs have security groups. Network load balancers do not. An NLB is invisible to the traffic so you put a security group around your resource (container) rather than your load balancer.
ALB IP whitelisting options:
- You can whitelist access to an ALB with a security group, but you can't blacklist with a security group. There's a maximum number of rules, but each ALB can probably have multiple SGs attached - though be careful as it can impact performance. This is my secondary recommendation to you if you don't want to use Cognito.
- You can whitelist or blacklist with Network Access Control Lists (NACLs)
- You can do something inside the container with a local firewall, but I don't suggest that
NLB IP Whitelisting options:
- Security group around the ECS container
- NACL around the subnet(s)
