אופטימיזציית עלויות S3: מדריך 2026

עודכן: 20 ביולי, 2026

אופטימיזציית עלויות S3 מבוססת על התאמת מחלקת האחסון (Storage Class) לתבנית הגישה בפועל של האובייקטים. העברה אוטומטית של נתונים "קרים" ל-S3 Intelligent-Tiering, Standard-IA או Glacier באמצעות Lifecycle Policies יכולה להוריד את חשבון ה-S3 שלך בין 40% ל-70% מבלי לפגוע בזמינות. במאמר הזה אני מפרק את שבע מחלקות ה-Storage הרלוונטיות לשנת 2026, נותן טבלת השוואת מחירים עדכנית לאזור us-east-1, ומראה את Terraform וה-CLI שאני מריץ ללקוחות שלי כדי להעביר פטבייטים בלי downtime.

S3 Intelligent-Tiering ב-2026 היא ברירת המחדל שלי לכל בקט מעל 128KB שגישתו לא צפויה. עמלה קבועה של $0.0025 ל-1,000 אובייקטים מפצה על עצמה כבר אחרי חודשיים.
Glacier Instant Retrieval (GIR) עלה בפופולריות אחרי שאמזון הורידה את מחיר האחזור ב-2025, והוא זול ב-68% מ-Standard לגישות של פעם בחודש.
Lifecycle Policies מבוסס-תגים (Object Tags) מאפשר מדיניות שונה לכל צוות באותו בקט, ומדויק בהרבה מ-Prefix.
ניקוי Multipart Uploads שלא הושלמו ו-Old Versions חוסך בממוצע 8-15% נוספים ללא שינוי במחלקת האחסון.
S3 Storage Lens עם Advanced Metrics ($0.20 למיליון אובייקטים לחודש) מזהה בקטים "עמומים" שאף אחד לא בעלים עליהם.
Data Transfer OUT ולא Storage הוא הסעיף הגדול בחשבונות S3 של יותר מ-30% מהלקוחות שלי. VPC Gateway Endpoint מבטל אותו בין S3 ל-EC2 באותו אזור.

מפה של כל מחלקות ה-Storage ב-S3 לשנת 2026

לפני שנוגעים ב-Lifecycle או ב-Intelligent-Tiering, חובה להבין מה אתם מנסים להזיז ולאן. אמזון מציעה כרגע שבע מחלקות אחסון כלליות (בלי לספור את S3 Express One Zone שהוא סיפור נפרד של low-latency). לכל אחת מהן פרופיל מחיר שונה לגמרי: אחסון, בקשות GET/PUT, אחזור, ומינימום זמן שמירה. את הטבלה הזאת אני משאיר פתוחה על מסך שני בכל שיחת FinOps עם לקוח.

מחלקה	מחיר אחסון (GB/חודש, us-east-1)	אחזור (GB)	מינימום שמירה	מתאים ל
S3 Standard	$0.023	ללא	ללא	גישה חמה, latency נמוך
S3 Intelligent-Tiering	$0.023 → $0.00099	ללא	ללא	תבנית גישה לא ידועה
S3 Standard-IA	$0.0125	$0.01	30 יום	גיבויים, DR, גישה חודשית
S3 One Zone-IA	$0.01	$0.01	30 יום	עותקים משניים, לוגים ניתנים לשחזור
S3 Glacier Instant Retrieval	$0.004	$0.03	90 יום	ארכיון עם גישה מיידית רבעונית
S3 Glacier Flexible Retrieval	$0.0036	$0.01	90 יום	ארכיון עם המתנה של דקות עד שעות
S3 Glacier Deep Archive	$0.00099	$0.02	180 יום	Compliance ארוך-טווח (7+ שנים)

שימו לב לעמודה של "מינימום שמירה", כי זה הרוצח השקט. אם תעבירו אובייקט ל-Standard-IA ואז תמחקו אותו אחרי שבוע, אמזון תגבה את מלוא 30 הימים בכל מקרה. ראיתי צוות DevOps שמחק לוגים אוטומטית אחרי שבעה ימים לפי מדיניות ישנה, לא שם לב שהם ב-Standard-IA, ושילם פי חמישה ממה שחשב במשך רבעון שלם. הכלל שאני נותן פשוט: אל תעבירו ל-Standard-IA שום דבר שאתם לא בטוחים שיישב שם לפחות 60 יום.

