Strategie i najlepsze praktyki 11 min czytaniaIntermediate

Optymalizacja kosztów AWS Lambda w 2026: Graviton, Provisioned Concurrency i tuning pamięci

Praktyczny przewodnik po cięciu rachunku za AWS Lambda w 2026: migracja na arm64 (Graviton), tuning pamięci, Compute Savings Plans, SnapStart i retencja CloudWatch Logs. Gotowy kod Terraform i AWS SAM oraz konkretne procenty oszczędności z realnych audytów FinOps.

Editorial TeamReviewed by Jordan Reeves, Jul 2026
AWS Lambda: Optymalizacja Kosztów 2026

Zaktualizowano: 20 lipca 2026

Optymalizacja kosztów AWS Lambda w 2026 roku sprowadza się do pięciu decyzji: wybór architektury arm64 (Graviton) (do 20% taniej), właściwy tuning pamięci (często zmniejsza koszt i latencję jednocześnie), objęcie stabilnego ruchu Compute Savings Plans (do 17% rabatu), włączenie SnapStart dla Javy/Pythona oraz agresywna retencja CloudWatch Logs. Poniższy przewodnik pokazuje, jak wdrożyć każdą z tych praktyk krok po kroku, z gotowym kodem i wynikami z realnych workloadów.

  • Migracja funkcji na architekturę arm64 (Graviton) daje 20% niższą cenę za GB-sekundę oraz zwykle 15–34% lepszą wydajność względem x86_64.
  • Tuning pamięci narzędziem AWS Lambda Power Tuning często obniża łączny koszt wywołania o 30–50%, ponieważ CPU skaluje się proporcjonalnie do RAM.
  • Compute Savings Plans obejmują też Lambdę: 1-roczny plan bez zaliczki daje ~12%, 3-letni z pełną zaliczką do 17% zniżki.
  • SnapStart eliminuje 90% cold startów w Javie 11/17/21 i Pythonie 3.12+ bez dopłat za invoke (płacisz jedynie za caching).
  • Ustaw retencję CloudWatch Logs na 7–14 dni zamiast domyślnego "Never expire". Logi potrafią być droższe niż same wywołania.
  • Provisioned Concurrency ma sens wyłącznie przy przewidywalnym ruchu >60% wykorzystania; w innych przypadkach jest droższe niż on-demand.

Jak liczy się rachunek za AWS Lambda w 2026

Zanim zaczniesz cokolwiek ciąć, warto rozumieć, za co dokładnie płacisz. Rachunek za Lambdę składa się z trzech głównych pozycji: liczba wywołań (0,20 USD za milion), czas trwania × pamięć (GB-sekundy) oraz ephemeral storage powyżej 512 MB. Do tego dochodzą koszty pośrednie: CloudWatch Logs, transfer danych, X-Ray, Lambda Insights, Provisioned Concurrency i (dla obrazów kontenerowych) ECR.

Ceny za GB-sekundę w regionie us-east-1 na lipiec 2026:

Pozycjax86_64arm64 (Graviton)
Cena za GB-sekundę0,0000166667 USD0,0000133334 USD
Cena za milion wywołań0,20 USD0,20 USD
Provisioned Concurrency (GB-h)0,015 USD0,012 USD
Ephemeral storage >512 MB (GB-s)0,0000000309 USD0,0000000247 USD
SnapStart caching (GB-h)0,0002000 USD0,0002000 USD

Kluczowa intuicja: pamięć nie tylko określa dostępny RAM, ale też proporcjonalnie skaluje moc CPU. Funkcja z 1769 MB pamięci dostaje 1 vCPU; przy 3008 MB dwa. Dlatego zmniejszenie pamięci nie zawsze oszczędza pieniądze. Jeśli spowoduje 3× dłuższe wykonanie, płacisz więcej. Dokładny model jest opisany w oficjalnej dokumentacji AWS Lambda Pricing.

Migracja na arm64 (Graviton): najszybszy zysk

Szczerze mówiąc, jeśli w 2026 roku uruchamiasz nową funkcję na x86_64, prawdopodobnie tracisz pieniądze. Procesory Graviton3 od AWS oferują 20% niższą cenę za GB-sekundę, a w większości benchmarków dorzucają jeszcze 15–34% lepszą wydajność. Dla workloadów typu API JSON, przetwarzanie obrazów czy funkcje w Node.js/Python/Go migracja to zwykle zmiana jednej linii w konfiguracji.

