VMs vs AKS vs App Service vs Functions voor AZ-305

• Begin met de minst beheerde compute-optie die de workload correct ondersteunt.
• Kies pas voor meer controle wanneer runtime, netwerk, state, compliance of operations dat vereisen.
• Bereken kosten op basis van gebruikspatroon, schaalgedrag, opslag, dataverkeer en beheerlast.
• Veranker de keuze in beschikbaarheid, governance, security en teamcompetenties, niet alleen in technische voorkeur.

Een AZ-305-computeontwerp is een onderbouwde keuze voor het platform waarop een workload draait. Een architect moet kunnen uitleggen waarom een workload op een virtuele machine, Azure Kubernetes Service, Azure App Service of Azure Functions hoort te draaien, en welke gevolgen die keuze heeft voor schaalbaarheid, beschikbaarheid, beveiliging, kosten en beheer.

Dat sluit rechtstreeks aan bij het domein “design compute solutions” binnen Microsoft-examen AZ-305. De examenvragen zijn doorgaans scenario-gericht: een organisatie heeft een bestaande applicatie, bepaalde eisen rond latency of compliance, een beperkt platformteam, of een workload met pieken. De juiste keuze ontstaat dan uit trade-offs, niet uit voorkeur voor de nieuwste service.

Waarom compute-keuzes in AZ-305 vaak lastig zijn

Azure biedt meerdere manieren om code uit te voeren, en veel workloads passen technisch gezien op meer dan één optie. Een web-API kan op App Service draaien, als container op AKS worden geplaatst, in een VM worden gehost of worden opgesplitst in Functions. Het verschil zit in hoeveel verantwoordelijkheid het team zelf wil of moet dragen.

Een praktische vuistregel is om te starten bij de minst beheerde optie die aan de vereisten voldoet. Voor een eenvoudige webapp of API is App Service vaak logischer dan AKS, omdat Azure meer platformbeheer overneemt. Voor event-driven verwerking met korte, stateless taken kan Functions beter passen. AKS of VMs worden interessanter wanneer er fijnmazige controle nodig is over runtime, netwerk, sidecars, stateful componenten, OS-configuratie of migratiecompatibiliteit.

Die volgorde voorkomt over-engineering. Een veelgemaakte ontwerpfout is een eenvoudige webworkload direct op Kubernetes plaatsen, terwijl het team nog geen volwassen aanpak heeft voor clusterbeheer, observability, patching, secrets, ingress en capacity planning. AKS kan zeer geschikt zijn, maar het introduceert ook een operationeel model dat in de totale architectuur moet worden meegenomen.

De vier belangrijkste opties in context

Azure Virtual Machines geven de meeste controle over besturingssysteem, netwerkconfiguratie, middleware en geïnstalleerde software. Ze passen goed bij lift-and-shift migraties, legacy-applicaties, software met specifieke OS-afhankelijkheden, of scenario’s waarin een leverancier alleen VM-installaties ondersteunt. Die vrijheid heeft een prijs: patching, hardening, monitoring, back-up, sizing en vaak ook meer operationele procedures blijven bij het platform- of applicatieteam liggen.

Azure Kubernetes Service is geschikt wanneer containers, microservices, portability en geavanceerde deploymentpatronen centraal staan. AKS is sterk bij teams die Kubernetes al operationeel aankunnen en workloads hebben die profiteren van containerorkestratie. Het is minder logisch voor een enkele eenvoudige webapp zonder duidelijke behoefte aan orchestration, omdat zelfs een beheerde Kubernetes-service nog steeds clusterkeuzes, node pools, upgrades, policies, ingress, logging en autoscaling vraagt.

Azure App Service is vaak de nuchtere keuze voor webapps, REST-API’s en backendservices die een beheerd hostingplatform nodig hebben. Het ondersteunt deployment slots, autoscale, integratie met Microsoft Entra ID, private networking-opties en gangbare runtimes. De service beperkt de noodzaak om servers of clusters te beheren, maar vraagt nog steeds aandacht voor App Service Plan sizing, idle-kosten, slot-strategie en netwerkontwerp.

Azure Functions past bij event-driven taken zoals queue processing, timers, webhooks, integraties en kleine verwerkingsstappen. Het model is aantrekkelijk bij bursty workloads, omdat capaciteit kan meebewegen met events. Het ontwerp moet wel stateless blijven; stateful logica, lange processen en afhankelijkheden die warm-startgedrag vereisen, vragen een zorgvuldiger keuze of een combinatie met Durable Functions, App Service of andere orchestration-services.

Vergelijkingsmatrix voor architectuurbeslissingen

Onderstaande matrix is geen vervanging voor sizing en proof-of-concept, maar helpt om de eerste keuze te structureren. Voor AZ-305 is vooral belangrijk dat de redenatie zichtbaar is: welke service vermindert beheerlast, welke service biedt controle, en waar ontstaan kosten- of schaalrisico’s?

