Norske og nordiske IT-avdelinger står stadig oftere overfor det samme valget: skal trafikken sikres og caches gjennom Cloudflares globale edge-nettverk, eller skal man bygge videre på Google Cloud CDN og Cloud Armor tett integrert med resten av GCP-miljøet? Spørsmålet dukker opp hver gang et nytt prosjekt skal driftsettes, og svaret er sjeldent åpenbart fordi de to plattformene er bygget etter helt ulik logikk. Denne artikkelen går gjennom arkitektur, pris, ytelse, sikkerhet og edge compute, med konkrete tall du kan bruke i egen anbudsvurdering. Se også vår oversikt over sky og infrastruktur for flere sammenligninger av skytjenester relevante for nordiske virksomheter.

Cloudflare selger seg inn som en skyagnostisk “front door” som kan stå foran hvilken som helst opprinnelsesserver, uansett om den kjører hos AWS, Azure, on-prem i et norsk datarom eller i Google Cloud selv. Google Cloud CDN er derimot bygget som et cache-lag tett vevd inn i Google Cloud Load Balancing, og krever i praksis en GCP-backend for å fungere fullt ut. Den forskjellen preger alt fra pris til hvor mye man låser seg til én leverandør, og den er kjernen i denne sammenligningen.

Hvorfor CDN- og WAF-valget er blitt viktigere for nordiske virksomheter

Trafikkveksten hos nordiske nettsteder og API-er har gjort at flere selskaper i Norge, Sverige, Danmark og Finland nå må ta et bevisst valg om edge-strategi. Samtidig har trusselbildet endret seg. ENISA sin trusselrapport for 2025 viser at DDoS-angrep utgjør rundt 76,7 prosent av registrerte hendelser i det undersøkte datasettet for Europa, noe som gjør robust DDoS- og WAF-beskyttelse til en forutsetning heller enn et tillegg for enhver virksomhet med kundevendt trafikk.

Samtidig legger EUs personvernregler og norsk datatilsyn stadig større vekt på hvor data faktisk behandles og caches. Google Cloud har to regioner i Norden: europe-north1 i Hamina i Finland og europe-north2 i Stockholm i Sverige, begge markedsført som lavutslipps-datasentre. Norge og Danmark har foreløpig ingen egen GCP-region, så norske og danske selskaper som velger Google Cloud CDN, ruter typisk trafikken gjennom Finland eller Sverige. Cloudflare løser dette annerledes: selskapet driver et globalt anycast-nettverk med noder i de nordiske hovedstedene, inkludert Oslo, der Cloudflare i 2026 åpnet sitt 75. datasenter globalt (se vår dekning av Cloudflare-etableringen i Oslo).

For en FinOps-ansvarlig eller sikkerhetsarkitekt i Norden handler valget derfor om tre ting samtidig: hvor nær brukeren kan innholdet leveres fra, hvor forutsigbar kostnaden er når trafikken vokser, og hvor mye fleksibilitet man beholder til å bytte skyleverandør senere. De neste avsnittene går i detalj på nettopp disse tre dimensjonene.

Arkitektur: skyagnostisk edge mot GCP-native cache-lag

Cloudflare fungerer som et lag foran hvilken som helst opprinnelsesserver. Man peker DNS-en mot Cloudflare, og trafikken går gjennom deres anycast-nettverk før den når origin, uavhengig av om origin ligger hos AWS, Azure, en lokal norsk hosting-leverandør eller Google Cloud selv. Dette gjør Cloudflare til det nærmeste man kommer en universell edge-plattform, og forklarer hvorfor selskapet ofte velges av organisasjoner med multi-cloud-arkitektur eller hybride miljøer med on-prem-komponenter i Norge.

Google Cloud CDN krever derimot at man setter opp en global HTTP(S)-lastbalanserer inne i GCP, koblet til Google-backends som Compute Engine, Cloud Storage eller Cloud Run. Det betyr at Google Cloud CDN i praksis ikke kan caches foran en origin som ligger hos en annen skyleverandør, med mindre man setter opp kompliserte omveier. For selskaper som allerede har hele arkitekturen sin i Google Cloud, inkludert logging, IAM og nettverksruting, gir dette en sømløs opplevelse. For alle andre er det en reell begrensning.

Denne strukturelle forskjellen har også konsekvenser for edge compute. Cloudflare tilbyr Workers, en fullverdig edge compute-plattform der man kan kjøre JavaScript, TypeScript eller WebAssembly nær brukeren, uten å måtte administrere servere. Google Cloud CDN er hovedsakelig et cache-lag uten generisk edge-kjøretid. Skal man kjøre logikk nær brukeren i GCP, må man sette opp Cloud Functions eller Cloud Run bak lastbalansereren, noe som legger til et ekstra hopp og økt kompleksitet sammenlignet med Cloudflares innebygde modell.

Spesifikasjoner side ved side

Tabellen under oppsummerer de tekniske og kommersielle egenskapene som betyr mest for et nordisk driftsteam som skal velge mellom de to plattformene.

