Не повторюй ці факапи при роботі з AWS. 3 частина
Юху, фінальна частина про проблеми при роботі з AWS вже тут. Почитай попередні 2 частини, щоб скласти всі пазли в голові:
Не повторюй ці факапи при роботі з AWS. 1 частина
Не повторюй ці факапи при роботі з AWS. 2 частина
У цій — говоримо про те, що часто ламає навіть добре спроєктовані системи: моніторинг, нетворкінг, загальні управлінські помилки та прогалини в навчанні.
Прогалини в моніторингу та технічному обслуговуванні
1. Відсутні тривоги CloudWatch для критичних ресурсів
Проблеми з CPU, памʼяттю або диском часто стають помітними лише тоді, коли застосунок уже лежить. Без тривог команда дізнається про інцидент від користувачів, а не з моніторингу.
Як правильно: налаштуй CloudWatch Alarms для ключових метрик — CPU, memory, disk, latency, error rate. Сповіщення мають приходити в Slack або пошту ще до того, як сервіс стане недоступним.
2. Відсутність регулярних health checks застосунків
Ресурси можуть бути в стані running і без помилок на рівні інфраструктури, але сам застосунок при цьому не обробляє запити або повертає 5xx. Без health checks AWS вважає сервіс працездатним і не перезапускає його та не виводить з балансування.
Як правильно: додавай health endpoints у застосунки та підʼєднуй їх до Load Balancer health checks або Route 53. Так проблемні інстанси автоматично виключаються з трафіку.
3. Ігнорування сервісних лімітів AWS
Ліміти по EC2, EIP, ENI або RDS зазвичай згадують тільки тоді, коли новий ресурс уже не створюється. У піковий момент це може зупинити масштабування або реліз.
Як правильно: регулярно переглядай Service Quotas, підвищуй ліміти заздалегідь і закладай їх у планування росту інфраструктури.
4. Відсутні політики зберігання логів
Логи або зникають через кілька днів, або зберігаються вічно в дорогому сховищі. У першому випадку — нічого аналізувати, у другому — ростуть витрати.
Як правильно: налаштуй retention policies для логів у CloudWatch і архівування в S3 з переходом у холодні класи зберігання.
5. Відсутність контролю витрат у реальному часі
Часто рахунки переглядають раз на місяць, коли гроші вже витрачені. У цей момент оптимізувати щось запізно.
Як правильно: використовуй бюджети AWS Budgets і сповіщення про перевищення.
6. Ігнорування сторонніх інструментів моніторингу
CloudWatch покриває базу, але без глибокої аналітики важко зрозуміти, чому система поводиться нестабільно.
Як правильно: для складних проєктів підключай Datadog, New Relic або Grafana + Prometheus. Вони дають кореляцію між метриками, логами та трасуванням.
7. Логи не аналізують безпеку й продуктивність
Логи є, але ніхто їх не дивиться. Через це є підозрілі запити, помилки авторизації або деградація продуктивності проходять повз.
Як правильно: автоматизуй аналіз логів через CloudWatch Insights або SIEM. Критичні патерни мають одразу викликати алерт.
8. Ігнорування метрик затримки та відповіді системи
CPU може бути в нормі, але користувачі скаржаться на повільну роботу. Без latency-метрик команда не бачить реальної проблеми.
Як правильно: відстежуй latency, error rate і throughput для API та бази даних. Це ключові показники здоровʼя сервісу, а не лише навантаження.
9. Відсутність синтетичного моніторингу
Система виглядає живою, але ключові сценарії користувачів не працюють.
Як правильно: налаштуй синтетичні перевірки через CloudWatch Synthetics або сторонні сервіси, які імітують дії реального користувача.
10. Відсутність регулярних аудитів інфраструктури
Зміни накопичуються місяцями: тимчасові рішення стають постійними, а технічний борг росте.
Як правильно: проводь регулярні ревʼю інфраструктури — щонайменше раз на квартал. Перевіряй моніторинг, алерти, ліміти й відповідність реальному навантаженню.
Помилки в нетворкінгу
1. Виставлення сервісів публічно без потреби
Часто EC2, бази або адмінпанелі мають публічні IP просто «щоб було зручно». У результаті внутрішні сервіси стають доступними ззовні й автоматично потрапляють під сканування та атаки.
Як правильно: усе, що не має бути доступне користувачам, розміщуй у приватних підмережах. Доступ організовуй через Load Balancer, Bastion Host або VPN.
2. Неправильна конфігурація підмереж і маршрутів у VPC
Коли публічні й приватні підмережі змішані або маршрути налаштовані хаотично, трафік іде не туди, куди очікується. Це призводить до проблем з доступністю або безпекою.
Як правильно: чітко розділяй публічні та приватні підмережі, перевіряй route tables і документуй, який трафік куди має ходити.
3. Ігнорування приватних IP для внутрішнього трафіку
Інстанси всередині VPC інколи спілкуються між собою через публічні IP. Це збільшує затримки й створює зайві ризики.
Як правильно: для внутрішньої взаємодії використовуй приватні IP або Private DNS. Публічний доступ залишай лише для edge-точок.
4. Перевантаження одного NAT Gateway
Уся приватна інфраструктура виходить в інтернет через один NAT Gateway. Під навантаженням він стає вузьким місцем і джерелом затримок.
Як правильно: розподіляй NAT Gateway по Availability Zone і стежте за метриками трафіку та з’єднань.
5. Непродумане налаштування VPN або Direct Connect
VPN з обмеженою пропускною здатністю або без резервування стає єдиною точкою відмови для гібридної інфраструктури.
Як правильно: закладай резервні тунелі, тестуй failover і перевіряй пропускну здатність під реальним навантаженням.
6. Ігнорування DNS-механізмів відновлення після збою
Навіть якщо інфраструктура відмовостійка, користувачі можуть продовжувати йти в недоступний endpoint через DNS.
Як правильно: використовуй Route 53 з health checks і failover-маршрутизацією, щоб трафік автоматично переходив на робочі ресурси.
7. Надто складна мережева архітектура без документації
VPC peering, VPN, Transit Gateway, кастомні маршрути — усе працює, доки хтось не спробує щось змінити. Без документації навіть дрібна правка може все зламати.
Як правильно: спрощуй архітектуру там, де можливо, і документуй мережеву схему та залежності.
8. Невикористання Transit Gateway для складних мереж
Коли багато VPC з’єднані між собою через десятки peering-з’єднань, керування стає болючим.
Як правильно: для масштабних середовищ використовуй AWS Transit Gateway як централізований хаб для маршрутизації.
9. Відсутність регулярного рев’ю правил Security Group
З часом правила накопичуються, відкриваються зайві порти, а ніхто вже не пам’ятає, навіщо вони потрібні.
Як правильно: регулярно переглядай Security Groups, прибирай невикористовувані правила й фіксуй призначення кожного відкритого порту.
10. Необмежений внутрішній трафік у VPC
Дозвіл «all traffic from anywhere» всередині VPC виглядає безпечно, але при компрометації одного сервісу зловмисник отримує доступ до всього.
Як правильно: сегментуй мережу й обмежуй внутрішній трафік за принципом мінімально необхідного доступу.
Загальні нагляди
1. Масштабування без попереднього аналізу сервісів
Інфраструктуру починають масштабувати, не розібравшись, як саме поводяться сервіси під навантаженням. У результаті система росте хаотично, а вузькі місця залишаються.
Як правильно: перед масштабуванням аналізуй метрики, ліміти сервісів і реальні точки навантаження.
2. Поверхневе читання документації AWS
Сервіс виконує свою роботу — значить все добре. Але дрібні нюанси в документації часто критичні для безпеки, вартості або стабільності.
Як правильно: звертай увагу не лише на quick start, а й на розділи з обмеженнями, квотами та best practices. Саме там ховаються більшість фейлів.
3. Ігнорування планів підтримки AWS
Проблеми виникають, але команда залишається з ними сам на сам, без доступу до експертів AWS і швидкої ескалації.
Як правильно: для продакшн-систем використовуй хоча б Business Support. Це не зайва витрата, а страховка від довгих простоїв.
4. Відсутність управління патчами EC2
Інстанси працюють роками без оновлень. Вразливості накопичуються, а ризик компрометації зростає з кожним місяцем.
Як правильно: автоматизуй патчинг через SSM Patch Manager або оновлюй образи й регулярно викочуй інстанси повторно.
5. Ігнорування сервісних квот
Про ліміти згадують лише тоді, коли новий ресурс не створюється в критичний момент.
Як правильно: перевіряй квоти наперед і збільшуй їх до того, як вони стануть блокером для росту.
6. Недооцінка Reserved Instances і Savings Plans
Для стабільних навантажень роками використовують on-demand — і переплачують без жодної користі.
Як правильно: аналізуй довготривале використання ресурсів і фіксуй витрати через Reserved Instances або Savings Plans.
7. Помилкова оцінка пікових навантажень
Система працює нормально більшу частину часу, але падає під час піків (акцій, релізів або сезонних стрибків).
Як правильно: плануй інфраструктуру з урахуванням worst-case сценаріїв і тестуй її під навантаженням.
8. Нетестоване перемикання на резерв
Резервна інфраструктура ніби є, але ніхто не перевіряв, чи вона реально працює.
Як правильно: регулярно проводь failover-тести. Резерв, який не перевіряли, — це ілюзія безпеки.
9. Один акаунт на все
Усі середовища й проєкти живуть в одному акаунті. У результаті — плутанина, ризики доступу й складний контроль витрат.
Як правильно: розділяй акаунти за проєктами або середовищами через AWS Organizations.
10. Відсутність перевірок операційної готовності
Інфраструктура працює, але команда не готова до інцидентів: немає сценаріїв, відповідальних і чітких дій.
Як правильно: проводь регулярні operational readiness review — перевіряй, чи система і команда готові до збоїв.
Проблеми всередині команди
1. Відсутність розвитку навичок
Команди працюють за звичними підходами, не стежать за оновленнями та покладаються на метод спроб і помилок. У результаті — застарілі рішення, зайві витрати й пропущені можливості оптимізації.
Як правильно: закладай регулярне навчання як частину роботи. Наприклад, курси, сертифікації AWS, безплатні воркшопи, розбір реальних кейсів і нових сервісів та навіть внутрішні заходи з командою, де співробітники діляться досвідом.
Хмара змінюється постійно, і знання теж мають оновлюватись.
2. Відсутність або нерозуміння зон відповідальності
Буває, що таска висить вже місяць, бо ніхто не береться її реалізовувати. Не через те, що команда демотивована чи непрофесійна, а через те, що ніхто не розуміє межі своїх обов’язків.
Як правильно: чітко зафіксуй модель спільної відповідальності AWS для команди. Хто відповідає за безпеку, оновлення, моніторинг, резервні копії — усе має бути задокументовано і зрозуміло.
3. Ігнорування досвіду спільноти
На просторах інтернету є купу схожих і навіть однакових кейсів як у твоєї команди.
Як правильно: використовуй досвід спільноти — документацію AWS, приклади проєктів, вебінари, технічні блоги й форуми. Регулярно моніторити інформацію набагато простіше, ніж шукати рішення з нуля.
Післяслово
Ось і фінал. Якщо під час читання ти ловив себе на думці «окей, це знайомо» — значить, стаття спрацювала. Більшість цих фейлів не виглядають критичними поодинці, але разом вони повільно ламають стабільність, бюджет і нерви команди.
Гарна новина — велику частину цих проблем може закрити авторський курс від ITEDU. Лише 6 занять і ти чи твоя команда отримають сильну базу, яка допоможе системно рухатись вперед.
Реєструйся на курс, ми вже набираємо наступну групу!