Porównanie chmur: AWS, Azure, GCP – ile kosztuje mały projekt i co dostajesz?

Założenia: czym jest „mały projekt” i jakie są scenariusze

Jak rozumieć „mały projekt” w chmurze

Mały projekt w chmurze AWS, Azure czy GCP to zazwyczaj prosta aplikacja, która ma obsłużyć pierwszych użytkowników, testy biznesowe lub niewielki zespół wewnętrzny. Z punktu widzenia kosztów kluczowe jest to, że mówimy o niewielkim obciążeniu i raczej pojedynczym środowisku produkcyjnym + ewentualnie testowym, a nie o skomplikowanym, wieloregionowym systemie.

Na potrzeby porównania można przyjąć, że „mały projekt” ma następujące cechy:

• kilkuset – kilku tysięcy użytkowników miesięcznie, bez ciężkiej analityki czy streamingu wideo,
• 1–2 niewielkie instancje obliczeniowe (VM / kontenery / PaaS),
• zarządzana baza danych o rozmiarze raczej w dziesiątkach niż setkach gigabajtów,
• kilkadziesiąt – kilkaset GB danych w storage na pliki i backupy,
• prostą sieć, bez VPN-ów, private linków i kilku VPC/VNetów na środowisko,
• podstawowy monitoring i logi, bez rozbudowanych rozwiązań observability.

Chodzi więc nie o studencki projekt na weekend, ale też nie o system klasy enterprise. To coś pomiędzy: już ma prawdziwych użytkowników i SLA, ale jeszcze nie wymaga osobnego działu SRE.

Trzy główne scenariusze małych projektów

Mały projekt w chmurze ma różne oblicza – koszt i wybór usług zależy mocno od scenariusza. Najczęściej pojawiają się trzy profile:

• Projekt hobbystyczny / strona plus prosty backend – blog, landing, mała aplikacja do własnego użytku, proste API. Tu nacisk jest na możliwie niski koszt miesięczny, nawet kosztem mniejszej niezawodności. Często da się zmieścić w free tier lub okolicach kilku–kilkunastu dolarów.
• MVP startupu / mały SaaS – aplikacja webowa lub mobilna z backendem, która ma obsłużyć pierwszych płacących klientów. Priorytet: przewidywalne koszty, sensowna wydajność, łatwość rozbudowy. Tu zwykle pojawiają się już zarządzane bazy relacyjne, load balancer, porządne logi.
• Małe środowisko firmowe – np. wewnętrzny system CRM, aplikacja do raportowania, narzędzie dla kilku–kilkunastu pracowników. Tu mocniej liczy się security, zgodność z politykami IT, backupy, czasem integracja z AD/Entra ID – a to zwiększa koszyk usług i potencjalne koszty.

Między tymi scenariuszami różni się przede wszystkim: liczba środowisk (prod/test/stage), wymagania SLA, ilość ruchu i to, jak bardzo jesteś wrażliwy na awarie. Ale zestaw bazowych usług pozostaje w dużej mierze podobny.

Wspólne elementy małego projektu

Bez względu na to, czy wybór padnie na AWS, Azure czy GCP, koszyk podstawowych komponentów dla małego projektu wygląda z grubsza tak samo:

• Compute – czyli zasoby obliczeniowe:
  • maszyny wirtualne (EC2, Azure VM, Compute Engine), lub
  • rozwiązania PaaS / kontenerowe (Elastic Beanstalk, App Service, Cloud Run, GKE/AKS/EKS w małej skali).
• Baza danych – zwykle zarządzana baza relacyjna, np.:
  • AWS RDS (MySQL/PostgreSQL),
  • Azure Database for PostgreSQL / Azure SQL Database,
  • Cloud SQL w GCP.

  Dodatkowo czasem prosty NoSQL (DynamoDB, Cosmos DB, Firestore) do sesji, cache’u czy dokumentów.

• Storage na pliki – odpowiednik „dysku sieciowego” i magazynu na statyczne pliki:
  • AWS S3,
  • Azure Blob Storage,
  • Google Cloud Storage.
• Sieć i dostęp od zewnątrz:
  • adresy IP,
  • load balancer (Application/Network LB, Azure Load Balancer / Application Gateway, Cloud Load Balancing),
  • DNS (Route 53, Azure DNS, Cloud DNS),
  • transfer danych wychodzących do internetu.
