Yandex Cloud CDN в 2026 году
Yandex Cloud CDN в 2026 году: стоимость и практическая настройка
В 2026 году Yandex Cloud заметно обновил Cloud CDN: расширил сеть точек присутствия, открыл сервис в регионе Казахстан, изменил тарификацию и добавил более точное управление query-параметрами в ключе кеша.
Материал актуален на 20 августа 2026 года.
Короткий вывод
- С 1 июля 2026 года минимальный платёж составляет 150 рублей в месяц за каждый CDN-ресурс.
- В платёж включено 150 ГБ исходящего трафика для этого ресурса.
- После 150 ГБ трафик оплачивается по стандартному тарифу.
- Запросы начинают тарифицироваться после бесплатного порога 100 000 000 запросов в месяц.
- Сеть Cloud CDN включает более 70 точек присутствия; среди новых локаций указан Амстердам.
- Сервис доступен в выделенном регионе Казахстан.
- Query-параметры можно учитывать все, исключать выбранные или, наоборот, учитывать только выбранные.
- Для небольшого сайта CDN стоит сначала подключать к статическим файлам. Кеширование HTML и API требует отдельной проверки cookies, авторизации и cache key.
Что изменилось
По продуктовому дайджесту Yandex Cloud от 5 августа 2026 года:
- число точек присутствия Cloud CDN превысило 70;
- среди новых локаций появился Амстердам;
- сервис стал доступен для компаний с инфраструктурой в выделенном регионе Казахстан;
- для каждого CDN-ресурса появился включённый пакет 150 ГБ;
- минимальный ежемесячный платёж установлен на уровне 150 рублей за ресурс;
- в консоли расширена настройка query-параметров, входящих в cache key.
История изменений Cloud CDN также фиксирует новую модель тарификации, ресурсную оплату выделенной IP-адресации и изменение списка HTTP-методов, заблокированных по умолчанию.
Новая модель тарификации
С 1 июля 2026 года стоимость Cloud CDN складывается из нескольких частей.
CDN-ресурсы
За каждый созданный CDN-ресурс взимается минимальный ежемесячный платёж 150 рублей. В него включено 150 ГБ исходящего трафика этого ресурса.
При удалении ресурса неиспользованный включённый трафик обнуляется. Перенести его на другой ресурс нельзя.
Исходящий трафик
Трафик с CDN-серверов пользователям сверх включённых 150 ГБ оплачивается отдельно.
Входящий трафик, поступающий на CDN-серверы из интернета или сервисов Yandex Cloud, в рамках тарифа CDN не оплачивается. Это не отменяет возможных расходов origin:
- внешний хостинг может тарифицировать отдачу данных в CDN;
- промахи кеша увеличивают сетевую и вычислительную нагрузку источника;
- очистка кеша и публикация новых файлов временно повышают число запросов к origin;
- отдельные сервисы Yandex Cloud могут иметь собственную тарификацию сети и операций.
Количество запросов
Для каждого месяца действует бесплатный порог 100 000 000 запросов к CDN-ресурсам. Запросы сверх порога тарифицируются блоками, указанными в актуальном прайс-листе.
Для обычного сайта ограничивающим фактором чаще будет трафик или число ресурсов, а не количество запросов. Для небольших файлов, API, игровых обновлений и телеметрии ситуация может быть обратной.
Платные функции
Отдельно оплачиваются:
- экранирование источников;
- экспорт логов;
- выделенная IP-адресация.
Перед включением функции нужно проверить не только месячную цену, но и момент списания. Документация указывает, что некоторые опции оплачиваются за полный месяц в день подключения.
Примеры минимальной стоимости
Без превышения включённого трафика и без дополнительных функций:
| Конфигурация | Минимальный платёж | Включённый трафик |
|---|---|---|
| 1 CDN-ресурс | 150 ₽/месяц | 150 ГБ |
| 3 CDN-ресурса | 450 ₽/месяц | по 150 ГБ на ресурс |
| 5 CDN-ресурсов | 750 ₽/месяц | по 150 ГБ на ресурс |
| 10 CDN-ресурсов | 1 500 ₽/месяц | по 150 ГБ на ресурс |
Включённые пакеты нельзя складывать. Если один ресурс передал 300 ГБ, а девять других не использовались, свободный объём остальных не компенсирует превышение первого.
Когда создавать отдельный CDN-ресурс
Отдельный ресурс оправдан, когда нужны различающиеся:
- домены и сертификаты;
- origin-группы;
- настройки кеширования;
- политики доступа;
- локационные правила;
- экспорт логов;
- выделенная IP-адресация;
- ответственные команды или проекты.
Не стоит создавать отдельный ресурс для каждого поддомена только «для порядка». При новой тарификации это прямо увеличивает минимальный ежемесячный платёж.
Query-параметры и cache key
Query-параметры, которые учитываются при кешировании, входят в ключ объекта. Разные значения таких параметров создают разные объекты в кеше.
Доступны режимы:
| Режим | Поведение |
|---|---|
| Не кешировать параметры | Все query-параметры игнорируются, один путь соответствует одному объекту |
| Кешировать всё | Все параметры и их значения входят в cache key |
| Кешировать всё, кроме | Указанные параметры игнорируются, остальные учитываются |
| Кешировать только | Учитываются только перечисленные параметры |
Почему это важно
Слишком широкий cache key дробит кеш:
/article/?utm_source=telegram
/article/?utm_source=email
/article/?gclid=123
Если тело страницы одинаково, три URL создают лишние копии и уменьшают cache hit.
Слишком узкий cache key может смешать разные ответы:
/catalog/?page=1
/catalog/?page=2
Если параметр page игнорируется, CDN рискует отдавать содержимое первой страницы вместо второй.
Практические правила для параметров
Обычно можно исключить
Только после проверки, что они не меняют содержимое:
utm_source;utm_medium;utm_campaign;utm_content;utm_term;gclid;yclid;- идентификаторы рекламных переходов и аналитики.
Обычно нужно учитывать
Если параметр действительно меняет ответ:
page;sort;filter;lang;currency;widthиheightдля сервиса изображений;- идентификатор версии файла;
- вариант продукта;
- параметры API;
- сегмент видео или плейлиста.
Требуют отдельной проверки
- подписанные URL;
- secure tokens;
- временные ссылки;
- параметры авторизации;
- preview;
- персонализация;
- A/B-тесты;
- параметры, влияющие на права доступа.
Игнорирование защитного параметра способно превратить закрытый файл в общий кеш-объект. Такие сценарии нужно проверять на тестовом ресурсе до запуска.
Cookies и персонализированный контент
Кеширование ответов на запросы с Cookie настраивается отдельно. Если игнорирование cookies выключено, ответы на такие запросы не кешируются и CDN обращается к источнику.
Включать кеширование при наличии cookies стоит только тогда, когда cookie гарантированно не меняет содержимое и права доступа.
Нельзя без отдельной схемы кешировать:
- личный кабинет;
- корзину и оформление заказа;
- административную панель;
- preview;
- ответы авторизованного API;
- персональные цены;
- данные пользователя;
- страницы с CSRF/nonce-токенами;
- результаты внутреннего поиска, зависящие от сессии.
Cache hit не гарантируется
Yandex Cloud прямо предупреждает, что сервис не гарантирует заданную долю попаданий в кеш.
CDN обращается к origin, когда:
- объект ещё не закеширован в отвечающей точке присутствия;
- истёк TTL;
- кеш очищен;
- публикуется новая версия;
- правила требуют запросить источник;
- ответ зависит от cookie или другого исключения;
- объект был удалён из-за отсутствия запросов.
Если контент не запрашивался 36 часов, он удаляется из кеша независимо от установленного TTL.
Для редкопосещаемого сайта CDN может почти не уменьшить нагрузку на origin. Для популярного статического файла эффект будет заметнее.
TTL и заголовки origin
В режиме «Как у источника» origin должен отдавать корректный Cache-Control, например:
Cache-Control: public, max-age=86400
Для файлов с уникальным именем или хешем можно использовать длительный срок:
Cache-Control: public, max-age=31536000, immutable
Для HTML обычно выбирают более короткий TTL или полностью отключают кеширование до настройки исключений.
Проверьте также:
ETag;Last-Modified;Vary;Content-Type;Content-Encoding;- редиректы;
- коды ошибок.
Очистка кеша
Полная очистка заставляет CDN повторно обращаться к origin за всеми объектами и может создать всплеск нагрузки.
Предпочтительна выборочная очистка:
/static/app.css
/images/logo*
/releases/*
Символ * поддерживается только в конце пути.
Если используются query-параметры, по умолчанию очистка пути удаляет все его варианты. Для удаления конкретной копии нужно указать параметры, входящие в cache key.
При Vary, например Vary: Accept-Encoding, документация рекомендует добавлять * к пути, чтобы убрать все версии объекта.
Принудительное заполнение кеша
Cloud CDN позволяет заранее загрузить файл в кеш. Yandex рекомендует использовать prefetch прежде всего для крупных файлов от 200 МБ.
Prefetch подходит для:
- игровых обновлений;
- дистрибутивов;
- крупных архивов;
- видео;
- файлов, на которые ожидается резкий спрос после публикации.
Обновить уже закешированный объект через prefetch нельзя: сначала требуется очистка кеша.
HTTP-методы
В истории изменений за II квартал 2026 года указано, что клиентские запросы с методами POST, PUT, PATCH и DELETE блокируются по умолчанию. Для нужных сценариев методы подключаются отдельно.
Это важно для:
- API;
- загрузки файлов;
- WebDAV;
- форм, отправляемых через CDN-домен;
- приложений с изменяющими запросами.
Обычному статическому CDN обычно достаточно GET и HEAD.
Перед проксированием API проверьте:
- разрешённые методы;
Authorization;- cookies;
- CORS и
OPTIONS; - кеширование ответов;
- логи и персональные данные;
- защиту origin от прямого обхода CDN.
Выделенная IP-адресация
По умолчанию CDN-ресурсы разных клиентов могут использовать один публичный IP. Выделенная адресация подключается через поддержку и оплачивается отдельно.
Выделенный IP привязывается к каталогу. Если выбрана оплата за отдельные CDN-ресурсы, плата взимается за все ресурсы каталога. Ресурсы, которым выделенный IP не нужен, лучше держать в другом каталоге.
Возможные сценарии:
- включение адреса в белый список;
- изоляция от соседей общего IP;
- доступ к origin через группы безопасности;
- требования сетевой архитектуры.
Выделенный IP не заменяет TLS, WAF, контроль доступа к origin и мониторинг.
Настройка для WordPress
Безопасный первый этап
- Оставить HTML на основном домене без CDN-кеширования.
- Подключить CDN к
/wp-content/uploads/. - Перенести через CDN CSS, JavaScript и шрифты.
- Сохранять в cache key параметр версии, если имя файла не меняется.
- Исключить только подтверждённые рекламные параметры.
- Настроить CORS для шрифтов.
- Проверить WebP, AVIF и
Vary. - Настроить выборочную очистку после публикации.
- Сравнить скорость, трафик, cache hit и стоимость.
Что исключить
Не кешируйте без специальной настройки:
/wp-admin/
/wp-login.php
/wp-json/ с авторизацией
/cart/
/checkout/
/my-account/
?preview=true
Точный список зависит от плагинов, темы и структуры сайта.
Версии файлов
WordPress часто добавляет параметр ver:
/wp-content/themes/example/style.css?ver=7.1
Если имя файла постоянно, ver должен входить в cache key, иначе после обновления CDN может продолжить отдавать старую версию.
Альтернативный подход — имена с хешем:
style.a4e9c31.css
В этом случае файл можно кешировать надолго, а новая сборка получает новый URL.
Настройка для Laravel и других приложений
Хорошие кандидаты для CDN:
- Vite-ассеты с хешами;
- публичные изображения;
- файлы загрузок без персональных прав;
- документация;
- дистрибутивы;
- публичное видео.
Не следует кешировать единым правилом:
/admin;/login;/api;- подписанные маршруты;
- ответы с сессией;
- пользовательские файлы с проверкой доступа;
- CSRF-токены;
- Livewire/Inertia-запросы, пока их поведение не проверено.
Чек-лист перед подключением
- [ ] Определить аудиторию и регионы.
- [ ] Посчитать количество CDN-ресурсов.
- [ ] Рассчитать минимальный платёж.
- [ ] Проверить цену трафика сверх 150 ГБ.
- [ ] Проверить тариф исходящего трафика origin.
- [ ] Разделить статический и динамический контент.
- [ ] Выписать параметры, которые меняют ответ.
- [ ] Выписать рекламные и служебные параметры.
- [ ] Проверить cookies и авторизацию.
- [ ] Настроить TTL.
- [ ] Подготовить выборочную очистку.
- [ ] Подготовить откат DNS.
- [ ] Проверить, нужен ли выделенный IP.
- [ ] Проверить методы API.
Чек-лист после подключения
- [ ] Проверить сертификат и TLS.
- [ ] Проверить DNS из нескольких сетей.
- [ ] Сравнить тело ответа origin и CDN.
- [ ] Проверить HTTP-коды и редиректы.
- [ ] Проверить
Cache-Control,Age,ETag,Last-ModifiedиVary. - [ ] Проверить cache key на значимых параметрах.
- [ ] Проверить игнорирование рекламных параметров.
- [ ] Убедиться, что авторизованный контент не попадает в общий кеш.
- [ ] Проверить формы и API.
- [ ] Проверить частичную очистку.
- [ ] Измерить cache hit.
- [ ] Измерить нагрузку и трафик origin.
- [ ] Проверить стоимость через несколько дней.
Команды для проверки
Заголовки обычного файла:
curl -I https://cdn.example.com/static/app.css
Повторный запрос:
curl -I https://cdn.example.com/static/app.css
Параметр версии:
curl -I 'https://cdn.example.com/static/app.css?ver=42'
Рекламные параметры:
curl -I 'https://cdn.example.com/article/?utm_source=telegram'
curl -I 'https://cdn.example.com/article/?utm_source=email'
Сравнивайте не только заголовок Age, но и тело, размер, HTTP-код и данные мониторинга Cloud CDN.
Что измерять
Минимальный набор:
- cache hit ratio;
- количество запросов;
- исходящий трафик CDN;
- трафик origin;
- запросы к origin;
- TTFB из нужных регионов;
- ошибки 4xx/5xx;
- время очистки кеша;
- стоимость CDN;
- стоимость источника до и после подключения.
CDN стоит сохранять, если он улучшает пользовательские показатели, снижает риск перегрузки или упрощает распространение контента при приемлемой итоговой цене.