CloudFront and Application Load Balancer based Routing of Applications for Increased Security

When an application is hosted via load balancer, it is possible to get security vulnerabilities through inappropriate access hence protecting to limit right user access needs expert solutions such as AWS CloudFront-explored this option by creating new Cloud Front Distribution for a ALB and shared insight in this article.

Initial Setup of Application via ALB

A load balancer in AWS distributes incoming network traffic across multiple targets, such as EC2 instances or containers, to ensure no single resource becomes overwhelmed. It improves application availability, fault tolerance, and performance by evenly spreading the load.

For example, imagine a web application hosted on multiple EC2 instances behind an AWS Application Load Balancer (ALB). When users access the website, the ALB directs traffic to the least busy instance, reducing the risk of overload. If one instance fails, the load balancer reroutes traffic to healthy instances, ensuring continuous service. This setup is common for high-traffic e-commerce sites, where consistent performance and uptime are critical.

Strong Needs to Have End Point Security using AWS CloudFront Distribution

Bad actors can target an AWS Load Balancer directly if its endpoint is exposed to the public internet without CloudFront or other security measures. They can exploit this by sending a high volume of requests, attempting DDoS attacks, or probing for vulnerabilities in the backend instances. Without CloudFront's advanced threat protection and caching, the load balancer and backend services must handle all incoming traffic, increasing the risk of overload or a security breach.

Assume that if a company's APIs were directly exposed through an Application Load Balancer. Attackers can discover the ALB's DNS name and launch a bot-driven DDoS attack. Because there was no CloudFront to absorb or mitigate the traffic, the load balancer became overwhelmed, impacting service availability. Properly configuring CloudFront, Web Application Firewalls (WAF), and using AWS Shield could have prevented this by filtering traffic before it reached the load balancer.

Steps involved in Configuration of AWS CF Distribution

Best idea is to enable custom header at cloud front distribution to avoid bad actors and increase end point security:

Now, let us take a close look at Application Load Balancer that DNS Name of this load balancer helps launching the application when pasting it in a new web browser:

This means the DNS directly launches the application without validating or distributing the throughput or the parallel requests hitting the load balancers directly. Hence it can potentially lead to a denial of service if multiple requests being made at same time for a longer period.

Introducing AWS Cloud Front on top of Load Balancer

Create a distribution in AWS by selecting the load balancer as origin:

Now choose the DNS Name or copy/paste to reflect in Origin Domain:

After that choose HTTP Only in protocol and create a new custom header:

Now update cashing as optimised:

After that make sure to redirect HTTP to HTTPS for a basic security while launching the application:

Now, recommended to enable WAF for live and critical systems and this is being disabled just for a Proof of Concept and ideal only for test environments:

Load Balancer Level Customisation

After that navigate back to load balancer and watch the listener of HTTP:80 which needs a tighter control to prevent unauthorised requests/loaded requests to target URL:

Now navigate to the listener to create a new rule for a header verification with the newly created custom header (at AWS Cloud Distribution):

After that, edit the default rule of listener and change from Forward to Target Groups to Return Fixed Response hence any bad actors can be displayed with error response of our choice:

Now update response body for 403 intending for any direct request to load balance which needs to be restricted:

After that, accessing direct DNS of load balancer will display error as expected-it means the direct access is impossible and completely restricted (as expected):

Now,navigating to the cloud front URL displays the target application by routing via AWS CF-this is the right approach to distribute the number of requests to application to prevent any DDoS:

Summary

AWS CloudFront helps prevent DDoS attacks by acting as a content delivery network (CDN) with built-in security features. When a DDoS attack occurs, it involves overwhelming a target with excessive traffic, often from a network of compromised devices. CloudFront mitigates these attacks through several technical measures. It distributes content across a global network of edge locations, which means traffic is handled closer to the users, reducing latency and making it difficult for attackers to focus on a single point.

If an attack targets a CloudFront-distributed endpoint, the traffic is absorbed and spread across multiple edge servers, reducing the impact on the origin server.

CloudFront integrates with AWS Shield, providing always-on DDoS protection by identifying and filtering malicious traffic patterns at the edge. For more sophisticated attacks, it works with AWS WAF (Web Application Firewall), allowing you to define rules to block specific traffic based on IP addresses, request patterns, or payloads. These combined layers ensure that even large-scale attacks are detected, filtered, and blocked before reaching backend resources, maintaining the availability and performance of your applications.

👉Please feel free to share your views in the comments section on simple application security mechanisms and use cases of AWS Cloud Distribution based on previous usages.

⚡Follow me on LinkedIn: Link

Like this article? Subscribe to Engineering Leadership , Digital Accessibility, Digital Payments Hub and Motivation newsletters to enjoy reading useful articles. Press SHARE and REPOST button to help sharing the content with your network.

#LinkedInNewsUK #FinanceLeadership