Checklista deploymentu na AWS, część 2 — koszty, budżety i higiena billingu

Aplikacja działa. Health check jest zielony. Load balancer odpowiada. Baza wstała. DNS został przełączony i nikt nie dzwoni, że coś nie działa.

Czyli deployment się udał?

Jeszcze nie.

W polskich firmach problem z AWS rzadko zaczyna się od spektakularnej awarii. Częściej wygląda dużo nudniej: wszystko działa, zespół wraca do normalnej pracy, a trzy tygodnie później przychodzi rachunek, którego nikt nie umie wytłumaczyć.

„Skąd 1800 zł za staging?” „Dlaczego CloudWatch kosztuje więcej niż aplikacja?” „Kto uruchomił instancję w Irlandii?” „Po co nam trzy NAT Gateway?”

To jest dokładnie ten moment, w którym okazuje się, że deployment nie był skończony. Był tylko uruchomiony.

W pierwszej części checklisty chodziło o bezpieczne postawienie systemu na AWS. Ta część jest o tym, żeby po uruchomieniu produkcji firma nie obudziła się z rachunkiem, którego nikt wcześniej nie zaakceptował.

Bo na AWS „działa” to za mało.

Ma działać, być widoczne kosztowo i mieścić się w budżecie, który biznes rozumie.

Billing to nie zadanie dla księgowości

Najgorsze podejście brzmi tak: „Fakturę sprawdzimy po miesiącu”.

W praktyce oznacza to, że przez miesiąc nikt nie patrzy na koszty. Programista uruchamia testową bazę i zapomina ją wyłączyć. Staging działa 24/7, chociaż używa go jedna osoba. Logi lecą bez retencji. NAT Gateway stoi tam, gdzie wystarczyłyby VPC Endpoints. A publiczne IPv4 są przypięte do rzeczy, które nigdy nie powinny być publiczne.

Księgowość zobaczy fakturę. Ale nie będzie wiedziała, czy RDS za 600 zł był potrzebny, czy przypadkowy. Nie powie Ci, który log group urósł za szybko. Nie odróżni produkcyjnego load balancera od starego testu sprzed trzech sprintów.

Dlatego higiena billingowa to część deploymentu, nie administracja po fakcie.

Prosta zasada:

Jeśli zasób może generować koszt, musi mieć właściciela, tagi i alert.

1. Ustaw AWS Budgets zanim wejdziesz na produkcję

AWS Budgets to pierwsza rzecz, którą konfigurujesz przed go-live. Nie po pierwszym rachunku. Nie „jak będzie czas”. Przed produkcją.

Dla typowej polskiej firmy MŚP warto zacząć od trzech poziomów.

Budżet całego konta. Ile to środowisko ma kosztować miesięcznie? 500 zł? 1500 zł? 4000 zł? Liczba nie musi być idealna. Ważne, żeby ktoś ją nazwał i zaakceptował.

Budżety per usługa. Osobno pilnuj usług, które najczęściej robią niespodzianki: EC2, RDS, NAT Gateway, CloudWatch, transfer danych, OpenSearch, GPU i wszystko, co jest „tymczasowe”. Jeśli architektura jest serverless, pilnuj Lambda, API Gateway, DynamoDB i CloudWatch.

Budżety per środowisko. Produkcja, staging, dev, sandbox. W małej firmie często wszystko startuje na jednym koncie AWS, ale nawet wtedy koszty muszą być rozdzielone tagami. Lepszy wariant to osobne konta przez AWS Organizations.

Praktyczny układ alertów:

50% budżetu — informacja
80% — sprawdzić
100% — decyzja
120% — eskalacja

Nie wysyłaj alertów tylko do jednej osoby.

Minimum to wspólna skrzynka albo kanał na Slacku/Teams. Alert powinien widzieć ktoś techniczny i ktoś odpowiedzialny za budżet. Inaczej skończy się klasycznie: mail przyjdzie, ktoś go zignoruje, a rachunek i tak zostanie zapłacony.

Alert, którego nikt nie czyta, nie jest kontrolą kosztów. Jest ozdobą.

2. Włącz Cost Anomaly Detection

Budżet mówi: „zbliżasz się do ustalonego limitu”.

Cost Anomaly Detection mówi: „dzieje się coś dziwnego”.

To ważna różnica.

Przykłady z życia: endpoint zaczyna logować pełne request body. Lambda wpada w retry loop. Ktoś wrzuca miliony małych plików do S3. Testowa baza zostaje podniesiona do większej klasy „na chwilę”. Developer uruchamia coś w eu-west-1, bo akurat tam kliknął.

