En rutinemessig oppgradering av nettverksutstyr i Google Clouds datasenter i Iowa endte som alt annet enn rutine 1. september 2026. En tekniker som skulle bytte ut svitsjer i sonen us-central1-b koblet fra de optiske fiberkablene i feil rekkefølge, og en region som normalt håndterer trafikk for tusenvis av kunder falt i praksis av nettet i over fire timer. Ifølge Googles egen hendelsesrapport varte forstyrrelsen fra klokken 07:41 til 11:52 amerikansk Stillehavstid, og uavhengige overvåkingstjenester registrerte at rundt 15 tjenester ble berørt før alt var normalisert igjen.
Hendelsen er interessant av flere grunner. Den viser hvor sårbar selv en hyperscale-sky kan være for en enkelt menneskelig feil, den kommer bare noen uker etter at Google Cloud rapporterte rekordvekst i markedsandel, og den skjer i en periode der stadig flere norske og nordiske selskaper legger arbeidslaster hos amerikanske skyleverandører. Denne saken går gjennom hva som faktisk skjedde, hvorfor det skjedde, og hva det betyr for kunder som vurderer hvor mye de kan stole på en enkelt sky-sone.
Hva skjedde i Iowa 1. september
Ifølge Googles offisielle statusside opplevde kunder med ressurser i us-central1-b, og en mindre del av us-central1-f, “alvorlig nettverksdegradering og ressursisolasjon” i tidsrommet 07:41 til 11:52 amerikansk Stillehavstid. Det tilsvarer 4 timer og 11 minutter der virtuelle maskiner i det berørte området mistet kontakten med resten av Googles nettverk. På verste tidspunkt falt trafikkgjennomstrømningen med 100 prosent gjennom den rammede banen, ifølge hendelsesrapporten på status.cloud.google.com.
Google klassifiserer episoden som nettverksdegradering, ikke et fullstendig regionbortfall. Det er en teknisk presis beskrivelse, men den fanger ikke opp hvordan det føltes for kundene som satt med utilgjengelige databaser og API-er midt i arbeidsdagen. Bransjenettstedet The Register omtalte hendelsen med en treffende overskrift om at en Google-ingeniør koblet fra hver fiber de kunne se, og understreket at dette var en ren driftsfeil, ikke et angrep eller en programvarebug.
Rotårsaken: fiberkablene som forsvant
Google skriver i sin egen forklaring at hendelsen ble utløst av en utilsiktet fysisk frakobling av nettverkets fiberoptiske kabler under rutinemessig maskinvarevedlikehold. En tekniker jobbet med en planlagt kapasitetsoppgradering på rutere i datasenteret og skulle bytte til høyere tetthet på transceiverne. Vanlig praksis er å koble fra og erstatte fiber gradvis, node for node, slik at trafikken kan rutes rundt det aktive arbeidet.
Det som gikk galt var rekkefølgen. På grunn av en prosedyrefeil ble samtlige optiske koblinger på de aktuelle enhetene frakoblet i rask rekkefølge, i stedet for gradvis. Resultatet var at ruterklyngen mistet all redundans samtidig, og trafikken som normalt fordeles over flere fiberveier hadde ingen steder å gå. Google beskriver selv at trafikkfallet nådde 100 prosent for ressurser i det berørte området i den mest kritiske fasen. Etter at fiberen ble koblet til igjen, stanset Google alt videre vedlikehold i regionen og satte i gang det de kaller en proaktiv gjennomgang av prosedyrer og automatisering for å hindre gjentakelse.
Hvilke tjenester og soner ble rammet
Googles egen statusside bruker den generiske formuleringen “flere produkter i us-central1-b opplever nettverksdegradering”, uten å liste opp alle berørte tjenester enkeltvis. Historikken for enkelttjenester gir likevel et bilde av omfanget. Compute Engine hadde en registrert nedetid på 1 time og 37 minutter i sin produkthistorikk, mens Bigtable viste 1 time og 31 minutter. Den samlede oppsummeringen på statussiden oppgir 1 time og 45 minutter for flere produkter, et tall som er kortere enn det fulle tekniske hendelsesvinduet fordi det kun teller den delen som utløser SLA-relevant nedetid per tjeneste.
Uavhengige overvåkingstjenester som følger Googles statusflyt fortløpende, deriblant gcpdown.com, knyttet hendelsen til rundt 15 ulike produkter og tjenester i sonen, fra beregningskraft og lagring til nettverkskomponenter i datalag-tjenester. Fordi Google selv ikke publiserer en fullstendig, autoritativ liste, bør det tallet leses som en indikasjon fra tredjepartssporing snarere enn en offisiell bekreftelse. Det som er sikkert er at både Compute Engine og Bigtable, to av de mest brukte grunnkomponentene i Google Cloud, sto på listen over rammede tjenester.
Tallene som ikke stemmer helt overens
Et poeng som er lett å overse er at Google selv opererer med flere ulike tidsangivelser for samme hendelse, avhengig av hvilken del av statussystemet man leser. Det offisielle hendelsesvinduet er 4 timer og 11 minutter, men den samlede produktoppsummeringen viser bare 1 time og 45 minutter. Forskjellen skyldes at hendelsesvinduet dekker hele perioden fra første avvik til full gjenoppretting, mens produkthistorikken kun teller perioden der en tjeneste formelt brøt sitt avtalte tjenestenivå.
For kunder som skal vurdere egen kompensasjon er dette skillet viktig. Det er produkthistorikkens tall, ikke det brede hendelsesvinduet, som normalt legges til grunn når Google beregner eventuelle krediteringer opp mot tjenesteavtalen. En kunde som kun så virkningen i Compute Engine kan dermed ende opp med et kortere nedetidstall enn det mediene siterer fra selve hendelsesrapporten.
Konsekvenser for kunder i Europa og Norden
Hendelsen var geografisk avgrenset til Iowa-regionen us-central1, og det finnes ingen offentlig dokumentasjon på at Googles europeiske regioner, som europe-north1 i Hamina i Finland, hadde egne tekniske problemer denne dagen. Likevel er det verdt å understreke at mange europeiske og nordiske selskaper plasserer deler av arbeidslasten sin i amerikanske regioner, ofte fordi de bruker globale SaaS-tjenester som selv kjører på Google Cloud i USA.
Et konkret eksempel er statusloggen til overvåkingsplattformen Torq, som meldte om nettverksdegradering knyttet til nettopp us-central1-b samme dag, og at automatisk feilhåndtering flyttet arbeidslaster ut av den rammede sonen i løpet av kort tid. Dette illustrerer et mønster som gjelder uavhengig av hvor kunden er lokalisert. Den som har bygget arkitekturen sin på tvers av flere soner eller regioner, merker langt mindre til denne typen hendelser enn den som har alt liggende i én sone.
Store skybrudd 2025–2026 sammenlignet
Iowa-hendelsen er langt fra den første store forstyrrelsen hos en hyperscale-leverandør de siste to årene. Tabellen under sammenstiller de mest omtalte hendelsene og viser at årsakene varierer mye, fra menneskelig svikt til lite dokumenterte konfigurasjonsfeil.
| Dato | Leverandør | Sted/omfang | Varighet | Årsak |
|---|---|---|---|---|
| 1. sep. 2026 | Google Cloud | us-central1-b, Iowa | 4t 11min (offisielt vindu) | Feil rekkefølge ved fiberfrakobling under vedlikehold |
| 12. juni 2025 | Google Cloud | Globalt, flere tjenester | Ca. 3,5–4,5 timer | Ikke offentliggjort i detalj, rammet Gmail, Meet, Spotify, Discord |
| Aug. 2026 | Google, Cloudflare, AWS (samlet) | 33 tjenester, 13 hendelser | Varierende per hendelse | Flere uavhengige driftsavbrudd samme måned |
| 2026 | Google Cloud | Nederland | Ca. 12 timer | Regional driftsforstyrrelse |
| 2026 | Cloudflare | Amsterdam-vedlikehold, Norden rammet | Ca. 10 timer | Planlagt vedlikehold med utilsiktede ringvirkninger |
Mønsteret som peker seg ut er at de fleste av disse hendelsene ikke skyldes ytre angrep, men interne feil under vedlikehold eller endringer. Det er et gjennomgående trekk i skybransjen at kompleksiteten i infrastrukturen gjør selv rutineoppgaver risikable når redundansen svikter samtidig som en endring gjennomføres.
Historisk kontekst: fra Nederland til Iowa
Den mest sammenlignbare hendelsen i nyere historie er trolig det globale Google Cloud-bruddet 12. juni 2025. Den gangen rammet forstyrrelsen langt bredere. Google innrømmet selv problemer i Chat, Meet, Gmail, Kalender, Disk, Cloud Search, Oppgaver og Voice, samtidig som tredjepartstjenester som musikkstrømmetjenesten Spotify og meldingstjenesten Discord ble påvirket fordi de kjører deler av infrastrukturen sin på Google Cloud. Ifølge nedetidsmålinger fra Downdetector, sitert av både Reuters og CNN, nådde antall feilrapporter for Spotify rundt 46 000 og for Discord nesten 11 000 i USA på det verste.
Cloudflare, som ofte blir trukket inn i skydebatter fordi selskapet leverer infrastruktur for store deler av internett, presiserte den gangen overfor CNN at dette var en Google Cloud-hendelse og at bare et lite antall av Cloudflares egne tjenester som bruker Google Cloud ble påvirket, mens kjernetjenestene fortsatte som normalt. Sammenlignet med juni 2025 er Iowa-hendelsen i september 2026 mer geografisk avgrenset, men til gjengjeld mer alvorlig innenfor det rammede området, med opptil 100 prosent trafikkfall for enkelte ressurser.
Markedsandeler: AWS, Azure og Google Cloud i 2026
Det pussige tidspunktet for et nettverksbrudd er at det kommer rett etter at Google Cloud har rapportert sin sterkeste kvartalsvise markedsposisjon på flere år. Ifølge Synergy Research Group, referert av flere analysebyråer i september 2026, holdt de tre store skyleverandørene til sammen 63 prosent av det globale markedet for skyinfrastruktur i andre kvartal 2026.
| Leverandør | Global markedsandel, Q2 2026 | Endring fra Q1 2026 | Markedsandel i Norge |
|---|---|---|---|
| AWS | 28 % | Uendret | Ca. 45 % |
| Microsoft Azure | 20 % | Ned fra 21 % | Ca. 23 % |
| Google Cloud | 15 % | Opp fra 14 % | Ca. 12 % |
| Sum de tre store | 63 % | Stabil | Ca. 80 % |
Tallene, hentet fra Synergy-data referert av blant annet Motley Fool i september 2026, viser at Google Cloud er den eneste av de tre store som vokser i andel kvartal for kvartal, riktignok fra et lavere utgangspunkt enn både AWS og Azure. AWS forsvarer fortsatt førsteplassen med solid margin, mens Azure har hatt en svakt fallende andel de siste to kvartalene til tross for sterk vekst i absolutte tall.
Slik ligger Norge an i skyfordelingen
I det norske markedet er bildet enda mer AWS-tungt enn globalt. Ifølge en oversikt fra analysetjenesten Stateglobe har AWS rundt 45 prosent av det norske skymarkedet, drevet av utstrakt bruk blant norske bedrifter og god tilgjengelighet via regionen i Stockholm. Azure følger med om lag 23 prosent, en posisjon selskapet delvis kan takke sin fysiske tilstedeværelse for. Microsoft er nemlig den eneste av de tre store hyperscale-leverandørene med en fullverdig skyregion fysisk plassert i Norge, kalt Norge Øst, med driftssentre i og rundt Oslo siden 2019.
Google Cloud har ingen egen region i Norge. Nærmeste infrastruktur er europe-north1 i Hamina i Finland, mens AWS sin nærmeste fullverdige region for norske kunder er eu-north-1 i Stockholm. Det betyr at norske selskaper som velger Google Cloud, uansett legger arbeidslasten sin utenfor landets grenser. Det kan spille inn både på ventetid og på hvor sårbare kundene er for hendelser som den i Iowa, ettersom mange fortsatt kobler globale tjenester tilbake til amerikanske kjerneregioner.
SLA-en din: dette lover Google egentlig
Mange kunder oppdager først hva tjenesteavtalen faktisk dekker når noe går galt. Googles offentlige tjenesteavtale for Compute Engine skiller tydelig mellom en enkelt instans og en arbeidslast fordelt over flere soner. For en enkelt instans er målet 99,5 prosent månedlig oppetid, mens en arbeidslast som er distribuert over flere soner skal holde minst 99,99 prosent. Det er nesten to størrelsesordener strengere krav, og det er ikke tilfeldig.
| Oppsett | Lovet oppetid (SLO) | Kompensasjon ved 99,00–99,99 % | Kompensasjon under 95 % |
|---|---|---|---|
| Enkelt instans | ≥ 99,5 % | 10 % av fakturert beløp | Opptil 50 % av fakturert beløp |
| Flere soner (multi-zone) | ≥ 99,99 % | 10 % av fakturert beløp | Opptil 50–100 % avhengig av avtaleversjon |
Poenget er enkelt, men lett å glemme i en travel driftshverdag. En kunde som kjørte alt i én enkelt sone i us-central1-b hadde i praksis ingen beskyttelse mot akkurat den typen hendelse som skjedde 1. september. Kompensasjonen fra Google dekker aldri det reelle forretningstapet ved nedetid, den dekker bare en prosentandel av regningen for den aktuelle tjenesten.
Konkurransedyktig sammenligning: hvordan de tre store håndterer nedetid
AWS, Azure og Google Cloud har alle lignende soneinndelte arkitekturer og lignende tjenesteavtaler i bunn og grunn, men de skiller seg i hvor åpne de er etter en hendelse. Google har lang tradisjon for å publisere detaljerte tekniske hendelsesrapporter i etterkant, slik det også ble gjort her, med konkret rotårsak og tidslinje offentlig tilgjengelig innen få dager. AWS er historisk noe knappere i sine offentlige rapporter, mens Microsoft Azure ofte kombinerer statusoppdateringer med driftsmeldinger direkte i administrasjonsportalen fremfor en fullt offentlig postmortem.
Det gjør at Google, ironisk nok, ofte fremstår som mer transparent nettopp fordi de er mer eksplisitte om egne feil. Ulempen er at det også gjør det lettere for konkurrenter og presse å plukke opp nøyaktig hvor enkel den underliggende feilen var, slik The Register gjorde med sin karakteristikk av hendelsen som et resultat av at en ingeniør koblet fra hver fiber de kunne se. For kunder som sammenligner leverandører bør denne typen åpenhet telle positivt, selv om selve hendelsen isolert sett er negativ omtale for Google.
Slik unngår du å bli et offer for neste sonefeil
Den praktiske lærdommen fra Iowa-hendelsen er ikke ny, men den blir bekreftet på nytt. Arbeidslaster som er spredt over flere soner overlever denne typen feil langt bedre enn de som ligger samlet i én sone. Googles egen dokumentasjon anbefaler at kritiske tjenester distribueres med minst tre replikaer fordelt på ulike soner innenfor en region, kombinert med automatisk feilhåndtering på applikasjonsnivå.
Et enkelt eksempel på hvordan dette kan defineres i infrastruktur-som-kode med Terraform, slik at en gruppe Compute Engine-instanser automatisk fordeles over flere soner i stedet for én:
resource "google_compute_region_instance_group_manager" "app" {
name = "app-multi-zone"
region = "us-central1"
base_instance_name = "app"
target_size = 6
distribution_policy_zones = [
"us-central1-a",
"us-central1-b",
"us-central1-c"
]
version {
instance_template = google_compute_instance_template.app.id
}
auto_healing_policies {
health_check = google_compute_health_check.app.id
initial_delay_sec = 300
}
}Med et slikt oppsett hadde en eventuell frakobling av fiber i én sone kun rammet en brøkdel av kapasiteten, ikke hele arbeidslasten. Kostnaden er noe høyere driftskompleksitet og litt mer nettverkstrafikk mellom soner, men for tjenester der nedetid koster mer enn marginalt ekstra i infrastruktur er regnestykket enkelt.
Markedspåvirkning: investortillit og Google Clouds vekst
Til tross for hendelsen i Iowa tyder ingenting på at den har svekket investorenes tillit til Google Cloud på kort sikt. Rapporteringen om at forretningsområdet vokser raskere enn både AWS og Azure i prosentvis omsetningsvekst, kombinert med at markedsandelen økte fra 14 til 15 prosent globalt fra første til andre kvartal 2026, tyder på at kunder fortsatt velger Google Cloud i økende tempo, særlig innen dataanalyse og maskinlæring.
Det er likevel verdt å følge med på om enkeltkunder begynner å kreve strengere kontraktsvilkår eller flerskyløsninger som en direkte konsekvens av gjentatte driftshendelser. Skybransjen har sett dette mønsteret før. Hver gang en stor leverandør får en godt dokumentert og pinlig hendelse, dukker det opp flere anbud der kunder eksplisitt ber om multisky-arkitektur eller garantier utover standard SLA.
Fem spådommer for skyens pålitelighet fremover
- Flere hyperscale-leverandører vil innføre strengere interne prosedyrekrav for fysisk vedlikehold av nettverksutstyr etter at Iowa-hendelsen har fått bred medieomtale.
- Andelen kunder som bevisst designer arbeidslaster på tvers av minst to soner, vil fortsette å øke, drevet av at slike hendelser gjentatte ganger rammer kunder som ikke har gjort det.
- Norske og nordiske virksomheter vil i økende grad stille krav om regional redundans i sine skyavtaler, særlig i sektorer med strenge krav til driftskontinuitet.
- Google Cloud vil fortsette å ta markedsandeler fra Azure i det globale regnskapet, men forbli klart mindre enn AWS også ved utgangen av 2026.
- Flere hendelsesrapporter vil trolig bli publisert med enda mer teknisk detaljnivå fremover, ettersom åpenhet har vist seg å dempe mye av den negative omtalen etter en hendelse.
Ofte stilte spørsmål
Hva forårsaket Google Cloud-bruddet i Iowa 1. september 2026?
En tekniker koblet fra optiske fiberkabler i feil rekkefølge under en planlagt kapasitetsoppgradering av rutere i sonen us-central1-b, noe som fjernet all nettverksredundans samtidig og førte til opptil 100 prosent trafikkfall for berørte ressurser.
Hvor lenge varte nedetiden?
Googles offisielle hendelsesvindu strakk seg fra 07:41 til 11:52 amerikansk Stillehavstid, totalt 4 timer og 11 minutter. Enkelttjenester som Compute Engine og Bigtable hadde kortere, SLA-relevante nedetidsvinduer på henholdsvis 1 time 37 minutter og 1 time 31 minutter.
Ble norske eller nordiske kunder direkte rammet?
Det finnes ingen offentlig dokumentasjon på at Googles europeiske regioner hadde tekniske problemer denne dagen. Nordiske kunder med arbeidslaster plassert direkte i us-central1-b, eller som brukte tredjepartstjenester avhengige av den sonen, kan likevel ha merket forstyrrelser indirekte.
Hvor mange tjenester ble påvirket?
Google selv oppgir bare at flere produkter ble rammet, uten en fullstendig offentlig liste. Uavhengige overvåkingstjenester har knyttet hendelsen til rundt 15 ulike tjenester i den berørte sonen.
Hva slags kompensasjon kan berørte kunder kreve?
Etter Googles tjenesteavtale for Compute Engine kan kunder med dokumentert nedetid under den lovede oppetiden kreve kreditering på fremtidige regninger, typisk fra 10 prosent og opp mot 50 prosent av fakturert beløp for den aktuelle tjenesten, avhengig av hvor alvorlig bruddet på tjenestenivået var.
Har Google Cloud hatt lignende hendelser tidligere?
Ja. Det mest kjente eksempelet er det globale bruddet 12. juni 2025, som rammet tjenester som Gmail, Google Meet, Spotify og Discord samtidig. Iowa-hendelsen i 2026 var mer geografisk avgrenset, men til gjengjeld mer alvorlig innenfor det rammede området.
Hvordan kan man unngå å bli rammet av en tilsvarende hendelse?
Ved å distribuere kritiske arbeidslaster over minst to eller tre soner i stedet for én, kombinert med automatisk feilhåndtering på applikasjonsnivå, reduseres eksponeringen mot at ett enkelt vedlikeholdsavvik tar ned hele tjenesten.
Har hendelsen påvirket Google Clouds markedsposisjon?
Foreløpig ikke merkbart. Google Cloud rapporterte økt global markedsandel, fra 14 til 15 prosent, i kvartalet der hendelsen fant sted, ifølge tall fra Synergy Research Group referert av flere analysebyråer i september 2026.
