Serverless bez finansowych niespodzianek - Lambda pricing i koszty EBS

„Serverless jest tani” - to jedno z najczęstszych uproszczeń w rozmowach o kosztach AWS. Lambda rzeczywiście jest tania przy niskim i średnim ruchu. Problem pojawia się, gdy ruch rośnie, funkcje stają się cięższe, albo ktoś włączy Provisioned Concurrency „na wszelki wypadek”.

Drugi element tej układanki to EBS. Nie jest serverless, ale towarzyszy prawie każdemu workload na AWS - od EC2 przez ECS po EKS. Jego model cenowy jest nieintuicyjny: płacisz za przydzieloną pojemność (nawet pustą), za IOPS osobno (w przypadku io2), i za snapshoty, te koszty rosną bez kontroli.

Jak działa Lambda pricing - model rozliczeń

AWS Lambda rozlicza się w trzech wymiarach:

1. Liczba wywołań (requests)

• $0.20 za 1 milion wywołań (po wykorzystaniu free tier)
• Free tier: 1 milion wywołań/miesiąc (bezterminowo, nie tylko 12 miesięcy)

To jest najprostszy składnik i rzadko stanowi problem. Nawet przy 100 milionach wywołań miesięcznie to „zaledwie” $20.

2. Czas wykonania × przydzielona pamięć (GB-seconds)

To jest główny składnik kosztów Lambda:

• $0.0000166667 za GB-sekundę (x86)
• $0.0000133334 za GB-sekundę (ARM/Graviton2 - 20% taniej)
• Free tier: 400 000 GB-sekund/miesiąc

Jak to liczyć? Jeśli funkcja ma 512 MB pamięci i wykonuje się 200 ms:

0.5 GB × 0.2 s = 0.1 GB-s na wywołanie
Koszt: 0.1 × $0.0000166667 = $0.00000167 na wywołanie

Przy 10 milionach wywołań/miesiąc: $16.67/miesiąc - to nadal tanio.

Problem pojawia się, gdy:

• Pamięć wzrasta do 1-3 GB (przetwarzanie obrazów, ML inference, parsowanie dużych plików JSON)
• Czas wykonania rośnie do 5-30 s (wywołania API zewnętrznych, operacje na S3, połączenia z bazą)
• Obie te wartości rosną jednocześnie

Wniosek: Lambda jest tania dla krótkich, lekkich funkcji. Przy ciężkich workloadach (>1 GB pamięci, >5 s) Fargate lub EC2 mogą być tańsze.

3. Provisioned Concurrency

Provisioned Concurrency eliminuje zimne starty, ale zmienia model kosztowy Lambdy z pay-per-use na stały koszt:

• $0.0000041667 za GB na sekundę utrzymania gotowości (opłata za utrzymanie „ciepłych” instancji)
• Plus standardowa opłata za execution (ale niższa: $0.0000097222 za GB-s)

Kalkulacja: 10 instancji × 1 GB × 24h × 30 dni:

10 × 1 GB × 86400 s × 30 = 25,920,000 GB-s utrzymania gotowości
Koszt: 25,920,000 × $0.0000041667 = $108/miesiąc

To $108 miesięcznie niezależnie od tego, czy te funkcje są wywoływane czy nie. Provisioned Concurrency to w praktyce „serwer w ukryciu” - płacisz jak za EC2, ale z interfejsem Lambda.

Kiedy Provisioned Concurrency ma sens:

• Funkcje na ścieżce krytycznej z SLA <100 ms latency
• API synchroniczne, gdzie cold start 1-5 s jest nieakceptowalny
• Workload z przewidywalnym, stabilnym ruchem

Kiedy nie ma sensu:

• Asynchroniczne przetwarzanie (SQS → Lambda) - cold start nie wpływa na UX
• Workload o niskim ruchu (<100 wywołań/h) - cold start zdarza się rzadko
• Batch processing - kilka sekund dodatkowego czasu nie robi różnicy

Ukryte koszty Lambda - na co uważać

Data transfer

Lambda w VPC generuje ruch sieciowy. Jeśli funkcja łączy się z bazą RDS, S3 (przez VPC endpoint) lub zewnętrznym API, pojawiają się opłaty za transfer:

• Lambda → internet: $0.09/GB (eu-central-1)
• Lambda → inna usługa w tym samym AZ: bezpłatnie
• Lambda → inna usługa w innym AZ: $0.01/GB (w obie strony)
• Lambda → S3 (przez gateway endpoint): bezpłatnie
• Lambda → S3 (przez NAT Gateway): $0.045/GB + opłata za NAT

Najczęstszy błąd: Lambda w VPC wysyła ruch do S3 przez NAT Gateway zamiast przez VPC Endpoint (gateway). Przy 1 TB transferu miesięcznie to $45 vs $0.

CloudWatch Logs

Każde wywołanie Lambdy domyślnie loguje do CloudWatch. Koszty:

• $0.50 za GB ingested (zapis logów)
• $0.03 za GB stored (przechowywanie)

Przy 10M wywołań z loggingiem na poziomie DEBUG, generujesz łatwo 50-100 GB logów miesięcznie = $25-50 tylko za ingest.

Rozwiązanie: ustaw retention na 7-14 dni dla dev/test, 30 dni dla produkcji. Archiwizuj do S3 (Glacier) jeśli potrzebujesz długoterminowo.

Lambda@Edge i CloudFront Functions

Jeśli używasz Lambda@Edge (np. do personalizacji odpowiedzi CDN), ceny są inne:

• $0.60 za 1M wywołań (3× drożej niż standardowa Lambda)
• $0.00000625125 za 128 MB-s (inna stawka)
• Brak free tier

CloudFront Functions (prostsze, wyłącznie JavaScript) są znacznie tańsze: $0.10/1M wywołań.

Step Functions

Jeśli orkiestrujesz Lambdy przez Step Functions:

• $25 za 1M przejść stanów (Standard Workflows)
• $0.025 za 1000 wywołań (Express Workflows)

Przy złożonym workflow z 10 krokami i 1M wywołań miesięcznie: 10M przejść = $250/miesiąc. To może przekroczyć koszt samych Lambd.

EBS pricing - dlaczego dyski kosztują więcej niż myślisz

EBS (Elastic Block Store) to storage blokowy dla EC2. Towarzyszy każdemu workload, który nie jest czysto serverless - od pojedynczych EC2 po klastry EKS z PersistentVolumes.

Model cenowy EBS

EBS rozlicza się w trzech wymiarach:

Kluczowa zasada: płacisz za przydzieloną pojemność, nie za użytą

Jeśli utworzysz wolumin gp3 o pojemności 500 GB, ale zapiszesz na nim 50 GB danych - płacisz za 500 GB:

500 GB × $0.08 = $40/miesiąc (niezależnie od wypełnienia)

To jest zasadnicza różnica w stosunku do S3, gdzie płacisz za faktycznie przechowywane dane.

Typowe pułapki EBS

1. Over-provisioning pojemności

Deweloperzy tworzą woluminy „z zapasem” - 500 GB na serwer, który realnie używa 80 GB. Przy 20 serwerach to:

• Przydzielone: 20 × 500 GB = 10 TB → $800/mies.
• Faktycznie użyte: 20 × 80 GB = 1.6 TB → $128/mies.
• Marnowane: $672/mies. (84% budżetu na storage)

Rozwiązanie: Elastic Volumes - EBS pozwala zwiększać pojemność woluminu bez downtime. Zacznij od tego, co potrzebujesz dziś, i rozszerzaj w miarę potrzeby.

2. Snapshoty bez lifecycle policy

Snapshoty EBS przechowywane w S3 (zarządzane przez AWS) kosztują $0.05/GB/miesiąc. Wydaje się niewiele, ale:

• Codzienne snapshoty woluminu 500 GB × 30 dni = 15 TB (inkrementalne, ale rośnie)
• Po roku bez czyszczenia: łatwo 5-10 TB snapshotów = $250-500/miesiąc

Rozwiązanie: AWS Backup z lifecycle rules - automatyczne usuwanie snapshotów starszych niż 30/60/90 dni. Lub Data Lifecycle Manager (DLM).

3. io2 tam, gdzie wystarczy gp3

io2 Block Express kosztuje $0.065/IOPS/miesiąc. Przy 10,000 IOPS (typowe dla bazy danych):

10,000 IOPS × $0.065 = $650/miesiąc (tylko za IOPS!)
+ pojemność 200 GB × $0.125 = $25/miesiąc
= $675/miesiąc łącznie