S3 Intelligent-Tiering: מתי הוא משתלם ומתי לא

S3 Intelligent-Tiering זו המחלקה שאני ממליץ עליה כברירת מחדל ב-95% מהמקרים החדשים ב-2026. אמזון מסווגת אוטומטית כל אובייקט לאחד מתוך חמישה קומות פנימיות: Frequent Access, Infrequent Access (אחרי 30 יום ללא גישה), Archive Instant Access (90 יום), ואופציונלית Archive Access (90+) ו-Deep Archive Access (180+). המחיר יורד מ-$0.023 ל-GB עד $0.00099, בלי שינוי בקוד ובלי אחזור בתשלום למחלקות ה-Instant. יש עמלת ניטור של $0.0025 ל-1,000 אובייקטים בחודש, מה שאומר שכדאי רק לאובייקטים מעל 128KB. לקבצים קטנים יותר אמזון לא גובה את דמי הניהול אבל גם לא מזיזה אותם (הם נשארים ב-Frequent Access).

המקרה היחיד שבו אני לא הולך על Intelligent-Tiering הוא כשיש תבנית גישה ברורה ויציבה. לוגים של CloudFront שנכתבים פעם ונקראים לעולם רק ב-Athena חודש אחרי? Standard-IA עם Lifecycle יעיל יותר. גיבויי RDS שנשמרים 7 שנים לצורך רגולציה? Glacier Deep Archive ישירות. בכל מקרה אחר, כשאתם לא יודעים אם המשתמש יגיע לקובץ עוד שבוע או לעולם, Intelligent-Tiering חוסך את הצורך לחשב את זה מראש. אני משלב את זה עם Cost Allocation Tags למולטי-אקאונט כדי לראות איזה צוות משתמש בכמה מכל שכבה.

# Terraform: יצירת בקט חדש שכל אובייקט חדש נכנס ישר ל-Intelligent-Tiering
resource "aws_s3_bucket" "data_lake" {
  bucket = "acme-data-lake-2026"
}

resource "aws_s3_bucket_intelligent_tiering_configuration" "archive" {
  bucket = aws_s3_bucket.data_lake.id
  name   = "EntireBucket"

  # מפעילים גם את קומות ה-Archive האופציונליות (חובה להפעיל ידנית)
  tiering {
    access_tier = "ARCHIVE_ACCESS"
    days        = 90
  }

  tiering {
    access_tier = "DEEP_ARCHIVE_ACCESS"
    days        = 180
  }
}

# מעבירים כל אובייקט חדש ישירות ל-Intelligent-Tiering ב-PUT
resource "aws_s3_bucket_lifecycle_configuration" "auto_tier" {
  bucket = aws_s3_bucket.data_lake.id

  rule {
    id     = "move-to-intelligent-tiering"
    status = "Enabled"

    filter {
      object_size_greater_than = 131072  # 128KB, מתחת לזה אין טעם
    }

    transition {
      days          = 0
      storage_class = "INTELLIGENT_TIERING"
    }
  }
}

איך משתמשים ב-Lifecycle Policies ב-S3 כדי לחסוך בעלויות

Lifecycle Policies הם המנוע שמזיז את האובייקטים בין מחלקות ומוחק אותם בסוף הדרך. כל מדיניות מורכבת מסינון (Filter לפי Prefix, Tag, או גודל אובייקט) ומאחת או יותר מפעולות: Transition (מעבר בין מחלקות), Expiration (מחיקה), NoncurrentVersionTransition ו-NoncurrentVersionExpiration (לגרסאות ישנות ב-versioned buckets), ו-AbortIncompleteMultipartUpload (ניקוי). ב-2026 אני משתמש הרבה יותר בסינון לפי Tag מאשר Prefix, כי זה מאפשר לצוות אחד לומר "הלוגים שלי נשארים 90 יום" ולצוות שני לומר "המודלים שלי נשארים 3 שנים" באותו בקט.

