CloudFront | ALB or EC2 as an origin Using VPC Origins.

How twteh Uses Amazon CloudFront with ALB or EC2 as an origin — especially with VPC-only resources — requires some understanding of how CloudFront handles private resources and what architecture makes that possible.

 Basics: CloudFront Origins

CloudFront supports several types of origins, such as:

·        S3 buckets

·        Application Load Balancers (ALB)

·        EC2 instances

·        API Gateway, MediaPackage, etc.

But CloudFront is a public service, so:

·        It cannot directly access private resources inside a VPC.

·        twtech must make the resource publicly accessible or use AWS PrivateLink / Lambda@Edge / CloudFront Functions / ALB integration.

 Use Case 1: CloudFront + ALB Origin (with EC2 in private subnets)

Recommended setup:

1.     ALB is public-facing (with an internet-facing scheme).

2.     ALB forwards traffic to EC2 instances in private subnets.

3.     CloudFront points to the public DNS name of the ALB.

Benefits:

·        EC2 remains in private subnet (not directly exposed).

·        CloudFront provides global caching, DDoS protection, and SSL termination.

·        ALB handles dynamic content, session stickiness, health checks.

 Security tip:

Use CloudFront origin access control:

·        Configure CloudFront with a custom header (e.g., X-Origin-Token) that only CloudFront sends.

·        At ALB/EC2 level, verify this header to reject non-CloudFront traffic.

 Use Case 2: CloudFront + EC2 as Origin (No ALB)

Options:

·        If EC2 instance has a public IP, CloudFront can directly access it.

·        But it’s not recommended for scalability and fault tolerance.

·        Better to put EC2 behind an ALB or API Gateway.

 Use Case 3: CloudFront + ALB/EC2 in Private VPC (VPC-only, no public IP)

This is trickier, but possible via AWS networking integrations.

 Problem:

CloudFront is external to twtech VPC and cannot access private-only endpoints.

 Solutions:

1. Use AWS Global Accelerator + ALB (Internal):

·        Global Accelerator allows traffic from CloudFront to your internal ALB.

·        Complex and usually overkill unless you need private CloudFront origins.

2. Use CloudFront → Lambda@Edge → VPC endpoint (e.g., API Gateway Private Endpoint):

·        twtech can build a flow like:

o   CloudFront → Lambda@Edge → API Gateway private endpoint (which invokes VPC resource).

·        Allows reaching private VPC resources securely.

·        Adds latency and complexity.

3. Use AWS CloudFront Functions + S3/ALB Public Entry Point + VPC Backend

·        CloudFront serves static content and invokes ALB that routes to private EC2.

·        twtech limits public access to ALB via security group and CloudFront headers.

 Summary Table

Origin Type	VPC Access	CloudFront Support	Recommended
Public ALB	Yes	✅ Native	✅ Best practice
Private ALB	Yes	❌ Not directly	🚫 Complex setup
Public EC2	No	✅ Possible	🚫 Not scalable
Private EC2	Yes	❌ Not directly	❌ Not possible without proxy
S3	Yes (via endpoint)	✅ (OAC preferred)	✅ Recommended for static

twtech Best Practices

·        Use ALB over direct EC2 origin.

·        Keep backend EC2 instances private, behind ALB.

·        Secure your origin using custom headers or signed URLs.

·        Use CloudFront Origin Access Control (OAC) if using S3.