AWS Lambda разходи: Ръководство 2026

Обновено: 28 юли 2026

Оптимизация на разходите за AWS Lambda означава да намалите цената на serverless функциите чрез настройка на паметта, миграция към ARM64 (Graviton2), използване на Compute Savings Plans и намаляване на разходите за CloudWatch Logs. За типична production функция комбинация от тези техники може да свали месечната сметка с 40–70%, без да пипате бизнес логиката. В това ръководство ще ви преведа през това как точно работи ценовият модел на Lambda през 2026 и кои настройки дават най-голям ефект върху сметката. Ще споделя и няколко неща, които съм научил, докато чистех запуснати serverless акаунти за клиенти.

AWS Lambda таксува за брой invocations ($0.20 на 1M заявки) плюс изчислително време в GB-секунди, което прави правилното настройване на паметта основният лост за икономии.
Миграцията към ARM64 (Graviton2) архитектура намалява цената с 20% и често подобрява производителността. Това е най-бързата „безрискова" оптимизация.
Compute Savings Plans от 2024 г. насам покриват Lambda с до 17% отстъпка при 1- или 3-годишен ангажимент, без да заключват архитектура или конфигурация.
Lambda SnapStart намалява cold start latency до 90% за Java, Python 3.12+ и .NET 8, което позволява намаляване или пълно премахване на Provisioned Concurrency.
CloudWatch Logs често струват повече от самата Lambda функция, така че задаването на retention period и филтриране на INFO логовете е задължителна стъпка.
AWS Lambda Power Tuning (open-source) намира оптималната памет автоматично чрез Step Functions, обикновено спестявайки 15–30% при по-бърза функция.

Как AWS Lambda таксува през 2026

Lambda ценообразуването се базира на три компонента: (1) брой invocations, (2) compute time измерено в GB-секунди, и (3) provisioned concurrency при активиране. Според официалната ценова страница на AWS Lambda, us-east-1 таксува $0.20 за 1 милион заявки и $0.0000166667 за GB-секунда на x86 архитектура. Ключовото прозрение е, че compute частта почти винаги надвишава invocation частта. За 100ms функция с 512 MB памет извикана 10 милиона пъти в месеца, invocations са $2, а compute е около $85.

Free tier остава щедър: 1 милион безплатни заявки и 400 000 GB-секунди на месец. За стартиращи проекти това често е достатъчно. За production обаче ще искате да разберете точно кой ъгъл от сметката трябва да натиснете, за да получите най-голям ефект от инвестираното време. Три ъгъла плащат почти цялата ви сметка: неправилно настроена памет, старата x86_64 архитектура, и разточителни CloudWatch Logs. Ще ги разгледаме един по един.

Как се изчислява GB-секунда

Формулата е: (конфигурирана памет в MB / 1024) × billed duration в секунди. AWS таксува на 1ms увеличения (от декември 2020 насам), така че функция от 40ms се таксува точно като 40ms, а не като 100ms. Това променя оптимизационната стратегия. Намаляването на duration с 5ms върху висок трафик може да оправдае цяло инвестиране на време в кеширане или warm connection pooling.

# Пример за месечен разход
# Функция: 512 MB, ср. duration 200ms, 5M извиквания/месец
invocations_cost = 5_000_000 * (0.20 / 1_000_000)  # $1.00
gb_seconds = 5_000_000 * (512 / 1024) * 0.200      # 500 000 GB-s
compute_cost = 500_000 * 0.0000166667              # $8.33
total = invocations_cost + compute_cost            # $9.33/месец

# Същата функция на ARM64 (Graviton2) с 20% отстъпка:
compute_cost_arm = 500_000 * 0.0000133334          # $6.67
total_arm = invocations_cost + compute_cost_arm    # $7.67/месец (-18%)

Right-sizing на памет с Lambda Power Tuning

Правило номер едно за оптимизация на разходите за AWS Lambda: паметта не е само памет, а пропорционално скалира и CPU, и мрежата. Функция с 1024 MB получава два пъти повече CPU от функция с 512 MB. За CPU-bound функции удвояването на паметта често намалява duration наполовина, оставяйки сметката непроменена, но с двойно по-бърза функция. За I/O-bound функции разликата е малка, така че по-скоро ще искате да останете на нисък memory setting.

Честно казано, ръчното пробване е загуба на време. Използвайте AWS Lambda Power Tuning, open-source Step Functions state machine, поддържан от AWS Serverless Hero Alex Casalboni. Той извиква вашата функция при 128, 256, 512, 1024, 1536, 3008 MB и генерира графика cost-vs-speed, върху която ясно се вижда „sweet spot" зоната.

