Serverless затраты: Lambda, Azure, GCP…

Q: Включает ли Free Tier Lambda холодные старты и init duration?

Init duration без SnapStart и без Provisioned Concurrency не входит в биллинг GB-секунд и не съедает Free Tier. С SnapStart и PC init биллится. Это явное изменение 2024 года, которое часто упускают. Если функция активно использует SnapStart, держите cold init под 500 мс.

Q: Стоит ли мигрировать с Cloud Functions Gen 1 на Cloud Run Functions?

Да, если ваши функции работают дольше 100 мс или имеют конкурентные запросы. Биллинг 100 мс (вместо 100 мс минимум в Gen 1) и concurrency до 1000 на инстанс снижают счёт в 3-10 раз для типичных API. Для редких триггеров (раз в час и реже) разница минимальна.

Q: Как понять, что моя Lambda переразмерена по памяти?

Смотрите метрику MaxMemoryUsed в логах CloudWatch (строка REPORT ). Если она постоянно меньше 60% от выделенной памяти и при этом длительность не CPU-зависимая (нет интенсивных вычислений), можно безопасно опустить memory_size на следующий шаг вниз. Делайте через Lambda Power Tuning, чтобы не сломать перформанс на CPU-bound операциях.

Q: Покрывает ли Compute Savings Plan функции в разных регионах?

Да. Compute Savings Plan, в отличие от EC2 Reserved Instances, не привязан к региону и автоматически применяется ко всем подходящим вычислительным ресурсам (Lambda, Fargate, EC2) во всех регионах вашего аккаунта или Organization. Это делает его идеальным для мульти-региональных serverless-архитектур.

Обновлено: 27 июня 2026

Оптимизация затрат на serverless сводится к трём ключевым решениям: правильный подбор объёма памяти под фактический CPU-профиль функции, переход на ARM-архитектуру (AWS Graviton2, Azure Functions Flex) и покупка Compute Savings Plans для предсказуемой части нагрузки. На практике эти три рычага дают экономию 40–72% от исходного счёта Lambda без снижения SLA. В этом руководстве разберём ценовые модели AWS Lambda, Azure Functions и Google Cloud Functions 2-го поколения по состоянию на июнь 2026 года и пройдём по конкретным шагам с примерами кода и формулами.

Честно говоря, после десятка FinOps-аудитов я пришёл к выводу: дороже всего стоит не сама Lambda, а неправильные допущения про неё. Дальше разберём, как их вычистить.

AWS Lambda на Graviton2 (arm64) дешевле x86 на 20% при той же памяти и часто работает быстрее на JIT-нагрузках (Node.js, Python с PyPy, Java 21).
Память Lambda определяет долю vCPU линейно: при 1 769 МБ функция получает полное ядро. Тюнинг через AWS Lambda Power Tuning почти всегда сокращает GB-секунды.
Compute Savings Plans покрывают Lambda, Fargate и EC2 одновременно и дают до 17% скидки на Lambda при коммите на 1-3 года.
В Azure Functions новый Flex Consumption Plan (GA с марта 2025) поддерживает Always Ready instances вместо дорогих Premium-планов и стоит в 2-3 раза дешевле.
Google Cloud Run Functions (бывшие Cloud Functions 2-го поколения) переехали на инфраструктуру Cloud Run в августе 2024 года. Биллинг идёт за CPU/Memory request с интервалом 100 мс, а не за полную аллокацию.
Анти-паттерны, съедающие 30-60% бюджета: рекурсивные триггеры S3 → Lambda → S3, синхронные API Gateway-вызовы из Lambda в Lambda и DynamoDB-стримы без Reserved Concurrency.

Как устроена цена serverless в 2026: AWS, Azure, GCP

Все три провайдера выставляют счёт по двум осям: количество вызовов и GB-секунды (объём выделенной памяти × длительность выполнения). По состоянию на июнь 2026 года цены в регионе us-east-1 / westeurope / europe-west1 выглядят так:

Параметр	AWS Lambda (x86)	AWS Lambda (arm64)	Azure Functions Flex	GCP Cloud Run Functions
Цена за 1M вызовов	$0,20	$0,20	$0,20	$0,40
Цена за GB-секунду	$0,0000166667	$0,0000133334	$0,000016	$0,0000025 (CPU) + $0,0000025 (Memory)
Free Tier (ежемесячно)	1M вызовов + 400 000 GB-с	1M вызовов + 400 000 GB-с	1M вызовов + 400 000 GB-с	2M вызовов + 360 000 GB-с
Гранулярность биллинга	1 мс	1 мс	1 мс	100 мс
Макс. длительность	15 минут	15 минут	60 минут (с лимитом)	60 минут (HTTP) / 9 минут (events)
Скидки за коммит	Compute Savings Plans до 17%	Compute Savings Plans до 17%	Reserved Capacity до 55%	Committed Use Discounts до 17%

Ключевое отличие 2026 года: биллинг Cloud Run Functions раздельный по CPU и Memory. Это значит, что аллоцировав 1 vCPU и 512 МБ, вы платите за каждый ресурс независимо. Для CPU-bound нагрузок это выгоднее Lambda, а для memory-bound, наоборот, дороже.

Подробные актуальные тарифы Lambda задокументированы в официальной таблице цен AWS Lambda, а изменения биллинга Cloud Run описаны в документации Google Cloud Run Pricing. Эти страницы стоит держать в закладках: цены меняются раз в полгода без громких анонсов.

Тюнинг памяти и CPU: главный рычаг экономии в Lambda

В Lambda объём памяти линейно связан с долей vCPU. При 128 МБ функция получает ~7,5% ядра, при 1 769 МБ — полное ядро (vCPU 1.0), при 10 240 МБ выделяется 6 ядер. Это означает, что увеличение памяти часто сокращает длительность выполнения сильнее, чем растёт цена за GB-секунду. Классический пример: функция на Node.js, парсящая 5 МБ JSON, при 512 МБ выполняется 2 800 мс, а при 1 792 МБ всего 720 мс. Счёт падает с 1 433 GB-с/100K до 1 290 GB-с/100K, плюс выигрыш в латентности.

Не тюньте память на глаз. Используйте AWS Lambda Power Tuning, инструмент на Step Functions, который прогоняет вашу функцию на разных уровнях памяти и строит график «стоимость vs время». Установка занимает 3 минуты через SAM:

sam init --location https://github.com/alexcasalboni/aws-lambda-power-tuning.git
cd aws-lambda-power-tuning
sam deploy --guided --stack-name lambda-power-tuning

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:my-api-handler",
    "powerValues": [128, 256, 512, 1024, 1769, 3008],
    "num": 50,
    "payload": {"path": "/users/42"},
    "parallelInvocation": true,
    "strategy": "balanced"
  }'

На выходе получите URL визуализации с рекомендованным конфигом. Совет на практике: для API-обработчиков выбирайте strategy=balanced, для пакетной обработки берите cost, а для критичных пользовательских путей ставьте speed.

Переход на ARM (Graviton2): 20% за один клик

AWS Graviton2 для Lambda доступен с 2021 года, но многие команды до сих пор не мигрировали. Прайс на arm64 на 20% дешевле x86, а производительность в среднем на 19% выше для интерпретируемых рантаймов (Python, Node.js, Ruby) и для Java 17+. Итоговая экономия выходит около 34% совокупной стоимости при равной нагрузке.

Миграция в Terraform — одна строка:

resource "aws_lambda_function" "api_handler" {
  function_name = "api-handler"
  runtime       = "nodejs20.x"
  handler       = "index.handler"
  role          = aws_iam_role.lambda.arn
  filename      = "function.zip"
  memory_size   = 1024
  timeout       = 30

  # вот это
  architectures = ["arm64"]

  environment {
    variables = {
      LOG_LEVEL = "INFO"
    }
  }
}

Подводные камни: нативные зависимости (например, sharp для обработки изображений, node-canvas, bcrypt) нужно пересобрать под arm64. Используйте esbuild с флагом --platform=node --target=node20 и собирайте образ в контейнере public.ecr.aws/sam/build-nodejs20.x:latest-arm64. Для Python чувствительны к ARM пакеты pandas, numpy, pillow. Их ставьте через --platform manylinux2014_aarch64.

Холодные старты и Provisioned Concurrency: когда платить, а когда нет

Холодный старт — это не только UX-проблема, но и стоимостный фактор. Время инициализации (init duration) до Node.js 20 не биллилось, а с релиза SnapStart для Python и Node.js в конце 2024 года init duration входит в биллинг для Provisioned Concurrency. Это значит, что неоптимизированный bundle на 25 МБ обойдётся в реальные деньги.

