Архитектура Multi-Cloud: S3 как независимый элемент — как не зависеть от одного облака и защитить данные

Серверы и инфраструктура · 25.10.2026 · 14 мин чтения · Команда НПП РЕКОРД

Облако тоже ломается, дорожает и уходит с рынка. Мультиоблачная архитектура снижает этот риск, но только если данные не заперты у одного провайдера. Разбираем, почему именно S3 стал «общим языком» хранилищ, как сделать его независимым слоем архитектуры, какие схемы работают для бэкапов и аварийного восстановления, сколько это стоит и где «S3-совместимость» подводит.

Коротко. Мультиоблако (multi-cloud) — это когда компания использует несколько облачных провайдеров, чтобы не зависеть от одного. Главная ловушка — данные: серверы перенести легко, а терабайты, привязанные к хранилищу конкретного облака, — нет. S3 решает это, потому что это не продукт одного провайдера, а общий стандарт: его поддерживают почти все облака и локальные системы хранения. Если приложения и бэкапы работают с данными через S3, смена провайдера сводится к смене адреса и ключей доступа, копию можно держать у второго провайдера, а неизменяемые копии (Object Lock) защищают от шифровальщика.

Перенос IT в облако часто продают как решение всех проблем: не надо покупать серверы, не надо следить за железом. Но облако — это тоже чей-то дата-центр. Он может сгореть, отключиться из-за ошибки инженера, поднять цены или уйти с рынка, как это сделали зарубежные провайдеры в 2022 году. Компания, у которой всё в одном облаке, просто перенесла единственную точку отказа из своей серверной в чужую. Мультиоблачная архитектура разносит риски по нескольким провайдерам, и ключевое слово в ней — данные: именно их сложнее и дороже всего переносить.

Данные в стандартном формате S3 можно держать у нескольких провайдеров одновременно

Облака тоже падают: три истории

• Февраль 2017 года: хранилище Amazon S3 в крупнейшем регионе AWS (Северная Вирджиния) было недоступно около четырёх часов. Причина — опечатка инженера в команде, которая отключила больше серверов, чем планировалось. Вместе с хранилищем легли тысячи сайтов и сервисов, построенных только на нём.
• Март 2021 года: пожар в дата-центре OVHcloud в Страсбурге уничтожил один из корпусов. Клиенты, которые хранили резервные копии в том же дата-центре или вообще не делали копий, потеряли данные безвозвратно.
• Октябрь 2025 года: сбой в том же регионе AWS из-за проблем с DNS (системой, которая переводит имена сервисов в адреса) на многие часы нарушил работу огромного числа сервисов по всему миру — от мессенджеров до банков.

Вывод не в том, что облака ненадёжны: крупные провайдеры работают надёжнее типовой серверной в офисе. Вывод в том, что любой провайдер — это одна точка отказа, и план на случай её отказа должен существовать до аварии.

Что такое мультиоблако и чем оно отличается от гибридного облака

API (программный интерфейс) — это набор команд, которыми программа общается с сервисом: «положи файл», «отдай файл», «покажи список». Когда команды у всех провайдеров одинаковые, программе всё равно, с каким из них работать.

Почему именно S3 стал общим языком хранилищ

S3 (Simple Storage Service) Amazon запустил в 2006 году. За два десятилетия его API стал стандартом де-факто: под него написаны тысячи программ — системы резервного копирования, CMS сайтов, аналитические платформы, медиасерверы. Поэтому другие производители хранилищ не стали изобретать своё, а повторили API S3. Сегодня S3-совместимое хранилище предлагают все крупные российские облака (Yandex Cloud, VK Cloud, Selectel, Cloud.ru и другие), а у себя его можно развернуть на открытых решениях вроде Ceph или MinIO.

Отсюда главная идея статьи. Хранилище с API S3 — это не часть конкретного облака, а независимый слой архитектуры. Приложение знает только адрес хранилища и ключи доступа. Сменили провайдера — поменяли адрес и ключи, код остался прежним. Добавили второго провайдера — настроили копирование между двумя хранилищами с одинаковым API.

• 2006 — год запуска Amazon S3 (API стал стандартом де-факто)
• 1 API — у облачных и локальных хранилищ (смена провайдера — смена адреса и ключей)
• 96% — атак вымогателей нацелены и на бэкапы (копии нужны вне досягаемости)
• 76% — таких попыток успешны (если копии можно перезаписать)

Источник: Amazon Web Services; Sophos State of Ransomware 2025

Четыре рабочие схемы

1. Бэкап у другого провайдера. Самая простая и самая полезная схема. Рабочие системы живут у провайдера А или в своей серверной, а резервные копии уходят в S3-хранилище провайдера Б. Пожар, блокировка аккаунта или сбой у основного провайдера не затрагивают копии. Большинство современных систем резервного копирования (Veeam, Кибер Бэкап, RuBackup и другие) умеют писать прямо в S3.