EgenskapCloudflareGoogle Cloud CDN + Cloud Armor
Edge-nettverkGlobalt anycast-nettverk i mer enn 330 byer i over 120 landBygget på Googles globale nettverk, markedsført med “200+ locations” for innholdslevering
Nordisk tilstedeværelseNode i Oslo (datasenter nr. 75), samt Stockholm, København og HelsingforsRegioner i Hamina (Finland) og Stockholm (Sverige), ingen egen region i Norge eller Danmark
Krav til originSkyagnostisk, fungerer foran enhver origin (AWS, Azure, on-prem, GCP)Krever GCP HTTP(S)-lastbalanserer og Google-backend
Edge computeCloudflare Workers: JavaScript, TypeScript og WebAssembly på edgeIngen generisk edge compute, krever Cloud Functions eller Cloud Run bak lastbalanserer
GratisnivåJa, gratis plan med CDN og grunnleggende WAF (5 egendefinerte regler)Nei, ren forbruksbasert prising fra første GiB
Prismodell CDNFlat, plan-basert med båndbredde inkludert på de fleste nivåer100 % forbruksbasert: betaling per GiB egress, cache fill og HTTP-forespørsel
WAF-prisingInkludert i plan (Pro/Business), egne regler skalerer med plannivåCloud Armor Standard: per policy, per regel og per forespørsel
DDoS-beskyttelseInkludert på alle nivåer, ubegrenset i praksisAdaptive Protection kun i Cloud Armor Enterprise-nivåene
SupportE-post, kunnskapsbase, telefon, chat og 24/7 live-representanter på høyere planerPrimært chat- og casebasert support gjennom Google Cloud-konsollen
Egnet driftsmodellMulti-cloud, hybrid og on-prem-tunge miljøerRene Google Cloud-miljøer med tett kobling mot øvrige GCP-tjenester
API-sikringWAF, Bot Management og Zero Trust i samme økosystemCloud Armor kombineres ofte med Apigee for API-trafikk

Prissammenligning: flat plan mot ren forbruksbasert modell

Prislogikken er der de to plattformene skiller lag mest tydelig. Cloudflare selger inn en forutsigbar, plan-basert modell der båndbredde stort sett er inkludert, mens Google Cloud CDN fakturerer hver eneste gigabyte som går gjennom nettverket, i tråd med Googles offisielle prisside for Cloud CDN. For et nordisk mediehus eller en e-handelsaktør med sesongvariert trafikk kan denne forskjellen bety titalls prosent i årlig regning, avhengig av trafikkmønster.

Nivå / komponentCloudflareGoogle Cloud CDN / Cloud Armor
InstegsnivåGratis: $0 per domene, CDN + 5 WAF-reglerIngen gratisnivå, betaling fra første GiB
Mellomnivå (selvbetjent)Pro: cirka $20/mnd (årlig) eller $25/mnd (månedlig) per domene, 20 WAF-reglerCloud CDN 0–102 400 GiB: $0,0375 per GiB per måned per prosjekt
ForretningsnivåBusiness: cirka $200/mnd (årlig) eller $250/mnd (månedlig), 100 WAF-reglerCloud CDN 102 400–512 000 GiB: $0,03 per GiB
Høyt volumEnterprise: ingen offentlig listepris, typisk fra $5 000/mnd for enkeltstående eiendomCloud CDN 512 000–1 024 000 GiB: $0,025 per GiB, over 1 024 000 GiB: $0,02 per GiB
Stor skalaEnterprise, global fotavtrykk: $25 000–$80 000+/mnd ifølge markedsdata for 2. kvartal 2026Cloud Armor Enterprise Annual: $3 000/mnd inkludert 100 beskyttede ressurser
WAF/DDoS instegspunktInkludert i Pro/Business-plan uten egen faktureringCloud Armor Standard: fra $5 per policy per måned + $1 per regel + $0,75 per million forespørsler
WAF entry enterpriseKun quote-basert, ingen offentlig satsCloud Armor Enterprise Pay-go: $200/mnd for opptil 2 beskyttede ressurser

Det er verdt å merke seg at Google Cloud sin modell gir svært granular kostnadskontroll: man betaler nøyaktig for det man bruker, ned til hver policy, regel og million forespørsler i Cloud Armor. Det gir god budsjetteringspresisjon for en organisasjon med jevn, forutsigbar trafikk, men kan bli overraskende dyrt ved trafikktopper, for eksempel under Black Friday-kampanjer hos norske nettbutikker. Cloudflares flate modell gjør motsatt: man betaler samme sum uansett trafikkmengde innenfor planens rammer, noe som beskytter mot budsjettoverraskelser, men gir mindre finstemt kostnadskontroll for team som ønsker å optimalisere krone for krone.