הנה מדיניות טיפוסית שאני מיישם על בקט לוגים ב-CloudTrail. Standard בהתחלה כדי לאפשר חקירות מהירות של תקריות, IA אחרי חודש, Glacier Instant אחרי שלושה חודשים, ו-Deep Archive אחרי שנה עד תום 7 שנים של Compliance:

aws s3api put-bucket-lifecycle-configuration \
  --bucket acme-cloudtrail-logs \
  --lifecycle-configuration '{
    "Rules": [
      {
        "ID": "cloudtrail-tiering",
        "Status": "Enabled",
        "Filter": { "Prefix": "AWSLogs/" },
        "Transitions": [
          { "Days": 30,  "StorageClass": "STANDARD_IA" },
          { "Days": 90,  "StorageClass": "GLACIER_IR" },
          { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
        ],
        "Expiration": { "Days": 2555 }
      },
      {
        "ID": "abort-stale-multipart",
        "Status": "Enabled",
        "Filter": {},
        "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
      }
    ]
  }'

שימו לב לכלל השני, AbortIncompleteMultipartUpload. הרבה SDK-ים ופיילינים של Spark מפסיקים באמצע העלאה גדולה ומשאירים חלקים שנמדדים ומחויבים כאילו הם אובייקט שלם. נתקלתי בבקט שהצטבר בו ב-4 חודשים 12TB של multipart-uploads מיתומים שאף אחד לא ראה ב-console (כי הם לא מופיעים ב-`aws s3 ls`). הכלל הזה, בפני עצמו, החזיר ללקוח $2,760 בחודש.

שימוש ב-S3 Storage Lens לזיהוי בזבוזים

S3 Storage Lens הוא דשבורד חינמי בגרסת Free Metrics שמראה לכם את התמונה של כל האחסון בכל האקאונטים ב-Organization. הגרסה המשולמת (Advanced Metrics ו-Recommendations) עולה $0.20 למיליון אובייקטים לחודש ומוסיפה 35 מטריקות, ובעיקר Advanced Data Protection (מזהה בקטים ללא הצפנה, ללא versioning), Cost Optimization (מזהה בקטים ללא Intelligent-Tiering, גרסאות ישנות מיתומות), ו-Prefix-level analytics.

המטריקות שאני מסתכל עליהן ראשונות בכל ביקורת: NonCurrentVersionStorageBytes (כמה אחסון מבוזבז על גרסאות ישנות), IncompleteMultipartUploadStorageBytes (יתומים), UnhealthyBucketCount (בקטים בלי encryption או lifecycle), ו-ObjectAccessPatterns. לדעת איזה prefix מקבל 0 בקשות GET במשך 90 יום זה זהב לתכנון Lifecycle. בכל פרויקט אני ממליץ ללקוחות להעביר את Storage Lens ל-CloudWatch כדי שיוכלו לבנות alerts כשגודל הגרסאות הישנות עובר סף מסוים. ב-התיעוד הרשמי של S3 Storage Lens יש רשימה מלאה של המטריקות.

ניקוי Multipart Uploads וגרסאות ישנות

שתי קטגוריות של "אחסון סמוי" יכולות להוסיף עד 20% לחשבון בלי שאף אחד ישים לב. הראשונה זו Incomplete Multipart Uploads שכבר דיברנו עליהן. השנייה זו Noncurrent Versions בבקטים עם Versioning פעיל. כל PUT יוצר אובייקט חדש, וכל DELETE שם רק Delete Marker, כלומר הגרסה הישנה נשמרת לנצח אלא אם יש לכם מדיניות. ראיתי בקט של תמונות פרופיל שגדל ל-40TB כשהיה צריך להיות 4TB. 90% מהגודל היו גרסאות של 12 חודשים אחורה של אותן תמונות שהמשתמשים החליפו.

פקודות שאני מריץ ראשונות על כל בקט שאני יורש:

# 1. כמה יש לי multipart uploads פתוחים ב-30+ ימים?
aws s3api list-multipart-uploads --bucket acme-data \
  --query 'Uploads[?Initiated<=`2026-06-20`].[Key,UploadId,Initiated]' \
  --output table

# 2. כמה זה שוקל בפועל? Storage Lens יגיד ב-console,
#    אבל בשורת הפקודה אני שולף מ-CloudWatch:
aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 \
  --metric-name BucketSizeBytes \
  --dimensions Name=BucketName,Value=acme-data \
                Name=StorageType,Value=StandardIAStorage \
  --start-time 2026-07-13T00:00:00Z \
  --end-time   2026-07-20T00:00:00Z \
  --period 86400 --statistics Average

# 3. מדיניות שמעבירה גרסאות ישנות ל-Glacier IR אחרי 30 יום ומוחקת אחרי שנה
aws s3api put-bucket-lifecycle-configuration \
  --bucket acme-data \
  --lifecycle-configuration file://noncurrent-cleanup.json

איך מפחיתים עלויות Data Transfer של S3

אצל יותר משליש מהלקוחות שאני עובד איתם, סעיף ה-DataTransfer-Out-Bytes גדול יותר מסעיף האחסון עצמו. S3 מוציא בחינם רק את ה-100GB הראשונים לחודש. אחר כך זה $0.09 ל-GB בסטנדרט ל-us-east-1, ויורד מדורג עד $0.05 מעל 150TB. הכי גרוע? Cross-Region Replication ל-S3 באזור אחר, שגם עולה על ה-Transfer וגם על ה-Storage הכפול. הכיתי בבאג הזה בפרויקט קודם, כשגילינו שאחוז נכבד מהחשבון החודשי שלנו הלך על replication בין us-east-1 ל-eu-west-1 בלי שבאמת עשינו שימוש ב-DR site.

שלוש הפעולות שיש להן הכי הרבה השפעה:

VPC Gateway Endpoint ל-S3: חינמי לחלוטין. כל תעבורה בין EC2 באותו אזור לבין S3 עוברת דרך הבאקבון של אמזון במקום דרך NAT Gateway (שגובה $0.045 ל-GB בנוסף לתשלום הראשוני). ליישום עם 10TB יציאה חודשית ל-S3 מ-EC2, זה חיסכון של $450 בחודש.
CloudFront מול S3 ציבורי: יציאה מ-CloudFront למשתמשי קצה עולה $0.085 ל-GB (זול ב-5% מ-S3), אבל היתרון האמיתי הוא ה-cache. Origin Fetch Rate של 10% אומרת 90% חיסכון על התעבורה שיצאה מ-S3.
Compression לפני העלאה: לוגים JSON נדחסים ביחס 8:1 עם zstd. אני מאלץ באמצעות S3 Object Lambda שכל אובייקט חדש נדחס בכניסה. ראו גם את המדריך שלנו ל-AWS Graviton, כי עיבוד compression על Graviton יעיל ב-25% יותר לוואט.

לצוותים שכבר משתמשים ב-Reserved Instances או ב-Savings Plans, שווה לוודא שגם ה-CloudFront בכיסוי. יש CloudFront Security Savings Bundle ב-2026 שנותן 30% הנחה על התעבורה תמורת התחייבות שנתית. פרטים ב-דף התמחור הרשמי של S3. אם עדיין לא בחרתם בין SP ל-RI, קראו את ההשוואה המלאה שלנו.

דוגמת Terraform מלאה לאופטימיזציה של בקט S3

הנה מודול Terraform שאני משתמש בו ב-baseline של כל פרויקט חדש. הוא כולל Intelligent-Tiering, ניקוי multipart, ניקוי גרסאות ישנות, VPC Endpoint, ו-Storage Lens בגרסת Advanced על ה-Organization:

module "cost_optimized_bucket" {
  source = "./modules/s3-finops"

  bucket_name           = "acme-app-prod"
  enable_versioning     = true
  enable_intelligent_tiering = true
  enable_lifecycle      = true

