Краткий обзор
- Yandex Cloud LLC — это не просто российская альтернатива глобальным гиперскейл-облакам. Её коммерческая роль состоит в том, чтобы превратить ограниченные вычислительные ресурсы, хранилища, управляемые базы данных, работу по соблюдению требований, локальное покрытие сети и возможности поддержки в такой внутренний счёт за услуги, который банки, ритейлеры, поставщики программного обеспечения и онлайн-бизнесы могут считать операционно нормальным.
- Инвестиционный вопрос заключается в том, создают ли российские правила локализации данных, ограничения на иностранные сервисы, сложности с импортом оборудования и работы по миграции предприятий устойчивую локальную надбавку для Yandex Cloud или же клиенты просто заперты на более дорогом замещающем рынке, экономика которого ослабнет, если улучшится доступ к оборудованию или трансграничным облакам.
Привычная виртуальная машина стала покупкой суверенитета
Покупатель начинает не с геополитики. Российский онлайн-ритейлер начинает с календаря промоакций, сервиса оформления заказа и ежемесячного счёта за виртуальную машину, управляемый кластер PostgreSQL и корзину объектного хранилища. Более дешёвая замена хорошо знакома: оставить рабочую нагрузку на собственной стойке, запустить старый стек виртуализации, растянуть ресурсы импортных серверов, купленных до шока поставок, и попросить небольшую команду системных администраторов «выхаживать» оборудование ещё один сезон. Такая замена ещё может подойти для среды разработки.
Но она может отказать именно в той задаче, за которую платит покупатель, — поддерживать доступность платежей, запасов и данных клиентов во время пиковой распродажи, банковской сверки или инцидента в поддержке.
Именно так открывается окно возможностей для Yandex Cloud LLC. Покупаемая единица выглядит технической и небольшой, но счёт включает скрытые постоянные издержки, которые внутри России больше не являются невидимыми: закупку оборудования, замену программного обеспечения, соблюдение санкционных требований, валютные риски, гарантии локализации данных, местную сертификацию безопасности и дефицитный инженерный труд. Yandex представляет сервис как полноценную облачную платформу для инфраструктуры, хранения данных, машинного обучения и инструментов разработки, с собственными дата-центрами и заявлениями о соответствии требованиям на англоязычной домашней страницеhttps://yandex.cloud/en. На русскоязычной корпоративной странице говорится, что платформа обслуживает крупные компании, средний бизнес и разработчиков в облаке, на собственной инфраструктуре и в гибридных сценариях, и указывается российское юридическое лицо LLC «Yandex.Cloud», ОГРН 1187746678580, зарегистрированное 13 июля 2018 года на улице Льва Толстого в Москве (https://yandex.cloud/ru/about). Карточка реквизитов компании повторяет те же данные и указывает генеральным директором Grigory Atrepev (https://storage.yandexcloud.net/doc-files/Yandex.Cloud_requisites.pdf).
Коммерческий вопрос не в том, есть ли у Yandex Cloud каталог услуг. Он есть. Вопрос в том, насколько устойчива надбавка за суверенитет. Если внутренний спрос, доступ к оборудованию и давление регуляторов усиливают друг друга, Yandex Cloud может получать локальную премию, потому что клиенты покупают операционную непрерывность в условиях ограничений. Если же эти ограничения главным образом запирают покупателей внутри меньшего и более дорогого набора заменителей, премия выглядит не как ценовая сила, а как налог на ограниченный выбор.
Счёт скрывает больше, чем процессор и хранилище
Собственная страница цен Yandex Cloud рекламирует начальные цены на виртуальные машины и кластеры обычным облачным языком, включая низкие стартовые ежемесячные цены и возможности бесплатного тарифа (https://yandex.cloud/en/prices). Такая подача важна, потому что покупатели облаков любят сравнивать один класс инстансов с другим. Но в России сравнение остаётся неполным, пока покупатель не добавит постоянные издержки на то, чтобы приложение стало приемлемым для местных регуляторов, платёжных партнёров, служб безопасности и закупочных отделов. Дешёвая иностранная виртуальная машина не является дешёвой, если российское юридическое лицо не может открыть новый аккаунт, если ломается маршрут биллинга, если поддержка недоступна или если ответ о локализации данных непригоден для собственного комплаенс-файла покупателя.
Yandex Cloud открыто говорила о движении цен. В обновлении 2026 года компания сообщила, что большинство затронутых сервисов Yandex Cloud подорожают с 1 мая 2026 года на 5–8 %, тогда как некоторые цены на ИИ и информационную безопасность не изменятся (https://yandex.cloud/en/blog/pricing-update-2026). Это полезный сигнал. На полностью открытом глобальном облачном рынке провайдеру, повышающему цены на широкий набор услуг, пришлось бы защищать такое решение перед глубоким пулом заменителей. В России реалистичные альтернативы покупателя могут быть уже: собственный хостинг, внутренний конкурент, управляемая частная инсталляция или унаследованный доступ к иностранным сервисам, который может быть недоступен для новых задач. Поэтому счёт оценивает и потребление ресурсов, и способность провайдера продолжать снабжение, эксплуатацию и сертификацию локального стека.
Именно поэтому запас прочности нельзя считывать только из тарифов на вычисления. Стек издержек включает электропитание, охлаждение, оптический транспорт, запасные части, системное программное обеспечение, экспертизу по базам данных, разработку облачной консоли, управление идентификацией и доступом, мониторинг, операции безопасности и локальную поддержку. Процесс сервисного соглашения Yandex Cloud также делает коммерческие отношения формальными: в биллинговой документации говорится, что каждый сервис действует по соглашению, которое заключается через оферту при создании платёжного аккаунта или через подписанное напрямую соглашение (https://yandex.cloud/en/docs/billing/concepts/contract). Для поставщика банка или ритейлера эта юридическая и операционная обвязка — часть продукта.
Скрытые постоянные издержки объясняют и то, почему собственный хостинг остаётся одновременно конкурентом и предупреждением. Клиент может купить серверы, использовать местный колокейшн и запустить стек с открытым исходным кодом. Но тогда ему придётся самостоятельно отвечать за установку обновлений, планирование мощностей, обновление оборудования, резервное копирование, мониторинг, доказательства для регуляторов и аварийный ремонт. Привлекательность Yandex Cloud в том, что она распределяет эти издержки между клиентами.
Риск в том, что санкции и дефицит оборудования повышают собственные постоянные издержки провайдера быстрее, чем он может их распределить.
Юридическая идентичность российская, даже когда бренд выглядит глобальным
Международные страницы Yandex Cloud могут создавать впечатление обычного глобального облачного бренда. Юридический и владельческий контекст более конкретен. Русскоязычная корпоративная страница называет российскую компанию LLC «Yandex.Cloud», с ОГРН 1187746678580, ИНН 7704458262 и разработкой программного обеспечения в качестве основного вида деятельности (https://yandex.cloud/ru/about). В PDF с реквизитами Yandex приводится английская версия, «LIMITED LIABILITY COMPANY YANDEX.CLOUD», и повторяются московский адрес и дата регистрации в июле 2018 года (https://storage.yandexcloud.net/doc-files/Yandex.Cloud_requisites.pdf). Более ранние юридические условия Yandex также описывали Yandex.Cloud LLC как российское аффилированное лицо, эксплуатирующее технические ресурсы Yandex.Cloud (https://yandex.com/legal/cloud_termsofuse/en/).
Структура собственности существенно изменилась в 2024 году. Yandex N.V. объявила об обязывающем соглашении о продаже своего бизнеса в России и сообщила, что приобретатель получит все активы и операции Yandex в России и на отдельных международных рынках, а продавец после завершения сделки не будет иметь доли в российском бизнесе (https://yandex.com/company/news/05-02-2024). Nebius, переименованная бывшая материнская компания, позже сообщила о втором и окончательном закрытии сделки и о том, что YNV полностью распорядилась оставшейся долей в российском бизнесе (https://nebius.com/newsroom/ynv-announces-successful-completion-of-the-divestment-of-its-russia-based-businesses). Для клиентов Yandex Cloud результатом стал более локально закреплённый провайдер, а не простое продолжение нидерландской материнской компании с российскими операциями.
Такая закреплённость имеет две стороны. Она может успокоить российских клиентов, чьи советы директоров хотят иметь внутреннего контрагента, локальный биллинг и платформу, построенную вокруг российского регулирования. Она также может сузить доступный провайдеру внешний капитал, поставки оборудования и партнёрскую вселенную. Покупатель Yandex Cloud выбирает не просто «Yandex» вместо AWS, Azure или Google Cloud. Он выбирает облако внутри российской корпоративной, юридической и платёжной среды со всеми вытекающими устойчивостью и ограничениями.
Поэтому договорные условия покупателя находятся на том же уровне анализа, что и технический каталог услуг. Если клиент — поставщик банка, ему нужно больше, чем база данных с низкой задержкой. Ему нужен контрагент, который может подписать локальные документы, пройти закупочные проверки, оказывать поддержку на русском языке, показывать документы о соответствии требованиям и поддерживать работу сервисов, когда трансграничные поставщики меняют политику. Юридическая идентичность Yandex Cloud помогает решать эту задачу.
Нерешённый вопрос в том, достаточно ли локальной идентичности для защиты экономики, когда замена оборудования и программного обеспечения становится дороже.
Каталог продуктов пытается заменить весь иностранный стек
Yandex Cloud ценна только в том случае, если может заменить достаточно большой фрагмент привычки к иностранным облакам, чтобы корпоративные рабочие нагрузки продолжали работать. Её страница услуг перечисляет вычисления, объектное хранилище, управляемый Kubernetes, выделенные серверы, CDN, резервное копирование, сети, базы данных, обработку данных, сервисы безопасности, инструменты разработчика и бессерверные сервисы (https://yandex.cloud/en/services). Страница сравнения платформ сопоставляет знакомые категории Google Cloud с сервисами Yandex, включая вычисления, объектное хранилище, управляемый PostgreSQL, управляемый Kubernetes, облачные функции, сетевые соединения, управление ключами, логирование и аналитику данных (https://yandex.cloud/en/docs/overview/platform-comparison/gcp). Такое сопоставление не доказывает паритет, но показывает коммерческую амбицию: сделать план миграции российского покупателя понятным для команд, обученных на глобальных облачных паттернах.
Основная работа по замене начинается с вычислений и хранения. Yandex Compute Cloud — это сервис виртуальных машин и блочного хранения в каталоге (https://yandex.cloud/en/services/compute), тогда как Yandex Object Storage представляет себя как S3-совместимое хранилище для масштабируемого хранения данных общего назначения с репликацией между зонами доступности и заявленным уровнем обслуживания 99,98 % на продуктовой странице хранилища (https://yandex.cloud/en/services/storage). Управляемые базы данных — вторая опора. Yandex продвигает управляемый PostgreSQL как сервис, где клиенты выбирают класс хоста, размер хранилища, сеть и зону доступности, а не управляют кластером базы данных самостоятельно (https://yandex.cloud/en/services/managed-postgresql). Компания также предлагает управляемые ClickHouse, MySQL, YDB, OpenSearch, Valkey, Kafka, Spark и другие сервисы данных в разделе платформы данных (https://yandex.cloud/en/services).
Третья опора — операционные инструменты. Managed Kubernetes позволяет командам сохранить контейнерную модель эксплуатации и при этом перенести часть ответственности за управляющий слой, а на странице сервиса сказано, что узлы могут включать серверы Yandex BareMetal или серверы за пределами Yandex Cloud (https://yandex.cloud/en/services/managed-kubernetes). Yandex BareMetal позиционируется как выделенные физические серверы, все ресурсы которых закреплены за клиентом; это полезно, когда изоляция, лицензирование, производительность или комплаенс делают обычную виртуальную машину менее привлекательной (https://yandex.cloud/en/services/baremetal). Cloud Interconnect предоставляет выделенные частные соединения между инфраструктурой клиента и Yandex Cloud (https://yandex.cloud/en/services/interconnect).
Каталог раскрывает стратегию. Yandex Cloud не продаёт один внутренний хостинговый продукт. Она продаёт язык миграции для компаний, которые знают, как должно ощущаться современное облако, но нуждаются в локальной замене. Слабость в том, что каждый добавленный сервис создаёт ещё одну поверхность обслуживания. Широкий каталог может углубить зависимость клиентов и поднять средний доход. Но он также может возложить на провайдера больше обязательств по обновлениям, совместимости, безопасности и мощностям в период, когда запасное оборудование и поддержка вендоров становятся труднее доступными.
Зоны доступности превращают локальность в проектное ограничение
Локализацию данных часто обсуждают как правовое правило, но покупатели облаков ощущают её как архитектуру. В документации Yandex Cloud говорится, что платформа размещена в четырёх дата-центрах Yandex, и перечисляются российские зоны доступности, включая ru-central1-a, ru-central1-b, ru-central1-d, ru-central1-e и отдельную зону ru-central1-m для Yandex BareMetal (https://yandex.cloud/en/docs/overview/concepts/geo-scope). В документации по регионам сказано, что регион объединяет зоны доступности и что консоль управления показывает сервисы и ресурсы для выбранного региона (https://yandex.cloud/en/docs/overview/concepts/region). Обзор сети напрямую связывает дата-центры с зонами доступности и описывает виртуальную сеть вокруг этих локаций (https://yandex.cloud/en/docs/overview/concepts/network).
Для ритейлера из вводного примера региональная схема — это не картографическое упражнение. Она определяет, где живут платёжный сервис, объектное хранилище, задачи аналитики и резервные копии. Она определяет, практична ли многозонная схема базы данных. Она влияет на то, какую задержку видят российские пользователи, какая схема аварийного восстановления возможна без выхода за пределы страны и сможет ли банковский или государственный заказчик принять такую архитектуру.
Yandex также вышла за пределы России, открыв в 2024 году присутствие дата-центра в Казахстане, в Караганде, с офисами в Алматы и Астане, и заявила, что пользователи в Казахстане, России и Центральной Азии могут запускать там цифровые продукты (https://yandex.cloud/en/blog/posts/2024/04/yandex-cloud-in-kazakhstan). На русскоязычной корпоративной странице теперь сказано, что в 2024 году платформа разместила серверную инфраструктуру в Казахстане и что Yandex Cloud используют сотни казахстанских компаний и организаций государственного сектора (https://yandex.cloud/ru/about). Это важно, потому что продукт больше не является только московской облачной историей; это также евразийская история локальности. Тем не менее компания и сетевые свидетельства закреплены в России, и основная надбавка за суверенитет — российская.
Локальность также создаёт операционное трение. В документации Yandex Cloud о квотах и лимитах сказано, что квоты — это организационные ограничения, которые можно изменить через поддержку, а лимиты — технические ограничения архитектуры, которые изменить нельзя; там же предупреждается, что квоты не гарантируют доступность ресурсов (https://yandex.cloud/en/docs/overview/concepts/quotas-limits). Это предупреждение звучит как обычный облачный язык, но на рынке с ограниченным оборудованием оно приобретает больший вес. Клиент может иметь квоту и всё равно столкнуться с практическими сроками предоставления мощностей. Провайдер может иметь спрос и всё равно нуждаться во времени, оборудовании и электроэнергии для добавления предложения.
Это первое коммерческое суждение: локальность Yandex Cloud даёт ей защищённый пул спроса, но она же концентрирует физические и регуляторные риски. Покупатель платит за близость, комплаенс и операционную уверенность. Провайдер должен постоянно доказывать, что эти качества стоят больше, чем гибкость, от которой покупатель отказывается, оставаясь внутри локального набора регионов.
Комплаенс — это и торговое преимущество, и центр издержек
Комплаенс-сообщение Yandex Cloud занимает центральное место в надбавке. На странице решения по Федеральному закону 152-ФЗ клиентам предлагается переносить, хранить и обрабатывать персональные данные российских сотрудников и клиентов в защищённом облаке внутри России, и говорится, что платформа сертифицирована ФСТЭК и соответствует требованиям защиты персональных данных для облачного хранения и обработки (https://yandex.cloud/en/solutions/152-fz). Та же страница ссылается на заявления о соответствии ISO, GDPR, PCI DSS и ГОСТ Р 57580. В документации по комплаенсу информационной безопасности говорится, что Yandex.Cloud LLC получила оценочное заключение о соответствии требованиям Банка России по информационной безопасности в рамках ГОСТ Р 57580.1-2017 с общим показателем R=0,92 и уровнем соответствия 5 на момент завершения аудита (https://yandex.cloud/en/docs/security/conform).
Эти детали не декоративны. Банк, финтех или розничный клиент в России не покупает облачные мощности как абстрактный товар. Он покупает ответ для аудиторов, внутренних комитетов по рискам и контрагентов. Чем более чувствительна рабочая нагрузка, тем больше сервис должен включать шифрование, аудиторские журналы, логирование, контроль идентичности и документированные зоны ответственности. Yandex Audit Trails продвигается как способ собирать события безопасности облачной платформы и поддерживать внутренние и внешние аудиты с экспортом в хранилище и внешние системы (https://yandex.cloud/en/services/audit-trails). В документации по наблюдаемости мониторинг, логи и аудиторские события описываются как взаимодополняющие инструменты для контроля работоспособности, анализа поведения, обнаружения ошибок и анализа событий безопасности (https://yandex.cloud/en/docs/overview/concepts/monitoring-logging-tools).
Комплаенс — это и центр издержек. Сертификация, аудиторские доказательства, безопасный по умолчанию дизайн, сервисы шифрования, персонал поддержки и реагирование на инциденты не бесплатны. В финансовом отчёте Yandex за 2025 год говорится, что информационная безопасность была одной из стратегических областей роста и что в 2025 году каждый четвёртый коммерческий клиент использовал решения безопасности Yandex Cloud (https://yandex.cloud/en/blog/financial-results-2025). Это подтверждает тезис о том, что клиенты покупают больше, чем сырые вычисления. Это также показывает, почему локальное облако может расти даже тогда, когда клиенты чувствительны к издержкам: комплаенс может направлять расходы в сервисы, снижающие внутренний риск.
Предел ценности столь же ясен. Заявление о соответствии наиболее сильно, когда оно привязано к конкретной рабочей нагрузке, конфигурации и границе ответственности клиента. На собственной странице Yandex Cloud о персональных данных клиентам говорится, что они должны определить тип данных, выбрать средства защиты и оценить собственное соответствие требованиям при миграции (https://yandex.cloud/en/solutions/152-fz). Провайдер может предоставить платформу, сертификации и инструменты. Он не может снять с каждого клиента его операционную ответственность. Это различие важно на рынке, где закупочные команды могут относиться к контракту с локальным облаком как к короткому пути к комплаенсу. Это короткий путь только в том случае, если приложение, модель доступа и процесс доказательств также построены правильно.
Сетевые свидетельства показывают публичный охват с местной гравитацией
Сетевые свидетельства подтверждают реальную операционную поверхность облака, но также показывают местную гравитацию. Сущность в каталоге ассоциирована с AS210656, который публичные сетевые инструменты называют YACLOUDBMS. Страница AS210656 в RIPEstat сообщает, что автономная система видна в коллекторах маршрутов; страница ресурса доступна по адресуhttps://stat.ripe.net/resource/AS210656. IPLocate указывает AS210656 как Yandex.Cloud LLC, имя AS — YACLOUDBMS, страна — Россия, регистратура — RIPE, распределение — 11 октября 2021 года, 4 608 адресов IPv4 и ни одного адреса IPv6 в этом представлении (https://www.iplocate.io/AS210656). Страница AS210656 на IPinfo также размещает долю IPv4 в России и показывает пингуемые адреса с образцами задержек из Москвы (https://ipinfo.io/AS210656).
AS210656 не следует переоценивать. Это свидетельство о сетевых ресурсах, а не отдельная компания. Судя по всему, он находится в более широкой среде маршрутизации Yandex Cloud. BGP.Tools показывает AS200350 как Yandex.Cloud LLC и включает замечания о маршрутной политике для «Yandex Cloud BMS» с импортом из AS210656 и экспортом в AS210656 (https://bgp.tools/as/200350). В собственной документации Yandex о частных соединениях говорится, что фиксированный номер автономной системы BGP Yandex Cloud для соединений равен 200350, и клиентам предлагается разрешить четырёхбайтовый ASN в конфигурации оборудования (https://yandex.cloud/en/docs/interconnect/concepts/priv-con). PeeringDB указывает AS200350 для Yandex.Cloud LLC, набор маршрутов AS-YACLOUD, тип сети Enterprise, 100 префиксов IPv4 и 10 префиксов IPv6 в публичной записи (https://www.peeringdb.com/net/20950). Cloudflare Radar аналогично определяет AS200350 как YandexCloud / Yandex.Cloud LLC и перечисляет связанные автономные системы той же организации, включая AS210656 и AS215013 (https://radar.cloudflare.com/routing/as200350).
Для клиентов важен уровень достижимости, а не детали ASN. Облачный провайдер должен надёжно передавать трафик между офисами клиентов, публичными пользователями, частными соединениями, хранилищами, управляемыми базами данных и сервисами поддержки. В документации Yandex Cloud Interconnect о частных соединениях описывается, как оборудование клиента или телеком-оператора устанавливает связность третьего уровня и BGP-пиринг с оборудованием Yandex Cloud в точках присутствия, а маршруты попадают во все зоны доступности Yandex Cloud (https://yandex.cloud/en/docs/interconnect/concepts/priv-con). Это сетевая версия надбавки за суверенитет: внутреннее облако полезно только в том случае, если его можно интегрировать в существующие корпоративные сети, не заставляя каждую рабочую нагрузку проходить по нестабильным публичным маршрутам.
Ограничение в том, что публичные BGP-данные дают лишь частичную картину. Они показывают заявленные ресурсы, отношения маршрутов и публичную достижимость. Они не доказывают доступную мощность, внутреннее резервирование, скорость ремонта или производительность для конкретного клиента. Свидетельств достаточно, чтобы подтвердить, что публичный сетевой след Yandex Cloud работоспособен и локально сбалансирован. Их недостаточно, чтобы заявить, что каждая корпоративная нагрузка получит отказоустойчивость уровня глобального гиперскейлера.
Спрос реален, но он не является полностью добровольным
История спроса Yandex Cloud сильна по её собственным цифрам. В финансовом отчёте за 2025 год говорится, что выручка Yandex Cloud достигла 27,6 млрд рублей в 2025 году, увеличившись на 39 % по сравнению с 2024 годом и в 3,5 раза по сравнению с 2022 годом, при четырёх годах положительной EBITDA и 93 % выручки от внешних клиентов (https://yandex.cloud/en/blog/financial-results-2025). Там же сказано, что число клиентов достигло 51 000, рост составил 17 %, а средний и крупный бизнес обеспечил 84 % выручки. В финансовом отчёте за 2024 год уже говорилось, что выручка достигла 19,80 млрд рублей, рост составил 50 %, а число клиентов превысило 44 000 (https://yandex.cloud/en/blog/posts/2025/03/financial-results-2024). В отчёте за первое полугодие 2025 года выручка за полугодие указана на уровне 12,8 млрд рублей, а лидерами потребления облачных услуг названы банковский сектор, финтех, розничная торговля и ИТ (https://yandex.cloud/en/blog/financial-results-h1-2025).
Эти цифры не равнозначны независимой аудированной сегментной отчётности, но они значимы, потому что описывают масштабируемую платформу с корпоративной структурой клиентов, внешней выручкой и положительной EBITDA. Они также соответствуют более широкой рыночной картине. Telecompaper со ссылкой на ComNews и iKS Consulting сообщил, что российский рынок услуг облачной инфраструктуры, как ожидалось, должен был достичь 416,5 млрд рублей в 2025 году, что на 29,2 % больше, чем 322,3 млрд рублей в 2024 году, с прогнозом 1,2 трлн рублей в 2030 году (https://www.telecompaper.com/news/russian-cloud-infrastructure-services-market-value-to-rise-30-percent-in-2025-study--1553936). TAdviser, обобщая данные iKS Consulting и других источников по российскому рынку, говорит, что рынок российской инфраструктурной облачной инфраструктуры значительно вырос в 2023 году отчасти потому, что пользователи переходили из иностранных облаков в российские, и что Cloud.ru и Yandex.Cloud увеличили долю на рынке IaaS в 2023 году (https://tadviser.com/index.php/Article%3AInfrastructure_as_a_Service%2C_IaaS_%28Russian_market%29).
Со словом «спрос» нужно быть осторожным. Часть спроса — это добровольная модернизация: компаниям нужны управляемые базы данных, Kubernetes, аналитика, безопасность и ИИ-инструменты, потому что облачные операционные модели полезны. Часть спроса — это защитное замещение: иностранные сервисы сложнее покупать, продлевать, поддерживать или обосновывать. Microsoft в марте 2022 года объявила о приостановке всех новых продаж продуктов и услуг в России и о прекращении многих аспектов своего российского бизнеса в соответствии с санкционными решениями (https://blogs.microsoft.com/on-the-issues/2022/03/04/microsoft-suspends-russia-sales-ukraine-conflict/). Amazon заявила, что больше не будет принимать новые регистрации AWS из России и Беларуси и что у неё нет дата-центров, инфраструктуры или офисов в России (https://www.aboutamazon.com/news/aws/updates-to-amazons-retail-entertainment-and-aws-businesses-in-russia-and-belarus). Oracle сообщает, что прекратила операции, услуги и поддержку для российских и белорусских компаний, дочерних структур и партнёров (https://www.oracle.com/corporate/conflict-in-ukraine/russia/).
Это не делает рост Yandex Cloud искусственным. Это означает, что компания обслуживает рынок, на котором обычное внедрение облаков и вынужденное замещение переплетены. Надбавка устойчива только в том случае, если клиенты остаются, потому что платформа работает, а не только потому, что выход обходится дорого.
Доступ к оборудованию — самое жёсткое ограничение надбавки
Самое слабое звено доказательной базы — оборудование. Yandex Cloud может показать клиентов, рост выручки, зоны доступности, документы о соответствии и широту продуктов. Публичные источники не могут полностью показать будущую стоимость серверов, ускорителей, сетевого оборудования, носителей, запасных частей и обслуживания в условиях экспортного контроля. Именно это звено важно для оценки, потому что любое облачное обещание в итоге упирается в машинный зал.
Внешние ограничения реальны. Бюро промышленности и безопасности США сообщает, что ввело жёсткий экспортный контроль в отношении России и Беларуси в ответ на вторжение России в Украину, а страновые рекомендации и программные ограничения поддерживаются на странице, посвящённой России и Беларуси (https://www.bis.gov/licensing/country-guidance/russia-belarus). Европейская комиссия сообщает, что ЕС ужесточил и расширил экспортный контроль товаров двойного назначения, чтобы ограничить чувствительные сектора в России и доступ к критически важным передовым технологиям (https://commission.europa.eu/topics/eu-solidarity-ukraine/eu-sanctions-against-russia-following-invasion-ukraine/sanctions-dual-use-goods_en). Совет Европейского союза сообщает, что с февраля 2022 года ЕС запретил товары и технологии на сумму более 48 млрд евро, которые в противном случае были бы экспортированы в Россию (https://www.consilium.europa.eu/en/policies/sanctions-against-russia-explained/).
Эти ограничения не говорят точно, что Yandex Cloud может или не может купить в каждом квартале. Они говорят о том, что закупки структурно сложнее, чем на неограниченном рынке. Провайдер может использовать существующие запасы, альтернативные маршруты поставок, российских интеграторов, поставщиков вне западных стран, восстановленное оборудование, оптимизацию рабочих нагрузок и собственную программную инженерию. Но чем больше спрос смещается в управляемые базы данных, аналитику, ИИ и безопасность, тем больше облаку нужны плотные вычисления, быстрое хранение, качественные сети и стабильный цикл замены.
Собственное продуктовое направление Yandex признаёт это, расширяясь за пределы обычных виртуальных машин. В финансовом отчёте за 2025 год говорится, что Yandex Cloud поддерживает публичное облако, локальную и гибридную модели и фокусируется на решениях в области ИИ, информационной безопасности, платформы данных и инфраструктуры (https://yandex.cloud/en/blog/financial-results-2025). Yandex BareMetal даёт клиентам выделенные физические серверы, когда им нужна изоляция ресурсов или прямой контроль (https://yandex.cloud/en/services/baremetal). Distributed Cloud продвигается как способ расширить технологии Yandex Cloud на среды публичного облака и площадки заказчика (https://yandex.cloud/en/solutions/distributed-cloud). Эти продукты помогают монетизировать ограниченную среду, но также показывают сложность обслуживания покупателей, которые не могут просто разместить каждую рабочую нагрузку в стандартном публичном регионе.
Коммерческое суждение неудобно, но полезно. Дефицит оборудования может защищать Yandex Cloud, делая внутренние мощности дефицитными и ценными. Он также может ограничивать рост, усиливать давление амортизации и делать расширение услуг дороже. Устойчивая надбавка требует, чтобы Yandex Cloud превращала дефицит в инженерную эффективность, а не просто пропускала дефицит через счета зависимых клиентов.
Цены сигнализируют об уверенности, а не об изобилии
Ценовые сигналы заслуживают отдельного прочтения, потому что они показывают, как провайдер хочет, чтобы клиенты воспринимали дефицит. В обновлении цен 2026 года повышения на уровне сервисов подаются как умеренные — от 5 % до 8 % для большинства затронутых сервисов, при этом часть предложений ИИ и безопасности не затрагивается (https://yandex.cloud/en/blog/pricing-update-2026). Публичная страница ценового калькулятора по-прежнему рекламирует конкурентные точки входа (https://yandex.cloud/en/prices). Вместе эти страницы показывают, что Yandex Cloud хочет сохранить представление о том, что внутреннее облако — это обычная операционная статья расходов, а не аварийная надбавка.
Покупатель видит более многослойную картину. Если обновление собственного серверного парка требует труднодоступных запчастей, неопределённой доставки и внутреннего инженерного времени, повышение облачных цен на 5–8 % может выглядеть разумным. Если иностранный облачный аккаунт нельзя открыть для новой российской работы, счёт за внутреннее облако приобретает опционную ценность. Если комплаенс-проверка проще с локальной документацией, у процесса закупки появляется ценность, которую не отражает сравнение стоимости процессорных часов.
В этом смысле цена Yandex Cloud конкурирует с полной стоимостью ограниченного заменителя, а не просто с самой дешёвой видимой облачной инстанцией в другой стране.
Есть и риск ложного успокоения. Покупатели облаков могут принять гладкость операционных расходов за низкие структурные издержки. Провайдер поглощает волатильность оборудования, электроэнергии, программного обеспечения и труда до того, как она дойдёт до счёта клиента. Это упрощает бюджетирование для клиента, но не устраняет издержки. Если слабость местной валюты, дефицит оборудования или ограничения электроэнергии усилятся, провайдеру придётся выбирать между более низкой маржой, более высокими ценами, более длинными сроками ввода мощностей или более жёстким поведением квот.
Документы Yandex Cloud об SLA и поддержке соответствуют такому прочтению. В обзоре SLA говорится, что условия уровня обслуживания определяют гарантированную доступность и уровни обслуживания сервисов Yandex Cloud (https://yandex.cloud/en/docs/overview/sla). В документации поддержки сказано, что поддержка Yandex Cloud доступна 24/7 в зависимости от тарифного плана через консоль управления (https://yandex.cloud/en/docs/overview/qa). Это обычные корпоративные заверения. На российском облачном рынке они также часть надбавки: покупатели платят, чтобы не отвечать за все режимы отказов самостоятельно.
Публичная видимость инцидентов — умеренный противовес. Yandex ведёт хронологию статусов компонентов платформы (https://status.yandex.cloud/en/timeline), а сторонние сводки мониторинга, такие как StatusGator, фиксируют историю статусов Yandex Cloud и недавние проблемы компонентов (https://statusgator.com/services/yandex-cloud). Такие страницы не доказывают ни хроническую слабость, ни силу. Они показывают, что клиентам следует относиться к сервису как к любой важной облачной зависимости: проектировать под отказы, использовать многозонные схемы там, где это оправдано, и сохранять достаточно операционных знаний, чтобы переместить или восстановить критичные рабочие нагрузки.
Локальная установка и выделенные серверы показывают границу доверия к публичному облаку
Развитие локальных, гибридных и выделенных серверных предложений Yandex Cloud — это не побочная история. Оно показывает, где российские покупатели всё ещё не решаются размещать рабочие нагрузки в общем публичном облаке. В финансовом отчёте за 2024 год говорилось, что с 2024 года сервисы Yandex Cloud стали доступны и в облаке, и на локальной инфраструктуре, начиная с таких продуктов, как YDB, базовые модели, SpeechKit и DataLens, а также были доступны гибридные варианты (https://yandex.cloud/en/blog/posts/2025/03/financial-results-2024). В финансовом отчёте за 2025 год говорится, что локальные решения обеспечили 3,4 % общей выручки, а Stackland назван инфраструктурным решением для управления ИИ-нагрузками и приложениями на микросервисах на локальной площадке (https://yandex.cloud/en/blog/financial-results-2025).
Для поставщика банка локальные облачные сервисы могут разрешить практическое противоречие. Покупатель хочет облачные инструменты, но его комитет по рискам может не принять размещение каждой рабочей нагрузки в публичном регионе. Локальное развёртывание позволяет покупателю держать чувствительные системы ближе к собственным площадкам, используя технологии и поддержку Yandex. Та же логика применима к крупным ритейлерам, промышленным компаниям и подрядчикам государственного сектора, которым нужны локализация данных, более строгий операционный контроль или интеграция с унаследованными системами.
Выделенные серверы решают ещё одну границу. На странице Yandex BareMetal сказано, что клиенты получают выделенный сервер, мощности которого закреплены за их компанией и на котором они могут устанавливать собственные инструменты виртуализации, операционные системы и программное обеспечение (https://yandex.cloud/en/services/baremetal). Там же сказано, что Yandex Cloud отвечает за работоспособность и обслуживание оборудования. Это гибридная сделка: клиент получает изоляцию и контроль, передавая слой дата-центра на аутсорсинг. Это привлекательно, когда лицензирование, производительность, безопасность или архитектура делают виртуализированное публичное облако слишком ограничивающим.
Такое продуктовое направление усиливает рыночную позицию Yandex Cloud, поскольку позволяет компании захватывать клиентов, не готовых к чистому публичному облаку. Но оно же делает бизнес более операционно сложным. Экономика публичного облака основана на пулинге, стандартизации и высокой утилизации. Выделенные серверы и локальные установки могут нести меньший эффект пулинга, больше индивидуальной поддержки и другие модели амортизации. Они могут углублять корпоративные отношения, но могут и превращать провайдера в интегратора управляемой инфраструктуры.
Правильная интерпретация такова: Yandex Cloud продаёт степени суверенитета. Публичное облако даёт совместные локальные мощности. Выделенные серверы добавляют физическую изоляцию. Локальные и распределённые варианты приносят технологии Yandex в среды, контролируемые клиентом. Каждый шаг может приносить доверие и выручку. Каждый шаг также требует больше инженерной дисциплины и коммерческой избирательности.
Сетевой клиент покупает поверхность зависимостей
Зависимость от облака редко бывает одной единственной. Клиент Yandex Cloud может зависеть от публичных диапазонов IP, объектного хранилища, управляемых баз данных, Kubernetes, контроля идентификации, журналов аудита, DNS, балансировщиков нагрузки, частных соединений, поддержки и биллинга. В документации Yandex о публичных диапазонах IP перечислены диапазоны адресов, назначенные ресурсам, поддерживающим работу Yandex Cloud, и сказано, что эти диапазоны недоступны пользователям (https://yandex.cloud/en/docs/overview/concepts/public-ips). В документации по соединениям объясняются требования BGP и выбор ASN на стороне клиента для частной связности (https://yandex.cloud/en/docs/interconnect/concepts/priv-con). Каталог услуг показывает набор компонентов, которые могут стоять за одним приложением (https://yandex.cloud/en/services).
Для сервиса оформления заказа у ритейлера поверхность зависимостей может включать группу виртуальных машин, балансировщик нагрузки, управляемый PostgreSQL, объектное хранилище для чеков, реестр контейнеров для развёртывания, мониторинг, журналы аудита и доступ поддержки. Отказ в любой части может стать бизнес-инцидентом. Изменение требований комплаенса может потребовать новых доказательств. Задержка с предоставлением мощностей может замедлить кампанию. Проблема маршрутизации может ухудшить пользовательский опыт. Поэтому покупатель приобретает набор зависимостей, который должен быть согласованным, а не просто дешёвым.
Именно здесь помогает широта Yandex Cloud. Клиент может держать большую часть стека у одного внутреннего провайдера и снижать трение от сшивания множества мелких вендоров. Сравнение платформы с категориями Google Cloud показывает, что Yandex хочет восприниматься как широкая облачная операционная среда, а не узкая хостинговая компания (https://yandex.cloud/en/docs/overview/platform-comparison/gcp). В отчёте за 2025 год сказано, что IaaS по-прежнему давал 52 % выручки, тогда как PaaS, включая решения для данных, контейнеризации, машинного обучения и безопасности, обеспечил 42 % (https://yandex.cloud/en/blog/financial-results-2025). Такое соотношение показывает, что покупатели переходят на более высокоуровневые сервисы, а не используют платформу только как арендованные серверы.
Это также повышает издержки переключения. Как только клиент выстроит систему вокруг управляемых баз данных, API хранилища, ролей идентификации, логов, частных соединений и сервисов безопасности, уйти становится сложнее, чем переместить один образ виртуальной машины. На обычном рынке привязка — знакомый облачный компромисс. На изолированном вычислительном рынке России привязка обостряется меньшим набором доступных заменителей. Это может поддерживать устойчивость выручки Yandex Cloud, но также делает недовольство клиентов более значимым, если качество сервиса ослабнет.
Покупатели, которые чувствуют себя запертыми, обычно начинают строже следить за повышением цен, сбоями и качеством поддержки.
Лучшим признаком для Yandex Cloud было бы использование платформы клиентами для новых цифровых продуктов, а не только для аварийной замены. Текущие свидетельства показывают и то и другое. Рост выручки и структура услуг указывают на внедрение продукта. Контекст санкций и иностранных сервисов указывает на давление замещения. Надбавка сильнее всего, когда эти силы сочетаются, не вызывая у клиентов недовольства.
Конкурентный набор — внутренние, гибридные и собственные решения
Реальная конкуренция Yandex Cloud — это не только другие названные облачные провайдеры. Это внутренняя инфраструктурная команда клиента, местный провайдер дата-центров с управляемым хостингом, частное облако банка, системный интегратор с индивидуальным стеком и публичный облачный конкурент с лучшим доступом к конкретному сектору. TAdviser сообщает, что по доле выручки российский рынок инфраструктурных облачных услуг по итогам 2023 года возглавил Rostelecom DPC, за ним следуют Cloud.ru, Yandex.Cloud, Selectel и MTS, и отмечает, что в этой версии Cloud.ru и Yandex.Cloud заняли первые два места в категории PaaS (https://tadviser.com/index.php/Article%3AInfrastructure_as_a_Service%2C_IaaS_%28Russian_market%29). Рыночный обзор Cloud4Y, хотя и подготовлен конкурентом, также относит Yandex Cloud к ведущим российским IaaS-провайдерам и отмечает широту услуг и ориентацию на ИИ (https://www.cloud4y.ru/en/blog/top-iaas-provider-2026/).
Важное конкурентное отличие — экосистема. Согласно финансовому отчёту за 2025 год, Yandex Cloud входит в Yandex B2B Tech, который включает Yandex 360 и другие бизнес-сервисы (https://yandex.cloud/en/blog/financial-results-2025). Это даёт узнаваемость бренда, знакомство разработчиков и межсервисные связи. Компания может продавать облако клиентам, которые уже знают Yandex по поиску, рекламе, картам, электронной коммерции, мобильности или бизнес-программам. Экосистема помогает объяснить, почему Yandex Cloud может расти в PaaS и ИИ-сервисах, а не конкурировать только по цене виртуальных машин.
Но экосистема не отменяет закупочную дисциплину. Крупные российские покупатели часто распределяют рабочие нагрузки, чтобы избежать зависимости от одного провайдера, сохранить переговорную силу или удовлетворить отраслевые требования. Заказчики, связанные с государством и регулируемыми секторами, могут иметь действующих телеком- или государственных поставщиков. Малый бизнес может выбирать более простой хостинг. Разработчики могут предпочитать самостоятельно управляемые компоненты с открытым исходным кодом, если цены на управляемые сервисы растут. Эти факторы ограничивают, какую надбавку Yandex Cloud может извлечь.
Конкурентный набор формируется и талантами. Провайдер с сильными инженерами может создавать отечественные замены отсутствующим сервисам, настраивать утилизацию и поддерживать сложные миграции. На русскоязычной странице «О компании» перечислена широкая команда руководителей и разработчиков продуктов, включая лидеров направлений управляемых сервисов, машинного обучения, YDB и инфраструктуры (https://yandex.cloud/ru/about). Кадровая база — стратегический актив. Это также издержки. Если квалифицированные облачные инженеры станут дефицитом, давление на зарплаты превратится в ещё одни постоянные издержки, скрытые в счёте.
Поэтому коммерческая оценка сбалансирована. Yandex Cloud обладает сильным внутренним позиционированием, заслуживающей доверия широтой услуг, видимыми сетевыми ресурсами и растущей заявленной выручкой. Её преимущество не абсолютно. Компании нужно продолжать побеждать внутренних конкурентов, собственные разработки и осторожность клиентов, одновременно неся тяжёлые издержки локального облачного замещения.
Качество обслуживания будут оценивать на границе рабочей нагрузки
Надбавку за суверенитет не будут защищать в презентациях для совета директоров. Её будут защищать на границе рабочей нагрузки, где покупатель узнаёт, может ли платформа поддерживать конкретный сервис в условиях конкретного ограничения. Поставщик банка будет оценивать Yandex Cloud по неудачной платёжной задаче, которая восстановилась или не восстановилась. Ритейлер — по корзине изображений, которая во время распродажи ограничила или не ограничила пропускную способность. Поставщик программного обеспечения — по тому, было ли окно обслуживания управляемой базы данных объявлено достаточно рано, чтобы защитить релиз.
Именно такой опыт решает, будет ли клиент относиться к Yandex Cloud как к стратегической платформе или как к вынужденному заменителю.
Это важно, потому что российское облачное замещение — не разовая миграция. Первым шагом может быть аварийная замена: перенести рабочие нагрузки из старого иностранного аккаунта, закрыть закупочный пробел, переместить персональные данные в локальную среду или снизить зависимость от оборудования, которое сложно обновить. Второй шаг сложнее. Клиенту нужно решить, должны ли новые продукты с самого начала проектироваться вокруг внутреннего облака. Такое решение требует доверия к мощностям, поддержке, документации, инструментам экосистемы и поведению цен на протяжении нескольких циклов, а не только одной успешной первоначальной миграции.
Возможность Yandex Cloud состоит в том, чтобы превращать каждый инцидент поддержки в доказательство компетентности. Если поддержка быстро решает вопросы квот, если документация актуальна, если управляемые базы данных предсказуемо проходят обновления, если частные соединения предоставляются без повторных инженерных сюрпризов, внутренняя надбавка становится менее болезненной. Покупатель начинает сравнивать Yandex Cloud с собственным риском самостоятельного хостинга, а не с глобальным провайдером, которого он не может легко купить. Именно в этот момент плен начинает превращаться в способность.
Верно и обратное. Если клиенты сталкиваются с медленным одобрением мощностей, запутанными изменениями продуктов, неровной документацией, повторяющимися мелкими сбоями или поддержкой, которая не может объяснить границы ответственности, надбавка становится заметной неправильным образом. Она перестаёт выглядеть как страховка и начинает выглядеть как наценка ограниченного рынка. В меньшем наборе заменителей недовольство может накапливаться тихо, потому что клиенты могут продолжать тратить деньги, даже планируя внутренние альтернативы или хеджирование через нескольких провайдеров.
Поэтому качество обслуживания — это переменная оценки, а не операционная сноска. Рост выручки доказывает, что клиенты покупают. Он не доказывает, что они становятся менее чувствительными к цене или менее готовыми уйти. Устойчивая надбавка принадлежит провайдеру, который может сделать локальное облако скучным в лучшем смысле: предсказуемые счета, предсказуемая поддержка, предсказуемое обслуживание, предсказуемые доказательства комплаенса и предсказуемое восстановление после отказов. У Yandex Cloud есть активы, чтобы бороться за эту позицию. Но ей ещё предстоит заслужить её, нагрузка за нагрузкой.
Вопрос оценки — превратится ли плен в способность
Итоговое суждение сводится к разнице между пленом и способностью. Плен означает, что клиенты используют Yandex Cloud, потому что иностранные альтернативы сокращены, оборудование трудно купить, комплаенс локален, а уход болезнен. Способность означает, что клиенты используют Yandex Cloud, потому что она помогает им строить системы лучше, чем они могли бы эксплуатировать сами, даже с учётом цены и привязки.
Свидетельства поддерживают обе стороны. Плен виден в рыночном контексте: иностранные провайдеры приостановили новые продажи в России или прекратили операции, экспортный контроль ограничивает потоки технологий, а российским клиентам нужны локальные ответы по данным и договорам. Способность видна в широте услуг Yandex Cloud, комплаенс-позиции, сетевом присутствии, росте выручки, числе клиентов и экспансии в локальные, гибридные и казахстанские инфраструктуры. Показатели финансового отчёта за 2025 год — выручка 27,6 млрд рублей, рост 39 %, 51 000 клиентов и 93 % внешней выручки — являются самыми сильными предоставленными компанией индикаторами коммерческого импульса (https://yandex.cloud/en/blog/financial-results-2025). Сетевые свидетельства вокруг AS210656 и AS200350 подтверждают наблюдаемый облачный след (https://stat.ripe.net/resource/AS210656иhttps://bgp.tools/as/200350). Комплаенс-страницы показывают, почему регулируемые покупатели могут обосновать выбор платформы (https://yandex.cloud/en/docs/security/conformиhttps://yandex.cloud/en/solutions/152-fz).
Свидетельства также оставляют три слабости. Во-первых, публичные источники не полностью раскрывают стоимость закупки оборудования, глубину запасов запчастей или будущий запас мощностей провайдера. Во-вторых, заявленная облачная выручка публикуется самой компанией и не является отдельным аудированным сегментом публичной компании с детальным раскрытием маржи. В-третьих, спрос, вызванный замещением, может скрывать недовольство до тех пор, пока у покупателей не появятся лучшие альтернативы. Клиент может увеличивать расходы у провайдера, одновременно желая, чтобы набор вариантов был шире.
Пока надбавка Yandex Cloud выглядит реальной, потому что решает срочную операционную проблему: она даёт российским предприятиям знакомую облачную операционную модель внутри ограниченной юридической, платёжной, сетевой и снабженческой среды. Надбавка — это не безрисковая ценовая сила. Это проверенный на прочность спред между стоимостью локальной способности и стоимостью хрупких заменителей. Если Yandex Cloud продолжит расширять мощности, поддерживать комплаенс, улучшать управляемые сервисы и развивать гибридные развёртывания, плен может превратиться в способность.
Если доступ к оборудованию ужесточится, сбои участятся, цены опередят ценность или клиенты найдут лучшие внутренние альтернативы, та же надбавка может стать доказательством запертого рынка.
Именно поэтому маленькая ежемесячная единица покупателя — виртуальная машина, корзина хранилища, месяц базы данных или инцидент поддержки — это правильное место для наблюдения. Она показывает, что на самом деле покупает счёт. Он покупает вычисления, но также локальную законность, достижимую инфраструктуру, инженерный труд, перенос риска и практичный заменитель облачного мира, к которому Россия больше не имеет доступа на обычных условиях. Коммерческое будущее Yandex Cloud зависит от того, удастся ли сделать этот заменитель похожим на платформу, а не на компромисс.