← Повернутися до блогу
15 червня 2025 р.

5 помилок архітектури AWS, які допускають малі та середні компанії (і як їх уникнути)

AWSАрхітектураМСБМіграція в ХмаруОптимізація ВитратБезпекаTerraformECS

AWS давно перестав бути прерогативою великих корпорацій. Малий та середній бізнес мігрує в хмару все активніше — от тільки багато хто наступає на одні й ті самі граблі.

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

1. Over-engineering з першого дня

Найпоширеніший гріх? Проєктувати під навантаження рівня Netflix, коли у тебе 500 користувачів.

Виглядає це зазвичай так: стартап розгортає Kubernetes-кластер із кількома мікросервісами, додає service mesh, по окремій базі даних на кожен сервіс і нагороджує все це розгалуженим CI/CD-пайплайном — і все це до того, як взагалі підтвердив, що продукт комусь потрібен. Далі приходить рахунок від AWS із чотиризначною цифрою, а першого платного клієнта ще й близько немає.

Що ми бачили наживо: До нас звернувся клієнт із трьома мікросервісами на EKS — для внутрішнього інструменту, яким користувалося 40 людей. Місячний рахунок за AWS — понад 1200 €. Ми перенесли все в один сервіс на ECS Fargate за Application Load Balancer. Рахунок впав нижче 150 €.

Що робити натомість:

  • Почніть із моноліту або мінімуму сервісів. ECS Fargate — відмінний компроміс: контейнери без головного болю з управлінням серверами, а під час простою витрати падають до нуля.
  • Обирайте DynamoDB в режимі on-demand замість provisioned capacity, доки не зрозумієте свої патерни навантаження.
  • Поставте собі одне запитання: «Чи вирішить це одна Lambda-функція?» Якщо так — з неї й починайте.

2. Безпека? «Налаштуємо після запуску»

«Нормальні IAM-політики додамо після релізу.» Ми це чуємо постійно. Біда в тому, що це «після» якось ніколи не настає — а коли настає, то вже після інциденту.

Компанії МСБ тут особливо вразливі, бо зазвичай не мають окремого спеціаліста з безпеки. Розробник з AdministratorAccess на своєму IAM-акаунті — це міна уповільненої дії.

До чого це призводить: Витік AWS-ключів на GitHub закінчується запуском інстансів для майнінгу крипти — буквально за кілька хвилин. Рахунки злітають до десятків тисяч. Це не теоретичний сценарій — у галузі таке трапляється щотижня.

Що робити натомість:

  • Увімкніть MFA для кожного IAM-акаунту з першого дня. Без жодних винятків.
  • Скрізь, де можливо, використовуйте IAM-ролі замість довгоживучих ключів доступу.
  • Активуйте AWS CloudTrail і налаштуйте бюджетні алерти ще до першого деплою.
  • Дотримуйтесь принципу мінімальних привілеїв: починайте з нуля і додавайте лише те, що реально потрібно.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

Така мінімальна S3-політика в рази безпечніша за s3:* — а написати її можна за пів хвилини.

3. Клацання замість коду, або життя без Infrastructure as Code

Якщо вся ваша інфраструктура — це послідовність кліків у консолі AWS, у вас серйозна проблема. Ресурси, створені вручну через консоль, не задокументовані, не відтворювані і практично не піддаються аудиту.

Ми бачимо це раз за разом: компанія підіймає все продакшн-середовище «мишкою». А потім виявляється, що треба staging. Або треба відновити систему після збою. Або в команду приходить новий розробник і запитує: «Як це все налаштовано?» Відповідь — розведені руки.

Що робити натомість:

  • Впровадьте Terraform або AWS CloudFormation із самого початку. В Otocolobus ми ставимо на Terraform — за його multi-cloud гнучкість та зрілу екосистему — але CloudFormation теж працює, якщо ви тільки в AWS.
  • Зберігайте код інфраструктури в Git поруч із кодом додатку.
  • Використовуйте модулі, щоб не дублювати одне й те саме (принцип DRY).
