Kalkulator kosztów AWS: jak oszacować wydatki na chmurę (z przykładami z życia)

„Ile będzie nas kosztował AWS?" — to pierwsze pytanie, które słyszymy od każdej polskiej firmy rozważającej przeprowadzkę do chmury. I zarazem najtrudniejsze do uczciwej odpowiedzi. AWS ma ponad 200 usług, każda z własnym modelem cenowym, a oficjalne cenniki czyta się jak umowę ubezpieczeniową.

Dobra wiadomość: nie musisz rozumieć ich wszystkich. Istnieje Kalkulator Cenowy AWS, a z odpowiednimi danymi wejściowymi da się uzyskać rzetelne oszacowanie miesięcznych kosztów w 20 minut.

W Otocolobus zbudowaliśmy infrastrukturę AWS dla kilkudziesięciu firm MŚP. W tym artykule przeprowadzimy Cię przez kalkulator krok po kroku, opierając się na trzech scenariuszach z naszych realnych projektów — z prawdziwymi kwotami, nie wymyślonymi.

Kalkulator AWS: od czego zacząć

Wejdź na calculator.aws. Interfejs jest prosty: dodajesz usługi jedną po drugiej, konfigurujesz je pod swoje przewidywane użycie, a kalkulator podaje szacunek miesięczny.

Zanim zaczniesz klikać, kilka rzeczy warto wiedzieć:

Wybierz region na starcie. Dla polskich firm standardem jest eu-central-1 (Frankfurt). Ceny różnią się między regionami — Frankfurt jest nieco droższy niż regiony amerykańskie, ale dane zostają w UE, co ma znaczenie dla RODO.

Szacuj ostrożnie, a potem dodaj 15–20%. Kalkulator pokazuje koszt usług, które skonfigurujesz. Nie uwzględnia transferu danych między usługami, logowania w CloudWatch ani kilkunastu drobnych opłat, które się sumują. My zawsze dodajemy 15–20% buforu na te rzeczy.

Skup się na dużych pozycjach. W większości projektów MŚP 80% rachunku generują trzy–cztery usługi. Dobrze oszacuj te i reszta to błąd zaokrąglenia.

Scenariusz 1: Strona firmowa (statyczna lub prawie statyczna)

Najprostsza i najtańsza konfiguracja na AWS — i ta, której większość małych firm naprawdę potrzebuje. Strona firmowa, landing page, witryna marketingowa. Żaden serwer nie chodzi 24/7, żadna baza danych. Tylko pliki serwowane szybko.

Czego potrzebujesz:

S3 — hosting HTML, CSS, JS i grafik
CloudFront — CDN do szybkiego serwowania i HTTPS
Route 53 — DNS

Krok po kroku w kalkulatorze:

1. S3. Dodaj S3:

1 GB w klasie Standard (większość firmowych stron mieści się w ułamku tego)
100 000 żądań GET/miesiąc, 10 000 PUT/miesiąc (deploy)
Przy takiej skali S3 kosztuje grosze — dosłownie kilka centów

2. CloudFront. Dodaj CloudFront:

50 GB transferu wychodzącego miesięcznie
500 000 żądań HTTPS/miesiąc
To spokojnie obsłuży stronę z kilkoma tysiącami odwiedzin dziennie

3. Route 53. Dodaj Route 53:

1 hosted zone (~$0,50/miesiąc)
500 000 zapytań DNS/miesiąc (~$0,20)

Co pokazuje kalkulator: ~20–35 zł/miesiąc

Co widzimy na fakturach klientów: 35–65 zł/miesiąc. Niespodzianek tu prawie nie ma — na tym polega piękno hostingu statycznego. Drobna różnica bierze się z alarmów CloudWatch (jeśli je ustawisz), nieco wyższego ruchu i okazjonalnych skoków po wrzutce w social mediach albo newsletterze.

To rząd wielkości taniej niż ta sama strona na VPS-ie czy w kontenerze. Jeśli Twoja firmowa strona nie potrzebuje bazy danych ani logiki po stronie serwera — nie płać za nie.

Scenariusz 2: API dla B2B SaaS (sporadyczne użycie, skalowanie do zera)

Ta architektura ma sens, kiedy Twoi użytkownicy to firmy, nie konsumenci. Ruch podąża za godzinami biurowymi — rano w jednej strefie czasowej, po południu w drugiej, cisza w nocy, martwo w weekendy. Nie chcesz płacić za serwer, który 70% czasu stoi bezczynnie.

