Sommeren 2026 har vært den mest hektiske perioden noensinne for serverløse containere. Google Cloud rullet ut generell tilgjengelighet for Cloud Run worker pools 27. august, mens AWS har oppdatert Fargate-prisene sine flere ganger gjennom året. For team i Norge og Norden som skal velge mellom AWS Fargate og Google Cloud Run, er spørsmålet ikke lenger “hvilken er raskest å sette opp”, men “hvilken koster minst og skalerer best for akkurat vår arbeidsmengde”. Denne artikkelen går gjennom pris, ytelse, arkitektur og migreringssteg, med tall hentet fra offisielle prissider og oppdaterte driftsrapporter fra 2026.

Hva er AWS Fargate og Google Cloud Run?

AWS Fargate er en kjøremotor for containere som fjerner behovet for å administrere EC2-noder bak Amazon ECS eller Amazon EKS. Du definerer en oppgave (task) med et bestemt antall vCPU og GB minne, og AWS drifter den underliggende infrastrukturen. Fargate ble lansert i 2017 og har siden blitt AWS sitt svar på “kubernetes uten noder”. Full oversikt over ressurstrinn og pris finnes på AWS sin offisielle prisside for Fargate.

Google Cloud Run er Googles fullstendig administrerte plattform for containere, bygget på det åpne Knative-rammeverket, og beskrives av Google selv som en tjeneste for on-demand-kompilering uten servere å administrere. Cloud Run startet som en ren HTTP-tjeneste, men har i 2026 blitt utvidet kraftig: i juli fikk plattformen sandkasser for kjøring av upålitelig kode (for eksempel kode generert av AI-agenter), og i slutten av august ble worker pools allment tilgjengelig for asynkrone jobber som ikke trenger en HTTP-inngang. Cloud Run har også fått automatisk regional feilhåndtering med trafikkomdirigering på sekunder, ifølge Googles egne driftsnotater fra sommeren 2026.

Det er verdt å understreke hvor forskjellig de to plattformene selger seg selv til utviklere. AWS omtaler Fargate som en kjøretype under et etablert orkestreringslag, mens Google har gjort et bevisst poeng av å bygge Cloud Run som “compute for alt”, inkludert AI-arbeidsmengder. Denne forskjellen i filosofi forklarer mye av hvorfor de to plattformene passer ulikt godt til ulike team, uavhengig av rene tekniske spesifikasjoner.

Kort sagt: begge plattformene løser det samme grunnleggende problemet (kjør en container uten å tenke på servere), men de har ulik opprinnelse. Fargate er compute-laget under ECS/EKS. Cloud Run er en selvstendig, hendelsesdrevet plattform som i økende grad tar over oppgaver som tidligere krevde Kubernetes eller Cloud Functions.

Spesifikasjoner side ved side: Fargate mot Cloud Run

Tabellen under stiller opp de tekniske egenskapene som betyr mest når man skal velge plattform for et produksjonsmiljø.

EgenskapAWS FargateGoogle Cloud Run
Lanseringsår20172019
Underliggende orkestreringAmazon ECS eller Amazon EKSKnative (åpen kildekode)
Maks vCPU per instans16 vCPU (opptil 32 vCPU med utvidede minnealternativer)8 vCPU per instans (standard konfigurasjon)
Maks minneOpptil 120 GB ved 16 vCPU, høyere ved 32 vCPUOpptil 32 GB per instans
Gratis lagringsplass per oppgave20 GB ephemeral storage inkludertIkke separat lagringskvote, bruker instansminne
FaktureringsgranularitetPer sekund, minimum 1 minuttPer sekund, ingen fast minimum
Kontrollplan-kostnad$0 via ECS, $0,10/time via EKS (~$73/mnd)$0, ingen klyngeavgift
Støtte for asynkrone jobberJa, via ECS-oppgaver og BatchJa, worker pools (GA fra 27. august 2026)
Multiregion høy tilgjengelighetManuell oppsett via flere ECS-tjenesterAutomatisk regional failover (fra sommeren 2026)
Sandkasse for upålitelig kodeKrever egen konfigurasjon av IAM og nettverkInnebygd sandkassefunksjon (juli 2026)
ARM-støtteJa, Graviton-prosessorer (ca. 20 % billigere)Ja, via Tau T2A-baserte instanser
Kald start (typisk container)Sekunder, avhenger av images-størrelseUnder ett sekund til noen sekunder for optimaliserte images
Nordiske datasenterregionereu-north-1 (Stockholm), eu-west-1 (Irland)europe-north1 (Finland), europe-west1 (Belgia)

Legg merke til at Fargate har et klart fortrinn på rå kapasitet per instans, mens Cloud Run i 2026 har hentet inn mye av forspranget på driftsfunksjoner som failover og sandkasser. For team som kjører tunge batch-jobber med høyt minnebehov, er Fargate fortsatt førstevalget. For team som vil ha “null oppsett” og innebygd robusthet, trekker Cloud Run foran.