For enterprise-avtaler er begge plattformer i stor grad forhandlingsbare. Markedsdata for 2026 antyder at Cloudflare Enterprise-kontrakter typisk starter rundt $5 000 per måned for en enkelt eiendom med moderat trafikk, og kan skalere til over $80 000 per måned for globale driftsmiljøer med full sikkerhetsstack og Zero Trust inkludert. Google Cloud Armor holder seg til en mer transparent, offentlig prisliste helt opp til Enterprise-nivå, noe som gjør det enklere å estimere kostnad på forhånd uten å gå gjennom en salgsprosess.

Ytelse og edge-utbredelse i Norden

Når det gjelder rå geografisk utbredelse har Cloudflare et klart fortrinn: over 330 byer i mer enn 120 land, mot Googles offentlig kommuniserte “200+ locations” for Cloud CDN. For nordiske brukere er imidlertid den lokale tilstedeværelsen viktigere enn det globale tallet. Cloudflare har node i Oslo siden åpningen av datasenter nummer 75 i det globale nettverket, i tillegg til noder i Stockholm, København og Helsingfors. Google Cloud sin nærmeste infrastruktur for Norge og Danmark er regionene i Hamina i Finland og Stockholm i Sverige, siden det ikke finnes en egen GCP-region i verken Norge eller Danmark per i dag.

Selve responstidsmålingene er ikke entydige. Eldre sammenlignende tester har vist at Google Cloud CDN i enkelte scenarioer var noen millisekunder raskere enn konkurrentene, mens Cloudflare kom rett bak. Dette illustrerer et viktig poeng: flere edge-noder er ikke automatisk lik lavere responstid, fordi ruting, cache-hit-rate og backend-ytelse påvirker mer enn selve antallet PoP-er. For et norsk selskap med brukere konsentrert i Oslo-regionen kan begge løsninger prestere godt, forutsatt at cachestrategien er riktig konfigurert og at origin selv ikke er flaskehalsen.

Det som derimot er tydelig dokumentert er bruksmønsteret: analyser fra 2026 peker på at Cloudflare er betydelig mer utbredt enn Google Cloud CDN på tvers av nettsteder globalt, drevet av at Cloudflare også fungerer som DNS-leverandør og sikkerhetslag for et bredt spekter av nettsteder utover ren CDN-bruk. Det gjør Cloudflare til et de facto-standardvalg i mange bransjer, mens Google Cloud CDN i praksis er reservert for organisasjoner som allerede har investert tungt i resten av Google Cloud-stacken.

Ytelsesbenchmarks: hva sier uavhengige kilder

Å finne en ferskt, direkte sammenlignende ytelsesmåling mellom akkurat Cloudflare og Google Cloud CDN for nordisk trafiko er ikke rett frem, siden ingen av de store overvåkningsselskapene publiserer et løpende Norden-spesifikt dashboard for nettopp disse to tjenestene. Det man derimot har er tre uavhengige datapunkter som til sammen tegner et bilde av hvor de to plattformene er sterkest, og de bør leses sammen heller enn hver for seg.

For det første dokumenterer Googles egen oversikt over regioner og soner at Cloud CDN sin ytelse i Norden i praksis er bundet til to fysiske punkter: Hamina i Finland og Stockholm i Sverige. Det gir en fast, målbar avstand for norske og danske brukere, i motsetning til Cloudflares distribuerte anycast-modell der responstiden i teorien avhenger av nærmeste av over 330 noder globalt. For det andre viser markedsanalysen fra BlazingCDN sin gjennomgang av Cloudflares offentlige prisplaner at selskapet har bygget hele forretningsmodellen sin rundt at trafikk skal treffe et lokalt PoP før den eventuelt går videre til origin, noe som i praksis reduserer avhengigheten av én enkelt regions ytelse. For det tredje bekrefter Cloudflares tekniske dokumentasjon av hvordan nettverket fungerer at anycast-routing gjør at samme domenenavn kan besvares fra ulike fysiske noder avhengig av hvor forespørselen kommer fra, noe som er den grunnleggende mekanismen bak den brede geografiske dekningen.

Konklusjonen fra disse tre kildene sett i sammenheng er nyansert. Google Cloud CDN kan gi svært god og forutsigbar ytelse for trafikk som uansett skal til Finland eller Sverige, fordi Google har lagt ned betydelig arbeid i backbone-nettverket mellom sine egne regioner. Cloudflare vinner på bredde og fleksibilitet: selskapet trenger ikke at trafikken går til en bestemt region i det hele tatt, siden caching og sikkerhetsfiltrering skjer ved den noden som fysisk er nærmest brukeren, inkludert i Oslo. For en tjeneste med brukere spredt over hele Norden, uten en klar konsentrasjon i Sverige eller Finland, peker dette i retning av at Cloudflares modell gir jevnere responstid på tvers av regionen som helhet.

Skyavhengighet og exit-strategi