# Deploy Power Tuning чрез Serverless Application Repository
aws serverlessrepo create-cloud-formation-template \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --semantic-version 4.3.6

# Изпълнение спрямо съществуваща функция
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:myFunction",
    "powerValues": [128, 256, 512, 1024, 1536, 2048, 3008],
    "num": 50,
    "payload": "{\"key\":\"value\"}",
    "strategy": "balanced"
  }'

strategy може да бъде cost (най-евтина), speed (най-бърза) или balanced (най-добро съотношение). За production API типично избирайте balanced. В един от последните ми проекти функция първоначално настроена на 128 MB (default в AWS Console) отчиташе $30/месец и завърши на 512 MB за $18/месец, при това с двойно по-добра latency. Никакви кодови промени, само конфигурация.

Миграция към ARM64 (Graviton2) за -20% цена

Най-простата и най-подценявана оптимизация: превключете Architectures от x86_64 на arm64. AWS предлага Lambda върху Graviton2 (arm64) чипове на 20% по-ниска цена за GB-секунда, а често с 15-19% по-добра производителност. Резултатът е 25-30% реална икономия за същата workload при непроменен код в повечето случаи.

Ако имате native compiled dependencies (например Sharp за image processing или NumPy binaries), ще трябва да ги пребилднете за arm64. За Node.js, Python и Ruby в повечето случаи промяната е тривиална. За задълбочен преглед на процеса вижте нашето пълно ръководство за AWS Graviton миграция към ARM64.

# Terraform: превключване на архитектура
resource "aws_lambda_function" "api" {
  function_name    = "orders-api"
  role             = aws_iam_role.lambda_role.arn
  handler          = "index.handler"
  runtime          = "nodejs20.x"
  architectures    = ["arm64"]  # По-рано: ["x86_64"]
  memory_size      = 512
  timeout          = 10
  filename         = "function.zip"
  source_code_hash = filebase64sha256("function.zip")

  environment {
    variables = {
      NODE_OPTIONS = "--enable-source-maps"
      LOG_LEVEL    = "WARN"
    }
  }
}

Docker container images за arm64

Ако използвате container image Lambda (до 10 GB image size), трябва да билднете multi-arch image или директно да таргетирате arm64. С buildx на Docker това е един ред:

docker buildx build --platform linux/arm64 \
  -t 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-lambda:v1 \
  --push .

# Или multi-arch (x86 + arm) за преход:
docker buildx build --platform linux/amd64,linux/arm64 \
  -t 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-lambda:v1 \
  --push .

Compute Savings Plans за Lambda

От 2024 г. Lambda се покрива от Compute Savings Plans. Те не са Lambda-специфични, а общите Compute SP, които покриват и EC2, и Fargate. Ангажимент за минимален разход $/hour за 1 или 3 години връща 17% отстъпка на Lambda cost при 1-годишен и до 30% при 3-годишен ангажимент с all-upfront плащане. Ключовата разлика от Reserved Instances е, че Savings Plans не заключват архитектура, регион или конфигурация.

Как да пресметнете правилния commitment: изтеглете последните 90 дни Lambda spend от Cost Explorer, вземете най-ниския месечен разход, разделете на 730 (часа/месец). Ангажирайте до 80% от този baseline, за да оставите буфер. Ако вече имате EC2 SP, добавете Lambda baseline към съществуващия ангажимент. За стратегическо сравнение с други commitment опции прочетете нашето ръководство за Savings Plans срещу Reserved Instances.

Provisioned Concurrency vs Reserved Concurrency

Двете имена звучат подобно, но правят различни неща и струват различни пари. Смесването им е една от най-скъпите грешки в serverless FinOps, която съм виждал в реални акаунти.

Характеристика	Reserved Concurrency	Provisioned Concurrency
Цел	Ограничава concurrency (throttling защита)	Държи функции „топли" (без cold start)
Разход	Безплатно	~$4.17/месец за 1 provisioned instance при 128 MB
Cold start	Не влияе	Елиминира cold start
Кога да се използва	Защита на downstream системи	Latency-critical API endpoints
Auto-scaling	Не	Да, с Application Auto Scaling
Покритие от Savings Plans	N/A (безплатно)	Отделен PC Savings Plan

Provisioned Concurrency таксува за всяка минута, че instance-ите са топли, независимо дали ги ползвате. За API endpoint със 100 RPS и 200ms duration, PC от 20 concurrent execution струва около $83/месец. За голяма част от случаите SnapStart (виж по-долу) е по-добра алтернатива, защото елиминира cold start без фиксирана месечна такса.

