AWS S3 Koszty 2026: Przewodnik FinOps

Q: Ile kosztuje S3 w 2026 roku?

W regionie us-east-1: S3 Standard 0,023 USD/GB/mies., Intelligent-Tiering od 0,023 do 0,0036 USD/GB w zależności od warstwy, Standard-IA 0,0125 USD/GB, Glacier Instant Retrieval 0,004 USD/GB, Glacier Deep Archive 0,00099 USD/GB. Do tego requesty (GET 0,0004 USD/1000, PUT 0,005 USD/1000) i egress do internetu od 0,09 USD/GB.

Q: Jak przenieść istniejące obiekty do Intelligent-Tiering bez czekania 30 dni?

Skonfiguruj politykę lifecycle z parametrem Days: 0 w transition rule. AWS rozpocznie migrację istniejących obiektów w ciągu 24–48 godzin. Pamiętaj o jednorazowej opłacie 0,01 USD za 1000 PUT requestów przy migracji.

Q: Dlaczego mój rachunek za S3 jest wyższy niż wskazuje cennik?

Najczęstsze przyczyny: niekompletne multipart uploads (niewidoczne na liście obiektów, ale płatne), stare wersje obiektów bez polityki ekspiracji, transfer cross-AZ i przez NAT Gateway zamiast VPC Endpoint, oraz minimum billable size 128 KB dla klas Standard-IA i Glacier IR. Storage Lens pokazuje rozkład tych pozycji.

Q: Czy warto włączać Cross-Region Replication dla backupu?

Tylko jeśli wymaga tego compliance lub RPO/RTO. CRR podwaja koszt storage, dodaje opłaty PUT (0,005 USD/1000) oraz transfer inter-region (0,02 USD/GB). Dla większości scenariuszy DR wystarczy Cross-Region Backup z polityką lifecycle do Glacier Deep Archive, czyli 20× taniej.

Aktualizacja: 30 maja 2026

Optymalizacja kosztów AWS S3 w 2026 roku polega na świadomym dobieraniu klas pamięci masowej (S3 Standard, Intelligent-Tiering, Glacier), wdrażaniu polityk lifecycle oraz eliminacji ukrytych opłat za transfer danych. W typowym audycie udaje mi się obniżyć rachunek za S3 o 40–80% bez zmian w kodzie aplikacji. W tym przewodniku pokażę dokładnie, co tnę najpierw, jakie liczby pokazuję CFO i jak konfiguruję reguły lifecycle, żeby nie skasować danych, których ktoś jeszcze potrzebuje.

S3 Intelligent-Tiering automatycznie przenosi obiekty do tańszych warstw po 30 i 90 dniach braku dostępu, dając oszczędność rzędu 40% i 68% wobec S3 Standard.
Opłata monitoringowa wynosi 0,0025 USD za 1000 obiektów miesięcznie; obiekty mniejsze niż 128 KB są z niej zwolnione.
Polityki lifecycle z parametrem Days: 0 migrują istniejące dane do Intelligent-Tiering natychmiast, bez opóźnienia 30 dni.
VPC Gateway Endpoints dla S3 są darmowe i eliminują opłatę NAT Gateway 0,045 USD/GB. Instalacja zajmuje 5 minut.
CloudFront z cache hit rate 80% redukuje koszt egressu z S3 o około 80%; różnica wobec bezpośredniego transferu to 30–50%.
Storage Lens w wersji Advanced kosztuje 0,20 USD za milion obiektów, ale zwraca się w pierwszym tygodniu audytu. Bez niego pracujesz po omacku.

Dlaczego rachunek za S3 rośnie szybciej niż dane

W ostatnim kwartale przejmowałem konto AWS, na którym S3 generował 312 000 USD miesięcznie, z czego 71% szło na dane, do których nikt nie sięgnął od ponad 90 dni. Wszystko leżało w S3 Standard, bo „kiedyś tam to wrzuciliśmy i działa”. Po trzech tygodniach zeszliśmy do 96 000 USD bez utraty SLA. To nie jest wyjątek. To scenariusz, który widzę u 80% klientów.

