Экономия на S3, Azure, GCS — гайд 2026

Почему хранилище данных съедает облачный бюджет

Вот что удивляет многих: затраты на хранение данных составляют от 25 до 40% общего счёта за облако. А большинство команд при этом бросают все силы на оптимизацию вычислительных ресурсов — и спокойно игнорируют растущие расходы на объектное хранилище.

По данным на 2026 год, организации без чёткой стратегии управления классами хранения переплачивают десятки тысяч долларов в год на каждый петабайт. Десятки тысяч — не на весь инфра-бюджет, а только на хранилище.

Давайте разберём конкретные стратегии снижения затрат в Amazon S3, Azure Blob Storage и Google Cloud Storage — с актуальными ценами, рабочими примерами кода и сравнительными таблицами.

Сравнение уровней хранения: S3 vs Azure Blob vs GCS

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

Amazon S3: семь классов хранения

AWS предлагает наибольшее количество вариантов — и это одновременно плюс и минус, потому что разобраться во всех нюансах непросто:

S3 Standard — $0,023/ГБ (первые 50 ТБ, us-east-1). Для часто используемых данных.
S3 Intelligent-Tiering — автоматическое перемещение между уровнями доступа на основе паттернов обращения. Об этом подробнее ниже.
S3 Standard-IA — $0,0125/ГБ. Для данных с редким доступом, но требующих мгновенной выдачи.
S3 One Zone-IA — $0,01/ГБ. То же самое, но без репликации между зонами доступности (подходит для данных, которые можно восстановить).
S3 Glacier Instant Retrieval — для архивов с единичным обращением раз в квартал.
S3 Glacier Flexible Retrieval — от $0,0036/ГБ. Восстановление за минуты или часы.
S3 Glacier Deep Archive — $0,00099/ГБ. Самый дешёвый вариант для долгосрочного хранения.

Azure Blob Storage: пять уровней и Premium

Hot — $0,018/ГБ. Низкая стоимость доступа, но высокая стоимость хранения.
Cool — $0,01/ГБ. Минимальный срок хранения — 30 дней.
Cold — $0,0045/ГБ. Минимальный срок — 90 дней.
Archive — $0,002/ГБ. Восстановление занимает часы. Минимальный срок — 180 дней.
Premium — для нагрузок с высокой частотой транзакций и требованиями к минимальной задержке.

Google Cloud Storage: четыре класса и Autoclass

Standard — $0,020/ГБ. Для активно используемых данных.
Nearline — $0,010–0,013/ГБ. Доступ реже раза в месяц.
Coldline — $0,004–0,006/ГБ. Доступ реже раза в квартал.
Archive — $0,0012/ГБ. Доступ реже раза в год.

Автоматизация перемещения данных между уровнями

Ручное управление уровнями хранения — это, мягко говоря, нереально при десятках миллионов объектов. Хорошая новость: все три провайдера предлагают механизмы автоматизации. Плохая — реализованы они по-разному.

S3 Intelligent-Tiering: автоматика на основе доступа

Intelligent-Tiering отслеживает паттерны обращения к каждому отдельному объекту и автоматически перемещает его между уровнями:

Нет обращений 30 дней → уровень Infrequent Access (экономия до 40%)
Нет обращений 90 дней → уровень Archive Instant Access (экономия до 68%)
Нет обращений 180 дней → уровень Deep Archive Access (экономия до 95%)

При повторном обращении объект автоматически возвращается в уровень частого доступа — без дополнительных сборов за извлечение. AWS утверждает, что с момента запуска Intelligent-Tiering клиенты сэкономили более $6 млрд. Цифра впечатляет, даже если учесть маркетинговый фактор.

Но есть нюанс: объекты размером менее 128 КБ не перемещаются между уровнями, а вот плата за мониторинг ($0,0025 за 1000 объектов/мес) всё равно начисляется. Если у вас миллионы мелких файлов — эта «оптимизация» может выйти дороже, чем обычный Standard.

S3 Lifecycle Policies: правила на основе времени

Lifecycle-политики работают проще: вы задаёте правило, и S3 механически перемещает или удаляет объекты по истечении указанного срока. Никакой магии с анализом доступа — чистая автоматизация по расписанию.

Пример конфигурации для перевода логов в архив:

{
  "Rules": [
    {
      "ID": "ArchiveLogs",
      "Filter": {
        "Prefix": "logs/"
      },
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        },
        {
          "Days": 365,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ],
      "Expiration": {
        "Days": 2555
      }
    }
  ]
}

