Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
ALB security group with cloudFront origin-facing prefix list ingress setting blocks target group health check for eks fargate
I'm trying to secure an Application Load Balancer (ALB) behind CloudFront, following this AWS official documentation: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html#limit-access-to-origin-using-aws-managed-prefixes
According to the guide, I've configured my ALB's security group to only allow inbound traffic from the CloudFront origin-facing prefix list. However, once this is applied:
-
The ALB starts marking all targets as unhealthy (health checks fail, timesout).
-
My pods running in EKS Fargate no longer receive health check access logs (which they do when this restriction is removed).
This seems to imply that outbound traffic from the ALB to the targets (pods) is somehow blocked or broken when restricting ingress via prefix list.
Here’s what I’ve tried so far:
Added ingress rule to the ALB security group:
-
Allow from the CloudFront origin-facing prefix (port 443)
-
Allow from the VPC CIDR block (port 0), assuming ALB ENIs communicate internally
Unrestricted egress from the ALB security group
Despite these changes, ALB health checks still fail with timesout, and the pods do not log the incoming health check requests.
Question: What is the correct security group configuration (for ALB and/or Fargate) to both:
Enforce CloudFront-only access to the ALB, according to the doc
Allow ALB to perform health checks on EKS pods
Ensure pods can still log incoming requests from the ALB?
Any help would be appreciated — especially if this requires a different approach than the managed prefix list.
- Language
- English
- Newest
- Most votes
- Most comments
Please take the following approach:
- Application Load Balancer (ALB) Security Group Configuration • Ingress Restriction for Public Traffic: Restrict inbound traffic to the ALB’s security group by allowing only HTTPS (or the specified application port) connections originating from the CloudFront origin-facing prefix list. This configuration ensures that all user requests from the internet are routed through CloudFront before reaching the ALB. • Outbound Settings: Maintain unrestricted outbound rules in the ALB’s security group, or explicitly allow traffic to the target groups. This ensures that the ALB can forward incoming end-user requests and health check probes to the backend targets without interruption.
- EKS Fargate Targets Security Group Configuration • Allow Health Check Traffic from the ALB: Modify the security group associated with your EKS Fargate targets to permit inbound traffic on the designated health check port(s) (e.g., 80 or 443) from the ALB’s security group. To achieve this, specify the ALB’s security group as the source for these inbound rules.
• Type: Ingress • Protocol: TCP • Port: (Configured health check port, e.g., 80 or 443) • Source: [Security group assigned to the ALB]
Hey,
Hope you're keeping well.
When you restrict ALB ingress to only the CloudFront origin-facing prefix list, you’re also blocking the ALB’s own health check traffic because those checks originate from the ALB’s VPC subnets, not from CloudFront. The solution is to keep the CloudFront prefix list rule for port 443, but also add an ingress rule in the target group’s security group that allows the ALB’s security group itself as a source on the health check port. In AWS terms, the EKS Fargate pod’s security group should allow inbound from the ALB’s security group, and the ALB’s security group should allow inbound from the CloudFront prefix list for public traffic.
Thanks and regards,
Taz
WOW! it works!! thank you!!!!!