Setting Up Yandex Cloud CDN: Delivery Bottlenecks
Setting up Yandex Cloud CDN begins not with enabling delivery, but with answering the question: what will happen to the origin when the cache stops shielding it.
While traffic is small, proxying looks like a free add-on — requests go to the nearest point of presence, and the origin server is busy only with the initial cache fill and updating stale copies.
As requests grow, this scheme breaks in several places at once, and each origin bottleneck is visible in the logs long before the user notices the delay.
The first source of problems is cache misses. It is enough for a changing parameter to be present in the static asset URL, for the origin not to distinguish between versions of a resource, or for the response to be served with a header that prohibits storage.
Each miss is a separate request to the application, and even a miss rate in the single-digit percentages turns a steady stream into a load the backend was not designed for.
The second scenario is more destructive: a request avalanche on switches. After deploying a new build or when many items expire at once, tens of thousands of copies are requested simultaneously, and all of it hits the origin in one burst.
Different retention periods by content type, serving a stale copy with background refresh, and forced warming of key URLs before traffic opens all help.
Third is connection drops and extra load on the application. If static delivery and dynamic traffic go through the same entry point, the origin spends resources establishing connections instead of processing requests, and retries after a timeout double and triple the stream.
Limiting concurrent requests to the origin and correct timeouts remove this class of failures. We will look at how this is addressed at the Yandex Cloud CDN configuration level: caching rules, miss behavior, and separating static from dynamic traffic.
What Changes After Implementation: Speed and Resilience
After switching traffic to the Yandex Cloud delivery network, visitor requests are served by the nodes closest to them, and the origin responds only to cache misses.
The hit rate is set by policies: for static content — images, styles, scripts, fonts — it reaches 85–95%, for personalized pages it stays around 50–70%.
The more precisely the cache key describes the resource variant — query parameters, language and regional versions — the higher the hit rate and the lower the risk of serving different versions of the same page.
Page response time drops by a factor: static content arrives from a node near the visitor, the secure connection is established at the edge, and the request often does not reach the origin at all.
In the report this is visible not in the average but in the 95th percentile — it is what shows that it is not an individual request that is slow, but the tail of the distribution.
The class of failures changes most of all. The origin stops being a single point: traffic peaks are absorbed at the edge instead of hitting its ceiling for connections and CPU.
If the origin is unavailable or responds slowly, the edge serves the previously cached content — the visitor sees a page instead of an error.
Availability under peak load stops depending on the moment: a sale, an announcement, a publication by a large channel — traffic grows severalfold, while response time stays in the same order.
Origin offload is measured directly: how many requests reached it versus the total number. We capture cache hits, response time, and error rate before and after the switch — the effect should be visible in numbers, not in words.
Delivery Schemes: Edge Cache, Proxy, Hybrid
The delivery scheme in Yandex Cloud CDN determines what share of requests reaches the origin and what share is served at the node closest to the user.
The choice is made not “to taste,” but according to the traffic profile: the share of static content, update frequency, privacy requirements, and acceptable time to first byte.
Three working configurations cover almost all tasks, and within one domain they are combined by path or by content type. The hybrid removes most traffic from the origin while not requiring a single response lifetime for the entire domain.
| Option | When it fits | Limitations |
|---|---|---|
| Edge cache | Images, scripts, fonts, build artifacts: updated in batches, no strict freshness requirements | Staleness until invalidation; with an incorrect cache key, some requests will receive someone else's response |
| Request proxying | Account area, payment, personal lists: the response is generated for a specific user | No cache — the entire peak goes to the origin, and latency equals the distance to it |
| Hybrid delivery scheme | Mixed site: static via the edge, dynamic directly, some paths cached by rules | Caching rules, invalidation, and headers must be coordinated with the application |
Caching rules are specified separately for each group of paths: response lifetime, cache key with or without request parameters, cache bypass for authenticated requests and cookies, and forced invalidation on release deployment.
This way static content lives at the edge for hours, while a product page does not serve someone else's price.
How Implementation Proceeds: Stages and Checkpoints
Setting up Yandex Cloud CDN is not “turning on acceleration,” but moving the point where traffic meets from the origin to the network edge.
The work proceeds sequentially: first we capture what the origin actually serves, then we build the scheme, test it in production, and only then switch users.
- Origin audit. We look at what content types the server serves, what caching headers it sets, and how it responds to errors and requests with parameters. Here we also determine what cannot be cached — otherwise delivery will start serving stale data.
- Delivery scheme. We separate domains and paths: what goes through the network, what remains on the origin, which requests bypass the cache, and by what criterion.
- Caching and certificate setup. Lifetime by content type, cache key, purge rules; edge certificate, trust chain, redirect to a secure protocol for all subdomains.
- Cache verification. Hit rate, refresh after publication, behavior when the origin is unavailable — we run test requests for each rule before switching.
- Traffic switching. We switch gradually: first part of requests or a non-priority domain, monitor error rate and response time, and keep rollback to direct delivery.
- Handover. The configuration is stored as code, and on-call scenarios are described — update content, view statistics, offload the origin during a failure.
Checkpoints are after the audit, before switching, and one day after it: they show that the scheme handles the load and does not break already working scenarios.
What You Keep: Configurations, Schemes, Regulations
We hand over all artifacts in your repository and internal documentation — not in chat and not in an engineer's personal notes. A month after launch, the on-call shift should be able to bring up delivery and explain any decision without tracking down the author. That is why the deliverables list is fixed, and every item is checked at acceptance.
- Yandex Cloud CDN resource configurations: origin groups, origins, health checks, timeouts, and load balancer binding — as declarative files with versioning in the repository.
- Caching rules: lifetimes by content type, cache keys accounting for query string parameters and headers, separate behavior for authenticated requests.
- Access policies: signing requests to the origin, hotlink protection, referrer and geo restrictions, cache bypass rules for debugging checks.
- Delivery scheme — the request route from the client through the point of presence to the origin, with caching points, failure zones, and switching logic.
- TLS documentation: certificate chain, issuance and renewal procedure, binding to domains, and emergency replacement method on expiration.
- On-call shift regulations: which metrics to watch, what counts as an incident, response thresholds, cache invalidation procedure, and configuration rollback.
Case Study: How We Offloaded the Origin Without Rewriting the Site
The delivery platform was built on Yandex Cloud, but the original caching scheme worked against the origin. The origin served both static content and API: cache rules were generic, request parameters went into the key, so identical scripts were considered different objects.
During promotional hours, the origin received almost all traffic, response time grew from a fraction of a second to several seconds, and some requests failed.
We broke content down by class and specified cache rules in the project. Versioned static content is served with a long retention period, pages and data with a short one, and personalized API responses bypass the cache.
We removed unnecessary parameters from the key, keeping those that affect content, and moved compression to the edge — the origin stopped spending effort on what already resides in the delivery network.
Return to Origin During Peak Hours
We added a reserve site for the origin and limited the request rate from the delivery network so that a miss spike would not fall in one stream. The build itself generates control headers and version tags: after a release, new content is fetched once, not on every request.
Result in Measurable Terms
The share of responses from the delivery network grew from ~55% to 93%, and peak load on the origin fell by a factor of four.
Static response time decreased by about 2.5 times, and failures during peak hours disappeared: previously there were several episodes per promotion, now there are zero.
The scheme handles a spike 3-4 times above normal without changes to the application — the site was not rewritten.
How Does the Edge Network Differ from a Load Balancer?
A load balancer works inside your environment: it accepts the connection, selects a live backend based on health checks, and distributes flows between zones.
Its area of responsibility is request distribution and application fault tolerance, but every request still reaches a server, including requests for static content.
The edge network solves a different task — delivering static content and cached responses closer to the visitor.
The point closest to the user accepts the connection, terminates TLS on its side, and serves a ready response from the cache without raising a request to the origin server. A cache hit is served at the edge, and a miss goes into the environment.
Caching versus balancing also means different efficiency metrics. For a load balancer, you look at the share of successful health checks and how evenly load is distributed; for the edge network, you look at cache hit rate and static delivery speed.
One tool does not replace the other: a load balancer does not hold content near the user, and an edge network does not monitor backend health.
In practice, they are arranged in a chain: traffic arrives at the edge network, which serves static content and cacheable responses and passes the rest to the load balancer, which distributes requests across live instances.
The key settings here are caching rules by content type, object lifetime, and correct invalidation after release. An error in them results either in stale static content for visitors or in all traffic passing through to the origin server and increasing latency.
We separate these roles at the design stage: first we assess what share of traffic is cacheable at all, then we configure rules at the edge, and only after that do we touch the balancing scheme. This way the edge removes load, and the load balancer does what it is meant for.
Common Technical Questions Before Implementation
Before starting, the same questions usually come up — they concern not functionality but how the new layer will coexist with the existing infrastructure. Below are short answers for each point; if your situation is different, we will review it separately.
We already have caching rules configured — will they have to be rewritten?
No, we inherit them. The headers the origin serves remain the base layer; on top of that we add only what is needed: a long TTL for static content, cache bypass for API and areas with authorization. For each rule we fix a priority so that a path rule does not conflict with a file type rule.
How do you change origin addressing without downtime for visitors?
The new origin is brought up alongside and checked with health probes before switching. Then we move traffic on a short TTL and keep the old one as a hot standby — reverting the record provides rollback in minutes, without reconfiguring visitors on the Yandex Cloud side.
How does a client get the current version of a page if the content has been updated?
Through invalidation: by exact URL, by file mask, or by object group. We additionally version static content in the URL — on release, links change, and the old build does not come from the cache. For compressed and mobile versions, we account for different representations of the same URL.
What should be done about certificates — issue new ones or connect your own?
Both options are possible: managed issuance with automatic renewal for the domain and subdomains, or connecting your certificate.
In this case the private key does not leave your area of responsibility, and the validity period is controlled separately so that renewal does not depend on a release.
The origin is closed to external access — can the layer still fetch from it?
Yes. We open the origin only to the layer's addresses; other requests are denied — it is impossible to reach it directly, bypassing the cache. For private objects, we issue signed links with a limited lifetime.
Let's Discuss Your Content Delivery Scheme
To make the review specific rather than general, start with context: where the content resides, who its consumers are, and what is critical for you — delivery speed, traffic cost, resilience to site failures.
Based on these inputs, our engineers will determine which cache groups make sense to create, how to configure cache-control headers on the origin, and whether a separate environment is needed for dynamic traffic.
Below is what to send so that we can return with an estimate and a work plan for delivery via Yandex Cloud CDN.
- List of domains and subdomains planned for delivery, indicating the primary and auxiliary ones.
- Origin description: a static bucket, your own web server, or multiple origins, and how traffic is distributed among them.
- Content volume and load profile: share of static and dynamic content, file types, approximate daily delivery volume, and peak spikes.
- Audience geography and TLS requirements: your own certificates or issuance on the service side, and whether forced redirect to a secure protocol is needed.
- Content update rules: how often files change, whether targeted cache purge by tags is needed, and how quickly the new version must become visible.
- Current protection and access scheme: who manages the DNS zone, what roles our engineers need, and what remains under your control.
- Constraints and preferences: acceptable response time, requirements for failover to a reserve origin, and operating mode when the origin is unavailable.
Describe the task in free form — even if some data is still unknown, this is enough to start. We will ask clarifying questions in the order of review, fix the delivery scheme, and return with an estimate and work plan: setup stages, checkpoints, and acceptance criteria.