Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

06.11.2023

Як не дати AWS Cloudwatch себе пограбувати

Давно вже не писав про Cloudwatch, хоча продовжую ним користуватись принаймні щотижня. Попри наявність “брендових” альтернатив, мені до вподоби те, що пропонує AWS у своєму рішенні для збору журналів та метрик. Є тільки один нюанс: можна швидко влетіти на багато грошей. Як і з усім в AWS.

Найризиковішим, як на мене, є утворення власних метрик. У метрик є “виміри” (dimension) - щоб під одним імʼям збирати показники по різних ресурсах. Кожне значення виміру власної метрики сплачується як окрема метрика. А це вже відчутні $0.30 на місяць. Якщо обрати такий вимір, у якого багато значень — наприклад, ID акаунта в нашій системі — то недовго почати витрачати сотні доларів на таку нібито тривіальну потребу.

Окремо підступний вимір - ID задачі ECS, або її ж IP адреса: вони не є сталими, тож за місяць перезапусків та деплоїв можна теж назбирати вагомий рахунок. Якщо вже збирати статистику за задачами, потрібно спочатку винайти сталий ідентифікатор.

Зазначу, що вбудовані метрики AWS нічого не коштують. Це ті, які неможливо відключити. Бо трапляються ще “розширені” метрики — вони рахуються як власні.

А ще дорого може вийти надсилання метрик. Тут $0.01 на тисячу запитів, але знов-таки, якщо наївно відправляти кожне значення окремо, то вони швидко накопичуються. Тому краще буферизувати на своєму боці та викликати PutMetricData рідше. До речі, оскільки для кожного значення в цьому запиті можна окремо вказати час, то нічого нам не заважає, наприклад, відправляти похвилинні метрики раз на пʼять хвилин.

Зате потім зайшов на сторінку цін DataDog та зрозумів, що в AWS не найбільш заплутана цінова політика.