W Terraformie wystarczy dodać atrybut architectures:

resource "aws_lambda_function" "api" {
  function_name = "orders-api"
  role          = aws_iam_role.lambda_exec.arn
  handler       = "index.handler"
  runtime       = "nodejs20.x"
  filename      = "function.zip"

  # Migracja na Graviton, 20% taniej za GB-s
  architectures = ["arm64"]

  memory_size = 512
  timeout     = 10

  environment {
    variables = {
      LOG_LEVEL = "info"
    }
  }
}

W AWS SAM analogicznie:

Resources:
  OrdersApi:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      Architectures:
        - arm64        # Graviton
      MemorySize: 512
      Timeout: 10
      CodeUri: ./src/

Kiedy NIE migrować: jeśli używasz natywnych bibliotek skompilowanych tylko dla x86_64 (np. legacy binaria C/C++), obrazów bazowych bez wariantu arm64, lub bibliotek ML z pinowaniem architektury (np. niektóre wheele TensorFlow). W tych przypadkach test warto zrobić w dedykowanym środowisku dev. Sam raz przełączyłem funkcję z sharp na arm64 bez sprawdzenia wersji binarki i przez pół godziny łapałem tajemniczy Runtime.ImportModuleError, więc nauka wyszła bolesna, ale trwała.

Tuning pamięci i AWS Lambda Power Tuning

To najczęściej pomijana, a jednocześnie najbardziej dochodowa optymalizacja. Standardowa intuicja mówi "mniej pamięci = mniej pieniędzy", ale w Lambdzie jest inaczej. Przy zbyt małej pamięci funkcja dostaje mniej CPU i wykonuje się dłużej, co często zwiększa koszt. Cel to znaleźć punkt, w którym iloczyn pamięć × czas jest minimalny.

Narzędzie AWS Lambda Power Tuning (state machine w Step Functions) automatycznie testuje funkcję dla różnych konfiguracji pamięci i zwraca wykres kosztu i latencji. Wdrożenie z SAR:

# 1. Wdroz Power Tuning ze Serverless Application Repository
aws serverlessrepo create-cloud-formation-change-set \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM

# 2. Uruchom test dla funkcji
aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:powerTuningStateMachine \
  --input '{
    "lambdaARN": "arn:aws:lambda:us-east-1:123456789012:function:orders-api",
    "powerValues": [128, 256, 512, 1024, 1769, 2048, 3008],
    "num": 50,
    "payload": {"orderId": "test-123"},
    "strategy": "balanced"
  }'

Wynik zwykle wygląda tak: funkcja API o średnim czasie 800 ms przy 128 MB kosztuje 2× więcej niż ta sama funkcja przy 1024 MB, która wykonuje się w 90 ms. Strategia balanced waży koszt i latencję 50/50; cost optymalizuje wyłącznie pod kątem ceny.

Compute Savings Plans dla Lambdy

Wiele zespołów nie wie, że Compute Savings Plans obejmują AWS Lambda (dokładnie: duration, provisioned concurrency i duration for provisioned concurrency; nie obejmują request charges). Dla stabilnego, przewidywalnego ruchu to najprostszy sposób na 12–17% redukcji rachunku bez zmian w kodzie.

Struktura oszczędności w 2026:

ZobowiązanieBez zaliczkiCzęściowa zaliczkaPełna zaliczka
1 rok~12%~13%~14%
3 lata~15%~16%~17%

Praktyczna rekomendacja: zacznij od 1-rocznego planu bez zaliczki na poziomie 60–70% baseline (najniższego stabilnego zużycia w ostatnich 90 dniach). Resztę zostaw na on-demand. To bezpieczna strategia, która praktycznie nigdy nie prowadzi do "niewykorzystanego commitmentu".

# Analiza rekomendacji SP na podstawie ostatnich 60 dni
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --account-scope PAYER

Jeśli używasz też Fargate lub EC2, Compute SP obejmuje wszystko naraz, nie musisz kupować osobnych planów dla każdej usługi. To podejście dobrze łączy się z klasycznym cięciem kosztów opisanym w porównaniu Savings Plans i Reserved Instances. Jeśli chcesz zobaczyć oficjalną tabelę rabatów wprost od AWS, sprawdź też stronę cennikową Lambdy, bo procenty potrafią się zmieniać między regionami.

SnapStart i redukcja cold startów

