Оптимізація витрат AWS Lambda у 2026: коли Lambda дорожча за Fargate

Оновлено: 3 липня 2026

Оптимізація витрат AWS Lambda у 2026 році зводиться до трьох важелів: правильний розмір пам'яті (він же визначає CPU), архітектура Graviton (ARM) замість x86 та тверезий розрахунок точки беззбитковості, після якої Lambda стає дорожчою за Fargate Spot чи EC2. За п'ять років у CloudHealth я бачив десятки випадків, коли команди платили $40–$120k на місяць за Lambda-воркоди, які на Fargate Spot коштували б $8–$20k. Нижче, покроковий фреймворк, який я використовую в консалтинговій практиці для клієнтів зі спендом $200k–$2M.

• Ціна Lambda у 2026: $0.0000166667 за GB-секунду (x86) і $0.0000133334 за GB-секунду (Graviton/arm64); перехід на ARM економить рівно 20%.
• Точка беззбитковості проти Fargate Spot настає приблизно на 40–60% утилізації воркера: далі Lambda дорожчає нелінійно.
• AWS Lambda Power Tuning знаходить оптимальну конфігурацію пам'яті за 5–10 хвилин і часто зменшує рахунок на 20–45% без зміни коду.
• SnapStart для Java, .NET та Python (з 2024–2025) прибирає холодні старти безкоштовно й дозволяє відмовитись від Provisioned Concurrency, що коштує $0.0000041667/GB-с додатково.
• Найбільша прихована стаття витрат, це не сама Lambda, а вихідний трафік через NAT Gateway ($0.045/GB) для функцій у VPC; переносьте їх через VPC Endpoint для S3/DynamoDB.
• Реальний кейс з моєї практики: $310k/місяць скорочення за рахунок міграції відео-конвеєра з Lambda на Fargate Spot.

Скільки коштує AWS Lambda у 2026

Отже, з чого почати. Модель ціноутворення Lambda не змінилася за структурою, але дві важливі речі варто тримати в голові у 2026 році. По-перше, ARM (Graviton2) архітектура коштує рівно на 20% дешевше за x86: $0.0000133334 за GB-секунду проти $0.0000166667. По-друге, з листопада 2022 року Lambda білить у мілісекундах (не 100 мс блоках, як було раніше), тому короткі функції на кшталт API-респондерів справді дешевшають.

Розбивка платежів для функції з 1024 МБ пам'яті та 10 млн викликів на місяць з середньою тривалістю 200 мс на x86:

• Запити: 10 000 000 × $0.20/1M = $2.00
• Обчислення: 10 000 000 × 0.2 с × 1 GB × $0.0000166667 = $33.33
• Ephemeral storage (понад 512 МБ): зазвичай $0, але для ML-навантажень із 10 ГБ /tmp це додатковий $0.0000000358 за GB-с.
• Provisioned Concurrency (якщо ввімкнено): $0.0000041667/GB-с плюс знижена ставка обчислення.

Той самий воркод на Graviton коштує $28.66 замість $35.33: беззатратна економія 19%. Офіційна сторінка з тарифами розкриває деталі: AWS Lambda Pricing. Порівнюйте цю ціну з on-demand EC2 t4g.small ($12/міс) не в абсолютних числах, а через ефективну годинну ставку, і саме тут починається наступний розділ.

Коли Lambda стає дорожчою за Fargate чи EC2

Це запитання №1, яке мені ставлять клієнти: «а де саме Lambda перестає бути дешевою?» Простий емпіричний фреймворк, який я використовую: розрахуйте, скільки GB-секунд ви споживаєте на місяць, і поділіть на 2 592 000 (секунд у 30-денному місяці). Це ваша ефективна кількість «постійно працюючих» GB. Далі помножте на $0.0000166667 × 2 592 000 = $43.20. Це вартість 1 GB-місяця Lambda x86 при 100% утилізації.

Порівняйте з Fargate Spot: $0.01286632 за vCPU-годину та $0.00141375 за GB-годину. За 1 GB на місяць Fargate Spot коштує близько $1.02, а з відповідним vCPU (0.25), виходить приблизно $3.35 сумарно. Тобто Lambda в режимі 100% зайнятості дорожча за Fargate Spot приблизно у 13–15 разів. Точка беззбитковості для більшості real-world воркодів становить 40–60% ефективної утилізації.

