Google Cloud har gitt Cloud Run worker pools generell tilgjengelighet (GA). Den nye ressurstypen er bygget for kontinuerlige bakgrunnsjobber som køforbruk og AI-inferens, og bryter med tjenestemodellen Cloud Run har vært kjent for siden lanseringen. Ifølge Google Clouds egne driftsnotater fikk worker pools GA-status tidlig i august 2026, og prissiden ble oppdatert 27. august samme år med nye satser og GPU-priser. For skyteam i Norge og Norden, som allerede bruker Cloud Run til API-er og mikrotjenester, åpner lanseringen en ny vei for arbeidslaster som verken passer i en HTTP-tjeneste eller en tidsbegrenset jobb.
Nyheten kommer midt i en periode hvor etterspørselen etter serverless containerdrift vokser raskt. Gartner har i sin Predicts 2025-analyse anslått at over 50 prosent av alle containerutrullinger vil bruke serverless containerforvaltning, opp fra under 25 prosent i 2024. Worker pools er Googles svar på den utviklingen, og et forsøk på å ta markedsandeler fra Kubernetes-baserte løsninger og fra konkurrenter som AWS Fargate og Azure Container Apps.
Hva har egentlig skjedd med Cloud Run
Cloud Run har frem til nå bestått av to hovedressurser: tjenester (services) for HTTP-basert trafikk, og jobber (jobs) for tidsbegrensede batch-oppgaver. Worker pools blir den tredje kategorien, og skal dekke arbeidslaster som verken svarer på innkommende forespørsler eller kjører til ferdig, men som skal stå på kontinuerlig i bakgrunnen. Google beskriver ressursen som en toppnivåbeholder som styrer et sett med konfigurasjoner og revisjonsmaler for pull-baserte arbeidslaster, altså prosesser som selv henter data fra en kø eller en strømkilde i stedet for å vente på et kall.
Funksjonen har ligget i forhåndsvisning siden sommeren 2025, først privat og deretter offentlig, før den nå er klar for produksjonsbruk. En Google Cloud-bloggpost knyttet til lanseringen understreker at worker pools gir opptil 40 prosent lavere pris på CPU og minne sammenlignet med instansfakturerte Cloud Run-tjenester, noe som gjør dem spesielt aktuelle for team som kjører store, stabile arbeidsmengder over tid.
Slik skiller worker pools seg fra tjenester og jobber
Forskjellen handler i praksis om tre ting: hvordan ressursen nås, hvordan den skalerer, og hvordan den faktureres. En Cloud Run-tjeneste eksponerer et lastbalansert HTTPS-endepunkt og skalerer automatisk basert på trafikk. En jobb kjører til den er ferdig og stopper. En worker pool har verken URL eller innebygd autoskalering. I stedet setter utvikleren et fast antall instanser, og containeren kobler seg selv til en kø, et Kafka-tema eller en annen intern kilde over VPC-nettverket.
Det gjør worker pools til en slags mellomting mellom en klassisk Kubernetes Deployment og en administrert serverless-tjeneste. Du slipper å drifte kontrollplanet selv, men du beholder kontrollen over hvor mange instanser som kjører til enhver tid. For team som har flyttet bakgrunnsarbeidere ut av Kubernetes og inn i Cloud Run tidligere, har mangelen på en ren “alltid på”-modell vært et hull i produktet. Det hullet tettes nå.
| Ressurstype | Arbeidslast | Skalering | Fakturering | Offentlig URL |
|---|---|---|---|---|
| Tjenester (services) | HTTP-forespørsler, API-er | Automatisk, basert på trafikk | Forespørselsbasert eller instansbasert | Ja |
| Jobber (jobs) | Tidsbegrensede batch-oppgaver | Fast antall oppgaver, kjører til ferdig | Instansbasert per kjøring | Nei |
| Worker pools | Kontinuerlig bakgrunnsarbeid, køforbruk, AI-inferens | Fast antall instanser, ingen autoskalering | Instansbasert, opptil 40 % lavere enn tjenester | Nei |
Nettverk, sidevogner og tilgangskontroll
Teknisk sett settes en worker pool opp omtrent som en tjeneste. Du velger et containerbilde, gir ressursen et navn, angir region og setter CPU- og minnegrenser per instans. Google har lagt til støtte for flere containere i samme pool, altså sidevogner (sidecars), og for å hente bilder fra andre GCP-prosjekter enn det poolen kjører i. Det siste er nyttig for større organisasjoner med sentraliserte containerregistre, en driftsmodell mange norske selskaper med flere GCP-prosjekter allerede bruker for skyressurser.
Fordi worker pools ikke eksponerer et offentlig endepunkt, kobles de i stedet til interne tjenester via VPC-nettverket, både for inngående og utgående trafikk. Det gjør det mulig å la en worker lese fra en intern kø eller database uten at noe av trafikken går via internett. Samme tjenestekonto-modell som resten av Cloud Run brukes for tilgangsstyring, så team som allerede har IAM-policyer på plass for tjenester og jobber, kan gjenbruke det meste av oppsettet.
Prismodellen: Instansbasert fakturering og rabatter
Worker pools bruker det Google kaller instansbasert fakturering. I motsetning til forespørselsbasert fakturering, der du kun betaler for CPU og minne mens en forespørsel behandles, betaler du her for hele levetiden til hver kjørende instans, uansett om den akkurat behandler noe eller venter på neste melding i køen. I Tier 1-regioner, som er Googles billigste prisklasse, ligger CPU-kostnaden for instansbasert fakturering på 0,000018 dollar per vCPU-sekund, tilsvarende om lag 0,0648 dollar per vCPU-time.
Google tilbyr også forpliktet bruk-rabatter (Committed Use Discounts) for instansbaserte tjenester, jobber og worker pools: 28 prosent rabatt ved ett års forpliktelse, og 46 prosent ved tre år. Kombinert med de opptil 40 prosent lavere grunnratene sammenlignet med instansbaserte tjenester, kan en treårig forpliktelse på en stabil worker pool gi en betydelig lavere totalkostnad enn å kjøre samme arbeidslast som en tradisjonell Cloud Run-tjeneste satt til å holde minimum én instans varm døgnet rundt.
Den forespørselsbaserte gratiskvoten i regionen us-central1 ligger på 384 204 vCPU-sekunder og 728 744 GiB-sekunder per måned, ifølge Cloud Runs offisielle prisside. Kvoten gjelder ikke direkte for worker pools, som er instansbasert fra første sekund, men gir et bilde av hvor Google fortsatt subsidierer små, sporadiske arbeidslaster tyngst.
Hvorfor nå: AI-inferens driver etterspørselen
Timingen er neppe tilfeldig. Google peker selv på storskala AI-inferens som et av hovedbruksområdene for worker pools. Modeller som kjører kontinuerlig og henter forespørsler fra en kø, i stedet for å svare på enkeltstående HTTP-kall, passer dårlig med den klassiske Cloud Run-tjenestemodellen, hvor kaldstart og autoskalering styrer hvor mange instanser som er oppe. En inferensarbeider som skal holde en modell lastet i minnet mellom hver jobb, har rett og slett ikke bruk for at instansen skrus av mellom hver forespørsel.
Samtidig har Cloud Run allerede fått GPU-støtte for NVIDIA L4, priset til 0,0001867 dollar per sekund uten sonal redundans, ifølge den oppdaterte prissiden fra 27. august 2026. Google har ikke bekreftet at worker pools i seg selv støtter GPU-konfigurasjon på lanseringstidspunktet, men kombinasjonen av GPU-støtte i plattformen og en ressurstype bygget for lange, kontinuerlige jobber peker i en tydelig retning: Cloud Run posisjoneres som et alternativ til å drifte egne GPU-noder i Kubernetes for inferensarbeid.
Fra forhåndsvisning til GA: Tidslinjen
Worker pools har hatt en lengre modningsperiode enn mange andre Cloud Run-funksjoner. Ressursen dukket først opp i konsollen i privat forhåndsvisning sommeren 2025, og gikk deretter over i offentlig forhåndsvisning samme år. På Google Cloud Next i april 2026 omtalte selskapet tjenester, jobber og worker pools samlet som de tre måtene å styre Cloud Run-infrastruktur på, et tegn på at worker pools allerede da var regnet som en fullverdig del av produktet. GA-statusen kom etter det, ifølge driftsnotatene, tidlig i august 2026.
Et år i forhåndsvisning er ikke uvanlig for Google Cloud, som historisk har brukt lengre testperioder på infrastrukturnære funksjoner enn på rene API-tillegg. For team som fulgte forhåndsvisningen tett, betyr GA-lanseringen i praksis at man nå kan bygge produksjonsarbeidslaster på ressursen med Googles vanlige tjenestenivåavtaler, i stedet for forhåndsvisningens mer uformelle støttegaranti.
Markedet for serverless containere: Hva sier analytikerne
Flere analysebyråer har publisert tall for serverless containermarkedet i 2025 og 2026, og selv om metodene spriker, peker alle i samme retning: sterk vekst. Market.us anslår at det globale markedet for serverless containere var verdt 8,2 milliarder dollar i 2025, og venter en økning til 10,6 milliarder dollar i 2026, med en samlet årlig vekstrate på 29 prosent frem mot 2035. Growth Market Reports opererer med en lavere, men fortsatt høy vekstrate på 26,9 prosent årlig frem til 2033.
Det bredere markedet for serverless computing, som inkluderer funksjoner-som-tjeneste i tillegg til containere, vurderes ulikt av forskjellige byråer. Fortune Business Insights setter markedsverdien til 2,57 milliarder dollar i 2025, med vekst til 9,41 milliarder dollar innen 2034. SNS Insider opererer med et helt annet utgangspunkt, 25,76 milliarder dollar i 2025, og spår 108,39 milliarder dollar innen 2035. Sprikene illustrerer hvor ulikt bransjen fortsatt definerer “serverless”, men den underliggende trenden, en tosifret årlig vekstrate over flere år, går igjen i samtlige rapporter.
| Analysebyrå | Marked | Verdi 2025/2026 | Prognose | Årlig vekstrate |
|---|---|---|---|---|
| Market.us | Serverless containere | 8,2 mrd. USD (2025) | 104,6 mrd. USD innen 2035 | 29,0 % |
| Growth Market Reports | Serverless containere | – | 18,4 mrd. USD innen 2033 | 26,9 % |
| Fortune Business Insights | Serverless computing | 2,57 mrd. USD (2025) | 9,41 mrd. USD innen 2034 | 15,52 % |
| SNS Insider | Serverless computing | 25,76 mrd. USD (2025) | 108,39 mrd. USD innen 2035 | 15,54 % |
| Gartner (Predicts 2025) | Containerforvaltning | Under 25 % i 2024 | Over 50 % av utrullinger i 2025 | – |
Konkurransebildet: AWS, Azure og Kubernetes
Worker pools setter Cloud Run i direkte konkurranse med flere etablerte alternativer for bakgrunnsarbeid. AWS Fargate har lenge tilbudt kjøring av containere uten å administrere servere, og brukes ofte nettopp til køforbrukere og bakgrunnsjobber i AWS-miljøer, med full kontroll over antall oppgaver og skaleringspolicyer via ECS eller EKS. AWS App Runner ligger nærmere Cloud Run-tjenester enn worker pools, siden det er bygget for HTTP-baserte applikasjoner med automatisk skalering, ikke for kontinuerlig bakgrunnsarbeid uten endepunkt.
Azure Container Apps dekker et lignende spenn som Cloud Run, med støtte for både skalerbare tjenester og jobber, men uten en direkte motpart til worker pools sin faste, alltid-på instansmodell på lanseringstidspunktet. Kubernetes selv, med Deployments og StatefulSets, har alltid kunnet gjøre det worker pools nå gjør, men krever at teamet drifter selve klyngen, håndterer noder, oppgraderinger og skalering manuelt eller via egne verktøy. Det er nettopp den driftsbyrden Cloud Run worker pools prøver å fjerne, ved å tilby den samme “sett antall instanser og la dem kjøre”-modellen uten et kontrollplan å vedlikeholde.
Google har ikke publisert en direkte prissammenligning mot AWS eller Azure for denne typen arbeidslast, og enhver sammenligning på tvers av skyleverandørene bør derfor gjøres med egne testarbeidslaster før man bytter plattform. Det som er tydelig, er at Google med worker pools fjerner et av de sist gjenværende argumentene for å velge Kubernetes fremfor Cloud Run: muligheten til å kjøre lenge levende, ikke-HTTP-baserte prosesser uten en autoskaleringsmodell som ikke passer arbeidslasten.
Slik setter du opp en worker pool
Oppsettet ligner mye på å opprette en vanlig Cloud Run-tjeneste, men uten steget der du velger om ressursen skal være offentlig tilgjengelig. Under kommandolinjeverktøyet gcloud ser et enkelt oppsett omtrent slik ut:
gcloud run worker-pools deploy min-kø-arbeider \
--image=europe-north1-docker.pkg.dev/mitt-prosjekt/arbeidere/kø-forbruker:latest \
--region=europe-north1 \
--instances=3 \
--cpu=2 \
--memory=4Gi \
--vpc-connector=min-vpc-connector \
--service-account=arbeider-sa@mitt-prosjekt.iam.gserviceaccount.comLegg merke til at antall instanser settes eksplisitt med parameteren --instances, i motsetning til tjenester der man typisk angir et minimum og maksimum for autoskalering. Skal antallet endres, gjøres det med en ny utrulling eller en oppdateringskommando, ikke automatisk basert på last. For team i Norge som allerede kjører Cloud Run i regionen europe-north1 (Finland), betyr det at worker pools kan driftes med samme lave nettverkslatens til nordiske brukere som eksisterende Cloud Run-tjenester.
Betydning for norske og nordiske skyteam
For norske selskaper som allerede har flyttet deler av driften til Google Cloud, dekker worker pools et konkret behov: køforbrukere, batch-lignende strømbehandling og AI-arbeidsbelastninger som i dag enten kjøres i en Kubernetes-klynge eller hackes inn i en Cloud Run-tjeneste ved å sette minimum antall instanser til én og ignorere at det ikke finnes noe HTTP-endepunkt å kalle. Begge løsningene har vært kompromisser. Den første krever at noen drifter klyngen, den andre betaler for infrastruktur beregnet på en annen trafikkmodell.
Nordiske skyteam har generelt vært tidlige til å ta i bruk serverless-mønstre, delvis fordi mindre utviklingsteam har begrenset kapasitet til å drifte egne Kubernetes-klynger. En ressurs som fjerner behovet for klyngedrift på nok en kategori arbeidslaster, kan derfor få større gjennomslag her enn i markeder med tyngre intern plattformkompetanse. Samtidig betyr fraværet av autoskalering at team selv må bygge overvåking og varsling for å fange opp når en kø vokser raskere enn worker poolen klarer å tømme den, noe som tradisjonelt har vært en av fordelene ved Kubernetes’ innebygde autoskalering av poder.
Historisk kontekst: Cloud Run siden starten
Cloud Run ble lansert som en administrert containerplattform bygget på det åpne Knative-rammeverket, og har siden den gang gradvis utvidet seg fra en ren HTTP-tjenesteplattform til noe som ligner en full applikasjonsplattform. Jobber kom som svar på etterspørsel etter batch-behandling uten å måtte sette opp egne Kubernetes CronJobs. GPU-støtte fulgte da AI-arbeidslaster ble en stadig større del av kundenes bruksmønster. Worker pools er det neste, naturlige steget i den utviklingen, og lukker det siste store gapet mot det Kubernetes historisk har vært alene om å tilby innenfor Googles eget skyøkosystem.
Det er også et tegn på en bredere trend i skybransjen: leverandørene beveger seg bort fra å tilby rene beregningsprimitiver, og mot ferdigpakkede ressurstyper skreddersydd for spesifikke arbeidsmønstre. AWS har gjort noe lignende med App Runner og Fargate-profiler, mens Azure har bygget stadig flere skreddersydde miljøer inn i Container Apps. Kappløpet handler ikke lenger bare om å tilby containere, men om hvem som best kan gjette hvilken kategori arbeidslast utviklerne trenger neste år.
Markedspåvirkning: Hva betyr dette for skyøkonomien
På kort sikt vil worker pools trolig hovedsakelig påvirke Googles egen andel av Cloud Run-relatert forbruk, ved å fange opp arbeidslaster som ellers ville gått til enten en dyrere instansbasert tjeneste eller en egendriftet Kubernetes-klynge. Prisreduksjonen på opptil 40 prosent for CPU og minne sammenlignet med instansbaserte tjenester er betydelig nok til at eksisterende Cloud Run-kunder med lengevarende bakgrunnsprosesser har god grunn til å migrere umiddelbart etter GA.
På lengre sikt er det mer interessant hvordan dette påvirker konkurrentene. Både AWS og Microsoft har historisk fulgt tett etter når Google introduserer nye Cloud Run-ressurstyper, slik de gjorde med jobber. Gitt at Gartner venter at over halvparten av alle containerutrullinger bruker serverless containerforvaltning i 2025, er det sannsynlig at AWS og Microsoft varsler tilsvarende “alltid på, ingen autoskalering”-ressurser i egne plattformer i løpet av det neste året, for ikke å tape terreng på nettopp AI-inferens og køforbruk, de to bruksområdene Google selv fremhever tydeligst.
Fem spådommer for de neste tolv månedene
- AWS og Azure svarer innen 2027. Begge selskaper har historisk speilet Cloud Run-funksjoner med egne varianter innen 12–18 måneder, og en “alltid på”-ressurs uten autoskalering er en naturlig neste utvidelse av både Fargate og Container Apps.
- Flere GPU-arbeidslaster flytter fra Kubernetes til worker pools. Kombinasjonen av NVIDIA L4-støtte i Cloud Run og en ressurstype bygget for kontinuerlig drift gjør plattformen mer attraktiv for mindre AI-inferensteam som vil unngå å drifte egne GPU-noder.
- Prisen på instansbasert fakturering justeres ned ytterligere. Med et voksende marked og hard konkurranse fra Fargate og Container Apps er det sannsynlig at Google fortsetter å justere Tier 1-satsene for å holde worker pools konkurransedyktige på pris, slik selskapet har gjort med tidligere Cloud Run-prisendringer.
- Tredjepartsverktøy for kø- og skaleringsstyring dukker opp. Fraværet av innebygd autoskalering skaper et hull som overvåkings- og automatiseringsleverandører trolig fyller med egne løsninger for å justere instansantall basert på kølengde.
- Flere norske og nordiske selskaper med Kubernetes-tretthet vurderer migrering. Mindre utviklingsteam uten dedikert plattformkompetanse er den gruppen som har mest å vinne på å legge ned egen klyngedrift til fordel for en administrert, instansbasert modell.
Ofte stilte spørsmål
Hva er en Cloud Run worker pool?
En worker pool er en Cloud Run-ressurs bygget for kontinuerlig bakgrunnsarbeid uten HTTP-endepunkt, som køforbruk, strømbehandling og AI-inferens. Den skiller seg fra tjenester og jobber ved at instansantallet settes manuelt og ikke autoskaleres.
Når fikk worker pools generell tilgjengelighet?
Ifølge Cloud Runs offisielle driftsnotater fikk worker pools GA-status tidlig i august 2026, etter over ett år i privat og offentlig forhåndsvisning.
Hvor mye billigere er worker pools enn Cloud Run-tjenester?
Google oppgir at worker pools kan koste opptil 40 prosent mindre for CPU og minne enn instansfakturerte Cloud Run-tjenester, i tillegg til at forpliktet bruk-rabatter på 28 til 46 prosent kan legges oppå grunnprisen. Se Google Clouds egen serverless-blogg for detaljer.
Støtter worker pools autoskalering?
Nei. I motsetning til Cloud Run-tjenester har worker pools ikke innebygd autoskalering. Utvikleren angir et fast antall instanser, og må selv bygge overvåking dersom antallet skal justeres basert på arbeidsmengde.
Kan worker pools bruke GPU?
Cloud Run som plattform støtter NVIDIA L4-GPUer, men Google har ikke på lanseringstidspunktet bekreftet eksplisitt at worker pools kan konfigureres med GPU-ressurser på samme måte som tjenester. Se produktoversikten for gjeldende status.
Hvordan sammenlignes worker pools med AWS Fargate?
AWS Fargate lar deg kjøre containere uten serveradministrasjon og brukes ofte til lignende bakgrunnsarbeid, men krever at du selv setter opp skaleringspolicyer via ECS eller EKS. Worker pools tilbyr en enklere, mer opinionert modell direkte i Cloud Run, uten et eget orkestreringslag å konfigurere.
Trenger jeg VPC for å bruke worker pools?
Det er ikke strengt påkrevd, men siden worker pools ikke har et offentlig endepunkt, kobles de i praksis til interne køer og tjenester via en VPC-connector for både inngående og utgående trafikk.
Erstatter worker pools Kubernetes for bakgrunnsjobber?
For mange mindre team, ja. Worker pools dekker det samme grunnleggende behovet som en Kubernetes Deployment for lenge levende arbeidere, men uten at teamet må drifte selve klyngen. Organisasjoner med komplekse orkestreringsbehov eller store, etablerte Kubernetes-miljøer vil trolig fortsette å bruke klyngen sin i overskuelig fremtid.
