Microsoft Azure Solutions Architect is de rol waarin ontwerpbeslissingen voor Azure-omgevingen samenkomen: beveiliging, schaalbaarheid, beheerbaarheid en kosten moeten ook overeind blijven zodra workloads in productie staan. Waar Azure-beheer vaak gericht is op het betrouwbaar laten werken van bestaande omgevingen, vraagt architectuur om het vormgeven van het platform waarop teams kunnen bouwen. Die verschuiving maakt de rol aantrekkelijk voor cloud engineers, systeembeheerders, developers en consultants die niet langer alleen resources willen configureren.
In 2026 ligt de nadruk minder op losse Azure-services en meer op platform engineering: landing zones, identity-first ontwerp, policy-as-code, shared services, netwerksegmentatie, observability en kostenbeheersing. Een architect moet kunnen uitleggen waarom een organisatie kiest voor een hub-spoke-netwerk, hoe least privilege wordt afgedwongen met Microsoft Entra ID en Privileged Identity Management, en welke trade-offs horen bij beschikbaarheid, prestaties, beveiliging en kosten.
Publicatiejaar: 2026. Deze tekst is opgesteld op basis van gangbare Microsoft-methodieken zoals het Azure Well-Architected Framework, het Cloud Adoption Framework, Azure Landing Zones, Azure Policy en Microsoft Defender for Cloud, aangevuld met NL/EU-context rond AVG, NIS2, bedrijfscontinuïteit en risicogestuurd ontwerpen. Externe bronnen zoals Microsoft Learn, de Autoriteit Persoonsgegevens en het Nationaal Cyber Security Centrum worden hier bewust als primaire referentiepunten genoemd zonder marketingclaims of garanties te suggereren.
Wat de rol in de praktijk inhoudt
Een Azure Solutions Architect vertaalt zakelijke doelen naar technische ontwerpen. Dat klinkt breed, maar in de praktijk gaat het vaak om terugkerende ontwerpvragen: hoe worden identiteiten beheerd, waar landen workloads, welke data mag in welke regio staan, hoe worden kosten bewaakt, hoe ziet herstel na een storing eruit en hoe voorkomen teams dat elke afdeling een eigen cloudvariant bouwt.
De rol vraagt daardoor om diepte én samenhang. Kennis van compute, storage, networking, databases en security blijft nodig, maar de waarde ontstaat vooral wanneer die onderdelen worden samengebracht in een beheerbaar platform. Een architect die alleen weet welke dienst beschikbaar is, mist het belangrijkste deel van het werk: beslissen welke dienst past bij de risico’s, afhankelijkheden, kosten en operationele volwassenheid van de organisatie.
Voor Nederlandse en Belgische organisaties komt daar een duidelijke compliance-dimensie bij. De AVG vraagt om zorgvuldige omgang met persoonsgegevens, NIS2 vergroot de aandacht voor weerbaarheid en governance, en sectorale normen zoals BIO kunnen richting geven aan beveiligingsmaatregelen. Azure kan hierbij ondersteunen met patronen zoals dataresidentie-keuzes, Microsoft Entra ID, Conditional Access, PIM, Azure Policy-initiatieven, Defender for Cloud en Microsoft Purview, maar de toolconfiguratie vervangt nooit de juridische en organisatorische beoordeling.
De belangrijkste verschuiving: van servicekennis naar platformontwerp
Veel professionals beginnen hun voorbereiding met het leren van afzonderlijke services. Dat is begrijpelijk, maar het leidt vaak tot een examengerichte aanpak waarin de bredere architectuur ontbreekt. In productieomgevingen draait het zelden om de vraag of iemand een virtuele machine kan aanmaken; het gaat om de vraag hoe landing zones, abonnementen, management groups, policies, netwerkzones, logging en toegangsmodellen samen een duurzaam platform vormen.
Een basisontwerp begint meestal met Azure Landing Zones. Daarbij worden management groups ingericht voor scheiding tussen platform, connectivity, identity en workloads. Azure Policy dwingt vervolgens minimumeisen af, bijvoorbeeld verplichte tags, toegestane regio’s, diagnostische instellingen en beperkingen op publieke endpoints. Identity wordt centraal ontworpen met least privilege, rollen op het juiste niveau en tijdelijke privilege-escalatie via PIM waar dat passend is.
Het netwerkontwerp is vaak een van de eerste momenten waarop architectuurkeuzes zichtbaar worden. Een hub-spoke-model past goed wanneer gedeelde netwerkdiensten, firewalling, DNS, private connectivity en centrale inspectie belangrijk zijn. Een eenvoudiger vNet-per-workload-model kan voldoende zijn voor kleine omgevingen, maar wordt sneller lastig wanneer meerdere teams, regio’s en compliance-eisen samenkomen. De volwassen architect legt die afweging vast in plaats van één patroon als standaardantwoord te presenteren.
Een concreet scenario: een eerste landing zone bouwen
Een realistische oefening voor een aankomend Azure Solutions Architect is het ontwerpen van een kleine, maar serieuze landing zone. Het scenario kan bestaan uit een organisatie met één productie-workload, één ontwikkelomgeving, centrale identiteit, basislogging, verplichte kostenlabels en een eerste BCDR-aanpak. De oefening is waardevol omdat vrijwel elke ontwerpkeuze een trade-off zichtbaar maakt.
De architect start met aannames. Bijvoorbeeld: de workload verwerkt persoonsgegevens, moet binnen Europa worden gehost, heeft een afgesproken hersteltijd en gebruikt een weblaag, applicatielaag en database. Daarna volgen ontwerpbeslissingen: welke regio past bij dataresidentie en beschikbaarheid, welke resources horen in gedeelde platformabonnementen, welke teams krijgen welke rollen, welke logging is verplicht en welke kostenlabels zijn nodig voor rapportage.
Een goede uitwerking bevat meer dan een diagram. Er hoort een Architecture Decision Record bij voor belangrijke keuzes, een risicologboek voor open punten, een kostenmodel, een runbook voor incidenten en een observability-plan met Log Analytics, alerts en verantwoordelijken. Werkgevers kijken steeds vaker naar zulke artefacten omdat ze laten zien of iemand ontwerpdenken beheerst. Een examencertificaat helpt, maar een portfolio met ADR’s, diagrammen, kostenmodellen en runbooks maakt bekwaamheid tastbaarder.
Governance, security en compliance in NL/EU-context
Governance is geen los hoofdstuk aan het einde van een ontwerp. Het hoort vanaf het begin in de structuur van management groups, abonnementen, policies, rollen en monitoring te zitten. Voor AVG-gerelateerde workloads moet bijvoorbeeld duidelijk zijn welke data wordt verwerkt, waar die data staat, wie toegang heeft, hoe toegang wordt gelogd en welke maatregelen helpen bij dataminimalisatie en beveiliging.
Azure Policy kan daarbij helpen door technische guardrails af te dwingen. Denk aan toegestane regio’s, verplichte diagnostische logs, blokkeren van publieke IP-adressen voor bepaalde workloadtypes, afdwingen van tags en eisen rond versleuteling. Defender for Cloud ondersteunt posture management en signaleert configuratierisico’s, terwijl Purview kan helpen bij dataclassificatie en governance rond gevoelige informatie. Deze diensten maken compliance aantoonbaarder, maar alleen wanneer de organisatie ook eigenaarschap, processen en periodieke reviews heeft ingericht.
Bedrijfscontinuïteit verdient extra aandacht. Een veelgemaakte fout is dat kandidaten veel tijd besteden aan het examencurriculum, maar weinig aan region pairs, Azure Backup, Azure Site Recovery, herstelprocedures, service-quota en afhankelijkheden tussen diensten. In een ontwerp hoort duidelijk te zijn welke RTO en RPO gelden, welke onderdelen actief-actief of actief-passief draaien, en welke beperkingen worden geaccepteerd om kosten en complexiteit beheersbaar te houden.
FinOps is een basisvaardigheid voor architecten
Kostenbeheersing is niet langer alleen een taak voor operations of finance. Een Azure Solutions Architect moet al tijdens het ontwerp kunnen uitleggen welke keuzes de totale kosten beïnvloeden. Prestaties, beschikbaarheid en beveiliging hebben bijna altijd een kostencomponent, en een ontwerp zonder kostenmodel is moeilijk te verdedigen tegenover stakeholders.
Een praktisch FinOps-ritme begint met modelleren in de Azure Pricing Calculator en het expliciet vastleggen van aannames: verwachte belasting, opslaggroei, netwerkverkeer, back-upretentie, loggingvolume en beschikbaarheidseisen. Daarna komen Azure Budgets, Action Groups en waarschuwingen om afwijkingen snel zichtbaar te maken. Azure Policy kan verplichte kostendragers afdwingen, zoals cost center, workload owner, omgeving en dataclassificatie.
Reserved Instances en Savings Plans kunnen nuttig zijn voor stabiele workloads, terwijl pay-as-you-go flexibiliteit biedt wanneer vraag en architectuur nog veranderen. De architect moet dus niet alleen naar de laagste maandprijs kijken, maar naar risico: lock-in, schaalbaarheid, wijzigingssnelheid, operationele belasting en de kans dat resources ongebruikt blijven. In veel ontwerpen is de juiste keuze een combinatie van baseline-capaciteit met commitment en flexibele capaciteit voor pieken.
Welke certificering past bij de rol?
Certificering is geen vervanging voor praktijkervaring, maar kan wel structuur geven aan de leerroute. Professionals die vooral Azure-omgevingen beheren, beginnen vaak logisch met AZ-104, de Azure Administrator Associate-route. Wie naar architectuur en ontwerp wil groeien, komt uit bij AZ-305, Designing Microsoft Azure Infrastructure Solutions, dat onderdeel is van Microsoft Certified: Azure Solutions Architect Expert. Wie vooral CI/CD, releaseflow en DevOps-praktijken wil verdiepen, kijkt eerder naar AZ-400, DevOps Engineer Expert.
Voor de architectrol is AZ-305 meestal de meest directe certificeringsstap, omdat het examen draait om ontwerpkeuzes rond identity, governance, data, business continuity en infrastructuur. Wie gestructureerd wil voorbereiden kan de Azure Solutions Architect AZ-305 training gebruiken als verdiepende route, mits die voorbereiding wordt gecombineerd met hands-on ontwerpwerk en eigen artefacten.
Het bredere Microsoft-portfolio kan nuttig zijn wanneer de rol raakt aan security, data, development of operations. Een overzicht van beschikbare Microsoft-trainingen staat op de Microsoft trainingpagina, maar de keuze moet altijd volgen uit het beoogde werk. Een architect met zwakke beheerbasis heeft vaak eerst baat bij operationele Azure-kennis; een ervaren cloud engineer heeft juist meer aan scenario-oefeningen, governance, kostenanalyse en ontwerpverantwoording.
| Situatie | Logische focus | Waarom dit past |
|---|
| Je beheert Azure-resources en wilt je basis versterken | AZ-104 | De nadruk ligt op beheer, monitoring, compute, networking, storage en identity in dagelijkse Azure-operaties. |
| Je wilt ontwerpen maken en keuzes verdedigen | AZ-305 | De nadruk ligt op architectuurbeslissingen, governance, business continuity, data en infrastructuurontwerp. |
| Je werkt aan platformchanges, CI/CD en deliveryflow | AZ-400 | De nadruk ligt op DevOps-praktijken, automatisering, pipelines en samenwerking tussen development en operations. |
Praktijkervaring opbouwen met Infrastructure as Code
Een architect hoeft niet elke pipeline zelf te beheren, maar moet wel begrijpen hoe platformwijzigingen reproduceerbaar, reviewbaar en traceerbaar worden uitgerold. Infrastructure as Code is daarom een kernvaardigheid. Bicep en Terraform maken ontwerpkeuzes zichtbaar in code en helpen voorkomen dat omgevingen handmatig uit elkaar groeien.
De volgende Bicep-snippet laat een klein governancepatroon zien: een resource group met verplichte tags en een budget. In een echte omgeving zou dit onderdeel zijn van een bredere landing zone met management groups, policies, RBAC, logging en CI/CD, maar het voorbeeld toont hoe kostenbewustzijn en eigenaarschap al op platformniveau kunnen worden vastgelegd.
Example — budget en eigenaarschap vastleggen met Bicep
targetScope = 'subscription'
param location string = 'westeurope'
param workloadName string = 'payments-platform'
param monthlyBudgetAmount int = 1500
param ownerEmail string = 'platform-operations@contoso.nl'
resource workloadRg 'Microsoft.Resources/resourceGroups@2024-03-01' = {
name: 'rg-${workloadName}-prod-weu'
location: location
tags: {
workload: workloadName
environment: 'prod'
costCenter: 'finance-it'
dataClassification: 'confidential'
}
}
resource monthlyBudget 'Microsoft.Consumption/budgets@2023-11-01' = {
name: 'budget-${workloadName}-prod'
scope: workloadRg
properties: {
category: 'Cost'
amount: monthlyBudgetAmount
timeGrain: 'Monthly'
timePeriod: {
startDate: '2026-01-01T00:00:00Z'
endDate: '2027-01-01T00:00:00Z'
}
notifications: {
actualEightyPercent: {
enabled: true
operator: 'GreaterThan'
threshold: 80
contactEmails: [
ownerEmail
]
}
}
}
}
Dit voorbeeld maakt twee leerpunten concreet. Ten eerste horen tags niet achteraf te worden toegevoegd wanneer rapportage mislukt; ze moeten onderdeel zijn van het ontwerp. Ten tweede is een budget zonder eigenaar zwak, omdat niemand verantwoordelijk is voor afwijkingen. In productie hoort dit te worden uitgebreid met Azure Policy voor tagafdwinging, Action Groups voor meldingen en releasecontroles in een pipeline.
Een portfolio dat meer zegt dan een badge
Een sterk portfolio toont hoe iemand denkt. Dat kan een kleine landing zone zijn, maar dan wel uitgewerkt alsof deze aan een architectuurboard wordt voorgelegd. Een diagram met bestandsnaam zoals azure-landing-zone-hub-spoke.png en beschrijvende alt-tekst zoals “Azure landing zone met hub-spoke-netwerk, centrale firewall, gedeelde identity-services en gescheiden workloadspokes” is nuttiger dan een generiek plaatje zonder besluitcontext.
Bij elk diagram hoort tekst. De ADR beschrijft de gekozen optie, alternatieven, redenen en gevolgen. Het risicologboek benoemt bijvoorbeeld afhankelijkheid van één regio, openstaande quota-aanvragen, onzeker loggingvolume of nog niet gevalideerde herstelprocedures. Een onderhoudsstrategie beschrijft patching, monitoring, incidentrespons, back-upvalidatie en periodieke Well-Architected-reviews.
Voor technische interviews is dit vaak waardevoller dan het opsommen van services. Hiring managers en technische interviewers letten op de volwassenheid van redeneren: kan de kandidaat beperkingen benoemen, aannames expliciet maken, kosten bespreken, beveiligingskeuzes verdedigen en uitleggen hoe het ontwerp wordt beheerd na livegang. Wie alleen over het examen praat, laat een belangrijk deel van de architectrol onzichtbaar.
Veelgemaakte valkuilen bij voorbereiding
De meest voorkomende valkuil is het verzamelen van servicekennis zonder scenario’s te bouwen. Kandidaten leren dan kenmerken van Azure Firewall, Application Gateway, SQL Database of Storage Accounts, maar oefenen niet met de vraag wanneer een keuze passend is. Architectuur vraagt om context: dataclassificatie, gebruikersvolume, latency, kostenplafond, hersteldoelen, operationele capaciteit en compliance-eisen.
Een tweede valkuil is governance te laat toevoegen. Landing zones, policy-as-code, logging, RBAC en kostenlabels werken het beste wanneer ze vanaf het begin worden meegenomen. Achteraf corrigeren leidt vaak tot uitzonderingen, handmatige reparaties en ontwerpen die moeilijker te auditen zijn. Hetzelfde geldt voor observability: Log Analytics, alerts, dashboards en incidentrunbooks moeten niet pas verschijnen nadat de eerste storing heeft plaatsgevonden.
Een derde valkuil is onderschatting van BCDR en servicebeperkingen. Azure-diensten hebben quota, regionale beschikbaarheid, afhankelijkheden en configuratiegrenzen. Een architect die daar niet naar kijkt, kan een ontwerp maken dat op papier klopt maar bij groei, storing of migratie vastloopt. Een goede oefening is daarom een chaos-day op kleine schaal: simuleer het verlies van een component, test herstelprocedures, controleer alerts en meet of de afgesproken RTO en RPO haalbaar lijken.
Een praktisch groeipad naar de architectrol
De beste voorbereiding combineert certificeringsstructuur, praktijkopdrachten en ontwerpdocumentatie. Wie al Azure-beheerervaring heeft, kan sneller naar scenario’s en ontwerpbeslissingen. Wie vooral uit development komt, moet waarschijnlijk extra tijd besteden aan networking, identity, governance en operations. Wie uit traditionele infrastructuur komt, moet meestal wennen aan cloud-native automatisering en gedeelde verantwoordelijkheden.
- Bouw een kleine Azure Landing Zone met gescheiden platform- en workloadstructuur.
- Leg governance vast met Azure Policy, RBAC, tags en diagnostische instellingen.
- Automatiseer platformwijzigingen met Bicep of Terraform en review via een pipeline.
- Voeg Log Analytics, alerts, back-up en herstelrunbooks toe.
- Maak een kostenmodel met budgetten, alerts en expliciete aannames.
- Documenteer keuzes in ADR’s en toets het ontwerp met een Well-Architected-review.
Wie sneller breedte wil opbouwen, kan een doorlopende leerroute overwegen in plaats van losse modules. Readynez biedt bijvoorbeeld Unlimited Microsoft Training voor professionals die meerdere Microsoft-onderwerpen willen combineren, maar de echte vooruitgang ontstaat pas wanneer training wordt gekoppeld aan eigen ontwerpen, code, reviews en incidentoefeningen.
Waar deze voorbereiding toe moet leiden
Microsoft Azure Solutions Architect worden betekent leren ontwerpen onder beperkingen. Elke organisatie heeft bestaande processen, budgetten, risicoacceptatie, compliance-eisen en teamgrenzen. De architect die daarin waarde levert, kiest niet alleen technologie, maar maakt gevolgen begrijpelijk voor security, operations, finance, development en management.
De meest effectieve volgende stap is een klein maar volledig portfolio-project: een landing zone, een workloadontwerp, een kostenmodel, een BCDR-plan, een observability-aanpak en een set ADR’s. Daarmee ontstaat bewijs dat verder gaat dan theorie. Wie daarbij begeleiding wil bij certificeringsvoorbereiding of het kiezen van een passend leerpad, kan contact opnemen met Readynez voor een gesprek over de volgende stap.