Przy budżecie miesięcznym zobaczysz problem późno. Przy anomalii — dużo szybciej.

Minimalny setup:

monitor całego konta AWS;
monitor produkcji;
osobny monitoring kosztów dla RDS, EC2, NAT Gateway, CloudWatch i data transfer;
niski próg alertu dla sandboxów i środowisk testowych.

Dla małych zespołów to szczególnie ważne, bo nikt nie otwiera Cost Explorera codziennie rano. Właściciel firmy tym bardziej nie będzie sprawdzał wykresów AWS między kawą a spotkaniem z klientem.

AWS ma sam powiedzieć, że coś zaczęło kosztować nietypowo dużo.

Nie po miesiącu. Od razu.

3. Taguj zasoby tak, żeby dało się je rozliczyć

Każdy przegląd kosztów AWS prędzej czy później dochodzi do tego samego pytania:

„Co to właściwie jest?”

Potem zaczyna się archeologia: nazwy zasobów, daty utworzenia, regiony, security groups, zgadywanie po konwencji nazewniczej. Ktoś pamięta, że „chyba to było do testu integracji”. Ktoś inny mówi, że „lepiej nie usuwać, bo może produkcja”.

Tak giną pieniądze.

Każdy zasób, który może być otagowany, powinien dostać minimum:

tags = {
  Environment = "production"
  Project     = "panel-klienta"
  Owner       = "backend"
  ManagedBy   = "terraform"
  CostCenter  = "engineering"
}

Nie chodzi o korporacyjną taksonomię na trzydzieści pól. Dla polskiej firmy MŚP wystarczy, żeby tagi odpowiadały na proste pytania:

Kto za to odpowiada? Do jakiego projektu należy? Czy to produkcja, staging czy test? Czy można to usunąć? Czy to jest zarządzane przez Terraform, czy kliknięte ręcznie?

Pamiętaj: cost allocation tags trzeba aktywować w Billing and Cost Management. Samo dodanie tagu do zasobu nie wystarczy, żeby pojawił się w raportach kosztowych.

Najprostszy standard warto wymusić już w Terraformie:

variable "default_tags" {
  type = map(string)
  default = {
    Environment = "production"
    ManagedBy   = "terraform"
    Company     = "example-sp-zoo"
  }
}

A potem rozszerzać w modułach:

module "api" {
  source = "./modules/ecs-service"

  name = "panel-klienta-api"

  tags = merge(var.default_tags, {
    Project = "panel-klienta"
    Owner   = "backend"
  })
}

Nie wygrasz z billingiem bez tagów.

Możesz mieć świetną architekturę, ale jeśli nikt nie wie, do czego należy połowa zasobów, kosztów też nie kontrolujesz.

4. Oddziel produkcję od stagingu i sandboxów

Na początku jedno konto AWS wydaje się wygodne. Jedno logowanie, jedna faktura, mniej konfiguracji.

To wygoda, która szybko się kończy.

Produkcja, staging, dev i eksperymenty zaczynają żyć obok siebie. Ktoś testuje OpenSearch. Ktoś odpala EC2 z publicznym IP. Ktoś robi PoC na dużej bazie. Ktoś tworzy zasób w złym regionie. A potem faktura pokazuje jedną kwotę i zaczyna się zgadywanie, co było produkcją, a co zabawką.

Dla małej firmy rozsądny podział wygląda tak:

Management account — billing, AWS Organizations, bez workloadów. Production account — systemy, z których korzystają klienci. Staging account — testy przed produkcją. Sandbox account — eksperymenty, PoC, krótkotrwałe zasoby.

Nie musisz od razu budować pełnej enterprise landing zone. Ale potrzebujesz takiego rozdzielenia, żeby eksperyment programisty nie zwiększył po cichu rachunku produkcji.

Budżety też powinny być różne:

produkcja: alert przy 80%, eskalacja przy 100%;
staging: alert przy 50%, sprawdzenie przy 80%;
sandbox: alert przy 30%, blokady przy 80%.

Sandbox ma być miejscem do nauki i testów. Nie miejscem, które po weekendzie generuje rachunek większy niż produkcja.

5. Ogranicz regiony i drogie usługi

Dla większości polskich firm domyślnym regionem AWS będzie eu-central-1, czyli Frankfurt. Dane zostają w UE, latencja do Polski jest rozsądna, oferta usług jest szeroka. Czasem sens ma eu-west-1 jako region zapasowy. Warsaw Local Zone to osobny temat — przy standardowych aplikacjach webowych zwykle nie jest potrzebna.

Co nie ma sensu? Przypadkowe zasoby w Stanach, Singapurze albo Sydney.