Что делает этот конфиг: перемещает объекты из папки logs/ в Standard-IA через 30 дней, в Glacier через 90 дней, в Deep Archive через год и удаляет через 7 лет. Простая и предсказуемая схема.

Когда выбрать Intelligent-Tiering, а когда Lifecycle

Используйте Intelligent-Tiering, если паттерны доступа непредсказуемы — пользовательский контент, данные аналитики, ML-датасеты. Используйте Lifecycle-политики, если жизненный цикл данных чётко определён — логи, бэкапы, архивы с известным сроком хранения.

На практике наиболее зрелый подход — комбинация обоих: Intelligent-Tiering для активных данных и Lifecycle-правила для принудительного удаления устаревших объектов. Именно так делают большинство команд, которые серьёзно занимаются FinOps.

Azure Blob: политики управления жизненным циклом

В Azure можно создавать правила на основе даты последнего изменения или доступа. Пример через Azure CLI:

az storage account management-policy create \
  --account-name mystorageaccount \
  --resource-group myResourceGroup \
  --policy @policy.json

Содержимое файла policy.json:

{
  "rules": [
    {
      "enabled": true,
      "name": "move-to-cool-and-archive",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 180
            },
            "delete": {
              "daysAfterModificationGreaterThan": 730
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/", "backups/"]
        }
      }
    }
  ]
}

Имейте в виду: политики Azure активируются в течение 24 часов после создания или изменения. Не паникуйте, если изменения не применились сразу.

GCS Autoclass: автоматическая оптимизация от Google

Autoclass — пожалуй, самое элегантное решение из трёх провайдеров. Он мониторит фактические паттерны доступа и автоматически переносит объекты между Standard, Nearline, Coldline и Archive. В отличие от S3 Intelligent-Tiering, Autoclass не требует минимального размера объекта и не взимает отдельную плату за мониторинг. Просто включаете — и работает.

Включение для существующего бакета:

gcloud storage buckets update gs://my-bucket --enable-autoclass

Проверка текущего статуса:

gcloud storage buckets describe gs://my-bucket \
  --format="value(autoclass)"

Скрытая угроза: стоимость исходящего трафика (egress)

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

Сравнение тарифов на исходящий трафик (первые 10 ТБ/мес):

AWS S3 — $0,09/ГБ
Azure Blob — $0,087/ГБ
GCS — $0,12/ГБ (первый 1 ТБ), затем $0,11/ГБ

Давайте посчитаем: при объёме 100 ТБ/мес одни только расходы на egress могут достигать $8 500–10 000. И это создаёт экономический «замок» — классический vendor lock-in. Данные лежат в S3? Значит, дешевле держать compute тоже в AWS, даже если у другого провайдера виртуалки стоят меньше.

Как снизить расходы на egress

Используйте CDN: CloudFront, Azure CDN или Cloud CDN существенно снижают стоимость раздачи контента конечным пользователям.
Держите compute рядом с данными: размещайте вычислительные ресурсы в том же регионе и у того же провайдера, где хранятся данные.
Минимизируйте cross-region репликацию: она удваивает стоимость хранения и генерирует дополнительный трафик.
Рассмотрите Cloudflare R2: не взимает плату за egress вообще. Для публичного контента это может дать серьёзную экономию.

Зарезервированная ёмкость и скидки за обязательства

Если объём хранения более-менее предсказуем, есть смысл посмотреть на скидки за долгосрочные обязательства:

Azure Reserved Capacity — скидки при фиксации объёма (шаг: 100 ТБ или 1 ПБ) на 1 или 3 года.
AWS S3 Storage Lens + Savings Plans — Savings Plans в первую очередь покрывают compute, но Storage Lens помогает выявлять паттерны хранения и находить возможности для оптимизации.
GCP Committed Use Discounts — модель на основе расходов, а не фиксированных ресурсов. Экономия может достигать 70%.

Охота на «зомби-ресурсы»: удаление забытых данных

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

Незавершённые multipart-загрузки — S3 хранит фрагменты незавершённых загрузок бессрочно. Да, бессрочно. Настройте правило Lifecycle для их автоматического удаления.
Старые версии объектов — если включено версионирование, каждое обновление файла сохраняет предыдущую копию. Это полезная функция, но без Lifecycle-правил количество версий растёт бесконтрольно.
Неиспользуемые снапшоты — снимки EBS-дисков, Azure-дисков и GCE-дисков часто остаются после удаления экземпляров.
Тестовые бакеты — данные из dev/test-окружений, которые создали «на пять минут» и забыли очистить на полгода.