Prissammenligning: Hva koster det egentlig?

Prising er der de to plattformene skiller seg mest fra hverandre i praksis. AWS Fargate fakturerer separat for vCPU-timer og GB-minnetimer, mens Cloud Run i økende grad markedsføres som en helhetlig pay-per-use-modell. Tallene under er hentet fra AWS sin offisielle prisside og Google Clouds egne blogginnlegg fra 2026.

Ressurs / scenarioAWS FargateGoogle Cloud Run
vCPU-time, Linux/x86 (us-east-1)$0,04048Inkludert i sammensatt pris per instans
vCPU-time, Linux/ARM (Graviton/Tau)$0,03238 (ca. 20 % billigere)Rabattert pris for Tau T2A-baserte instanser
GB-minnetime (us-east-1)$0,004445Inkludert i sammensatt pris per instans
vCPU-time, EU-region (eu-west-1)$0,04556 (ca. 12-13 % dyrere enn US)Regionpriser varierer, typisk 5-15 % over US-pris
Kontinuerlig instans, 1 vCPU / 1 GiB, 30 dagerCa. $35,74/mnd on-demand (1 vCPU / 2 GB-konfigurasjon)Ca. $5,70 for 30 dager sammenhengende drift (Google Cloud-blogg, juli 2026)
Fargate Spot-rabattOpptil 70 % rabatt på on-demand-prisIngen direkte spot-modell, men skalering til null
Compute Savings PlansOpptil 50 % rabatt ved commitmentCommitted use-rabatter tilgjengelig separat
Ekstra lagringsplass utover gratiskvote$0,000111 per GB-timeIkke separat lagringsgebyr for standard bruk
Kontrollplan (EKS vs. Cloud Run)$0,10/time for EKS-klynge (~$73/mnd)$0, ingen klyngeavgift
Skalering til null ved inaktivitetKrever manuell konfigurasjon eller Fargate SpotStandard oppførsel, betaler kun ved forespørsler

Det interessante her er hvor forskjellig de to modellene straffer ulike arbeidsmønstre. En kontinuerlig arbeidsmengde på 1 vCPU og rundt 1 GB minne kostet i overkant av $35 i måneden på Fargate on-demand, mot i overkant av $5 for en tilsvarende Cloud Run-instans som kjørte sammenhengende i 30 dager, ifølge Googles eget regneeksempel fra 31. juli 2026. Det er en femdobling i pris til fordel for Cloud Run for denne spesifikke, alltid-på-arbeidsmengden. Men bildet snur fort for team som kjører spisse, korte arbeidsmengder med Fargate Spot: der kan rabatten på opptil 70 % gjøre AWS til det billigste alternativet totalt sett.

Ytelsesbenchmarks fra tre uavhengige kilder

Fordi hverken AWS eller Google publiserer direkte sammenlignende ytelsestall mot hverandre, må man se til uavhengige driftsteam og kostnadsanalytikere for å forstå hvordan plattformene oppfører seg i praksis. Tre kilder skiller seg ut fra 2026-analyser av dette markedet.

Kostnadsanalysebyrået bak LeanOps publiserte i mai 2026 en detaljert gjennomgang av Fargate-priser på tvers av regioner, og fant at eu-west-1 (Irland) lå på $0,04556 per vCPU-time mot $0,04048 i us-east-1, en forskjell på rundt 12-13 prosent som ofte overses når team budsjetterer basert på amerikanske referansepriser. Samme analyse viste at et standard 24/7-oppsett med 1 vCPU og 2 GB minne kostet i overkant av $35 i måneden på Fargate on-demand, før eventuelle rabatter.

En separat gjennomgang fra driftsbloggen Techoral, publisert i juni 2026, fokuserte på kostnadsoptimalisering og fant at Fargate Spot kunne kutte vCPU-prisen fra $0,04048 til rundt $0,01214 per time, en besparelse på nesten 70 prosent for arbeidsmengder som tåler avbrudd. Den samme kilden pekte på at billing skjer per sekund med et minimum på ett minutt, noe som gir liten forskjell for langvarige oppgaver, men kan slå negativt ut for svært korte, hyppige jobber.

Den tredje kilden, en sammenligning publisert av driftsanalytikere hos Tech Insider i juni 2026, satte Fargate opp mot både EC2 og EKS, og konkluderte med at Fargate på ren compute kan koste opptil dobbelt så mye som tilsvarende EC2-kapasitet for identisk container, men at besparelsen i administrasjonstid ofte gjør det lønnsomt likevel for team uten dedikert plattformkapasitet. Google Cloud sin egen driftsblogg oppgir på sin side at en kontinuerlig Cloud Run-instans med 1 vCPU og 1 GiB minne koster omkring $5,70 for 30 sammenhengende dager, et tall som er hentet direkte fra selskapets eget regneeksempel fra 31. juli 2026, ikke fra en tredjepartsanalyse.

