Перейти к основному содержанию

Yandex Cloud

Ичи12.10.2026ХостингХостингОблакоYandex CloudЯндекс152-ФЗУЗ-1ИнцидентыWorkflowsAI StudioEventRouterОколо 5 минОколо 1641 слов

Yandex Cloud

Yandex Cloud — отдельный российский облачный провайдер. В этой базе он не должен смешиваться с REG.RU или Cloud.ru: это другой кабинет, другая линейка сервисов, отдельные документы по безопасности и свои условия поддержки.

Статус заметки

Свежего личного опыта эксплуатации конкретного сервера в Yandex Cloud пока нет. Это не бюджетный VPS для простых задач, а платформа с управляемыми сервисами и документами по комплаенсу; её продуктовые возможности следует оценивать отдельно от текущей доступности.

Выборочная проверка 11 октября 2026 года: временная категория «Рискованные / спорные» для новых критичных размещений. Основание — заявленный провайдером аварийный режим и ограничения дополнительной ёмкости и поддержки. Это редакционная оценка эксплуатационного риска, а не заявление о закрытии облака, потере всех данных или недоступности каждого продукта.

До нового размещения или аварийного переноса необходимо проверить выбранную зону, услугу, квоты, доступность данных и независимый способ восстановления. История 8–11 октября и ограничения проверки находятся в журнале инцидентов; последовательность безопасных действий — в runbook восстановления. Пользовательские ресурсы при подготовке не тестировались.

Условия пересмотра оценки: подтверждённая стабилизация нужных сервисов, восстановленная возможность создавать/восстанавливать ресурсы, доступная поддержка и успешный restore-test выбранной архитектуры. Закрытие одной записи status-панели или успешный вход в Console сами по себе не возвращают категорию «Рекомендую».

Что известно

По публичным страницам Yandex Cloud предлагает полноценную облачную платформу: виртуальные машины, сети, хранилища, базы данных, Kubernetes, serverless, AI/ML и сопутствующие сервисы.

Практический вывод для этой подборки:

  • для простого сайта или небольшой виртуальной машины Yandex Cloud может быть избыточен по цене и сложности;
  • для проектов с персональными данными, managed-сервисами и требованиями к документам это один из основных российских вариантов;
  • перед запуском нужно отдельно считать цену сети, дисков, снимков, NAT, публичных IP и managed-сервисов.

Serverless Integrations: закрытие и перенос Workflows

Выборочная проверка 11 сентября 2026 года: актуальное уведомление уточняет дату перехода управления Workflows в AI Studio — 4 сентября, а не 3 сентября из ранее использованной документации. Сами Workflows сохраняются; API Gateway продолжает работать отдельно.

По опубликованному тогда плану EventRouter становится read-only 15 сентября, а Serverless Integrations прекращает работу 8 октября. Это уже не только смена интерфейса: необходимо проверить зависимые источники событий, получателей и автоматизацию. Этот раздел сохраняет сентябрьскую проверку графика, а не подтверждает повторно фактическое выполнение всех этапов в октябре.

Календарь, условия получения резервных копий и безопасный план переключения собраны в инструкции по миграции EventRouter. В частности, нельзя считать совместное чтение одной Message Queue старым и новым контуром корректным сравнительным тестом.

На дату сентябрьской проверки категория «Рекомендую» сохранялась. Прекращение сервиса учитывалось как риск жизненного цикла продукта, а не как подтверждённая авария всего облака. Текущая октябрьская оценка приведена выше. До переноса нужно проверить права команды в AI Studio, запуск Workflows и обработку событий приложением.

Cloud CDN

Yandex Cloud CDN — отдельный сервис доставки и кеширования контента. Его можно использовать как перед виртуальной машиной или балансировщиком в Yandex Cloud, так и перед внешним origin-сервером, если он доступен по HTTP или HTTPS.

Тарификация с июля 2026 года

