AWS S3: оптимізація витрат (2026)

Q: Який клас S3 найдешевший у 2026 році?

Найдешевший клас за ціною зберігання це S3 Glacier Deep Archive ($0,00099 за ГБ у us-east-1). Проте він має мінімальний термін зберігання 180 днів і час відновлення до 12 годин, тому підходить лише для довготривалих архівів. Для повсякденних задач із рідкісним доступом кращий вибір: Glacier Instant Retrieval або Standard-IA.

Q: Чи варто вмикати S3 Intelligent-Tiering для всіх бакетів?

Так, для бакетів із середнім розміром об'єкта більше 128 КБ і непередбачуваним патерном доступу це найбезпечніший вибір у 2026 році. Не вмикайте його для бакетів із мільйонами дрібних файлів (наприклад, thumbnails), бо об'єкти менше 128 КБ штрафуються мінімальним розміром і додатковою платою за моніторинг.

Q: Як зменшити витрати S3 без переходу на інші класи зберігання?

Три швидкі перемоги: увімкніть автоматичне переривання незавершених multipart-завантажень через 7 днів, налаштуйте видалення неактуальних версій старше 90 днів у бакетах із версіонуванням, і додайте CloudFront перед публічними бакетами. Ці три зміни зазвичай зрізають 20–35% рахунку без будь-яких ризиків для продакшну.

Q: Чим S3 Storage Lens відрізняється від AWS Cost Explorer?

Cost Explorer показує загальні витрати за сервісами й тегами, але не деталізує, чому саме S3 коштує стільки. Storage Lens натомість дає операційні метрики на рівні бакетів і префіксів: кількість запитів, розподіл між класами зберігання, обсяг незавершених multipart-завантажень. Разом ці інструменти покривають фінансовий та операційний зрізи одночасно.

Q: Скільки коштує перехід між класами S3?

Перехід оплачується як API-запит: $0,01 за 1 000 переходів у Standard-IA або Glacier IR і $0,05 за 1 000 переходів у Glacier Flexible/Deep Archive. Для мільйонів дрібних об'єктів це може перевищити економію на зберіганні, тому спершу порахуйте break-even за формулою: (cost_per_transition × N) / (price_diff_per_GB × avg_object_size_GB × months).

Оновлено: 13 вересня 2026

Оптимізація витрат AWS S3 — це системний підхід до вибору правильного класу зберігання, автоматизації переходів між ними за допомогою Lifecycle-політик, увімкнення S3 Intelligent-Tiering для непередбачуваних шаблонів доступу та регулярного аудиту невикористаних об'єктів через S3 Storage Lens. У більшості акаунтів такий комплекс заходів зменшує рахунок за S3 на 40–70% протягом одного біллінгового циклу. Найбільший ефект дає перехід «холодних» даних до Glacier Instant Retrieval або Deep Archive, а також очищення багатоскладових завантажень, які «зависли» без завершення.

S3 Intelligent-Tiering автоматично переміщує об'єкти між чотирма рівнями доступу і у 2026 році є типовим вибором для більшості робочих навантажень із непередбачуваним патерном звернень.
Правильно налаштована Lifecycle-політика з переходом у Glacier Instant Retrieval через 90 днів і Deep Archive через 180 днів економить до 68% на «холодних» даних.
S3 Storage Lens (безкоштовний рівень) уже показує 28 метрик, зокрема мертві багатоскладові завантаження, неповні multipart-об'єкти та розподіл за класами зберігання.
Плата за API-запити (GET, PUT, LIST) часто складає 20–35% рахунку S3, і її не зменшує жоден клас зберігання, тільки кешування та архітектурні зміни.
Egress-трафік S3 до інтернету (від $0,09 за ГБ) залишається найдорожчим компонентом, тому VPC Endpoint для S3 та CloudFront обов'язкові для будь-якого продакшн-навантаження.
Для повторюваних завдань (щомісячна архівація, видалення старих версій) використовуйте S3 Batch Operations замість самописних скриптів, це на порядок дешевше й прозоріше.

Класи зберігання S3 у 2026: повний огляд і актуальні ціни

Отже, давайте почнемо з фундаменту. У 2026 році AWS S3 пропонує вісім основних класів зберігання, і вибір правильного класу для конкретного набору даних це база будь-якої стратегії оптимізації. Класи різняться не лише ціною за гігабайт, а й вартістю запитів, часом відновлення, мінімальним терміном зберігання та мінімальним розміром об'єкта, який тарифікується.

