Чекліст деплою на AWS, частина 2 — витрати, бюджети і billing hygiene

Додаток задеплоєний. Health check зелений. Load balancer відповідає. База піднялась. DNS переключився, клієнти не пишуть у паніці.

Значить, деплой успішний?

Ще ні.

Для українських компаній AWS часто починається як переїзд із VPS: Hetzner, DigitalOcean, HOSTiQ, HostPro, сервер “який колись налаштували”. На VPS витрати прості: $12, $24 або $50 на місяць. Подобається чи ні — сума фіксована.

В AWS так не працює.

Тут маленька помилка може коштувати грошей щогодини. Staging не вимкнули. NAT Gateway поставили “на всяк випадок”. CloudWatch зберігає все без retention. Хтось запустив інстанс у не тому регіоні. Через три тижні приходить інвойс — і команда починає згадувати, що саме вона деплоїла.

У першій частині чекліста ми говорили про безпечний запуск системи на AWS. Ця частина — про те, як не отримати cloud bill, який ніхто не може пояснити.

Бо на AWS “працює” — замало.

Система має працювати, бути спостережуваною і залишатися в межах бюджету, який бізнес реально готовий платити.

Billing — це не бухгалтерія після факту

Поганий план звучить так: “Подивимось на інвойс в кінці місяця”.

До кінця місяця AWS уже все порахує.

Розробник підніме тестову RDS-базу і забуде. Логи полетять у CloudWatch без обмежень. Sandbox буде працювати всі вихідні. NAT Gateway стоятиме там, де можна було обійтися VPC Endpoints. А в Cost Explorer раптом з’явиться сервіс, про який ніхто не пам’ятає.

Бухгалтерія побачить суму. Але вона не пояснить, чи цей RDS був потрібний, чи випадковий. Не скаже, який log group росте занадто швидко. Не відрізнить production load balancer від тестового, який мав жити один день.

Тому billing hygiene — це частина деплою. Не задача на “потім”. Не прибирання раз на квартал. Не реакція після болючого інвойсу.

Правило просте:

Якщо ресурс може витрачати гроші, він має мати власника, теги і alert.

1. Створи AWS Budgets до запуску

AWS Budgets треба налаштувати до production launch. Не після першого інвойсу.

Для типової української компанії, яка переходить із VPS або хостингу на AWS, варто почати з трьох рівнів.

Бюджет акаунта. Скільки цей AWS-акаунт має коштувати на місяць? $100? $300? $800? Не треба вгадати ідеально. Треба мати число, з яким погодився бізнес.

Бюджети по сервісах. Окремо дивись на те, що найчастіше дивує: EC2, RDS, NAT Gateway, CloudWatch, data transfer, OpenSearch, GPU. Якщо архітектура serverless — Lambda, API Gateway, DynamoDB і CloudWatch теж окремо.

Бюджети по середовищах. Production, staging, dev, sandbox. Якщо все поки в одному акаунті — розділяй тегами. Якщо є можливість — краще рознести по акаунтах через AWS Organizations.

Практична схема alert-ів:

50% бюджету — heads-up
80% — перевірити
100% — прийняти рішення
120% — ескалація

Не відправляй ці alert-и одній людині.

Мінімум — спільна пошта або Slack/Teams-канал. Alert має бачити той, хто деплоїв workload, той, хто відповідає за AWS, і той, хто відповідає за бюджет.

Alert, який ніхто не читає, — це не контроль витрат. Це декорація.

2. Увімкни Cost Anomaly Detection

Бюджет ловить перевищення очікуваної суми.

Cost Anomaly Detection ловить дивні патерни.

Це різні речі.

Приклади: Lambda починає retry’итись кожні кілька секунд. Тестовий скрипт заливає мільйони файлів у S3. Debug logging випадково залишається в production. Staging-базу “на годинку” апгрейдять до великого інстансу і забувають. Хтось запускає ресурси в регіоні, який ніхто не моніторить.

Бюджет може спрацювати пізно. Аномалія — раніше.

Мінімальний setup:

monitor для всього AWS-акаунта;
окремий monitor для production;
monitor для ризикових сервісів: RDS, EC2, NAT Gateway, CloudWatch, data transfer, OpenSearch, Bedrock, GPU instances;
нижчий поріг для sandbox і dev.

Для українських команд це особливо важливо, бо багато хто приходить в AWS із ментальної моделі VPS: “сервер коштує фіксовано, рахунок не зміниться”. В AWS рахунок зміниться, якщо зміниться використання.

Тому AWS має повідомити, що щось пішло не так.

Не через три тижні. Сьогодні.

3. Тегай ресурси так, щоб їх можна було пояснити

У кожному AWS cost review є момент, коли хтось питає:

“А що це таке?”

Потім команда відкриває консоль, клікає по ресурсах, дивиться дати створення, назви, регіони, security groups і намагається згадати, хто це підняв.

Це поганий спосіб керувати витратами.

Кожен ресурс, який можна тегати, має отримати базові теги:

tags = {
  Environment = "production"
  Project     = "client-portal"
  Owner       = "backend"
  ManagedBy   = "terraform"
  CostCenter  = "engineering"
}