• Monitoring i logi – klasyczne minimum:
  • metryki zużycia CPU/RAM/dysku,
  • logi aplikacyjne i systemowe,
  • alerty przy awarii lub przekroczeniu budżetu.

Ten pakiet jest dobrą bazą do porównywania cen między AWS, Azure i GCP. Dodatkowe usługi (kolejki, CDN, wysyłka maili, funkcje serverless) oczywiście wpływają na rachunek, ale w małym projekcie często da się je dodać później, gdy aplikacja już „zaskoczy”.

Co świadomie pomijamy, żeby nie zamulić obrazu

Porównując koszty małego projektu, można bardzo łatwo wpaść w pułapkę zbyt szczegółowych scenariuszy. Dla przejrzystości warto na starcie odsunąć na bok elementy typowe raczej dla większych wdrożeń:

• rozbudowane sieci (kilka VPC/VNet, peering, VPN-y do on-premise, direct connect / express route),
• zaawansowany security stack (WAF, SIEM, osobne konta/projekty per zespół, HSM),
• systemy big data, hurtownie danych, streaming, AI/ML na dużą skalę,
• dedykowane rozwiązania HA i DR w wielu regionach.

One są ważne, ale znacząco podnoszą koszt i rzadko wchodzą w skład pierwszej wersji małego projektu. Skupienie się na podstawach daje sensowniejsze liczby i pozwala lepiej ocenić, na co naprawdę pójdzie pierwszy budżet.

Horyzont czasu: miesięczny vs roczny koszt

Większość cenników chmurowych podaje stawki godzinowe. Większość zespołów myśli jednak w kategoriach miesięcznego lub rocznego budżetu. To powoduje naturalne rozjazdy, jeśli przeliczenia robi się „na oko”.

Dla małych projektów praktyczne jest podejście:

• szacowanie podstawowego scenariusza w skali miesiąca (co faktycznie zobaczysz na fakturze),
• zderzenie go z wariantem rocznym przy założeniu rabatów za rezerwacje / commitment (gdzie to ma sens),
• sprawdzenie, co da się wziąć „za darmo” z free tier i w jakim okresie (pierwsze 12 miesięcy vs permanentny darmowy plan).

Dopiero na takiej siatce porównanie AWS, Azure i GCP dla małego projektu staje się czytelne i realne, a nie akademickie.

Jak rozliczają AWS, Azure i GCP – fundamenty modelu kosztowego

Model pay‑as‑you‑go i minimalne jednostki rozliczeniowe

Wszystkie trzy główne chmury opierają się na zasadzie pay‑as‑you‑go – płacisz za zasoby, które faktycznie zużywasz. Podstawowe kategorie to:

• czas działania zasobów obliczeniowych (CPU/RAM instancji, funkcji serverless, kontenerów),
• rozmiar i czas przechowywania danych (GB‑miesiąc dla storage, bazy),
• transfer danych (głównie wychodzący – egress – w GB),
• operacje I/O (requesty do storage, operacje na bazie),
• specjalne jednostki, np. „zapytań” w API (usługi typu Vision, Translate, itp.).

Różnice pojawiają się na poziomie minimalnej jednostki rozliczeniowej dla compute:

• AWS – VM (EC2) liczone są co do sekundy, ale z minimalnym progiem 1 minuty,
• Azure – większość VM rozlicza w modelu minutowym/godzinowym, ale dla App Service i funkcji pojawiają się dedykowane jednostki (sekundy + pamięć),
• GCP – szczególnie agresywnie rozlicza co do sekundy dla VM i ma naturę „przyjazną krótkim workloadom”, choć przy małym projekcie ma to marginalne znaczenie.

Jeżeli mały projekt ma działać 24/7, różnice między sekundowym a godzinnym rozliczaniem nie mają aż tak dużego wpływu jak przy sporadycznych zadaniach batchowych. Znacznie mocniej na rachunek działa wybór rozmiaru instancji, regionu i typu storage.

Rezerwacje, zobowiązania i rabaty za użycie

Każdy dostawca ma swój mechanizm „nagradzania” za przewidywalne, długoterminowe użycie. Dla małego projektu może to być sposób na obniżenie kosztów nawet o kilkadziesiąt procent, ale kosztem elastyczności.

