How can you restrict ALB traffic to CloudFront at the network layer?

Understanding the requirement

The company needs to ensure that all inbound traffic to the Application Load Balancer comes only from CloudFront. The key qualifiers are "network layer" and "most operationally efficient". In AWS, network-layer controls include VPC security groups and network ACLs that filter packets based on IP addresses, protocols, and ports. Application-layer controls, on the other hand, rely on HTTP headers, AWS WAF rules, or ALB listener logic.

Why option A is correct

Option A adds an inbound rule to the ALB's security group with the AWS managed prefix list for CloudFront as the source. A managed prefix list is a set of CIDR blocks that AWS maintains automatically for CloudFront edge locations. This means the security group will only accept traffic from CloudFront IP ranges, and AWS handles updates to those ranges. This is a network-layer enforcement because security groups filter traffic at the instance/ENI level.

This approach is also operationally efficient: there is no Lambda function, no custom header configuration, and no application changes. As community commenter [3] noted, the managed prefix list "can be used in the ALB's security group to restrict access to only traffic originating from CloudFront without manually managing IP ranges." Commenter [5] also emphasized that the question "explicitly ask[s] for changes at network layer," making option A the natural fit.

Why option B is incorrect

Option B appears network-related, but it has several problems. Network ACLs are stateless, so you would need to manage both inbound and outbound rules, including ephemeral ports for return traffic. More importantly, NACLs are attached to subnets, not to the ALB specifically, so they affect all traffic in those subnets, including traffic to other resources. Additionally, AWS managed prefix lists are not supported in network ACL rules; they are designed for security groups and route tables. Therefore, option B is not a valid solution, and even if it were, it would be less operationally efficient and less targeted than option A.

Why option C is incorrect

Option C uses a custom HTTP header that CloudFront adds to requests before forwarding them to the ALB. You would then configure an ALB rule to only forward traffic that contains that header. This is a valid and commonly documented approach for restricting access to an ALB, but it is an application-layer (Layer 7) solution. The question specifically requires implementation at the network layer, so option C fails the primary requirement. Community commenter [4] referenced the official AWS documentation for this approach, and commenter [8] voted for C, but they did not account for the explicit network-layer constraint. This is the classic trap in this question.

Why option D is incorrect

Option D uses AWS WAF with an IP set for CloudFront, updated by a Lambda function. WAF is a Layer 7 firewall, not a network-layer control. In addition, maintaining a WAF IP set and a Lambda updater introduces significant operational overhead. It is neither a network-layer solution nor the most operationally efficient way to meet the requirement. The managed prefix list in option A provides the same IP-based restriction with far less complexity and no custom automation.

Final conclusion

Option A is correct because it uses an AWS managed prefix list in the ALB's security group, meeting both the network-layer and operational-efficiency requirements. It avoids application changes, avoids stateless NACL complexity, and leverages AWS-managed IP updates. As community commenter [7] pointed out, the AWS announcement for the CloudFront managed prefix list confirms this is the intended solution.