Zablokuj regiony, których firma nie używa.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "route53:*",
        "cloudfront:*",
        "support:*",
        "budgets:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "eu-central-1",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

To jedna z tych polityk, które nie wyglądają efektownie, ale oszczędzają mnóstwo nerwów.

Inne rozsądne blokady:

brak GPU bez zgody;
brak dużych klas RDS poza produkcją;
brak publicznych IP tam, gdzie workload ma być prywatny;
brak zasobów bez wymaganych tagów;
ograniczenie tworzenia NAT Gateway;
blokada drogich usług w sandboxie.

Nie zaczynaj od pięćdziesięciu SCP. Zacznij od tych pomyłek, które realnie mogłyby zaboleć Twoją firmę.

6. Ustaw retencję logów, zanim CloudWatch Cię zaskoczy

Logi są potrzebne. Ale logi bez retencji to faktura z opóźnionym zapłonem.

CloudWatch często zaskakuje firmy, które wcześniej siedziały na VPS-ie. Na VPS-ie logi „po prostu były na dysku”. Na AWS każdy zapis, storage i część metryk może mieć koszt. Jeśli aplikacja zacznie logować za dużo, zobaczysz to na fakturze.

Przed deploymentem ustal:

Co logujemy? Błędy, zdarzenia bezpieczeństwa, deploymenty, wolne requesty, płatności, logowania.

Czego nie logujemy? Pełnych payloadów, danych osobowych, health checków co kilka sekund, każdego udanego joba w tle.

Jak długo trzymamy logi? Dla wielu systemów MŚP wystarczy 14, 30 albo 90 dni. Nie ustawiaj „never expire” tylko dlatego, że nikt nie podjął decyzji.

Przykład:

resource "aws_cloudwatch_log_group" "api" {
  name              = "/ecs/panel-klienta-api"
  retention_in_days = 30

  tags = {
    Environment = "production"
    Project     = "panel-klienta"
    ManagedBy   = "terraform"
  }
}

Jeśli potrzebujesz archiwum na potrzeby audytu, wrzucaj wybrane logi do S3 i ustaw lifecycle rules. Gorące logi trzymaj krótko. Archiwizuj tylko to, co ma sens.

RODO też ma tu znaczenie: logi nie powinny stawać się śmietnikiem na dane osobowe. Jeśli zapisujesz tam requesty z formularzy, tokeny albo identyfikatory użytkowników, masz nie tylko problem kosztowy, ale też prawny.

7. Sprawdź pułapki kosztowe przed go-live

Większość kosztów AWS da się przewidzieć. ECS, RDS, S3, Lambda, load balancer — to widać w architekturze.

Najdroższe niespodzianki często siedzą obok.

NAT Gateway. Klasyk. Czasem potrzebny, często użyty z rozpędu. Jeśli prywatne zasoby potrzebują głównie dostępu do S3 albo DynamoDB, sprawdź VPC Endpoints.

CloudWatch. Logi, metryki, dashboardy, alarmy. Każda rzecz osobno wygląda niewinnie. Razem potrafią zrobić zauważalną pozycję na fakturze.

Transfer danych. Między regionami, między AZ, przez NAT, do internetu. Na diagramie to tylko strzałka. Na fakturze — realny koszt.

RDS. Storage rośnie, backupy zostają, Multi-AZ podnosi cenę, read replica nie jest darmowa.

Load balancery. Jeden ALB dla aplikacji jest normalny. Osobny ALB dla każdego małego serwisu często oznacza lenistwo architektoniczne.

Porzucone zasoby. Wolumeny EBS, snapshoty, AMI, niepodpięte IP, testowe bazy, stare log groups.

Przed startem zrób prostą tabelę. Nie projekt FinOps. Tabelę.

Komponent	Oczekiwany koszt miesięczny	Właściciel	Uwagi
ECS Fargate	300–400 zł	Backend	API produkcyjne
RDS PostgreSQL	400–600 zł	Backend	Single-AZ na start
ALB	~100 zł	Platform	Wspólny dla API
NAT Gateway	150 zł+	Platform	Sprawdzić VPC Endpoints
CloudWatch	50–150 zł	Platform	Retencja 30 dni
S3 + CloudFront	30–100 zł	Frontend	Assety i pliki
Suma	~1000–1500 zł	CTO	Dodać 15–20% buforu

Ta tabela nie musi być idealna. Ma dać punkt odniesienia.

Jeśli zakładasz 1200 zł miesięcznie, a po tygodniu forecast pokazuje 3000 zł, wiesz, że coś jest nie tak.

Bez estymacji nie masz z czym porównać faktury.

8. Włącz Cost and Usage Reports, jeśli rośniesz

