Cloud Architecture · Updated November 1, 2026
Public edge, private origins: designing an ingress boundary without public backends
A public application does not require a publicly addressable backend. The durable pattern is a single inspected edge, private origin connectivity, explicit identity and a recovery path tested independently of the primary control plane.
Private-origin delivery removes direct Internet reachability from the application tier. It does not remove the need for application authentication, origin authorization, resilient routing, observability or a recovery channel.
Dated development
Cloudflare moved its public-to-private application path to general availability
On October 30, Cloudflare made application services for private origins generally available. A proxied DNS record can target a private address reached through Cloudflare One connectivity while WAF, bot controls, rate limiting, caching, transforms and Workers continue to execute at the edge.
The architectural pattern is broader than one provider. Amazon CloudFront VPC origins similarly make CloudFront the public entry point for applications on private VPC subnets. The products differ in supported origins, routing primitives and limitations, but both separate public delivery from public backend addressing.
Continue to authenticate users and workloads at the application layer. A private route narrows network exposure; it does not establish end-user identity or make edge policy infallible.
Reference architecture
Make the edge the only normal ingress path
Internet client
↓ TLS, DDoS and WAF
Public edge hostname
↓ private connector or provider-managed path
Private load balancer / service ingress
↓ workload identity and authorization
Application services and dataThe public edge terminates or forwards TLS, applies coarse network and application controls, and routes over a private path. The origin accepts traffic only from the provider-managed interface, connector or narrowly defined source boundary. Application authentication and authorization still decide what the caller may do.
Keep edge configuration and origin policy in version control. Treat DNS, routes, connector identity, security groups, certificates and application policy as one deployable change set with staged validation and rollback.
Trust boundaries
Five boundaries need separate controls
| Boundary | Required evidence |
|---|---|
| Client to edge | TLS policy, abuse controls, authenticated identity and request logs |
| Edge policy | Versioned WAF/routing rules, change approval and tested exceptions |
| Edge to private network | Connector or service identity, redundant paths, route health and encryption |
| Private ingress to workload | Origin allowlist, workload authentication and no unintended direct path |
| Workload to data | Least privilege, service identity, egress policy and audit trails |
For internal APIs, MCP servers and agent backends, tool authorization deserves special attention. Network reachability must never become permission to invoke every tool or access every tenant.
Trade-offs
Reduced exposure creates a stronger dependency on the delivery control plane
- Security: direct scanning and bypass paths shrink, but edge configuration becomes high-impact infrastructure.
- Availability: connector, tunnel, route and provider incidents can remove the only ingress path.
- Operations: origin firewalls become simpler, while end-to-end debugging spans more control planes.
- Portability: private routing primitives and policy syntax differ across providers.
- Cost: eliminating public endpoints may reduce exposure and IPv4 overhead, but edge, connector and transfer charges still require workload-level modeling.
Migration workflow
Prove the private path before removing the public one
- Inventory every public origin address, DNS record, firewall rule and health-check dependency.
- Build redundant private connectivity and verify forward and return routes from each failure domain.
- Attach a staging hostname and replay representative traffic through WAF, cache, authentication and application flows.
- Confirm the origin rejects direct requests that do not arrive through the approved path.
- Shift production traffic gradually while comparing latency, errors, cache behavior and security events.
- Remove public exposure only after rollback and emergency access procedures have been exercised.
Operations
Observe the complete request path
- Correlate edge request IDs with connector, load-balancer and application traces.
- Alert separately on edge rejection, routing failure, origin timeout and application authorization failure.
- Continuously test for accidental public origin exposure and alternate DNS paths.
- Exercise connector, route and region failover with stateful and long-running requests.
- Keep break-glass access private, strongly authenticated, time-bounded and independently audited.
- Test recovery when the edge provider or its management API is unavailable.
Operational takeaway
Private origins are an ingress architecture, not an authentication strategy.Use them to remove direct Internet exposure, then preserve explicit identity, bounded authorization, redundant routing and independently testable recovery.Readiness checklist
Before closing the public origin
- Is the edge the only routable production ingress path?
- Can the origin verify that traffic arrived through an approved provider path?
- Are end-user and workload permissions enforced independently of network location?
- Have forward and return routes been tested across connector failures?
- Can responders trace one request from edge to application and data access?
- Is there a tested break-glass path that does not silently recreate public exposure?
- Have provider limitations, data residency and transfer costs been recorded?
The strongest design makes direct origin access impossible during normal operation—and recovery possible without weakening that boundary permanently.