Traditionele webhosting vs serverless op AWS.

Twee fundamenteel andere modellen voor je website

Wanneer je een website online zet, kies je tussen twee grondstructuren. De eerste is het traditionele model: je huurt een server — shared hosting bij een Nederlandse provider als TransIP, een VPS bij DigitalOcean, of een dedicated machine in een datacenter. Die server staat 24/7 aan, je hebt SSH-toegang, je installeert PHP, MySQL en Nginx, je houdt patches bij, en je beheert dat alles zelf — of besteedt het uit.

De tweede is het serverless model. Je website draait niet op een server die jij beheert, maar op functies bij een cloudprovider — meestal AWS Lambda — die alleen worden uitgevoerd op het moment dat een bezoeker een pagina opvraagt. Voor Laravel-gebaseerde websites is Laravel Vapor de standaard die deze brug slaat: het neemt je standaard Laravel-codebase, pakt die in als Lambda-deploybundel, regelt routing via API Gateway, mediabestanden via S3, achtergrondwerk via SQS, content delivery via CloudFront en database via RDS of Aurora.

Het verschil is fundamenteler dan veel mensen denken. Bij traditionele webhosting beheer je een machine, bij serverless beheer je alleen nog code. Dat ene onderscheid bepaalt voor het overgrote deel hoe je website wordt onderhouden, beveiligd en uitgeleverd. Beide modellen hebben hun plek — in dit artikel zetten we eerlijk naast elkaar wat ze inhouden, waar ze sterk in zijn en wanneer welke optie het beste past.

Wat is traditionele webhosting?

Onder de paraplu "traditionele webhosting" vallen drie categorieen, oplopend in vrijheid en verantwoordelijkheid.

Shared hosting. De goedkoopste optie, populair bij Nederlandse providers als TransIP, Vimexx, Hostnet en Antagonist. Honderden websites delen dezelfde fysieke server. Je krijgt toegang tot een controlepaneel (DirectAdmin, Plesk, cPanel), kunt PHP-versies kiezen en databases aanmaken, maar je hebt geen root-toegang en geen invloed op de Linux-configuratie. Goed voor een eenvoudige bedrijfssite of klein portfolio; ongeschikt zodra je website maatwerk-functionaliteit nodig heeft of integraties met andere systemen.

VPS (Virtual Private Server). Een virtuele machine met gegarandeerde resources op een gedeelde fysieke host. DigitalOcean, Hetzner, Linode (nu Akamai) en Vultr zijn de bekendste internationale aanbieders; in Nederland leveren TransIP en TrueServer hetzelfde model. Je hebt root, je beheert het besturingssysteem, je installeert de stack zelf — of laat dat doen door beheerlagen als Laravel Forge of Ploi.

Dedicated server / colocation. Een complete fysieke machine die alleen voor jouw website is. Hoogste performance, maximale controle, hoogste verantwoordelijkheid. Tegenwoordig zeldzaam buiten enterprise-toepassingen, omdat goed afgestelde VPS-instances of bare-metal cloud (Hetzner Dedicated, AWS EC2 Bare Metal) hetzelfde leveren met meer flexibiliteit.

Wat al deze varianten gemeen hebben: er is een server die altijd draait, jij (of je hostingpartner) bent verantwoordelijk voor patches, security-updates, monitoring, backups en schaling. Volgens het Hacked Website Threat Report van Sucuri zijn niet-bijgewerkte CMS- en serversoftware in 2026 nog altijd de grootste oorzaak van gehackte websites — een directe consequentie van het beheermodel.

Wat is serverless webhosting via Laravel Vapor?

Bij serverless verdwijnt de server uit jouw verantwoordelijkheid. Concreet bij Vapor: je website wordt opgesplitst in twee soorten functies. Pagina-aanvragen worden afgehandeld door Lambda-functies achter API Gateway. Achtergrondtaken — denk aan formulier-mails of het genereren van een sitemap — draaien op aparte Lambdas, getriggerd door SQS-queues. Statische assets (CSS, JavaScript, afbeeldingen) en alle uploads staan op S3, wereldwijd uitgeleverd via CloudFront. Database is RDS of Aurora Serverless v2.

