Azure App Service-plannen uitgelegd: hoe prijsniveaus functies en resources afschermen

By Mirko Peters · 2026-10-21

Ontdek hoe Azure App Service-plannen en prijsniveaus functies afschermen, rekenresources beheren en invloed hebben op schalen voor webapps en API's.

Automatically translated with AI from the original post. Read the English original

Ontdek hoe Azure App Service-plannen bepalen welke cloudresources, prijzen en essentiële functiegrenzen je krijgt. Leer hoe je veelvoorkomende valkuilen vermijdt, zoals gedeelde plannen die vol raken, een verkeerd begrip van CPU-quota en het effectief schalen van je webapps en API's, zonder onverwachte productiestoringen of oplopende maandelijkse cloudkosten.

Belangrijkste punten

• Een Azure App Service-plan is een bundel rekenresources die je besturingssysteem, regio, machinegrootte, aantal instanties en prijsniveau bepaalt.
• Prijsniveaus werken als functiegrenzen in plaats van simpele groottesprongen: ze sluiten aangepaste domeinen, SSL-certificaten, deployment slots en automatisch schalen af achter bepaalde niveaus.
• Alle apps die binnen hetzelfde App Service-plan worden gedeployd, delen exact dezelfde onderliggende rekenpool en schalen tegelijkertijd samen.
• De Free- en Shared-niveaus leggen strikte dagelijkse CPU-minuten op en missen essentiële mogelijkheden zoals 'Always On', waardoor ze alleen geschikt zijn voor een eerste kennismaking.
• Productieworkloads hebben minimaal het Basic-niveau nodig om dedicated machines, ondersteuning voor aangepaste domeinen en bescherming tegen time-outs door inactiviteit van de applicatie te krijgen.

De anatomie van een App Service-plan

Wanneer je webapplicaties en REST API's begint te deployen naar de Microsoft-cloud, is het allereerste object dat je aanmaakt een App Service-plan. Veel ontwikkelaars denken ten onrechte dat ze simpelweg hosting kopen voor één webapp. In werkelijkheid is het plan het kernproduct dat je koopt. Het fungeert als een gedeelde pool van virtuele machines en bepaalt tegelijk vijf fundamentele keuzes: het besturingssysteem, de regio waar je code staat, de fysieke grootte van de machines, het aantal actieve instanties en het prijsniveau.

Omdat meerdere apps in één plan kunnen staan, putten alle applicaties, achtergrondtaken, diagnostische logs en deployment slots uit precies dezelfde resourcepool. Compute-isolatie gebeurt uitsluitend op planniveau, niet op appniveau. Als je drie verschillende microservices of interne portals in één plan plaatst, zal een verkeerspiek op één app de CPU- en geheugenresources verbruiken die de andere apps delen. Als je productieworkload dus time-outs begint te krijgen, ligt de oorzaak zelden in een bug in je code; meestal heb je je App Service-plan stilletjes vol laten lopen.

Prijsniveaus als functiegrenzen

Veel beginnende cloudgebruikers zien de prijsladder van Azure App Service—van Free en Shared tot Basic, Standard, Premium en Isolated—als een eenvoudige maatgids waarbij je meer betaalt voor een snellere machine. Microsoft ziet deze niveaus echter voornamelijk als functiegrenzen. Omhoog gaan in de ladder kent niet zomaar meer werkgeheugen of rekenkracht toe; het ontgrendelt actief de mogelijkheden die je architectuur nodig heeft om professioneel te draaien.

Neem bijvoorbeeld de Free-tier: die beperkt je tot één app per plan, plafonneert je gebruik op zestig CPU-minuten per dag, kent één gigabyte geheugen toe en blokkeert aangepaste domeinnamen volledig. Je applicatie moet dan verplicht op een standaardadres onder azurewebsites.net draaien. Bovendien zitten functies als deployment slots, geautomatiseerd schalen en de cruciale instelling ‘Always On’ (die voorkomt dat inactieve web-apps in slaapstand gaan en koude starts veroorzaken) achter specifieke hogere niveaus van het tiersysteem.

Inzicht in de valkuilen van de Free- en Shared-tier