Et spørsmål som sjelden får nok oppmerksomhet før kontrakten er signert, er hvor vanskelig det blir å bytte leverandør senere. Google Cloud CDN sin avhengighet av en global HTTP(S)-lastbalanserer og Google-backends betyr at hele cache-konfigurasjonen, sikkerhetsreglene i Cloud Armor og eventuell Apigee-oppsett må bygges om fra bunnen dersom man senere velger å flytte origin til en annen skyleverandør. Dette er ikke unikt for Google, men det er verdt å sammenligne med hvordan vi tidligere har beskrevet lignende bindinger i vår gjennomgang av OIDC og CA-rotasjon i AWS EKS, der tett integrasjon mot én skyleverandørs identitetssystem skaper akkurat samme type friksjon ved en eventuell migrasjon.

Cloudflare sin skyagnostiske modell reduserer denne risikoen betraktelig, siden origin kan flyttes fritt mellom AWS, Azure, GCP eller on-prem uten at DNS-oppsettet eller sikkerhetsreglene i Cloudflare må endres nevneverdig. Dette har en kostnad i motsatt retning: dersom man en dag ønsker å forlate Cloudflare til fordel for en ren GCP-løsning, må man bygge opp en helt ny lastbalanserer- og Cloud Armor-konfigurasjon fra scratch, siden det ikke finnes noe direkte importverktøy mellom de to systemene. For en nordisk virksomhet med krav om leverandøruavhengighet i egen IT-strategi, for eksempel innenfor offentlig sektor eller kritisk infrastruktur, bør denne typen bindingsrisiko vurderes eksplisitt før man signerer en flerårig avtale med noen av leverandørene.

Sikkerhet: Cloudflare WAF mot Google Cloud Armor

Sikkerhetslaget er der forskjellen i filosofi blir mest praktisk. Cloudflare pakker WAF, DDoS-beskyttelse og bot-håndtering inn i abonnementet, uten separat fakturering per regel eller forespørsel på de fleste planer. Google Cloud Armor er derimot bygget som en granulær tjeneste, dokumentert i Googles offisielle oversikt over Cloud Armor: man betaler per sikkerhetspolicy, per regel innenfor policyen, og per million forespørsler som filtreres. Ifølge Googles offisielle prisside for Cloud Armor koster Standard-nivået fra $5 per policy per måned pluss $1 per regel og $0,75 per million forespørsler globalt, mens Enterprise-nivåene ($200/mnd Pay-go eller $3 000/mnd Annual) låser opp Adaptive Protection, som bruker maskinlæring til å oppdage volumetriske DDoS-angrep automatisk.

Gitt at ENISA rapporterer at DDoS-angrep står for rundt tre firedeler av registrerte sikkerhetshendelser i Europa, blir spørsmålet om hvor Adaptive Protection og tilsvarende Cloudflare-funksjoner ligger i prisstrukturen, avgjørende for et realistisk kostnadsbilde. Hos Cloudflare er DDoS-beskyttelse i praksis ubegrenset og inkludert selv på lavere plannivåer, mens man hos Google Cloud må opp på Enterprise-nivåene i Cloud Armor for å få tilsvarende automatisert beskyttelse. Det betyr at et lite norsk selskap som kun trenger grunnleggende WAF, kan komme billigere unna med Cloudflares Business-plan enn med en fullverdig Cloud Armor Enterprise-oppsett, mens en stor virksomhet med presist definerte sikkerhetspolicyer kan finne Cloud Armors granularitet mer kostnadseffektiv i det lange løp.

For API-tung trafikk kombinerer mange Google Cloud-kunder Cloud Armor med Apigee for å håndtere autentisering, rate-limiting og trafikkstyring i samme økosystem. Cloudflare tilbyr et tilsvarende sett med API-sikringsfunksjoner integrert i samme grensesnitt som WAF og Bot Management, uten å måtte legge til et separat produkt. Har man allerede lest vår sammenligning av Cloudflare og Akamai på markedsandel, vil man kjenne igjen mønsteret: Cloudflare vinner på enkelhet og bredde, mens de GCP-native alternativene vinner på dybde innenfor eget økosystem.

Edge compute: Workers mot Cloud Functions bak lastbalanserer

Skal man kjøre egen kode nær brukeren, er forskjellen mellom plattformene enda tydeligere. Cloudflare Workers lar utviklere deploye JavaScript, TypeScript eller WebAssembly direkte til edge-nettverket, med kaldstarttid målt i millisekunder fordi kjøretiden er bygget på V8 isolates i stedet for tradisjonelle containere. Dette egner seg godt til A/B-testing, personalisering, autentisering ved kanten og enkel API-logikk som må kjøre så nær sluttbrukeren som mulig, noe vi har gått i dybden på i vår oppsettguide for Cloudflare Workers.

Google Cloud CDN har ingen tilsvarende innebygd edge-kjøretid. Skal man kjøre logikk i forbindelse med cache-laget i GCP, må man sette opp Cloud Functions eller Cloud Run bak den globale HTTP(S)-lastbalansereren, noe som i praksis flytter kompute-laget bort fra selve edgen og inn i en av Googles regioner. Det er verdt å sammenligne kaldstart-tider direkte: i vår tidligere test av Cloudflare Workers mot Azure AKS målte vi Workers til rundt 2 millisekunder kaldstart mot 200 millisekunder for en containerbasert løsning. Google Cloud Run ligger nærmere AKS enn Workers i denne sammenhengen, siden begge er containerbaserte kjøretider snarere enn isolatbaserte.