Kosten en schaalbaarheid zijn ontwerpcriteria, geen nazorg

Compute-kosten worden vaak te laat in het ontwerp besproken. Een architectuur kan technisch correct zijn en toch financieel onvoorspelbaar worden door permanente idle-capaciteit, verkeerde opslagkeuzes, overbodige node pools of onverwacht dataverkeer tussen regio’s en netwerken. In Azure moeten compute, storage, networking en monitoring samen bekeken worden.

Bij VMs speelt sizing een grote rol. Een voorspelbare 24/7 workload kan baat hebben bij reserveringsopties of Azure Hybrid Benefit wanneer de licentiesituatie dat toelaat, terwijl ontwikkel- en testomgevingen vaak beter werken met start-stop automatisering en kleinere SKU’s. Ook schijfkeuze telt mee: Premium SSD v2, Premium SSD en Standard-opties hebben verschillende prestatie- en kostenprofielen. De goedkoopste schijf is niet automatisch geschikt voor transactionele workloads, maar overdimensionering kan even problematisch zijn.

Bij AKS zitten kosten niet alleen in applicatiepods. System node pools, logverzameling, load balancers, container registry, egress en onderliggende disks tellen mee. Horizontal Pod Autoscaler en cluster autoscaler kunnen helpen, maar moeten bewust worden ontworpen en getest. Zonder requests, limits en schaalregels kan een containerplatform tegelijk duurder en minder betrouwbaar worden dan verwacht.

App Service lijkt eenvoudiger, maar een App Service Plan kost zolang het draait, ook wanneer de applicatie weinig verkeer krijgt. Voor voorspelbare webworkloads is dat acceptabel en vaak efficiënt; voor sterk wisselende kleine taken kan Functions beter passen. Bij Functions verschuift de aandacht naar triggers, cold starts, integraties, execution limits en het vermijden van verborgen kosten door excessieve retries of chatty netwerkverkeer.

Belgische en Europese context: regio, data en latency

Belgische organisaties kiezen in Azure vaak voor regio’s zoals West Europe of North Europe vanwege nabijheid, beschikbaarheid van services en Europese dataresidentie-eisen. Er bestaat echter geen algemene regel die elke workload oplost. De juiste regio hangt af van servicebeschikbaarheid, disaster recovery-model, gebruikerslocaties, koppelingen met on-premises systemen en afspraken rond gegevensverwerking.

Latency moet expliciet worden getest, zeker bij hybride workloads, industriële omgevingen, retailnetwerken of applicaties met veel databasecalls. Een webapp in één regio en data of integraties in een andere regio kunnen meer impact hebben dan de compute-keuze zelf. Ook egresskosten en datastromen horen in het ontwerpdocument, omdat ze security, compliance en budget tegelijk beïnvloeden.

Voor governance is compute zelden los te zien van landing zones, Azure Policy, identity en network segmentation. Microsoft Entra ID, managed identities, private endpoints, Microsoft Defender for Cloud en logging naar een centraal platform bepalen hoe veilig en beheerbaar de workload wordt. In AZ-305-scenario’s is dat relevant omdat compute-keuzes vaak verbonden zijn met bredere ontwerpbeslissingen rond security, monitoring en operations.

Mini-case: Benelux retail-API met piekbelasting

Een retailer in de Benelux wil een promotieplatform bouwen voor campagnes met grote, korte pieken. De applicatie bestaat uit een publieke web-API, enkele achtergrondtaken voor ordervalidatie en integraties met bestaande systemen. Het platformteam is klein en heeft beperkte Kubernetes-ervaring, maar gebruikt wel CI/CD en infrastructure-as-code.

In dit scenario is App Service een logische kandidaat voor de web-API, omdat deployment slots, autoscale en beheerde runtime-ondersteuning veel operationele last wegnemen. Functions kunnen de achtergrondtaken verwerken wanneer events binnenkomen via queues of berichtenstromen. AKS zou pas sterker worden als er meerdere containerteams, complexe service-to-service patronen, custom ingress-eisen of portability-doelen zijn. VMs blijven vooral relevant als een bestaande component niet anders kan worden gemigreerd.

Het ontwerp moet vervolgens worden vastgelegd in Bicep of Terraform, samen met tagging, policies, diagnostic settings, autoscale-regels en budgetbewaking. Infrastructure-as-code is hier geen bijzaak: het maakt de compute-keuze reproduceerbaar en dwingt guardrails af rond security en kosten. Dat sluit ook aan bij de AZ-305-verwachting dat een architect niet alleen een service kiest, maar een beheerbaar ontwerp neerzet.

Hoe dit helpt bij AZ-305-voorbereiding

Wie zich voorbereidt op AZ-305 doet er goed aan compute-services niet als losse productdefinities te studeren. De vraag is meestal niet “wat is AKS?”, maar “welke compute-oplossing past bij deze constraints?”. Kandidaten moeten daarom oefenen met scenario’s waarin kosten, availability zones, identity, monitoring, compliance en operationele vaardigheden tegelijk meespelen.