De Free- en Shared-tiers zijn uitdrukkelijk bedoeld als proefrit en niet als functionele productieomgeving. Zestig of tweehonderdveertig minuten CPU-tijd per dag klinkt royaal voor een prototype, maar een druk webpagina of een agressieve Power Automate-flow die je REST API bevraagt, kan dat budget binnen een paar uur opmaken. Bovendien ondersteunen deze lagere niveaus geen opschaling naar meerdere instanties. Hoge gelijktijdigheid leidt daardoor meteen tot throttling en mislukte aanvragen.

Overstappen naar dedicated compute-tiers

Om iets robuusts te bouwen voor een klant of intern team is de Basic-tier het absolute functionele minimum. Basic introduceert dedicated virtuele machines, integratie met aangepaste domeinen, beheerde TLS/SSL-certificaten en de configuratieschakelaar ‘Always On’. Naarmate je verder klimt naar de Standard- en Premium-tiers, krijg je toegang tot geavanceerde enterprisemogelijkheden, zoals deployment slots voor releases zonder downtime en geautomatiseerde horizontale schaalregels.

Opschalen versus uitschalen

Om prestaties en verkeerspieken te beheersen, moet je het fundamentele verschil begrijpen tussen scaling up en scaling out binnen Azure App Service. Deze twee concepten door elkaar halen is een veelvoorkomende bron van architectuurverwarring en opgeblazen cloudrekeningen.

Scaling up betekent verticale groei: je verplaatst je App Service-plan naar een grotere machinegrootte of een hogere prijscategorie om meer ruwe rekenkracht en extra platformfuncties te krijgen. Scaling out betekent horizontale groei: je voegt meer identieke kopieën van je virtuele-machine-instanties toe achter hetzelfde eindpunt, zodat inkomende HTTP-aanvragen gelijkmatig over een grotere pool worden verdeeld.

Waar basistiers handmatige aanpassingen van het aantal instanties toestaan, begint geautomatiseerd schalen op basis van CPU-percentages of tijdschema’s pas bij de Standard-tier. Elke extra instantie die je opstart is weer een fysieke machine die je code draait, en dat heeft direct invloed op je maandelijkse kosten. Voor een diepgaander verhaal over het beheren van je cloudworkloads en het kiezen van de juiste configuraties: luister de volledige aflevering voor expertinzichten en praktische tips.

Conclusie

Azure App Service beheersen betekent verder kijken dan de eenvoud van code pushen en de onderliggende economie van plannen en tiers begrijpen. Als je inziet dat je plan bepaalt hoe resources worden gedeeld, welke functies beschikbaar zijn en welke schaalgrenzen gelden, kun je veerkrachtige cloudarchitecturen ontwerpen die soepel meegroeien zonder onverwachte kosten. Of je nu een interne tool host, een mobiele back-end, of API’s voor het Power Platform: de juiste tier kiezen vanaf dag één bespaart later uren aan refactoring. Luister naar de volledige aflevering van de M365 FM Podcast en hoor ons volledige gesprek over het vermijden van beginnersvalkuilen, het beheren van deployment slots en het optimaliseren van je Microsoft-cloudomgeving.

Veelgestelde vragen

Wat is een Azure App Service-plan?

Een Azure App Service-plan definieert de set fysieke rekenresources, het besturingssysteem, de regio en de schaalgrenzen die worden gebruikt door een of meer web-apps of API’s. Het fungeert als de factuur- en resourcegrens voor je clouddeployments.

Waarom zijn functies gekoppeld aan prijscategorieën?

Microsoft structureert de App Service-tiers om informele testomgevingen te scheiden van productieworkloads op enterprisniveau. Functies zoals aangepaste domeinen, deployment slots en automatisch schalen vereisen dedicated infrastructuur en beheerlast, die alleen in betaalde tiers beschikbaar is.

Kunnen meerdere apps hetzelfde App Service-plan delen?

Ja, je kunt meerdere web-apps en API’s binnen één App Service-plan hosten. Alle apps in dat plan delen echter dezelfde onderliggende CPU- en geheugenresources en schalen tegelijkertijd mee.

Wat is het verschil tussen scaling up en scaling out?

Opschalen (scale up) betekent overstappen naar een grotere machine of een hogere prijscategorie voor meer rekenkracht en functies, terwijl uitschalen (scale out) extra identieke instanties van je app toevoegt om een hoger verkeersvolume aan te kunnen.