Zufar Dhiyaulhaq
Writing
Sep 7, 2026 ·networking

Your CDN is for clients, not your backend

networking

A CDN is built for one job: last-mile delivery to clients at the edge. When a backend service fetches an object through that same CDN, it quietly signs up for a network path nobody controls.

Backend object access: CDN path versus the storage internal endpoint Via the CDN, a backend request crosses CDN points of presence and partner ISPs on the public internet and can reroute to another region. Via the object storage internal endpoint, it stays on the provider backbone in-region. VIA CDN · UNCONTROLLED Backend NAT Partner ISPs / BGP public internet CDN PoP far region on reroute VIA INTERNAL ENDPOINT · STABLE Backend Object storage internal endpoint provider backbone · in-region

Why a backend on the CDN path is fragile

CDN points of presence (PoPs) live on partner ISPs, spread out so they sit close to end users. Not every PoP peers directly with every cloud region. When your compute fetches an object through the CDN, the request egresses through the NAT gateway onto the public internet, crosses third-party ISPs end to end, and only then reaches a CDN PoP, often in a different autonomous system. If that PoP does not peer with the origin region, every object request crosses an inter-AS boundary on the public internet.

That path is governed by BGP between the ISPs, not by your cloud provider. On an ISP fault or a BGP change, the partner ISP can reroute the traffic to another ISP in a different region, and a request that used to terminate at a local PoP now terminates hundreds of kilometers away. Latency stops being a property of your infrastructure and becomes a property of someone else’s routing table. You also pay internet egress for the privilege.

The fix: reach object storage directly, over the internal endpoint

Object storage usually exposes the same object at three different addresses:

public  (CDN):     https://<cdn-domain>/<object>                         # partner-ISP path, uncontrolled
public  (storage): https://<bucket>.<region>.aliyuncs.com/<object>       # internet path, internet egress
private (storage): https://<bucket>.<region>-internal.aliyuncs.com/<object>  # provider backbone, in-region

For server-to-server access, use the internal endpoint. Same object, provider backbone, in-region, no internet egress.

Property Backend to CDN PoP (public) Backend to storage internal endpoint (private)
Network public internet provider backbone
Path control partner ISP / BGP, not yours provider, in-region
Peering guarantee none for every PoP yes
Reroute on ISP or BGP fault yes, to another ISP or region no
Latency under fault non-deterministic stable, intra-region
Internet egress cost billed none
Designed for client, last-mile delivery server-to-server object access

The example above uses Alibaba Cloud OSS, but every cloud has the same split: on AWS, reach S3 through a VPC gateway or interface endpoint instead of its CloudFront domain; on GCP, use private access to Cloud Storage. The names differ, the rule does not.

Rule of thumb

A browser or mobile app resolving to the nearest PoP is exactly what a CDN is for: if that PoP reroutes, the client is already on the public internet and a few hundred milliseconds of jitter is invisible next to the rest of its request. A backend that depends on that PoP’s ISP peering is not fine. Send client traffic through the CDN, and send backend object access straight to object storage over the internal endpoint.

Further reading: Alibaba Cloud OSS, regions and endpoints and internal endpoints and VIP ranges.