Стратегия 2026 года:

Не включайте Provisioned Concurrency «на всякий случай». Она стоит ~$0,0000041667 за GB-с в простое: для 1024 МБ × 10 инстансов это $108 в месяц без единого вызова.
Используйте Application Auto Scaling для PC по расписанию: WORKDAY 09:00-19:00 = 50 инстансов, остальное время = 5.
Включите SnapStart для Java и Python. Это снижает cold start с 4-8 с до 200-400 мс бесплатно.
Уменьшайте размер пакета. Lambda Layer с тяжёлыми зависимостями выгружается дольше, чем встроенный bundle с tree shaking.

Если у вас уже выстроено тегирование инфраструктуры, понять реальный профиль вызовов помогут отчёты Cost Explorer. Базовую методологию мы разобрали в материале про тегирование облачных ресурсов для аллокации затрат.

Compute Savings Plans для Lambda

Compute Savings Plans (CSP) это единственный механизм коммитов, покрывающий Lambda. В отличие от EC2 Reserved Instances, CSP не привязан к конкретной функции, региону или семейству. Это коммит «в долларах в час». Скидка на Lambda составляет до 17% за 1-летний all-upfront и до 12% за 3-летний no-upfront.

Как рассчитать оптимальный коммит, не переплатив:

# Получаем средние почасовые траты на Lambda за последние 30 дней
aws ce get-cost-and-usage \
  --time-period Start=2026-05-27,End=2026-06-26 \
  --granularity HOURLY \
  --metrics "UnblendedCost" \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Lambda"]}}' \
  --output json > lambda_hourly.json

# Берём 25-й перцентиль почасовых расходов как safe commit base
python3 -c "
import json, statistics
data = json.load(open('lambda_hourly.json'))
costs = [float(r['Total']['UnblendedCost']['Amount']) for r in data['ResultsByTime']]
print(f'p25 hourly: \${statistics.quantiles(costs, n=4)[0]:.2f}')
print(f'median:     \${statistics.median(costs):.2f}')
print(f'p75:        \${statistics.quantiles(costs, n=4)[2]:.2f}')
"

Коммитьте сумму на уровне p25: она почти всегда утилизируется на 100%, а остальное оплачивается по on-demand. Не пытайтесь покрыть пик. Неутилизированные часы CSP сгорают, и любой простой обнуляет преимущество. Эта же методология описана для других сервисов в нашем руководстве по облачным обязательствам 2026.

Azure Functions Flex Consumption: альтернатива Premium

В марте 2025 Microsoft перевела Flex Consumption Plan в GA. Это новый план, который заменяет Premium для большинства сценариев. Главные отличия от старого Consumption:

VNet integration, без перехода на Premium ($300+/мес базовая стоимость).
Always Ready instances: фиксированное число прогретых инстансов вместо непредсказуемых cold starts.
Per-instance memory до 4 ГБ (против 1,5 ГБ в Consumption).
HTTP-триггеры с длительностью до 60 минут для долгих задач.

Конфиг через Bicep:

resource flexFunctionApp 'Microsoft.Web/sites@2024-04-01' = {
  name: 'api-flex-func'
  location: location
  kind: 'functionapp,linux'
  properties: {
    serverFarmId: flexPlan.id
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.properties.primaryEndpoints.blob}deployment'
        }
      }
      scaleAndConcurrency: {
        maximumInstanceCount: 100
        instanceMemoryMB: 2048
        alwaysReady: [
          { name: 'http', instanceCount: 2 }
        ]
      }
      runtime: { name: 'node', version: '20' }
    }
  }
}

GCP Cloud Run Functions: новая модель биллинга

В августе 2024 Google объединил Cloud Functions 2-го поколения с Cloud Run под брендом Cloud Run Functions. Старые Cloud Functions Gen 1 остаются в режиме поддержки, но новые проекты лучше создавать сразу на Cloud Run. Главное преимущество для бюджета: гранулярность биллинга 100 мс и раздельный учёт CPU/Memory.

gcloud run deploy api-handler \
  --source . \
  --region europe-west1 \
  --cpu 1 \
  --memory 512Mi \
  --concurrency 80 \
  --min-instances 0 \
  --max-instances 100 \
  --cpu-throttling \
  --execution-environment gen2