Na początku Cost Explorer wystarczy. Zobaczysz usługi, regiony, trendy i dzienne koszty.

Ale jeśli masz kilka kont, kilka projektów albo chcesz rozliczać koszty per klient, włącz Cost and Usage Reports.

CUR daje szczegółowe dane kosztowe w S3. Możesz potem analizować je w Athenie, QuickSight albo własnym narzędziu. Dla małej firmy na starcie może to brzmieć jak przesada. Ale historia kosztów szybko zaczyna się przydawać.

Zwłaszcza kiedy pada pytanie:

„Dlaczego w maju płaciliśmy 900 zł, a w czerwcu 1800 zł?”

Bez danych odpowiadasz z pamięci. Z CUR możesz sprawdzić.

Jeśli używasz ECS albo EKS na większą skalę, sprawdź też split cost allocation data. Przy współdzielonych klastrach to dużo lepsze niż wrzucanie całego kosztu compute do jednego worka.

9. Pierwszą fakturę potraktuj jak retrospektywę

Pierwszy pełny rachunek po deploymentcie trzeba przejrzeć technicznie. Nie tylko zaksięgować.

Otwórz Cost Explorer. Porównaj estymację z rzeczywistością. Sprawdź koszty per usługa, dzień, region, konto i tag. Zobacz, co jest untagged.

Pytania są proste:

Co kosztowało więcej, niż zakładaliśmy? Co kosztowało mniej? Które zasoby nie mają właściciela? Jakie usługi pojawiły się na fakturze, choć nie było ich w planie? Czy staging kosztuje za dużo? Czy logi rosną szybciej, niż powinny? Czy backupy się kumulują? Czy transfer danych jest zrozumiały? Co możemy usunąć już teraz?

Taki przegląd prawie zawsze coś znajduje.

Instancję RDS o klasę za dużą. NAT Gateway, którego nikt nie zaplanował. Log group bez retencji. Testowy EC2 zostawiony po migracji. Staging działający cały weekend, chociaż nikt go nie używał.

Naprawienie tego po pierwszym miesiącu jest normalne.

Zignorowanie przez rok — drogie.

Checklista przed produkcją

Przed go-live odhacz:

AWS Budgets ustawione dla konta, usług i środowisk.
Alerty budżetowe trafiają do wspólnego kanału.
Cost Anomaly Detection jest włączony.
Tagi kosztowe są zdefiniowane, stosowane i aktywowane.
Produkcja jest oddzielona od stagingu i sandboxa.
Regiony są ograniczone do tych, których firma używa.
Drogie usługi są zablokowane tam, gdzie nie powinny być dostępne.
Retencja CloudWatch Logs jest ustawiona jawnie.
CloudTrail jest skonfigurowany świadomie.
NAT Gateway został sprawdzony pod kątem kosztu.
RDS ma uzasadniony rozmiar, storage i backup retention.
Oczekiwany miesięczny koszt jest zapisany.
Ktoś jest właścicielem kosztów.
Przegląd pierwszej faktury jest zaplanowany.

Jeśli nie możesz tego odhaczyć, deployment nie jest skończony.

Może być live. Może działać. Ale operacyjnie nie jest gotowy.

Jak wygląda zdrowy AWS billing w małej firmie

Nie potrzebujesz pełnoetatowego zespołu FinOps.

Dla większości polskich firm wystarczy, że budżety są ustawione, alerty trafiają do ludzi, każdy zasób ma właściciela, produkcja jest oddzielona od eksperymentów, logi wygasają, drogie regiony są zablokowane, a pierwsza faktura jest przejrzana przez kogoś technicznego.

To nie jest biurokracja. To podstawowa higiena.

AWS nie staje się drogi przez jeden wielki błąd. Najczęściej robi się drogi przez małe rzeczy zostawione bez kontroli.

Testowa baza. Zapomniany wolumen. Logi bez retencji. NAT Gateway postawiony z rozpędu. Staging działający przez weekend. Faktura opłacona bez czytania.

Guardraile kosztowe nie są po to, żeby spowalniać zespół.

Są po to, żeby firma mogła korzystać z AWS bez strachu, że następny rachunek będzie niespodzianką.

W Otocolobus audytujemy środowiska AWS właśnie pod kątem takich problemów — niejasnej własności zasobów, brakujących guardraili kosztowych, źle ustawionych logów, zbyt szerokich uprawnień, zapomnianej infrastruktury i rachunków, które zaskakują dopiero po fakcie.

Jeśli chcesz wiedzieć, gdzie Twój AWS przepala pieniądze, zanim pokaże to kolejna faktura — odezwij się.