• AWS:
  • Reserved Instances – głównie dla EC2, RDS; zobowiązujesz się do wykorzystania konkretnego typu instancji przez 1 lub 3 lata, w zamian za niższą stawkę,
  • Savings Plans – deklarujesz stały poziom wydatków na compute (np. X USD/h) niezależnie od konkretnych typów instancji; bardziej elastyczne niż tradycyjne RI.
• Azure:
  • Reserved VM Instances – podobnie jak w AWS, rezerwacje 1‑ i 3‑letnie, również dla baz danych i innych usług,
  • Hybrid Benefit – dodatkowe oszczędności, jeśli używasz własnych licencji Windows/SQL Server.
• GCP:
  • Committed Use Discounts – zobowiązanie do określonego poziomu zużycia CPU/RAM przez 1 lub 3 lata, w zamian za zniżki,
  • Sustained Use Discounts – automatyczny rabat, gdy dana maszyna działa przez znaczną część miesiąca.

Przy małym projekcie, szczególnie we wczesnej fazie (MVP, testy), sztywne commit’y na 1–3 lata rzadko są dobrym pomysłem. Rozsądniej jest zacząć od pay‑as‑you‑go, odczekać kilka miesięcy, ustabilizować architekturę i dopiero wtedy rozważyć rezerwacje na najstabilniejsze elementy (np. produkcyjna baza RDS lub Cloud SQL).

Free tier vs trial credit – jak różnie startuje się w AWS, Azure i GCP

Każda z chmur ma inny sposób „przywitania” nowych użytkowników darmowymi zasobami:

• AWS:
  • tzw. Always Free (pewne limity usług dostępne za darmo na stałe, np. Lambda do określonej liczby wywołań, mały S3),
  • 12‑miesięczny free tier – np. 750 godzin miesięcznie dla t2.micro/t3.micro w EC2, mała RDS, niewielkie ilości S3 i transferu,
  • dodatkowe promocje akceleratorów dla startupów (np. AWS Activate) – oddzielny temat.
• Azure:
  • kredyt startowy na 30 dni (konto trial) – można wydać na niemal dowolne usługi,
  • wybrane usługi z darmowymi tierami (App Service Free, B1/Basic do testów, mały poziom Storage, Functions),
  • pule free w niektórych usługach PaaS (np. baza w niewielkim, darmowym planie przez ograniczony czas).
• GCP:
  • kredyt startowy (kilkaset USD) do wykorzystania w określonym czasie,
  • Always Free Tier – niewielkie, ale realne limity: mała VM e2‑micro, Cloud Functions, Firestore, pewien poziom Cloud Storage i egress,
  • często atrakcyjny dla małych, lekkich projektów dzięki darmowej małej VM i storage’owi.

Różnica praktyczna: AWS i GCP mocno premiują projekty, które zmieszczą się w free tier (szczególnie dla e2‑micro / t2.micro + małe bazy), Azure jest bardziej nastawiony na krótkotrwały trial z większą swobodą, ale później szybciej można wpaść w płatne plany PaaS.

Dlaczego sama tabela cen to za mało

Cenniki AWS, Azure i GCP wyglądają podobnie: stawka X za godzinę instancji, Y za GB‑miesiąc w storage, Z za GB transferu. Bez zrozumienia, jak usługi liczą operacje i transfer, można wyciągnąć zupełnie fałszywe wnioski.

Typowe przykłady:

• tania stawka za GB w storage, ale droga stawka za operacje (np. duże ilości małych plików w S3/Blob/Cloud Storage),
• bezkosztowe logi w małej skali, które po kilku tygodniach bez retencji generują niespodziewany rachunek,
• niewidoczny w kalkulatorze koszt transferu między strefami dostępności w ramach regionu, jeśli aplikacja korzysta z kilku AZ,

Ukryte koszty: transfer, logi, monitoring

Nawet przy małym projekcie końcowy rachunek często „puchnie” nie od maszyn wirtualnych, tylko od drobnicy:

• transferu wychodzącego z chmury (egress),
• logów i metryk zbieranych domyślnie,
• backupów, snapshotów, kopii w innych regionach.

Typowy scenariusz: prosta aplikacja webowa, wszystko stoi na jednej małej instancji, a mimo to rachunek jest wyższy o kilkadziesiąt procent przez monitoring i nadmiar logów.