Czego potrzebujesz:

Lambda — logika API
API Gateway — udostępnienie API klientom
DynamoDB — baza danych (tryb on-demand, płacisz za żądanie)
S3 — pliki
CloudFront — jeśli serwujesz jakąkolwiek statyczną treść

Krok po kroku w kalkulatorze:

1. Lambda. Dodaj Lambda:

500 000 żądań/miesiąc (rozsądny punkt wyjścia dla produktu B2B z ~50 aktywnymi tenantami)
Średni czas wykonania: 200 ms
Pamięć: 256 MB
Darmowy tier Lambda obejmuje milion żądań/miesiąc — na początku możesz nie zapłacić tu nic

2. API Gateway. Dodaj API Gateway (HTTP API — tańsze niż REST API):

500 000 wywołań API/miesiąc
Średni rozmiar wiadomości: 3 KB

3. DynamoDB. Dodaj DynamoDB w trybie on-demand:

500 000 jednostek zapisu/miesiąc
2 000 000 jednostek odczytu/miesiąc (odczytów jest zazwyczaj wielokrotnie więcej niż zapisów)
5 GB storage

4. S3. Dodaj S3 na pliki:

10 GB w klasie Standard
50 000 żądań GET/miesiąc

Co pokazuje kalkulator: ~35–85 zł/miesiąc

Co widzimy w praktyce: 65–170 zł/miesiąc. Architektury serverless mają mniejszą rozbieżność między szacunkiem a rzeczywistością, bo nie płacisz za bezczynne zasoby. Największy niespodziewany koszt to zwykle API Gateway — przy dużym wolumenie potrafi przekroczyć koszt samej Lambdy.

Czemu nie ECS? Przy sporadycznym B2B-owym użyciu płacenie za kontener chodzący 24/7 nie ma sensu. Lambda skaluje się do zera: brak aktywnych tenantów, brak kosztów. Na ECS Fargate zapłacisz minimum ~85 zł/miesiąc za jeden task, który w weekendy i wieczorami nie robi nic. Przy tej skali to podwojenie rachunku bez żadnej korzyści.

Scenariusz 3: E-commerce B2C (przewidywalny ruch, always on)

Zupełnie inny wzorzec niż B2B: konsumenci kupują wieczorami, przeglądają w przerwie na lunch, a w dni wyprzedaży ruch skacze. Ruch jest bardziej przewidywalny i bardziej ciągły — widać, kiedy użytkownicy są aktywni. Kontenery chodzące non-stop mają tu więcej sensu niż rozliczanie per żądanie, a Lambda obsługuje zadania w tle: przetwarzanie zamówień, powiadomienia, aktualizacje stanów magazynowych.

Czego potrzebujesz:

ECS Fargate — aplikacja webowa (always on)
RDS PostgreSQL — baza relacyjna na produkty, zamówienia, użytkowników
Lambda — przetwarzanie asynchroniczne (zdarzenia zamówień, powiadomienia)
S3 — zdjęcia produktów, uploady użytkowników
CloudFront — CDN na grafiki i assety statyczne
Application Load Balancer — kierowanie ruchu do kontenerów
SES — emaile transakcyjne (potwierdzenia zamówień, aktualizacje wysyłek)

Krok po kroku w kalkulatorze:

1. ECS Fargate. Tym razem always on, z zapasem na ruch:

2 taski 24/7 (redundancja — jeśli jeden padnie, drugi dalej serwuje)
1 vCPU, 2 GB pamięci na task
To spokojnie obsłuży kilka tysięcy aktywnych użytkowników dziennie

2. RDS PostgreSQL. Dodaj RDS:

db.t4g.small (2 vCPU, 2 GB RAM)
50 GB storage z gp3
Single-AZ na razie (Multi-AZ, kiedy przychody to uzasadnią)

3. Lambda. Przetwarzanie asynchroniczne:

200 000 wywołań/miesiąc (zdarzenia zamówień, triggery email, synchronizacja magazynu)
Średni czas: 300 ms
Pamięć: 256 MB

4. S3 + CloudFront. Zdjęcia produktów i assety:

20 GB storage S3
100 GB transferu wychodzącego CloudFront/miesiąc
1 000 000 żądań HTTPS/miesiąc

5. Application Load Balancer. Dodaj ALB:

1 ALB 24/7
10 LCU — rozsądna średnia dla umiarkowanego ruchu e-commerce

