02 mei 2025·4 min
Van CDN naar platform: hoe de edge van Cloudflare uitbreidde
Lees hoe de edge van Cloudflare evolueerde van CDN-caching naar beveiligings- en ontwikkelaarsdiensten naarmate meer verkeer naar de netwerkperimeter verschuift.
Lees hoe de edge van Cloudflare evolueerde van CDN-caching naar beveiligings- en ontwikkelaarsdiensten naarmate meer verkeer naar de netwerkperimeter verschuift.
Een edge-netwerk is een verzameling servers verspreid over veel steden die “dichtbij” eindgebruikers staan. In plaats van dat elk verzoek helemaal terugreist naar de origin-servers van je bedrijf (of naar een cloudregio), kan de edge dat verzoek lokaal beantwoorden, inspecteren of doorsturen.
Denk eraan als het plaatsen van behulpzame medewerkers bij de ingangen van een locatie in plaats van alles bij het achterste kantoor te regelen. Sommige verzoeken kunnen meteen worden afgehandeld (zoals het serveren van een gecachte file), terwijl andere veilig worden doorgestuurd.
De perimeter is de grens waar buitenstaand internetverkeer je systemen voor het eerst ontmoet: je website, apps, API’s en de diensten die deze beschermen en routeren. Historisch behandelden veel bedrijven de perimeter als een smalle deuropening (DNS en een load balancer). Vandaag is het waar de drukste en risicovolste interacties plaatsvinden—inlogpogingen, API-aanroepen, bots, scraping, aanvallen en plotselinge pieken.
Naarmate meer werk online gaat en meer integraties op API’s vertrouwen, is het steeds praktischer verkeer via de perimeter te leiden zodat je consistente regels kunt toepassen—prestatie-optimalisaties, beveiligingscontroles en toegangsregels—voordat verzoeken je kerninfrastructuur bereiken.
Dit artikel volgt een ontwikkeling: eerst performance (CDN), daarna beveiliging aan de edge (DDoS, WAF, botcontrols, Zero Trust) en tenslotte ontwikkelaarstools (code draaien en data dichter bij gebruikers verwerken).
Het is geschreven voor niet-technische besluitvormers—kopers die leveranciers vergelijken, oprichters die afwegingen maken, en PM’s die het “waarom” en “wat verandert” nodig hebben, zonder netwerkboeken te moeten lezen.
Een traditionele CDN (Content Delivery Network) begon met een eenvoudige belofte: websites sneller laten aanvoelen door content vanaf een locatie dichter bij de bezoeker te serveren. In plaats van dat elk verzoek terugreist naar je origin-server (vaak een enkele regio of datacenter), houdt de CDN kopieën van statische bestanden—afbeeldingen, CSS, JavaScript, downloads—op veel points of presence (PoP’s). Wanneer een gebruiker een bestand opvraagt, kan de CDN lokaal reageren, waardoor latency afneemt en de druk op de origin vermindert.
In wezen focust een “CDN-only” setup op drie uitkomsten:
Dit model is vooral effectief voor statische sites, media-zware pagina’s en voorspelbare verkeerspatronen waar steeds dezelfde assets worden opgevraagd.
In de beginperiode beoordeelden teams CDN’s met een paar praktische metrics:
Deze cijfers waren belangrijk omdat ze direct vertaalden naar gebruikerservaring en infrastructuurkosten.
Zelfs een basis CDN verandert hoe verzoeken je site bereiken. Meestal wordt deze via DNS geïntroduceerd: je domein wijst naar de CDN, die bezoekers naar een nabijgelegen PoP routeert. Vanaf daar kan de CDN optreden als een reverse proxy—de verbinding van de gebruiker beëindigen en een aparte verbinding naar je origin openen wanneer dat nodig is.
Die “in het midden” positie doet ertoe. Zodra een provider betrouwbaar voor je origin staat en verkeer aan de edge afhandelt, kan die meer dan bestanden cachen—hij kan verzoeken inspecteren, filteren en vormen.
Veel moderne producten bestaan niet meer voornamelijk uit statische pagina’s. Het zijn dynamische applicaties die op API’s draaien: gepersonaliseerde content, realtime-updates, geauthentiseerde flows en frequente write-operaties. Caching helpt, maar lost niet alles op—vooral niet wanneer antwoorden per gebruiker verschillen, afhankelijk zijn van cookies of headers, of directe origin-logica vereisen.
Die kloof—tussen statische versnelling en dynamische applicatiebehoeften—is waar de evolutie van “CDN” naar een breder edge-platform begint.
Een grote verschuiving in hoe het internet wordt gebruikt heeft meer verzoeken naar “de edge” (de netwerkperimeter) geduwd voordat ze je origin-servers raken. Het gaat niet meer alleen om snellere websites—het gaat om waar verkeer van nature stroomt.
HTTPS overal is een belangrijke drijfveer. Zodra het meeste verkeer versleuteld is, kunnen netwerk-middleboxes binnen een bedrijfsnetwerk het niet eenvoudig inspecteren of optimaliseren. Organisaties kiezen er daarom vaker voor TLS te termineren en beheren dichter bij de gebruiker—bij een edge-service die daarvoor gebouwd is.
API’s hebben ook de vorm van verkeer veranderd. Moderne apps zijn een constante stroom kleine verzoeken van webfrontends, mobiele clients, partnerintegraties en microservices. Voeg bots toe (zowel goede als slechte), en plotseling is een groot deel van de “gebruikers” geen mens—waardoor verkeer gefilterd en gerate-limiteerd moet worden voordat het de applicatie-infrastructuur bereikt.
Dan is er de alledaagse realiteit van mobiele netwerken (variabele latency, roaming, retransmits) en de opkomst van SaaS. Je medewerkers en klanten bevinden zich niet meer binnen één netwerkgrens, dus beveiligings- en prestatiebeslissingen verplaatsen zich naar waar die gebruikers daadwerkelijk verbinding maken.
Wanneer applicaties, gebruikers en diensten verspreid zijn over regio’s en clouds, zijn er minder betrouwbare plekken om regels af te dwingen. Traditionele controlepunten—zoals een enkele datacenter-firewall—houden op de standaardroute te zijn. De edge wordt één van de weinige consistente checkpoints waar de meeste verzoeken doorheen kunnen worden geleid.
Omdat zoveel verkeer door de perimeter gaat, is het een natuurlijke plek om gedeelde beleidsregels toe te passen: DDoS-filtering, bot-detectie, WAF-regels, TLS-instellingen en toegangscontroles. Dit vermindert “besluitvorming” bij elke origin en houdt bescherming consistent over apps heen.
Verkeer centraliseren op de edge kan origin-IP’s verbergen en directe blootstelling verminderen, wat een betekenisvolle beveiligingswinst is. De afweging is afhankelijkheid: beschikbaarheid en correcte configuratie van de edge worden kritisch. Veel teams behandelen de edge als onderdeel van de kerninfrastructuur—meer een control plane dan een simpele cache.
Voor een praktische checklist, zie /blog/how-to-evaluate-an-edge-platform.
Een traditionele CDN begon als “slimme caching”: het bewaarde kopieën van statische bestanden dichter bij gebruikers en haalde ze van de origin wanneer nodig. Dat helpt performance, maar verandert niet fundamenteel wie de verbinding “bezit”.
De grote verandering gebeurt wanneer de edge stopt met alleen cache zijn en een volledige reverse proxy wordt.
Een reverse proxy staat voor je website of app. Gebruikers verbinden met de proxy, en de proxy verbindt met je origin (je servers). Voor de gebruiker ís de proxy de site; voor de origin lijkt de proxy op de gebruiker.
Die positionering maakt diensten mogelijk die niet mogelijk zijn met alleen cache-gedrag—omdat elk verzoek kan worden afgehandeld, aangepast of geblokkeerd voordat het je infrastructuur bereikt.
Wanneer de edge TLS beëindigt (HTTPS), wordt de versleutelde verbinding eerst bij de edge opgezet. Dat creëert drie praktische mogelijkheden:
Hier is het mentale model:
user → edge (reverse proxy) → origin
De edge in het midden plaatsen centraliseert controle, wat vaak precies het doel is: consistente beveiligingsbeleid, eenvoudigere uitrols en minder “speciale gevallen” bij elke origin.
Maar het voegt ook complexiteit en afhankelijkheid toe:
Deze architectuurverandering is wat een CDN in een platform verandert: zodra de edge de proxy is, kan het veel meer dan alleen cachen.
Een DDoS (Distributed Denial of Service) aanval is eenvoudig gezegd een poging om een site of app zoveel verkeer te geven dat echte gebruikers er niet doorheen komen. In plaats van “inbreken” probeert de aanvaller de oprit te blokkeren.
Veel DDoS-aanvallen zijn volumetrisch: ze gooien enorme hoeveelheden data op je IP-adres om bandbreedte uit te putten of netwerkapparatuur te overbelasten voordat een verzoek je webserver bereikt. Als je pas bij de origin verdedigt (je datacenter of cloudregio), betaal je al de prijs—je upstream-links kunnen verzadigen en je firewall of load balancer kan de bottleneck worden.
Een edge-netwerk helpt omdat het beschermende capaciteit dichter bij de plek zet waar verkeer het internet binnenkomt, niet alleen waar je servers leven. Hoe gedistribueerder de verdediging, hoe moeilijker het voor aanvallers is om zich op één choke point op te stapelen.
Wanneer providers DDoS-bescherming beschrijven als “absorberen en filteren”, bedoelen ze twee dingen die plaatsvinden over veel PoP’s:
Het belangrijkste voordeel is dat het ergste deel van de aanval upstream van je infrastructuur afgehandeld kan worden, waardoor de kans kleiner is dat je eigen netwerk—of cloudrekening—het slachtoffertje wordt.
Rate limiting is een praktische manier om te voorkomen dat één bron—of één gedrag—te veel resources te snel opeist. Bijvoorbeeld kun je limiteren:
Het stopt niet elk type DDoS op zichzelf, maar het is een effectieve ontlastingsklep die misbruikpieken reduceert en kritieke routes bruikbaar houdt tijdens een incident.
Als je edge-gebaseerde DDoS-bescherming evalueert, controleer dan:
Een edge-netwerk is een gedistribueerde set servers (points of presence) geplaatst in veel steden zodat verzoeken dichter bij gebruikers kunnen worden afgehandeld. Afhankelijk van het verzoek kan de edge:
Het praktische resultaat is lagere latency en minder belasting en blootstelling van je origin-infrastructuur.
De perimeter is de grens waar internetverkeer als eerste je systemen bereikt—je website, apps en API’s—vaak via DNS en een edge reverse proxy. Het is belangrijk omdat daar:
Het centraliseren van controles op de perimeter maakt het mogelijk consistente prestatie- en beveiligingsregels toe te passen voordat verkeer je kernservices bereikt.
Een klassieke CDN richt zich op het cachen van statische inhoud (afbeeldingen, CSS, JS, downloads) op edge-locaties. Het verbetert snelheid vooral door afstand te verkleinen en de origin te ontlasten.
Een modern edge-platform gaat verder door te fungeren als een volledige reverse proxy voor het meeste verkeer, waardoor routing, beveiligingsinspectie, toegangscontroles en soms compute mogelijk worden—ongeacht of inhoud cachebaar is.
DNS is vaak de eenvoudigste manier om een CDN/edge-provider voor je site te plaatsen: je domein verwijst naar de provider, en die routeert bezoekers naar een nabijgelegen PoP.
In veel opstellingen fungeert de edge ook als reverse proxy, wat betekent dat gebruikers eerst met de edge verbinden, en de edge alleen bij nodig contact opneemt met je origin. Die “in het midden” positie maakt schaalbare caching, routing en beveiligingshandhaving mogelijk.
Wanneer de edge TLS beëindigt, wordt de versleutelde HTTPS-verbinding bij de edge opgezet. Dat maakt drie praktische mogelijkheden mogelijk:
Het vergroot de controle—maar betekent ook dat edge-configuratie mission-critical wordt.
Je zou een CDN moeten beoordelen met metrics die gekoppeld zijn aan gebruikerservaring en infrastructuurkosten, zoals:
Koppel deze aan origin-metrics (CPU, verzoeksnelheid, egress) om te bevestigen dat de CDN echt druk wegneemt waar dat ertoe doet.
Edge-mitigatie is effectief omdat veel DDoS-aanvallen volumetrisch zijn—ze proberen bandbreedte of netwerkapparaten te verzadigen voordat verzoeken je applicatie bereiken.
Een gedistribueerde edge kan:
Alleen bij de origin verdedigen betekent vaak dat je de prijs betaalt (verzadigde links, overbelaste load balancers, hogere cloudkosten) voordat mitigatie ingrijpt.
Rate limiting beperkt hoeveel verzoeken een client (of token) in een tijdsvenster kan doen, zodat één bron niet onevenredig veel resources consumeert.
Veelvoorkomende edge-gebruiksscenario’s zijn:
Het lost niet elke DDoS op, maar het is een krachtig, eenvoudig te begrijpen middel tegen misbruikpieken.
Een WAF inspecteert HTTP-verzoeken en past regels toe om veelvoorkomende applicatie-aanvallen te blokkeren (zoals SQLi en XSS). Botmanagement richt zich op het identificeren en afhandelen van geautomatiseerd verkeer—zowel goede bots (bijv. zoekcrawlers) als schadelijke (scraping, nep-aanmeldingen, credential stuffing).
Een praktische uitrol is:
Zero Trust betekent dat toegangsbeslissingen gebaseerd zijn op identiteit en context, niet op het ‘binnen zijn’ van het netwerk. Aan de edge ziet dat er vaak zo uit:
Een veelgemaakte fout is het zien van Zero Trust als alleen een VPN-vervanger—zonder permissies, sessieduur en apparaatcontroles aan te scherpen blijven risico’s bestaan. Dat zijn juist de maatregelen die het op lange termijn veiliger maken.