Пример правила для очистки незавершённых multipart-загрузок в S3:

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-bucket \
  --lifecycle-configuration file://cleanup.json

Содержимое cleanup.json:

{
  "Rules": [{
    "ID": "CleanupIncompleteUploads",
    "Status": "Enabled",
    "Filter": {},
    "AbortIncompleteMultipartUpload": {
      "DaysAfterInitiation": 7
    }
  }]
}

Мониторинг и аналитика: нет видимости — нет экономии

Оптимизировать то, что не измеряешь, невозможно. Вот инструменты, которые стоит настроить:

AWS S3 Storage Lens — панель с метриками по всем бакетам: общий объём, распределение по классам, тренды роста, доля данных без обращений.
Azure Storage Analytics + Cost Management — детализация затрат по контейнерам, уровням доступа и операциям.
GCP Storage Insights — отчёты по бакетам с рекомендациями по оптимизации классов хранения.

И обязательно настройте алерты на аномальный рост объёма или количества запросов. Лучше получить ложное срабатывание, чем неожиданный счёт в конце месяца.

Чек-лист оптимизации хранилища на 2026 год

Проведите аудит текущего распределения данных по классам хранения — найдите данные, которые хранятся в слишком дорогом тире.
Включите S3 Intelligent-Tiering или GCS Autoclass для бакетов с непредсказуемыми паттернами доступа.
Настройте Lifecycle-политики для логов, бэкапов и архивных данных с чёткими сроками хранения.
Добавьте правило автоматического удаления незавершённых multipart-загрузок (7 дней).
Ограничьте версионирование: настройте удаление старых версий объектов через Lifecycle.
Проанализируйте расходы на egress и минимизируйте cross-region трафик.
Оцените зарезервированную ёмкость, если нагрузка предсказуема.
Настройте мониторинг и алерты на аномальный рост затрат.

Часто задаваемые вопросы

Что выгоднее — S3 Intelligent-Tiering или Lifecycle-политики?

Зависит от предсказуемости паттернов доступа. Для данных с непредсказуемым доступом (пользовательский контент, аналитика) Intelligent-Tiering экономит до 68% без ручного управления. Для данных с чётким жизненным циклом (логи, бэкапы) Lifecycle-политики эффективнее — можно сразу переместить данные в самый дешёвый тир без платы за мониторинг. На практике лучше всего работает комбинация обоих подходов.

Как снизить расходы на исходящий трафик из облачного хранилища?

Основные методы: CDN для раздачи контента конечным пользователям, размещение compute в том же регионе, что и хранилище, минимизация cross-region репликации. Если объёмы большие — стоит посмотреть на Cloudflare R2, который не берёт плату за egress. При объёмах от 100 ТБ/мес расходы на egress легко превышают $8 000.

Чем GCS Autoclass отличается от S3 Intelligent-Tiering?

Оба механизма автоматически перемещают данные между уровнями на основе паттернов доступа. Ключевые отличия: GCS Autoclass не ограничивает минимальный размер объекта (S3 IT игнорирует объекты меньше 128 КБ), не берёт плату за мониторинг и работает со всеми четырьмя классами GCS. S3 Intelligent-Tiering зато предлагает более глубокие архивные уровни и лучше интегрирован с экосистемой AWS.

Какой класс хранения самый дешёвый для долгосрочных архивов?

S3 Glacier Deep Archive — $0,00099/ГБ — остаётся самым дешёвым среди трёх провайдеров. GCS Archive стоит $0,0012/ГБ, Azure Archive — $0,002/ГБ. Но не забывайте про стоимость извлечения: восстановление из Deep Archive занимает до 12 часов и обходится в $0,02/ГБ.

Как обнаружить забытые и неиспользуемые данные в облачном хранилище?

Начните с встроенных инструментов: AWS S3 Storage Lens покажет метрики доступа по всем бакетам, Azure Storage Analytics детализирует операции, GCP Storage Insights выдаст рекомендации. Отдельно проверьте незавершённые multipart-загрузки, старые версии объектов (если включено версионирование) и неиспользуемые снапшоты дисков — именно они чаще всего оказываются теми самыми «зомби».