resource "aws_ecs_service" "app" {
  name            = "my-app"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets         = var.private_subnets
    security_groups = [aws_security_group.app.id]
  }
}

Infrastructure as Code — не розкіш. Це абсолютний мінімум для будь-якого продакшн-середовища.

4. Витрати? «Розберемось, коли прийде рахунок»

Ціноутворення AWS складне — і це не випадково. Без свідомого контролю витрат дрібні неефективності нашаровуються й перетворюються на суттєві суми. Ми регулярно проводимо аудити AWS-акаунтів у наших клієнтів і щоразу бачимо одне й те саме: 30–50% бюджету йде на ресурси, які простоюють, завеликі за розміром або просто забуті.

Головні винуватці:

  • EC2-інстанси, що працюють цілодобово для задач, потрібних лише в робочі години
  • Непідключені EBS-томи та забуті Elastic IP (так, AWS бере гроші за невикористані EIP)
  • NAT Gateway, що гоняє трафік, який спокійно міг би йти через VPC endpoint
  • RDS-інстанси, підібрані під пікове навантаження, яке тримається 2 години на добу

Що робити натомість:

  • Увімкніть AWS Cost Explorer і заглядайте туди щотижня — не раз на місяць і не раз на квартал.
  • Налаштуйте алерти в AWS Budgets. Алерт на 500 €/місяць неодноразово рятував наших клієнтів від неприємного сюрпризу у рахунку.
  • Тегуйте кожен ресурс: project, environment, owner. Ресурси без тегів — це гроші, які тихо витікають.
  • Беріться за Reserved Instances чи Savings Plans тільки після оптимізації базових витрат. Річне зобов'язання на неправильно підібраний інстанс — це не економія, а фіксація втрат.

5. Запуск без спостережуваності

Не полагодиш те, чого не бачиш. Але безліч компаній МСБ запускають додатки без продуманого логування, без метрик і без алертів. Коли о другій ночі щось ламається, перший сигнал — сердитий лист від клієнта наступного ранку.

Як виглядає нормальна спостережуваність у компанії МСБ:

Зовсім не обов'язково дорого чи складно. Надійний базовий набір — це CloudWatch Logs для централізованого збору логів, CloudWatch Alarms із порогами на CPU, пам'ять і відсоток помилок, а також X-Ray для трейсингу запитів між сервісами.

Коли ми будували платформу аналітики реального часу для клієнта з логістичної галузі — на ECS та DynamoDB Streams — спостережуваність була частиною архітектури з першого начерку, а не «фічею», додаваною на фініші. DynamoDB Streams подавав дані в контейнери обробки, і кожен етап логувався, вимірювався та був під алертами. Коли о третій ночі зовнішній API без попередження змінив формат відповіді, черговий інженер дізнався про це за хвилину — а не за шість годин.

Що робити натомість:

  • Із першого дня логуйте в структурованому форматі JSON. Це нічого не коштує додатково, зате CloudWatch Logs Insights починає реально працювати.
  • Зберіть дашборд із 5–7 ключовими метриками вашого додатку. Якщо не вміщується на одному екрані — ви відстежуєте забагато.
  • Підключіть PagerDuty, Opsgenie або хоча б найпростіший алерт SNS → email на критичні пороги.

Спільний знаменник

Усі п'ять помилок ростуть із одного кореня: ставлення до хмарної інфраструктури як до чогось, що налаштовують раз і забувають. AWS винагороджує продуману, поступову архітектуру. Починайте просто, захистіть фундамент, опишіть все кодом, тримайте руку на пульсі витрат і інструментуйте свої системи.

Якщо ви ведете бізнес на AWS і хоч одна з цих помилок здалася знайомою — ви не самі. І жодна з них не є незворотною. Найкращий час виправити архітектуру був на старті. Другий найкращий — зараз.

В Otocolobus ми допомагаємо малим і середнім компаніям будувати архітектури AWS, які від першого дня безпечні, ефективні за витратами та готові до продакшну. Хочете безкоштовний огляд своєї архітектури? Напишіть нам.