Een deploy van je website ziet er zo uit:

$ vapor deploy production

Compiling assets...
Building project...
Uploading project... (12.4 MB)
Deploying...
Activating function...
Deployed: production [v47] in 38s

Geen SSH, geen composer install op de productie-server, geen php artisan migrate via een tunnel. Vapor zorgt voor zero-downtime: terwijl versie 47 wordt uitgerold, blijft versie 46 actief tot het verkeer naadloos overgaat. Komt er een fout? vapor rollback en je website is binnen tien seconden terug op de vorige versie.

Schaling gebeurt automatisch. Een rustige zondagochtend? Er draait letterlijk niets. Een persbericht of een TV-uitzending die ineens veel verkeer trekt? Lambda spint binnen een paar honderd milliseconden parallelle instances op om alle bezoekers tegelijk te bedienen. Je hoeft daar niets voor te doen — geen auto-scaling-groepen, geen load balancers, geen capaciteitsplanning.

Onderhoud en beheer: het grootste praktische verschil

Hier zit het grootste praktische verschil tussen het hosten van een website. Op een VPS ben jij (of je hostingpartner) verantwoordelijk voor:

• Linux-kernel-updates en security-patches (zie Copy Fail (CVE-2026-31431) als voorbeeld waarom dit acuut kan zijn);
• PHP-, MySQL/Postgres- en Nginx-versies up-to-date houden;
• SSL-certificaten verlengen (Let's Encrypt-automatisering inrichten);
• Backups configureren, testen en periodiek terugzetten als oefening;
• Monitoring opzetten — uptime, schijfgebruik, geheugen, database-load;
• Log-rotatie, fail2ban, UFW-firewallregels beheren;
• Onderhoudsvensters plannen waarin je website tijdelijk offline gaat voor updates;
• Incidenten oplossen om 02:00 's nachts wanneer de schijf vol is en de website offline gaat.

Diensten als Laravel Forge en Ploi verlichten dit door een GUI op deze taken te leggen, maar de verantwoordelijkheid blijft bij jou. Een patch die je niet installeert, is een gat dat openstaat — en dat is voor een publiek toegankelijke website een direct risico. Een server die je niet monitort is een server die op een zaterdagavond zonder waarschuwing offline kan gaan.

Bij Vapor neemt AWS dit allemaal over. De Lambda-runtime, het besturingssysteem, de Nginx-equivalent, het netwerk, de hardware — allemaal beheerd door AWS. Jij beheert je website-code en de configuratie van Vapor (vapor.yml). Een SSL-certificaat is een regel YAML. Een backup van RDS is automatisch en point-in-time-recoverable. Een failover bij hardwarefalen merk je niet — je website blijft gewoon bereikbaar.

Er zijn geen onderhoudsvensters. Er zijn geen handmatige updates. Er is geen 's nachts wakker worden voor een storingsmelding. Voor een MKB-bedrijf zonder DevOps-engineer betekent dat letterlijk uren per maand bespaard, plus de zekerheid dat je website 24/7 actueel en bereikbaar blijft zonder dat iemand er aandacht aan hoeft te besteden.

Beveiliging: het aanvalsoppervlak vergeleken

Een tweede belangrijk verschil zit in beveiliging — en dat wordt vaak onderschat. Een traditionele webserver is per definitie een machine die 24/7 op het internet staat met:

• Een SSH-poort die altijd luistert (poort 22 of een alternatieve poort);
• Een webserver (Nginx of Apache) die continu requests accepteert;
• Soms een beheerpaneel als DirectAdmin of Plesk op een aparte poort;
• Een MySQL- of Postgres-proces dat draait, vaak op dezelfde machine;
• Een vaste set OS-libraries en services die actueel gehouden moeten worden.

Elk van die componenten is een potentieel aanvalsoppervlak. Een verlopen patch in OpenSSH, een zero-day in Nginx, een verkeerde configuratie in fail2ban, een vergeten database-port die open staat richting het internet — het zijn allemaal scenarios die we in de praktijk regelmatig tegenkomen. Brute-force-pogingen op SSH zijn bij vrijwel elke publieke server een dagelijkse realiteit; alleen al het aantal automated scans dat continu loopt op het IPv4-bereik is overweldigend.

Bij Vapor op AWS bestaat die altijd-aan-server niet. Er is geen SSH-poort. Er is geen permanent draaiende webserver die je moet patchen. Pagina-aanvragen worden uitgevoerd in geisoleerde Lambda-containers die per request opgespind worden, hun werk doen en daarna verdwijnen. Het OS, de runtime, de Nginx-equivalent — allemaal door AWS beheerd, automatisch up-to-date, zonder dat jij ooit iets hoeft in te loggen of een commando hoeft te draaien.

Daarbij komt dat AWS-services standaard achter identity en access management (IAM) zitten: communicatie tussen Lambda, S3, SQS en RDS gaat via gesigneerde, tijdelijk geldige credentials in plaats van vaste wachtwoorden. CloudFront staat voor de hele site en biedt automatisch DDoS-bescherming via AWS Shield. WAF-regels (Web Application Firewall) zijn een paar klikken weg.

Het netto-resultaat: in het serverless-model heeft een aanvaller simpelweg geen server om aan te vallen. Geen brute-force op SSH, geen scannen op verlopen Nginx-versies, geen exploit op een verkeerd geconfigureerde MySQL. Een aantal klassieke webhosting-aanvallen zijn structureel uitgeschakeld omdat het oppervlak ze niet meer biedt. Bij traditionele hosting is dit oppervlak er wel, maar met goed beheer (snelle patches, gehardende SSH-config, een degelijke firewall) is het ook prima beheersbaar — het kost alleen aandacht en discipline.

CloudFront CDN: wereldwijd razendsnel uitleveren

Een van de minst zichtbare maar meest impactvolle voordelen van Vapor is dat CloudFront standaard meekomt. CloudFront is het wereldwijde Content Delivery Network van AWS, met meer dan 600 edge-locaties in tientallen landen — waaronder meerdere in Nederland.

Wat dat concreet betekent voor je website:

• Statische assets (CSS, JavaScript, afbeeldingen, fonts) worden gecached op de dichtstbijzijnde edge-locatie. Een bezoeker uit Amsterdam krijgt je CSS uit Frankfurt of Schiphol, niet uit Ireland of Virginia. Latency daalt drastisch.
• Pagina-responses kunnen op pagina-niveau gecached worden. Een blog-overzichtspagina die voor iedereen hetzelfde is, hoeft maar een keer per cache-window door Lambda te worden gerenderd; daarna serveert CloudFront de gecachte versie direct aan iedereen wereldwijd.
• Wereldwijde performance: een bezoeker uit Singapore, New York of Tokyo krijgt je website van een server in zijn eigen continent. Geen handmatige multi-region-setup nodig — het werkt vanaf de eerste deploy.
• DDoS-bescherming via AWS Shield Standard zit gratis ingebakken: CloudFront filtert volumetrische aanvallen voordat ze ooit bij je origin komen.
• HTTP/3 en moderne protocollen zijn standaard, zonder dat je je webserver hoeft te tunen.

Bij traditionele hosting moet je dit allemaal zelf inrichten. Cloudflare Pro of Fastly aansluiten, een aparte CDN-configuratie maken, je origin afschermen, cache-headers tunen, asset-versionering opzetten. Het is doenbaar, maar het is werk — en het is werk dat regelmatig stuk gaat bij configuratiewijzigingen. Bij Vapor is het de standaard-uitkomst van vapor deploy: na 38 seconden draait je website wereldwijd op een CDN waar grote tech-bedrijven hun infrastructuur op bouwen.

Assets en uploads op S3: niet meer op je eigen disk

Een vaak onderschat verschil zit in hoe mediabestanden en uploads worden afgehandeld. Bij traditionele hosting staat alles op dezelfde lokale disk: de PHP-code, de logfiles, de database-data, de geuploade afbeeldingen, de gegenereerde PDFs, alle gecreeerde varianten. Dat heeft drie grote nadelen.

Risico 1: de disk loopt vol. Een populair artikel met veel foto-uploads, een logfile die niet goed gerouleerd wordt, een backup die per ongeluk lokaal wordt gezet — en plotseling staat je hele website offline omdat de disk 100 procent vol is. We hebben dit in de praktijk vaker zien gebeuren dan ons lief is, vaak op het slechtste moment.

Risico 2: schaling wordt onmogelijk. Zodra je naar twee servers achter een load balancer wilt, krijg je een nieuw probleem: de uploads van bezoekers landen op server A, maar het volgende request gaat naar server B die het bestand niet kent. Dat kun je oplossen met NFS, GlusterFS of een aparte storage-server, maar dat is engineeringwerk dat voor een gewone bedrijfssite zelden te verantwoorden is.

Risico 3: bij verlies van de server ben je alles kwijt. Een crash, een verkeerde reinstall, een gehackte server die opnieuw moet worden opgezet — alle uploads die alleen lokaal stonden, zijn weg tenzij je backups perfect bijhoudt en periodiek test. Bij shared hosting ben je bovendien afhankelijk van wat je provider als backup-strategie hanteert.

Bij Vapor zit dit anders by-design. Alle uploads gaan automatisch naar S3 — Amazon's object storage met 99,999999999 procent (elf negens) durability. Concreet:

• Een gebruiker uploadt een foto via een formulier op je site. Vapor schrijft die direct naar een S3-bucket, niet naar de lokale disk van de Lambda — die bestaat namelijk maar voor de duur van het request.
• Afbeeldingen, PDFs en andere downloads worden uitgeleverd via CloudFront vanaf S3, niet vanaf je website.
• S3-storage schaalt onbeperkt: het maakt niet uit of je 10 MB of 10 TB aan uploads hebt staan, het werkt hetzelfde.
• Backups en versionering zijn ingebouwde S3-features (object lock, versioning, lifecycle policies).
• Geen disk om vol te lopen — er is geen disk in het bezoekers-pad.

De Storage::disk('s3')-driver in Laravel maakt dit transparant: je code werkt lokaal met een lokale disk en op productie automatisch met S3, zonder dat je iets hoeft aan te passen aan je controllers of upload-logica. Het is precies het soort architectuurkeuze die later veel waard blijkt — niet omdat je hem nodig dacht te hebben, maar omdat hij voorkomt dat je website ooit "vol" raakt of bij een serverincident waardevolle bestanden verliest.

Schaalbaarheid en performance

Op een VPS is de capaciteit hard begrensd door wat de machine aankan. Een verkeerspiek door een persbericht of TV-uitzending kan de site traag maken of laten crashen. Verticale schaling (een grotere machine) vereist downtime en handwerk; horizontale schaling (meerdere machines achter een load balancer) vereist auto-scaling-groepen, een database die meerdere read replicas aankan en een sessie-store die over machines heen werkt — kortom: serieus engineeringwerk dat voor een gewone bedrijfssite zelden de moeite waard is.

Bij Vapor schaalt elke pagina-aanvraag individueel. Als er ineens veel verkeer komt, draait Lambda evenveel parallelle instances als nodig, geheel automatisch. De website heeft geen weet van schaling, omdat het AWS-platform die complexiteit absorbeert. Wat hier wel extra aandacht vraagt is de database, omdat veel parallelle Lambdas veel parallelle database-connecties kunnen openen. Daarom raadt AWS RDS Proxy aan — een transparante connection-pool die Lambda-connecties consolideert tot een handelbaar aantal back-end-verbindingen.

Op het gebied van pure latency wint een goed afgestelde VPS bij warme requests vaak met 10 tot 50 ms ten opzichte van een koude Lambda. Lambda heeft de befaamde koude start: de eerste pagina-aanvraag na inactiviteit moet wachten tot AWS een container heeft opgewarmd. Voor PHP via Vapor is dat 200 tot 800 ms. Voor websites met regelmatig bezoek is dat zelden zichtbaar — Lambda-containers blijven zon 5 tot 15 minuten warm, en CloudFront vangt veel pagina-views af nog voordat Lambda uberhaupt geraakt wordt. Voor latency-gevoelige websites biedt AWS bovendien Provisioned Concurrency: je houdt een aantal instances altijd warm, en de koude start verdwijnt volledig.

Deployment: een nieuwe versie van je website live zetten

Op een VPS deploy je via Git-pulls met deploy-scripts, via Forges "Deploy Now"-knop, of via Envoyer (zero-downtime via symlinks). Werkt prima, maar er is altijd kans op een halfafgemaakte migratie, een vergeten composer install, een vergeten npm run build, of een race-condition tijdens de deploy zelf. Voor een website die altijd bereikbaar moet zijn, is dat een reeel risico.

Vapors deploy-pipeline doet alles atomair. vapor deploy bouwt een complete deploybundel met alle assets, draait migraties via een aparte vapor:hook-functie, en wisselt het verkeer pas om als de nieuwe versie 100 procent gereed is. Faalt de migratie? Dan blijft de oude versie van je website actief en krijg jij een rode foutmelding — geen halfgekantelde site die bezoekers met fouten begroet.

Voor branches of preview-omgevingen: Vapor laat je met een commando een complete preview-environment van je website uitrollen — handig om een nieuw ontwerp of een nieuwe sectie te tonen aan een opdrachtgever voordat het live gaat. Op een VPS betekent dat een nieuwe server, een nieuwe database, een nieuwe DNS-configuratie. Het verschil in iteratiesnelheid is voor groeiende bureaus en in-house teams substantieel.

De nadelen van serverless eerlijk benoemd

Serverless is geen wondermiddel. Drie reele kanttekeningen voor wie zijn website serverless wil hosten:

Vendor lock-in. Je website draait op AWS-specifieke services: Lambda, API Gateway, SQS, RDS Proxy, CloudFront. Migreren naar Google Cloud of Azure is geen kwestie van een DNS-wissel; het is een herontwerp. Dit is overigens minder dramatisch dan het lijkt — Laravel Vapor isoleert het meeste AWS-werk in zijn YAML-configuratie en de Laravel-code zelf blijft volledig portable. We schreven hier eerder uitgebreid over in Laravel Vapor en AWS: je code is niet vendor-locked, maar je infrastructuur wel.

Niet elke website is geschikt. Vapor is gebouwd voor Laravel-applicaties. Bouw je website op Laravel of Statamic? Dan past het uitstekend. Heb je een pure WordPress-site? Dan blijft traditionele hosting of een gespecialiseerde WordPress-host de logische keuze. Heb je een statische site (Hugo, Astro, Jekyll, Eleventy)? Dan hoort die op een CDN als Cloudflare Pages, Netlify of Vercel — daar is Vapor overkill voor. Lambda-functies hebben bovendien een maximum van 15 minuten executie-tijd, dus zware exports of imports moet je opsplitsen.

Debugging-complexiteit. Op een VPS doe je tail -f storage/logs/laravel.log en zie je live wat er op je website gebeurt. Bij Vapor zit je log verspreid over CloudWatch Logs, Vapors eigen UI en eventueel een log-shipper als Datadog of Sentry. Een trage pagina reproduceren in een lokale omgeving is lastiger omdat de productie-context (concurrency, cold starts) lokaal niet bestaat. Tools als Laravel Pail en X-Ray helpen, maar de leercurve is reeel.

Wanneer kies je wat voor je website?

Het is geen religieuze keuze. Het is een afweging op een paar duidelijke assen: het framework van je site, de tijd die je aan beheer wil besteden, en de eisen aan beveiliging en wereldwijde performance.

Kies traditionele webhosting (shared / VPS via Forge) wanneer:

• Het een eenvoudige brochuresite, blog of basale WordPress-installatie is;
• Je website langlopende processen draait die niet binnen 15 minuten afgerond zijn;
• Je team al ervaring heeft met Linux-beheer of een vaste hostingpartner;
• Je expliciet bij een Nederlandse provider wil zitten om datasoevereiniteit (TransIP, TrueServer, Bytenode);
• Je volledige controle over de stack belangrijker vindt dan een managed setup.

Kies serverless via Vapor wanneer:

• Het een Laravel- of Statamic-gebaseerde website is;
• Je geen DevOps-capaciteit hebt en het onderhoud van een server liever uitbesteedt aan AWS;
• Zero-downtime deploys, automatische backups, multi-AZ-failover en wereldwijde CDN-uitlevering essentieel zijn voor je vindbaarheid en reputatie;
• Een kleiner aanvalsoppervlak en het ontbreken van een permanent open server zwaar wegen in je risicoafweging;
• Je preview-omgevingen per ontwerpiteratie waardevol vindt;
• Je wil dat verkeerspieken automatisch worden opgevangen in plaats van handmatig opschalen.

De praktijk bij Coding Agency

Bij Coding Agency draaien onze eigen website en die van veel klanten op Laravel Vapor. De redenen zijn niet ideologisch maar pragmatisch.

Klanten verwachten in 2026 dat hun website s nachts gewoon bereikbaar is, zonder dat iemand wakker hoeft te worden voor een herstart. Ze verwachten dat een verkeerspiek door een persbericht of een TV-uitzending niet leidt tot een onbereikbare site precies op het moment dat het belangrijk is. Ze verwachten dat een nieuwe deploy van content of design geen risico vormt voor de live-versie. Op een VPS-stack regel je dat allemaal zelf — bij Vapor is het de standaard.

Tegelijk hebben we klanten waar Vapor niet past. Een klant met een eenvoudige WordPress-bedrijfssite hoort thuis bij een gespecialiseerde WordPress-host of een goede Nederlandse shared host. Een klant met een statisch portfolio draait op Cloudflare Pages voor letterlijk nul euro per maand. Een klant met strikte eisen aan Nederlandse datalokalisatie tot op het datacenter draait op TrueServer in Eindhoven.

De vraag die we altijd stellen voor we een website deployen: "hoe ziet het bezoekerspatroon eruit, op welk framework draait de site, en wie wordt er wakker als de site s nachts onbereikbaar is?" Het antwoord daarop bepaalt de keuze veel betrouwbaarder dan een prijslijst.

Conclusie

De vergelijking tussen traditionele webhosting en serverless is geen kwestie van "modern versus oud" — het zijn twee modellen met elk hun eigen domein. Traditionele hosting wint op voorspelbaarheid, eenvoud bij simpele sites en lage instapdrempel; serverless wint op schaalbaarheid, beheerlast en deployment-betrouwbaarheid.

Voor de meeste maatwerk-websites die we bouwen op Laravel of Statamic valt de balans uit naar serverless via Laravel Vapor. Niet omdat het altijd goedkoper is, maar omdat het de operationele last verschuift van het bedrijf van de klant naar het platform van AWS — en daarmee een hoeveelheid risico, kennis en tijd vrijspeelt die elders meer waarde oplevert. Voor andere websites — eenvoudige WordPress-sites, statische portfolios, sites met strikte lokalisatie-eisen — blijft een goed afgestelde VPS bij Forge of Ploi, of een gewone Nederlandse shared-host, de juiste keuze.

De juiste vraag is niet "welke hosting is de beste?", maar "welk model past bij deze specifieke website, dit team en deze bezoekers?". Pas met die vraag scherp gesteld wordt de keuze tussen TransIP, DigitalOcean en AWS Vapor een rationele afweging in plaats van een smaakkwestie.