Je bent twee jaar geleden live gegaan op AWS. De architectuur was degelijk. Security was op orde, de kosten waren redelijk en het team kende elk onderdeel.
Spoel door naar vandaag. Drie teams deployen onafhankelijk van elkaar. Iemand heeft “tijdelijk” oversized instances opgestart, zes maanden geleden. Je disaster recovery plan staat op een Confluence-pagina die niemand heeft geopend sinds de initiële build. En die S3 bucket? Public read access sinds een demo in Q2.
Niemand bouwt bewust een puinhoop. Het sluipt erin.
Wat het Well-Architected Framework eigenlijk is
Wij voeren regelmatig Well-Architected Reviews uit voor Nederlandse bedrijven, en wat de meeste teams verrast: het framework is geen theoretische checklist. Het is een gestructureerde set lastige vragen, ontworpen om precies die dingen boven water te halen waar je te druk voor was om naar te kijken.
AWS heeft het georganiseerd rond zes pijlers. Je hebt de lijst waarschijnlijk al eens gezien. Maar pijlers opsommen is makkelijk. De waarde zit in de vragen die elke pijler je dwingt eerlijk te beantwoorden.
Operational Excellence — Kan je team reageren op incidenten zonder heldendaden? Zijn deployments geautomatiseerd en herhaalbaar, of SSH’t er iemand om 2 uur ‘s nachts naar een server? Leer je van failures, of fix je het en ga je door?
Security — Wie heeft toegang tot wat, en hoe weet je dat? Is data encrypted at rest en in transit? Zou je een breach nu kunnen detecteren, niet morgen, niet nadat iemand iets vreemds opmerkt in CloudWatch?
Reliability — Wat gebeurt er als een component uitvalt? Heb je failover echt getest, of hoop je dat het runbook uit 2024 nog klopt? Kun je schalen zonder handmatige interventie?
Performance Efficiency — Gebruik je de juiste resource types? Wanneer heeft iemand voor het laatst gekeken of die instance families nog logisch zijn? Draai je containers op oversized EC2 terwijl Fargate de helft zou kosten?
Cost Optimization — Weet je wat elk team uitgeeft, en waarom? Betaal je voor resources die niemand gebruikt? Is je tagging strategy echt, of een spreadsheet die iemand ooit heeft ingevuld?
Sustainability — Minimaliseer je verspilde compute? Kun je dezelfde workload draaien op minder resources met slimmere architectuurkeuzes?
Elke pijler bevat tientallen specifieke vragen. Ze zijn ontworpen om blinde vlekken te vinden, de aannames die je team maakt omdat niemand ze recentelijk heeft gecontroleerd.
Waarom architecturen afdwalen
Niemand wordt wakker en besluit een fragiele, dure, onveilige omgeving te bouwen. Drift is stiller dan dat.
Een feature wordt opgeleverd onder tijdsdruk. Het team slaat de architecture review over omdat “het maar een kleine wijziging is.” Vermenigvuldig dat met vijftig deployments over drie squads in achttien maanden. Nu ziet je omgeving er heel anders uit dan het oorspronkelijke ontwerp, en niemand kan aanwijzen wanneer het misging.
Dit zien we het vaakst:
| Bevinding | Wat er in de praktijk gebeurt |
|---|---|
| Geen DR-testing | Het disaster recovery plan bestaat. Het is geschreven tijdens de initiële build. Het is nooit uitgevoerd. Als het moment komt, weet niemand of het werkt. Hoop is geen recovery-strategie. |
| Handmatige deployments | Eén team heeft geautomatiseerd. Twee anderen deployen nog met de hand. Het is een kwestie van tijd voordat een handmatige push iets spannends introduceert in productie. |
| Over-provisioned resources | Die m5.4xlarge was gedimensioneerd voor piekbelasting die één keer voorkwam. Hij draait dagelijks op 12% CPU. Niemand heeft hem verkleind omdat “hij werkt.” Klopt, en hij verbrandt ondertussen geld. |
| Ontbrekende encryptie | Data at rest is encrypted in productie maar niet in staging. Staging bevat productiedata. Je ziet het probleem. |
| Geen kostenallocatie | De AWS-factuur komt binnen. Hij is hoger dan vorige maand. Niemand kan met vertrouwen uitleggen waarom. |
Dit zijn geen uitzonderingen. Dit zijn de meest voorkomende bevindingen bij de enterprises die wij reviewen.
Hoe wij een Well-Architected Review uitvoeren
Een review is geen afvinkexercitie. Het is een gestructureerde deep dive in je workloads tegen de zes pijlers. Geen PDF van 200 pagina’s die stof verzamelt. Concrete bevindingen waar je maandagochtend mee aan de slag kunt.
Discovery
We beginnen met het begrijpen van je landschap. Welke workloads draaien er? Wat is bedrijfskritisch? Wie deployt wat, en hoe? Hoe ziet je teamstructuur eruit?
Dit gaat niet over het auditen van je team. Het gaat over het begrijpen van context, zodat de bevindingen landen als uitvoerbare aanbevelingen, niet als abstract advies.
Workload analyse
We beoordelen je architectuur tegen het framework met de AWS Well-Architected Tool en Trusted Advisor. Maar de tooling is slechts het startpunt. De echte waarde zit in engineers die met je team zitten, CDK- en Terraform-configuraties reviewen, deployment pipelines, monitoring, IAM policies, networking en kostenstructuur doorlopen. De vragen stellen die elke pijler vereist. Doorvragen op de antwoorden.
Dit is geen vulnerability scan. Het is geen geautomatiseerd rapport. Het is een gesprek.
Bevindingen rapport
Je krijgt een helder, geprioriteerd rapport. Kritieke risico’s gescheiden van middellange-termijnverbeteringen, gescheiden van nice-to-haves.
Elke bevinding beschrijft wat het probleem is, waarom het ertoe doet, en wat je eraan kunt doen. Geen vaagheid. Geen consultantjargon. Als wij een bevinding niet in heldere taal kunnen uitleggen, hebben we hem zelf niet goed genoeg begrepen.
Remediatie roadmap
Bevindingen zonder plan zijn alleen maar stress. We leveren een geprioriteerde roadmap: wat eerst te fixen, geschatte inspanning, en de verwachte impact van elke verandering.
Security gaps en single points of failure gaan naar de top. Kostenoptimalisatie wordt geordend op besparingspotentieel versus implementatie-inspanning. Je loopt weg met precies de kennis waar je moet beginnen en wat je voorlopig kunt negeren.
Wat het je concreet oplevert
Minder risico. Je vindt de single points of failure, de onversleutelde datastores, de IAM policies met *:* die iemand drie jaar geleden “tijdelijk” heeft toegevoegd. De kosten van preventie zijn een fractie van de kosten van een breach of outage. Elke CTO weet dit intellectueel. Een review maakt het concreet.
Lagere AWS-kosten. Over-provisioned instances, ongebruikte Elastic IPs, vergeten snapshots, verkeerde pricing models. Het telt sneller op dan de meeste teams beseffen. Wij zien doorgaans 10-30% besparing op compute-uitgaven in de eerste optimalisatieronde. Sommige teams staren naar de cijfers en vragen zich af waarom ze zo lang hebben gewacht.
Sterkere compliancepositie. NIS2 is nu afdwingbaar in Nederland. GDPR-audits worden elke cyclus gedetailleerder. Nederlandse enterprises staan onder echte regelgevingsdruk om security controls aan te tonen, en het venster om je zaakjes op orde te krijgen sluit. Een Well-Architected Review mapt direct op deze frameworks. Het geeft je gedocumenteerd bewijs van je posture, of laat je precies zien waar de gaten zitten voordat een toezichthouder dat doet.
Snellere incidentrespons. Als je je architectuur door en door kent (wat faalt, wat herstelt, wat handmatige interventie nodig heeft), reageert je team sneller. Runbooks zijn gebaseerd op de werkelijkheid, niet op aannames uit de initiële build.
Vertrouwen om te schalen. Je kunt niet schalen wat je niet begrijpt. Een review geeft engineering leadership een helder beeld van waar de architectuur staat en wat er moet gebeuren voor de volgende groeifase.
Wanneer moet je er een doen?
Er is geen verkeerd moment. Maar sommige momenten maken het extra waardevol:
- Voor een grote migratie of uitbreiding. Ken je baseline voordat je erop gaat bouwen.
- Na snelle groei. Als je team is verdubbeld of je workload verdrievoudigd, heeft je architectuur vrijwel zeker geen gelijke tred gehouden.
- Jaarlijks, als hygiëne. AWS brengt constant nieuwe services uit. Wat twee jaar geleden well-architected was, is dat vandaag misschien niet meer.
- Na een incident. Er is iets kapotgegaan. Een review helpt je de andere dingen te vinden die staan te wachten om kapot te gaan.
- Voorafgaand aan compliance-deadlines. NIS2 is van kracht. Een Well-Architected Review geeft je een voorsprong in het aantonen van je controls.
Je architectuur is afgedwaald
Je AWS-omgeving staat niet stil. Je business verandert, je team verandert, AWS zelf verandert. Wat achttien maanden geleden goed was gebouwd, is afgedwaald. De enige vraag is hoe ver.
Een Well-Architected Review geeft je duidelijkheid. Geen verkooppraatje. Geen theoretisch framework. Een concrete beoordeling van waar je staat en wat je vervolgens moet doen.
Plan een Well-Architected Review met Forrict en ontdek waar je AWS-omgeving werkelijk staat.
Forrict
AWS expert en consultant bij Forrict, gespecialiseerd in cloud architectuur en AWS best practices voor Nederlandse bedrijven.
