BACK
In the world of modern cloud architecture, security is paramount. When it comes to securing applications hosted on AWS using CloudFront, Application Load Balancers (ALB), and ECS, some critical security configurations can easily be overlooked. This blog outlines a few key steps to ensure your infrastructure is protected from unnecessary exposure, while also offering better control over incoming traffic.
In our architecture, we used a three-tier setup with CDN (CloudFront) in front of the ALB, which in turn directs traffic to the ECS services. The setup is highly scalable and efficient, but with a few potential security risks that need to be addressed.
Here’s how the issue can be tackled to ensure the infrastructure is as secure as possible
A common mistake is leaving the ALB’s Security Group open to all traffic, even though CloudFront is sitting in front of it. While CloudFront helps offload traffic and cache content, it doesn’t automatically restrict access to your ALB. Many setups allow traffic from any source on port 80 or 443, which means anyone could bypass CloudFront and directly reach the ALB.
To prevent this, AWS provides a prefix list that contains all the IP ranges for CloudFront. By configuring your ALB’s inbound rules to only allow traffic from this CloudFront prefix list, you ensure that only requests routed through your CDN can access the ALB.
Why this matters: This setup blocks direct access from the internet, reducing the attack surface. Even if someone knows the ALB endpoint, they won’t be able to connect directly unless they come through CloudFront.
While restricting traffic to CloudFront IP ranges is great, it’s still possible for other CloudFront distributions to hit your ALB, potentially causing security or availability issues.
To solve this, you can configure custom headers in CloudFront’s origin settings. These headers act like a signature, and only requests containing the right header and value are forwarded to the ALB.
Following the above step, ALB listener rules should be updated to forward traffic only if the correct custom header is present in the request. This adds an extra validation layer, ensuring only requests from our CloudFront distribution can reach the ALB.
Why this matters: This method ensures that no other CloudFront distributions (even with valid IPs) can access your ALB. It gives you granular control over the traffic flow and prevents any unauthorized requests from reaching your backend.
By default, ALB has a rule to forward any unmatched requests to the target group. However, if the request does not contain the necessary custom header, we don’t want it to reach our ECS services.
To handle this, you have to block the default rule in ALB. This rule simply rejects any request that doesn’t meet the custom header conditions, returning an appropriate status code like 403 Forbidden
This step ensures that any request without the correct header will never be processed, adding another layer of protection.
Securing your AWS infrastructure goes beyond the basic setup of CloudFront, ALB, and ECS. By leveraging CloudFront’s prefix list, adding custom headers, and configuring strict ALB rules, you can ensure that only legitimate traffic reaches your backend services. Combine these with proper monitoring and logging tools like CloudWatch and CloudTrail to maintain a secure, high-availability environment.
By following these best practices, we’ve fortified our architecture and reduced potential vulnerabilities — ensuring that our application can scale securely and efficiently.
Explore More
Experience the power of our cutting-edge technology firsthand
© 2025 TRINGAPPS, INC. ALL RIGHTS RESERVED
