Rosnący rachunek za chmurę: gdzie naprawdę ucieka kasa?
Co wiemy? Czego nie wiemy?
Co wiemy: miesięczny koszt w AWS, Azure lub GCP rośnie szybciej niż ruch czy przychody, a wydajność usług pozostaje akceptowalna. Czego nie wiemy: które zasoby są przewymiarowane, gdzie płacisz głównie za transfer danych, a gdzie „kapią” drobne, ale stałe opłaty za logi, snapshoty i nieużywane maszyny.
Aby obniżyć rachunek bez cięcia wydajności, trzeba najpierw oddzielić koszty „produkcyjne i konieczne” od „milczących przecieków”. W chmurze takie przecieki to przede wszystkim nadmiar mocy, nieużywane zasoby, niewłaściwe klasy storage, chaotyczny ruch sieciowy i brak polityk retencji danych.
Najczęstsze objawy marnotrawstwa bez degradacji wydajności
Środowiska testowe i deweloperskie działają całą dobę, mimo że zespół korzysta z nich 8–10 godzin dziennie.
Maszyny z niskim CPU i IO, ale wysokim kosztem (np. zbyt duża rodzina instancji lub niepotrzebna akceleracja sieciowa).
Ruch między strefami dostępności (AZ) i regionami jest wyższy niż ruch do użytkownika końcowego.
Logi i metryki przechowywane „na zawsze” w najdroższej klasie, mimo że przeglądane są tylko przez tydzień.
Słabe tagowanie – brak możliwości wskazania właściciela kosztu i priorytetu usługi w budżecie.
Mapa kosztów: compute, storage, sieć i usługi zarządzane
Największe pozycje na fakturze zwykle pochodzą z czterech kategorii: obliczenia, przechowywanie danych, transfer sieciowy oraz usługi zarządzane (bazy, analityka, kolejki). Oszczędności bez ryzyka spadku wydajności w praktyce osiąga się przez:
lepsze dopasowanie rozmiarów instancji i autoskaling zamiast stałej nadmiarowości,
właściwą klasę storage i polityki cyklu życia danych,
minimalizację płatnego transferu (egress, ruch między AZ/regionami, NAT),
rozsądne zobowiązania rabatowe (Savings Plans/Reservations/CUD) dopasowane do stabilnego zużycia.
Dlaczego koszty AWS, Azure i GCP puchną mimo stabilnych obciążeń
Nadmiar mocy „na wszelki wypadek”
Najczęstsza przyczyna to overprovisioning. Zespół dodał 50–100% zapasu, aby mieć spokój podczas pików. Po czasie piki są rzadkie, ale zapas został i kosztuje co godzinę. Pojawia się też „dryf konfiguracji”: migracje, update’y, nowe regiony – i rozmiar instancji podwaja się z braku uwagi.
W kontenerach dodatkowy problem to złe limity i żądania zasobów (requests/limits). Klastrom Kubernetesa przyznaje się więcej vCPU/RAM niż obciążenia zużywają, a autoskaler nie ma powodu, by skalować w dół.
Źródło: Pexels | Autor: Brett Jordan
Braki w tagowaniu i przypisaniu kosztów
Bez spójnych tagów (projekt, właściciel, środowisko, produkt) trudno odróżnić to, co rzeczywiście napędza biznes, od kosztów „porzuconych”. Brak właściciela = brak decyzji. W AWS, Azure i GCP jest to równie dokuczliwe, bo narzędzia do optymalizacji bazują na atrybutach zasobów – jeśli ich nie ma, rekomendacje są płaskie lub ignorowane.
Antywzorce architektoniczne i „szum” sieciowy
Chmurowe rachunki zjada głównie ruch między AZ/regionami i przez NAT. Mikroserwisy intensywnie rozmawiające między strefami powodują, że płacisz zarówno za ruch out, jak i in – wielokrotnie. Podobnie zbędne przetwarzanie zdarzeń i nadmierne logowanie (debug na produkcji) generuje stały strumień danych, który mnoży koszty przetwarzania, przechowywania i transferu.
Precyzyjna diagnoza: jak znaleźć duże oszczędności w 7 dni
Inwentaryzacja i tagi, bez których ani rusz
Zacznij od wyciągnięcia listy zasobów i rachunku w podziale na projekty/konta/subskrypcje i przypnij tagi/etykiety. Minimum:
Następnie wdroż politykę „no tag – no deploy” dla środowisk niekrytycznych i automatyczne uzupełnianie tagów przez IaC/cięcie budżetu.
Skup się na Top N i jednostkach biznesowych
Wylistuj Top 20 największych pozycji kosztowych. Dla każdej określ właściciela, SLO usługi, pory dnia z największym ruchem oraz minimalne i szczytowe usage metryki (CPU, pamięć, IO, QPS). Zestaw to z oczekiwanym czasem odpowiedzi i dostępnością. Pytanie kontrolne: które zasoby mają średnie użycie CPU/RAM < 25% w godzinach szczytu? To kandydaci do natychmiastowego „rightsizingu”.
Unit economics i progi bezpieczeństwa
Oblicz koszt na transakcję, sesję, GB przetworzonych danych lub inny sensowny wskaźnik. Dostosuj cele: „Zachować P95 latency i dostępność na poziomie 99,9%, jednocześnie obniżając koszt/1000 żądań o 20%”. Pozwoli to testować każdą optymalizację przeciwko realnym metrykom jakości.
Bezpieczne techniki oszczędności: cięcia, które nie naruszają SLO
Rightsizing i autoskaling zamiast stałej nadwyżki
Najtańszy „gigaherc” to ten, którego nie uruchamiasz. Zacznij od rekomendacji dostawców: AWS Compute Optimizer, Azure Advisor, GCP Recommender – porównaj je z P95/P99 metryk z produkcji. Dla usług webowych celuj w 40–60% średniego użycia CPU w szczycie po zmianie rozmiaru i zezwól autoskalerom pracować agresywniej w dół.
AWS: Auto Scaling Groups + target tracking, skale w dół szybciej (cooldown krótszy, termination policies „oldest first”).
Azure: VM Scale Sets ze skalowaniem po metrykach (CPU/QPS), dopnij Scheduled Events.
GCP: Managed Instance Groups z autoskalingiem po niestandardowych metrykach (np. latency z Cloud Monitoring).
Środowiska dev/test wygaszaj harmonogramem (np. 19:00–7:00 i weekendy). To szybkie 40–60% mniej godzin bez dotykania produkcji.
Spot/Preemptible/Low-priority: taniej, jeśli masz plan B
Wykorzystuj niestabilne instancje do zadań przerywalnych: batch, ETL, CI, render, workers bez stanu. Zabezpieczenia:
mieszanka 60–80% spot + 20–40% on-demand/reserved w grupie,
podział po wielu typach/rozmiarach (diversity) oraz wielu AZ,
checkpointing i idempotentność zadań, kolejka z retry (np. SQS/Pub/Sub/Service Bus),
w Kubernetes: osobne nodepool dla spot, PodDisruptionBudget, tolerations, priorytety.
Kubernetes bez „powietrza” w requestach
Najczęstszy wyciek to zawyżone requests. Zmierz P95 zużycia CPU/RAM per pod i ustaw requests blisko tych wartości; limits nieco wyżej lub bez limitów CPU dla bursty. Włącz HPA po metrykach aplikacyjnych (np. QPS, lag) i testowo VPA dla serwisów stateful poza krytycznym ruchem. Cluster autoscaler musi mieć możliwość skali w dół – zbyt restrykcyjne PDB i anty-affinity potrafią blokować oszczędności. W EKS rozważ Karpenter do szybszego bin-packingu.
Dane i storage: ta sama dostępność, mniejszy rachunek
Obiektowy: klasy i retencja szyte na wzorzec dostępu
Ułóż polityki cyklu życia w S3/Blob/GCS: hot (0–7 dni) → warm (30–90) → cold/archewum. Dla rzadko czytanych logów i backupów przełącz na klasy z niższym kosztem GB, ale z uwzględnieniem minimalnych okresów przechowywania i opłat za odczyt/rekonstrukcję.
AWS: Standard → Standard-IA/One Zone-IA → Glacier Instant/Flexible/Deep Archive.
Azure: Hot → Cool → Archive; włącz automatyczne tiering i polityki rehydracji na okno SLA.
GCP: Standard → Nearline/Coldline → Archive; użyj lifecycle na prefixach, nie na całych bucketach bez wyjątku dla hot.
Pułapka: migracja „na hurra” do archiwum, a potem masowe odczyty do analityki – rachunek skacze na opłatach za retrieval. Zasada: najpierw rozdziel strumienie danych na „gorące do zapytań” i „zimne do compliance”.
Blokowy i plikowy: płać za IOPS, których naprawdę używasz
Przegląd wolumenów i IOPS:
AWS: przełączenie z gp2 na gp3 (taniej za GB, niezależne IOPS/throughput), IO2 tylko tam, gdzie wymagane trwałe IOPS. Włącz autoskalę storage w RDS/Aurora ostrożnie – bez nadmiernego buforowania po skokach.
Azure: dobierz między Premium SSD v2/Standard SSD a Ultra tylko dla krytycznych I/O; unikaj nieużywanych provisioned IOPS.
GCP: PD Balanced dla większości, PD SSD dla krytycznych; sprawdź, czy rozmiar wolumenu nie jest sztucznie powiększony „dla IOPS”.
Snapshoty automatyzuj i tnij retencję (np. dzienne 7 dni, tygodniowe 4 tygodnie, miesięczne 6–12). Typowy przeoczenie: pozostawione osierocone dyski po skasowanych VM.
Sieć i transfer: mniej ruchu płatnego, ten sam rezultat
Chattiness mikroserwisów i geografii
Drogi jest ruch między AZ/regionami i do Internetu. Ogranicz go przez:
lokalność wywołań (zone affinity, preferencje routingu w service mesh),
cache i agresywne TTL dla odpowiedzi,
przeniesienie „gadatliwych” duetów serwisów do tej samej AZ (z planem HA przez replikę, nie przez chat).
Dla ruchu do użytkowników wykorzystaj CDN (CloudFront/Cloud CDN/Azure CDN), kompresję i HTTP/2/3. Zmniejsza to egress z originu.
Bazy i analityka: tę sama wydajność, mniejszy rachunek
Problem: szybkie warstwy „na zapas” i bezrefleksyjny tryb always-on
Co wiemy? Zarządzane bazy i silniki analityczne szybko rosną w koszcie, gdy wybierasz najwyższe klasy lub utrzymujesz szczytową moc całą dobę. Czego nie wiemy? Które parametry naprawdę utrzymują P95/P99 i ile z nich można zdjąć bez dotykania SLO.
Przyczyna zwykle jest prosta: domyślne rozmiary, brak poolingu połączeń, brak rozdziału ścieżek odczyt/zapis i zbyt krótka retencja cache na poziomie aplikacji.
Rozwiązania: dopasuj klasę, model skali i wzorzec zapytań
AWS: RDS/Aurora – przejrzyj rozmiary instancji pod realne P95 CPU/IO i pamięć bufora. Rozważ Aurora Serverless v2 tam, gdzie obciążenie faluje. Read-replica do odczytów zamiast powiększania mastera. Connection pooling (RDS Proxy) dla burstów. Zmniejsz IOPS/throughput wolumenów gp3 do wartości obserwowanych.
Azure: Azure SQL – dopasuj między vCore a DTU; wielu klientom wystarcza niższy tier z autoskalą. W Hyperscale nie płać za zapas, którego nie wykorzystasz – skala pozioma odczytów często tańsza niż większy compute. Sprawdź Intelligent Query Processing i cache na poziomie aplikacji.
GCP: Cloud SQL – włącz autoskalę storage i zbij rozmiar maszyny do punktu, w którym buffer cache nie jest sztucznie „na zapas”. Dla obciążeń analitycznych rozważ BigQuery zamiast własnych klastrów ETL, ale z kontrolą kosztów zapytań.
Analityka:
BigQuery: partycjonuj po czasie i klastruj po kolumnach filtrujących; ustaw „maximum bytes billed” w narzędziach BI; reużywaj materialized views. Jeśli przewidywalne obciążenie – rozważ rezerwacje slotów na baseline, resztę zostaw on-demand.
Redshift: RA3 (storage odseparowane od compute) i pause/resume klastrów poza godzinami pracy raportów. W Serverless pilnuj limitów RPU i monitoruj concurrency scaling.
Azure Synapse: pauzuj dedicated SQL pools, a krótkie batch’e ładuj okienkami zamiast stałego streamingu.
Czego unikać: zwiększania instancji „bo rośnie latency” bez profilu zapytań – często wina brakujących indeksów lub N+1 w ORM. Każda dodatkowa replika i scenariusz DR między regionami to osobny koszt storage i egress; uruchamiaj je tylko dla systemów w tierze krytyczności, który tego wymaga.
Krótki przykład: zespół raportowy przerzucił nocne ładunki do BigQuery z surową partycją dzienną i limitem „maximum bytes billed”. Ten sam dashboard przestał skanować pełne tabele – koszt spadł kilkukrotnie, a P95 odpowiedzi został utrzymany.
Obserwowalność i pipeline’y: tnij szum, nie sygnał
Problem: metryki o wysokiej krotności i logi w trybie debug na produkcji
Nadwyżka kosztów rodzi się z kardynalności (metryki z labelami o wielu wartościach), pełnego próbkowania trace’ów i nieograniczonej retencji logów aplikacyjnych.
Rozwiązania: budżet kardynalności, sampling i retencja per klasa zdarzeń
Logi: ustaw retencję różną dla klas (aplikacyjne 7–14 dni, audytowe dłużej). W AWS CloudWatch ustaw polityki retencji i eksport do S3 z kompresją + lifecycle; w Azure Monitor/Log Analytics nałóż data collection rules i limity ingestion; w GCP Cloud Logging użyj exclusion filters i log buckets z krótszą retencją.
Trace’y: dynamiczny sampling (np. 5–10% ruchu stałego, 100% przy błędach/timeoutach). W OpenTelemetry ogranicz atrybuty o wysokiej zmienności.
Metryki: agreguj po wymiarach potrzebnych do SLO, a „long tail” wrzucaj jako logi licznikowe tańsze w składowaniu. Zdefiniuj budżet liczby szeregów czasowych na usługę.
CI/CD i artefakty: czyść obrazy w rejestrach (retencja tagów), limituj liczbę buildów nocnych i skróć przechowywanie artefaktów. Cache’y zależności trzymać w tańszym storage z TTL.
Pułapka: przeniesienie całości logów do „tańszego” object storage bez indeksu – odzyskasz koszt, ale stracisz czas reakcji. Rozwiązanie pośrodku: krótkie okno „hot” w systemie zapytań + archiwum do długiego przechowywania.
Rabaty i zobowiązania: jak kupować, żeby nie żałować
Problem: presja na natychmiastowe rabaty i ryzyko „zacementowania” złej bazy
Kiedy rachunek rośnie, kuszą zobowiązania: AWS Savings Plans/RI, Azure Reservations/Savings Plans, GCP CUD. Błąd: kupić dużo i szybko, zanim uporządkujesz rozmiary i harmonogramy.
Rozwiązania: najpierw baseline, potem schodkowe zakupy
Zakres i termin: zaczynaj od 1 roku i pokrycia 40–60% stabilnego zużycia (po rightsizingu). Dokładaj co miesiąc małe transze, obserwując wykorzystanie.
Elastyczność: preferuj AWS Savings Plans Compute/Convertible RI oraz Azure/AWS Savings Plans, gdy miks typów maszyn się zmienia. W GCP stawiaj na CUD vCPU/RAM dla GCE i odrębnie dla GKE/Cloud Run, jeśli to twoja baza.
Podział: kupuj per region i per warstwa (prod osobno od dev/test), by uniknąć niedopasowań.
FinOps operacyjnie: tagi, budżety i polityki zamiast „gaszenia pożarów”
Problem: koszty bez właścicieli i brak hamulców na etapie tworzenia zasobów
Gdy nie wiadomo, kto płaci i za co, nikt nie czuje presji, by optymalizować. Zasoby powstają spoza szablonów, bez tagów i limitów. Co wiemy? Rachunek rośnie w rytmie nowych projektów. Czego nie wiemy? Które zespoły generują lwią część kosztów i gdzie uciekają pieniądze poza planem.
Rozwiązania: wymuś identyfikację kosztów u źródła i automatyzuj progi
Tagging/labeling jako kontrakt: właściciel, produkt, środowisko, krytyczność/SLA, centrum kosztów.
AWS: włącz cost allocation tags (najpierw user-defined, potem AWS-generated), wymuś tagi w CloudFormation/Terraform; pilnuj w OU przez SCP.
Azure: tagi na Management Group/Subscription + Azure Policy blokujące tworzenie zasobów bez wymaganych tagów; dziedziczenie na Resource Groups.
GCP: labels i tagi organizacyjne, separacja kosztów per Project/Folder; włącz eksport billing do BigQuery i buduj widoki alokacyjne.
Budżety i alerty: ustaw progi ostrzegawcze i twarde alarmy.
AWS Budgets: alerty procentowe + działania przez SSM/Automation (np. stop dev-instances nocą).
Azure Cost Management: budget alerts i akcje remediacyjne przez Functions/Logic Apps.
Polityki ograniczające: tylko zatwierdzone regiony i klasy maszyn, limity public IP, wymagana enkrpycja i lifecycle na storage.
AWS: SCP + Service Quotas i IAM condition keys po tagach.
Azure: Azure Policy „deny/modify” (np. wymuś premium tylko w prod).
GCP: Organization Policy (blokuj drogie GPU/regiony) i limity kwotowe.
Widoczność: codzienna zrzutka kosztów do warstwy analitycznej.
AWS: Cost and Usage Report do S3 + Athena/QuickSight/CUDOS.
Azure: eksport do Storage/Log Analytics; raporty w Cost Management + Kusto.
GCP: Cloud Billing Export do BigQuery + Looker Studio/ własne widoki miedzy projektami.
Pułapka: retro-tagowanie po fakcie i „zgadywanie” alokacji. Bez blokujących polityk nowe zasoby będą dalej „bezpańskie”. Zasada: najpierw enforcement, potem porządki wstecz.
Serverless i event-driven: płacisz za wynik, ale konfiguracja potrafi podwoić rachunek
Gdzie ucieka koszt w praktyce
Nadmiarowa pamięć i zbyt długie time-outy, provisioned/min concurrency ustawione na stałe oraz zbyt drobny batch zdarzeń. Do tego logowanie każdego wywołania na poziomie INFO/DEBUG i nadmierna liczba funkcji per endpoint.
Jak skalibrować bez utraty SLO
Pamięć vs czas: test A/B dla funkcji – większa pamięć skraca czas wykonywania i bywa tańsza w sumie (mniej ms-billed).
AWS Lambda: wyznacz „sweet spot” memory/CPU (np. przez power tuning), skoryguj timeouty do realnych P99 + margines.
Azure Functions: porównaj Consumption vs Premium; Premium opłaca się przy stałym ruchu i potrzebie always ready.
GCP Cloud Functions/Run: Cloud Run – zwiększ concurrency (np. 20–80), ogranicz max instances i unikaj „min instances” poza hot-path.
Batching i kolejki:
AWS: SQS/Kinesis – zwiększ batch size, włącz partial batch response, by nie powtarzać całych partii.
Azure: Event Hubs/Service Bus – dopasuj prefetch i batch, ustaw auto-complete rozważnie.
GCP: Pub/Sub – max messages i max bytes na pull; włącz exactly-once tylko tam, gdzie to naprawdę potrzebne.
Cold starts: pre-warming tylko dla funkcji krytycznych dla P95.
Lambda: provisioned concurrency w oknach szczytu, nie 24/7.
Cloud Run: min instances na 0 w niekrytycznych ścieżkach, 1–2 w gorących.
Azure: always on tylko w planach, które obsługują kluczowe API.
I/O i sieć: łącz operacje w transakcje, ogranicz wywołania do baz z funkcji (lepiej batch po kolejce), kompresuj payloady i unikaj czatliwej orkiestracji.
Obserwowalność: sampling logów i trace’ów również dla serverless; wyłącz request/response body w logach poza diagnostyką incydentalną.
Krótki przykład: zespół miał 100% provisioned concurrency na wszystkich funkcjach w godzinach nocnych. Po redukcji do 0–10% poza pikiem i zwiększeniu concurrency w Cloud Run, rachunek spadł bez wzrostu P95.
Czego unikać: „jeden endpoint – jedna funkcja” bez uzasadnienia wydajności. Agregacja kilku pokrewnych operacji w jeden proces często ogranicza koszty cold startów i logowania.
Środowiska nieprodukcyjne: szybkie oszczędności bez dotykania prod
Dlaczego tu leżą „proste procenty”
Dev/test/stage bywają utrzymywane 24/7 w tych samych klasach co prod. Z perspektywy kosztu to strata: ruch jest przewidywalny i okienkowy, a SLO luźniejsze.
Źródło: Pexels | Autor: Tobi &Chris
Schemat działań na 30 dni
Standaryzuj klasy: mniejsze maszyny, niższe dyski (Standard SSD/HDD), niższe IOPS. Włącz ograniczenia SKU przez polityki.
Harmonogramy:
AWS: EventBridge + SSM/Instance Scheduler; pauza RDS/Redshift w nocy/weekendy.
GCP: Instance schedules, pauza Cloud SQL (w GCP brak pauzy – użyj mniejszych klas + snapshot/restore dla środowisk tymczasowych), ogranicz min instances w Cloud Run.
Spot/Preemptible:
AWS: Spot dla batch/CI i środowisk testów obciążeniowych; capacity-optimized i diverse instance types.
Azure: Spot VMs dla pipeline’ów; wymuś retry/ checkpointing.
GCP: Spot/Preemptible VMs w połączeniu z GKE Autopilot/Standard i PodDisruptionBudget pod testy, nie pod krytyczne ścieżki.
Ephemeral: twórz środowiska per feature branch (Terraform + krótkie TTL), automatyczne niszczenie po merge.
Artefakty i rejestry: retencja tagów i cleanup obrazów; krótsze TTL cache’ów w dev.
Pułapka: kopiowanie prodowych tajemnic i rozmiarów 1:1. W dev/test wytnij integracje zewnętrzne (płatne API), użyj stubów i datasetów syntetycznych.
Kontrola po zmianach: czy oszczędzamy bez regresu SLO?
Metryki decyzyjne tygodniowo
Koszt jednostkowy: $/request, $/build, $/GB przetworzonych, $/raport BI. Śledź trend, nie tylko sumę.
Storage i dane: gdy retencja nie ma hamulca
Problem: wolumen rośnie, rachunek też – a SLO tego nie potrzebuje
Najczęściej puchną: dane w object storage, snapshoty dysków i logi. Co wiemy? Koszt rośnie liniowo z TB i operacjami (PUT/GET/Lifecycle). Czego nie wiemy? Które zbiory naprawdę muszą być w klasie „hot” i jak długo trzymać kopie.
Przyczyny: brak polityk cyklu życia i „domyślne” klasy przechowywania
Brak lifecycle per bucket/container i brak rozróżnienia hot/warm/cold.
Snapshoty tworzone z cronów bez wygaszania i bez limitu wersji.
Format danych i rozdrobnienie plików (miliony małych obiektów) windują operacje i metadane.
Rozwiązania: klasy, cykl życia i porządek w formatach
Klasy przechowywania i przełączanie:
AWS S3: dla nieaktywnych – Intelligent-Tiering lub Standard-IA/One Zone-IA po 30–60 dniach; archiwum w Glacier/Deep Archive poza ścieżką SLO.
Azure Blob: Hot → Cool → Archive polityką Lifecycle Management; oddziel prod od backup.
GCP Cloud Storage: Standard → Nearline/Coldline/Archive regułami na prefixach/etykietach.
Snapshoty i kopie:
AWS: rotacja snapshotów EBS/RDS, replikacja tylko dla krytycznych; dla Aurora – binlog/archiwa z limitem dni.
Azure: Managed Disks snapshots ze stałą retencją; Azure SQL – krótsze PITR tam, gdzie RPO dopuszcza.
GCP: Persistent Disk snapshots w trybie inkrementalnym + rotacja; Cloud SQL – skrócenie retencji backupów w nieprod.
Format i układ danych:
Jeziorka danych: Parquet/ORC + partycjonowanie po czasie/kluczu; unikać tysięcy małych plików – włącz kompaktację.
Logi: krótsza retencja w dev/test, eksport „zimnych” logów z droższych usług (np. CloudWatch/Log Analytics/Logging) do tańszego storage.
Widoczność kosztów operacji: osobne metryki na requesty (GET/PUT/LIST) i lifecycle – nadmiarowe reguły mogą drożeć przy milionach obiektów.
Czego unikać: masowego przenoszenia małych i krótkotrwałych obiektów do klas „cold” – opłaty za monitoring/operacje i minimalne okresy przechowywania potrafią zjeść oszczędność. Dla danych w ścieżkach na krytycznym P95 nie używaj klas z opóźnionym odczytem.
Ruch sieciowy i egress: najcichszy składnik rosnącego rachunku
Problem: transfer między AZ/regionami i do Internetu wymyka się z planu
Rozproszone mikroserwisy rozmawiają „na krzyż”, a NAT-y liczą GB dzień po dniu. Co wiemy? Egress między regionami i do Internetu kosztuje realne pieniądze. Czego nie wiemy? Które przepływy są czatliwe i czy można je zlokalizować bliżej danych.
Przyczyny: złe rozmieszczenie usług i domyślne ścieżki przez NAT/Internet
Komunikacja między strefami/regionami bez powodu (np. baza w innej AZ niż aplikacja).
Brak endpoints/privatelink do usług zarządzanych, cały ruch idzie przez NAT Gateway.
Brak CDN i cache na brzegu; payloady bez kompresji.
Rozwiązania: lokalność, prywatne ścieżki i cache
Lokalność:
Planowanie topologii per AZ – dane i compute w tej samej strefie; ruch cross-AZ tylko dla wysokiej dostępności.
Replikacja między regionami – selektywnie i asynchronicznie, jeśli SLO/RPO pozwala.
Prywatne połączenia do usług:
AWS: Gateway/Interface Endpoints (S3, DynamoDB, itp.), mniej GB przez NAT Gateway; PrivateLink do usług wewnętrznych.
Azure: Private Endpoints/Service Endpoints do Storage/SQL; zmniejszasz egress i ryzyko SNAT.
GCP: Private Service Connect i VPC-SC dla ruchu do usług Google/partnerów.
Front i cache:
CDN: AWS CloudFront, Azure Front Door, Cloud CDN – offload statycznych treści i API GET z krótką TTL.
Kompresja i protokoły: gzip/br, HTTP/2/3, mniejsze payloady = mniej egress.
Kontrola NAT:
AWS: agreguj subnets za NAT, ale używaj endpointów gdzie się da; dla low-throughput rozważ NAT Instances tylko z pełnym monitoringiem i HA.
Azure: NAT Gateway tam, gdzie potrzeba stabilnego SNAT; monitoruj koszty i porty SNAT.
Najczęściej zadawane pytania (FAQ)
Dlaczego rachunek za AWS/Azure/GCP rośnie mimo stabilnego ruchu i jak to szybko zdiagnozować?
Co wiemy? Zużycie wygląda stabilnie, SLO nie cierpią. Czego nie wiemy? Które zasoby są przewymiarowane, gdzie „kapie” transfer i które opłaty są stałe, choć zbędne. Pierwszy krok to inwentaryzacja i tagi: owner, product, environment, cost-center, criticality, lifecycle, data-class. Bez tego trudno wskazać winnych kosztu.
Następnie wylistuj Top 20 pozycji z faktury i zestaw je z P95 CPU/RAM/IO oraz czasem największego ruchu. Jeśli średnie użycie CPU/RAM w szczycie jest poniżej ~25–30%, to kandydat do rightsizingu lub agresywniejszego autoskalowania. Równolegle sprawdź: transfer między AZ/regionami, koszty NAT, retencję logów/metryk i klasy storage.
Jakie działania dają najszybsze oszczędności bez ryzyka dla wydajności?
Najpierw tnij „nadmiar godzin” i „nadmiar mocy”, a nie zasoby krytyczne dla SLO. Testuj każdą zmianę na tle celu: zachować P95 latency i 99,9% dostępności przy niższym koszcie jednostkowym (np. koszt/1000 żądań).
Rightsizing instancji według P95 metryk + włączenie autoskalowania w dół.
Harmonogram wyłączania dev/test (np. 19:00–7:00 i weekendy).
Polityki retencji logów/metryk i tiering storage (hot→warm→cold).
Minimalizacja płatnego transferu: ruch w tej samej AZ, prywatne endpointy, CDN.
Rozsądne zobowiązania rabatowe (Savings Plans/RI/CUD) tylko dla stabilnego baselinu.
Na czym polega rightsizing instancji i jak ustawić bezpieczne progi?
Rightsizing to dopasowanie CPU/RAM/IO do realnego P95 obciążenia. Skorzystaj z narzędzi: AWS Compute Optimizer, Azure Advisor, GCP Recommender i porównaj ich wskazania z własnym monitoringiem. Celem jest pozostawienie rezerwy, ale nie płacenie za „powietrze”.