2. Неизменяемые копии против шифровальщика. В S3 есть механизм Object Lock (блокировка объектов, принцип WORM — «записал один раз, читай много»). Объект с такой блокировкой нельзя удалить или перезаписать до окончания срока хранения. В строгом режиме (compliance) этого не может сделать даже администратор с полными правами. Злоумышленник, захвативший сеть и учётные записи, не сотрёт такие копии — а именно это вымогатели пытаются сделать почти в каждой атаке.

3. Основное хранилище + реплика. Приложение работает с хранилищем провайдера А, а объекты по расписанию или непрерывно копируются к провайдеру Б. При отказе А приложение переключают на Б сменой адреса. Подходит для файлов сайта, документов, медиаархивов.

4. Гибрид: своё хранилище + облако. Локальное S3-хранилище (на Ceph или MinIO) в своей серверной — для быстрого доступа и данных, которые нельзя выносить, и копия в облачный S3 — для защиты от потери площадки. Код приложения одинаков для обоих.

Совет. Начинать стоит с первых двух схем: бэкап у другого провайдера с Object Lock. Это несколько дней работы, а защищает от двух самых дорогих сценариев — потери провайдера и шифровальщика. Сложные «активные» мультиоблака нужны единицам.

Где «S3-совместимость» подводит

S3-совместимый — не значит одинаковый. Базовые операции (положить, получить, удалить файл, список) работают везде. А вот более продвинутые функции у разных провайдеров и решений реализованы по-разному или отсутствуют:

• Object Lock и версионирование: есть не у всех, а если есть — проверьте, поддерживается ли строгий режим и работает ли с ним ваша система резервного копирования.
• Политики доступа и права: синтаксис и возможности отличаются от провайдера к провайдеру, настройки прав не переносятся «копированием».
• Правила жизненного цикла (автоматическое удаление или перенос старых файлов в дешёвый класс хранения): классы хранения и их названия у всех свои.
• Встроенная репликация между хранилищами обычно работает только внутри одного провайдера. Для копирования между разными провайдерами нужны внешние инструменты — например, rclone или сама система резервного копирования.
• Уведомления о событиях, шифрование с ключами клиента, временные ссылки на скачивание — проверяйте каждую функцию, которую используете.

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

Сколько это стоит

Объектное хранилище — один из самых дешёвых способов хранить большие объёмы данных, но в мультиоблаке у него три статьи расходов, о которых часто забывают:

Особое внимание — исходящему трафику. Положить данные в облако обычно бесплатно, а забрать большой объём при переезде или восстановлении может оказаться неожиданно дорого. Это и есть экономическая привязка к поставщику: технически уйти можно, но платить за выгрузку приходится сразу и много. Считайте стоимость восстановления заранее, при выборе провайдера, а не в день аварии.

Персональные данные и 152-ФЗ

Если в хранилище лежат персональные данные граждан России (базы клиентов, документы сотрудников, сканы паспортов), действует требование закона о персональных данных: запись, хранение и обработка таких данных должны вестись в базах данных на территории России, а с 1 июля 2025 года требование ужесточено. На практике это значит: для таких данных выбирайте российских провайдеров с дата-центрами в России и аттестацией под требования к защите персональных данных, а зарубежные облака — только для данных без персональной информации и с пониманием рисков.

Совет. Ещё один довод за шифрование: включите шифрование объектов, а ключи храните отдельно от хранилища — у себя или в отдельном сервисе ключей. Тогда даже при утечке на стороне провайдера данные останутся нечитаемыми.

Как сделать S3 независимым элементом: пошагово

1. Составить карту данных: что лежит где, сколько весит, что критично и что содержит персональные данные.
2. Определить для каждой группы данных RPO и RTO: сколько данных можно потерять и как быстро нужно восстановиться.
3. Перевести хранение файлов и резервных копий на работу через API S3, а не через уникальные сервисы конкретного облака.
4. Вынести адрес хранилища, ключи и имя бакета (контейнера для объектов) в настройки приложения, а не в код.
5. Выбрать второго провайдера и настроить копирование критичных данных к нему: для бэкапов — средствами системы резервного копирования, для файлов — инструментом репликации.
6. Включить Object Lock для резервных копий и версионирование для рабочих данных.
7. Разделить учётные записи: ключи, которые пишут бэкапы, не должны иметь права удалять их, а доступ к консоли провайдера — только с многофакторной аутентификацией.
8. Раз в квартал проводить учебное переключение: восстановить систему или переключить приложение на второе хранилище и засечь время.

Мультиоблако — это не про количество провайдеров, а про свободу уйти от любого из них за часы, а не за месяцы. Серверы переносятся быстро, данные — нет. Поэтому независимость начинается со слоя хранения, и S3 — самый практичный способ её получить.

Теги: multi-cloud, мультиоблако, S3, объектное хранилище, резервное копирование, Object Lock, vendor lock-in, облака, 152-ФЗ