Amazon CloudFront can serve as a content delivery network (CDN) not only for static files from S3 but also for custom HTTP backends, including EC2 instances and Application Load Balancers (ALB). This setup improves performance and security while ensuring a global, low-latency experience for users.

Pattern 1: CloudFront with EC2 Instance (Public Instance)

If you have an HTTP backend running on an EC2 instance, CloudFront can act as a proxy, distributing requests through its edge locations.

Setup Requirements

1. Public EC2 Instance:
   • The EC2 instance must be public because CloudFront does not have private VPC connectivity.
2. Security Group Configuration:
   • The EC2 instance’s security group must allow incoming requests from CloudFront edge locations.
   • AWS provides a list of CloudFront public IPs here.
3. How it Works:
   • Users access CloudFront edge locations.
   • CloudFront forwards requests to the EC2 instance.
   • The EC2 instance processes the request and responds through CloudFront.

📌 Key Limitation: The EC2 instance must remain public, which might pose a security risk.

Pattern 2: CloudFront with an Application Load Balancer (ALB)

A more secure approach is to use CloudFront with an ALB, allowing backend EC2 instances to remain private.

Setup Requirements

1. Public ALB, Private EC2 Instances:
   • The Application Load Balancer (ALB) is public-facing.
   • Backend EC2 instances can be private because ALB has private VPC connectivity with them.
2. Security Group Configuration:
   • The ALB security group must allow incoming traffic from CloudFront edge locations.
   • The EC2 security group must allow traffic from the ALB security group.
3. How it Works:
   • Users access CloudFront edge locations.
   • CloudFront routes requests to the ALB.
   • ALB forwards requests to private EC2 instances.
   • The response is returned via CloudFront.

✅ Key Benefit:

• Backend EC2 instances remain private, improving security.
• ALB handles load balancing, making it scalable and fault-tolerant.