Ігнорувати ці «дрібні» параметри, і ось типова помилка. Чесно кажучи, я багато разів бачив, як у половині акаунтів, де команда «перевела все у Glacier», реальний рахунок навіть зріс. Причина проста: тарифікація мінімальних 128 КБ на кожен об'єкт плюс плата за перехід перекривають економію на самому зберіганні. У межах кожного об'єкта S3 бере плату за три речі: власне зберігання (ціна за ГБ на місяць), API-запити (GET, PUT, LIST, DELETE) і трафік назовні. Класи «холодного» зберігання дешевші на першій позиції, але значно дорожчі на другій, тому переміщувати гарячі логи в Glacier Deep Archive економічно самогубно.

Клас	Ціна за ГБ/міс (us-east-1)	Мін. термін	Мін. об'єкт	Ідеальний випадок
S3 Standard	$0,023	–	–	Активні дані, статичні сайти, API-бекенд
S3 Intelligent-Tiering	$0,023 → $0,00099	–	128 КБ	Непередбачуваний доступ, датасети
S3 Standard-IA	$0,0125	30 днів	128 КБ	Резервні копії, довгі логи
S3 One Zone-IA	$0,01	30 днів	128 КБ	Відновлювані дані, вторинні копії
S3 Glacier Instant Retrieval	$0,004	90 днів	128 КБ	Медіаархіви, дані комплаєнс
S3 Glacier Flexible Retrieval	$0,0036	90 днів	–	Довгий архів із рідкісним доступом
S3 Glacier Deep Archive	$0,00099	180 днів	–	7–10 років ретенції, юридичні дані
S3 Express One Zone	$0,11	1 година	–	ML-тренування, аналітика мілісекундного доступу

Актуальні цифри звіряйте з офіційною сторінкою тарифів S3, бо AWS періодично оновлює регіональні ціни й додає нові класи. Для країн Європи (eu-central-1, eu-west-1) множник до us-east-1 зазвичай складає 1,05–1,15, тобто економічний ефект від правильного класу тут ще помітніший.

Що таке S3 Intelligent-Tiering і коли його вмикати

S3 Intelligent-Tiering — це клас зберігання, який автоматично переміщує об'єкти між чотирма рівнями доступу залежно від того, як часто до них звертаються, без ручного втручання й додаткової плати за API-запити на моніторинг великих об'єктів. Це найпростіший спосіб перестати платити за «холодні» дані у Standard, а ще найбезпечніший вибір для команд, які не знають реального патерну доступу до своїх бакетів. У 2026 році AWS рекомендує Intelligent-Tiering як типовий клас для нових бакетів із непередбачуваним профілем звернень.

Всередині Intelligent-Tiering працюють чотири рівні: Frequent Access (як Standard), Infrequent Access (доступ у минулі 30 днів був нижче порогу), Archive Instant Access (90+ днів без доступу) і два опційні глибокі рівні: Archive Access (90+ днів, latency 3–5 годин) та Deep Archive Access (180+ днів, latency 12+ годин). Плата за моніторинг складає лише $0,0025 за 1 000 об'єктів, і об'єкти менші за 128 КБ ніколи не тарифікуються як моніторингові.

Ключове обмеження: Intelligent-Tiering штрафує за об'єкти менші за 128 КБ, бо з них тарифікується мінімальний розмір. Тому для бакетів із мільйонами дрібних об'єктів (наприклад, аватарки, thumbnails) економія може виявитися негативною. Я сам одного разу увімкнув Intelligent-Tiering на бакеті з 40 мільйонами PNG-мініатюр і за перший тиждень рахунок піднявся на 12%, поки я не відкатив зміну.

Перевірити середній розмір об'єкта в бакеті можна командою AWS CLI:

aws s3api list-objects-v2 --bucket my-bucket \
  --query 'sum(Contents[].Size) / length(Contents[])' \
  --output text

Якщо середній розмір об'єкта менше 128 КБ, розгляньте альтернативу: агрегуйте дрібні файли в архіви (tar.gz, Parquet, ORC) перед завантаженням у S3. Це не тільки економить на зберіганні, а й радикально знижує кількість GET-запитів під час читання.

Як налаштувати S3 Lifecycle-політики для автоматичного переходу

S3 Lifecycle — це декларативний механізм, який автоматично переводить об'єкти в дешевші класи або видаляє їх за розкладом. На відміну від Intelligent-Tiering, який приймає рішення на основі реального доступу, Lifecycle працює за календарем. Це передбачуваніше й безкоштовне (плата стягується лише за самі API-переходи).

Оптимальна стратегія для більшості команд це комбінація обох підходів: Intelligent-Tiering для активних бакетів із непередбачуваним патерном і жорсткі Lifecycle-правила для логів, резервних копій і артефактів CI/CD, де життєвий цикл відомий наперед. Базова конфігурація Lifecycle-правила у форматі JSON для бакета з логами застосунку виглядає так:

{
  "Rules": [
    {
      "ID": "logs-tiered-retention",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30,  "StorageClass": "STANDARD_IA" },
        { "Days": 90,  "StorageClass": "GLACIER_IR" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 },
      "NoncurrentVersionTransitions": [
        { "NoncurrentDays": 30, "StorageClass": "GLACIER_IR" }
      ],
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Ця політика робить чотири речі одночасно: переводить активні логи в IA через місяць, у Glacier Instant Retrieval через квартал, у Deep Archive через рік і повністю видаляє через 7 років (типова юридична ретенція). Окремі правила для неактуальних версій та автоматичне переривання незавершених multipart-завантажень: це два найбільш недооцінені пункти, які часто економлять більше, ніж основні переходи. Застосувати політику до бакета:

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-app-logs \
  --lifecycle-configuration file://lifecycle.json

S3 Storage Lens: як знайти «приховані» витрати за 15 хвилин

S3 Storage Lens: це вбудований інструмент аналітики, який показує метрики використання та витрат по всіх бакетах в акаунті (або в усій AWS Organization) на єдиному дашборді. Безкоштовний рівень включає 28 метрик і 14 днів історії, і його достатньо, щоб знайти три найбільш дорогі проблеми у 90% акаунтів: незавершені multipart-завантаження, забуті неактуальні версії об'єктів у бакетах із версіонуванням і бакети, які досі повністю на S3 Standard попри «холодні» дані.

Увімкнути дашборд за замовчуванням можна одним викликом:

aws s3control put-storage-lens-configuration \
  --account-id 123456789012 \
  --config-id default-account-dashboard \
  --storage-lens-configuration '{
    "Id": "default-account-dashboard",
    "AccountLevel": {
      "ActivityMetrics": { "IsEnabled": true },
      "BucketLevel": {
        "ActivityMetrics": { "IsEnabled": true },
        "PrefixLevel": { "StorageMetrics": { "IsEnabled": true } }
      }
    },
    "IsEnabled": true
  }'

За 24–48 годин у консолі з'явиться повний зріз: топ-10 бакетів за розміром, розподіл між класами зберігання, обсяг unincomplete multipart uploads і зростання «шуму» від неактуальних версій. У більшості акаунтів саме останні дві категорії становлять 5–15% рахунку, про який ніхто не знає, бо ці об'єкти не видно в AWS Console навіть при увімкнутій опції показу «всіх версій».

Розширений рівень (Advanced Metrics) коштує $0,20 за мільйон об'єктів на місяць і додає 35+ метрик, prefix-level аналіз і 15 місяців історії. Раціонально вмикати його лише на бакетах більше 10 ТБ, де окупність метрик очевидна. Детальніше про метрики див. офіційну документацію Storage Lens.

Витрати на API-запити, egress-трафік і незавершені Multipart Upload

Класичне непорозуміння: команди фокусуються на ціні за ГБ і забувають, що плата за API-запити та egress-трафік часто становить більшу частину рахунку S3, особливо для активних застосунків. GET-запит коштує $0,0004 за 1 000 викликів у Standard, але вже $0,01 за 1 000 у Glacier Instant Retrieval, тобто у 25 разів дорожче. Якщо ви робите мільйон запитів на день до архівних даних, класи зберігання «холодніші за IA» стають антиекономічними навіть при копійчаній ціні за ГБ.

Три конкретні джерела втрат, які треба закрити першими:

Незавершені multipart-завантаження. Кожен виклик CreateMultipartUpload, який не завершився CompleteMultipartUpload, залишає частини об'єкта у бакеті. Ви платите повну ціну зберігання за них, але їх немає в списку об'єктів. Одне правило Lifecycle з AbortIncompleteMultipartUpload: 7 днів вирішує цю проблему назавжди.
Egress-трафік до інтернету. Перший гігабайт вихідного трафіку безкоштовний, але далі ціна складає $0,09 за ГБ до 10 ТБ. Для CDN-подібних навантажень CloudFront + S3 через Origin Access Control знижує витрати на 60–80% через дешевший трафік CloudFront та кешування на edge-локаціях. Детальніше про це у нашому матеріалі про зменшення витрат на egress у AWS, Azure та GCP.
Cross-region реплікація (CRR) без потреби. Copy-запит плюс міжрегіональний трафік коштує $0,02 за ГБ. Для DR-сценаріїв достатньо реплікації в один регіон, а не в кілька. Використовуйте S3 Batch Replication тільки для критичних даних із RPO < 15 хв.

Знайти «завислі» multipart-об'єкти вручну:

aws s3api list-multipart-uploads --bucket my-bucket \
  --query 'Uploads[?Initiated<`2026-08-01`].[Key,UploadId,Initiated]' \
  --output table

Практична стратегія економії 40–70% на S3 за один місяць

Реалістичний план, який ми застосовуємо у виробничих акаунтах, займає п'ять кроків і завершується за 3–4 тижні. Перший тиждень означає виключно збір даних і аудит. Жодних змін до продакшн-конфігурації, поки повний Storage Lens дашборд не покаже реальний розподіл витрат. У другий і третій тиждень застосовуємо Lifecycle-правила спершу до dev/staging-бакетів, потім до продакшн-логів і резервних копій. Четвертий тиждень залишається на моніторинг і донастройку порогів.

Тиждень 1: Аудит. Увімкнути безкоштовний Storage Lens на рівні акаунта та експортувати перший звіт у CSV. Ідентифікувати три бакети з найбільшими витратами та їхній профіль доступу через CloudTrail Data Events (тільки на 24 години, щоб не збільшувати рахунок).
Тиждень 2: Швидкі виграші. Застосувати AbortIncompleteMultipartUpload: 7 до всіх бакетів через AWS Config Rule. Видалити неактуальні версії старше 90 днів у бакетах з увімкненим версіонуванням, де немає юридичної потреби їх зберігати.
Тиждень 3: Lifecycle. Написати та застосувати Lifecycle-правила для логів (Standard → IA → Glacier IR → Deep Archive), резервних копій (Standard → Deep Archive через 30 днів) і артефактів CI/CD (видалення через 30 днів).
Тиждень 4: Intelligent-Tiering. Перевести бакети з непередбачуваним патерном доступу на S3 Intelligent-Tiering. Для нових бакетів встановити його як типовий клас через bucket policy та Terraform-модуль.
Постійно: CloudFront + VPC Endpoint. Обгорнути всі публічні бакети CloudFront-дистрибуцією та створити S3 Gateway Endpoint в кожному VPC, звідки йдуть запити до бакетів. Це закриває найдорожче джерело egress.

Ці ж принципи добре поєднуються з іншими інструментами FinOps. Рекомендуємо переглянути наш матеріал про FinOps та AI для автономної оптимізації хмарних витрат, де показано, як AWS Cost Anomaly Detection автоматично помічає стрибки витрат на S3 через 24 години після їх появи. Якщо ж більша частина ваших витрат припадає на compute, а не сховище, паралельно варто глянути на right-sizing EC2 з AWS Compute Optimizer.

Автоматизація конфігурації через Terraform і CDK

Ручні зміни через AWS Console: головне джерело регресій в оптимізації S3. Через півроку ніхто не пам'ятає, чому конкретне Lifecycle-правило вимкнене, і при переносі workload у новий регіон конфігурація втрачається. Тому будь-яка серйозна стратегія оптимізації повинна жити в Infrastructure as Code. Нижче наведений приклад Terraform-модуля, який задає всі рекомендовані параметри для «типового» продакшн-бакета: версіонування, шифрування, блокування публічного доступу, Intelligent-Tiering за замовчуванням і Lifecycle для незавершених multipart-завантажень.

resource "aws_s3_bucket" "app_data" {
  bucket = "myco-app-data-prod"
}

resource "aws_s3_bucket_versioning" "app_data" {
  bucket = aws_s3_bucket.app_data.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_lifecycle_configuration" "app_data" {
  bucket = aws_s3_bucket.app_data.id

  rule {
    id     = "intelligent-tiering-default"
    status = "Enabled"
    transition {
      days          = 0
      storage_class = "INTELLIGENT_TIERING"
    }
    abort_incomplete_multipart_upload { days_after_initiation = 7 }
    noncurrent_version_expiration     { noncurrent_days       = 90 }
  }

  rule {
    id     = "logs-archive"
    status = "Enabled"
    filter { prefix = "logs/" }
    transition { days = 30  storage_class = "STANDARD_IA" }
    transition { days = 90  storage_class = "GLACIER_IR" }
    transition { days = 365 storage_class = "DEEP_ARCHIVE" }
    expiration { days = 2555 }
  }
}

resource "aws_s3_bucket_intelligent_tiering_configuration" "app_data" {
  bucket = aws_s3_bucket.app_data.id
  name   = "archive-tiers"

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

Для команд на AWS CDK аналогічна конфігурація ще лаконічніша через готові L2-конструкції. Обидва підходи дозволяють винести оптимізацію S3 в окремий модуль організації, який автоматично застосовується до всіх нових бакетів через Service Control Policies та AWS Config Rules. Це і є справжня масштабована FinOps-стратегія, а не разова акція. Для складніших сценаріїв багато-акаунтового тегування паралельно застосовуйте стратегію cost allocation tags для multi-account. Для нових функцій S3 та змін API-параметрів слідкуйте за офіційним журналом оновлень Amazon S3.

Поширені запитання

Який клас S3 найдешевший у 2026 році?