Konsekvensen for et nordisk utviklingsteam er konkret. Trenger man kun å cache statisk og dynamisk innhold nærmere brukeren, er begge plattformer gode nok. Skal man derimot bygge logikk som personalisering, geoblokkering, header-manipulasjon eller enkel autentisering direkte i edge-laget, gir Cloudflare Workers en vesentlig enklere utviklingsopplevelse enn å sette opp og vedlikeholde Cloud Functions eller Cloud Run bak Google sin lastbalanserer.

Datasuverenitet og GDPR i en nordisk kontekst

Google Cloud sin regionmodell gir en fordel når det gjelder å dokumentere hvor data faktisk ligger. Med europe-north1 i Hamina og europe-north2 i Stockholm kan et norsk selskap konfigurere arbeidslaster slik at data i hvile forblir innenfor EU, noe som forenkler GDPR-dokumentasjon og interne personvernvurderinger. Siden Norge er del av EØS og ikke EU, gjelder GDPR likevel fullt ut, og norske virksomheter må uansett vurdere overføringsgrunnlag når data flyttes mellom jurisdiksjoner, selv innad i Norden.

Cloudflare opererer et globalt anycast-nettverk, noe som betyr at forespørselsmetadata og cachet innhold kan behandles i flere jurisdiksjoner samtidig, avhengig av hvilken node som er nærmest brukeren. Cloudflare tilbyr databehandleravtaler og lokaliseringskontroller for virksomhetskunder, men det krever en bevisst konfigurasjon for å sikre at man oppfyller interne krav til datalokalisering. For en norsk offentlig etat eller en helseaktør med strenge krav til hvor persondata behandles, er dette et poeng som må avklares konkret med leverandøren før kontraktsignering, uavhengig av hvilken av de to plattformene man ender opp med.

Fem konkrete brukstilfeller: hvilken plattform passer hvor

Under følger fem typiske scenarioer fra nordiske virksomheter, og hvilken plattform som normalt gir best resultat basert på arkitektur og driftskrav.

Norsk nettbutikk med sesongtopper. En nettbutikk som opplever ti ganger normal trafikk under Black Friday og julehandelen, trenger en løsning der kostnaden ikke eksploderer samtidig med besøkstallet. Cloudflares flate plan-baserte prising, kombinert med DDoS-beskyttelse uten ekstra fakturering per forespørsel, gjør regningen forutsigbar selv når trafikken tidobles i løpet av noen timer. Med Google Cloud Armor ville hver eneste ekstra million forespørsler generert en direkte kostnad, noe som gjør budsjettplanleggingen mer krevende i en bransje der trafikktoppene er både kortvarige og vanskelige å estimere presist på forhånd.

Offentlig etat med data allerede i Google Cloud. En kommune eller statlig etat som allerede har migrert saksbehandlingssystemer og lagring til Google Cloud, har mye å vinne på å bli værende i samme økosystem for CDN og WAF. Cloud Armor gir tett integrasjon med eksisterende IAM-roller, logging i Cloud Monitoring og nettverksregler som allerede er definert, og forenkler samtidig dokumentasjonen av at persondata forblir i regionene i Hamina eller Stockholm. Å innføre Cloudflare på toppen ville krevd en ny leverandøravtale, nye tilgangsstyringsrutiner og en separat revisjon av databehandleravtalen, uten en tilsvarende klar gevinst for en etat som ikke opererer på tvers av flere skyer.

Fintech-selskap med API-tung arkitektur på tvers av AWS og GCP. Et fintech-selskap som kjører betalingstjenester på AWS og dataanalyse i Google Cloud, trenger et sikkerhetslag som fungerer likt uansett hvor trafikken går. Cloudflare kan settes opp som en skyagnostisk sikkerhetsgrense foran begge miljøene, med samme WAF-regelsett, samme bot-håndtering og samme rate-limiting-logikk. Alternativet, å sette opp separate Cloud Armor-policyer for GCP-delen og en annen løsning for AWS-delen, dobler både konfigurasjonsarbeidet og risikoen for at reglene driver fra hverandre over tid.

Mediehus med behov for personalisering og A/B-testing ved kanten. Et nordisk mediehus som ønsker å vise ulike forsider basert på lesers geografi, abonnementsstatus eller enhetstype, trenger kode som kjører så nær brukeren som mulig for å unngå ekstra rundtur til origin. Cloudflare Workers gjør dette mulig med kaldstarttid målt i millisekunder, og lar utviklerne deploye endringer uten å administrere egen infrastruktur. Skulle det samme bygges i Google Cloud, må man sette opp Cloud Functions eller Cloud Run bak lastbalansereren, noe som legger til et ekstra nettverkshopp og gjør iterasjonssyklusen tregere for redaksjonelle team som ønsker å teste nye visningsvarianter raskt.