Ytelsestall for serverløse containere er ellers notorisk vanskelig å sammenligne rettferdig, fordi resultatet avhenger enormt av image-størrelse, språk og oppstartslogikk i applikasjonen. Likevel finnes det noen mønstre som går igjen på tvers av flere uavhengige tester og driftsrapporter fra 2026.

  • Cloud Run har historisk hatt et fortrinn på kaldstart for lette, HTTP-baserte tjenester, spesielt for containere bygget med minimalt basisbilde (distroless eller Alpine).
  • Fargate-oppgaver bruker typisk noen sekunder lenger på å bli klare, delvis fordi ECS/EKS-orkestreringslaget legger til et ekstra planleggingssteg før containeren faktisk starter.
  • For arbeidsmengder med jevn, forutsigbar trafikk (batch-prosessering, ETL-jobber, bakgrunnstjenester) er forskjellen i oppstartstid nesten irrelevant, siden containeren uansett kjører kontinuerlig.
  • Googles nye worker pools (GA 27. august 2026) er spesifikt designet for pull-baserte, ikke-HTTP arbeidsmengder, og lukker et gap Cloud Run tidligere hadde mot Fargate på denne typen jobber.
  • Fargates støtte for opptil 32 vCPU og 244 GB minne i én oppgave gir et klart fortrinn for minnetunge arbeidsmengder som store databehandlingsjobber eller AI-inferens med store modeller lastet i minnet.

Konklusjonen fra disse mønstrene er ikke at den ene plattformen er “raskere” i alle tilfeller. Det er heller slik at Cloud Run vinner på oppstartstid for lette, hendelsesdrevne tjenester, mens Fargate vinner på rå kapasitet for tunge, langvarige arbeidsmengder. Team bør teste med sin egen container og sitt eget trafikkmønster før de konkluderer.

Arkitektur: hvordan de to plattformene er bygget opp

AWS Fargate: et lag under ECS eller EKS

Fargate er strengt tatt ikke en frittstående tjeneste. Den er en kjøretype (launch type) du velger inne i enten Amazon ECS eller Amazon EKS. Det betyr at alt av nettverksoppsett, IAM-roller, service discovery og logging går gjennom det samme rammeverket som du ville brukt for EC2-baserte containere, bare uten at du selv administrerer de underliggende maskinene. For team som allerede har investert i ECS-oppsett, eller som trenger EKS for å kjøre standard Kubernetes-manifester, gir dette en jevn overgang. Ulempen er at man arver kompleksiteten til ECS/EKS-modellen, inkludert oppsett av task-definisjoner, cluster-konfigurasjon og IAM-policyer som må vedlikeholdes separat.

Google Cloud Run: en selvstendig, hendelsesdrevet plattform

Cloud Run er bygget som en frittstående tjeneste fra grunnen av, med Knative som åpen kildekode-fundament. Du sender inn et container-image, og Cloud Run håndterer resten: ruting, skalering, HTTPS-terminering og nå også multiregional failover. Fra april 2026 har Google Cloud eksplisitt posisjonert Cloud Run som plattformen for “alt fra vibe-kodede apper til AI-modeller og agenter”, ifølge selskapets egen omtale fra Google Cloud Next ’26. Dette gjenspeiles i utvidelsene gjennom sommeren: sandkasser for upålitelig AI-generert kode i juli, og worker pools for asynkrone jobber i august. Ulempen er at Cloud Run har mindre finkornet kontroll over nettverksisolasjon og ressursallokering sammenlignet med et fullt konfigurert ECS/EKS-oppsett.

På nettverkssiden krever begge plattformene ekstra oppmerksomhet dersom containeren skal snakke med ressurser i et privat nettverk, som en database uten offentlig IP. Fargate-oppgaver plasseres direkte inn i en VPC, med subnett og sikkerhetsgrupper som styrer trafikken på samme måte som for EC2-instanser, noe som gir presis kontroll men også krever at teamet forstår VPC-modellen godt. Cloud Run kobles til et privat nettverk gjennom en egen VPC-connector eller direkte VPC-utgang (Direct VPC egress), en funksjon som har blitt gradvis mer fleksibel gjennom 2025 og 2026. For team med enkle nettverksbehov er Cloud Run sin modell raskere å sette opp, mens team med komplekse krav til segmentering, som flere lag med interne tjenester og strenge brannmurregler, ofte finner Fargate sin tette VPC-integrasjon mer forutsigbar å forvalte over tid.

Sikkerhet og containersikkerhet

Begge plattformene håndterer den underliggende infrastruktursikkerheten (patching av vertsmaskiner, isolasjon mellom kunder), men ansvarsdelingen for applikasjonslaget ser litt annerledes ut. På Fargate styres tilgang gjennom IAM-roller knyttet til hver task-definisjon, og nettverksisolasjon håndteres via VPC-er, sikkerhetsgrupper og eventuelt et service mesh dersom man kjører EKS. Dette gir mye kontroll, men krever også at teamet forstår IAM-modellen godt for å unngå overprivilegerte roller.

