In AWS, while configuring CLB and ALB type of Load balancers, it is mandatory to associate a Security Group. This association helps in limiting the type of traffic to the Load balancer. Why is a Security Group not required for an NLB? Is it not a security risk? I know the best guess here could be - "AWS designed it this way" but their documentation does not seem to explain the reasoning / advantage on omitting security group configuration for NLB.
3 Answers
6
votes
NLB is not an exception. NAT gateway also does not have SGs.
The major difference between ALB, CLB and NLB (and NAT) is that their network interfaces (ENI) have different Source/dest. check setting.
For ALB and CLB, the Source/dest. check is true. For NLB and NAT gateway, the option is false. Although I don't know the technical reasons why there are no SGs for NLB and NAT, I think a part of the reason could be due to the Source/dest. check settings:
Indicates whether source/destination checks are performed, where the instance must be the source or destination of any traffic it sends or receives.
Thus, in my view the reason is due to intended purpose of NAT and NLB, rather than a technical inability of AWS to provide SGs on them. Their main purpose is to act as a proxy. NLB nor NAT generally do not interfere with the traffic, and mostly just pass it through. Its up to the destinations to determine if the traffic is allowed or not. Thus NAT nor NLB don't use SGs. They only way to block incoming traffic to them is through NACLs.
In contrast, ALB and CLB take active part in the transfer of traffic as they inspect all requests. Therefore, they also have ability to decide whether the traffic is allowed or not.
1
votes
I guess a security group is not required for a Network Load Balancer (NLB) because it behaves transparently by preserving the source IP for the associated target instances. That is, you can still specify security groups - but at the target level directly instead of the load balancer. So conceptually, it does not make much of a difference (when using EC2 instances behind an NLB) where the SGs are specified. Although, some people point out it might be tricky to restrict the IP range for the NLB health check. [1] Moreover, I think it might be more convenient to specify security group rules once (centrally) at the load balancer instead of attaching a specific security group to each EC2 instance which is a target of an NLB. These two can be seen as shortcomings of the NLB compared to the other two load balancers.
Technically, the NLB is built on a completely new technology compared to the ALB/CLB. Some of the differences are pointed out on reddit by an AWS employee [2]:
At a high level, Classic (CLB) and Application (ALB) Load Balancers are a collection of load balancing resources connected to your VPC by a collection of Elastic Network Interfaces (ENIs). They have listeners that accept requests from clients and route them to your targets (ALB & NLB) / backends (CLB). In the same vein, a Network Load Balancer (NLB) is a similar grouping of load balancing resources connected to your VPC, but using an AWS Hyperplane ENI, instead of a regular ENI. A Hyperplane ENI is a distributed construct that integrates with EC2's Software Defined Network (SDN) to transparently connect multiple underlying load balancing resources via a single IP address.
Everyone who did not hear the term Hyperplane before, feel free to check out the corresponding re:Invent session. [3] Hyperplane is used for NAT Gateway, PrivateLink and Lambda's improved VPC Networking [4].
Given how much Hyperplane is capable to do and also given the fact that it is built on EC2, I see no reason why AWS could not have implemented SGs for NLBs if they wanted to. I agree with @Marcin that this is probably by design.
[1] https://forums.aws.amazon.com/thread.jspa?threadID=263245
[2] https://www.reddit.com/r/aws/comments/cwbkw4/behind_the_scenes_what_is_an_aws_load_balancer/#t1_eyb2gji
[3] https://www.youtube.com/watch?v=8gc2DgBqo9U#t=33m40s
[4] https://aws.amazon.com/de/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/
0
votes
NLB works at the fourth layer of the OSI model, the communication goes through the network load balancer, and the connection details reach to target, in this case, the EC2 instances receives the client IP and the instance security group have to allow source client's IPs.
ALB works at the seventh layer of the OSI model, the communication reach to ALB listener and then it opens a connection to targets, the EC2 instance receives the ALB IPs instead of clients IPs
For more details, https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html