С 1 июля 2026 года для каждого активного CDN-ресурса действует минимальный платёж 150 ₽ в месяц. В него включено 150 ГБ исходящего трафика CDN. Первые 100 млн запросов в месяц не тарифицируются отдельно; дальнейшая стоимость зависит от актуальных тарифных правил.

Для небольшого сайта это означает, что CDN больше нельзя считать полностью условно-бесплатным дополнением: даже при нескольких гигабайтах трафика нужно учитывать минимальный платёж за каждый созданный ресурс. Для крупного сайта включённый объём, наоборот, может сделать базовую стоимость предсказуемее.

Перед подключением нужно считать не только цену CDN, но и:

  • количество отдельных CDN-ресурсов;
  • трафик от CDN к пользователям;
  • трафик и запросы к origin;
  • стоимость публичного IP, балансировщика и хранилища;
  • стоимость очистки, логирования и мониторинга, если они используются в выбранной архитектуре.

География и возможности

По продуктовому дайджесту за июль 2026 года сеть Cloud CDN выросла до более чем 70 точек присутствия. Среди новых точек упоминался Амстердам, а сам сервис стал доступен клиентам региона Казахстан.

Наличие большого количества точек не гарантирует одинаковый маршрут для каждого пользователя. Перед переносом рабочего сайта полезно измерить TTFB и скорость загрузки из тех регионов, где находится реальная аудитория.

Cloud CDN поддерживает:

  • настройку TTL и правил кеширования;
  • очистку кеша и предварительную загрузку файлов;
  • управление query-параметрами в cache key;
  • передачу или исключение cookies;
  • собственный домен и HTTPS;
  • выделенную IP-адресацию для отдельных сценариев;
  • мониторинг запросов, трафика и эффективности кеша.

Особенно полезно управление query-параметрами. Например, рекламные utm_*-метки можно не учитывать в ключе кеша, чтобы одна и та же страница не сохранялась как множество разных объектов. Параметры версии вроде ?ver=42, наоборот, иногда нужно сохранить в cache key, чтобы после релиза пользователь получил новый CSS или JavaScript.

Для каких задач подходит

Cloud CDN имеет смысл рассматривать для:

  • изображений, CSS и JavaScript WordPress-сайта;
  • статических файлов Vue-приложения;
  • больших файлов и публичных загрузок;
  • сайтов с аудиторией в нескольких регионах;
  • защиты origin от всплесков запросов к кешируемому содержимому;
  • проектов, уже использующих Object Storage, Load Balancer или другие сервисы Yandex Cloud.

CDN сам по себе не ускоряет медленный PHP, тяжёлые SQL-запросы и персонализированные страницы. Если HTML нельзя безопасно кешировать, основная задержка останется на origin-сервере. Также CDN не заменяет резервное копирование и отказоустойчивость источника.

Что проверить перед использованием

  • итоговую стоимость при реальном количестве CDN-ресурсов;
  • cache hit ratio и количество обращений к origin;
  • TTFB из нужных городов и стран;
  • корректность cache key для utm_*, версий файлов и функциональных параметров;
  • поведение cookies, авторизации и персонализированных страниц;
  • скорость очистки кеша после публикации или отката;
  • работу HTTPS, редиректов, CORS и Range-запросов;
  • доступность origin только через ожидаемые маршруты;
  • влияние CDN на Core Web Vitals и нагрузку сервера.

Добавление CDN не меняет текущую категорию Yandex Cloud в каталоге: это полезное расширение облачной платформы, но свежего личного теста производительности и итоговой стоимости пока нет.

Сертификация и безопасность

По официальной странице стандартов Yandex Cloud заявляет выполнение требований 152-ФЗ и первый уровень защищенности персональных данных — УЗ-1.

На отдельной странице по 152-ФЗ указано, что платформа имеет аттестат соответствия ИСПДн требованиям безопасности информации и персональных данных, а также выполняет требования постановления правительства № 1119 и приказа ФСТЭК № 21.