Практично це означає: якщо ваша функція викликається безперервно понад 6–8 годин на добу з тривалістю понад 1 с, ви майже гарантовано переплачуєте. Аналогічний підхід я застосовую до EC2: пор. з правильним розміром EC2 через Compute Optimizer, де порогом є 40% CPU. Далі частина воркодів логічно мігрує на Spot Instances у AWS, Azure та GCP, де знижка ще глибша.

Метрика	Lambda (x86)	Lambda (Graviton)	Fargate Spot	EC2 Spot (t4g)
Ціна за GB-год	$0.060	$0.048	$0.00423	$0.0016
Плата за запит	$0.20/1M	$0.20/1M	n/a	n/a
Cold start	50–500 мс	50–400 мс	15–40 с	60–120 с
Мін. одиниця білінгу	1 мс	1 мс	1 с	1 хв (Linux)
Ризик переривання	0%	0%	~5–10%	~5%
Оптимальна утилізація	< 20%	< 25%	40–90%	60–100%

Як підібрати правильний розмір пам'яті через Power Tuning

Це найпоширеніша помилка, яку я знаходжу в аудитах: команди залишають дефолтні 128 МБ або підвищують до 3008 МБ «на всяк випадок». Обидва варіанти зазвичай коштують дорожче за оптимум. Причина в тому, що Lambda масштабує CPU лінійно від пам'яті: 1769 МБ = 1 vCPU. Функція, обмежена CPU (JSON парсинг, шифрування, ML-inference), може виконуватись у 3 рази швидше на 1792 МБ і в підсумку коштувати дешевше, ніж на 512 МБ.

Стандартний інструмент для цього, відкритий проєкт AWS від aws-lambda-power-tuning Алекса Касалбоні. Це Step Functions state machine, що прогонить вашу функцію на 6–10 різних значеннях пам'яті і будує криву «ціна vs час».

# Розгорнути через SAM (займає ~2 хвилини)
sam init --location https://github.com/alexcasalboni/aws-lambda-power-tuning \
  --output-dir ./power-tuning
cd power-tuning
sam build && sam deploy --guided \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM

# Запуск для конкретної функції
aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:us-east-1:111122223333:stateMachine:powerTuningStateMachine \
  --input '{
    "lambdaARN": "arn:aws:lambda:us-east-1:111122223333:function:image-resize",
    "powerValues": [128, 256, 512, 1024, 1536, 1792, 2048, 3008],
    "num": 50,
    "payload": {"bucket": "test-bucket", "key": "sample.jpg"},
    "parallelInvocation": true,
    "strategy": "balanced"
  }'

У моїй практиці Power Tuning знаходить економію 20–45% на 60–70% проаудитованих функцій. Стратегія balanced оптимізує співвідношення 50/50 ціна/швидкість; cost оптимізує тільки за ціною, а speed, тільки за швидкістю. Для user-facing API беріть speed, для фонових ETL, cost.

Graviton (ARM) у Lambda: 20% економії за 1 клацання

Чесно кажучи, це найпростіше рішення з усього списку. З 2021 року Lambda підтримує архітектуру arm64 (Graviton2), а у 2026 році це production-ready для >95% типових Node.js, Python, Go, Java та .NET воркодів. Різниця в ціні, рівно 20% на обчислення; і на моїй практиці міграція займає 5 хвилин для більшості функцій.

Проста зміна в SAM або CDK:

# SAM template (AWS::Serverless::Function)
Resources:
  ImageResize:
    Type: AWS::Serverless::Function
    Properties:
      Architectures:
        - arm64        # було: x86_64
      Runtime: python3.12
      MemorySize: 1024
      Handler: app.lambda_handler
      # Пакет із нативними бібліотеками (наприклад Pillow) потрібно
      # білдити під arm64:
      #   docker run --platform linux/arm64 -v $PWD:/var/task \
      #     public.ecr.aws/sam/build-python3.12 pip install -r requirements.txt -t python/

Пастки, на які натрапляють клієнти:

• Нативні бінарники. Pillow, numpy, pandas, lxml, cryptography, gRPC, sharp: усі вимагають перезбирання під linux/arm64. У 99% випадків це один рядок у Dockerfile.
• Lambda Layers. Layer із x86 бінарниками зламає arm64 функцію без явної помилки: просто ImportError у рантаймі. Створюйте окремі шари або мультиархітектурні.
• Тести CI. Якщо ваш GitHub Actions білдить на x86 і деплоїть на arm64, невдалі імпорти проходять непоміченими. Додавайте runs-on: ubuntu-24.04-arm у релевантні джоби.