Scale-up med presist definerte sikkerhetsregler og jevn trafikk. Et modent SaaS-selskap med stabilt, godt forstått trafikkmønster og et sikkerhetsteam som ønsker finmasket kontroll over hver eneste WAF-regel, kan faktisk spare penger på Cloud Armors granulære modell. Når trafikkvolumet er kjent og forutsigbart, blir kostnaden per policy, regel og million forespørsler enklere å beregne nøyaktig enn en forhandlet Cloudflare Enterprise-avtale uten offentlig prisliste. Dette er det ene scenarioet i denne gjennomgangen der Google Cloud sin modell kommer klart bedre ut, forutsatt at selskapet allerede har kompetansen til å administrere Cloud Armor sine policyer i detalj.

Migrasjonsguide: fra Google Cloud CDN til Cloudflare (og omvendt)

En migrasjon mellom disse to plattformene er sjelden en ren teknisk øvelse. Her er stegene et nordisk driftsteam typisk bør gå gjennom, uansett retning.

  1. Kartlegg all eksisterende cache-konfigurasjon, TTL-verdier og cache-nøkler i dagens oppsett før noe endres.
  2. Dokumenter alle WAF-regler og sikkerhetspolicyer som er aktive i dag, inkludert egendefinerte regler og rate-limiting.
  3. Sett opp den nye plattformen parallelt med den gamle, uten å endre DNS ennå (skyggemodus).
  4. Test cache-hit-rate og responstid mot et representativt utvalg av nordisk trafikk, ikke bare fra ett testpunkt.
  5. Overfør WAF-regler én policy om gangen, og valider mot logger fra den gamle løsningen for å unngå falske positiver.
  6. Ved bytte til Cloudflare: verifiser at origin-serveren aksepterer trafikk kun fra Cloudflares IP-område for å hindre at angripere går utenom edge-laget.
  7. Ved bytte til Google Cloud CDN: sett opp global HTTP(S)-lastbalanserer og bekreft at backend-tjenesten støtter nødvendig cache-modus (CACHE_ALL_STATIC eller USE_ORIGIN_HEADERS).
  8. Flytt DNS gradvis med lav TTL, og overvåk feilrater time for time de første 48 timene.
  9. Behold den gamle konfigurasjonen aktiv i minst to uker som fallback før den avvikles permanent.
  10. Oppdater interne runbooks og varslingsregler slik at driftsteamet vet hvilken plattform som nå er kilde til sannhet ved en hendelse.

Fordeler og ulemper: Cloudflare

Cloudflare sin styrke ligger i bredde og enkelhet. Man får CDN, WAF, DDoS-beskyttelse, DNS og edge compute i samme grensesnitt, uten at man må stykke opp regningen per komponent. For nordiske selskaper med hybride eller multi-cloud-miljøer er dette ofte avgjørende, fordi Cloudflare fungerer likt uansett hvor origin ligger.

  • Fordel: Skyagnostisk, fungerer foran enhver origin uavhengig av skyleverandør.
  • Fordel: Flat, forutsigbar prising som ikke eksploderer ved trafikktopper.
  • Fordel: Innebygd edge compute (Workers) uten behov for separat kompute-tjeneste.
  • Fordel: Gratis nivå tilgjengelig, lav terskel for å starte.
  • Ulempe: Enterprise-priser er ikke offentlige, krever forhandling for større avtaler.
  • Ulempe: Mindre granulær kostnadskontroll enn Cloud Armors per-regel-modell for organisasjoner som ønsker finstemt budsjettering.

Fordeler og ulemper: Google Cloud CDN og Cloud Armor

Google Cloud sin styrke er dybde innad i eget økosystem. For selskaper som allerede kjører hele stacken i GCP, gir integrasjonen mot IAM, logging, Apigee og Cloud Monitoring en driftsmessig fordel som er vanskelig å matche med en tredjepartsløsning lagt oppå.

  • Fordel: Transparent, offentlig prisliste helt opp til Enterprise-nivå.
  • Fordel: Tett integrasjon med resten av GCP: IAM, logging, Apigee og Cloud Monitoring.
  • Fordel: Regional tilstedeværelse i Norden (Hamina og Stockholm) forenkler GDPR-dokumentasjon.
  • Fordel: Svært granulær kostnadskontroll per policy, regel og forespørsel.
  • Ulempe: Krever GCP-backend, fungerer dårlig foran origin hos andre skyleverandører.
  • Ulempe: Ingen gratisnivå, og Adaptive Protection krever Enterprise-nivå i Cloud Armor.
  • Ulempe: Ingen generisk edge compute, krever Cloud Functions eller Cloud Run bak lastbalanserer.

Kodeeksempel: grunnleggende cache-regel i begge plattformer