Также на странице стандартов перечислены:

  • ISO/IEC 27001;
  • ISO/IEC 27017;
  • ISO/IEC 27018;
  • ISO/IEC 42001:2023;
  • PCI DSS;
  • ГОСТ Р 57580;
  • GDPR;
  • государственные реестры РФ.

Важная оговорка: часть требований законодательства остается на стороне клиента. Для реального проекта нужно проверять договор, соглашение об обработке данных, нужную услугу и актуальные документы.

Инциденты и надежность

Актуальная хронология повреждений площадок, доступности компонентов и ограничений квот за 8–11 октября приведена в журнале инцидентов. Она не подменяется прежним закрытым сетевым эпизодом.

27 мая 2026 года ошибочная конфигурация сетевого оборудования временно нарушила внешнюю связность сервисов во всех российских зонах. Внутренние ресурсы и основной data plane продолжали работать, но публичные IP и зависящие от внешней сети сервисы были недоступны. Yandex Cloud опубликовал технический разбор с причиной и мерами предотвращения.

Практический вывод: распределение между зонами одного облака не защищает от общей ошибки пограничной сети. Для критичного сервиса нужен независимый внешний мониторинг и, при необходимости, резервная площадка.

Быстрая проверка

Проверка 11 июня 2026 года из текущей сети:

  • https://yandex.cloud/ru/security/standards открылся с HTTP 200 примерно за 1,6 секунды.

Это только проверка доступности публичной страницы. Новый сервер не создавался.

Плюсы

  • сильный вариант для российских проектов с требованиями к документам и комплаенсу;
  • есть УЗ-1 и документы по 152-ФЗ;
  • много managed-сервисов в одной платформе;
  • есть публичные страницы по стандартам, сертификатам и зонам ответственности;
  • есть открытая status-панель и технические разборы значимых инцидентов;
  • хорошо подходит, если проект уже использует экосистему Яндекса.

Минусы и риски

  • на проверку 11 октября — повышенный риск доступности и восстановления критичных приложений; нужна независимая площадка и проверенный restore-план;
  • обычно дороже и сложнее бюджетных VPS;
  • стоимость нужно считать целиком, включая сеть, IP, диски, снимки и managed-сервисы;
  • нет свежего личного теста конкретного VPS/VM в этой заметке;
  • для комплаенса недостаточно просто создать виртуальную машину: нужны правильные настройки и документы на стороне клиента;
  • общая ошибка сетевого контура может затронуть сразу несколько зон;
  • изменения интерфейсов и прекращение managed-сервисов требуют миграционного плана, а не только обновления runbooks.

Что тестировать перед рекомендацией

  • итоговую стоимость минимальной VM с публичным IP, диском, снимками и трафиком;
  • поддержку и скорость реакции на технические вопросы;
  • сетевую задержку до нужной аудитории;
  • ограничения по исходящему трафику, SMTP, PTR и антиабузу;
  • применимость документов по 152-ФЗ к конкретной архитектуре проекта;
  • поведение приложения при потере внешней связности и переключение на резервную площадку;
  • доступ к Workflows и история executions через AI Studio после миграции UI;
  • сохранение поведения приложения после замены EventRouter, включая дубли, фильтры и обработку ошибок.

Итог

На проверку 11 октября 2026 года новые критичные размещения временно относятся к рискованным. Продуктовые возможности, документы по безопасности и прежние наблюдения сохранены, но не отменяют текущего эксплуатационного риска. Возврат к положительной рекомендации требует выполнения условий из раздела «Статус заметки» и проверки конкретной архитектуры, а не только публичного сообщения о доступности одного сервиса.

Перенос Workflows и закрытие EventRouter не меняют категорию автоматически, но требуют проверки приложения. Актуальные сроки и порядок подготовки — в миграционной инструкции.

Источники