August 2026 ble en måned skyleverandørene helst vil glemme. Google Cloud mistet 33 tjenester i regionen us-west1 i over to timer. Cloudflare samlet 13 separate driftsforstyrrelser på bare én uke, og mistet siden fiberforbindelsen i Istanbul. AWS kom lettere unna, men også der ble det registrert avbrudd. Ingen av hendelsene var globale katastrofer, men til sammen tegner de et bilde av en skybransje som stadig oftere svikter i det små, akkurat idet norske og nordiske virksomheter legger stadig mer av driften sin i nettopp disse plattformene.
Ifølge driftsovervåkeren Is Internet Up var kun 4 av 31 dager i august helt fri for hendelser hos de store skyleverandørene. Ingen av dagene ble klassifisert som et globalt utfall, men mønsteret av gjentatte, lokaliserte avbrudd reiser et spørsmål mange norske IT-ledere nå stiller seg: hvor robust er egentlig skyen de har bygget virksomheten sin på?
Google Cloud-avbruddet 20. august: 33 tjenester rammet i us-west1
Det mest omtalte enkeltavbruddet i august rammet Google Cloud sin region us-west1. Ifølge Google Cloud sin egen hendelsesrapport oppsto problemene torsdag 20. august klokken 08.00 til 10.22 amerikansk Stillehavstid (15.00 til 17.22 norsk tid), og rammet en rekke tjenester med økt ventetid, feil ved provisjonering og forhøyet feilrate. Google selv oppgir varigheten til 2 timer og 22 minutter for kjerneperioden, mens tredjeparts overvåking beskrevet av Is Internet Up målte en reell påvirkningsperiode nærmere 3 timer og 40 minutter før alt var normalisert igjen.
Årsaken var ikke et cyberangrep eller en programvarefeil, men rutinemessig fibervedlikehold som gikk galt. Det høres banalt ut, men illustrerer et kjernepoeng ved moderne skyinfrastruktur: selv de største aktørene i verden er avhengige av fysisk fiber, strøm og kjøling som kan svikte uansett hvor mye programvare som ligger på toppen. Google Cloud sin egen statusside, som oppdateres kontinuerlig på status.cloud.google.com/summary, viser at hendelsen ble registrert med varighet 2 timer og 45 minutter i den offisielle sammendragsloggen, et lite men tydelig sprik fra de 2 timer og 22 minuttene som oppgis i selve hendelsesrapporten.
For norske selskaper med arbeidslaster i amerikanske Google Cloud-regioner er ikke us-west1 nødvendigvis der produksjonstrafikken ligger. Men mange nordiske virksomheter bruker global lastbalansering, replikerte databaser og felles identitetstjenester som kan strekke seg på tvers av regioner. Et avbrudd i California kan dermed forplante seg til Oslo eller Stockholm dersom arkitekturen ikke er bygget for regional isolasjon.
Cloudflare: 13 hendelser på en uke, deretter fiberbrudd i Istanbul
Mens Google Cloud fikk sitt store enkeltavbrudd, hadde Cloudflare et helt annet problem gjennom august: volum. Ifølge sammenstillingen fra Is Internet Up opplevde Cloudflare en klynge på 13 separate hendelser mellom 7. og 14. august, hvor tjenester som R2-lagring, Durable Objects og Workers KV alle viste ustabilitet i perioder. Ingen av de enkelte hendelsene var langvarige, men frekvensen i seg selv er påfallende for en infrastrukturleverandør som normalt fremhever driftsstabilitet som en kjernefordel.
26. august fulgte enda en episode: en cirka 90 minutter lang degradering av Durable Objects, sammen med et kortvarig API-problem i Realtimekit. Begge ble løst samme dag, men understreker at Cloudflares edge-plattform, som håndterer trafikk for en betydelig andel av verdens nettsteder, fortsatt krever kontinuerlig operativ finjustering selv når arkitekturen i utgangspunktet er designet for høy redundans.
Den siste og kanskje mest illustrerende hendelsen kom mot slutten av måneden, da Cloudflare mistet mørk fiber i Istanbul-regionen fra klokken 08.25 UTC. Selskapet jobbet med leverandører for å gjenopprette kapasiteten, men hendelsen viser hvor sårbart selv et globalt distribuert nettverk er for enkeltpunkts fysiske feil i én by. For Cloudflares brukere i Norden fikk ikke dette direkte konsekvenser, men det er en påminnelse om at edge-nettverk består av fysisk infrastruktur som kan svikte lokalt, uansett hvor mange datasentre selskapet har totalt.
AWS: roligere måned, men ikke feilfri
Sammenlignet med Google Cloud og Cloudflare hadde AWS en forholdsvis rolig august. Driftsrapporten fra What is down? registrerte to hendelser for AWS gjennom måneden, med samlet nedetid på 4 timer og 9 minutter og alvorlighetsgrad klassifisert som “degradert” fremfor fullt utfall. Google Cloud fikk til sammenligning én hendelse klassifisert som delvis utfall med 2 timer og 49 minutters varighet i samme rapport, et tall som ligger tett opp mot Googles egen oppgitte varighet for us-west1-hendelsen.
AWS brukte samtidig august til å annonsere positive nyheter som til dels kan leses som et forsøk på å holde fokus på produktutvikling snarere enn driftsproblemer. Selskapet lanserte AWS Glue 6.0 med rundt 30 prosent lavere pris og full støtte for Apache Iceberg v3, ifølge AWS sin offisielle nyhetsblogg. For dataingeniører i Norden som jobber med store datasjøer og tabellformater, er dette en konkret kostnadsbesparelse som til en viss grad kan oppveie bekymringen rundt driftsstabilitet andre steder i skyøkosystemet.
AWS var også involvert i en av månedens mer interessante strategiske nyheter: et samarbeid med Microsoft Azure om multisky-tilkobling. Azure Multicloud Interconnect ble lansert i offentlig forhåndsvisning med AWS som første støttede leverandør, ifølge oppdateringer fra EU Cloud Cost sin gjennomgang av mai til august 2026. Samtidig fikk Azure Files-driveren i Azure Kubernetes Service støtte for arbeidsbelastningsidentitet på pod-nivå, som styrker autentisering mot SMB-filandeler uten statiske legitimasjoner.
Tabell: Skyavbrudd i august 2026 sammenlignet
| Leverandør | Antall hendelser | Verste enkelthendelse | Total nedetid (rapportert) | Alvorlighetsgrad |
|---|---|---|---|---|
| Google Cloud | 1 storhendelse (us-west1) | 20. august, 2t22m–3t40m | 2t45m–3t40m avhengig av kilde | Delvis utfall |
| Cloudflare | 13 hendelser (7.–14. aug) + 2 senere | 90 min Durable Objects-degradering (26. aug) | Flere kortvarige episoder | Degradert ytelse |
| AWS | 2 hendelser | Ikke spesifisert enkelthendelse | 4t09m samlet | Degradert |
| Azure | Ingen store hendelser rapportert | – | – | Stabil |
Tabellen viser et tydelig mønster: Google Cloud og Cloudflare sto for de mest synlige hendelsene i august, mens AWS og Azure fremstår som noe mer stabile i samme periode. Det betyr ikke at AWS og Azure er immune. Historisk har begge hatt egne store avbrudd, og statistikken for én måned sier lite om langsiktig pålitelighet. Det den derimot viser, er at ingen skyleverandør i 2026 kan skilte med null hendelser over en fireukersperiode.
Hvorfor august 2026 er relevant for norske virksomheter
Norge har de siste årene blitt en stadig viktigere brikke i det europeiske skylandskapet. Microsoft åpnet egne Azure-datasentre i Norge, ifølge Microsofts offisielle kunngjøring, og landet har siden tiltrukket seg investeringer fra både Google, Cloudflare og flere AI-fokuserte skyselskaper, samtidig som spørsmål om europeisk skysuverenitet preger innkjøpsbeslutninger i offentlig sektor. Med mer infrastruktur lokalt følger også mer avhengighet, og dermed mer eksponering når noe går galt et annet sted i et globalt nettverk disse plattformene er del av.
Mange norske selskaper bruker i praksis en kombinasjon av flere skyleverandører, ofte uten å ha kartlagt fullt ut hvilke avhengigheter som finnes på tvers. Et Cloudflare-avbrudd som rammer Workers KV kan for eksempel påvirke autentiseringslogikk som i sin tur stopper tilgang til en tjeneste som kjører på AWS eller Google Cloud. Denne typen kaskadefeil er vanskelig å oppdage før den faktisk inntreffer, og understreker verdien av å teste feilscenarioer proaktivt fremfor å anta at redundans løser problemet automatisk.
Historisk kontekst: fra sjeldne katastrofer til hyppige småfeil
For ti år siden var et skyavbrudd typisk en sjelden, dramatisk hendelse som fikk store oppslag: hele regioner nede i timevis, e-handelsselskaper som mistet inntekter i millionklassen på minutter. I 2026 ser mønsteret annerledes ut. Hendelsene er hyppigere, men også mindre og mer avgrensede. Det gjenspeiler dels at skyleverandørene har blitt flinkere til å isolere feil til enkeltregioner eller enkelttjenester, men det betyr også at driftsteam må overvåke langt flere potensielle feilpunkter enn før.
Denne utviklingen henger sammen med kompleksiteten som har bygget seg opp i moderne skyarkitektur. En enkelt applikasjon kan i dag være avhengig av titalls separate administrerte tjenester, fra objektlagring og køer til AI-inferens og edge-funksjoner. Hver av disse tjenestene er en egen feilkilde. Google Cloud sin egen liste over berørte tjenester i us-west1-hendelsen talte 33 ulike tjenester, noe som i seg selv illustrerer hvor mange bevegelige deler en enkelt regional forstyrrelse kan berøre samtidig.
Markedskonsekvenser: tillit, prising og forhandlingsmakt
Gjentatte driftsforstyrrelser påvirker ikke bare oppetid, de påvirker også hvordan virksomheter forhandler avtaler med skyleverandørene. Selskaper som har opplevd flere mindre avbrudd i løpet av et år, bruker i økende grad denne historikken som forhandlingskort for bedre kompensasjonsvilkår i tjenesteavtaler (SLA-er). Samtidig ser man at leverandører som AWS bruker perioder med relativ driftsstabilitet til å annonsere prisreduksjoner, som de 30 prosentene på Glue 6.0, delvis for å holde kundelojaliteten oppe mens konkurrentene sliter med synlige driftsproblemer.
Det er også en tydelig kommersiell dimensjon i multisky-strategien flere selskaper nå forfølger. Lanseringen av Azure Multicloud Interconnect med AWS som første partner er ikke bare en teknisk nyhet, det er et signal om at selv de største skygigantene innser at kundene vil unngå å være låst til én enkelt leverandørs feilpunkter. For mange nordiske IT-avdelinger er dette i tråd med en strategi de allerede har startet på egen hånd: å spre kritiske arbeidslaster over flere leverandører for å redusere risikoen for at ett enkelt avbrudd stopper hele driften.
Konkurransesammenligning: hvordan måler leverandørene seg mot hverandre
| Kriterium | Google Cloud | Cloudflare | AWS |
|---|---|---|---|
| Hendelsesmønster august 2026 | Ett stort, avgrenset avbrudd | Mange små, hyppige hendelser | Få hendelser, moderat varighet |
| Årsakstype | Fysisk fibervedlikehold | Programvareustabilitet + fiberbrudd | Ikke offentliggjort i detalj |
| Åpenhet om hendelser | Detaljert offentlig hendelsesrapport | Løpende statusoppdateringer | Mindre detaljerte offentlige rapporter |
| Nylig prisnyhet | Ingen store prisendringer i august | Ingen store prisendringer i august | Glue 6.0: cirka 30% lavere pris |
| Strategisk augustnyhet | Ingen større produktlansering | Fortsatt utbygging av edge-nettverk | Multicloud Interconnect med Azure |
Det som skiller leverandørene mest fra hverandre er ikke nødvendigvis hvor ofte de feiler, men hvor åpne de er om det når det skjer, en dynamikk som også preger den bredere konkurransen mellom edge-leverandører som Cloudflare og Akamai. Google Cloud sin praksis med å publisere detaljerte, tidsstemplede hendelsesrapporter gir kundene et faktagrunnlag å vurdere risiko mot. Cloudflare oppdaterer status løpende, men med mindre dybde i etterfølgende analyser. Denne forskjellen i åpenhet kan i seg selv bli en konkurransefaktor etter hvert som kunder blir mer bevisste på driftshistorikk som en del av leverandørvalget.
Hva bør norske IT-team gjøre nå
Det første steget er å kartlegge faktiske avhengigheter på tvers av skyleverandører, ikke bare hvilke tjenester som brukes direkte, men hvilke tredjepartstjenester som igjen er avhengige av dem. Et selskap som bruker en identitetsleverandør bygget på Cloudflare Workers, bør vite det, selv om selskapets egen produksjon kjører på AWS.
Det andre steget er å teste feilscenarioer aktivt fremfor passivt. Chaos engineering, altså kontrollert simulering av feil i produksjonslignende miljøer, har lenge vært en beste praksis hos de store teknologiselskapene, men er fortsatt underutnyttet i mange nordiske virksomheter. Gitt hvor hyppig mindre avbrudd nå forekommer, er det mer sannsynlig enn før at et selskap vil oppleve en reell hendelse i løpet av et gitt kvartal.
Det tredje steget er å revurdere SLA-forventninger. Mange kontrakter er skrevet med tanke på store, sjeldne katastrofer, men gir lite beskyttelse mot hyppige, mindre forstyrrelser som samlet sett kan koste like mye i tapt produktivitet. Det er verdt å spørre leverandøren direkte hvordan kompensasjon beregnes for en måned med flere små hendelser fremfor én stor.
Fem prediksjoner for skydrift fremover
- Antallet små, regionalt avgrensede hendelser vil trolig fortsette å øke i takt med at skytjenestene blir mer finkornede og tjenesteantallet per plattform vokser.
- Flere leverandører vil sannsynligvis følge Google Cloud sitt eksempel med mer detaljerte offentlige hendelsesrapporter, drevet av kundekrav om åpenhet.
- Multisky-tilkobling, som Azure Multicloud Interconnect med AWS, vil trolig utvides til flere leverandørpar i løpet av det neste året, ettersom kunder etterspør enklere failover mellom skyer.
- Fysisk infrastruktur, som fiberforbindelser og strømforsyning, vil fortsette å være en av de vanligste enkeltårsakene til avbrudd, uavhengig av hvor moden programvarelaget blir.
- Nordiske virksomheter med kritiske arbeidslaster vil i økende grad kreve regional isolasjon som avtalefestet krav, ikke bare som teknisk anbefaling, i fremtidige skyavtaler.
Det underliggende laget: hvorfor Kubernetes-modenhet spiller inn
En del av forklaringen på hvorfor enkelte hendelser blir avgrenset mens andre sprer seg, ligger i modenheten til orkestreringslaget under skytjenestene. AWS annonserte støtte for Kubernetes 1.36 i Amazon EKS og EKS Distro fra 2. juni 2026, ifølge EU Cloud Cost sin gjennomgang, og rullet støtten ut i samtlige regioner der EKS er tilgjengelig, inkludert GovCloud i USA. Nyere Kubernetes 1.37-oppgraderinger følger samme mønster med gradvis, regionsvis utrulling. Denne typen jevnlig, forutsigbar versjonsoppgradering av det underliggende containerlaget er nettopp det som gjør det mulig å isolere feil til enkelttjenester fremfor at de sprer seg til hele klynger.
Google Cloud sin evne til å begrense us-west1-hendelsen til nettopp den ene regionen, i stedet for at den forplantet seg globalt, henger sammen med samme prinsipp: godt isolerte kontrollplan og separate nettverkssoner per region. Cloudflare sitt utfordring er annerledes, siden edge-nettverket per design er tettere sammenvevd på tvers av lokasjoner for å minimere ventetid for sluttbrukere. Den samme arkitekturen som gjør Cloudflare raskt, gjør det også mer utsatt for at en enkelt feil i et delt kontrollplan brer seg til flere produkter samtidig, slik man så med R2, Durable Objects og Workers KV i samme uke.
For norske driftsteam er dette et nyttig rammeverk å vurdere leverandører etter: hvor godt er kontrollplanet isolert per region eller sone, og hva skjer med de andre tjenestene dine dersom én komponent i samme sone svikter? Spørsmålet er langt mer konkret enn generelle oppetidsgarantier, og det er noe man faktisk kan teste gjennom kontrollerte feilinjeksjoner i egne testmiljøer før man er avhengig av svaret i produksjon.
Hvordan avbruddene skiller seg fra tidligere store hendelser
Sammenlignet med tidligere, mer alvorlige hendelser i den samme regionen, som det tidligere avbruddet i Nederland omtalt tidligere i år hvor kunder opplevde rundt 12 timers nedetid, fremstår august-hendelsene som langt mer begrensede i omfang. Det er en villedende trøst dersom man ser bort fra frekvensen. Tolv timer nede én gang i året er alvorlig, men forutsigbart å planlegge rundt. Flere timers samlet nedetid fordelt på ti eller flere separate hendelser i løpet av én måned er vanskeligere å planlegge for, fordi driftsteamet aldri helt vet når neste episode kommer, eller hvilken tjeneste som rammes.
Dette skiftet fra sjeldne, store hendelser til hyppige, små forstyrrelser er trolig den viktigste driftsmessige trenden å følge med på fremover for enhver virksomhet som er avhengig av offentlig sky. Det krever en annen type beredskap enn tradisjonell katastrofegjenoppretting, nemlig kontinuerlig overvåking og raske, automatiserte fallback-mekanismer fremfor sjeldent testede nødprosedyrer.
Ofte stilte spørsmål
Hva forårsaket Google Cloud-avbruddet 20. august 2026?
Ifølge Google Cloud sin egen hendelsesrapport skyldtes forstyrrelsen i us-west1 rutinemessig fibervedlikehold som gikk galt, ikke et cyberangrep eller en programvarefeil. Hendelsen varte fra klokken 08.00 til 10.22 amerikansk Stillehavstid og påvirket flere titalls tjenester.
Hvor lenge varte Google Cloud-avbruddet egentlig?
Google selv oppgir 2 timer og 22 minutter for kjerneperioden i den offisielle hendelsesrapporten, mens den offisielle sammendragsloggen viser 2 timer og 45 minutter. Uavhengig overvåking fra tredjeparter målte en reell påvirkningsperiode på opp mot 3 timer og 40 minutter før alt var normalisert.
Hvorfor hadde Cloudflare så mange hendelser i august?
Cloudflare opplevde en klynge på 13 separate hendelser mellom 7. og 14. august knyttet til tjenester som R2, Durable Objects og Workers KV, etterfulgt av en 90 minutter lang degradering 26. august og et fiberbrudd i Istanbul mot slutten av måneden. Årsakene varierte fra programvareustabilitet til fysisk infrastruktursvikt.
Ble norske virksomheter direkte påvirket av disse avbruddene?
De fleste hendelsene var regionalt avgrensede til amerikanske eller tyrkiske lokasjoner, men norske virksomheter med global lastbalansering, replikerte databaser eller tredjepartstjenester bygget på de berørte plattformene kan ha opplevd indirekte konsekvenser gjennom kaskadeeffekter.
Er AWS mer pålitelig enn Google Cloud og Cloudflare?
I august 2026 hadde AWS færre og kortere registrerte hendelser enn både Google Cloud og Cloudflare, men det er for tidlig å trekke en generell konklusjon om langsiktig pålitelighet basert på én enkelt måned. Historisk har alle tre leverandørene hatt egne større avbrudd i ulike perioder.
Hva er Azure Multicloud Interconnect?
Det er en administrert tjeneste i offentlig forhåndsvisning som gir privat tilkobling mellom Azure og andre skyleverandører, med AWS som den første støttede partneren. Tjenesten er ment å forenkle multisky-arkitektur og redusere avhengigheten av offentlig internett for trafikk mellom skyene.
Bør bedrifter vurdere multisky-strategi etter august-hendelsene?
Mange IT-ledere bruker nå hendelsesmønsteret fra august som argument for å spre kritiske arbeidslaster over flere leverandører. Multisky reduserer risikoen for at ett enkelt leverandørutfall stopper hele driften, men øker samtidig kompleksiteten i overvåking og drift, noe som må veies opp mot den økte robustheten.
Hvordan kan jeg følge med på fremtidige skyavbrudd i sanntid?
Google Cloud, Cloudflare og AWS publiserer alle egne offentlige statussider med løpende oppdateringer, mens uavhengige tjenester som Is Internet Up og What is down? samler og sammenligner data på tvers av leverandører for å gi et mer helhetlig bilde av driftshistorikken.