gp3 z 10,000 IOPS:

Bazowe 3,000 IOPS w cenie
Dodatkowe 7,000 × $0.005 = $35/miesiąc
+ pojemność 200 GB × $0.08 = $16/miesiąc
= $51/miesiąc łącznie

Różnica: $624/miesiąc na jednym woluminie. io2 ma sens tylko gdy potrzebujesz >16,000 IOPS lub gwarantowanej durability 99.999%.

4. Woluminy osierocone (unattached)

Odłączone woluminy EBS nadal kosztują. Po terminacji EC2 woluminy z flagą DeleteOnTermination: false zostają. W Cost Explorer szukaj: UsageType: EBS:VolumeUsage z LinkedAccount ale bez powiązanej instancji.

Rozwiązanie: AWS Trusted Advisor lub aws ec2 describe-volumes --filters Name=status,Values=available - lista woluminów do usunięcia.

Lambda vs Fargate vs EC2 - kiedy co się opłaca

Nie każdy workload powinien być serverless. Oto porównanie kosztów dla tego samego workload:

Scenariusz: API obsługujące 1000 req/s, 100 ms latency, 512 MB RAM

Punkt przełamania: Lambda jest tańsza niż Fargate do ~200 req/s ciągłego ruchu (przy 100 ms execution). Powyżej tego progu - Fargate lub EC2.

Kiedy Lambda jest optymalnym wyborem kosztowym

• Ruch sporadyczny, z nagłymi szczytami - API z 50 req/s w szczycie, ale 0.1 req/s w nocy. Lambda skaluje się do zera.
• Event-driven processing - SQS/SNS → Lambda. Płacisz tylko za faktyczne przetwarzanie.
• Cron jobs - zamiast EC2 działającego 24/7 dla jednego crona o 3:00 w nocy.
• Prototypowanie - MVP bez zobowiązań infrastrukturalnych.

Kiedy Lambda jest droga

• Stały, wysoki ruch - >500 req/s ciągle → EC2 lub Fargate są tańsze.
• Długie execution - funkcje >30 s → Fargate (max 15 min) lub ECS.
• Duże zużycie pamięci - >3 GB → EC2 z odpowiednio dobranym rozmiarem instancji.
• GPU workload - Lambda nie obsługuje GPU.

Optymalizacja kosztów Lambda - praktyczne techniki

1. Right-sizing pamięci

Lambda automatycznie skaluje CPU proporcjonalnie do pamięci. Więcej pamięci = więcej CPU = szybsze wykonanie. Paradoksalnie, zwiększenie pamięci może obniżyć koszt:

Funkcja z 128 MB, execution 3000 ms:
0.128 GB × 3 s = 0.384 GB-s = $0.0000064 per call

Funkcja z 512 MB, execution 800 ms (więcej CPU):
0.512 GB × 0.8 s = 0.4096 GB-s = $0.0000068 per call

Minimalnie drożej per call, ale 3× szybsza. Dla użytkownika - lepszy UX.

Narzędzie: AWS Lambda Power Tuning (open-source, SAR) - testuje funkcję z różnymi konfiguracjami pamięci i pokazuje optymalny punkt cena/wydajność.

2. ARM (Graviton2) zamiast x86

Lambda na ARM jest 20% tańsza za GB-s i zazwyczaj porównywalnie szybka. Migracja jest bezproblemowa dla:

• Python, Node.js, Java, .NET 6+ - żadnych zmian w kodzie
• Natywne binaria - wymagają rekompilacji

Zmiana to jedna linia w konfiguracji: Architectures: [arm64]

3. Unikanie zimnych startów bez Provisioned Concurrency

• Utrzymuj pakiet deployment mały - mniej kodu = szybszy zimny start
• Lazy initialization - nie ładuj wszystkiego przy starcie
• SnapStart (Java) - eliminuje zimny start dla Javy bez dodatkowych kosztów
• Ping/warmup - EventBridge co 5 min wywołuje funkcję (koszt: praktycznie zero)

4. Batching zamiast wielu wywołań

Zamiast 1000 osobnych wywołań Lambda po jednym rekordzie z SQS, ustaw BatchSize: 100 i przetwarzaj 10 wywołań po 100 rekordów. Oszczędność na request fee + mniejszy narzut przy zimnym starcie.