Een nuttige studieaanpak is om per workload eerst de beheerlast te verlagen en daarna pas extra controle toe te voegen. Start bij Functions of App Service wanneer de workload daar netjes past. Ga naar AKS wanneer containers en orchestration echt waarde toevoegen. Kies VMs wanneer applicatie-eisen, migratiedruk of vendorbeperkingen dat noodzakelijk maken. Die redenering is vaak sterker dan het memoriseren van service-eigenschappen.

Gestructureerde oefening kan helpen om die afwegingen sneller te herkennen. De AZ-305-training van Readynez kan in dat kader nuttig zijn voor lezers die examengerichte labs en architectuurscenario’s willen combineren met de officiële Microsoft-examendomeinen.

FAQ

Wat zijn de belangrijkste Azure compute-oplossingen voor AZ-305?

Voor AZ-305 zijn vooral Virtual Machines, Azure Kubernetes Service, Azure App Service en Azure Functions belangrijk wanneer het gaat om compute-ontwerp. Azure Virtual Desktop kan ook relevant zijn in scenario’s rond desktopvirtualisatie, maar voor applicatiehosting ligt de nadruk meestal op VMs, containers, beheerde webhosting en serverless verwerking.

Het examen verwacht dat kandidaten deze opties kunnen koppelen aan schaalbaarheid, beschikbaarheid, beheer, security en kosten. De service op zich kennen is onvoldoende; de architecturale afweging is het belangrijkste.

Wanneer kies je voor VMs in plaats van App Service of AKS?

VMs zijn passend wanneer een workload specifieke controle over het besturingssysteem, geïnstalleerde software, netwerkconfiguratie of legacy-afhankelijkheden vereist. Ze zijn ook nuttig bij migraties waarbij applicaties niet eenvoudig kunnen worden aangepast naar een platformservice of containeromgeving.

Als een webapp zonder zware OS-afhankelijkheden kan draaien op een beheerd platform, is App Service vaak eenvoudiger te beheren. AKS is sterker wanneer containerorkestratie echt nodig is, maar het vraagt meer operationele volwassenheid dan veel teams aanvankelijk verwachten.

Is AKS altijd de beste keuze voor schaalbare applicaties?

Nee. AKS kan zeer schaalbaar zijn, maar schaalbaarheid hangt af van applicatieontwerp, clusterconfiguratie, node pools, autoscaling, netwerk, storage en observability. Voor eenvoudige web-API’s kan App Service vaak voldoende schaalbaarheid leveren met minder beheerlast.

Voor bursty, event-driven taken kan Functions een betere match zijn. AKS wordt vooral interessant wanneer teams meerdere containerworkloads beheren en de voordelen van Kubernetes opwegen tegen de complexiteit.

Welke kostenvalkuilen komen vaak voor bij Azure compute?

Veelvoorkomende valkuilen zijn te ruim gesizede VMs, App Service Plans die blijven draaien zonder voldoende gebruik, AKS-system nodes en loggingkosten die niet zijn meegerekend, verkeerde schijf-SKU’s en onderschat dataverkeer tussen regio’s of netwerken. Autoscale helpt alleen wanneer schaalregels realistisch zijn getest.

Voor voorspelbare 24/7 workloads kunnen reserveringsopties interessant zijn, terwijl variabele workloads vaak baat hebben bij dynamische schaalmodellen. Exacte kosten moeten altijd worden gevalideerd met de actuele Azure Pricing-informatie en het concrete gebruikspatroon.

Hoe belangrijk is praktijkervaring voor AZ-305?

Praktijkervaring is belangrijk omdat AZ-305 sterk leunt op ontwerpkeuzes in scenario’s. Kandidaten die alleen definities leren, missen vaak de nuance rond schaalbaarheid, netwerk, security, governance en kosten.

Hands-on labs helpen om te zien wat er achter een keuze schuilgaat: hoe autoscale wordt ingesteld, hoe deployment slots werken, hoe AKS-capacity zich gedraagt en hoe monitoring of policies het ontwerp beïnvloeden. Die ervaring maakt examenvragen beter interpreteerbaar en helpt ook in echte projecten.

Compute-keuzes die standhouden in projecten

Een goede Azure compute-keuze is verdedigbaar wanneer ze past bij de workload, het team, het budget en de governance-eisen. De meest effectieve architecten kiezen niet automatisch de service met de meeste mogelijkheden, maar de service die voldoende controle biedt zonder onnodige operationele last te creëren.

De sleutel is om elk scenario terug te brengen tot concrete vragen: hoeveel beheer wil het team dragen, hoe voorspelbaar is de belasting, welke eisen gelden rond data en latency, en waar zitten de echte beperkingen? Wie die redenering consequent toepast, bouwt betere Azure-architecturen en bereidt zich tegelijk gerichter voor op AZ-305.