Szczerze, powody są zawsze te same: brak polityk lifecycle, brak Intelligent-Tiering, multipart uploads, które nigdy się nie zakończyły, niezarządzane wersjonowanie i transfer danych przepychany przez NAT Gateway zamiast VPC Endpoint. Każda z tych pozycji wygląda niewinnie w izolacji, ale razem potrafią zdublować rachunek. AWS świadomie projektuje S3 tak, żeby domyślne ustawienia były bezpieczne, nie tanie. Twoja praca jako praktyka FinOps polega na świadomym tuningu tych domyśli.

Drugi powód, dla którego rachunki rosną szybciej niż dane, to opłaty „obok storage”. Requesty PUT/GET, transfer cross-AZ, NAT Gateway processing, opłaty za skanowanie z Athena czy S3 Select. W jednym audycie 38% rachunku za S3 to były requesty, a nie dane. Bez Storage Lens nie zobaczysz tego rozkładu i będziesz ciął nie to, co trzeba.

Klasy pamięci S3 w 2026, tabela porównawcza

AWS oferuje obecnie osiem klas pamięci S3, z czego realnie do wyboru pozostaje pięć. Pełną aktualną cennikową siatkę znajdziesz w oficjalnym cenniku Amazon S3; poniższa tabela pokazuje ceny w regionie us-east-1 dla pierwszych 50 TB i służy do szybkiej decyzji architektonicznej.

Klasa pamięci	Cena (USD/GB/mies.)	Min. czas przechowywania	Czas dostępu	Kiedy wybrać
S3 Standard	0,023	brak	ms	Dane gorące, dostęp wielokrotny w miesiącu
S3 Intelligent-Tiering	0,023 → 0,0036	brak	ms	Nieprzewidywalne wzorce, obiekty ≥128 KB
S3 Standard-IA	0,0125	30 dni	ms	Dostęp rzadziej niż raz w miesiącu, znany wzorzec
S3 One Zone-IA	0,01	30 dni	ms	Dane odtwarzalne, jedno AZ akceptowalne
S3 Glacier Instant Retrieval	0,004	90 dni	ms	Archiwum z dostępem kwartalnym
S3 Glacier Flexible Retrieval	0,0036	90 dni	minuty–godziny	Backupy, compliance, dostęp roczny
S3 Glacier Deep Archive	0,00099	180 dni	12 godzin	Długoterminowa retencja, audyt prawny

Rzecz, której nie widać w tabeli, a która zabija budżety: minimum billable object size. Standard-IA i One Zone-IA naliczają minimum 128 KB za obiekt, a Glacier Instant Retrieval minimum 128 KB plus 8 KB metadanych. Jeśli masz bucket z milionami plików po 4 KB i puścisz lifecycle do Glacier IR, twój rachunek pójdzie w górę, nie w dół. Sprawdzam to zawsze przed migracją: aws s3 ls --recursive --summarize plus skrypt liczący rozkład rozmiarów.

Czym jest S3 Intelligent-Tiering i kiedy się opłaca

S3 Intelligent-Tiering to klasa pamięci, która automatycznie monitoruje wzorce dostępu i przenosi obiekty pomiędzy trzema warstwami: Frequent Access (cena S3 Standard), Infrequent Access (po 30 dniach bez dostępu, oszczędność 40%) oraz Archive Instant Access (po 90 dniach, oszczędność 68%). Opcjonalnie można włączyć Deep Archive Access (180+ dni). Klienci AWS zaoszczędzili od premiery w 2018 roku ponad 6 miliardów USD na tej jednej klasie. Szczegóły w dokumentacji S3 Intelligent-Tiering.

Kiedy Intelligent-Tiering się opłaca, a kiedy nie? Decyzja sprowadza się do dwóch zmiennych: średniego rozmiaru obiektu i przewidywalności dostępu. Praktyczna reguła, której używam:

Włącz: bucket z obiektami ≥128 KB i mieszanym/nieprzewidywalnym dostępem (logi aplikacyjne, user uploads, dane analityczne, ML training data).
Nie włączaj: bucket z milionami małych plików (thumbnails, JSON eventów <10 KB), bo opłata monitoringowa 0,0025 USD/1000 obiektów przekroczy oszczędności.
Zastąp lifecycle: jeśli masz przewidywalny wzorzec „90 dni gorące, potem zimne”, twardy lifecycle do Standard-IA będzie tańszy, bo unikasz opłaty monitoringowej.

Polityki lifecycle: konfiguracja krok po kroku