Lambda SnapStart и cold starts

Lambda SnapStart, обявен през 2022 за Java и разширен през 2025 до Python 3.12+ и .NET 8, намалява cold start latency с до 90% чрез Firecracker snapshots. Вместо да стартира runtime-а от нулата, Lambda реставрира от pre-warmed snapshot на initialized runtime, което елиминира голямата част от JVM startup или Python import time за heavy dependencies.

От април 2025 SnapStart стана безплатен за Python и .NET (Java има малка такса за caching и restore). Активирането е един параметър в CloudFormation или Terraform:

resource "aws_lambda_function" "checkout" {
  function_name = "checkout"
  runtime       = "python3.12"
  handler       = "app.handler"
  memory_size   = 1024
  architectures = ["arm64"]
  role          = aws_iam_role.lambda_role.arn
  filename      = "checkout.zip"

  snap_start {
    apply_on = "PublishedVersions"
  }
}

resource "aws_lambda_alias" "prod" {
  name             = "prod"
  function_name    = aws_lambda_function.checkout.function_name
  function_version = aws_lambda_function.checkout.version
}

Един улов, който ме удари при първо активиране: SnapStart работи само с published version, не с $LATEST. Ще трябва да setup-нете lifecycle с deploy, publish version и alias to new version. За production това всъщност е желана практика, защото ви дава clean rollback pathway. За детайли и ограничения проверете официалната SnapStart документация на AWS.

CloudWatch Logs: скритата половина от сметката

В моята практика съм виждал акаунти, където CloudWatch Logs таксата е 2-3 пъти по-голяма от самата Lambda сметка. Причината е проста: по default никой не задава retention period и логовете се пазят вечно, а всеки log line таксува $0.50/GB за ingestion и $0.03/GB/месец за storage. За висок-traffic Lambda с verbose logging това бързо се натрупва. Първият клиент, при който проверих това, плащаше повече за логове, отколкото за самите функции.

Три стъпки за намаляване на CloudWatch Logs разход

Задайте retention period на всички log групи. 7 дни за development, 30 дни за production, 90+ дни само където compliance го изисква. Default-ът е „никога".
Използвайте log level filtering в кода. Не оставяйте console.log в hot path. За structured logging използвайте AWS Lambda Powertools, което позволява LOG_LEVEL environment variable за динамично контролиране.
Разгледайте CloudWatch Logs Infrequent Access (обявен 2024). За архивни логове IA class е около 50% по-евтин от standard, с трейдоф на по-бавни queries.

# Terraform: задаване на retention за всички log групи наведнъж
resource "aws_cloudwatch_log_group" "lambda_logs" {
  for_each          = toset(local.function_names)
  name              = "/aws/lambda/${each.value}"
  retention_in_days = 30
  log_group_class   = "STANDARD"  # или "INFREQUENT_ACCESS" за архивни
  skip_destroy      = false
}

#!/bin/bash
# retention-cleanup.sh, стартирайте веднъж на нов акаунт
aws logs describe-log-groups \
  --log-group-name-prefix "/aws/lambda/" \
  --query "logGroups[?retentionInDays==null].logGroupName" \
  --output text | tr '\t' '\n' | while read lg; do
    aws logs put-retention-policy \
      --log-group-name "$lg" \
      --retention-in-days 30
    echo "Set 30-day retention: $lg"
done

Как да мониторирате разходите за Lambda

Без видимост оптимизацията е предположение. AWS предлага три инструмента, които трябва да настроите за всяка сериозна Lambda workload: Cost Explorer с daily granularity, Budgets за alert-и над threshold, и Cost Anomaly Detection за ML-базирано откриване на скокове. Пълните стъпки за настройка сме описали в нашето ръководство за AWS Cost Explorer, Budgets и Anomaly Detection.

Специфични метрики за Lambda в CloudWatch

Invocations: брой извиквания за периода
Duration: average, p95 и p99
ConcurrentExecutions: за capacity planning спрямо account limit (default 1000)
Throttles: ако виждате throttles с reserved concurrency, увеличете лимита; ако виждате throttles от account-level limit, отворете support case
ProvisionedConcurrencyUtilization: ако е под 60% продължително време, намалете PC или сменете на SnapStart
ClaimedAccountConcurrency: сумата от всички reserved concurrency в акаунта, за да не надхвърлите лимита

Cost per invocation metric

Създайте custom Cost Explorer report, групиран по USAGE_TYPE и филтриран по service = "AWS Lambda". Ще видите разбивка на:

Lambda-GB-Second: compute cost за x86
Lambda-GB-Second-ARM: compute cost за arm64
Request: invocation cost
Lambda-Provisioned-Concurrency: PC cost
Lambda-Storage-Duration: за Lambda ephemeral storage над 512 MB

