Chmura AWS dla polskiej firmy — od czego zacząć?
„AWS to rozwiązanie dla dużych firm" — to zdanie słyszymy regularnie od właścicieli małych i średnich przedsiębiorstw w Polsce. Zwykle tuż przed tym, jak opowiadają nam o swoim serwerze na home.pl, który pada przy każdym większym ruchu, albo o VPS-ie, którego nikt w firmie nie umie zaktualizować.
Prawda jest taka: AWS obsługuje zarówno Netflixa, jak i jednoosobowe startupy. Różnica nie polega na tym, czy AWS jest dla Twojej firmy — tylko na tym, jak go skonfigurować, żeby nie przepłacać i nie komplikować rzeczy, które powinny być proste.
W Otocolobus stawiamy infrastrukturę AWS dla polskich firm MŚP od lat. Ten artykuł to esencja tego, co powtarzamy każdemu klientowi na pierwszym spotkaniu.
Czy AWS ma sens dla firmy z 5-osobowym zespołem?
Krótka odpowiedź: tak, jeśli Twoja firma polega na aplikacji webowej, API, sklepie internetowym lub dowolnym systemie, który musi działać niezawodnie.
Długa odpowiedź: typowe obciążenie małej polskiej firmy — aplikacja webowa, baza danych, storage na pliki — kosztuje na AWS od 200 do 800 zł miesięcznie. To porównywalne z przyzwoitym hostingiem, ale z zupełnie inną klasą niezawodności, skalowalności i bezpieczeństwa.
Jeśli dziś siedzisz na współdzielonym hostingu u jednego z polskich dostawców i regularnie natykasz się na limity — wydajnościowe, pamięciowe, konfiguracyjne — to prawdopodobnie dobry moment, żeby poważnie pomyśleć o chmurze. Nie dlatego, że hosting jest „zły", ale dlatego, że Twoja firma z niego wyrosła.
Pierwsze 30 minut: konto, budżety, bezpieczeństwo
Największy błąd, jaki widzimy u firm wchodzących na AWS, to rzucenie się od razu do stawiania serwerów. Tymczasem pierwszą rzeczą, którą powinieneś zrobić, jest zabezpieczenie konta — bo niezabezpieczone konto AWS potrafi wygenerować rachunek na dziesiątki tysięcy złotych w ciągu jednej nocy.
Oto co zrobić zanim postawisz cokolwiek:
Konto i organizacja. Załóż AWS Organization nawet jeśli masz jedno konto. Da Ci to porządek od pierwszego dnia i ułatwi rozdzielanie środowisk (produkcja, staging, dev) w przyszłości.
Budżet i alerty. Wejdź w AWS Budgets i ustaw alert na kwotę, której przekroczenie chcesz natychmiast zauważyć. Dla większości małych firm to 500–1000 zł. Zajmuje to dwie minuty i ratuje przed nieprzyjemnymi niespodziankami.
MFA i blokada konta root. Włącz uwierzytelnianie dwuskładnikowe na koncie root, a potem schowaj dane logowania do sejfu i nie używaj tego konta do codziennej pracy. Stwórz osobnych użytkowników IAM z odpowiednimi uprawnieniami.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::moja-firma-pliki/*"
}
]
}
Taka polityka daje użytkownikowi dostęp tylko do konkretnego bucketa S3 — zamiast otwierać drzwi do wszystkiego. Zasada jest prosta: każdy użytkownik i serwis powinien mieć dostęp wyłącznie do tego, czego potrzebuje do pracy. Nic więcej.
AWS CloudTrail. Włącz go. Loguje każdą operację wykonaną na Twoim koncie. Jeśli kiedykolwiek będziesz musiał sprawdzić, kto co zmienił i kiedy — CloudTrail to jedyne źródło prawdy.
Jaki stos technologiczny wybrać?
To zależy od tego, co Twoja firma faktycznie robi w internecie. Zamiast ogólnych porad podajemy trzy konkretne zestawy, które stosujemy u naszych klientów.
Strona firmowa lub landing page (budżet: ~50–100 zł/mies.)
Dla statycznych stron najlepiej sprawdza się połączenie S3 (hosting plików) z CloudFront (CDN, czyli globalna sieć dystrybucji treści). Strona ładuje się błyskawicznie z lokalizacji najbliższej użytkownikowi, a koszty są minimalne. Nie potrzebujesz żadnego serwera.
Aplikacja webowa z bazą danych (budżet: ~200–600 zł/mies.)
ECS Fargate do uruchomienia aplikacji w kontenerach, RDS PostgreSQL lub MySQL jako baza danych, S3 na pliki użytkowników, CloudFront na frontend. To nasz najczęstszy setup dla polskich firm MŚP — wystarczająco prosty, żeby jeden programista go ogarnął, a jednocześnie na tyle solidny, żeby przeżył skok ruchu.
API lub backend mobilny (budżet: ~100–400 zł/mies.)
Lambda (funkcje bezserwerowe) + API Gateway + DynamoDB. Płacisz tylko za faktyczne zapytania — jeśli nikt nie korzysta z API w nocy, rachunek za te godziny wynosi zero. Idealny model dla aplikacji mobilnych lub integracji między systemami.
RODO i dane w chmurze — co musisz wiedzieć
To temat, który niepokoi każdą polską firmę rozważającą AWS, i słusznie. Kilka kluczowych faktów.
AWS oferuje region eu-central-1 (Frankfurt) — fizycznie w Europie, objęty europejskim prawem o ochronie danych. Dla polskich firm to naturalny wybór: dane są blisko (niska latencja), a jednocześnie spełniają wymogi RODO dotyczące przetwarzania na terenie UE.
AWS udostępnia Data Processing Addendum (DPA), które stanowi umowę powierzenia przetwarzania danych osobowych zgodną z RODO. Nie musisz niczego negocjować indywidualnie — DPA jest częścią standardowych warunków usługi.
Pamiętaj jednak: AWS odpowiada za bezpieczeństwo chmury, Ty odpowiadasz za bezpieczeństwo w chmurze. To znaczy, że Amazon dba o fizyczne bezpieczeństwo serwerowni i infrastrukturę sieciową, ale to Ty musisz zadbać o szyfrowanie danych, polityki dostępu, backupy i konfigurację swoich serwisów. RODO nie jest problemem technicznym AWS — jest Twoją odpowiedzialnością operacyjną.
Na co zwrócić uwagę:
- Włącz szyfrowanie at-rest na S3, RDS i EBS — to jedno kliknięcie przy tworzeniu zasobu.
- Używaj HTTPS wszędzie — CloudFront z certyfikatem ACM załatwia to za darmo.
- Dokumentuj, gdzie przechowujesz dane osobowe i kto ma do nich dostęp. RODO wymaga tego niezależnie od tego, czy używasz chmury, czy szafy serwerowej w piwnicy.
Infrastructure as Code od pierwszego dnia
Kuszące jest postawienie wszystkiego „na klikacza" przez konsolę AWS. Szybko, łatwo, działa. Problem pojawia się, gdy:
- Trzeba odtworzyć środowisko po awarii.
- Przychodzi nowy programista i pyta „jak to jest postawione?"
- Potrzebujesz środowiska testowego identycznego z produkcją.
Rozwiązanie: opisz swoją infrastrukturę kodem od samego początku. W Otocolobus używamy Terraforma — pozwala nam trzymać całą infrastrukturę klienta w repozytorium Git, wersjonować zmiany i odtwarzać środowiska jednym poleceniem.
resource "aws_ecs_service" "app" {
name = "moja-firma-app"
cluster = aws_ecs_cluster.main.id
task_definition = aws_ecs_task_definition.app.arn
desired_count = 1
launch_type = "FARGATE"
network_configuration {
subnets = var.private_subnets
security_groups = [aws_security_group.app.id]
}
}
Nawet jeśli dziś masz jedną aplikację i jedno środowisko — zacznij od kodu. Podziękujesz sobie za pół roku.
Ile to kosztuje naprawdę?
Zamiast mówić „to zależy", podajemy konkretne przedziały z naszego doświadczenia z polskimi firmami MŚP:
| Scenariusz | Skład | Koszt miesięczny |
|---|---|---|
| Strona firmowa | CloudFront + S3 | 50–100 zł |
| Aplikacja webowa | ECS Fargate + RDS + S3 + CloudFront | 200–600 zł |
| API / backend mobilny | Lambda + API Gateway + DynamoDB | 100–400 zł |
| Pełna platforma (apka + API + dashboard + analityka) | ECS + RDS + DynamoDB + CloudFront + Lambda | 600–2000 zł |
Kwoty dotyczą typowego obciążenia MŚP — kilkaset do kilku tysięcy użytkowników dziennie. Przy gwałtownym wzroście ruchu koszty rosną, ale też proporcjonalnie — nie skokowo, jak przy konieczności kupna nowego serwera.
Kluczowe: włącz AWS Cost Explorer i AWS Budgets od pierwszego dnia. Przeglądaj koszty co tydzień. Taguj zasoby etykietami (projekt, środowisko, odpowiedzialny). Koszty pod kontrolą to koszty, których się nie boisz.
Robić samemu czy wynająć kogoś?
Uczciwa odpowiedź: to zależy od stawki, jaką Twoja firma płaci za przestoje.
Rób sam, jeśli: masz w zespole programistę, który chce się rozwijać w kierunku DevOps, Twoje obciążenie jest proste (strona + baza), a ewentualny dzień przestoju nie kosztuje Cię fortuny.
Wynajmij pomoc, jeśli: Twoja aplikacja to rdzeń biznesu, nie masz w zespole osoby z doświadczeniem w AWS, albo przenosisz się z legacy systemu i nie chcesz ryzykować danych klientów przy migracji.
Nie chodzi o to, żeby na stałe zatrudniać firmę do zarządzania chmurą. Chodzi o to, żeby ktoś doświadczony postawił fundamenty — konto, bezpieczeństwo, architekturę, IaC — a Twój zespół mógł na tym budować dalej.
Następny krok
AWS to nie jest decyzja, którą podejmujesz raz i zapominasz. To infrastruktura, która rośnie razem z firmą — jeśli jest dobrze postawiona od początku. Najgorsze, co możesz zrobić, to postawić wszystko na szybko przez konsolę, bez zabezpieczeń, bez budżetów, bez kodu — i modlić się, żeby nic nie poszło nie tak.
Najlepsze, co możesz zrobić, to zacząć od solidnych fundamentów i rozbudowywać je stopniowo.
W Otocolobus pomagamy polskim firmom MŚP stawiać pierwsze kroki na AWS — albo naprawiać kroki, które poszły nie tak. Chcesz porozmawiać o swojej infrastrukturze? Odezwij się — pierwsze konsultacje są bezpłatne.