AWS S3 -kustannusten optimointi 2026: storage classit, Intelligent-Tiering ja lifecycle-säännöt käytännössä
Käytännön opas S3-kustannusten leikkaamiseen 2026: storage class -hinnat, Intelligent-Tiering vs lifecycle-säännöt, Storage Lens ja yleisimmät piilolaskut. Esimerkit ja JSON-konfiguraatiot us-east-1-hinnoilla.
AWS S3 -kustannusten optimointi tarkoittaa oikean storage classin valintaa kullekin objektille, lifecycle-sääntöjen automatisointia ja Intelligent-Tieringin hyödyntämistä siten, että harvoin käytetty data siirtyy edullisempiin tasoihin ilman manuaalista työtä. Olen ajanut numerot kymmenille S3-tileille viime vuosina, ja säännöllinen kaava on sama: 60–80 % datasta voisi olla halvemmassa tasossa, mutta kukaan ei ole asettanut sääntöjä. Tämä opas näyttää 2026 hinnoilla, miten leikkaat S3-laskua 40–70 % puuttumatta sovelluslogiikkaan.
S3 Standard maksaa 0,023 USD/GB/kk, Glacier Deep Archive vain 0,00099 USD/GB/kk, eli ero on 23-kertainen samalla us-east-1-alueella.
S3 Intelligent-Tiering siirtää objektit automaattisesti pääsymallin mukaan ja tuo tyypillisesti 30–60 % säästöt sekakuormille ilman riskiä noutoviiveestä.
Keskeneräiset multipart-lataukset voivat kerryttää piilolaskua jopa tuhansia euroja kuukaudessa, ja yksi lifecycle-sääntö siivoaa ne pois.
S3 Storage Lens paljastaa hukkadatan: vanhat versiot, ei-tagatut bucketit ja inaktiiviset objektit yhdellä koontinäytöllä.
Glacier Instant Retrieval on usein parempi valinta kuin Standard-IA, jos pääsy on alle kerran kuukaudessa (0,004 USD/GB vs 0,0125 USD/GB).
Versioinnin päälle jättäminen ilman lifecycle-sääntöjä on yleisin kustannusvuoto, jonka löydän asiakastileiltä.
Mistä S3-kustannukset koostuvat?
S3-lasku ei ole yksi rivi vaan vähintään kuusi eri kustannustyyppiä, ja juuri tämän takia optimointi ei onnistu pelkästään storage classia vaihtamalla. Kun avaan AWS Cost Explorerin asiakkaan kanssa ja suodatan Service = S3, näen tyypillisesti seuraavat rivit:
Storage: tallennettu data per GB/kk, eroittain storage classin mukaan. Tämä on yleensä 60–75 % laskusta.
Requests (PUT, COPY, POST, LIST): kirjoituspyynnöt. 0,005 USD per 1 000 pyyntöä Standardissa. Pieniä tiedostoja kirjoittavat sovellukset polttavat tätä.
Requests (GET, SELECT): lukupyynnöt, 0,0004 USD per 1 000 pyyntöä Standardissa, mutta Glacier Deep Archivessa 0,10 USD per 1 000 GET-pyyntöä, eli 250-kertainen.
Data Transfer Out: datasiirto internettiin, 0,09 USD/GB ensimmäiseen 10 TB asti us-east-1:ssä.
Lifecycle transitions: siirrot storage classien välillä, 0,01 USD per 1 000 objektia siirrettäessä Glacier-tasoihin.
Tunne tämä rakenne ennen kuin ehdotat mitään muutoksia. Olen nähnyt tiimien siirtävän 50 TB miljardia pientä objektia Glacier Deep Archiveen, ja seuraavan kuun kun joku ajaa palautuksen, lasku räjähtää siirtohinnoissa. Numerot pitää ajaa ensin.
S3 storage classit ja hinnat 2026
AWS:llä on nyt seitsemän storage classia, ja niiden ero ei ole vain hinnassa per GB vaan myös vähimmäissäilytysajassa, vähimmäisobjektikoossa ja noutoviiveessä. Tämä taulukko näyttää us-east-1-hinnat kesäkuun 2026 tilanteessa. Lähde on aina virallinen S3-hinnoittelusivu, jonka kannattaa varmistaa ennen budjetointia, sillä hinnat eroavat alueittain.
Storage class
Hinta (USD/GB/kk)
Min. säilytys
Noutoviive
Käyttötapaus
S3 Standard
0,023
ei
ms
Aktiivinen, usein luettu data
S3 Intelligent-Tiering
0,023 → 0,00099
ei
ms–12 h
Tuntematon tai vaihteleva pääsymalli
S3 Standard-IA
0,0125
30 pv
ms
Harvoin luettu, mutta pikapääsy
S3 One Zone-IA
0,01
30 pv
ms
Uudelleenrakennettava varmuuskopio
S3 Glacier Instant Retrieval
0,004
90 pv
ms
Arkisto, pääsy < 1×/kk
S3 Glacier Flexible Retrieval
0,0036
90 pv
1 min–12 h
Arkisto, pääsy harvinaista
S3 Glacier Deep Archive
0,00099
180 pv
12 h
Säädösarkisto, 7+ vuotta
Käytännön sääntö, jota käytän asiakkaiden kanssa: jos objekti luetaan harvemmin kuin kerran kuukaudessa eikä pikapääsyä vaadita, Standard-IA ei ole halvin vaan Glacier Instant Retrieval on. Standard-IA on 0,0125 USD/GB, Glacier Instant Retrieval 0,004 USD/GB samalla millisekuntien noutoviiveellä. Ainoa ero on, että Glacier IR:n GET-pyyntöhinta on 0,01 USD per 1 000 pyyntöä Standard-IA:n 0,001 USD:n sijaan, joten matikka kääntyy ainoastaan jos pääsyfrekvenssi nousee yli noin kerran viikossa. Aja S3 Storage Class Analysis ennen siirtoa.
Milloin S3 Intelligent-Tiering kannattaa?
S3 Intelligent-Tiering on lähes aina oikea valinta, jos et tiedä etukäteen miten dataa luetaan. Ja totuus on, että useimmat tiimit eivät tiedä. Tier siirtää objektit automaattisesti viiteen tasoon (Frequent Access, Infrequent Access 30 vrk:n jälkeen, Archive Instant Access 90 vrk:n jälkeen, sekä valinnaiset Archive Access ja Deep Archive Access 90–180+ vrk:n jälkeen) pääsymallin mukaan. Ei vähimmäissäilytysaikaa, ei noutomaksuja Frequent/Infrequent/Archive Instant -tasoissa.
Monitorointikustannus on 0,0025 USD per 1 000 objektia kuukaudessa, joten objekteille alle 128 KB Intelligent-Tiering ei kannata (ne pysyvät Frequent Access -tasossa joka tapauksessa). Kustannusrajaksi muodostuu suunnilleen tämä: jos objekti on alle 128 KB tai sen elinkaari alle 30 päivää, käytä Standardia. Muutoin lähes kaikki uudet bucketit kannattaa luoda Intelligent-Tiering oletuksena.
Tämä konfiguraatio on se, jota suosittelen oletuksena: pidetään Archive ja Deep Archive -tasot päällä, jolloin yli 180 päivää koskemattomat objektit valuvat 0,00099 USD/GB hintaan automaattisesti. Yhdellä asiakkaallani 800 TB analytiikkadataa tippui Intelligent-Tieringin jälkeen 18 400 USD:sta 6 200 USD:hen kuukaudessa, eli 66 % säästö ilman koodimuutoksia. En ole nähnyt yhtä helppoa voittoa muualla cloud-puolella.
Lifecycle-sääntöjen rakentaminen käytännössä
Vaikka Intelligent-Tiering hoitaa siirrot puolestasi, lifecycle-säännöt ovat välttämättömiä kahteen asiaan: vanhojen versioiden ja keskeneräisten multipart-latausten siivoamiseen sekä deterministisiin siirtoihin silloin, kun tunnet datan pääsymallin (esim. lokit, jotka luetaan ensimmäiset 7 päivää ja sitten ei koskaan). FinOps-tiimini noudattaa tätä FinOps-strategiaopasta kaikkien bucketien tarkastuksessa.
Tässä on tuotantokäytössä oleva JSON-sääntö, joka kattaa loki-bucketin elinkaaren:
Tallenna tämä tiedostoon lifecycle.json ja aja aws s3api put-bucket-lifecycle-configuration --bucket mun-bucket --lifecycle-configuration file://lifecycle.json. Sääntö siirtää lokit Standard-IA:han 30 päivän kuluttua, Glacier Instant Retrievaliin 90 päivässä, Deep Archiveen vuodessa ja poistaa ne 7 vuoden jälkeen (säädöksenmukainen retentioaika). Lisäksi se siivoaa keskeneräiset multipart-lataukset 7 päivän jälkeen ja vanhentaa ei-aktiiviset versionit 30 päivässä.
S3 Storage Lens hukkadatan löytämiseen
S3 Storage Lens on AWS:n koko organisaation kattava analyysityökalu, joka näyttää 60+ mittaria (käyttömäärä, pyyntöaktiivisuus, salausstatus, replikointi, versiointi) kaikkien tilien ja alueiden poikki yhdellä koontinäytöllä. Ilmainen versio kattaa 28 päivän historian ja perusmittarit. Advanced metrics (0,20 USD per miljoona objektia kuukaudessa) avaa pääsymallit ja optimointisuositukset 15 kuukaudeksi taaksepäin. Virallinen Storage Lens -dokumentaatio kuvaa kaikki ulottuvuudet.
Käytännössä ensimmäinen asia, jonka katson uudessa tiliassessmentissä, on Storage Lens -koontinäytön "Cost optimization" -välilehti. Se nostaa esiin tyypillisesti:
Bucketit ilman lifecycle-sääntöjä: yleensä 40–60 % bucketeista organisaatiossa, joka ei ole tehnyt FinOps-tarkastusta.
Ei-aktiivisten versioiden määrä: versiointi päällä mutta ei vanhentamissääntöjä = piilolasku.
Keskeneräiset multipart-lataukset: usein 5–20 % "objektimäärästä" mutta laskutetaan täysimittaisina.
Replikoidut bucketit eri alueille: joskus replikointi on jäänyt päälle vanhasta projektista.
Aktivointi tapahtuu konsolissa S3 → Storage Lens → Create dashboard, ja organisaatiolaajuinen näkymä vaatii AWS Organizationsin delegointioikeudet hallintatilille.
Multipart-lataukset ja versionit, piilolaskun lähteet
Tämä on yksi yleisimmistä löydöistä asiakasprojekteissa. Multipart-upload pilkkoo suuren objektin osiin (yleensä 5–100 MB per osa), ja jos lataus epäonnistuu eikä asiakassovellus kutsu AbortMultipartUpload-API:a, osat jäävät S3:hen. Ne ovat laskutettuja mutta näkymättömiä normaalissa ListObjects-kutsussa. Yhdellä asiakkaalla löysin aws s3api list-multipart-uploads -komennolla 47 TB orpoja osia, jotka kerryttivät 1 081 USD/kk Standard-hinnoilla. Yksi lifecycle-sääntö lopetti vuodon.
# Listaa keskeneräiset multipart-lataukset kaikissa bucketeissa
for b in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
count=$(aws s3api list-multipart-uploads --bucket $b \
--query 'length(Uploads || `[]`)' --output text 2>/dev/null)
if [ "$count" -gt "0" ] 2>/dev/null; then
echo "$b: $count incomplete multipart uploads"
fi
done
Versiointi on toinen yhtä yleinen vuoto. Kun joku ottaa versioinnin käyttöön (tyypillisesti compliance-syistä) eikä luo NoncurrentVersionExpiration-sääntöä, jokainen PutObject samaan avaimeen luo uuden version ja vanha jää maksulliseksi ikuisesti. Olen nähnyt bucketin, jossa "aktiivista" dataa oli 2 TB ja vanhoja versioita 38 TB. Korjaus on lisätä lifecycle-sääntö, joka siirtää ei-aktiiviset versionit Glacier Deep Archiveen 30 päivän jälkeen ja vanhentaa ne kokonaan esim. 365 päivässä. Säilytät palautusmahdollisuuden, mutta et maksa Standard-hintaa hylätyistä versioista.
Pyyntö- ja siirtokustannusten leikkaaminen
Storage maksaa rivinä paljon, mutta pyyntö- ja siirtokustannukset ovat usein toiseksi suurin rivi, ja niihin pätevät täysin eri optimointistrategiat. Tyypillinen kuvio: data-analytics-tiimi ajaa Athena-kyselyitä, jotka tekevät miljoonia pieniä GET-pyyntöjä parquet-tiedostoihin, ja kuukausilasku on 60 % storage + 30 % requests + 10 % data transfer.
Pyyntöoptimointi:
Yhdistele pieniä tiedostoja: 10 000 × 1 MB tiedostoa = 10 000 GET-pyyntöä = 0,004 USD; sama data yhdessä 10 GB tiedostossa = 1 GET = 0,0000004 USD plus range-pyyntö.
Käytä S3 Select tai Athenan parquet-pruning: älä noua koko objektia, jos tarvitset murto-osan.
Aseta CloudFront S3:n eteen: CloudFront → S3 -siirto on ilmaista, ja CloudFrontin Data Transfer Out on hieman halvempaa (0,085 USD/GB vs 0,09 USD/GB), plus välimuistiin lyödyt pyynnöt eivät edes osu S3:een.
Datasiirtoa käsittelimme erikseen egress-kustannusten optimointi -oppaassa, mutta S3:n näkökulmasta yksi muistilappu: VPC Endpoint S3:lle (Gateway tyyppi) on ilmainen ja poistaa NAT Gateway -kustannukset, kun EC2- tai Lambda-koodi lukee S3:sta saman alueen sisällä. Tämä yksi muutos säästää usein 200–2 000 USD/kk keskikokoisilla kuormilla.
Compressointi on toinen yksinkertainen mutta usein unohdettu vipu. Athena-pohjaiset analytiikkakuormat saavat tyypillisesti 3–5x kokoeron, kun raaka CSV-tiedostot muunnetaan Snappy-pakatuksi Parquet-muodoksi, jolloin sekä storage- että pyyntökustannukset tippuvat suhteessa. AWS Glue Jobissa konversio onnistuu noin 50 rivillä koodia, ja takaisinmaksu on yleensä alle viikko. Ei-rakenteiselle datalle Zstandard tai gzip ennen S3-uploadia toimii samalla logiikalla.
Lopuksi, käytä S3 Storage Class Analysisia. Aktivoit sen prefix-tasolla bucketissa ja se kerää 30 päivän pääsymallin sekä antaa konkreettisen suosituksen, milloin objektit kannattaisi siirtää IA-tasoihin. Yksityiskohdat löytyvät AWS:n virallisesta dokumentaatiosta. Tämä on ilmainen ja datavetoinen tapa perustella tiimille muutokset, ja minulle se on lähes aina ensimmäinen askel ennen kuin ehdotan yhtään lifecycle-sääntöä.
Usein kysytyt kysymykset
Mikä on halvin S3-storage class 2026?
S3 Glacier Deep Archive on halvin hinnoilla 0,00099 USD/GB/kk us-east-1-alueella, mutta sillä on 180 päivän vähimmäissäilytysaika ja 12 tunnin noutoviive. Pikapääsyä vaativalle datalle halvin on Glacier Instant Retrieval (0,004 USD/GB) tai Intelligent-Tiering Archive Instant Access -taso (sama 0,004 USD/GB).
Onko S3 Intelligent-Tiering aina edullisempi kuin Standard?
Ei. Intelligent-Tieringissä on 0,0025 USD per 1 000 objektia kuukaudessa monitorointimaksu, joten alle 128 KB objekteille ja alle 30 päivää eläville objekteille Standard on halvempi. Suurille (>128 KB) ja pitkäikäisille (>30 päivää) objekteille Intelligent-Tiering voittaa lähes aina.
Miten löydän keskeneräiset multipart-lataukset S3-bucketista?
Aja aws s3api list-multipart-uploads --bucket BUCKET_NAME. Jos vastauksessa on Uploads-taulukko, niissä on keskeneräisiä latauksia. Voit poistaa ne yksitellen abort-multipart-upload-komennolla tai automaattisesti lifecycle-säännöllä, joka käyttää AbortIncompleteMultipartUpload-toimintoa 7 päivän jälkeen.
Voinko siirtää objekteja takaisin Standardiin Glacierista?
Et suoraan lifecycle-säännöllä, sillä lifecycle-siirrot kulkevat vain "kylmempään" suuntaan. Sinun on tehtävä restore-object -kutsu palauttaaksesi tilapäisen kopion Glacieristä, ja jos haluat objektin pysyvästi Standardiksi, kopioi se uudella avaimella aws s3 cp -komennolla. Tämä aiheuttaa palautus- ja siirtokustannukset, joten suunnittele storage class -strategia huolella alusta alkaen.
Kuinka paljon S3 Storage Lens maksaa?
Free-tier sisältää 28 päivän historian ja noin 28 perusmittaria, joka riittää useimmille tiimeille. Advanced metrics maksaa 0,20 USD per miljoona objektia kuukaudessa ja avaa 60+ mittaria sekä 15 kuukauden historian. 100 miljoonan objektin tilillä advanced metrics maksaa 20 USD/kk, mikä on käytännössä aina kannattava investointi.
Opi toteuttamaan tehokas pilviresurssien tagausstrategia AWS:ssä, Azuressa ja GCP:ssä. Terraform-koodiesimerkit, tagien pakottaminen käytännöillä ja laskutusintegraatio — kaikki kustannusten kohdistamisen rakennuspalikat yhdessä oppaassa.