5 błędów architektury AWS, które popełniają małe i średnie firmy (i jak ich uniknąć)

AWS dawno przestał być domeną korporacji. Małe i średnie firmy przenoszą się do chmury coraz szybciej — tyle że wiele z nich popełnia dokładnie te same błędy.

W Otocolobus pomagamy firmom MŚP z Polski i Europy budować rozwiązania cloud-native na AWS. Stawialiśmy dashboardy analityczne działające w czasie rzeczywistym, backendy aplikacji mobilnych i systemy przetwarzania danych — wiemy, co się sprawdza, a co kończy się bólem. Poniżej pięć błędów architektonicznych, które spotykamy najczęściej, oraz konkretne sposoby, żeby ich uniknąć.

1. Over-engineering na dzień dobry

Najczęstszy grzech? Projektowanie pod ruch rodem z Netflixa, kiedy korzysta z tego 500 osób.

Scenariusz jest zazwyczaj taki: startup stawia klaster Kubernetes z kilkoma mikroserwisami, dodaje service mesh, oddzielne bazy danych na każdy serwis i rozbudowany pipeline CI/CD — a to wszystko zanim w ogóle potwierdzi, czy produkt ma rację bytu na rynku. Potem przychodzi rachunek od AWS i robi się czterocyfrowo, mimo że pierwszego płacącego klienta wciąż nie ma.

Z czym się spotkaliśmy: Klient zgłosił się do nas z architekturą trzech mikroserwisów na EKS — dla wewnętrznego narzędzia, z którego korzystało 40 osób. Miesięczny rachunek? Ponad 1200 €. Przenieśliśmy wszystko do jednego serwisu na ECS Fargate za Application Load Balancerem. Rachunek spadł poniżej 150 €.

Co robić zamiast tego:

Zacznij od monolitu albo niewielkiej liczby serwisów. ECS Fargate to świetny kompromis — dostajesz kontenery bez zarządzania serwerami, a w czasie przestoju koszty spadają do zera.
Wybierz DynamoDB w trybie on-demand zamiast provisioned capacity, póki nie znasz swoich wzorców ruchu.
Zadaj sobie jedno pytanie: „Czy da się to rozwiązać jedną funkcją Lambda?" Jeśli tak — zacznij od niej.

2. Bezpieczeństwo? „Zajmiemy się tym po premierze"

„Porządne polityki IAM dodamy po uruchomieniu." Słyszymy to notorycznie. Tyle że to „po uruchomieniu" jakoś nigdy nie nadchodzi — a jeśli już, to zwykle po incydencie.

Firmy MŚP są tu szczególnie narażone, bo najczęściej nie mają dedykowanego specjalisty od bezpieczeństwa. Programista z AdministratorAccess przypiętym do swojego konta IAM to proszenie się o kłopoty.

Co z tego wynika w praktyce: Wyciek kluczy AWS na GitHubie kończy się uruchomieniem instancji do kopania kryptowalut — dosłownie w ciągu kilku minut. Rachunki idą w dziesiątki tysięcy. To nie są teoretyczne scenariusze — to się dzieje w branży co tydzień.

Co robić zamiast tego:

Wymuś MFA na każdym koncie IAM od pierwszego dnia. Żadnych wyjątków.
Tam, gdzie to możliwe, używaj ról IAM zamiast stałych kluczy dostępu.
Włącz AWS CloudTrail i ustaw alerty budżetowe jeszcze przed pierwszym wdrożeniem.
Stosuj zasadę minimalnych uprawnień — zacznij od zera i dodawaj tylko to, co faktycznie potrzebne.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

Taka minimalna polityka S3 jest wielokrotnie bezpieczniejsza niż s3:* — a jej napisanie zajmuje pół minuty.

3. Klikanie zamiast kodowania, czyli życie bez Infrastructure as Code

Jeśli cała Twoja infrastruktura to seria kliknięć w konsoli AWS — masz poważny problem. Zasoby postawione ręcznie przez konsolę nie mają dokumentacji, nie da się ich odtworzyć, a ich audyt to koszmar.

Widzimy to regularnie: firma buduje całe środowisko produkcyjne „na klikacza". Potem okazuje się, że potrzebne jest środowisko stagingowe. Albo trzeba podnieść system po awarii. Albo dochodzi nowy człowiek do zespołu i pyta: „Jak to jest postawione?" Odpowiedź? Wzruszenie ramion.

Co robić zamiast tego:

Wdróż Terraform lub AWS CloudFormation od samego początku. W Otocolobus stawiamy na Terraform — cenimy jego elastyczność multi-cloud i dojrzały ekosystem — ale CloudFormation też się sprawdzi, jeśli działasz wyłącznie w AWS.
Trzymaj kod infrastruktury w Git, obok kodu aplikacji.
Korzystaj z modułów, żeby nie powielać tego samego w kółko (zasada 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 to nie luksus. To absolutne minimum dla każdego środowiska produkcyjnego.

4. Koszty? „Popatrzymy, jak przyjdzie faktura"

Cennik AWS jest skomplikowany — i to z założenia. Bez świadomego zarządzania kosztami drobne nieefektywności nawarstwiają się w poważne kwoty. Robimy regularne audyty kont AWS u naszych klientów i za każdym razem okazuje się, że 30–50% budżetu idzie na zasoby, które stoją bezczynnie, są przewymiarowane albo po prostu zapomniane.

Największe grzechy:

Instancje EC2 chodzące 24/7 dla zadań potrzebnych tylko w godzinach pracy
Niepodpięte wolumeny EBS i zapomniane Elastic IP (tak — AWS nalicza opłaty za nieużywane EIP)
NAT Gateway obsługujący ruch, który spokojnie mógłby iść przez VPC endpoint
Instancje RDS zwymiarowane pod szczytowe obciążenie, które trwa 2 godziny dziennie

Co robić zamiast tego:

Włącz AWS Cost Explorer i zaglądaj tam co tydzień — nie co miesiąc i nie co kwartał.
Ustaw alerty w AWS Budgets. Alert na 500 €/miesiąc nie raz uratował naszych klientów przed sporą niespodzianką na fakturze.
Taguj każdy zasób: project, environment, owner. Zasoby bez tagów to niewidzialne pieniądze w błoto.
Po Reserved Instances czy Savings Plans sięgaj dopiero po optymalizacji bazy kosztowej. Roczne zobowiązanie na źle dobraną instancję to zamrożenie strat, nie oszczędność.

5. Wdrożenie bez obserwowalności

Nie naprawisz czegoś, czego nie widzisz. A mimo to mnóstwo firm MŚP wypuszcza aplikacje bez przemyślanego logowania, bez metryk i bez alertów. Gdy o drugiej w nocy coś się sypie, firma dowiaduje się o tym następnego ranka — z wściekłego maila od klienta.

Jak wygląda sensowna obserwowalność w firmie MŚP:

Wcale nie musi być droga ani skomplikowana. Solidny, podstawowy zestaw to CloudWatch Logs do centralnego zbierania logów, CloudWatch Alarms z progami na CPU, pamięć i wskaźnik błędów oraz X-Ray do śledzenia requestów między serwisami.

Kiedy budowaliśmy platformę analityki czasu rzeczywistego dla klienta z branży logistycznej — na ECS i DynamoDB Streams — obserwowalność była częścią architektury od pierwszego szkicu, nie dodatkiem wrzuconym na koniec. DynamoDB Streams zasilał kontenery przetwarzające dane, a każdy etap był logowany, mierzony i objęty alertami. Gdy o trzeciej w nocy zewnętrzne API bez zapowiedzi zmieniło format odpowiedzi, dyżurny inżynier wiedział o tym w ciągu minuty — nie sześciu godzin.

Co robić zamiast tego:

Od pierwszego dnia loguj w ustrukturyzowanym formacie JSON. Nie kosztuje to nic dodatkowego, a sprawia, że CloudWatch Logs Insights wreszcie zaczyna mieć sens.
Zbuduj dashboard z 5–7 kluczowymi metrykami aplikacji. Jeśli nie mieści się na jednym ekranie — śledzisz za dużo.
Skonfiguruj PagerDuty, Opsgenie albo choćby prosty alert SNS → e-mail na krytyczne progi.

Wspólny mianownik

Każdy z tych pięciu błędów ma ten sam korzeń: podejście do infrastruktury chmurowej jako do czegoś, co ustawia się raz i zapomina. AWS nagradza przemyślaną, iteracyjną architekturę. Zacznij prosto, zabezpiecz fundamenty, opisz wszystko kodem, pilnuj kosztów i instrumentuj swoje systemy.

Jeśli prowadzisz firmę na AWS i któryś z tych błędów brzmi znajomo — nie jesteś w tym sam. I żaden z nich nie jest nieodwracalny. Najlepszy moment na naprawę architektury był na starcie. Drugi najlepszy — teraz.

W Otocolobus pomagamy małym i średnim firmom budować architektury AWS, które od pierwszego dnia są bezpieczne, efektywne kosztowo i gotowe na produkcję. Chcesz bezpłatny przegląd swojej architektury? Odezwij się do nas.