Optymalizacja kosztów EBS - praktyczne techniki

1. Migracja z gp2 na gp3

gp3 jest domyślnie 20% tańszy niż gp2 i daje lepszą wydajność bazową (3000 IOPS + 125 MB/s vs skalowanie z rozmiarem woluminu w gp2).

Migracja nie wymaga downtime - zmiana typu woluminu w locie:

aws ec2 modify-volume --volume-id vol-xxx --volume-type gp3

Oszczędności przy 100 woluminach × 200 GB:

• gp2: 100 × 200 × $0.10 = $2,000/mies.
• gp3: 100 × 200 × $0.08 = $1,600/mies.
• Oszczędność: $400/mies. bez żadnego wpływu na wydajność

2. Automatyczne czyszczenie snapshotów

# Znajdź snapshoty starsze niż 90 dni
aws ec2 describe-snapshots --owner-ids self \
  --query "Snapshots[?StartTime<='2026-05-04'].SnapshotId" \
  --output text

Lepiej: skonfiguruj AWS Backup z retention policy lub Data Lifecycle Manager.

3. Identyfikacja osieroconych woluminów

# Woluminy w stanie "available" (odłączone)
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query "Volumes[].{ID:VolumeId,Size:Size,Created:CreateTime}" \
  --output table

Każdy wolumen na tej liście to pieniądze wyrzucone - nie jest podłączony do żadnej instancji, ale AWS nalicza opłatę.

4. Right-sizing IOPS

Sprawdź faktyczne wykorzystanie IOPS w CloudWatch (VolumeReadOps + VolumeWriteOps). Jeśli wolumin io2 z 10,000 IOPS faktycznie zużywa max 4,000 - przejdź na gp3 z 4,000 IOPS i zaoszczędź $600+/miesiąc.

Monitoring kosztów - co śledzić

Dla Lambda

W CloudWatch Metrics monitoruj:

• Duration (p99) - jeśli rośnie, koszt rośnie proporcjonalnie
• ConcurrentExecutions - jeśli zbliża się do limitu, rozważ architekturę
• Throttles - oznaczają utracone wywołania i potencjalnie wyższe koszty (retry)
• IteratorAge (dla stream triggers) - opóźnienie w przetwarzaniu

W Cost Explorer:

• Filtr: Service = Lambda, Group by: Function Name
• Zidentyfikuj top 5 najdroższych funkcji i zoptymalizuj je

Dla EBS

W Cost Explorer:

• Filtr: Usage Type = EBS:VolumeUsage.gp3 (lub io2, gp2)
• Group by: Availability Zone - sprawdź czy masz równomierny rozkład

W CloudWatch:

• VolumeReadOps / VolumeWriteOps - czy przydzielone IOPS są wykorzystywane?
• BurstBalance (gp2) - jeśli spada do 0, potrzebujesz gp3 lub io2

Realny scenariusz: polska firma SaaS - optymalizacja Lambda + EBS

Sytuacja wejściowa

Firma SaaS z API na Lambda (20 funkcji, ~5M wywołań/dzień) + backend na ECS z woluminami EBS. Miesięczny rachunek: $4,800.

Rozkład kosztów:

Identyfikacja problemów

1. Lambda - 3 funkcje odpowiadały za 70% kosztów Lambda. Jedna z nich (image processing) miała 3 GB pamięci i 8 s execution.
2. EBS - 12 woluminów gp2 po 500 GB, faktyczne użycie: 60-120 GB każdy. Plus 4 TB starych snapshotów.
3. NAT Gateway - Lambda w VPC wysyłała ruch do S3 przez NAT zamiast VPC Endpoint.

Optymalizacja

Łączna oszczędność: $1,356/miesiąc (28% rachunku)

Czas wdrożenia: 2 dni pracy inżyniera DevOps.

Savings Plans a Lambda

Compute Savings Plans pokrywają Lambda. Jeśli masz stabilne zużycie Lambda ($500+/miesiąc), Savings Plan daje dodatkowe 17% zniżki na duration charges.

Kalkulacja:

• Stabilne zużycie Lambda: $800/miesiąc
• Compute SP commitment: $0.37/h (≈ $270/miesiąc commitment na Lambdę)
• Zniżka: 17% na pokrytą część
• Oszczędność: ~$46/miesiąc