Cloud Run sin nye sandkassefunksjon fra juli 2026 er spesielt relevant for team som eksperimenterer med AI-agenter som genererer og kjører kode automatisk. Ved å isolere kjøringen i en sikker sandkasse reduseres risikoen for at feilaktig eller ondsinnet generert kode får tilgang til andre ressurser i prosjektet. For regulerte bransjer i Norden, som finans og helse, er dette en funksjon verdt å følge med på ettersom den modnes.

Begge plattformer krever fortsatt at teamet selv holder container-images oppdatert med sikkerhetsoppdateringer i base-imaget. Verken Fargate eller Cloud Run patcher automatisk sårbarheter inne i applikasjonslaget av containeren, det er fortsatt utviklerens ansvar å bygge på oppdaterte, minimale basisbilder og skanne images for kjente sårbarheter før produksjonssetting. Dette skillet mellom infrastruktursikkerhet (leverandørens ansvar) og applikasjonssikkerhet (kundens ansvar) er identisk på begge plattformer, og bør inngå i enhver sikkerhetsvurdering uavhengig av hvilken av de to man ender opp med å velge.

Overvåkning, logging og feilsøking

Driftsteam undervurderer ofte hvor mye tid som går med til å sette opp overvåkning riktig, og dette er et område hvor de to plattformene krever ulik tilnærming. Fargate-oppgaver logger som standard til Amazon CloudWatch Logs, og metrikker som CPU- og minnebruk er tilgjengelige gjennom CloudWatch Container Insights. Skal man ha detaljert sporing av enkeltforespørsler på tvers av mikrotjenester, må man typisk sette opp AWS X-Ray eller en tredjeparts observability-løsning separat, noe som legger til enda et lag konfigurasjon.

Cloud Run er tettere integrert med Google Cloud sin operations-pakke fra dag én. Logger, metrikker og sporing samles automatisk i Cloud Logging og Cloud Monitoring uten at man trenger å legge til en egen agent i containeren. For team som allerede bruker Grafana eller Prometheus, støtter begge plattformene eksport av metrikker til disse verktøyene, men Cloud Run krever i praksis mindre oppsett for å komme i gang med grunnleggende observability.

Feilsøking i produksjon skiller seg også noe. På Fargate kan man ikke koble seg direkte inn i en kjørende container med SSH, men AWS tilbyr `ecs execute-command` for å åpne et begrenset shell inn i en kjørende oppgave til feilsøkingsformål. Cloud Run tilbyr ikke tilsvarende direkte tilgang til kjørende instanser i det hele tatt, av sikkerhetsmessige årsaker knyttet til plattformens hendelsesdrevne modell, noe som betyr at feilsøking må skje gjennom logger og lokal reproduksjon av feilen i større grad enn på Fargate.

Fem virkelighetsnære eksempler fra drift

For å gjøre sammenligningen konkret er det nyttig å se på typiske driftsscenarioer slik de faktisk ser ut i mellomstore nordiske organisasjoner. Eksemplene under er hverdagslige mønstre gjenkjennelig fra driftsteam i regionen, ikke enkelttilfeller fra navngitte selskaper, men de illustrerer hvordan kostnadene i tabellene over slår ut i praksis.

  • Betalingsintegrasjon hos en nettbutikk: en tjeneste som validerer betalinger har svært spiky trafikk rundt lønningsdager og kampanjer. På Cloud Run skalerer tjenesten automatisk opp i disse periodene og ned til null utenom, mens et tilsvarende Fargate-oppsett krever forhåndsdefinerte skaleringsregler for å unngå unødvendig kjøretid.
  • Bildekomprimering for et medieselskap: en bakgrunnsjobb som komprimerer opplastede bilder kjører i korte, intensive rykk. Med Cloud Run sine worker pools, tilgjengelig fra 27. august 2026, kan denne jobben kjøre pull-basert uten å måtte eksponere et HTTP-endepunkt, noe som tidligere krevde en separat Kubernetes-jobb eller Fargate-task.
  • Regnskapsberegning ved månedsslutt for et fintech-selskap: en tung batch-jobb som krever mye minne i korte, forutsigbare vinduer hver måned. Her henter Fargate ut sitt fortrinn med støtte for opptil 32 vCPU og 244 GB minne, langt utover hva en enkelt Cloud Run-instans kan tilby.
  • Intern API for et logistikkselskap med kontor i flere nordiske land: tjenesten må være tilgjengelig i flere regioner samtidig. Cloud Run sin automatiske regionale failover, innført sommeren 2026, reduserer behovet for at driftsteamet manuelt konfigurerer redundans på tvers av regioner slik man må med flere ECS-tjenester på Fargate.
  • Sandkasse-kjøring av AI-generert kode hos et programvareselskap: et team som lar en AI-agent generere og teste kodeendringer automatisk trenger isolasjon mot resten av infrastrukturen. Cloud Run sin sandkassefunksjon fra juli 2026 er bygget spesifikt for denne typen upålitelig, automatisk generert kode.