SnapStart проти Provisioned Concurrency: що обрати у 2026

Провізіонована конкурентність (Provisioned Concurrency), це буквально «гарячі» контейнери, за які ви платите цілодобово незалежно від запитів. Ставка: $0.0000041667/GB-с додатково, тобто ~$10.80 на 1 GB на місяць. Для 20 забезпечених екземплярів по 1024 МБ це $216/міс постійного платежу. І саме тут з'являється спокуса викинути гроші, коли SnapStart вирішить проблему безкоштовно.

SnapStart, це фіча, яка робить снапшот ініціалізованого рантайму й відновлює його за <100 мс. У 2022 році з'явився для Java 11+, у 2024 розширений на Python 3.12+ та .NET 8+. Активація безкоштовна для запитів; ви платите лише за кеш снапшоту ($0.0000015 за GB-год за версію функції). Деталі активації описані в офіційній документації Lambda SnapStart.

Мій алгоритм вибору у 2026: якщо це Java/Python/.NET, завжди SnapStart, а Provisioned Concurrency лише як fallback для унікальних кейсів (наприклад, LLM inference з великим VRAM state). Якщо Node.js або Go, то cold start і без того <150 мс, тому нічого не потрібно.

Приховані витрати: VPC, NAT Gateway та ефемерне сховище

Найбільший недооцінений компонент Lambda-рахунків, це не сама Lambda. У проєктах, що я аудитував, від 25 до 60% реального «Lambda spend» насправді витрачалося на суміжні сервіси. Три головні:

1. NAT Gateway: тихий убивця

Функція у VPC без Internet Gateway ходить у S3, DynamoDB, зовнішні API через NAT Gateway. Тариф: $0.045 за 1 GB обробленого трафіку плюс $0.045/год за сам NAT. Для функції, що щогодини вантажить 500 МБ з S3, це $16 200 на місяць лише за NAT-процессинг (сам колись пропустив це у клієнтському рахунку, потім довелось довго пояснювати). Рішення: VPC Gateway Endpoints для S3 та DynamoDB (безкоштовні) та VPC Interface Endpoints для інших сервісів ($0.01/год + $0.01/GB, приблизно вдвічі дешевше NAT). Детальніше в моєму матеріалі про зменшення витрат на egress-трафік.

2. CloudWatch Logs

Лямбда пише все в CloudWatch Logs: $0.50 за GB інгестії плюс $0.03/GB на місяць за зберігання. Функція з рівнем DEBUG і 10 млн викликів легко генерує 200+ GB логів, це $103/міс. Тримайте ретеншен 7–14 днів для не-критичних функцій і експортуйте у S3 Glacier для відповідності.

3. Ephemeral storage (/tmp) та Lambda Layers

Максимум /tmp зараз 10 240 МБ. Кожен GB понад 512 МБ коштує $0.0000000358 за GB-с. Це копійки для більшості, але для ML-inference з розпаковкою моделі це може складати $150–$400/міс. Розгляньте Container Image Lambda (до 10 ГБ) замість layer+/tmp.

Кейс: міграція $310k/місяць з Lambda на Fargate Spot

Клієнт, стрімінговий стартап розміром ~$1.6M/міс на AWS. Головна стаття витрат, відео-конвеєр: ~2 800 паралельних Lambda-функцій, кожна ffmpeg-транскод сегмента 6-секундного HLS. Пам'ять 3008 МБ, тривалість ~45 с. Рахунок за Lambda: $412k/місяць плюс $71k за пов'язаний трафік NAT.

Що ми зробили за 6 тижнів:

1. Тиждень 1–2: запакували ffmpeg у Docker-образ, розгорнули на Fargate Spot із tasksize 4 vCPU / 8 GB. Основний трюк тут, переписати оркестрацію зі Step Functions на SQS + Auto Scaling based on queue depth.
2. Тиждень 3: обробили ризик переривання Spot: додали idempotency check у SQS message deduplication, налаштували stopTimeout: 120 та SIGTERM handler у контейнері, щоб дотранскодити поточний сегмент.
3. Тиждень 4: shadow-режим (10% трафіку). Виміряли p99 latency 68 с (Lambda: 51 с). Прийнятно для фонового конвеєра.
4. Тиждень 5–6: повний cutover, Lambda залишили як fallback для черг понад 10 хв.

