Оптимизация на разходите за AWS CloudWatch Logs: ingestion, Infrequent Access и Insights (2026)

Обновено: 16 август 2026 г.

AWS CloudWatch Logs разходите се намаляват чрез комбинация от преминаване към Infrequent Access log class (50% отстъпка на ingestion), задаване на retention policies (по подразбиране логовете стоят завинаги), филтриране на шума със subscription filters и експортиране на архивните данни в S3 Glacier. В повечето multi-account среди тези четири мерки свалят месечната сметка с 40–70%. Ingestion таксата от $0.50/GB (us-east-1) е най-големият дял, защото по-евтино е да пишете по-малко, отколкото да съхранявате по-хитро.

• Ingestion (приемането) е 80–90% от разходите за CloudWatch Logs: $0.50/GB в us-east-1, срещу $0.03/GB/месец за storage.
• Log class Infrequent Access (пуснат 2023 г., достъпен във всички търговски региони) намалява ingestion до $0.25/GB, без промяна в кода на приложението.
• Log groups без retentionInDays се съхраняват завинаги. По подразбиране това генерира тих дълг, който расте линейно.
• Vended logs (VPC Flow Logs, CloudTrail data events, Route 53) използват отделна тарифа и трябва да се насочват директно към S3, не към CloudWatch Logs.
• CloudWatch Logs Insights таксува $0.005/GB сканирани данни. Една неоптимизирана заявка върху VPC Flow Logs може да струва десетки долари.
• Multi-account setup: изпратете production логовете в централен log archive account през subscription filters и Firehose към S3, а не през cross-account log destinations.

Защо CloudWatch Logs е толкова скъп?

Ако сте отваряли Cost Explorer с групировка по SERVICE и сте видели ред AmazonCloudWatch в топ 3, познавате чувството. В повечето случаи причината е една: ingestion таксата от $0.50/GB (us-east-1; други региони варират до $0.90/GB). Storage е почти безплатен в сравнение, само $0.03/GB/месец, което на година прави $0.36/GB. С други думи, ако запишете 1 TB логове веднъж, платените $500 за ingestion остават, дори ако след ден изтриете всичко.

В моята практика с multi-account setup-и (обикновено 30–150 акаунта в един AWS Organization) най-често виждам три доминиращи източника на шокове в сметката:

1. Verbose Lambda функции с console.log(JSON.stringify(event)) върху високо-QPS ендпойнти. Един endpoint с 500 rps × 5KB event × 30 дни = 6.5 TB/месец = $3,250 само за ingestion.
2. VPC Flow Logs, насочени към CloudWatch Logs вместо към S3. Един натоварен VPC генерира десетки GB на ден при ALL traffic capture.
3. Липсваща retention policy. Log groups растат безкрайно, докато някой не забележи в годишния review.

Ключът е да разделите проблема на две решения: по-малко данни на входа (filtering, sampling, structured logging) и по-евтин клас данни (IA log class, S3 archive). Първото винаги дава по-голяма отстъпка от второто.

Ценова структура на CloudWatch Logs през 2026 г.

За да оптимизирате разумно, трябва да знаете какво плащате. Ето актуалната ценова матрица (us-east-1, регионалните разлики са ~10–30%):

Компонент	Standard log class	Infrequent Access (IA)
Ingestion (приемане)	$0.50 / GB	$0.25 / GB
Storage (архив)	$0.03 / GB / месец	$0.03 / GB / месец
Insights заявки	$0.005 / GB сканиран	$0.005 / GB сканиран
Live Tail (за 5 min)	$0.01 / min	Не се поддържа
Metric filters	Включени безплатно	Не се поддържат
Data protection (маскиране на PII)	Поддържа се	Поддържа се
Subscription filters	Поддържа се	Поддържа се

Vended logs (VPC Flow Logs, Route 53 Query Logs, CloudTrail data events, Elemental MediaTailor) имат отделна тарифа: $0.25/GB ingestion към CloudWatch Logs, но само $0.05/GB при директен export към S3. Това е 5x разлика, за която ще говорим подробно в секцията за vended logs.

Log class Infrequent Access: 50% отстъпка за минути

CloudWatch Logs Infrequent Access (IA) е новият log class, обявен от AWS в края на 2023 г. и разширен през 2024–2025 г. до всички търговски региони. Основната идея е проста. Логове, които четете рядко (audit trails, дебъг за incident response, compliance архив), не се нуждаят от Live Tail и metric filters, но поглъщат същия ingestion бюджет. IA намалява ingestion таксата от $0.50 на $0.25/GB. Половин цена без промяна в кода.