Fem konkrete brukstilfeller: hvem bør velge hva?

Valget mellom Fargate og Cloud Run avhenger sjelden av en enkelt faktor. Her er fem realistiske scenarioer og hvilken plattform som passer best i hvert tilfelle.

  • API-backend med sporadisk trafikk (f.eks. en intern SaaS-tjeneste for et nordisk fintech-selskap): Cloud Run er billigere fordi tjenesten skalerer til null mellom forespørslene, og du unngår kontinuerlig fakturering for ledig kapasitet.
  • Tungt batch-jobb-pipeline med høyt minnebehov (databehandling for et logistikkselskap): Fargate vinner takket være støtte for opptil 32 vCPU og 244 GB minne i én oppgave, langt utover det Cloud Run tilbyr per instans.
  • Team som allerede kjører Kubernetes-manifester i produksjon: EKS med Fargate gir en naturlig overgang uten å måtte omskrive alt til Cloud Run sin modell, selv om det koster ekstra i kontrollplan-avgift.
  • Bakgrunnsjobber som leser fra en kø (bildeprosessering, e-postutsendelse): Cloud Run sine nye worker pools (GA august 2026) er skreddersydd for akkurat denne pull-baserte, ikke-HTTP arbeidsmengden.
  • Multiregional tjeneste med krav om høy oppetid på tvers av Norden og resten av Europa: Cloud Run sin automatiske regionale failover, med trafikkomdirigering på sekunder, krever mindre manuelt arbeid enn å sette opp tilsvarende redundans med flere ECS-tjenester på Fargate.

Fordeler og ulemper med AWS Fargate

Fargate sin største styrke er fleksibiliteten i ressursallokering og den tette integrasjonen med resten av AWS-økosystemet. For team som allerede er dypt investert i AWS, er dette ofte et naturlig valg.

FordelerUlemper
Opptil 32 vCPU og 244 GB minne per oppgaveKrever ECS eller EKS som orkestreringslag, ikke frittstående
Fargate Spot gir opptil 70 % rabatt for tolerante arbeidsmengderEKS-kontrollplan koster $0,10/time (~$73/mnd) på toppen
Dyp integrasjon med IAM, VPC og resten av AWSSkalering til null krever ekstra konfigurasjon
Graviton (ARM) gir ca. 20 % lavere pris per vCPU-timeNoe lengre kaldstart enn Cloud Run for lette HTTP-tjenester
20 GB gratis ephemeral storage inkludert per oppgaveEkstra lagring over kvoten faktureres separat

Fordeler og ulemper med Google Cloud Run

Cloud Run sin styrke ligger i enkelheten og de nye robusthetsfunksjonene som har kommet på plass gjennom 2026. Ulempen er en lavere kapasitetstak per instans sammenlignet med Fargate.

FordelerUlemper
Ingen klyngeavgift, $0 i kontrollplan-kostnadMaks 8 vCPU og 32 GB minne per instans (standard)
Skalerer til null som standardoppførselMindre finkornet nettverkskontroll enn full VPC-oppsett
Automatisk multiregional failover fra sommeren 2026Worker pools er en relativt ny funksjon (GA august 2026), mindre driftserfaring i markedet ennå
Innebygd sandkasse for AI-generert/upålitelig kode (juli 2026)Færre alternativer for svært spesialisert maskinvarekonfigurasjon
Betydelig lavere kostnad for alltid-på, lette arbeidsmengder (ca. $5,70/mnd i Googles eksempel)Tettere bundet til Google Cloud sitt økosystem for avanserte nettverksbehov

Utvikleropplevelse og lokal testing

En ofte undervurdert faktor i valget mellom de to plattformene er hvor raskt et team kan gå fra kode til kjørende tjeneste i et testmiljø. Cloud Run støtter lokal kjøring via standard Docker-verktøy, og et image som fungerer lokalt kan i de fleste tilfeller rulles rett ut med `gcloud run deploy` uten ytterligere konfigurasjon. Fargate krever derimot at man først definerer en task-definisjon og eventuelt en tjeneste i ECS eller EKS, noe som betyr flere trinn før man ser containeren kjøre i skyen, selv om selve utviklingen av applikasjonskoden er identisk.

For team som jobber tett med CI/CD-pipeliner er begge plattformene godt støttet av standardverktøy som GitHub Actions og GitLab CI. Forskjellen ligger mer i antall ressurser som må defineres i infrastructure-as-code-verktøy som Terraform: en Cloud Run-tjeneste kan typisk beskrives i færre linjer enn et tilsvarende ECS-oppsett med task-definisjon, tjeneste, klynge og eventuelt en Application Load Balancer. Dette er ikke i seg selv et argument for at det ene er teknisk overlegent, men det er en reell faktor for hvor raskt et lite team kan komme i produksjon.