For å illustrere den praktiske forskjellen i konfigurasjon, viser eksemplene under hvordan man setter en enkel cache-regel for statiske filer i henholdsvis Cloudflare (via Workers) og Google Cloud (via gcloud-kommandolinjen).

// Cloudflare Worker: cache statiske filer i 24 timer ved kanten
export default {
  async fetch(request) {
    const cache = caches.default;
    let response = await cache.match(request);
    if (!response) {
      response = await fetch(request);
      response = new Response(response.body, response);
      response.headers.append("Cache-Control", "public, max-age=86400");
      await cache.put(request, response.clone());
    }
    return response;
  }
};
# Google Cloud CDN: aktiver caching på en backend-tjeneste
gcloud compute backend-services update BACKEND_SERVICE_NAME \
  --global \
  --enable-cdn \
  --cache-mode=CACHE_ALL_STATIC \
  --default-ttl=86400 \
  --client-ttl=86400

Forskjellen er talende: Cloudflare-eksempelet kjører direkte ved kanten uavhengig av hvor origin ligger, mens Google Cloud-kommandoen forutsetter at man allerede har en backend-tjeneste og global lastbalanserer satt opp inne i GCP. Dette er samme mønster vi så da vi sammenlignet AWS Fargate mot Google Cloud Run: GCP-tjenester er kraftige, men forutsetter at man allerede har akseptert å bygge innenfor Googles rammeverk.

Support og driftserfaring

Support-tilbudet skiller de to plattformene tydelig fra hverandre. Cloudflare tilbyr et bredt spekter av kanaler på høyere plannivåer: e-post, kunnskapsbase, telefon, chat og 24/7 live-representanter for Enterprise-kunder. Google Cloud CDN og Cloud Armor støtter seg primært på chat- og casebasert support gjennom Google Cloud-konsollen, supplert av omfattende offisiell dokumentasjon.

For et norsk driftsteam som opererer utenfor normal arbeidstid, kan tilgang til 24/7 telefonstøtte være utslagsgivende ved en pågående DDoS-hendelse klokken tre om natten. Samtidig er Google Cloud sin dokumentasjon generelt ansett som grundig og oppdatert, noe som reduserer behovet for å kontakte support i utgangspunktet for team som allerede kjenner GCP-økosystemet godt fra før, for eksempel etter å ha satt opp sikker lagring i Google Cloud Storage.

NIS2 og krav til driftskontinuitet ved kanten

For virksomheter som faller inn under NIS2-regelverket i Norge, altså digitalsikkerhetsloven, er valget av CDN og WAF ikke lenger bare et driftsspørsmål, men en del av risikostyringen som må dokumenteres overfor tilsynsmyndighetene. Kravene handler i stor grad om å kunne vise at man har vurdert leverandørrisiko, at man har en plan for hendelseshåndtering, og at kritiske tjenester ikke faller helt ut ved et enkelt utfall hos én leverandør. Dette er relevant uansett om man velger Cloudflare eller Google Cloud, men konsekvensene av et utfall arter seg ulikt.

Et utfall hos Cloudflare rammer typisk alle domener som ligger bak selskapets edge-nettverk samtidig, uavhengig av hvilken skyleverandør origin ligger hos. Et utfall i en av Googles regioner, for eksempel Hamina eller Stockholm, rammer i utgangspunktet kun trafikk som er rutet til nettopp den regionen, men til gjengjeld har man færre alternative regioner å falle tilbake på i Norden dersom den ene regionen blir utilgjengelig. Uansett valg bør et driftsteam som er underlagt NIS2 dokumentere en konkret failover-plan: for Cloudflare kan dette bety en sekundær DNS-oppsett som kan rute forbi edge-nettverket ved en fullstendig utilgjengelighet, mens man for Google Cloud bør vurdere om trafikken kan rutes mellom Hamina og Stockholm automatisk ved et regionalt utfall.

Det er også verdt å merke seg at begge leverandørene selv er attraktive mål for angrep nettopp fordi de sitter foran så mange kritiske tjenester samtidig. Et sikkerhetsteam i en NIS2-regulert virksomhet bør derfor ikke bare vurdere hvor godt CDN-en beskytter mot angrep rettet mot egen tjeneste, men også hvor robust leverandørens eget nettverk er mot storskala-hendelser som kan ramme svært mange kunder på én gang.

Verdikt: hvilken plattform bør nordiske virksomheter velge

Basert på gjennomgangen over gir dataene et ganske tydelig bilde. Cloudflare vinner på fleksibilitet, prisforutsigbarhet og edge compute, og er det naturlige valget for multi-cloud-miljøer, hybride arkitekturer og team som trenger å kjøre logikk nær brukeren uten å administrere egne servere. Med et gratisnivå, en klar oppgraderingsvei til Pro og Business, og innebygd DDoS-beskyttelse på alle nivåer, er terskelen for å komme i gang lav samtidig som plattformen skalerer til store enterprise-avtaler.