За кои log groups има смисъл да преминете на IA? По моята евристика:

• Audit логове (CloudTrail management events, custom compliance streams)
• Debug логове от Lambda функции, които четете само след инцидент
• Дългосрочен архив, който държите заради регулация (PCI-DSS, GDPR)
• Логове с обем над 100 GB/месец на log group, където 50% отстъпка има реална стойност

Не преминавайте на IA за: production APM логове, които четете чрез Live Tail; log groups с активни metric filters (те няма да работят); real-time monitoring dashboards.

Създаване на нов log group директно в IA клас с AWS CLI:

aws logs create-log-group \
  --log-group-name /aws/lambda/my-audit-processor \
  --log-group-class INFREQUENT_ACCESS \
  --tags Environment=prod,CostCenter=finops-1042,LogPurpose=audit

Съществуващ log group не може да се промени in place. Трябва да създадете нов IA log group, да пренасочите приложението към него и да експортирате стария в S3. За Lambda това е промяна на logGroupName в advanced logging controls.

Retention policies: спрете тихия дълг

Log groups в CloudWatch по подразбиране нямат retention. Това означава, че всеки байт, който сте приели през 2018 г., все още ви струва $0.03/GB/месец, освен ако не сте задали изрично retentionInDays. При multi-account setup с 30+ акаунта и 200+ log groups това лесно се превръща в няколко TB "забравени" данни.

Първата ми стъпка при аудит на нов клиент винаги е този скрипт. Той намира всички log groups без retention и генерира CSV, който да отворя в spreadsheet за преглед:

#!/bin/bash
# Списък на log groups без retention policy във всички региони
REGIONS=$(aws ec2 describe-regions --query 'Regions[].RegionName' --output text)
echo "Region,LogGroupName,StoredBytes,CreationTime" > no-retention.csv

for region in $REGIONS; do
  aws logs describe-log-groups \
    --region "$region" \
    --query 'logGroups[?retentionInDays==`null`].[logGroupName,storedBytes,creationTime]' \
    --output text | while read name bytes ctime; do
      echo "$region,$name,$bytes,$ctime" >> no-retention.csv
  done
done

# Сортирай по обем в MB, най-скъпите отгоре
sort -t',' -k3 -rn no-retention.csv | head -50

След като идентифицирате кандидатите, задайте retention (в дни; валидните стойности са 1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1096, 1827, 2192, 2557, 2922, 3288, 3653):

aws logs put-retention-policy \
  --log-group-name /aws/lambda/legacy-cron-worker \
  --retention-in-days 30

За предотвратяване на бъдещ дълг, включете Service Control Policy (SCP) на ниво AWS Organization, която задава default retention чрез aws:RequestTag. Комбинирайте я с задължителна tagging стратегия за cost allocation, за да имате видимост кой екип какъв log volume произвежда.

Как да намалите ingestion такси за Lambda и ECS

Ingestion е основното бойно поле. Тук няма магическо копче, има технически решения, които трябва да приложите на ниво приложение. Ето подхода, който съм използвал десетки пъти.

1. Структурирано логване с level filters

Изхвърлете console.log и минете на структурирано JSON logging (Powertools for Lambda, pino, structlog). После задайте log level дефолт на WARN в production и позволете runtime override през environment variable:

// Node.js Lambda с AWS Lambda Powertools
import { Logger } from '@aws-lambda-powertools/logger';

const logger = new Logger({
  serviceName: 'orders-api',
  logLevel: process.env.LOG_LEVEL || 'WARN',
  sampleRateValue: 0.1,  // 10% sampling на DEBUG events
});

export const handler = async (event) => {
  logger.debug('Full event received', { event });  // само 10% ще стигнат до CW
  logger.info('Processing order', { orderId: event.orderId });
  // ...
};

sampleRateValue е недооценена функция. При 500 rps × 30% DEBUG обем × 10% sampling получавате 97% спестяване на този клас логове, без да губите наблюдаемост при инциденти (когато вдигате sample rate на 100% за 30 минути). Честно, използвам точно това на почти всяка production Lambda от 2022 г. насам.

2. Advanced Logging Controls за Lambda

От средата на 2024 г. Lambda поддържа Advanced Logging Controls: задавате format (JSON или Text), system log level, application log level и target log group, включително IA log group. Пример за Terraform:

resource "aws_lambda_function" "orders_api" {
  function_name = "orders-api"
  role          = aws_iam_role.lambda.arn
  handler       = "index.handler"
  runtime       = "nodejs20.x"

  logging_config {
    log_format            = "JSON"
    application_log_level = "WARN"
    system_log_level      = "WARN"
    log_group             = aws_cloudwatch_log_group.orders_api_ia.name
  }
}

resource "aws_cloudwatch_log_group" "orders_api_ia" {
  name              = "/aws/lambda/orders-api"
  retention_in_days = 30
  log_group_class   = "INFREQUENT_ACCESS"
}

3. ECS/Fargate: awsfirelens вместо awslogs

Стандартният awslogs driver в ECS изпраща всичко в CloudWatch Logs. При shift към awsfirelens (Fluent Bit sidecar) можете да маршрутизирате INFO логове към S3, ERROR към CloudWatch Logs, а traces към OpenTelemetry колектор. За натоварени микро-услуги това е 60–80% спестяване. Ако въртите workloads на Kubernetes, подобни принципи важат и за EKS. Вижте Kubernetes оптимизация на разходите с Karpenter, KEDA и VPA за по-широка картина.

VPC Flow Logs, CloudTrail и Route 53: пращайте директно в S3

Тук е една от най-често пропуснатите оптимизации. AWS ги нарича vended logs. Това са логове, които други AWS услуги "продават" (генерират) към централен log endpoint. Тарифата им се различава от нормалните CloudWatch Logs:

Destination	Vended log ingestion	Standard log ingestion
CloudWatch Logs (Standard)	$0.25 / GB	$0.50 / GB
CloudWatch Logs (IA)	$0.15 / GB	$0.25 / GB
Kinesis Data Firehose → S3	$0.025 / GB	N/A
Директно S3 (Parquet)	$0.05 / GB	N/A

Разликата между $0.25/GB (CloudWatch) и $0.05/GB (S3) е 5x. За голям VPC с 500 GB/месец Flow Logs това е разликата между $125 и $25 месечно. На 30 акаунта става $3,000 годишно, само от една промяна в конфигурацията.

Ако използвате VPC Flow Logs за security investigation (post-hoc анализ през Athena), сложете ги директно в S3 с Parquet compression:

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-0a1b2c3d4e5f67890 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::my-org-flow-logs/AWSLogs/ \
  --log-format '${version} ${account-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}' \
  --destination-options FileFormat=parquet,PerHourPartition=true

За CloudTrail, management events вече са безплатни в CloudWatch (един trail на акаунт), но data events (S3 object-level, Lambda invoke) генерират огромни обеми. Насочете ги към отделен S3 trail в централен log archive account и заявявайте с Athena, когато трябва. За общия принцип "по-хитро съхранение вместо по-скъпо съхранение", вижте и Lifecycle Policies за S3, Azure Blob и GCP Cloud Storage.

Оптимизация на CloudWatch Logs Insights заявки

CloudWatch Logs Insights таксува $0.005 за GB сканирани данни. Звучи евтино, но една неоптимизирана заявка върху VPC Flow Logs (200 GB за 24 часа) струва $1. При SRE екип, който прави по 50 такива заявки на ден, това е $1,500/месец само за търсене. Често повече от самото storage.

Правила, които въвеждам при моите клиенти:

• Винаги стеснявайте времевия прозорец. Дефолтният "Last 1 hour" в Console става "Last 15 min" при investigation, разширявате го само при нужда.
• Използвайте fields преди filter. Селектирането на конкретни полета намалява паметта, но не сканирания обем. Сканираният обем се намалява от филтъра.
• Не използвайте parse над цялото съобщение, ако имате structured JSON. Insights извлича полетата автоматично от @message.
• Запазвайте често използвани заявки и ги пускайте на schedule (Insights supports scheduled queries от 2024 г.) с извеждане към CloudWatch metrics, вместо всеки път да сканирате наново.

Пример за неоптимизирана vs оптимизирана заявка:

# Лоша: сканира ~50 GB, струва $0.25
fields @timestamp, @message
| filter @message like /ERROR/

# Добра: сканира ~5 GB, струва $0.025 (10x по-евтино)
fields @timestamp, level, error.code, error.message
| filter level = "ERROR" and service = "orders-api"
| stats count() by error.code
| sort count desc
| limit 20

За мониторинг на самите разходи на Insights, включете CloudWatch:GetQueryResults и CloudWatch:StartQuery collection в CloudTrail и създайте Cost Anomaly Detection monitor. Детайлно как в ръководството за AWS Cost Explorer, Budgets и Anomaly Detection.

Multi-account log aggregation без свръхразходи