Cold start to nie tylko problem UX, to również koszt. Funkcja Javy, która "budzi się" 3 sekundy dla każdego wywołania po okresie bezczynności, spala dodatkowe GB-sekundy oraz często wymusza wyższą pamięć, żeby zmniejszyć czas inicjalizacji. Lambda SnapStart rozwiązuje to bez kosztu per-invoke.

SnapStart robi snapshot zainicjalizowanej JVM/interpretera i przywraca go z każdego uruchomienia, redukując cold start z ~3000 ms do ~200 ms. W 2026 SnapStart wspiera: Java 11/17/21, Python 3.12/3.13 oraz .NET 8. Włączenie w Terraformie:

resource "aws_lambda_function" "payments" {
  function_name = "payments-service"
  runtime       = "java21"
  architectures = ["arm64"]
  memory_size   = 1024
  handler       = "com.example.Handler::handleRequest"
  s3_bucket     = aws_s3_bucket.artifacts.id
  s3_key        = "payments.jar"
  publish       = true  # SnapStart wymaga wersjonowanych aliasow

  snap_start {
    apply_on = "PublishedVersions"
  }
}

resource "aws_lambda_alias" "live" {
  name             = "live"
  function_name    = aws_lambda_function.payments.function_name
  function_version = aws_lambda_function.payments.version
}

Koszt SnapStart to tylko caching (0,0002 USD za GB-godzinę) oraz jednorazowa opłata za restore. Dla funkcji z tysiącami wywołań dziennie to zwykle mniej niż jeden cent, a redukcja czasu wywołania oszczędza znacznie więcej niż koszt cachingu.

Provisioned Concurrency vs On-Demand: kiedy się opłaca

Provisioned Concurrency (PC) trzyma określoną liczbę "ciepłych" środowisk wykonawczych, eliminując cold start całkowicie. Ale nie zawsze jest tania. Płacisz za PC 24/7 niezależnie od tego, czy funkcja jest wywoływana, więc zysk ekonomiczny pojawia się dopiero powyżej pewnego progu wykorzystania.

Reguła kciuka: Provisioned Concurrency jest tańsze od On-Demand, gdy średnie wykorzystanie przekracza ~60%. Poniżej tego progu przepłacasz za bezczynne środowiska.

ScenariuszRekomendacjaUzasadnienie
Predictable API (dzienne peaki 9–17)PC + Application Auto ScalingSkaluj PC harmonogramem, masz zerowe cold starty w godzinach ruchu
Nieregularne wywołania (webhooks, cron)On-Demand + SnapStartPC byłoby marnowaniem, koszt idle > oszczędność
Backend do syntetycznego trafficuOn-DemandCold start nie boli, nie ma użytkownika, który czeka
Streamingowe API o niskiej latencjiPC z minimum floor200 ms p99 wymaga eliminacji cold startów
Java 11/17/21 z natywnymi bibliotekamiSnapStart zamiast PCProstsze, tańsze, bez opłat idle

Application Auto Scaling dla PC:

# Skaluj PC miedzy 5 a 50 w oparciu o wykorzystanie
aws application-autoscaling register-scalable-target \
  --service-namespace lambda \
  --resource-id function:orders-api:live \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --min-capacity 5 --max-capacity 50

aws application-autoscaling put-scaling-policy \
  --service-namespace lambda \
  --resource-id function:orders-api:live \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --policy-name pc-utilization-target \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 0.7,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization"
    }
  }'

Ukryty koszt: CloudWatch Logs, X-Ray i Insights

W wielu audytach FinOps, które prowadziłem, koszt CloudWatch Logs generowanych przez Lambdę okazywał się wyższy niż koszt samych wywołań. Dzieje się tak z trzech powodów: (1) domyślna retencja to "Never expire", (2) opłata za ingest to 0,50 USD za GB, (3) verbose logging (np. cały request/response body w JSON) potrafi zjeść budżet w tydzień. Nie zmyślam. U jednego klienta z fintechu logi kosztowały 4× więcej niż same funkcje, bo ktoś zostawił console.log(event) na hot pathu.

Trzy szybkie ruchy, które robię na pierwszym audycie:

  1. Ustawienie retencji 7 lub 14 dni dla wszystkich log groupów Lambdy przez skrypt zbiorczy.
  2. Zmiana LOG_LEVEL na info lub warn w produkcji (debug tylko w dev).
  3. Wyłączenie Lambda Insights dla funkcji, które i tak nie mają alarmingu.