Google Cloud CDN og Cloud Armor vinner der virksomheten allerede har investert tungt i GCP, og ønsker maksimal kostnadskontroll ned til hver policy og regel. Den transparente prislisten helt til Enterprise-nivå gjør budsjettering enklere uten en salgsprosess, og regionene i Hamina og Stockholm gir et solid utgangspunkt for GDPR-dokumentasjon i en nordisk kontekst. Prisen for dette er redusert fleksibilitet: løsningen fungerer dårlig utenfor GCP, og mangler en innebygd edge compute-modell på linje med Workers.

For de fleste nordiske virksomheter uten et rendyrket, allerede etablert GCP-miljø, peker tallene i retning av Cloudflare som standardvalg for CDN og WAF, med Google Cloud Armor som et sterkt alternativ for organisasjoner som ønsker granulær kostnadskontroll og allerede lever tett integrert med resten av Google Cloud-stacken.

Den praktiske testen bør likevel alltid gjøres lokalt før man signerer en flerårig avtale. Sett opp en piloteringsperiode på fire til seks uker der man logger cache-hit-rate, responstid fra faktiske nordiske brukere og reell kostnad basert på egen trafikk, ikke leverandørens generelle markedsføringstall. Et driftsteam som har gjort denne øvelsen internt, kommer nesten alltid ut med et mer presist grunnlag for beslutningen enn det denne eller noen annen artikkel alene kan gi, rett og slett fordi trafikkmønsteret til hver enkelt virksomhet er forskjellig nok til å endre kalkylen.

Uansett hvilken retning man lander på, bør beslutningen dokumenteres skriftlig med begrunnelse, spesielt for virksomheter som er underlagt NIS2 eller tilsvarende krav til leverandørstyring. Det gjør det enklere å revurdere valget når trafikkmønsteret endrer seg, når prisstrukturen hos en av leverandørene endres, eller når en ny generasjon av edge compute-tjenester gjør dagens vurdering utdatert.

Ofte stilte spørsmål

Kan jeg bruke Cloudflare foran en backend som kjører i Google Cloud?

Ja. Cloudflare er skyagnostisk og fungerer foran enhver origin, inkludert servere eller lastbalanserere som kjører i Google Cloud. Man peker DNS-en mot Cloudflare og lar origin ligge uendret i GCP.

Har Google Cloud CDN en gratis plan slik Cloudflare har?

Nei. Google Cloud CDN er 100 prosent forbruksbasert fra første gigabyte, uten gratisnivå. Cloudflare tilbyr derimot en gratis plan med CDN og fem egendefinerte WAF-regler inkludert.

Hvorfor har ikke Google Cloud en egen region i Norge?

Google Cloud har foreløpig valgt å dekke det nordiske markedet fra regionene i Hamina i Finland (europe-north1) og Stockholm i Sverige (europe-north2), fremfor å bygge en egen region i Norge eller Danmark. Norske og danske kunder ruter dermed trafikken til en av disse to regionene.

Er Cloud Armor dyrere enn Cloudflare WAF?

Det kommer an på trafikkmønster. Cloud Armor Standard fakturerer per policy, regel og million forespørsler, noe som kan bli rimeligere ved lavt og stabilt volum. Cloudflares WAF er inkludert i Pro- og Business-planene uten egen fakturering, noe som ofte lønner seg ved høyt eller uforutsigbart volum.

Kan jeg kjøre egen kode ved kanten i Google Cloud CDN slik jeg kan med Cloudflare Workers?

Ikke direkte. Google Cloud CDN er hovedsakelig et cache-lag uten generisk edge-kjøretid. Skal man kjøre kode i forbindelse med cachingen, må man sette opp Cloud Functions eller Cloud Run bak Googles globale lastbalanserer, noe som gir høyere kaldstarttid enn Cloudflare Workers.

Hvor mye koster en Cloudflare Enterprise-avtale for et nordisk selskap?

Det finnes ingen offentlig listepris, men markedsdata for 2. kvartal 2026 peker på at instegsnivå for Enterprise typisk starter rundt $5 000 per måned for én eiendom med moderat trafikk, og kan skalere til over $80 000 per måned for global drift med full sikkerhetsstack.

Passer Cloudflare eller Google Cloud CDN best for en norsk offentlig etat?

Det avhenger av eksisterende infrastruktur. En etat som allerede kjører i Google Cloud, vil ofte finne Cloud CDN og Cloud Armor enklere å dokumentere opp mot GDPR-krav takket være regionene i Hamina og Stockholm. En etat med hybrid eller multi-cloud-arkitektur vil normalt finne Cloudflare enklere å standardisere på tvers av alle systemer.

Må jeg velge én av platformene, eller kan de kombineres?

De kan kombineres, men det øker kompleksiteten. Noen organisasjoner bruker Cloudflare som DNS- og sikkerhetslag foran en backend som selv bruker Google Cloud Load Balancing internt, men da bør man unngå dobbel caching av samme innhold for å hindre unødvendig kostnad og feilsøkingskompleksitet.