Datasuverenitet og etterlevelse for norske virksomheter

For norske og nordiske selskaper som håndterer person- eller helseopplysninger, er spørsmålet om hvor dataene faktisk befinner seg minst like viktig som pris og ytelse. Begge skyleverandørene har regioner lokalisert i Norden eller nærliggende EU/EØS-land: AWS med eu-north-1 i Stockholm og eu-west-1 i Irland, Google Cloud med europe-north1 i Finland og europe-west1 i Belgia. Å velge riktig region er det første steget, men det er ikke tilstrekkelig alene, siden kontrollplan og enkelte støttetjenester i noen tilfeller fortsatt kan involvere databehandling utenfor den valgte regionen.

Google har gjennom 2026 fortsatt å bygge ut funksjoner som er relevante for regulerte bransjer, inkludert sandkasse-isolasjon for upålitelig kode, beskrevet i selskapets offisielle driftsnotater for Google Cloud. AWS på sin side gir finkornet kontroll over nettverksisolasjon gjennom VPC-er og sikkerhetsgrupper, noe som kan være en fordel for virksomheter med strenge interne krav til nettverkssegmentering utover det som følger av standard skyleverandørkonfigurasjon. Uansett plattform bør norske virksomheter gjennomføre en egen vurdering av databehandleravtale og underleverandørkjede før produksjonssetting, uavhengig av hvilken av de to plattformene som velges.

Migreringsguide: fra Fargate til Cloud Run (eller motsatt)

Å bytte plattform for containeriserte arbeidsmengder er sjelden en ren løft-og-flytt-jobb, men det er heller ikke en fullstendig omskriving. Her er stegene de fleste team følger.

  1. Kartlegg dagens ressursbruk: noter faktisk vCPU- og minnebruk per container over minst to uker, ikke bare det som er allokert i task-definisjonen.
  2. Sjekk maksgrensene på målplattformen: hvis arbeidsmengden trenger mer enn 8 vCPU eller 32 GB minne, er ren Cloud Run trolig ikke tilstrekkelig uten omstrukturering.
  3. Bygg om container-imaget til å være plattformnøytralt: unngå avhengigheter til AWS-spesifikke metadata-endepunkter eller Google-spesifikke miljøvariabler direkte i koden.
  4. Flytt hemmeligheter og konfigurasjon til plattformens secret manager (AWS Secrets Manager eller Google Secret Manager) i stedet for å bake dem inn i imaget.
  5. Sett opp tilsvarende IAM/service-konto-rettigheter på målplattformen, med minste nødvendige privilegium som prinsipp.
  6. Konfigurer skaleringsregler: Fargate krever eksplisitt oppsett for å skalere til null, mens dette er standard i Cloud Run.
  1. Test kaldstart og responstid under realistisk last før du bytter produksjonstrafikk, siden oppstartsprofilen ofte endrer seg mellom plattformene.
  2. Sett opp logging og overvåkning på ny plattform (CloudWatch for AWS, Cloud Logging/Monitoring for Google) før migrering, ikke etter.
  3. Flytt trafikk gradvis med en vektet DNS- eller lastbalanseringsstrategi, ikke en direkte “big bang”-omkobling.
  4. Behold den gamle plattformen aktiv i minst én driftssyklus (typisk 1-2 uker) som fallback før du dekommisjonerer den.
  5. Sammenlign faktisk faktura fra begge plattformer for samme trafikkvolum før du regner migreringen som fullført og lønnsom.
  6. Dokumenter forskjellene i driftsrutiner for teamet, spesielt rundt feilsøking og skalering, siden disse verktøyene ikke er identiske mellom AWS og Google Cloud.

FinOps-perspektivet: hva bør norske team følge med på?

For finansavdelinger og FinOps-ansvarlige i norske og nordiske selskaper er regionprising et undervurdert element i denne sammenligningen. AWS sine EU-regioner, inkludert eu-west-1 (Irland) og eu-north-1 (Stockholm), ligger typisk 10-30 % over prisene i us-east-1, ifølge flere uavhengige kostnadsanalyser publisert i 2026. Dette betyr at et Fargate-oppsett som ser rimelig ut basert på amerikanske prislister, fort blir dyrere enn forventet når man faktisk kjører i en europeisk region av hensyn til datalagringskrav eller GDPR.

Cloud Run sin prismodell, med fravær av separat kontrollplan-avgift og skalering til null som standard, gjør det generelt enklere å forutsi kostnader for arbeidsmengder med varierende trafikk. For selskaper som allerede bruker FinOps-praksis til å overvåke skyforbruk, anbefales det å sette opp kostnadsvarsler per tjeneste fra dag én, uavhengig av hvilken plattform som velges, slik at uventede kostnadstopper fanges opp raskt.

