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

Yandex Cloud

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

Yandex Cloud

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

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

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

Что известно

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

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

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

Workflows: управление переезжает в AI Studio 3 сентября

В документации Yandex Workflows, обновлённой 18 августа 2026 года, опубликован близкий дедлайн: с 3 сентября 2026 года создавать и управлять workflows через обычный интерфейс Yandex Cloud больше нельзя. Для этих операций нужно использовать интерфейс Yandex AI Studio.

До дедлайна действуют два интерфейса, но между ними есть асимметрия:

  • workflow, созданный через Yandex Cloud UI, автоматически доступен в AI Studio UI;
  • workflow, созданный через AI Studio UI, не отображается в старом Yandex Cloud UI.

Это важно для команды, которая одновременно использует обе консоли: отсутствие нового workflow в старом интерфейсе не означает, что ресурс не был создан.

Что именно меняется

Объявление относится к пользовательскому интерфейсу создания и управления. В актуальной документации по-прежнему описаны CLI и API для просмотра, запуска и управления workflows.

Поэтому некорректно писать:

Yandex Workflows закрывается 3 сентября

Корректнее:

управление Workflows переезжает из обычного Yandex Cloud UI в AI Studio UI

Сами workflows, их executions, сервисные аккаунты, сети и API не объявлены прекращающими работу.

Что проверить до 3 сентября

  1. Открываются ли существующие workflows в AI Studio.
  2. Есть ли у операторов доступ к нужному каталогу и интерфейсу AI Studio.
  3. Сохранились ли роли serverless.workflows.* и доступ к service account.
  4. Видны ли история executions, логи и настройки сети.
  5. Можно ли создать тестовый workflow через новый UI и запустить его.
  6. Обновлены ли внутренние инструкции и скриншоты старой консоли.
  7. Не используют ли сотрудники старый UI как единственный способ поиска ресурсов.
  8. Сохранена ли спецификация workflow в YaWL или другом воспроизводимом виде.
  9. Работают ли автоматизация через CLI/API и CI/CD после смены UI.
  10. Есть ли rollback-план для изменений workflow, сделанных через новый интерфейс.

Особенно полезно заранее открыть все production-workflows в AI Studio и проверить не только список ресурсов, но и редактирование, роли, service account, private network, retry policy и logging.

Влияние на оценку провайдера

Это миграция интерфейса, а не авария и не ухудшение SLA. Категория Yandex Cloud остаётся «Рекомендую».

Практический риск возникает у клиента, если команда пропустит дедлайн и продолжит искать управление Workflows только в старой консоли. Изменение стоит внести в operational calendar и внутренние runbooks.

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;
  • государственные реестры РФ.

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

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

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

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

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

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

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

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

Плюсы

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

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

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

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

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

Итог

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

Переезд управления Workflows в AI Studio не меняет оценку провайдера, но требует действий до 3 сентября 2026 года: проверить доступ к новому UI и обновить внутренние инструкции.

Источники