Флаг --concurrency 80 позволяет одному инстансу обрабатывать до 80 одновременных HTTP-запросов. У Lambda этого нет, там модель one-request-per-instance. Для лёгких I/O-bound функций это режет счёт в 5-20 раз: один инстанс делает работу за восьмерых, иногда и больше.

Опция --cpu-throttling (включена по умолчанию) останавливает биллинг CPU между запросами, оставляя память «горячей». Если у вас фоновые задачи (стрим, websocket), выключайте, иначе они умрут в дросселе.

Антипаттерны, которые удваивают счёт

За пять лет аудитов serverless-систем мы видели одни и те же ловушки. Топ-5 по частоте:

Рекурсивная цепочка S3 → Lambda → S3 в одном bucket. Функция пишет в тот же бакет, на который подписана, и каждое обновление перезапускает её. В 2023 году один клиент получил счёт на $48 000 за выходные. Защита: триггер только на префикс input/, запись в префикс output/.
Синхронные Lambda → Lambda вызовы. Пока внешняя функция ждёт ответа, биллинг идёт на обеих. Используйте Step Functions или EventBridge для асинхронного fan-out.
Отсутствие Reserved Concurrency на DynamoDB Streams. Throttling источника вызывает retry-storm и взрывной рост вызовов. Поставьте лимит = 50% от max concurrency аккаунта.
Чрезмерные retry в SQS. maxReceiveCount=10 при failed message = 10× счёт. Ставьте 3 и отправляйте в DLQ.
Логирование всего запроса в CloudWatch на DEBUG. CloudWatch Logs Ingestion часто превышает стоимость самой Lambda ($0,50/GB). Используйте sampling.

Эти ловушки родственны проблемам, описанным в материале о стоимости egress-трафика в AWS, Azure и GCP: там тот же паттерн, невидимая утечка маленькими порциями.

Мониторинг и алёрты на аномалии

Любая serverless-оптимизация должна заканчиваться алёртами, иначе через квартал всё деградирует обратно. Минимальный набор для AWS:

# CloudWatch Anomaly Detector на ежедневные траты Lambda
aws cloudwatch put-anomaly-detector \
  --namespace AWS/Lambda \
  --metric-name Duration \
  --stat Average \
  --dimensions Name=FunctionName,Value=api-handler

aws cloudwatch put-metric-alarm \
  --alarm-name lambda-cost-anomaly \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum \
  --period 21600 \
  --evaluation-periods 1 \
  --threshold-metric-id ad1 \
  --comparison-operator GreaterThanUpperThreshold \
  --metrics '[{
    "Id": "m1",
    "MetricStat": {"Metric": {"Namespace":"AWS/Billing","MetricName":"EstimatedCharges","Dimensions":[{"Name":"ServiceName","Value":"AWSLambda"}]},"Period":21600,"Stat":"Maximum"}
  },{
    "Id": "ad1",
    "Expression": "ANOMALY_DETECTION_BAND(m1, 2)"
  }]' \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:cost-alerts

В Azure аналог называется Cost Anomaly Detection в Cost Management (бесплатно с 2024 года), в GCP это Recommender API с фильтром google.run.service.CostRecommender. Подпишите алёрты на тот же Slack-канал, что и инциденты прода. Стоимость это тоже инцидент, просто отложенный.

Часто задаваемые вопросы

Что дешевле для постоянной нагрузки: Lambda или EC2/Fargate?

Эмпирическое правило: если функция запускается чаще, чем 1 раз в 2 секунды, и работает дольше 200 мс, Fargate Spot или t4g.small с Compute Savings Plan почти всегда дешевле Lambda. Для пиковых API с трафиком до 100 RPS и долей p99 < 500мс Lambda на arm64 + CSP остаётся выгоднее за счёт нулевой оплаты в простое.

Включает ли Free Tier Lambda холодные старты и init duration?

Init duration без SnapStart и без Provisioned Concurrency не входит в биллинг GB-секунд и не съедает Free Tier. С SnapStart и PC init биллится. Это явное изменение 2024 года, которое часто упускают. Если функция активно использует SnapStart, держите cold init под 500 мс.

Стоит ли мигрировать с Cloud Functions Gen 1 на Cloud Run Functions?