Et konkret FinOps-tiltak som fungerer godt uavhengig av plattform, er å tagge hver enkelt tjeneste eller task-definisjon med kostnadssenter og team fra første dag. På Fargate gjøres dette gjennom vanlige AWS-tagger på task-definisjonen, mens Cloud Run bruker etiketter (labels) på tjenestenivå. Uten denne merkingen blir det raskt vanskelig å svare på hvilket team eller produkt som faktisk driver kostnadsveksten når fakturaen øker, spesielt i organisasjoner med mange små, uavhengige tjenester. Flere nordiske selskaper har gjennom 2026 begynt å kreve slik merking som en forutsetning for produksjonssetting, uavhengig av om arbeidsmengden kjører på AWS eller Google Cloud.

Eksempel: kostnadsberegning for en typisk norsk SaaS-arbeidsmengde

La oss se på et konkret eksempel: en mellomstor SaaS-tjeneste med moderat, men ujevn trafikk gjennom døgnet, som krever 1 vCPU og 2 GB minne i snitt. På Fargate on-demand i en europeisk region vil dette typisk lande i overkant av $40 i måneden ved kontinuerlig drift, gitt EU-tillegget på 12-13 % over US-prisene. Med Fargate Spot, forutsatt at arbeidsmengden tåler avbrudd, kan denne kostnaden kuttes med opptil 70 %, ned mot $12-15 i måneden.

På Cloud Run, hvor tjenesten skalerer ned i lavtrafikkperioder i stedet for å kjøre kontinuerlig for fullt, vil den reelle regningen ofte ligge nærmere de $5,70 Google oppga som eksempel for en sammenhengende 1 vCPU/1 GiB-instans over 30 dager, justert opp noe for det høyere minnebehovet og trafikktoppene. For en arbeidsmengde med denne typen ujevnt mønster er Cloud Run som oftest det rimeligste alternativet, med mindre man aktivt bruker Fargate Spot og har toleranse for avbrudd.

Kodeeksempel: minimal oppsett på begge plattformer

For å illustrere forskjellen i kompleksitet, her er et forenklet eksempel på hvordan man definerer en tjeneste på hver plattform via kommandolinjeverktøyene.

# AWS Fargate via ECS CLI (forenklet)
aws ecs register-task-definition \
  --family min-tjeneste \
  --requires-compatibilities FARGATE \
  --cpu "1024" --memory "2048" \
  --container-definitions '[{"name":"app","image":"MITT_IMAGE:latest"}]'

aws ecs create-service \
  --cluster min-klynge \
  --service-name min-tjeneste \
  --task-definition min-tjeneste \
  --desired-count 1 \
  --launch-type FARGATE
# Google Cloud Run via gcloud CLI
gcloud run deploy min-tjeneste \
  --image=europe-north1-docker.pkg.dev/PROSJEKT/min-tjeneste:latest \
  --region=europe-north1 \
  --cpu=1 --memory=2Gi \
  --min-instances=0 --max-instances=10 \
  --allow-unauthenticated

Forskjellen i antall steg og konsepter man må forstå er tydelig. Fargate-eksemplet krever kjennskap til task-definisjoner, klynger og tjenester som separate ressurser, mens Cloud Run-kommandoen samler det meste i én enkelt utrulling. Dette er ikke nødvendigvis et argument for at det ene er “bedre”, men det illustrerer hvorfor mindre team ofte opplever Cloud Run som raskere å komme i gang med.

Driftserfaringer fra 2026: hva rapporterer team som allerede har byttet?

Flere driftsteam som har publisert kostnadsanalyser gjennom 2026 peker på et gjentagende mønster: arbeidsmengder som tidligere kjørte på EC2 direkte, og som ble flyttet til Fargate for å slippe patching og kapasitetsplanlegging, endte ofte med en høyere direkte compute-kostnad, men lavere totalkostnad når man regner inn tid brukt på drift. Dette samsvarer med funn fra flere 2026-analyser av ECS/EKS-kostnader, som viser at Fargate kan koste opptil dobbelt så mye som tilsvarende EC2-kapasitet i rene compute-kroner, men at besparelsen i driftstid ofte oppveier dette for team uten dedikert plattformkapasitet. Fullstendig prisoversikt for kontrollplan og kompatible kjøretyper finnes på AWS sin offisielle side for ECS-priser.

For Cloud Run er det spesielt worker pools-funksjonen som har fått oppmerksomhet siden den ble allment tilgjengelig 27. august 2026. Team som tidligere måtte kombinere Cloud Run for HTTP-endepunkter med en separat Kubernetes-jobb for bakgrunnsprosessering, kan nå samle begge deler under samme plattform, noe som forenkler både overvåkning og fakturering.

Verdikt: hvilken plattform bør du velge?

Basert på tallene i denne sammenligningen finnes det ikke ett riktig svar, men noen klare tommelfingerregler. Velg Google Cloud Run hvis arbeidsmengden din har ujevn trafikk, du vil unngå å tenke på klynger og kontrollplan, og du kan leve med en øvre grense på 8 vCPU og 32 GB minne per instans. Prisen for en alltid-på, lett arbeidsmengde landet på rundt $5,70 i måneden i Googles eget eksempel fra juli 2026, mot over $35 for en sammenlignbar Fargate-konfigurasjon on-demand.

