# Your CDN is for clients, not your backend > Canonical: https://zufardhiyaulhaq.com/your-cdn-is-for-clients-not-your-backend/ > Tags: [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: ```text public (CDN): https:/// # partner-ISP path, uncontrolled public (storage): https://..aliyuncs.com/ # internet path, internet egress private (storage): https://.-internal.aliyuncs.com/ # 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](https://www.alibabacloud.com/help/en/oss/user-guide/regions-and-endpoints) and [internal endpoints and VIP ranges](https://www.alibabacloud.com/help/en/oss/user-guide/internal-endpoints-of-oss-buckets-and-vip-ranges).