Малій команді не потрібна складна enterprise-схема тегів. Потрібно, щоб теги відповідали на прості питання:

Хто власник ресурсу? Для якого він проєкту? Це production, staging чи test? Це створено Terraform-ом чи руками? Це можна видалити?

Cost allocation tags треба активувати в Billing and Cost Management. Просто додати тег на ресурс недостатньо — для cost reports його ще треба увімкнути.

Базовий стандарт можна закласти прямо в Terraform:

variable "default_tags" {
  type = map(string)
  default = {
    Environment = "production"
    ManagedBy   = "terraform"
    Company     = "example-company"
  }
}

А далі додавати ownership на рівні модуля:

module "api" {
  source = "./modules/ecs-service"

  name = "client-portal-api"

  tags = merge(var.default_tags, {
    Project = "client-portal"
    Owner   = "backend"
  })
}

Без тегів ти не контролюєш billing. Ти просто дивишся на суму.

4. Відділи production від staging і sandbox

На старті один AWS-акаунт здається нормальним. Менше налаштувань, один bill, усі все бачать.

Потім production, staging, dev і експерименти перемішуються. Хтось пробує OpenSearch. Хтось запускає EC2 “на день”. Хтось тестує RDS. Хтось робить PoC і забуває прибрати. Через пів року ніхто не знає, що критичне, а що можна видалити.

Нормальний setup для невеликої компанії:

Management account — billing, AWS Organizations, без workload-ів. Production account — реальні системи для клієнтів. Staging account — перевірка перед production. Sandbox account — експерименти, PoC, short-lived ресурси.

Це не обов’язково має бути складний enterprise landing zone. Але production не має жити поруч із експериментами в одному кошику.

Бюджети теж мають бути різні:

production: alert на 80%, escalation на 100%;
staging: alert на 50%, investigate на 80%;
sandbox: alert на 30%, блокування ризикових сервісів на 80%.

Sandbox має бути місцем, де можна швидко пробувати. Але помилка в sandbox не повинна ставати проблемою для всього бізнесу.

5. Обмеж регіони і дорогі сервіси

Для більшості українських компаній базовий AWS-регіон — eu-central-1, Франкфурт. Це найближчий повний регіон AWS в ЄС, нормальна latency до України, широкий набір сервісів і зрозумілий вибір для роботи з європейськими клієнтами.

Якщо потрібен резервний регіон — часто дивляться на Ірландію (eu-west-1) або Стокгольм (eu-north-1). Але випадкові ресурси в США, Сінгапурі чи Австралії — майже ніколи не те, що хотіла компанія.

Тому регіони варто обмежити.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "route53:*",
        "cloudfront:*",
        "support:*",
        "budgets:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "eu-central-1",
            "eu-west-1",
            "eu-north-1"
          ]
        }
      }
    }
  ]
}

Ця policy не виглядає цікаво. Зате вона не дасть випадково створити інфраструктуру там, де її ніхто не очікує.

Інші корисні guardrails:

заборонити GPU instances без погодження;
заборонити великі RDS classes у staging і sandbox;
заборонити public IP там, де workload приватний;
вимагати теги при створенні ресурсів;
обмежити створення NAT Gateway;
заблокувати дорогі сервіси в sandbox.

Не треба починати з десятків політик. Почни з тих помилок, які можуть зробити найбільший рахунок.

6. CloudWatch — не безкоштовна папка з логами

На VPS логи часто сприймаються як файли на диску. Є місце — пишемо. Закінчиться місце — почистимо.

На AWS це погана звичка.

CloudWatch бере участь у рахунку. Логи, метрики, retention, custom metrics, dashboards — усе це може коштувати. Якщо production почне писати debug payload-и на кожен request, проблема буде не тільки в шумі. Вона буде в інвойсі.

Перед деплоєм виріши:

Що логувати? Errors, security events, deployment events, slow requests, payments, authentication events.

Що не логувати? Full request bodies, персональні дані, tokens, великі payload-и, шумні health checks, кожен успішний background job.

Скільки тримати? Для більшості SMB-систем 14, 30 або 90 днів достатньо. “Never expire” — поганий default.

Приклад:

resource "aws_cloudwatch_log_group" "api" {
  name              = "/ecs/client-portal-api"
  retention_in_days = 30

  tags = {
    Environment = "production"
    Project     = "client-portal"
    ManagedBy   = "terraform"
  }
}

Якщо потрібне довге зберігання — відправляй вибрані логи в S3 і став lifecycle rules. Hot logs тримай коротко. Архівуй важливе. Решту видаляй.

Для українських бізнесів, які працюють із клієнтами з ЄС, це ще й питання GDPR. Логи не мають ставати смітником для персональних даних.

7. Перевір cost traps до go-live

Очевидні витрати видно одразу: ECS, RDS, S3, Lambda, load balancer.

Несподівані витрати зазвичай сидять збоку.

NAT Gateway. Дуже часта пастка. Потрібен не завжди, коштує постійно. Якщо приватним ресурсам потрібен доступ тільки до S3 або DynamoDB — перевір VPC Endpoints.