Разделяйки по usage type веднага виждате къде отива бюджетът. Ако Lambda-GB-Second е 5x повече от Request, вашата оптимизация трябва да таргетира duration и памет, а не invocation честота.

Често допускани грешки при оптимизация на Lambda

1. Оптимизиране на памет без reprofiling

След code промяна (нова dependency, изменена логика, upgrade на runtime) старият Power Tuning резултат вече не важи. Reprofile-вайте след всеки major release, или поне на всеки 3 месеца за често-обновявани функции. Виждал съм екипи, които настроят паметта веднъж и я забравят с години.

2. Активиране на PC на всички функции

Provisioned Concurrency има смисъл само за latency-critical, високо-traffic пътища. За batch функции, cron-и и rarely-called endpoints това е чист waste. Използвайте SnapStart или просто приемете cold start-овете за не-latency-критични workloads.

3. Игнориране на VPC networking overhead

Lambda в VPC има елиминиран cold start overhead от 2019 насам, но междинните ENI и NAT Gateway транзитни разходи остават. Ако Lambda чете от private RDS/ElastiCache или прави outbound calls към AWS services, обмислете VPC endpoints вместо NAT Gateway. Виж нашето ръководство за AWS NAT Gateway разходи и VPC Endpoints.

4. Забравени тестови и dev функции

Използвайте tag-и (Environment=dev) и настройте автоматично изтриване на функции без invocations 30+ дни. AWS Trusted Advisor вече откроява такива функции безплатно, но реален cleanup изисква процес: CI/CD hook, който trigger-ва cleanup Lambda върху dev акаунта веднъж седмично.

5. Твърде агресивен timeout

Timeout над реалната p99 duration прави дълги грешки при downstream проблеми (retry storm-ите таксуват!). Задавайте timeout = p99 × 1.5, вместо default 3 сек или max 15 минути. Комбинирайте с DLQ (Dead Letter Queue) или Lambda destinations, за да не преизвиквате безкрайно.

6. Синхронни invocations, където async работи

Ако функция A трябва да trigger-не функция B, но не се нуждае от резултата, използвайте async invocation (InvocationType=Event) или EventBridge. Синхронен invoke от Lambda A към Lambda B държи A billed за цялото време, докато B работи. Плащате двойно за същата единица работа.

Често задавани въпроси

Колко струва AWS Lambda през 2026?

AWS Lambda таксува $0.20 за 1 милион invocations и $0.0000166667 за GB-секунда compute на x86 архитектура в us-east-1. ARM64 (Graviton2) е с 20% по-евтин. Free tier включва 1M заявки и 400K GB-секунди месечно, което покрива много малки проекти без разход.

По-евтин ли е Lambda от EC2?

За unpredictable, spiky workload с ниска утилизация Lambda е драстично по-евтин. За постоянен, високо-utilized traffic (24/7 API, който натоварва CPU 60%+), EC2 със Savings Plans обикновено печели. Break-even точката обичайно е около 40-50% utilization на еквивалентна инстанция.

Как да намаля cold start-овете на Lambda?

Три опции според случая: (1) Lambda SnapStart, безплатно за Python и .NET, малка такса за Java, намалява cold start до 90%; (2) Provisioned Concurrency, гарантирано без cold start, но струва пари всеки месец; (3) намаляване на deployment package size (tree shaking, esbuild за Node.js) и избягване на heavy dependencies при initialization.

Каква е разликата между Reserved и Provisioned Concurrency?

Reserved Concurrency е безплатен горен лимит за concurrency (throttling защита за downstream системи). Provisioned Concurrency плаща, за да държи N instances топли и премахне cold start-овете. Reserved таксува $0 и хвърля throttle грешки над лимита; Provisioned таксува около $4/месец per warm instance при 128 MB.

Струва ли си миграция към ARM64 за Lambda?

За Node.js, Python, Ruby и Go в 90% от случаите отговорът е да. Ще получите 20% отстъпка на compute price плюс често 15-19% по-добра производителност без промяна на кода. За функции с native compiled dependencies (Sharp, Pillow с SIMD extensions) проверете дали arm64 wheels/binaries са налични, преди да мигрирате.

Покрива ли Compute Savings Plans разходите за AWS Lambda?

Да, от 2024 г. Compute Savings Plans покриват Lambda invocations и duration с до 17% отстъпка при 1-годишен ангажимент (all-upfront). Provisioned Concurrency обаче е отделна категория и не се покрива. За него има отделен PC Savings Plan.