Калькулятор вартості AWS: як оцінити витрати на хмару (з прикладами з реальних проєктів)

«Скільки нам коштуватиме AWS?» — перше запитання, яке задає кожна компанія перед переїздом у хмару. І водночас — найскладніше для чесної відповіді. В AWS понад 200 сервісів, кожен зі своєю моделлю ціноутворення, а офіційні прайси читаються як договір страхування.

Хороша новина: розбиратися у всіх не потрібно. Існує Калькулятор Цін AWS, і з правильними вхідними даними можна отримати адекватну місячну оцінку за 20 хвилин.

В Otocolobus ми будуємо інфраструктуру на AWS для десятків компаній МСБ. У цій статті проведемо вас через калькулятор крок за кроком на трьох реальних сценаріях із наших проєктів — із справжніми цифрами, а не вигаданими.

Калькулятор AWS: з чого почати

Заходьте на calculator.aws. Інтерфейс простий: додаєте сервіси один за одним, налаштовуєте під очікуване навантаження, калькулятор видає місячну оцінку.

Перш ніж клікати, кілька речей, які варто знати:

Оберіть регіон на старті. Для компаній, що працюють із європейськими клієнтами, стандарт — eu-central-1 (Франкфурт). Ціни відрізняються між регіонами — Франкфурт трохи дорожчий за американські, але дані залишаються в ЄС, що важливо для GDPR-комплаєнсу. Якщо ваші клієнти переважно в Україні та регіоні, Франкфурт все одно оптимальний за співвідношенням ціна/затримка.

Рахуйте консервативно, а потім додайте 15–20%. Калькулятор показує вартість сервісів, які ви сконфігурували. Він не враховує трансфер даних між сервісами, логування в CloudWatch та десятки дрібних витрат, що накопичуються. Ми завжди додаємо 15–20% буферу на ці речі.

Фокусуйтесь на великих позиціях. У більшості проєктів МСБ 80% рахунку генерують три-чотири сервіси. Точно оціните їх — решта буде похибкою округлення.

Сценарій 1: Сайт компанії (статичний або майже статичний)

Найпростіший і найдешевший варіант на AWS — і саме той, який більшості малих компаній реально потрібен. Корпоративний сайт, лендінг, маркетингова сторінка. Жодного сервера, що крутиться 24/7, жодної бази даних. Просто файли, що швидко віддаються.

Що потрібно:

S3 — хостинг HTML, CSS, JS та зображень
CloudFront — CDN для швидкої роздачі та HTTPS
Route 53 — DNS

Покроково в калькуляторі:

1. S3. Додайте S3:

1 GB у класі Standard (більшість корпоративних сайтів — це дріб'язок від цього)
100 000 GET-запитів/місяць, 10 000 PUT-запитів/місяць (деплой)
При такому масштабі S3 коштує копійки — буквально кілька центів

2. CloudFront. Додайте CloudFront:

50 GB вихідного трафіку на місяць
500 000 HTTPS-запитів/місяць
Цього з запасом вистачить для сайту з кількома тисячами відвідувань на день

3. Route 53. Додайте Route 53:

1 hosted zone (~$0,50/місяць)
500 000 DNS-запитів/місяць (~$0,20)

Що показує калькулятор: ~$5–8/місяць

Що ми бачимо в рахунках клієнтів: $8–15/місяць. Сюрпризів тут майже не буває — у цьому й краса статичного хостингу. Невелика різниця — це CloudWatch-аларми (якщо їх налаштувати), трохи більший трафік і рідкісні сплески після публікації в соцмережах чи розсилки.

Це на порядок дешевше, ніж той самий сайт на VPS чи в контейнері. Якщо вашому корпоративному сайту не потрібна база даних чи серверна логіка — не платіть за них.

Сценарій 2: API для B2B SaaS (спорадичне навантаження, масштабування до нуля)

Ця архітектура має сенс, коли ваші користувачі — бізнеси, а не споживачі. Навантаження прив'язане до робочих годин — ранок в одному часовому поясі, обід в іншому, тиша вночі, мертво у вихідні. Немає сенсу платити за сервер, що 70% часу простоює.

Що потрібно:

Lambda — логіка API
API Gateway — щоб відкрити API клієнтам
DynamoDB — база даних (режим on-demand, оплата за запит)
S3 — файли
CloudFront — якщо віддаєте статичний контент

Покроково в калькуляторі:

1. Lambda. Додайте Lambda:

500 000 запитів/місяць (розумна стартова точка для B2B-продукту з ~50 активними тенантами)
Середній час виконання: 200 мс
Пам'ять: 256 MB
Безкоштовний рівень Lambda покриває мільйон запитів/місяць — спочатку можете не платити тут нічого

2. API Gateway. Додайте API Gateway (HTTP API — дешевший за REST API):

500 000 API-викликів/місяць
Середній розмір повідомлення: 3 KB

3. DynamoDB. Додайте DynamoDB в режимі on-demand:

500 000 одиниць запису/місяць
2 000 000 одиниць читання/місяць (читань зазвичай набагато більше, ніж записів)
5 GB сховища

4. S3. Додайте S3 для файлів:

10 GB у класі Standard
50 000 GET-запитів/місяць

Що показує калькулятор: ~$8–20/місяць

Що ми бачимо в реальності: $15–40/місяць. Serverless-архітектури мають меншу розбіжність між оцінкою та дійсністю, бо ви не платите за ресурси, що простоюють. Найбільший сюрприз — зазвичай API Gateway: при високих обсягах він може коштувати дорожче за саму Lambda.

Чому не ECS? При спорадичному B2B-навантаженні платити за контейнер, що крутиться 24/7, безглуздо. Lambda масштабується до нуля: немає активних тенантів — немає витрат. На ECS Fargate ви платитимете мінімум ~$20/місяць за один таск, який увечері та у вихідні не робить нічого. При такому масштабі це подвоєння рахунку без жодної користі.

Сценарій 3: B2C-інтернет-магазин (передбачуваний трафік, always on)

Зовсім інший патерн, ніж B2B: споживачі купують увечері, гортають у обідню перерву, а в дні розпродажів трафік злітає. Навантаження більш передбачуване й стабільне — ви бачите, коли користувачі активні. Контейнери, що працюють постійно, тут мають більше сенсу, ніж оплата за кожен запит, а Lambda бере на себе фонову роботу: обробку замовлень, сповіщення, оновлення залишків.

Що потрібно:

ECS Fargate — веб-додаток (always on)
RDS PostgreSQL — реляційна база для товарів, замовлень, користувачів
Lambda — асинхронна обробка (події замовлень, сповіщення)
S3 — фото товарів, аплоади користувачів
CloudFront — CDN для зображень і статичних ресурсів
Application Load Balancer — маршрутизація трафіку до контейнерів
SES — транзакційні листи (підтвердження замовлень, оновлення доставки)

Покроково в калькуляторі:

1. ECS Fargate. Цього разу — always on, із запасом під трафік:

2 таски 24/7 (резервування — якщо один впаде, другий продовжує обслуговувати)
1 vCPU, 2 GB пам'яті на таск
Цього вистачає для кількох тисяч активних користувачів на день

2. RDS PostgreSQL. Додайте RDS:

db.t4g.small (2 vCPU, 2 GB RAM)
50 GB сховища з gp3
Single-AZ поки що (Multi-AZ — коли доходи це виправдають)

3. Lambda. Асинхронна обробка:

200 000 викликів/місяць (події замовлень, email-тригери, синхронізація складу)
Середній час: 300 мс
Пам'ять: 256 MB

4. S3 + CloudFront. Фото товарів і статика:

20 GB сховища S3
100 GB вихідного трафіку CloudFront/місяць
1 000 000 HTTPS-запитів/місяць

5. Application Load Balancer. Додайте ALB:

1 ALB 24/7
10 LCU — розумна середня для помірного e-commerce трафіку

6. SES. Транзакційні листи:

10 000 листів/місяць (~$1)

Що показує калькулятор: ~$130–180/місяць

Що ми бачимо в реальності: $200–280/місяць. На цьому рівні приховані витрати починають накопичуватись: NAT Gateway (~~$38/місяць), логування CloudWatch (~~$15–25/місяць), трансфер між зонами доступності та Route 53. Різниця між калькулятором і дійсністю тут більша, ніж у serverless-варіантах, бо більше компонентів працює постійно й генерує фонові витрати.

Цінові пастки, про які ніхто не попереджає

Калькулятор непогано справляється з очевидними сервісами. Ось чого він систематично не дораховує або взагалі пропускає:

NAT Gateway — тихий вбивця бюджету. Якщо ваші Fargate-таски або Lambda-функції працюють у приватній підмережі (а вони мають — з міркувань безпеки), їм потрібен NAT Gateway для доступу в інтернет. У регіоні Франкфурт NAT Gateway коштує ~$38/місяць просто за факт існування ($0,052/годину), плюс ~$0,052 за кожен GB оброблених даних. Для невеликого додатку з помірною кількістю зовнішніх API-викликів це легко виливається в $45–75/місяць — часто більше, ніж сам compute.

Як зменшити: Використовуйте VPC endpoints для AWS-сервісів (S3, DynamoDB, ECR). Вони дешевші й не навантажують NAT Gateway. Gateway endpoints (для S3 та DynamoDB) — безкоштовні.

Трансфер даних між зонами доступності. Якщо ваш ECS-таск у eu-central-1a, а RDS-інстанс у eu-central-1b, кожен байт між ними коштує $0,01/GB у кожну сторону. Копійки на один запит, але в масштабі набігає.

CloudWatch Logs ingestion. Кожен рядок логу коштує грошей за ingestion і зберігання. Надто детальне логування на продакшні може додати $20–50/місяць непомітно. Встановіть політику ретенції логів (14 або 30 днів) і не логуйте тіла запитів/відповідей у продакшні.

Публічні IPv4-адреси. З лютого 2024 року AWS бере $0,005/годину за кожну публічну IPv4-адресу — байдуже, прив'язана вона до працюючого ресурсу чи просто лежить. Це ~$3,60/місяць за адресу. Стосується всіх сервісів: EC2-інстансів, ALB, NAT Gateway, RDS — кожен із публічним IP додає до рахунку. «Осиротілі» Elastic IP — це очевидна втрата (ми регулярно знаходимо 3–5 на клієнтський акаунт), але тепер навіть ті, що активно використовуються, коштують гроші. Це ще один привід подумати про IPv6 там, де ваш стек це підтримує.

ECR storage. Кожен Docker-образ, завантажений в ECR, лишається там назавжди, якщо ви не налаштували lifecycle policies. Через рік деплоїв можна назбирати сотні старих образів, які коштують кілька доларів на місяць — не катастрофа, але зайві гроші.

Із реального проєкту: PaaS vs AWS Lambda vs власний сервер

Не завжди йдеться про те, щоб витягти когось з цінової ями. Іноді достатньо порахувати наперед — і просто в неї не потрапити.

До нас звернувся B2B SaaS-клієнт із multi-tenant додатком на популярному PaaS. React на фронті, Python-бекенд на serverless-функціях, managed Postgres з окремою базою під кожного кінцевого клієнта. При десяти тенантах рахунок виглядав нормально — десь £90/місяць. Але вони готувалися рости і хотіли зрозуміти, у що це виллється при 100, 500 і 1 000 клієнтах, перш ніж остаточно зав'язуватися на одну платформу.

Ми порівняли три варіанти: залишитися на поточному PaaS, переїхати на AWS Lambda або підняти контейнери в класичного провайдера на VPS чи виділених серверах.

Що показав аналіз:

При 10 тенантах — різниці практично нема, скрізь £55–90/місяць. Розбіжності починаються тільки з масштабом:

Масштаб	Поточний PaaS	AWS Lambda	VPS / Виділений
10 тенантів	~£90/міс.	~£55/міс.	~£90/міс.
100 тенантів	~£315/міс.	~£280/міс.	~£470/міс.
500 тенантів	~£2600+/міс.	~£990/міс.	~£1 150/міс.
1000 тенантів	~£4600+/міс.	~£1 700/міс.	~£1 900/міс.

PaaS б'є в стіну десь при 500 тенантах — саме тоді вмикається їхній Enterprise-план і ціна стрибає. Lambda виходить найдешевше на кожному рівні вище безкоштовного, бо платиш тільки за реальні виклики, а в решту часу вона масштабується до нуля. VPS — конкурентний варіант, що не прив'язує до жодного вендора, але фіксовані серверні витрати роблять його дорожчим за Lambda в діапазоні 100–500 тенантів.

Найбільша стаття витрат — база даних, а не compute. При 1 000 тенантах сам managed Postgres коштував би дорожче, ніж обчислювальна платформа в будь-якому з варіантів. На шляху VPS перехід на self-hosted Postgres різко знижує загальний рахунок. Найбільшу економію дало рішення про базу даних, а не про те, де крутиться код.

Наша рекомендація: Поки що залишайтесь там, де є — нуль операційного навантаження, швидка ітерація, на цьому етапі це виправдано. Але збирайте метрики використання, щоб рішення про переїзд спиралось на реальні цифри, а не на інтуїцію. Коли прийде час — переїжджайте на AWS Lambda.

Весь аналіз зайняв кілька днів. Він вберіг клієнта і від передчасної міграції (даремна витрата інженерного часу), і від запізнілої (удар у поріг кількох тисяч фунтів, якого вони не бачили наперед). Таку роботу жоден калькулятор за вас не зробить.

Як використовувати калькулятор ефективно

Після того, як ми провели через цей процес десятки клієнтів, ось наш алгоритм:

Починайте з одного сценарію, а не з усієї інфраструктури. Оцініть спершу найважливіше навантаження. Точно підгоніть його, а потім додавайте решту.

Використовуйте функцію «поділитися». Калькулятор дозволяє експортувати оцінки та ділитися ними через посилання. Надішліть команді на перегляд, перш ніж ухвалювати рішення. Ми надсилаємо такі оцінки кожному клієнту як частину нашої архітектурної пропозиції.

Звіряйте щомісяця протягом першого кварталу. Ваша початкова оцінка буде неточною — це нормально. Порівняйте її з реальним рахунком у Cost Explorer після першого місяця, знайдіть розбіжності й скоригуйте. До третього місяця ваші оцінки мають потрапляти з точністю до 10%.

Не оптимізуйте, доки не виміряли. Ми бачимо компанії, які купують Reserved Instances у перший місяць, бо «це економить гроші». Так — якщо ви знаєте, що саме резервуєте. Попрацюйте на on-demand 2–3 місяці, зрозумійте свої реальні патерни навантаження, і тільки тоді беріть зобов'язання.

Що повинна містити ваша оцінка

Перш ніж вважати оцінку готовою, переконайтесь, що врахували:

Compute (Fargate, Lambda або EC2)
Базу даних (RDS або DynamoDB)
Сховище (S3)
CDN (CloudFront)
Балансувальник навантаження (ALB)
NAT Gateway (додайте — калькулятор про нього не нагадає)
DNS (Route 53 — ~$0,50/hosted zone/місяць плюс оплата за запити)
Моніторинг (CloudWatch — мінімум базове логування та алерти)
15–20% буферу на трансфер даних, додаткові платежі та сюрпризи

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

В Otocolobus ми допомагаємо компаніям МСБ оцінити, побудувати та оптимізувати їхню AWS-інфраструктуру. Пройшли через калькулятор і хочете, щоб хтось перевірив ваші цифри? Або хочете одразу пропустити здогадки? Напишіть нам — розберемо ваш конкретний випадок.