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.