Результат: Fargate Spot spend приблизно $89k/міс, NAT приблизно $12k (більшість трафіку залишилась усередині VPC до S3 через Gateway Endpoint). Загальне скорочення, $382k. Вирахувавши додаткові витрати ECR/CloudWatch, чиста економія $310k/місяць, повернення інвестицій за 3 дні роботи інженера.

Моніторинг і атрибуція Lambda-витрат

Тепер про моніторинг. Без атрибуції ви просто не знаєте, які функції реально коштують багато. Lambda підтримує cost-allocation теги, які пробрасуються в Cost Explorer. У multi-account setup я рекомендую комбінацію з стратегією тегування AWS Organizations: обов'язкові теги team, service, environment, cost-center. AWS Config rule блокує деплой без них.

# AWS CLI: розбивка Lambda за тегом team
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE Type=TAG,Key=team \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Lambda"]}}' \
  --query 'ResultsByTime[0].Groups[?Metrics.UnblendedCost.Amount > `100`]'

Для команд, що хочуть глибше: увімкніть CUR 2.0 (Cost and Usage Report) з погодинною гранулярністю та завантажте у Athena. Так ви побачите costs per function per hour, що необхідно для розрахунку точки беззбитковості з попереднього розділу. FinOps Foundation опублікувала специфікацію FOCUS 1.1 у 2025 році, і всі великі провайдери мапіруються на неї, тож ваша аналітика працюватиме і в multi-cloud.

Дашборд-мінімум для Lambda spend

• Cost per invocation по кожній функції (топ-20 за спендом).
• GB-seconds/day тренд: стрибки означають регресію коду або зростання пам'яті.
• NAT Gateway bytes processed помножено на $0.045: окремий tile.
• Concurrent executions проти регіонального ліміту 1000: якщо ви близько, час дивитись у бік Fargate.

Часті питання

Скільки коштує 1 мільйон викликів AWS Lambda у 2026?

За стандартним тарифом $0.20 за запити плюс обчислення. Для функції 1024 МБ / 100 мс на x86 це ще $1.67, разом $1.87. На Graviton виходить $1.53. Перші 1 мільйон запитів і 400 000 GB-с щомісяця залишаються у Free Tier.

Чи справді Graviton завжди дешевший за x86 у Lambda?

Так, за ціною обчислення завжди на 20% дешевший. Виняток, якщо ваш код працює на Graviton істотно повільніше через відсутність оптимізованих бібліотек (рідко у 2026). Завжди міряйте p50/p95 після міграції: іноді +30% часу зжирає економію.

Коли варто вимкнути Provisioned Concurrency?

Якщо ваш рантайм підтримує SnapStart (Java, Python 3.12+, .NET 8+), вимикайте PC після A/B тесту латентності. SnapStart дає <100 мс cold start безкоштовно. Для Node.js та Go PC зазвичай не потрібен, оскільки native cold start і так <200 мс.

Як зрозуміти, що Lambda дорожча за EC2 для мого воркоду?

Розрахуйте ефективну GB-годину: (invocations × duration_sec × memory_gb) / 3600. Якщо ця цифра перевищує 40–50% від безперервно працюючого сервера аналогічного розміру, EC2 (особливо Spot) буде дешевшою. Використайте AWS Compute Optimizer: він з 2024 року містить рекомендації для Lambda.

Що робити з холодними стартами Java Lambda?

По-перше, увімкніть SnapStart. Це знімає 70–90% проблеми безкоштовно. По-друге, переходьте на GraalVM native image (Quarkus, Micronaut) для cold start <50 мс. По-третє, оптимізуйте класи в phase INIT: lazy-load Spring Beans, не робіть DB connect на верхньому рівні.

Чи можна використовувати Fargate Spot замість Lambda для API?

Так, якщо ви маєте більше 15–30 rps стабільно і латентність p95 <500 мс достатня. Комбінуйте з ALB та Auto Scaling. Для sporadic API (менше 5 rps) Lambda залишається кращою через квант часу і cold start > час старту Fargate task.