Lifecycle policies to najbardziej niedoceniana funkcja S3, i jednocześnie ta, która zwraca się najszybciej. Poniżej polityka, której używam jako bazowej dla większości bucketów aplikacyjnych: natychmiastowa migracja istniejących obiektów do Intelligent-Tiering, twarde przejście do Glacier IR po roku, ekspiracja niekompletnych multipart uploads i czyszczenie starych wersji.

{
  "Rules": [
    {
      "ID": "MoveToIntelligentTiering",
      "Status": "Enabled",
      "Filter": {},
      "Transitions": [
        {
          "Days": 0,
          "StorageClass": "INTELLIGENT_TIERING"
        }
      ]
    },
    {
      "ID": "ArchiveOldDataToGlacierIR",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        {
          "Days": 365,
          "StorageClass": "GLACIER_IR"
        }
      ]
    },
    {
      "ID": "AbortIncompleteMultipartUploads",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    },
    {
      "ID": "ExpireNoncurrentVersions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 90,
        "NewerNoncurrentVersions": 3
      }
    }
  ]
}

Aplikujesz to jednym poleceniem:

aws s3api put-bucket-lifecycle-configuration \
  --bucket moj-bucket-produkcyjny \
  --lifecycle-configuration file://lifecycle.json

Drugi częsty błąd: zapomniana reguła AbortIncompleteMultipartUpload. Każdy nieukończony upload (np. crash klienta przy ładowaniu pliku 5 GB) zostawia części, za które płacisz po cenie Standard, ale których nie widzisz na liście obiektów. W jednym audycie znalazłem 47 TB takich „duchów”. Czyste 1080 USD/miesiąc do odzyskania, dosłownie z niczego.

Jak obniżyć koszty S3 o 40–80%

To jest sekcja, którą najczęściej dostaję jako pytanie od zespołów: „Jak obniżyć koszty S3?”. Moja kolejność interwencji, w której każdy krok zwraca się szybciej niż następny:

Włącz Storage Lens Advanced (1 dzień). Bez danych pracujesz po omacku.
Wyczyść niekompletne multipart uploads (1 dzień, lifecycle rule). Średnio 2–10% rachunku.
Wdróż Intelligent-Tiering dla bucketów aplikacyjnych (1 tydzień). 30–60% oszczędności.
Ustaw VPC Gateway Endpoint dla S3 (5 minut). Eliminuje opłatę NAT 0,045 USD/GB.
Skonfiguruj CloudFront dla publicznych assetów (1 tydzień). 30–50% taniej niż bezpośredni egress.
Przeprowadź audyt wersjonowania (2–5 dni). Stare wersje rosną w nieskończoność, jeśli nie masz NoncurrentVersionExpiration.
Wymuś compression at source (gzip/zstd) dla logów i metryk. Typowo 60–75% redukcji rozmiaru.

Mam w doświadczeniu konto, na którym wykonanie tylko kroków 1–4 obniżyło rachunek S3 z 84 000 USD do 31 000 USD w 11 dni. Reszta listy to dalsza optymalizacja, ale ROI rośnie najszybciej z pierwszych pięciu pozycji. Podobne wzorce (kolejność interwencji, nie indywidualne triki) opisuję też w naszym przewodniku po AWS Savings Plans vs Reserved Instances, bo logika oszczędzania na compute działa identycznie: najpierw widoczność, potem twarde commitmenty, na końcu mikrooptymalizacje.

Ukryte koszty transferu i egressu z S3

Sam storage to tylko jedna strona rachunku za S3. W większości audytów, które prowadzę, transfer danych stanowi 25–40% pozycji „S3 + Data Transfer”. AWS pobiera 0,09 USD/GB za egress do internetu w pierwszych 10 TB, schodząc do 0,07 USD/GB przy 150 TB+. Region São Paulo to 0,15 USD/GB. Cross-AZ transfer wewnątrz tego samego regionu to 0,02 USD/GB w obie strony, często niewidoczne, bo „przecież to wewnątrz AWS”.

Trzy interwencje, które tnę najpierw:

VPC Gateway Endpoint dla S3 i DynamoDB: darmowy, eliminuje przepychanie ruchu przez NAT Gateway. Lambdy odpytujące S3 z prywatnego subnetu bez endpointu płacą podwójnie: 0,045 USD/GB NAT processing plus egress. Pełną konfigurację opisuje dokumentacja VPC Endpoints dla S3.
CloudFront przed publicznymi bucketami: origin fetch z S3 do CloudFront jest darmowy, a edge cache redukuje liczbę requestów. Przy 80% cache hit rate i 50 TB miesięcznego ruchu oszczędzasz około 800 USD/mies. plus zysk na latencji.
Cross-Region Replication tylko tam, gdzie wymaga compliance: replikacja S3 to ukryta opłata za PUT (0,005 USD/1000) plus transfer inter-region (0,02 USD/GB). Widziałem konta, gdzie zespół włączył CRR „bo backup”, a wymóg DR był spełniony przez sam region us-east-1.

Jeśli twoja architektura jest mocno rozproszona między AZ, polecam też nasz przewodnik po optymalizacji kosztów Kubernetes. Wzorce ruchu pod-to-pod cross-AZ generują dokładnie te same opłaty, tylko ukryte w pozycji „EC2-Other”.

Storage Lens i audyt rzeczywistego zużycia

S3 Storage Lens to wbudowana w AWS usługa analityczna, która pokazuje pełny obraz wykorzystania storage w całej organizacji. Free tier daje 28 metryk i 14 dni historii, czyli wystarczająco do szybkiej oceny, ale dla poważnego audytu potrzebujesz Advanced (0,20 USD za milion obiektów monitorowanych, 15 miesięcy historii, 35 metryk dodatkowych w tym Activity Metrics i Prefix Aggregation).

Metryki, na które patrzę w pierwszej kolejności:

% Non-Current Version Bytes: jeśli przekracza 20%, masz problem z wersjonowaniem.
% Incomplete Multipart Upload Bytes: wszystko powyżej 1% to natychmiastowa interwencja.
Cold Bytes Ratio (Advanced): procent danych bez dostępu >90 dni. Powyżej 40% to sygnał do agresywnego lifecycle.
Average Object Size per Prefix: pomaga zdecydować, czy dany prefix nadaje się do Glacier IR (minimum 128 KB billable).

Storage Lens eksportuje też dane do Parquet w S3, co pozwala podpiąć Athenę i robić własne raporty. Mam zapytanie, które uruchamiam co miesiąc; pokazuje top 20 prefixów po zimnych bajtach, posortowanych malejąco. Z tej listy 80% optymalizacji powstaje w 30 minut.

Nowości w S3 w 2026: Intelligent-Tiering dla S3 Tables

Najważniejsza zmiana 2026 roku to wprowadzenie Intelligent-Tiering oraz cross-region replication dla S3 Tables, czyli zarządzanej oferty Apache Iceberg na S3. Wcześniej trzeba było ręcznie pisać polityki lifecycle dla plików Parquet w data lake, co kończyło się albo zbyt agresywną archiwizacją (slow queries), albo brakiem archiwizacji w ogóle. Teraz tabela Iceberg sama przesuwa partycje do tańszych warstw na podstawie wzorców dostępu. Szczegóły w blogu AWS What's New.

Drugi ciekawy ruch to obniżka cen Glacier Instant Retrieval w wybranych regionach i nowy „Express One Zone” dla workloadów wymagających milisekundowego dostępu przy ekstremalnej skali. Nie używam go domyślnie, bo opłata za storage jest wyższa niż S3 Standard, ale request pricing jest 50% niższy. Opłaca się tylko jeśli twój workload jest request-heavy, a nie storage-heavy. Sprawdź swój stosunek requests/GB w Storage Lens przed podjęciem decyzji.

Trzecia rzecz, której nie widać w marketingu: AWS zmienił domyślne zachowanie versioningu dla nowych bucketów tworzonych przez Console, wymuszając jawną decyzję. To dobrze, ale nie pomaga tym, którzy mają stare buckety z włączonym wersjonowaniem bez polityki ekspiracji. To zostaje twoja praca.

Najczęściej zadawane pytania

Czy S3 Intelligent-Tiering zawsze się opłaca?

Nie. Opłata monitoringowa 0,0025 USD za 1000 obiektów może przekroczyć oszczędności w bucketach z milionami małych plików (<128 KB). Dla obiektów ≥128 KB z mieszanym wzorcem dostępu Intelligent-Tiering prawie zawsze wygrywa. Dla przewidywalnych wzorców tańszy jest twardy lifecycle do Standard-IA bez opłaty monitoringowej.

Ile kosztuje S3 w 2026 roku?