Централизираният log archive account е добра практика (AWS Landing Zone и Control Tower го препоръчват), но начинът на транспортиране има огромно значение за сметката.

Грешен подход: Cross-account CloudWatch Logs subscription filter към CloudWatch Logs destination в log archive account. Резултат: плащате ingestion в source акаунта (за local retention) и ingestion отново в destination акаунта. Двойни разходи.

Правилен подход, който използвам:

1. В source акаунт: log group с retentionInDays=7 (за local debug) в IA клас.
2. Subscription filter към Kinesis Data Firehose stream в същия акаунт.
3. Firehose доставя batched Parquet файлове директно в S3 bucket в log archive акаунта (cross-account bucket policy).
4. S3 lifecycle policy: 30 дни Standard, 90 дни Standard-IA, 365 дни Glacier Flexible Retrieval, 7 години Glacier Deep Archive.
5. Query през Athena, когато има разследване.

За хосването на самата дистрибуция на политики препоръчвам StackSet, който да разпространява retention SCP и default IA log group class на всички new-onboarded акаунти автоматично.

Сравнителна таблица на сценариите за архивиране

Ето кога кой destination има смисъл:

Сценарий	Препоръчано решение	Ориентировъчна цена / GB
Real-time debugging на production API	CloudWatch Logs Standard + Live Tail, retention 7 дни	$0.50
Application logs (WARN+ само)	CloudWatch Logs IA, retention 30 дни	$0.25
Audit / compliance трейлове	CloudTrail към S3 + Glacier lifecycle	$0.02–0.05
VPC Flow Logs за security forensics	Директно S3 Parquet + Athena	$0.05
Long-term retention (7+ години)	S3 Glacier Deep Archive	$0.00099
Multi-account централен архив	Firehose към cross-account S3	$0.025 + $0.023 (S3 Std)

За справка с официалните тарифи вижте CloudWatch pricing, анонса на Infrequent Access log class и официалната документация на CloudWatch Logs концепции.

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

Защо CloudWatch Logs са толкова скъпи?

Основната причина е ingestion таксата: $0.50/GB в us-east-1, което е около 17x по-скъпо от месечен storage от $0.03/GB. Verbose приложения (Lambda с console.log на всяка invocation, ECS containers с DEBUG level в production) генерират гигабайти на ден. Липсата на default retention policy усилва проблема, защото логовете се съхраняват безкрайно, ако не зададете retentionInDays.

Как да намаля разходите за CloudWatch Logs?

Четири стъпки, подредени по ROI: (1) задайте retention на всички log groups (най-често 7–30 дни за app logs); (2) преминете подходящите log groups на Infrequent Access class за 50% отстъпка на ingestion; (3) намалете обема с log level filters и sampling на ниво приложение; (4) насочете vended logs (VPC Flow, CloudTrail data events) директно към S3 вместо към CloudWatch Logs.

Какво е CloudWatch Logs Infrequent Access клас?

IA log class е тип log group, оптимизиран за рядко достъпвани данни (audit, дебъг след инцидент, compliance архив). Ingestion таксата е $0.25/GB (50% отстъпка спрямо Standard клас). За сметка на цената не се поддържат Live Tail, metric filters и някои embedded metric format функционалности. Storage тарифата остава същата: $0.03/GB/месец.

Мога ли да експортирам CloudWatch Logs в S3, за да спестя?

Да, но има нюанс. Ръчният S3 export не намалява ingestion таксата (тя вече е платена). За vended logs (VPC Flow, CloudTrail) най-евтиният вариант е директно S3 destination: $0.05/GB срещу $0.25/GB към CloudWatch. За application logs използвайте subscription filter към Kinesis Data Firehose с S3 destination, което дава непрекъснат low-cost поток и запазва последните 7 дни в CloudWatch за debug.

Как да задам retention на log groups от CLI?

Използвайте aws logs put-retention-policy --log-group-name /aws/lambda/my-fn --retention-in-days 30. Валидните стойности са 1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1096, 1827, 2192, 2557, 2922, 3288 или 3653 дни. За bulk промяна на всички съществуващи log groups напишете bash script с describe-log-groups и цикъл. Примерът в секцията "Retention policies" по-горе е готов за копиране.

Струва ли си да преместя всичко на IA log class?

Не. IA не поддържа Live Tail и metric filters. Това означава, че production APM log groups, dashboards, които разчитат на metric filters от логове, и real-time alerting стриймове ще спрат да работят. Правилният подход е сегментиране: hot log groups (последно 7 дни, активно наблюдавани) остават Standard; warm и archive groups (audit, compliance, стари debug) минават на IA.