6. SES. Emaile transakcyjne:

10 000 emaili/miesiąc (~$1)

Co pokazuje kalkulator: ~560–770 zł/miesiąc

Co widzimy w praktyce: 860–1 200 zł/miesiąc. Na tym poziomie ukryte koszty zaczynają się sumować: NAT Gateway (~150 zł/miesiąc), logowanie CloudWatch (~65–105 zł/miesiąc), transfer między strefami dostępności i Route 53. Różnica między kalkulatorem a rzeczywistością jest tu większa niż przy serverless, bo masz więcej komponentów chodzących non-stop i generujących opłaty w tle.

Pułapki cenowe, o których nikt nie ostrzega

Kalkulator dobrze radzi sobie z oczywistymi usługami. Oto czego systematycznie nie doszacowuje albo w ogóle nie uwzględnia:

NAT Gateway — cichy zabójca budżetu. Jeśli Twoje taski Fargate lub funkcje Lambda działają w prywatnej podsieci (a powinny, ze względów bezpieczeństwa), potrzebują NAT Gateway, żeby sięgnąć do internetu. W regionie Frankfurt NAT Gateway kosztuje ~150 zł/miesiąc samo za to, że istnieje ($0,052/godz.), plus ~0,21 zł za każdy GB przetworzonych danych. Dla małej aplikacji robiącej umiarkowaną liczbę wywołań do zewnętrznych API potrafi to dać 170–300 zł/miesiąc — często więcej niż sam compute.

Jak obniżyć: Użyj VPC endpointów do usług AWS (S3, DynamoDB, ECR). Są tańsze i nie obciążają NAT Gateway. Endpointy typu gateway (do S3 i DynamoDB) są darmowe.

Transfer danych między strefami dostępności. Jeśli Twój task ECS jest w eu-central-1a, a instancja RDS w eu-central-1b, każdy bajt przesłany między nimi kosztuje ~0,04 zł/GB w każdą stronę. To grosze na jedno żądanie, ale przy skali się sumuje.

Logowanie w CloudWatch. Każda linia logu kosztuje pieniądze za ingestion i przechowywanie. Gadatliwe logowanie na produkcji potrafi dorzucić 80–200 zł/miesiąc bez ostrzeżenia. Ustaw politykę retencji logów (14 lub 30 dni) i nie loguj ciał żądań/odpowiedzi na produkcji.

Publiczne adresy IPv4. Od lutego 2024 AWS nalicza $0,005/godzinę za każdy publiczny adres IPv4 — niezależnie, czy jest podpięty do działającego zasobu, czy leży odłożony. To ~$3,60/miesiąc za adres. Dotyczy wszystkich usług: instancji EC2, ALB, NAT Gateway, RDS — każda z publicznym IP dokłada do rachunku. Osierocone Elastic IP to oczywiste marnotrawstwo (regularnie znajdujemy 3–5 na konto klienta), ale teraz nawet te aktywnie używane kosztują. To kolejny powód, żeby rozważyć IPv6, gdzie stack na to pozwala.

ECR storage. Każdy obraz Dockerowy wrzucony do ECR zostaje tam na zawsze, chyba że ustawisz polityki cyklu życia. Po roku wdrożeń możesz mieć setki starych obrazów kosztujących kilkanaście złotych miesięcznie — nie katastrofa, ale zbędny wydatek.

Z życia wzięte: PaaS vs AWS Lambda vs własny serwer

Nie zawsze chodzi o ratowanie kogoś z kosztowej dziury. Czasem wystarczy dobrze policzyć, zanim się w nią wpadnie.

Przyszedł do nas klient z branży B2B SaaS — mieli aplikację multi-tenant postawioną na popularnym PaaS-ie. Frontend w React, backend w Pythonie na funkcjach serverless, managed Postgres z oddzielną bazą dla każdego klienta końcowego. Przy dziesięciu tenantach rachunek wyglądał niewinnie: jakieś 90 funtów miesięcznie. Problem w tym, że planowali rosnąć, i chcieli wiedzieć, w co się pakują przy 100, 500 i 1000 klientach.

Porównaliśmy trzy warianty: zostać na dotychczasowym PaaS-ie, przenieść się na AWS Lambda albo postawić kontenery u klasycznego dostawcy VPS-ów lub serwerów dedykowanych.

Co z tego wyszło:

Przy 10 tenantach — bez różnicy, wszędzie 55–90 funtów. Różnice zaczynają się dopiero przy skali:

Skala	Dotychczasowy PaaS	AWS Lambda	VPS / Dedykowany
10 tenantów	~£90/mies.	~£55/mies.	~£90/mies.
100 tenantów	~£315/mies.	~£280/mies.	~£470/mies.
500 tenantów	~£2600+/mies.	~£990/mies.	~£1 150/mies.
1000 tenantów	~£4600+/mies.	~£1 700/mies.	~£1 900/mies.

PaaS uderza w ścianę gdzieś przy 500 tenantach — tam włącza się ich plan Enterprise i cena skacze. Lambda wychodzi najtaniej na każdym poziomie powyżej darmowego tieru, bo płacisz tylko za faktyczne wywołania, a poza tym skaluje się do zera. VPS jest konkurencyjny i nie wiąże z żadnym dostawcą, ale stałe koszty serwera sprawiają, że w przedziale 100–500 tenantów wychodzi drożej niż Lambda.

Największy koszt to baza danych, nie compute. Przy 1000 tenantach sam managed Postgres kosztowałby więcej niż cała platforma obliczeniowa — w każdym z trzech wariantów. Na ścieżce VPS zamiana na self-hosted Postgres dramatycznie obniża rachunek. Największą oszczędność dała decyzja o bazie danych, nie o tym, na czym chodzi aplikacja.

Nasza rekomendacja: Na razie zostań, gdzie jesteś — zero narzutu operacyjnego, szybka iteracja, na tym etapie to się opłaca. Ale zbieraj metryki użycia, żeby decyzja o przeprowadzce opierała się na liczbach, a nie na przeczuciu. Kiedy nadejdzie moment — przenoś się na AWS Lambda.

Cała analiza zajęła kilka dni. Uchroniła klienta przed przeprowadzką za wczesną (strata czasu inżynierów) i za późną (uderzenie w próg kilku tysięcy funtów, którego nie widzieli). Takiej roboty żaden kalkulator za Ciebie nie zrobi.

Jak korzystać z kalkulatora efektywnie

Po przeprowadzeniu kilkudziesięciu klientów przez ten proces, oto nasz schemat:

Zacznij od jednego scenariusza, nie od całej infrastruktury. Oszacuj najpierw swoje najważniejsze obciążenie. Dopiero potem dodawaj resztę.

Używaj funkcji udostępniania. Kalkulator pozwala eksportować szacunki i dzielić się nimi przez link. Wyślij go zespołowi do przeglądu zanim podejmiecie decyzję. My wysyłamy takie szacunki każdemu klientowi jako część propozycji architektury.

Weryfikuj co miesiąc przez pierwszy kwartał. Twój początkowy szacunek będzie niedokładny — to normalne. Porównaj go z faktycznym rachunkiem w Cost Explorer po pierwszym miesiącu, zidentyfikuj luki i skoryguj. Do trzeciego miesiąca Twoje szacunki powinny trafiać z dokładnością do 10%.

Nie optymalizuj zanim nie zmierzysz. Widzimy firmy, które kupują Reserved Instances w pierwszym miesiącu, bo „oszczędza pieniądze". Owszem — jeśli wiesz, co rezerwujesz. Jedź na on-demand przez 2–3 miesiące, poznaj swoje faktyczne wzorce użycia, a potem dopiero się zobowiązuj.

Co powinien zawierać Twój szacunek

Zanim uznasz oszacowanie za gotowe, upewnij się, że uwzględniłeś:

Compute (Fargate, Lambda lub EC2)
Baza danych (RDS lub DynamoDB)
Storage (S3)
CDN (CloudFront)
Load balancer (ALB)
NAT Gateway (dodaj — kalkulator Ci o nim nie przypomni)
DNS (Route 53 — ~2 zł/hosted zone/miesiąc plus opłaty za zapytania)
Monitoring (CloudWatch — minimum to podstawowe logowanie i alarmy)
15–20% buforu na transfer danych, opłaty dodatkowe i niespodzianki

Zsumuj to i będziesz miał kwotę, z którą możesz spokojnie pójść na spotkanie budżetowe.

W Otocolobus pomagamy firmom MŚP oszacować, zbudować i zoptymalizować ich infrastrukturę AWS. Przeszedłeś przez kalkulator i chcesz, żeby ktoś sprawdził Twoje liczby? A może wolisz pominąć zgadywanie? Odezwij się — przejdziemy przez Twój konkretny przypadek.