• Transfer – ruch do internetu jest płatny w każdej chmurze, ruch wewnątrz tej samej strefy / regionu bywa darmowy lub tańszy. Architektura typu „wszystko w jednym AZ i w tym samym VPC/VNet/Network” zwykle minimalizuje koszt egress.
• Logi – przy starcie domyślne ustawienia retencji (30–90 dni) często wystarczą. W małym projekcie warto:
  • ustawić krótszą retencję dla logów technicznych (np. 7–14 dni),
  • odseparować logi audytowe/bezpieczeństwa z dłuższą retencją (np. 90 dni) w osobnej klasie storage.
• Monitoring – metrici są tanie, ale dashboardy + dodatkowe funkcje (np. dłuższe przechowywanie metryk, zaawansowane alerty) szybko dokładają kilka–kilkanaście USD miesięcznie, jeśli zostawisz wszystko w „domyślnym” planie.

Minimalna higiena kosztowa na starcie:

• zdefiniuj politykę retencji logów (osobno dla aplikacji, bazy, infrastruktury),
• ustaw alert kosztowy na poziomie całego konta (próg np. 50–100% zakładanego budżetu),
• unikaj wieloregionowych replik bazy / storage, dopóki naprawdę ich nie potrzebujesz.

Co wchodzi w koszt małego projektu: wspólny „koszyk usług”

Minimalne komponenty typowej aplikacji webowej

Żeby porównanie było sensowne, trzeba patrzeć na podobny zestaw usług w każdej chmurze. Dla małej aplikacji webowej (np. prosty SaaS B2B) bazowy „koszyk” zazwyczaj obejmuje:

• warstwę web/API – instancja VM, kontener lub usługa PaaS (App Service, App Runner, Cloud Run),
• bazę danych – zarządzana baza SQL (RDS, Azure SQL, Cloud SQL) albo lekka NoSQL,
• storage plików – obiektowy (S3, Blob, Cloud Storage) na uploady użytkowników, statyczne pliki, backupy,
• DNS + certyfikat SSL – Route 53 / Azure DNS / Cloud DNS + certyfikaty (czasem darmowe),
• monitoring i logi – CloudWatch / Azure Monitor / Cloud Logging & Monitoring,
• ewentualnie cache – mały Redis lub podobny, jeśli aplikacja tego potrzebuje.

Taki zestaw spokojnie obsłuży:

• kilka–kilkanaście tysięcy użytkowników miesięcznie (light usage),
• kilka–kilkadziesiąt requestów na sekundę w godzinach szczytu,
• kilka–kilkadziesiąt GB danych w bazie i storage po pierwszych miesiącach.

Uśrednione założenia obciążenia

Żeby policzyć orientacyjny koszt, przyjmijmy wspólne założenia:

• aplikacja działa 24/7, brak agresywnego skalowania w dół w nocy,
• średnio 50–100 równoległych użytkowników w szczycie,
• baza relacyjna o rozmiarze rzędu kilkudziesięciu GB po kilku miesiącach,
• ok. 100 GB plików w storage (uploady, logi, backupy),
• transfer wychodzący do internetu rzędu 200–500 GB/miesiąc.

Nie są to wartości laboratoryjne – tak wyglądają pierwsze wersje sporej części młodych SaaS-ów, wewnętrznych portali czy prostszych API wystawionych do klientów.

Warianty architektury: IaaS vs PaaS vs serverless

Nawet mały projekt można zbudować na trzy różne sposoby, które mocno zmieniają kształt rachunku:

• IaaS (VM‑ki) – jedna lub dwie instancje (prod + staging), samodzielne zarządzanie OS, aktualizacjami, skalowaniem.
• PaaS (App Service / App Engine / App Runner / Cloud Run) – platforma bierze na siebie OS, część skalowania i aktualizacji, płacisz za instancje aplikacyjne lub uśredniony wymiar zasobów.
• Serverless (FaaS + zarządzana baza/serverless DB) – płacisz per wywołanie i czas wykonania. Opłacalne, gdy obciążenie jest nieregularne lub niskie średnio‑długoterminowo.

Dla porównania kosztów małego projektu najczęściej sensowny jest wariant PaaS dla warstwy web/API i zarządzana baza. W dalszej części przybliżenia będą oparte właśnie na takim modelu.

AWS – ile realnie kosztuje mały projekt

Przykładowy koszyk usług AWS dla małej aplikacji

Przykładowa, prosta konfiguracja w AWS, która pokrywa typowy mały projekt:

