Pattern · Draft
Private Origin
Serve a private backend through CloudFront without exposing it to the internet.
Architecture
Viewers reach CloudFront over HTTPS. A VPC origin connects it to an internal ALB, NLB, or EC2 instance in private subnets. The backend security group admits CloudFront; the backend has no public address.
Draft: this pattern is captured but not yet reviewed. The forces, trade-offs and failure modes below are a working position, not a finished one.
The problem
A backend that must not be publicly reachable still has to serve internet users. Giving it a public load balancer widens the attack surface, exposes it to direct scanning, and pushes network controls out to the edge of the VPC.
The solution
Connect CloudFront to the private resource with a CloudFront VPC origin, pointing at an internal ALB, NLB, or EC2 instance. CloudFront reaches into the VPC, and the backend stays in private subnets with no public address.
Forces
What pulls against what.
- Attack surface against reachability
- Network control against delivery convenience
- A regional origin against a global edge
On AWS
- CloudFront
- VPC origins
- Network Load Balancer
- Application Load Balancer
- EC2
- Security groups
Trade-offs
- Nothing public to defend, and origin access follows the network rather than a shared secret
- The VPC origin is newer and regional, so availability and supported origin types are a constraint
- The target security group must admit CloudFront, which couples ingress configuration to the backend
When not to use it
- The backend is already a managed public endpoint with its own access control, such as AppSync, API Gateway, or S3
- The origin already sits behind a CDN or gateway you do not control
Failure modes
How it breaks when it breaks.
- The security group does not admit CloudFront, so every request times out
- A VPC origin created in an unsupported region or against an unsupported target type
- The backend is assumed private while a public path to it still exists