Velg AWS Fargate hvis du trenger opptil 32 vCPU og 244 GB minne i én enkelt oppgave, allerede har investert tungt i ECS eller EKS, eller kan utnytte Fargate Spot sin rabatt på opptil 70 % for arbeidsmengder som tolererer avbrudd. For team i Norge som må holde data innenfor EU/EØS, bør begge alternativene evalueres med regionpriser inkludert, siden både AWS sine EU-regioner og Google Cloud sine europeiske regioner typisk koster mer enn de amerikanske referanseprisene som ofte brukes i markedsføringsmateriell.

Den kanskje viktigste erkjennelsen fra 2026 er at gapet mellom de to plattformene har krympet. Cloud Run sine nye worker pools og automatiske failover fjerner flere av grunnene til at team tidligere valgte Fargate/ECS av rene driftshensyn. Samtidig har Fargate beholdt sitt fortrinn på ren kapasitet. Valget bør derfor styres av arbeidsmengdens faktiske profil, ikke av vane eller hvilken skyleverandør man “alltid har brukt”.

Har organisasjonen allerede en etablert AWS-kontostruktur, med eksisterende IAM-policyer, VPC-oppsett og Terraform-moduler for ECS, er kostnaden ved å innføre en ny sky-leverandør bare for én tjeneste sjelden verdt det, selv om Cloud Run i isolasjon ville vært billigere for akkurat den arbeidsmengden. Motsatt gjelder for team som allerede står på Google Cloud: å legge til AWS for én enkelt Fargate-arbeidsmengde med høyt minnebehov er sjelden fornuftig før man har vurdert om Cloud Run sine nyeste worker pools faktisk løser behovet. Den reelle beslutningen bør derfor veie total driftskompleksitet, ikke bare timeprisen på vCPU og minne isolert sett.

Ofte stilte spørsmål

Er AWS Fargate eller Google Cloud Run billigst?

Det avhenger av trafikkmønsteret. For kontinuerlige, lette arbeidsmengder viste Googles eget eksempel fra juli 2026 en kostnad på ca. $5,70 i måneden mot over $35 for en tilsvarende Fargate on-demand-konfigurasjon. For arbeidsmengder som kan bruke Fargate Spot med opptil 70 % rabatt, kan AWS derimot bli rimeligere.

Kan jeg kjøre Kubernetes-manifester på Cloud Run?

Nei, ikke direkte. Cloud Run bruker Knative som fundament, men eksponerer ikke full Kubernetes-API. Skal du kjøre standard Kubernetes-manifester uendret, er Google Kubernetes Engine eller Amazon EKS (med eller uten Fargate) et bedre valg.

Hva er worker pools i Cloud Run?

Worker pools er en ny ressurstype i Cloud Run, som ble allment tilgjengelig 27. august 2026. De er designet for pull-baserte, ikke-HTTP arbeidsmengder, som bakgrunnsjobber som leser fra en kø, og gjør Cloud Run relevant for flere brukstilfeller som tidligere krevde Fargate eller Kubernetes.

Støtter Fargate skalering til null?

Ikke som standard. Fargate-oppgaver må eksplisitt konfigureres til å skalere ned til null instanser ved inaktivitet, mens dette er standardoppførselen i Cloud Run.

Hvilken plattform har lavest kaldstart?

Cloud Run har generelt lavere kaldstart for lette, HTTP-baserte tjenester med optimaliserte container-images. Fargate-oppgaver bruker typisk noen sekunder lenger, delvis på grunn av ECS/EKS-orkestreringslaget som legger til et planleggingssteg før containeren starter.

Kan jeg bruke ARM-prosessorer på begge plattformer?

Ja. AWS tilbyr Graviton-baserte ARM-instanser på Fargate til omtrent 20 % lavere pris per vCPU-time enn x86. Google Cloud tilbyr tilsvarende ARM-støtte via Tau T2A-baserte instanser på Cloud Run.

Hvilke europeiske regioner bør norske selskaper velge?

For AWS er eu-north-1 (Stockholm) og eu-west-1 (Irland) de mest brukte regionene for nordiske selskaper. For Google Cloud er europe-north1 (Finland) og europe-west1 (Belgia) de vanligste valgene. Begge har et prispåslag på 10-30 % sammenlignet med amerikanske referansepriser.

Er det mulig å kombinere Fargate og Cloud Run i samme arkitektur?

Ja, en multicloud-tilnærming er teknisk mulig, men krever ekstra arbeid på nettverk, autentisering og overvåkning på tvers av leverandører. De fleste team velger én hovedplattform for containerarbeidsmengder og bruker den andre kun for spesifikke, isolerte tjenester der den har et klart fortrinn.