• Warstwa aplikacji: AWS Fargate (kontenery) lub AWS App Runner / ewentualnie mała EC2,
• Baza danych: Amazon RDS (PostgreSQL / MySQL) w małym rozmiarze, single‑AZ,
• Storage: Amazon S3 na pliki aplikacji i backupy,
• DNS + certyfikat: Route 53 + AWS Certificate Manager (certyfikat publiczny darmowy),
• Monitoring i logi: CloudWatch (metryki + logi aplikacji),
• Load Balancer: Application Load Balancer, jeśli aplikacja ma skalę i kilka instancji.

Dla MVP lub wewnętrznej aplikacji często wystarczy jedno środowisko produkcyjne + lekkie testowe (może być tańsze, wyłączane poza godzinami pracy).

Warstwa aplikacji na AWS: EC2 vs Fargate vs App Runner

Przy małym projekcie wybór między EC2 a wyższymi abstrakcjami to głównie kompromis między czasem zespołu a ceną.

• EC2 – najniższy poziom. Mała instancja generacji t3/c5/c6 może spokojnie obsłużyć MVP. Zyskujesz pełną kontrolę, ale sam dbasz o aktualizacje, autoscaling, itp.
• Fargate – uruchamiasz kontenery bez zarządzania klastrem. Płacisz za vCPU i RAM na sekundę. Przy stałym, całodobowym obciążeniu koszt często zbliżony do EC2, ale zyskujesz mniej „operacji” po swojej stronie.
• App Runner – jeszcze prostsze podejście: wrzucasz obraz kontenera lub repozytorium kodu, resztą zajmuje się usługa. Dla typowego małego projektu to często najbardziej pragmatyczny wybór.

Praktyczna wskazówka: jeśli zespół nie ma dużego doświadczenia z infrastrukturą, a projekt nie ma wyśrubowanych wymagań wydajnościowych, App Runner lub Fargate zwykle zapewnią najniższy „całkowity koszt posiadania” (TCO), nawet jeśli na fakturze compute wyjdzie odrobinę drożej niż goła EC2.

Baza danych w AWS dla małego projektu

Najczęstszy wybór to RDS PostgreSQL/MySQL w małym wariancie:

• jedna instancja (single‑AZ),
• automatyczne backupy (np. 7 dni),
• brak Multi‑AZ na start, jeśli akceptujesz krótką przerwę w razie awarii.

Najbardziej boli nie tylko sama instancja, ale także:

• storage bazy (GB‑miesiąc, IOPS),
• snapshoty – pełne backupy trzymane miesiącami, jeśli nie ustawisz polityki czyszczenia.

Dla małego projektu lepiej wybrać skromniejszy rozmiar instancji i uprościć architekturę (single‑AZ), niż oszczędzać na backupach. Opcja Multi‑AZ może poczekać do momentu, gdy aplikacja zacznie przynosić realne przychody.

Storage, CDN i transfer w AWS

Amazon S3 to naturalny wybór na statyczne pliki, logi i backupy:

• podstawowa klasa storage (Standard) na dane często używane,
• tańsze klasy (np. Infrequent Access, Glacier) na starsze backupy.

CDN (CloudFront) w małym projekcie bywa opcjonalny. Można zacząć bez niego, a włączyć dopiero przy większym ruchu lub globalnej publiczności. W podstawowym scenariuszu najważniejszy jest transfer wychodzący z regionu (S3, EC2, ALB) – właśnie on dodaje kilkanaście–kilkadziesiąt procent do miesięcznego rachunku przy rosnącym ruchu.

Logi i monitoring w AWS

CloudWatch jest domyślnym magazynem metryk i logów:

• metryki instancji i usług są tanie, często wliczone w usługę,
• logi aplikacyjne + retention to główny „niespodziewany” składnik kosztu.

Dobry nawyk na start:

• ustaw krótki retention dla logów aplikacyjnych (np. 7–14 dni),
• jeśli potrzebujesz dłuższej historii, eksportuj logi okresowo do S3 w tańszej klasie storage.

Jak wygląda miesięczny rachunek AWS dla małego projektu (orientacyjnie)

Przy realistycznym, małym projekcie z jedną instancją aplikacyjną, małą bazą RDS, S3 na pliki i sensownie ustawionymi logami, całkowity koszt często mieści się w przedziale kilkudziesięciu–kilkuset USD miesięcznie, zanim przekroczysz free tier i zaczniesz intensywnie rosnąć. Granicę przesuwa głównie:

• wybór wielkości instancji aplikacyjnej i bazy,
• ilość transferu wychodzącego,
• długość retencji logów i backupów.

Azure – ile realnie kosztuje mały projekt

Przykładowy koszyk usług Azure dla małej aplikacji

Dla prostego projektu w Azure typowy zestaw wygląda tak:

• Warstwa aplikacji: Azure App Service (Web App) w małym planie,
• Baza danych: Azure SQL Database lub Azure Database for PostgreSQL/MySQL w wariancie Single Server / Flexible Server,
• Storage plików: Azure Blob Storage,
• DNS + certyfikaty: Azure DNS + certyfikat (np. z App Service Managed Certificate lub zewnętrzny),
• Monitoring: Azure Monitor + Application Insights,
• Opcjonalnie: Azure Front Door lub Azure CDN, jeśli potrzebny jest CDN/load balancing globalny.

App Service wprowadza sporo wygody – deployment z GitHub, sloty, łatwe skalowanie – co dla małego zespołu jest realną oszczędnością czasu.

Warstwa aplikacji na Azure: App Service vs VM vs Container Apps

W małych projektach App Service jest najczęściej pierwszym wyborem:

• masz plan App Service (Basic/Standard) z określoną ilością CPU/RAM,
• na jednym planie możesz odpalić kilka aplikacji (prod, staging, API, panel admina),
• skalowanie poziome (więcej instancji) i pionowe (mocniejszy plan) jest dość proste.

Alternatywy:

• Azure VM – pełna kontrola, ale dodatkowa praca DevOps,
• Azure Container Apps / AKS – sensowne, jeśli od razu planujesz architekturę kontenerową; dla najmniejszych projektów to często strzelanie z armaty do muchy.

W ujęciu kosztowym mały plan App Service w trybie 24/7 zwykle kosztowo wypada zbliżenie do AWS‑owego App Runnera/Fargate.

Baza danych w Azure dla małego projektu

Najpopularniejsze opcje:

• Azure SQL Database – zarządzany SQL Server w modelu vCore lub DTU,
• Azure Database for PostgreSQL/MySQL – zarządzane warianty popularnych silników open source.

Różnice w modelu rozliczeń (DTU/vCore, provisioned vs serverless) przekładają się na to, jak przewidywalny jest rachunek:

• model provisioned (stała moc) – przewidywalny koszt, mniej niespodzianek,
• model serverless – potencjalnie niższy koszt dla sporadycznego ruchu, ale przy 24/7 bywa droższy i trudniejszy do odczytania.

Dla małego, stale działającego projektu prościej zacząć od provisioned w niższej klasie, a dopiero później myśleć o optymalizacji.

Storage, CDN i transfer w Azure

Azure Blob Storage pełni podobną rolę jak S3:

• kontenery na uploady użytkowników, statyczne pliki, backupy,

Najważniejsze punkty

• „Mały projekt” w chmurze to produkcyjna, ale nieskomplikowana aplikacja: kilka setek–tysięcy użytkowników miesięcznie, 1–2 niewielkie instancje, baza w dziesiątkach GB i proste środowisko prod + ewentualnie test.
• Kluczowe scenariusze to: projekt hobbystyczny (maksymalne cięcie kosztów, czasem w free tier), MVP startupu (zbalansowanie ceny, wydajności i skalowalności) oraz małe środowisko firmowe (większy nacisk na bezpieczeństwo, backupy, integrację z korporacyjnym IT).
• Koszyk bazowych komponentów jest w AWS, Azure i GCP praktycznie identyczny: compute (VM/PaaS/kontenery), zarządzana baza danych, storage na pliki, elementarna sieć (IP, DNS, load balancer, transfer) oraz podstawowy monitoring i logi.
• Różnice między scenariuszami wynikają głównie z liczby środowisk (prod/test/stage), wymagań SLA i wrażliwości na awarie, a nie z zupełnie innych usług – fundament pozostaje ten sam.
• Zaawansowana sieć, rozbudowany security stack, big data, AI/ML czy wieloregionowe HA/DR mocno podbijają koszty i zwykle nie są potrzebne w pierwszej wersji małego projektu.
• Planowanie budżetu wymaga patrzenia na koszty w skali miesiąca i roku, z uwzględnieniem rabatów za rezerwacje/commitment oraz realnego użycia darmowych limitów (free tier stały vs pierwsze 12 miesięcy).