Как сократить расходы на облако: практические советы

Короткий ответ

Расходы на облако снижаются в определенном порядке — от простого и безопасного к требующему обязательств:

1. Видимость: теги и отчеты, чтобы понимать, кто и на что тратит.
2. Уборка: удаление и остановка того, что не используется.
3. Rightsizing: размер ресурсов по реальной нагрузке.
4. Модель оплаты: резервирование для постоянной нагрузки, spot для прерываемой.
5. Хранилище: правила жизненного цикла и сроки хранения логов.

Если начать с резервирования, можно на годы закрепить оплату ресурсов, которые потом окажутся лишними.

Видимость: теги

Без тегов счет — это список сервисов, а не ответ на вопрос «какой проект дорожает». Договоритесь о минимальном наборе:

• project — продукт или клиент;
• env — production, staging, dev;
• owner — команда или ответственный.

В AWS теги нужно активировать как cost allocation tags в разделе Billing, после этого по ним можно группировать расходы в Cost Explorer. Ресурсы без тегов — первый кандидат на проверку: часто это забытые эксперименты. Чтобы правила соблюдались, используйте tag policies и проверку тегов в инфраструктурном коде.

Уборка простаивающих ресурсов

Пройдитесь по чек-листу хотя бы раз в месяц:

• диски EBS, не подключенные ни к одному инстансу;
• старые снапшоты и образы, которые никто не использует;
• неиспользуемые публичные IP-адреса;
• load balancer без целевых серверов;
• остановленные инстансы: за них не платят по часам, но диски продолжают тарифицироваться;
• тестовые окружения, которые работают ночью и в выходные.

Dev- и staging-окружения удобно выключать по расписанию — через планировщик провайдера или простую задачу по cron. Если окружение не нужно неделями, его лучше удалить и пересоздавать из кода.

Rightsizing: размер по нагрузке

Инстансы часто выбирают «с запасом» и потом не пересматривают. Посмотрите загрузку CPU, памяти и сети за несколько недель, включая пиковые дни. Если ресурс стабильно загружен слабо, уменьшите его размер.

Что помогает:

• рекомендации AWS Compute Optimizer или аналогов у других провайдеров;
• переход на новые поколения инстансов и архитектуру ARM, если софт ее поддерживает;
• автомасштабирование вместо постоянно включенного запаса под пик.

Модель оплаты

У Google Cloud и Azure есть аналоги: committed use discounts, reservations и spot VM. Правило одно: резервируйте только гарантированный минимум нагрузки, а пики покрывайте on-demand или spot.

Хранилище и логи

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

{
  "Rules": [
    {
      "ID": "logs-archive",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

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

Сроки подберите под свои требования. Учтите, что у «холодных» классов есть плата за извлечение и минимальный срок хранения. И задайте retention для всех лог-групп: бессрочные логи — частая скрытая статья расходов.

Частые ошибки

• Покупать резервирование до того, как размер ресурсов приведен в порядок.
• Запускать на spot то, что не переживает внезапной остановки.
• Удалять ресурсы без тегов, не выяснив владельца.
• Оптимизировать один раз и не повторять проверку.