# Ustawienie 14-dniowej retencji dla wszystkich log groupow Lambdy
for lg in $(aws logs describe-log-groups \
  --log-group-name-prefix "/aws/lambda/" \
  --query 'logGroups[?!retentionInDays].logGroupName' \
  --output text); do
  echo "Ustawiam retencje 14 dni dla $lg"
  aws logs put-retention-policy \
    --log-group-name "$lg" \
    --retention-in-days 14
done

Function URL vs API Gateway: różnica w cenie

Dla wielu prostych API HTTP Function URL jest 3–5× tańsze od API Gateway REST. Nie ma opłaty za miliony wywołań, płacisz tylko za samą Lambdę. API Gateway HTTP API jest tańsze od REST API, ale Function URL bije oba, jeśli nie potrzebujesz custom domains z certyfikatami zarządzanymi przez AWS, WAF na poziomie API GW, ani transformacji requestów.

CechaFunction URLAPI Gateway HTTP APIAPI Gateway REST
Koszt za milion requestów0 USD1,00 USD3,50 USD
Auth (IAM / Cognito)IAMIAM, JWT, CognitoWszystko
Custom domainPrzez CloudFrontWbudowanyWbudowany
WAF integrationPrzez CloudFrontTakTak
Request/response transformationNieOgraniczonaPełna (VTL)
Rate limiting per-keyNieTak (usage plans)Tak

Sensowna hybryda: Function URL + CloudFront + WAF daje ci CDN, WAF i custom domain po znacznie niższym koszcie niż API Gateway REST. Dla wewnętrznych API narzędziowych, webhooków i integracji server-to-server Function URL wystarcza bez CloudFront.

Najczęściej zadawane pytania

Czy więcej pamięci sprawia, że AWS Lambda jest tańsza?

Czasem tak. Pamięć skaluje proporcjonalnie CPU, zwiększenie z 128 MB do 1024 MB może obniżyć czas wykonania 3–5×, co daje niższy koszt całkowity mimo wyższej ceny za GB-sekundę. Zawsze weryfikuj to narzędziem AWS Lambda Power Tuning na realnym payloadzie.

Czy Lambda arm64 jest zawsze tańsza niż x86_64?

Cena za GB-sekundę jest o 20% niższa dla arm64. Realny koszt zależy jednak od czasu wykonania. W większości workloadów (API, JSON, procesowanie plików) Graviton jest szybszy o 15–34%, więc oszczędność jest sumaryczna. Wyjątki to funkcje z natywnymi bibliotekami tylko x86_64 lub źle skompilowanym runtime.

Kiedy Provisioned Concurrency przestaje się opłacać?

Provisioned Concurrency jest tańsze od on-demand tylko, gdy średnie wykorzystanie przekracza ~60%. Poniżej tego progu płacisz za bezczynne środowiska, których nikt nie wywołuje. Dla nieregularnego ruchu użyj SnapStart (Java/Python/.NET) lub zostaw on-demand, cold start rzędu 200–500 ms jest akceptowalny dla większości backendów.

Czy Compute Savings Plans obejmują AWS Lambda?

Tak. Compute Savings Plans obejmują komponent duration (GB-sekundy) oraz Provisioned Concurrency dla Lambdy, obok EC2 i Fargate. Nie obejmują opłaty za liczbę wywołań (0,20 USD/milion). Dla stabilnego ruchu 1-roczny plan bez zaliczki daje ~12% zniżki bez zmian w kodzie.

Dlaczego mój koszt CloudWatch Logs przekracza koszt samej Lambdy?

Trzy typowe przyczyny: domyślna retencja "Never expire" powoduje niekończące się gromadzenie logów; verbose logging (pełne request/response body) generuje wiele GB dziennie przy 0,50 USD/GB ingest; oraz Lambda Insights włączone bez potrzeby. Ustaw retencję 7–14 dni, obniż poziom logów w produkcji i wyłącz Insights tam, gdzie nie ma alarmów.

Czy warto migrować z API Gateway na Function URL?

Warto, jeśli nie używasz mapping templates, usage plans z API keys, ani request validatorów. Te funkcje nie mają odpowiedników w Function URL. Migracja obniża koszt HTTP o 100% (Function URL to 0 USD/mln requestów vs 1,00 USD dla HTTP API i 3,50 USD dla REST). Dla publicznych API dodaj CloudFront + WAF.

O Autorze Editorial Team

Our team of expert writers and editors.

Powiązane Artykuły