What should the SysOps administrator do to meet these requirements with the LEAST operational overhead?
Configure the security group that is associated with the EC2 instances to allow traffic from only the security group that is associated with the NLB
Configure the security group that is associated with the EC2 instances to allow traffic from only the elastic network interfaces that are associated with the NLB
Create a network ACL Associate the network ACL with the application subnets. Configure the network ACL to allow inbound traffic from only the CIDR ranges of the NLB
Use a third-party firewall solution that is installed on a separate EC2 instance. Configure a firewall rule that allows traffic to the application’s EC2 instances from only the subnets where the NLB is deployed.
Explanations:
This option allows the EC2 instances to accept traffic only from the NLB’s security group. It simplifies management since the rules automatically adjust if the NLB’s security group changes, providing an efficient way to control access with minimal overhead.
This option suggests allowing traffic from the elastic network interfaces (ENIs) associated with the NLB, which is not a practical approach. ENIs can change, and this method would require constant updates, increasing operational overhead.
While network ACLs can restrict traffic, managing them involves more complexity compared to security groups. Additionally, network ACLs apply to the subnet level rather than specific instances, which might not adequately restrict access only to the NLB.
Implementing a third-party firewall solution introduces unnecessary complexity and operational overhead. This solution requires additional management, maintenance, and potential costs, making it less efficient compared to using security groups.
It appears that the answer is:
Configure the security group that is associated with the EC2 instances to allow traffic from only the security group that is associated with the NLB