מדריך FinOps מעשי לאופטימיזציית עלויות AWS CloudWatch: מעבר ל-Logs Infrequent Access, retention נכון, Metric Streams במקום GetMetricData ו-VPC Flow Logs ל-S3 - חיסכון של 50-80%.
עודכן: 18 בספטמבר 2026
אופטימיזציית עלויות AWS CloudWatch ב-2026 מבוססת על ארבעה מנופים עיקריים: העברת לוגים ישנים ל-log class חדש בשם Infrequent Access (חיסכון של 50%), קיצור מדיניות שמירה (retention) לפי חשיבות ה-log group, החלפת GetMetricData ב-Metric Streams עם Firehose ל-S3, וסינון של VPC Flow Logs לפני שהם מגיעים ל-CloudWatch Logs. שילוב נכון של הארבעה מוריד את החשבון ב-50-80% תוך שמירה על יכולות ה-observability הקריטיות למערכת ייצור.
GetMetricData - חיסכון של פי 3.3 בעומסי dashboard כבדים.aws logs put-retention-policy אוטומטיים דרך AWS Config מונעים חזרה של החוב לאורך זמן.בואו נודה בזה: כמעט בכל ארגון שאני נכנס אליו בתפקידי כ-AWS Solutions Engineer, שורת CloudWatch בחשבון כבר הוציאה את ה-Finance מדעתם עוד לפני שהתחלנו לדבר. הסיבה כמעט תמיד זהה: אף אחד לא הסתכל על ה-Cost and Usage Report (CUR) ברמת ה-usage_type, ולכן לא ידעו ש-DataProcessing-Bytes (ingestion) הוא זה שגובה 0.50$ לכל GB, וש-TimedStorage-ByteHrs (אחסון של לוגים ישנים) גובה 0.03$ לכל GB בחודש. חשבון של 25,000$ בחודש שראיתי לאחרונה התפרק כך: 62% ingestion של VPC Flow Logs, 18% אחסון של לוגים בני 4 שנים ב-Never Expire, ו-11% קריאות GetMetricData מ-Grafana on-prem שרץ dashboard כל 10 שניות. רק 9% היו לוגים אפליקטיביים אמיתיים.
לפני שנוגעים באופטימיזציה, יש לרוץ את שאילתת ה-CUR הבאה ב-Athena כדי להבין מה קורה בפועל:
SELECT
line_item_usage_type,
product_region,
SUM(line_item_unblended_cost) AS cost_usd,
SUM(line_item_usage_amount) AS usage_amount
FROM cur.your_cur_table
WHERE product_product_name = 'AmazonCloudWatch'
AND bill_billing_period_start_date = DATE '2026-08-01'
GROUP BY 1, 2
ORDER BY cost_usd DESC
LIMIT 50;הפלט הזה יגיד לכם תוך שנייה אם הבעיה שלכם היא Logs, Metrics, Contributor Insights, או Custom Events. בלי הפירוט הזה אתם יורים באפילה. Compute Optimizer של AWS לא כולל המלצות ל-CloudWatch עצמו, ולכן ה-Athena על ה-CUR הוא כלי החובה כאן.
מודל התמחור של CloudWatch Logs מורכב משלושה רכיבים שרוב הצוותים מכירים רק את הראשון: ingestion (0.50$/GB ב-Standard class, us-east-1), storage (0.03$/GB לחודש), ו-data scan ב-Logs Insights (0.005$/GB נסרק). בעוד ה-ingestion הוא ה"רעש" הרועש, האחסון הוא ה"רעש השקט" - GB של לוג שיושב 24 חודשים עלה בסך הכל 0.72$ באחסון (0.03 × 24), כפול 20,000 log groups של מיקרו-שירותים = 14,400$ בחודש רק על לוגים שאף אחד לא מסתכל עליהם.
ב-2026 נוסף פרמטר חמישי בעקבות שינוי מדיניות במאי: אם ה-log group שלכם בקטגוריית Infrequent Access, ה-ingestion יורד ל-0.25$/GB אבל ה-scan ב-Logs Insights עולה ל-0.0075$/GB. זה משתלם מהמדגם הראשון של כל log group ש-query שלו מתבצע פחות מ-6 פעמים בחודש - למשל, audit logs, debug logs של batch jobs, או logs של environments לא-פרודקשן. הרוב המכריע של ה-log groups נופלים לקטגוריה הזו.
# השוואת עלות חודשית ל-100 GB log group
# Standard class:
# Ingest: 100 GB × $0.50 = $50.00
# Storage: 100 GB × $0.03 = $3.00 (חודש ראשון)
# Total: $53.00
# Infrequent Access class:
# Ingest: 100 GB × $0.25 = $25.00
# Storage: 100 GB × $0.03 = $3.00
# Total: $28.00 ← חיסכון של 47%יצירת log group ב-Infrequent Access class היא לא אופציה שאפשר להחליף אחר כך - צריך ליצור group חדש ב-class הזה, ולהעביר אליו את ה-log stream. הנה איך עושים את זה נכון עם AWS CLI:
aws logs create-log-group \
--log-group-name "/aws/lambda/order-service-ia" \
--log-group-class INFREQUENT_ACCESS \
--retention-in-days 90 \
--region us-east-1
# עדכון של הפונקציה ל-log group החדש
aws lambda update-function-configuration \
--function-name order-service \
--logging-config LogGroup=/aws/lambda/order-service-ia,LogFormat=JSON,ApplicationLogLevel=INFO,SystemLogLevel=WARNשים לב לפרמטר ApplicationLogLevel - הוא זמין החל מסוף 2023 ל-Lambda ומאפשר לסנן DEBUG/TRACE עוד לפני ה-ingestion. אנחנו לא סופרים על 0.50$/GB את מה שקבצי log של Winston/pino יוצרים ברמת debug ב-production. זה מוריד את ה-volume בכ-40% מיד.
ה-caveat העיקרי של Infrequent Access: אין תמיכה ב-metric filters, ואין export ל-S3 דרך CreateExportTask (אך subscription filters ל-Firehose כן עובדים). אם צריכת ה-metric filter היא חלק מהאופרציה שלכם, השאירו את ה-log groups הקריטיים ב-Standard, והעבירו רק את השאר. ברוב הפרויקטים שלי יחס של 20/80 (Standard/IA) הוא המציאותי.
ברירת המחדל של CloudWatch Logs היא Never Expire - זו הגדרה שיצרה יותר בזבוז כספי מכל תכונה אחרת בהיסטוריה של AWS. Retention נכון הוא הרלוונטיות של הלוג כפול ה-compliance requirement:
לוגים לטווח ארוך צריכים לצאת מ-CloudWatch. subscription filter ל-Kinesis Data Firehose שכותב ל-S3 Glacier Deep Archive עולה 0.00099$/GB-חודש - פי 30 זול יותר מ-CloudWatch storage. הנה סקריפט Python לתיקון גורף של retention בכל ה-log groups בחשבון:
import boto3
# Map של pattern -> retention days
POLICY = {
"/aws/lambda/": 30,
"/aws/apigateway/": 30,
"/aws/rds/": 90,
"/aws/vpc/flowlogs/": 90,
"/aws/cloudtrail/": 365,
}
logs = boto3.client("logs", region_name="us-east-1")
paginator = logs.get_paginator("describe_log_groups")
for page in paginator.paginate():
for lg in page["logGroups"]:
name = lg["logGroupName"]
current = lg.get("retentionInDays") # None = Never Expire
target = next((v for k, v in POLICY.items() if name.startswith(k)), 30)
if current != target:
logs.put_retention_policy(
logGroupName=name,
retentionInDays=target,
)
print(f"Set {name}: {current} -> {target} days")Grafana, Datadog ו-New Relic כולם משתמשים ב-GetMetricData API כדי לשלוף מטריקות מ-CloudWatch. המחיר: 0.01$ לכל 1,000 קריאות. dashboard יחיד ב-Grafana עם 30 פאנלים שרץ auto-refresh כל דקה יוצר בערך 43,200 קריאות ליום = 43.2 קריאות שהן קוסטיות אחרי הפירוט הפנימי (בגלל MetricStat arrays). לתוך הטבלה של customer שבדקתי בחודש שעבר, זה יצא 8,400$ בחודש רק על קריאות ה-API.
CloudWatch Metric Streams משנה את המודל: במקום שהצרכן ישאל, AWS דוחפת את המטריקות ב-real-time ל-Kinesis Data Firehose, ומשם ל-S3 או ישירות ל-vendor. המחיר: 0.003$ לכל 1,000 עדכוני מטריקה. הנה השוואה מספרית:
| מדד | GetMetricData (Pull) | Metric Streams (Push) |
|---|---|---|
| מחיר ל-1,000 יחידות | 0.01$ | 0.003$ |
| Latency | 1-5 דקות | < 60 שניות |
| Rate limit | 50 TPS לחשבון | ללא מגבלה |
| תמיכה ב-namespaces מותאמים אישית | כן | כן |
| פורמט output | JSON | OpenTelemetry / JSON |
| מתאים ל- | ad-hoc queries | dashboards continuous |
Metric Streams אידיאלי לכל תרחיש observability מתמשך - dashboards, alerting חיצוני, cold storage למטרות tuning. GetMetricData אמור להיות מוגבל ל-Cost Explorer, לרפורטים ad-hoc, ולסקריפטים חד-פעמיים. המעבר לרוב מוריד את שורת ה-API-Requests ב-CloudWatch ב-85% ומעלה.
Custom metric ב-CloudWatch עולה 0.30$ לחודש, לכל מטריקה ייחודית (dimensions × metric name). נשמע קטן, נכון? עד שאתה מגלה שאפליקציית microservices עם 200 pods, כל אחד מדווח על request_duration עם dimensions של pod_name, service, endpoint ו-status_code - יוצרת בפועל 200 × 15 × 4 = 12,000 מטריקות ייחודיות = 3,600$ בחודש רק על מטריקות. אני רואה את זה שוב ושוב בצוותים שעברו מ-Prometheus ל-CloudWatch Embedded Metric Format (EMF) בלי לחשוב על ה-cardinality.
הפתרון: השתמשו ב-Embedded Metric Format אבל עם רשימה מוגבלת של dimensions. במקום להעביר pod_name כ-dimension, שים אותו רק כשדה metadata בלוג עצמו. הנה הבדל מעשי:
// לפני: יוצר מטריקה חדשה לכל pod
console.log(JSON.stringify({
_aws: {
Timestamp: Date.now(),
CloudWatchMetrics: [{
Namespace: "MyApp/Orders",
Dimensions: [["service", "endpoint", "pod_name"]], // גבוה cardinality!
Metrics: [{ Name: "Duration", Unit: "Milliseconds" }]
}]
},
service: "order-service",
endpoint: "/api/checkout",
pod_name: "order-service-7d4b-x9k2j", // גורם ל-explosion
Duration: 145
}));
// אחרי: dimensions נמוכים, metadata כשדה רגיל
console.log(JSON.stringify({
_aws: {
Timestamp: Date.now(),
CloudWatchMetrics: [{
Namespace: "MyApp/Orders",
Dimensions: [["service", "endpoint"]], // 15 endpoints × 1 service = 15 מטריקות
Metrics: [{ Name: "Duration", Unit: "Milliseconds" }]
}]
},
service: "order-service",
endpoint: "/api/checkout",
pod_name: "order-service-7d4b-x9k2j", // רק metadata
Duration: 145
}));לגבי alarms: 0.10$ לחודש ל-standard alarm, 0.30$ ל-composite alarm, ו-0.50$ ל-anomaly detection. אלארם שהוגדר ב-2021 על שירות שכבר לא קיים? יש עשרות כאלה בכל חשבון. הסקריפט aws cloudwatch describe-alarms --query 'MetricAlarms[?StateValue==`INSUFFICIENT_DATA` && StateUpdatedTimestamp<`2026-01-01`]' יגלה לכם את זה תוך שנייה.
VPC Flow Logs שנשלחים ל-CloudWatch Logs הם הסיבה מספר 1 לחשבונות של 6 ספרות בחודש. ל-VPC פעיל בגודל בינוני עם 50 EC2 instances יש בקלות 500 GB-1 TB של flow logs ליום - כלומר 250-500$ ליום, או 7,500-15,000$ בחודש רק על ingestion. הפתרון המקצועי לא כולל את CloudWatch בכלל: יש להעביר את ה-Flow Logs ישירות ל-S3 עם partitioning ולעשות queries עם Athena.
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-0a1b2c3d \
--traffic-type ALL \
--log-destination-type s3 \
--log-destination arn:aws:s3:::my-flowlogs-bucket/vpc-flow-logs/ \
--destination-options FileFormat=parquet,HiveCompatiblePartitions=true,PerHourPartition=true \
--log-format '${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${action}'הפורמט parquet חוסך פי 3-5 באחסון לעומת text, וה-HiveCompatiblePartitions מאפשר ל-Athena לסרוק רק את הפרטישן הרלוונטי. עלות הכוללת ל-1 TB Flow Logs חודשי ב-S3 Parquet + Athena queries רגילים: כ-25$ לעומת 500$+ ב-CloudWatch. חיסכון של 95%.
אם אתם עדיין רוצים אלארמים על תעבורה חשודה, השתמשו ב-אופטימיזציית עלויות NAT Gateway יחד עם GuardDuty, שכבר עושה את הניתוח הזה על Flow Logs מבפנים של AWS בלי צורך ל-ingest ל-CloudWatch. GuardDuty עולה 1.00$ ל-GB עד ל-500 GB, ופחות מעליו - הרבה יותר יעיל מ-CloudWatch ingest + מנוע ה-alarms שלכם.
אז, שאלה שאני מקבל כמעט בכל שיחת ייעוץ: האם CloudWatch באמת זול יותר, או שכדאי לעבור ל-Datadog או Grafana Cloud? התשובה תלויה בכמות ה-hosts, כמות המטריקות הייחודיות, וכמות ה-log volume. הנה מטריצת ההחלטה ל-2026 בהתבסס על 4 פרויקטים שהובלתי השנה:
| קריטריון | CloudWatch (Optimized) | Datadog | Grafana Cloud |
|---|---|---|---|
| ingest של 100 GB logs | 25-50$ | 270$ | 50$ (Loki) |
| מטריקה מותאמת אישית | 0.30$/חודש | 18$/100 מטריקות | 8$/1,000 series |
| alerting מתקדם | סביר, דרך EventBridge | מצוין, out-of-box | מצוין, Grafana OSS-compatible |
| Distributed tracing | X-Ray נפרד | APM כלול | Tempo כלול |
| Lock-in ל-AWS | גבוה | נמוך (multi-cloud) | נמוך (OSS-compatible) |
| מתאים ל- | AWS-only, עד 500 GB/day | enterprise, multi-cloud | startups, k8s-native |
עבור workloads שכולם ב-AWS ועם צוות מוגבל, CloudWatch המוגדר נכון תמיד מנצח. עבור סביבות multi-cloud או מקומות שדורשים APM עמוק, Datadog הוא ה-standard. Grafana Cloud עם Loki + Tempo היא אמצע הדרך הטוב: התאמה טובה ל-Kubernetes ומחירים הגונים על log volumes של 200 GB+ ליום.
כדי למנוע חזרה של החוב, אכיפה של הכללים חייבת לרוץ ברמת ה-IaC. ה-Terraform module הבא אוכף Infrequent Access + retention של 30 יום כברירת מחדל לכל log group חדש שנוצר ב-account:
resource "aws_cloudwatch_log_group" "default" {
name = var.log_group_name
log_group_class = var.log_class # ברירת מחדל: "INFREQUENT_ACCESS"
retention_in_days = var.retention_days # ברירת מחדל: 30
kms_key_id = var.kms_key_arn # הצפנה חובה ב-2026
tags = merge(var.common_tags, {
"cost-center" = var.cost_center
"retention-tier" = var.retention_days <= 30 ? "short" : "long"
})
}
# אכיפה: כל log group ללא retention נחסם ב-Sentinel/OPA
# rule: log_group_must_have_retention
# violation if: resource.log_group.retention_in_days == nullברמת ה-account, AWS Config Rule cw-loggroup-retention-period-check מוצא log groups עם retention של Never Expire ומדווח עליהם ל-Security Hub. שילוב עם EventBridge → Lambda שמפעיל put-retention-policy אוטומטית סוגר את הלולאה. עבור צוותים שרצים Shift-Left FinOps עם Terraform ו-Infracost, אפשר לחשב את עלות ה-CloudWatch לפני ה-deploy עם resource dependency בין aws_cloudwatch_log_group ל-aws_lambda_function.
לוגיקה משלימה שמומלץ לשלב: tags לחלוקת עלויות במולטי-אקאונט כמו owner-team, service-tier ו-environment מאפשרים show-back מדויק בין הצוותים. בלי ה-tags, אין דרך להראות ל-team lead מדוע ה-log group שלו עולה 900$ בחודש.
Ingestion של CloudWatch Logs עולה 0.50$/GB ב-Standard class ו-0.25$/GB ב-Infrequent Access. אחסון עולה 0.03$/GB לחודש. Metric ingestion דרך PutMetricData עולה 0.01$/1,000 שיחות, וקריאת מטריקה דרך GetMetricData עולה 0.01$/1,000. השוויון הזה משתנה קלות בין regions - us-east-1 היא הזולה ביותר.
כן, למרבית ה-log groups. IA מציע 50% חיסכון על ingestion בתמורה ל-scan יקר ב-50% ב-Logs Insights. אם ה-log group שלכם נסרק פחות מ-6 פעמים בחודש (מה שנכון לרוב ה-audit logs, debug logs ו-non-prod), IA משתלם. שמרו ב-Standard רק log groups שיש בהם metric filters פעילים או dashboards שרצים כל הזמן.
הריצו את השאילתה הזו ב-CloudWatch Logs Insights: stats sum(bytes) as ingested_bytes by @logStream | sort ingested_bytes desc | limit 20. לחלופין, ב-Athena על ה-CUR חפשו את שורות usage_type שמתחילות ב-DataProcessing-Bytes. שילוב של השניים נותן תמונה מלאה - CloudWatch Insights ל-per-stream, ו-CUR ל-per-log-group cost.
ברוב המקרים, כן - בפער של 95% במחיר. VPC Flow Logs ל-CloudWatch עולה 0.50$/GB ingest, בעוד ל-S3 ב-Parquet + Athena queries סטנדרטיים עולה כ-0.025$/GB חודשי כולל האחסון והסריקה. השאירו את CloudWatch רק אם אתם צריכים alarms בזמן אמת על תעבורה חריגה - וגם אז, GuardDuty הוא לרוב אופציה יותר טובה.
Datadog יקר יותר בכל תרחיש AWS-only שבו CloudWatch מוגדר כמו שצריך: 15-31$/host לעומת עלות אפקטיבית של 4-8$/host ב-CloudWatch עם IA + retention נכון. אבל Datadog משתלם ברגע שאתם multi-cloud, זקוקים ל-APM עמוק, או ל-anomaly detection out-of-box שלא רוצים לבנות עם CloudWatch Anomaly Detection + Lambda.
מדריך FinOps מעשי לחיסכון 40-70% בחשבון AWS Lambda ב-2026: כיוונון זיכרון עם Power Tuning, מעבר ל-Graviton arm64, שליטה ב-CloudWatch Logs, ו-SnapStart מול Provisioned Concurrency.
המדריך המעשי לקיצוץ 60-90% מעלויות NAT Gateway ב-AWS: איתור מקורות התעבורה עם Flow Logs, מעבר ל-VPC Endpoints, ניתוב per-AZ וחלופות כמו fck-nat.
מדריך אסטרטגי ל-AWS Spot Instances ב-2026: איך לבחור price-capacity-optimized, לגוון instance types, לטפל בהפרעות עם Karpenter ולשלב עם Savings Plans לחיסכון של 55%–70% על חשבון ה-EC2. כולל דוגמאות קוד ל-ASG ול-NodePool.