CloudFront with ALB or EC2 As VPC Origin | Overview.

CloudFront with ALB or EC2 As  VPC Origin - Overview.

Scope:

• Intro,
• Basics: CloudFront Origins,
• But CloudFront is a public service, so,
• Recommended setup,
• Benefits,
• Security tip,
• Use Case,
• Summary Table,
• Best Practices.

Intro:

•  twteh Uses Amazon CloudFront with ALB or EC2 as an origin, Especially with VPC-only resources,
• The architecture requires some understanding of how CloudFront handles private resources (Subnet) 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 twtech internal ALB.
•         Complex and usually overkill unless twtech needs private CloudFront origins.

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

•         twtech can build a flow like:
•    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

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.