Przy niskim zużyciu Lambda (<$200/mies.) Savings Plans nie mają sensu wyłącznie dla Lambdy. Ale jeśli masz mix Lambda + EC2 + Fargate - Compute SP pokrywa wszystko jednym zobowiązaniem.

Podsumowanie - checklist optymalizacji

Lambda

• Uruchom Lambda Power Tuning na top 5 najdroższych funkcji
• Migruj na ARM (Graviton2) gdzie to możliwe
• Sprawdź czy Provisioned Concurrency jest naprawdę potrzebne
• Ustaw S3 VPC Endpoint (gateway) - eliminuje koszty NAT
• Zmniejsz log retention w CloudWatch (7-30 dni)
• Rozważ Fargate/ECS dla funkcji >3 GB pamięci lub >30 s execution
• Użyj batching (SQS BatchSize) zamiast wielu pojedynczych wywołań

EBS

• Migruj wszystkie gp2 na gp3 (zero downtime, 20% taniej)
• Right-size woluminy - sprawdź faktyczne użycie vs przydzielone
• Usuń unattached volumes (status=available)
• Skonfiguruj DLM lub AWS Backup z retention policy na snapshoty
• Sprawdź czy io2 jest potrzebne - gp3 z 16K IOPS pokrywa większość przypadków
• Taguj woluminy (Owner, Environment) - bez tagów nie zidentyfikujesz winowajcy w Cost Explorer

Jak możemy pomóc

W Devopsity przeprowadzamy audyty kosztów AWS ze szczególnym uwzględnieniem serverless i storage - dwóch obszarów, które najczęściej rosną niekontrolowanie.

• Audyt Lambda (1 dzień) - identyfikacja najdroższych funkcji, rekomendacje right-sizing i architektury
• Audyt EBS/storage (1 dzień) - mapowanie over-provisioned woluminów, osieroconych snapshotów, błędnych typów dysków
• Wdrożenie optymalizacji (1-3 dni) - migracja gp2→gp3, Elastic Volumes, DLM, VPC Endpoints, ARM migration
• FinOps dashboard (1 dzień) - automatyczne alerty na anomalie kosztowe, raporty per-team

Rachunek za AWS rośnie?

Umów się na bezpłatną 30-minutową konsultację. Pokażemy, ile oszczędzisz na Lambda i storage bez zmiany architektury.

Umów rozmowę

Najczęściej zadawane pytania

Czy Lambda ma free tier?

Tak, i to bezterminowy (nie tylko 12 miesięcy): 1 milion wywołań + 400,000 GB-sekund miesięcznie. Dla typowego side-project lub wewnętrznego narzędzia - to wystarczy na zero kosztów.

Jaki jest maksymalny czas wykonania Lambda?

15 minut (900 sekund). Jeśli Twoja funkcja regularnie zbliża się do tego limitu, rozważ Fargate (bez limitu czasu) lub Step Functions (orchestracja krótszych kroków).

Czy gp3 jest zawsze lepszy niż gp2?

Prawie zawsze. gp3 jest tańszy ($0.08 vs $0.10/GB), daje wyższe bazowe IOPS (3000 vs zależne od rozmiaru) i nie ma mechanizmu burst balance. Jedyny edge case: woluminy <170 GB w gp2 mogą mieć teoretycznie wyższy peak burst, ale w praktyce gp3 jest lepszy.

Jak sprawdzić ile kosztuje konkretna funkcja Lambda?

W Cost Explorer: filtr Service = Lambda, Group by = Resource (wymaga tagowania). Lub użyj aws ce get-cost-and-usage z filtrem na tag aws:lambda:function:name.

Czy EBS snapshoty są inkrementalne?

Tak. Pierwszy snapshot kopiuje cały wolumen, kolejne tylko bloki zmienione od ostatniego snapshotu. Ale opłata za storage to suma wszystkich unikalnych bloków we wszystkich snapshotach - jeśli nie usuwasz starych, koszt rośnie.

Czy mogę zmniejszyć wolumin EBS?

Nie bezpośrednio. AWS pozwala tylko zwiększać woluminy (Elastic Volumes). Żeby zmniejszyć, musisz: utworzyć nowy mniejszy wolumin → skopiować dane → podłączyć nowy → usunąć stary. Dlatego warto zaczynać z mniejszym rozmiarem.