CloudWatch. Логи, метрики, alarms, dashboards. По одному небагато. У сумі — відчутно.

Data transfer. Між регіонами, між AZ, через NAT, назовні в інтернет. На схемі це просто стрілка. В AWS bill — гроші.

RDS. Storage росте, backups накопичуються, Multi-AZ збільшує ціну, read replica не безкоштовна.

Load balancers. Один ALB для кількох малих сервісів може бути ок. Окремий ALB на кожну дрібницю — часто зайва витрата.

Покинуті ресурси. EBS volumes, snapshots, AMI, unattached IPs, старі test DB, unused log groups.

Перед запуском зроби просту таблицю:

Компонент	Очікувана місячна вартість	Власник	Нотатки
ECS Fargate	$60–100	Backend	Production API
RDS PostgreSQL	$80–150	Backend	Single-AZ на старт
ALB	~$25	Platform	Спільний для API
NAT Gateway	$35+	Platform	Перевірити VPC Endpoints
CloudWatch	$15–50	Platform	Retention 30 днів
S3 + CloudFront	$10–30	Frontend	Static assets
Разом	~$225–390	CTO	Додати 15–20% буферу

Це не має бути ідеальна фінансова модель. Це точка порівняння.

Якщо очікуєш $300, а forecast через тиждень показує $700 — треба дивитися зараз, а не після інвойсу.

8. Вмикай Cost and Usage Reports, коли з’являється складність

Cost Explorer вистачить на старті. Там видно сервіси, регіони, daily spend і загальний тренд.

Але якщо у тебе кілька акаунтів, кілька проєктів або треба рахувати витрати по клієнтах — вмикай Cost and Usage Reports.

CUR складає детальні cost data в S3. Потім це можна аналізувати через Athena, QuickSight або власні скрипти. Для маленької команди це може звучати як overkill. Але коли bill росте, історія стає дуже корисною.

Питання “чому в червні стало дорожче, ніж у травні?” не вирішується пам’яттю. Воно вирішується даними.

Якщо використовуєш ECS або EKS у помітному масштабі, подивись split cost allocation data. Shared cluster без нормального розподілу витрат швидко стає чорною скринькою.

9. Перший інвойс — це deployment retrospective

Перший повний AWS invoice після запуску треба розібрати технічно.

Не просто оплатити.

Відкрий Cost Explorer. Порівняй expected vs actual. Подивись service breakdown, daily spend, regions, accounts, tags і untagged resources.

Питання прості:

Що коштувало більше, ніж очікували? Що коштувало менше? Які ресурси без owner? Які сервіси з’явилися, хоча їх не було в плані? Чи staging коштує занадто багато? Чи CloudWatch росте швидше, ніж треба? Чи backups накопичуються? Чи data transfer зрозумілий? Що можна видалити зараз?

Такий review майже завжди щось знаходить.

RDS на клас завеликий. NAT Gateway, який поставили автоматично. Log group без retention. EC2 instance після міграції. Staging, що працює 24/7, хоча ним користуються двічі на тиждень.

Виправити це після першого місяця — нормально.

Ігнорувати рік — дорого.

Чекліст перед production launch

Перед запуском перевір:

AWS Budgets налаштовані для акаунта, сервісів і середовищ.
Budget alerts ідуть у спільний канал.
Cost Anomaly Detection увімкнений.
Cost allocation tags визначені, застосовані й активовані.
Production відділений від staging і sandbox.
Регіони обмежені до тих, які компанія реально використовує.
Дорогі сервіси заблоковані там, де вони не потрібні.
CloudWatch Logs мають explicit retention.
CloudTrail налаштований свідомо.
NAT Gateway перевірений на необхідність.
RDS size, storage і backup retention мають пояснення.
Очікувана місячна вартість записана.
Є owner витрат.
Review першого інвойсу запланований.

Якщо це не відмічено — деплой не завершений.

Він може бути live. Він може працювати. Але операційно він не готовий.

Як виглядає здоровий billing setup

Не потрібна окрема FinOps-команда.

Для більшості українських компаній достатньо, щоб бюджети були налаштовані, alert-и доходили до людей, кожен ресурс мав owner, production був відділений від експериментів, регіони були обмежені, логи мали retention, а перший invoice хтось технічно розібрав.

Це не бюрократія. Це базова гігієна.

AWS стає дорогим не через одну велику помилку. Найчастіше — через дрібні витоки, які ніхто не закрив.

Тестова база. Забутий volume. Логи без retention. NAT Gateway “про всяк випадок”. Sandbox, який працював усі вихідні. Інвойс, який просто оплатили.

Cost guardrails не сповільнюють команду.

Вони дають бізнесу можливість користуватися AWS без страху, що наступний рахунок стане сюрпризом.

В Otocolobus ми аудимо AWS-середовища саме на такі проблеми — незрозуміле ownership ресурсів, відсутні cost guardrails, шумні логи, надто широкі permissions, забуту інфраструктуру і billing-сюрпризи, які видно тільки після інвойсу.

Якщо хочеш зрозуміти, де твій AWS непомітно витрачає гроші, перш ніж це покаже наступний рахунок — напиши нам.