  lifecycle_rules = {
    logs = {
      prefix         = "logs/"
      ia_days        = 30
      glacier_ir_days = 90
      deep_archive_days = 365
      expiration_days = 2555
    }
    exports = {
      prefix         = "exports/"
      ia_days        = 14
      expiration_days = 90
    }
  }

  noncurrent_version_expiration_days = 30
  abort_incomplete_multipart_days    = 7

  vpc_endpoint_route_tables = [
    aws_route_table.private_a.id,
    aws_route_table.private_b.id,
  ]

  tags = {
    CostCenter  = "engineering-platform"
    ManagedBy   = "terraform"
    FinOpsOwner = "platform-team"
  }
}

המודול הזה מייצר אחרי apply בקט עם כל שבעת המנגנונים שדיברנו עליהם. אני מריץ אותו על סביבת staging חדשה, מחכה שבוע, ומסתכל ב-Storage Lens לראות שההעברות בין המחלקות באמת מתרחשות. ההחזר על ההשקעה הטיפוסי שאני רואה: 45%-65% הפחתה בעלויות S3 בתוך 60 יום. תיעוד רשמי של האפשרויות ב-תיעוד ה-S3 Lifecycle Examples של AWS.

שאלות נפוצות

כמה עולה S3 Glacier Instant Retrieval בהשוואה ל-S3 Standard?

S3 Glacier Instant Retrieval עולה $0.004 ל-GB לחודש ב-us-east-1, לעומת $0.023 ל-GB לחודש ב-S3 Standard, כלומר 82% זול יותר על אחסון. עם זאת, כל אחזור עולה $0.03 ל-GB בנוסף. הכלכלה משתלמת כאשר תדירות הגישה נמוכה מפעם בחודש בממוצע, ובתנאי שהאובייקט יישאר לפחות 90 יום (מינימום שמירה).

מה ההבדל בין S3 Intelligent-Tiering ל-Lifecycle Policy?

Intelligent-Tiering מזיז אובייקטים אוטומטית בין קומות אחסון בהתבסס על תבנית הגישה בפועל, בלי שתגדירו טריגרים מראש. Lifecycle Policy דורש מכם לבחור מראש חוקים ("אחרי 30 יום העבר ל-IA") שרצים על סמך גיל האובייקט ולא הגישה אליו. השילוב הנכון: Lifecycle כדי להעביר אובייקטים חדשים ל-Intelligent-Tiering ביום 0, ו-Lifecycle נוסף כדי למחוק לגמרי אחרי תקופת retention.

האם S3 Intelligent-Tiering כדאי לקבצים קטנים?

לא. אמזון גובה עמלת ניטור של $0.0025 ל-1,000 אובייקטים בחודש, ואובייקטים מתחת ל-128KB נשארים ב-Frequent Access ולא יורדים מחיר כלל. עבור בקטים עם מיליוני אובייקטים קטנים (thumbnail-ים, metadata), כדאי לאחד אותם ל-tarballs או להשאיר אותם ב-Standard.

איך אני יודע כמה מהחשבון S3 שלי הוא Data Transfer ולא Storage?

ב-Cost Explorer, סננו לפי Service = "Amazon Simple Storage Service" וקבצו לפי Usage Type. חפשו שורות שמתחילות ב-DataTransfer-Out-Bytes או Requests-Tier2. אני ממליץ להעביר CUR ל-Athena ולהריץ שאילתות מפורטות ברמת ה-bucket, כי Cost Explorer מסכם ברמה גבוהה מדי לזיהוי הנוזלה.

האם Cross-Region Replication מכפיל את חשבון S3 שלי?

כן, וגם קצת יותר. אתם משלמים על האחסון באזור היעד (מחיר מלא) בנוסף לאזור המקור, על תעבורת ה-replication ($0.02 ל-GB בין אזורי US), ועל בקשות PUT באזור היעד. עבור DR שלא דורש RTO של דקות, בדקו אם S3 Cross-Region Replication למחלקת Glacier Deep Archive לא נותן לכם 90% חיסכון עם RPO ו-RTO שעדיין עומדים ב-SLA.