Infracost — оценка стоимости
Тема дорожной карты · Terraform
Управление затратами с Terraform — это дисциплина использования IaC-инструментов и практик для понимания, прогнозирования и контроля расходов на облако в AWS, Azure и GCP до, во время и после запусков terraform apply. Основной инструмент управления затратами с Terraform — Infracost, интегрирующийся в конвейеры GitHub Actions, GitLab CI и Atlantis для парсинга JSON-вывода terraform plan и публикации детальной разбивки затрат по ресурсам как комментария к PR — предоставляя ревьюерам diff затрат вместе с diff инфраструктуры до одобрения любых расходов. Инженеры практикуют управление затратами с Terraform путём выбора правильного размера ресурсов через variable-управляемые карты типов инстансов в tfvars, использования terraform destroy (или запланированного terraform apply с count = 0) для сноса эфемерных окружений вне рабочих часов и разметки всех ресурсов картами local.common_tags с метками cost-center и environment для атрибуции в облачных биллинговых отчётах. Функция оценки стоимости Terraform Cloud предоставляет нативное прогнозирование расходов прямо на страницах запусков воркспейсов, а политики OPA и Sentinel могут жёстко блокировать terraform apply, если план превышает определённый месячный бюджетный порог. Сочетание проверок tflint для пометки чрезмерно ресурсоёмких конфигураций, gates Infracost в PR и применения разметки через Checkov даёт командам многоуровневую стратегию управления затратами с Terraform, масштабируемую от проектов одной команды до корпоративных мультиаккаунтных развёртываний.
Как это работает
Infracost — оценка стоимости покрывает операционную гигиену: remote state с локингом + versioning, per-environment разделение, секреты вне git, CI/CD с PR-plan + ручным гейтом для prod, drift-detection по расписанию, policy-as-code гейты, версионирование модулей + приватный module registry, observability terraform apply-операций (логи, аудит), DR (бекапы state, runbook отката). Относитесь к Terraform-изменениям с той же осторожностью, что и к релизам приложения.
Когда применять
Применяйте эти практики с первого дня — ретрофит потом болезненный. Политика "destroy табу": production-ресурсы имеют prevent_destroy = true; удаление prod требует снятия флага, ревью PR, одобрения apply. Drift-detection еженочно — ручные изменения ловятся. Тренируйте recovery state на staging до нужды на prod.
Типичные ошибки
Ловушки Infracost — оценка стоимости: нет бекапа state, потом коррумпированный state = дни ручной сверки; нет prevent_destroy на БД; apply с ноута в production (нет аудита); пропуск staging-среды ("это же просто конфиг, заработает"). Production-дисциплина не вытекает из добрых намерений — нужны гейты.