Regningen for skylagring ser enkel ut helt til den ikke gjør det. Et par cent per GB virker ubetydelig, men legg til forespørsler, utgående trafikk og bindingstid på kald lagring, og totalen kan overraske selv erfarne driftsteam. AWS S3, Azure Blob Storage og Google Cloud Storage er de tre mest brukte objektlagringstjenestene i verden, og alle tre reklamerer med lave startpriser. Forskjellen ligger i detaljene: hvor mye du betaler for å hente ut data, hvor lenge du er bundet i en lagringsklasse, og hvor raskt tjenesten faktisk svarer under last. Denne sammenligningen går gjennom priser, spesifikasjoner og uavhengige ytelsestester for alle tre, med reelle tall fra offisielle prissider og publiserte benchmarker. Målet er ikke å kåre én vinner, men å vise nøyaktig hvor kronene går, slik at du kan regne på egen arbeidsmengde i stedet for å stole på en generell anbefaling som ikke tar hensyn til hvor mye data du faktisk henter ut, hvor lenge du lagrer den, og hvilken sky resten av systemene dine allerede kjører i.
Hva er objektlagring i skyen?
Objektlagring skiller seg fra tradisjonell fillagring ved at data lagres som frittstående objekter i en flat struktur, med metadata og en unik nøkkel i stedet for mapper og stier. Dette gjør tjenestene ekstremt skalerbare: du kan lagre noen få filer eller flere milliarder objekter uten å endre arkitektur. AWS S3, Azure Blob Storage og Google Cloud Storage bygger alle på denne modellen, og de brukes til alt fra nettstedsbilder og videostrømming til datainnsjøer for maskinlæring og lovpålagt arkivering.
Det som skiller tjenestene fra hverandre, er ikke selve lagringsmodellen, men hvordan de priser tilgang til dataene. Alle tre deler lagringen inn i klasser eller “tiers” basert på hvor ofte du forventer å hente ut data. Jo sjeldnere tilgang, jo lavere lagringspris, men til gjengjeld høyere kostnad og lengre ventetid når du faktisk trenger dataene. Denne artikkelen bruker offisielle priser fra AWS, Microsoft Azure og Google Cloud, i tillegg til uavhengige ytelsestester, for å vise hvor forskjellene faktisk ligger.
Tre ulike tilnærminger: AWS S3, Azure Blob Storage og Google Cloud Storage
Selv om alle tre løser samme grunnleggende problem, er de bygget med ulike prioriteringer. AWS S3 er eldst og har det bredeste økosystemet av tredjepartsverktøy. Azure Blob Storage er tettest integrert med resten av Microsofts skyportefølje. Google Cloud Storage er bygget rundt Googles interne infrastruktur og markedsføres på enkelhet i klassestruktur. Disse prioriteringene arvet fra hver leverandørs opprinnelse, henholdsvis en netthandelsplattform, en bedriftsprogramvareleverandør og et søk- og annonseselskap, gjenspeiles fortsatt i hvordan tjenestene er priset og hvilke tilleggstjenester de er tettest integrert med i dag.
AWS S3
Amazon S3 (Simple Storage Service) lanserte objektlagring som skytjeneste og har siden bygget ut en rekke lagringsklasser: Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval og Glacier Deep Archive. Intelligent-Tiering flytter automatisk objekter mellom klasser basert på tilgangsmønster, noe som gjør S3 til det mest fleksible alternativet for arbeidsmengder der du ikke vet på forhånd hvor ofte data vil bli hentet ut.
Azure Blob Storage
Azure Blob Storage tilbyr fire tilgangsnivåer: Hot, Cool, Cold og Archive, ifølge Microsofts offisielle prisside. Tjenesten er tett koblet mot Azure Active Directory og resten av Azure-økosystemet, noe som gjør den til et naturlig valg for organisasjoner som allerede kjører arbeidslaster i Azure eller bruker Microsoft 365 i stor skala. Blob Storage støtter også flere redundansnivåer, fra lokalt redundant lagring (LRS) til geo-redundant lagring med lesetilgang (RA-GRS).
Google Cloud Storage
Google Cloud Storage holder seg til fire lagringsklasser: Standard, Nearline, Coldline og Archive, ifølge Googles offisielle dokumentasjon. Google markedsfører en enklere modell der samme API brukes uavhengig av klasse, og der du kan endre lagringsklasse på et objekt uten å flytte det til en annen bøtte. Google Cloud Storage brukes ofte sammen med BigQuery og Vertex AI i dataanalyse- og maskinlæringspipeliner.
Spesifikasjoner side om side
Tabellen under stiller opp de tekniske forskjellene mellom tjenestene basert på offisiell dokumentasjon fra AWS, Microsoft og Google.
| Egenskap | AWS S3 | Azure Blob Storage | Google Cloud Storage |
|---|---|---|---|
| Antall lagringsklasser | 7 (Standard til Glacier Deep Archive) | 4 (Hot, Cool, Cold, Archive) | 4 (Standard, Nearline, Coldline, Archive) |
| Automatisk klassebytte | Ja, via Intelligent-Tiering | Ja, via livssyklusregler | Ja, via Object Lifecycle Management |
| Publisert holdbarhet | 99,999999999 % | 99,999999999 % (LRS) | 99,999999999 % |
| Minste bindingstid, mellomklasse | 30 dager (Standard-IA) | 30 dager (Cool) | 30 dager (Nearline) |
| Minste bindingstid, kald klasse | 90 dager (Glacier) | 90 dager (Cold) | 90 dager (Coldline) |
| Minste bindingstid, arkiv | 180 dager (Deep Archive) | 180 dager (Archive) | 365 dager (Archive) |
| Redundansalternativer | Standard, One Zone | LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS | Regional, dobbeltregional, multiregional |
| Skriveforespørsel, standardklasse | 0,005 USD / 1000 | 0,065 USD / 10 000 | 0,005 USD / 1000 (Klasse A) |
| Leseforespørsel, standardklasse | 0,0004 USD / 1000 | 0,005 USD / 10 000 | 0,0004 USD / 1000 (Klasse B) |
| Tett integrasjon med | AWS-økosystemet (Lambda, CloudFront, Athena) | Azure-økosystemet (Entra ID, Synapse, AKS) | Google-økosystemet (BigQuery, Vertex AI, GKE) |
| Tidligste lansering | 2006 | 2010 | 2010 (som Google Cloud Storage) |
Bindingstiden på arkivklassene er der forskjellen er størst. Google Cloud Storage krever at data ligger i Archive-klassen i 365 dager før du kan slette eller flytte det uten et gebyr for tidlig sletting, mot 180 dager hos både AWS Glacier Deep Archive og Azure Archive. For organisasjoner med lovpålagt oppbevaringsplikt på nøyaktig ett år kan det gjøre GCS Archive til det naturlige valget, mens kortere oppbevaringskrav passer bedre med AWS eller Azure.
Prissammenligning: lagring per GB per måned
Lagringsprisen er utgangspunktet for enhver kostnadsvurdering. Tabellen under viser offisiell listepris per GB per måned for hver lagringsklasse, hentet fra prissidene til AWS, Azure og Google Cloud for standardregioner i USA.
| Lagringsklasse | AWS S3 | Azure Blob Storage | Google Cloud Storage |
|---|---|---|---|
| Standard / Hot (varm) | 0,023 USD/GB | 0,0184 USD/GB | 0,020 USD/GB |
| Mellomklasse (Cool/Nearline/IA) | Standard-IA (egen pris) | 0,01 USD/GB (Cool) | 0,010 USD/GB (Nearline) |
| Kald klasse (Coldline/Cold) | Glacier Flexible Retrieval | Egen Cold-pris | 0,004 USD/GB (Coldline) |
| Arkiv (dypeste klasse) | 0,00099 USD/GB (Deep Archive) | 0,00099 USD/GB (Archive) | 0,0012 USD/GB (Archive) |
Ser du kun på standardklassen, er Azure Blob Storage billigst på papiret med 0,0184 USD per GB, mot 0,020 USD hos Google Cloud Storage og 0,023 USD hos AWS S3. Det gir Azure et forsprang på rundt 25 prosent lavere listepris enn AWS på ren lagring av varme data. På arkivnivå er bildet snudd: AWS Glacier Deep Archive og Azure Archive ligger begge på 0,00099 USD per GB, mens Google Cloud Storage Archive er omtrent 21 prosent dyrere på 0,0012 USD per GB. Forskjellen mellom en bedrifts dyreste og billigste klasse hos samme leverandør er stor: hos AWS er Standard-klassen rundt 23 ganger dyrere per GB enn Glacier Deep Archive, og det samme forholdet gjelder hos Azure mellom Hot og Archive.
Regneeksempel: hva koster 10 TB lagring i praksis?
Prosentforskjeller er abstrakte inntil du regner dem om til et konkret scenario. Se for deg et team som lagrer 10 TB (10 240 GB) i standardklassen gjennom en hel måned, og som i tillegg henter ut 1 TB (1 024 GB) til internett i samme periode. Basert på listeprisene i tabellene over blir ren lagringskostnad for måneden 235,52 USD hos AWS S3, 188,42 USD hos Azure Blob Storage og 204,80 USD hos Google Cloud Storage.
Legger du til egress-kostnaden for uttrekket på 1 TB, endrer bildet seg noe. Hos AWS er de første 100 GB gratis, så de resterende 924 GB koster 83,16 USD, som gir en samlet månedskostnad på 318,68 USD. Hos Azure og Google Cloud er det ikke bekreftet noen tilsvarende fri kvote i samme størrelse i denne sammenligningen, så full pris på 1 024 GB gir henholdsvis 89,09 USD og 122,88 USD i egress-kostnad. Samlet lander Azure på rundt 277,51 USD, mens Google Cloud Storage ender på 327,68 USD, dyrest av de tre i dette scenarioet selv om Google har lavere ren lagringspris enn AWS. Eksempelet viser hvorfor egress-kostnad kan overstyre selv en fordel på lagringsprisen når arbeidsmengden innebærer mye uttrekk av data.
Forespørsler og API-kall: hva koster hver operasjon?
Lagringsprisen forteller bare halve historien. Alle tre tjenester tar betalt per forespørsel, og for arbeidsmengder med mange små filer, som miniatyrbilder, IoT-logger eller hendelsesdata, kan forespørselskostnaden fort overgå selve lagringskostnaden.
AWS S3 tar 0,005 USD per 1000 skriveoperasjoner (PUT, COPY, POST, LIST) og 0,0004 USD per 1000 leseoperasjoner (GET og lignende) i standardklassen. Google Cloud Storage bruker en tilsvarende modell med Klasse A-operasjoner (skriving og oppføring) til 0,005 USD per 1000 og Klasse B-operasjoner (lesing) til 0,0004 USD per 1000, altså identisk med AWS på dette punktet. Azure Blob Storage prises annerledes, med skriveoperasjoner i Hot-tier til 0,065 USD per 10 000 operasjoner og leseoperasjoner til 0,005 USD per 10 000. Omregnet til samme enhet som de to andre tilsvarer det 0,0065 USD per 1000 skriveoperasjoner, altså rundt 30 prosent dyrere enn AWS og Google på skriving, mens leseprisen på 0,0005 USD per 1000 ligger tettere opp mot konkurrentene.
For arbeidsmengder med enorme mengder små skriveoperasjoner, som logging fra tusenvis av enheter samtidig, kan denne forskjellen bety mer for totalregningen enn selve GB-prisen. Det er en av grunnene til at kostnadsberegning for objektlagring alltid bør ta utgangspunkt i faktisk trafikkmønster, ikke bare i lagringsvolum.
Utgående trafikk: den skjulte kostnaden
Utgående trafikk, eller egress, er ofte den posten som overrasker teams mest. Å laste data inn i alle tre tjenestene er gratis, men å hente det ut igjen koster penger, og prisen er ikke lik på tvers av leverandørene.
AWS S3 gir de første 100 GB utgående trafikk gratis hver måned, deretter 0,09 USD per GB til internett. Azure Blob Storage har ingen tilsvarende offisiell fri kvote i samme størrelse, men lander på 0,087 USD per GB etter eventuell fri sone, marginalt billigere enn AWS på selve GB-prisen. Google Cloud Storage er dyrest av de tre med 0,12 USD per GB til internett, rundt 33 prosent mer enn AWS sin listepris. For selskaper som flytter store datamengder ut av skyen regelmessig, for eksempel til CDN-er utenfor leverandørens eget nettverk eller til lokale servere, kan denne forskjellen alene avgjøre totalkostnaden.
Egress-kostnaden er også grunnen til at mange selskaper unngår å flytte store datamengder mellom skyleverandører i utgangspunktet. Når data først ligger hos én leverandør, blir det dyrt å flytte det ut igjen i stor skala, noe som er verdt å tenke på allerede når du velger leverandør for et nytt prosjekt.
Arkiv- og kald lagring: bindingstid og hentetid
Kald og arkivert lagring er billigst per GB, men kommer med to skjulte kostnader: bindingstid og hentetid. Bindingstiden bestemmer hvor lenge du må la data ligge i klassen før du kan slette eller flytte det uten straffegebyr. Som vist i spesifikasjonstabellen krever både AWS Glacier og Azure Cold en minimumsperiode på 90 dager, mens Google Coldline har samme krav. På det dypeste arkivnivået krever AWS og Azure 180 dager, mens Google Cloud Storage Archive krever hele 365 dager.
Hentetid er den andre faktoren. Når data ligger i en arkivklasse, kan du ikke hente det ut umiddelbart slik som fra standardklassen. AWS skiller mellom Glacier Instant Retrieval, som gir tilgang med millisekunders ventetid til en høyere GB-pris, og Glacier Flexible Retrieval eller Deep Archive, der henting tar fra timer til et helt døgn avhengig av hvor mye du er villig til å betale for hasteoppdrag. Azure og Google har lignende modeller, der Archive-klassen krever en eksplisitt gjenopprettingsoperasjon før dataene blir tilgjengelige igjen. Dette gjør arkivklassene godt egnet for data du sjelden trenger, som lovpålagte sikkerhetskopier, men dårlig egnet for data du kan trenge på kort varsel.
Ytelse: hva sier uavhengige benchmarker?
Prisliste er én ting, faktisk ytelse under last er noe annet. Uavhengige benchmarker av objektlagring er sjeldne fordi resultatene er svært følsomme for region, objektstørrelse, samtidighet og nettverksvei, men noen få publiserte tester gir et bilde av forskjellene.
En benchmark fra StorageReview sammenlignet Google Cloud Storage, Amazon S3 og Azure Blob Storage på tvers av objektstørrelser. Ved lesing av 4 KB-objekter var Google Cloud Storage 41 prosent raskere enn Amazon S3 og 25 prosent raskere enn Azure Blob Storage. På 128 MB-objekter var forskjellen enda tydeligere: Google hadde opptil 60 prosent lavere ventetid enn S3 og 50 prosent lavere ventetid enn Azure. På rene skriveoperasjoner av små objekter var forskjellen langt mindre, kun 2 til 5 prosent til Googles fordel.
En eldre, men uavhengig gjennomført test av utvikleren Sachin K. Agarwal sammenlignet nedlastingstid for et 100 MB-objekt fra alle tre tjenestene. Nedlasting fra Azure Blob Storage tok over 4 sekunder, mot rundt 1 sekund fra Google Cloud Storage, en forskjell på opptil 4 ganger for store objekter. Samtidig hadde Azure lavere opplastingsventetid for små objekter i samme test, noe som viser at ingen tjeneste vinner på alle scenarioer samtidig.
En tredje kilde, et benchmark fra lagringsselskapet Nasuni referert av Solutions Review, pekte i en annen retning: der kom Azure Blob Storage best ut sammenlignet med både S3 og Google Cloud Storage i en serie tester. Den offentlig tilgjengelige oppsummeringen gir ikke eksakte tall eller testår, men den bekrefter et mønster som går igjen i alle tre kildene: rangeringen mellom leverandørene endrer seg avhengig av objektstørrelse, operasjonstype og testmetode. Konklusjonen er at ingen av de tre tjenestene er konsekvent raskest, og at egne tester i din faktiske region og med dine egne objektstørrelser er det eneste pålitelige grunnlaget for en ytelsesbeslutning.
Ønsker du å teste selv, finnes det åpne benchmark-verktøy som warp fra MinIO-prosjektet og COSBench, som begge lar deg simulere lese- og skrivelast mot en objektlagringstjeneste over det ordinære S3-, Azure- eller GCS-APIet. Poenget med å kjøre egne tester er ikke å reprodusere tallene fra StorageReview eller Nasuni, men å måle ytelse med din egen objektstørrelse, samtidighet og nettverksvei, siden det er disse faktorene som i praksis avgjør hvordan brukerne dine opplever tjenesten.
API-kompatibilitet og verktøystøtte
AWS S3 sitt API har blitt en de facto standard i bransjen. En rekke andre lagringstjenester og selvhostede løsninger, blant annet MinIO, Wasabi og Backblaze B2, tilbyr S3-kompatible grensesnitt slik at eksisterende verktøy og biblioteker kan snakke med dem uten endringer. Det gjør at et team som allerede har bygget applikasjonslogikk mot S3-APIet, ofte kan bytte til en annen S3-kompatibel leverandør med minimale kodeendringer, mens en overgang til Azure Blob Storage eller Google Cloud Storage krever at klientkoden skrives om mot et annet SDK og en annen API-struktur.
Azure og Google har egne SDK-er for de fleste utbredte programmeringsspråk, inkludert Python, Java, Go, Node.js og .NET, på linje med AWS. Forskjellen ligger mer i økosystemet rundt: AWS har det klart største antallet tredjepartsverktøy for overvåking, sikkerhetskopiering og databehandling bygget spesifikt mot S3, ganske enkelt fordi tjenesten har eksistert lengst og har størst markedsandel av de tre. Det er verdt å vurdere allerede før du velger, siden det påvirker hvor mye egenutviklet integrasjonskode teamet ditt må vedlikeholde over tid.
Holdbarhet og driftssikkerhet
På ett punkt er de tre leverandørene identiske: alle publiserer 99,999999999 prosent holdbarhet, ofte omtalt som “elleve nitall”, for objekter lagret med standard redundans. Det betyr en teoretisk sannsynlighet for at et enkelt objekt går tapt på under én av hundre milliarder objekter i løpet av et år. Tallet er ikke det samme som tilgjengelighet, altså hvor ofte tjenesten faktisk svarer på en forespørsel, men det viser at alle tre bygger på flere kopier fordelt over fysisk adskilt infrastruktur.
Forskjellen ligger heller i hvor mange redundansalternativer hver tjeneste tilbyr. Azure Blob Storage har det bredeste utvalget med LRS, ZRS, GRS, RA-GRS, GZRS og RA-GZRS, som lar deg velge nøyaktig hvor mange kopier som holdes og hvor geografisk spredt de er. AWS S3 og Google Cloud Storage tilbyr færre, men enklere valg mellom regional og flerregional replikering. For organisasjoner med strenge krav til geografisk dataplassering, for eksempel innenfor EUs personvernregler, er detaljnivået i Azures redundansmodell en fordel, selv om det også gjør konfigurasjonen mer komplisert å sette opp riktig.
Sikkerhet og tilgangskontroll
Alle tre tjenester krypterer data i hvile som standard, uten at du trenger å konfigurere det selv. Forskjellen ligger i hvordan tilgangskontrollen er bygget opp. AWS S3 bruker IAM-policyer (Identity and Access Management) kombinert med bøttepolicyer og valgfrie tilgangskontrollister, et system som gir svært finmasket kontroll, men som samtidig er en vanlig kilde til feilkonfigurering når bøtter ved en feil blir gjort offentlig tilgjengelige. Azure Blob Storage bygger på Entra ID (tidligere Azure Active Directory) for identitetsstyring, kombinert med rollebasert tilgangskontroll (RBAC) og delte tilgangssignaturer (SAS-tokener) for midlertidig, tidsbegrenset tilgang. Google Cloud Storage bruker Identity and Access Management på samme måte som AWS, men med et enklere rollehierarki og tettere kobling mot Google Cloud sin sentrale prosjektstruktur.
For organisasjoner med krav til soveren sky eller europeisk dataplassering er det verdt å merke seg at alle tre nå tilbyr regioner i Europa med mulighet til å låse data til en spesifikk region eller flerregional sone innenfor EU. Ingen av tjenestene flytter data ut av valgt region automatisk, men standardinnstillingene og hvor lett det er å ved et uhell velge feil region, varierer. Det anbefales å sette opp automatiserte policyer, som AWS S3 Block Public Access, Azure sin “secure transfer required”-innstilling og Google sin organisasjonspolicy for offentlig tilgang, som en fast del av oppsettet uansett hvilken tjeneste du velger.
Fordeler og ulemper med hver tjeneste
AWS S3: fordeler og ulemper
- Fordel: Størst økosystem av tredjepartsverktøy og integrasjoner
- Fordel: Intelligent-Tiering flytter data automatisk uten manuell konfigurasjon
- Fordel: Lavest egress-terskel med 100 GB gratis per måned
- Ulempe: Høyest listepris på standardklassen av de tre
- Ulempe: Flest lagringsklasser å holde styr på, som kan gjøre valg av riktig klasse forvirrende
Azure Blob Storage: fordeler og ulemper
- Fordel: Billigst listepris på standard (Hot) lagring av de tre
- Fordel: Bredest utvalg av redundansalternativer for geografisk kontroll
- Fordel: Tett integrasjon med resten av Microsofts skyportefølje
- Ulempe: Dyrest på skriveoperasjoner sammenlignet med AWS og Google
- Ulempe: Færre uavhengige tredjepartsverktøy enn AWS-økosystemet
Google Cloud Storage: fordeler og ulemper
- Fordel: Enklest klassemodell med kun fire nivåer og samme API på tvers
- Fordel: Sterk integrasjon med BigQuery og Vertex AI for dataanalyse
- Fordel: Kan bytte lagringsklasse på et objekt uten å flytte det til ny bøtte
- Ulempe: Dyrest utgående trafikk av de tre tjenestene
- Ulempe: Lengst bindingstid på arkivklassen, 365 dager mot 180 hos konkurrentene
Fem bruksmønstre og hvilken tjeneste som passer best
I stedet for én fasit finnes det flere typiske bruksmønstre der valget mellom AWS S3, Azure Blob Storage og Google Cloud Storage bør styres av arbeidsmengden, ikke bare av listeprisen.
- Strømmetjeneste med mye videotrafikk: Høyt volum av utgående trafikk gjør at egress-prisen dominerer regningen. Azure sin lavere egress-pris på 0,087 USD per GB, kombinert med CDN-integrasjon, gjør den til et konkurransedyktig valg her, tett fulgt av AWS.
- Fintech-selskap med lovpålagt arkivering i sju år: Både AWS Glacier Deep Archive og Azure Archive har lavere GB-pris og kortere minimumsbinding (180 dager) enn Google Cloud Storage Archive (365 dager), noe som gir mer fleksibilitet dersom oppbevaringskravet endres underveis.
- SaaS-startup med brukeropplastede filer: Uforutsigbart tilgangsmønster passer godt med AWS S3 Intelligent-Tiering, som automatisk flytter sjelden brukte filer til billigere klasser uten manuell logikk i applikasjonen.
- Forskningsmiljø med store datasett for maskinlæring: Tett kobling mot BigQuery og Vertex AI gjør Google Cloud Storage naturlig for team som allerede kjører analyse- og treningspipeliner i Google Cloud.
- E-handelsplattform med produktbilder og global trafikk: Behovet for lav ventetid på små objekter i mange regioner samtidig favoriserer tjenesten som allerede er tettest koblet til resten av infrastrukturen din, siden nettverksvei ofte betyr mer enn ren lagringspris for brukeropplevelsen.
- Backup- og gjenopprettingsleverandør: Bredden i Azures redundansalternativer (LRS til RA-GZRS) gir finere kontroll over hvor mange geografisk adskilte kopier som holdes, noe som er verdifullt når kunder stiller egne krav til dataplassering.
Slik overvåker du lagringskostnaden løpende
Fordi kostnaden er satt sammen av flere komponenter, lagring, forespørsler og utgående trafikk, holder det ikke å se på én faktura ved månedsslutt for å forstå hva som driver kostnaden. Alle tre leverandørene har egne verktøy for dette: AWS Cost Explorer og S3 Storage Lens gir innsikt i hvilke bøtter og lagringsklasser som koster mest, Azure Cost Management + Billing gir tilsvarende oversikt for Blob Storage-kontoer, og Google Cloud sin Billing Reports-modul bryter ned kostnaden per bøtte og lagringsklasse i Google Cloud Storage.
Den enkeltfaktoren som oftest driver opp kostnaden mest uventet, er data som blir liggende i feil lagringsklasse. Et vanlig mønster er filer som er hyppig brukt de første ukene etter opplasting, men som deretter sjelden hentes ut igjen. Uten en livssyklusregel blir disse liggende i den dyre standardklassen på ubestemt tid. Alle tre tjenestene støtter automatiske livssyklusregler som flytter objekter til billigere klasser etter et gitt antall dager uten tilgang, og det er den enkeltinnstillingen som har størst effekt på totalregningen for de fleste team, uavhengig av hvilken av de tre tjenestene de bruker.
Et annet vanlig kostnadsproblem er ufullstendige flerdelte opplastinger (multipart uploads) som blir liggende og fortsetter å telle mot lagringsvolumet selv om opplastingen aldri ble fullført. AWS S3 lar deg sette opp en livssyklusregel som automatisk rydder opp i disse etter et gitt antall dager, og tilsvarende ryddemekanismer finnes hos både Azure og Google. Å sjekke at denne opprydningen faktisk er aktivert, er en av de enkleste kostnadsbesparelsene å hente ut uansett hvilken av de tre tjenestene du bruker. Sett den gjerne opp som en fast rutine ved oppsett av nye bøtter, i stedet for noe som ryddes opp i etterkant når fakturaen allerede har vokst seg stor.
Native overføringsverktøy fra leverandørene
Utover åpen kildekode-verktøy som rclone tilbyr alle tre leverandørene egne tjenester bygget spesifikt for storskala dataoverføring. AWS DataSync er laget for å flytte store datamengder inn og ut av S3 med innebygd validering og planlegging, og brukes ofte når kildedataene ligger i et lokalt datasenter eller hos en annen skyleverandør. Azure tilbyr Azure Storage Mover for nettverksbasert overføring og Azure Data Box for fysisk frakt av data når nettverksbåndbredden ikke strekker til for svært store volum. Google Cloud sin Storage Transfer Service er bygget for planlagte, tilbakevendende overføringer, blant annet direkte fra AWS S3 og Azure Blob Storage inn til Google Cloud Storage, uten at du trenger å bygge og vedlikeholde egne overføringsskript.
Valget mellom et åpen kildekode-verktøy og leverandørens egen tjeneste avhenger av skala og kompleksitet. For enkeltstående migreringer eller mindre datamengder er rclone raskt å sette opp og fungerer likt uansett hvilke to tjenester du flytter mellom. For gjentakende overføringer i produksjonsmiljø, eller når du trenger innebygd overvåking, varsling og automatisk gjenoppretting ved feil, er de native tjenestene som DataSync og Storage Transfer Service som regel mer robuste i lengden.
| Bruksmønster | Anbefalt tjeneste | Hovedgrunn |
|---|---|---|
| Strømmetjeneste med mye videotrafikk | Azure Blob Storage | Lavest egress-pris av de tre (0,087 USD/GB) |
| Lovpålagt arkivering med fast oppbevaringstid | AWS S3 / Azure Blob | Kortest bindingstid på arkivklasse (180 dager) |
| Brukeropplastede filer med uforutsigbar tilgang | AWS S3 | Intelligent-Tiering flytter klasse automatisk |
| Maskinlæring og dataanalyse i stor skala | Google Cloud Storage | Tett integrasjon med BigQuery og Vertex AI |
| Global e-handel med mange små objekter | Avhenger av eksisterende sky | Nettverksvei betyr mer enn ren lagringspris |
| Backup med strenge krav til geografisk plassering | Azure Blob Storage | Bredest utvalg av redundansalternativer |
Slik migrerer du mellom objektlagringstjenester
Å bytte leverandør, eller å kjøre flere leverandører side om side, krever en plan for selve dataoverføringen. Det finnes tre hovedtilnærminger: leverandørenes egne overføringstjenester, åpen kildekode-verktøy som synkroniserer direkte mellom skytjenester, og egenutviklede skript mot hver tjenestes API.
For mindre datamengder er det åpne kildekode-verktøyet rclone et vanlig valg, fordi det snakker med alle tre tjenestenes API-er gjennom samme kommandolinje-grensesnitt. Et typisk oppsett for å synkronisere en bøtte fra AWS S3 til Google Cloud Storage ser slik ut:
# Konfigurer begge tjenestene som eksterne mål i rclone
rclone config
# Synkroniser innhold fra en S3-bøtte til en GCS-bøtte
rclone sync s3remote:min-kildebotte gcsremote:mitt-malbotte --progress
# Verifiser at alt overførte data er identisk før du sletter kilden
rclone check s3remote:min-kildebotte gcsremote:mitt-malbotteFor større migreringer i produksjonsmiljø bør du planlegge i fire trinn. Først kartlegger du hvilke lagringsklasser hvert objekt ligger i, siden objekter i arkivklasser må gjenopprettes før de kan leses og overføres. Deretter beregner du egress-kostnaden fra kildetjenesten, siden denne ofte overstiger selve overføringsverktøyets kostnad. Så kjører du en første full synkronisering mens produksjonstrafikken fortsatt går mot den gamle tjenesten, etterfulgt av inkrementelle synkroniseringer for å fange opp endringer. Til slutt bytter du applikasjonens skriveretning til den nye tjenesten og lar en siste verifisering bekrefte at alle objekter, inkludert metadata og tilgangskontroll, er overført korrekt før den gamle bøtten slettes.
Mange organisasjoner velger i praksis å ikke migrere fullt ut, men i stedet kjøre en multisky-strategi der ny data skrives til én tjeneste mens gamle arkiver blir liggende hos den opprinnelige leverandøren. Det unngår den store engangskostnaden ved full egress, men krever at driftsteamet holder styr på hvor hvilke data faktisk ligger.
Verdikt: hvilken tjeneste bør du velge?
Det finnes ikke ett riktig svar, men tallene peker i klare retninger for ulike behov. Ser du kun på ren lagringspris for aktivt brukte data, vinner Azure Blob Storage med 0,0184 USD per GB, rundt 25 prosent billigere enn AWS S3 sin standardklasse. Ser du på arkivering, er AWS Glacier Deep Archive og Azure Archive identiske på pris, men AWS og Azure krever begge kortere bindingstid (180 dager) enn Google Cloud Storage (365 dager), noe som gjør de to førstnevnte mer fleksible for arkiver der oppbevaringskravet kan endre seg.
For arbeidsmengder med mye utgående trafikk er rekkefølgen Azure (0,087 USD/GB), AWS (0,09 USD/GB) og Google Cloud Storage (0,12 USD/GB), der Google er klart dyrest. På forespørselskostnad ligger AWS og Google likt på skriving og lesing, mens Azure ligger rundt 30 prosent høyere på skriveoperasjoner. Ytelsesmessig finnes det ikke én vinner: uavhengige tester fra StorageReview og Sachin K. Agarwal peker på Google Cloud Storage som raskest på lesing av både små og store objekter, mens Nasunis test pekte på Azure som sterkest samlet sett. Konklusjonen basert på tallene i denne artikkelen: velg Azure Blob Storage hvis standardlagring og lav egress-kostnad er hovedprioriteten, velg AWS S3 hvis du trenger det bredeste økosystemet og mest fleksibel arkivering, og velg Google Cloud Storage hvis arbeidsmengden allerede lever i Google Cloud og leseytelse på små objekter er kritisk.
Sjekkliste før du velger leverandør
Før du signerer en avtale eller bygger arkitekturen rundt én av de tre tjenestene, er det noen spørsmål som er verdt å stille konkret opp mot egen arbeidsmengde, ikke bare mot listeprisen.
- Hvor mye data forventer du å hente ut (egress) hver måned, og hvordan slår det ut med prisene på 0,09 USD (AWS), 0,087 USD (Azure) og 0,12 USD (Google Cloud) per GB?
- Hvor lenge må arkiverte data ligge før de kan slettes, og passer det med bindingstiden på 180 dager hos AWS og Azure eller 365 dager hos Google Cloud?
- Hvor mange små objekter og skriveoperasjoner genererer arbeidsmengden din, gitt at Azure ligger rundt 30 prosent høyere enn AWS og Google på skriveforespørsler?
- Hvilken skyleverandør kjører resten av infrastrukturen din allerede, og hvor mye egenutviklet integrasjonskode sparer du ved å bruke samme leverandørs objektlagring?
- Har organisasjonen krav til geografisk dataplassering som gjør Azures brede utvalg av redundansalternativer mer verdifullt enn en lavere listepris?
Ofte stilte spørsmål
Hvilken skytjeneste er billigst for lagring?
På standardklassen er Azure Blob Storage billigst med 0,0184 USD per GB per måned, mot 0,020 USD hos Google Cloud Storage og 0,023 USD hos AWS S3. På den dypeste arkivklassen er AWS og Azure billigst og like på pris, med 0,00099 USD per GB, mens Google Cloud Storage Archive ligger på 0,0012 USD.
Hva er hovedforskjellen mellom S3, Azure Blob og Google Cloud Storage?
Alle tre er objektlagringstjenester med lignende grunnfunksjonalitet, men de skiller seg på antall lagringsklasser, prising av forespørsler og utgående trafikk, bindingstid på kalde klasser, og hvilket skyøkosystem de er tettest integrert med.
Hvor lenge må data ligge i arkivlagring før jeg kan slette den uten straffegebyr?
Hos AWS Glacier Deep Archive og Azure Archive er minimumsperioden 180 dager. Hos Google Cloud Storage Archive er kravet 365 dager. Sletter eller flytter du data før denne perioden er ute, belastes du for resten av bindingstiden.
Hvor raskt kan jeg hente ut data fra kald lagring?
Hentetiden varierer fra millisekunder til et helt døgn avhengig av tjeneste og hvor mye du betaler for hasteoppdrag. AWS Glacier Instant Retrieval gir tilgang umiddelbart mot en høyere GB-pris, mens Glacier Flexible Retrieval og Deep Archive krever en eksplisitt gjenopprettingsoperasjon som kan ta flere timer.
Hvilken tjeneste har raskest ytelse ifølge uavhengige tester?
Det finnes ikke ett entydig svar. En StorageReview-benchmark og en uavhengig test av Sachin K. Agarwal pekte begge på Google Cloud Storage som raskest på lesing av både små og store objekter. Et benchmark fra Nasuni, referert av Solutions Review, pekte derimot på Azure Blob Storage som sterkest samlet. Resultatet avhenger sterkt av region, objektstørrelse og testmetode.
Kan jeg migrere data mellom skytjenester uten nedetid?
Ja, ved å kjøre en første full synkronisering mens produksjonen fortsatt går mot kildesystemet, etterfulgt av inkrementelle synkroniseringer med verktøy som rclone, kan du bytte skriveretning til den nye tjenesten uten avbrudd for sluttbrukerne.
Hva koster det å hente ut data fra hver tjeneste?
AWS S3 gir 100 GB gratis per måned og tar deretter 0,09 USD per GB. Azure Blob Storage tar 0,087 USD per GB. Google Cloud Storage er dyrest med 0,12 USD per GB til internett, rundt 33 prosent mer enn AWS sin listepris.
Er dataene mine sikre mot tap hos alle tre leverandørene?
Alle tre publiserer samme holdbarhetstall, 99,999999999 prosent, for objekter lagret med standard redundans. Nivået på geografisk spredning og antall kopier kan du selv justere, spesielt hos Azure Blob Storage som tilbyr flest redundansalternativer av de tre.
Hvordan unngår jeg overraskelser på skyfakturaen for lagring?
Sett opp automatiske livssyklusregler som flytter data til billigere klasser etter et gitt antall dager uten tilgang, ryd opp i ufullstendige flerdelte opplastinger, og følg med på kostnadsoversikter som AWS Cost Explorer, Azure Cost Management eller Google Cloud sin Billing Reports-modul. Feil lagringsklasse er den vanligste årsaken til unødvendig høye regninger hos alle tre leverandørene.
Kan jeg bruke flere av de tre tjenestene samtidig?
Ja. Mange organisasjoner kjører en multisky-strategi der ny data skrives til én tjeneste, mens eldre arkiver blir liggende hos en annen leverandør for å unngå den store engangskostnaden ved å flytte alt på én gang. Dette krever verktøy som rclone eller leverandørenes egne overføringstjenester for å holde oversikt over hvor de ulike dataene faktisk befinner seg.
