VM vs App Service vs Functions vs AKS: Så väljs rätt Azure Compute för AZ-305

Azure Compute-valet avgör hur en intern orderplattform körs, skalas och förvaltas: webbgränssnittet kan ha jämn trafik under kontorstid, API:erna korta toppar vid kampanjer, databasen känsliga kunduppgifter och driften ansvaras för av ett litet plattformsteam. För AZ-305 handlar beslutet därför sällan om vilken tjänst som är mest avancerad, utan om vilken tjänst som passar arbetslastens beteende, risknivå och driftmodell.

Azure Compute handlar om att välja rätt körmiljö för applikationer och arbetsflöden i Azure, från virtuella maskiner och skalningsgrupper till App Service, Functions och Kubernetes. För az-305/">AZ-305: Designing Microsoft Azure Infrastructure Solutions förväntas kandidaten kunna resonera som en arkitekt: väga kontroll mot enkel drift, kapacitet mot kostnad, och tillgänglighet mot komplexitet.

Senast uppdaterad: 2026. Terminologi i artikeln följer nuvarande Microsoft-namn, där Azure Active Directory benämns Microsoft Entra ID och Azure Security Center benämns Microsoft Defender for Cloud.

Compute-valet börjar med arbetslasten

Ett vanligt misstag i AZ-305-förberedelser är att memorera tjänsternas egenskaper var för sig. I verkliga designbeslut börjar arkitekten i andra änden: hur applikationen beter sig, vilka beroenden den har och vilka begränsningar organisationen lever med. En enkel webbapp kan bli onödigt dyr och svårdriven om den placeras i AKS utan ett tydligt container- eller orkestreringsbehov, medan en äldre Windows-applikation med särskilda OS-beroenden ofta kräver den kontroll som virtuella maskiner ger.

Ett praktiskt beslutsramverk kan byggas runt arbetslastens tillstånd, trafikprofil, runtime, driftkrav och efterlevnad. Är applikationen stateless eller behöver den lokal state? Är trafiken jämn, toppig eller händelsedriven? Krävs Windows, Linux, containrar, särskilda drivrutiner eller låg nivå av OS-åtkomst? Har teamet mognad för klusterlivscykel, patchning och containerhärdning? Behöver arbetslasten privat nätverksisolering, strikt policy eller särskilda efterlevnadskontroller?

När dessa frågor besvaras blir compute-valet tydligare. En stateless webbapp med standardruntime passar ofta App Service. En händelsedriven integrationskomponent passar ofta Functions. En containeriserad mikrotjänstplattform med flera team, service discovery och avancerad skalning kan motivera AKS. En äldre applikation, en licenskänslig produkt eller en arbetslast med krav på full OS-kontroll pekar ofta mot virtuella maskiner eller VM Scale Sets.

Virtuella maskiner och VM Scale Sets

Virtuella maskiner i Azure är rätt utgångspunkt när arbetslasten kräver kontroll över operativsystem, installerad programvara, nätverkskonfiguration eller särskilda beroenden. De används ofta vid lift-and-shift-migreringar, verksamhetskritiska system med etablerade driftsrutiner och applikationer där PaaS-alternativ inte matchar tekniska eller regulatoriska krav. Microsofts dokumentation beskriver separata tjänstgränser, storleksfamiljer och tillgänglighetsalternativ, vilket bör kontrolleras mot vald region innan designen låses.

För en enskild serverarbetslast är en VM enkel att förstå, men den är sällan den bästa resiliensmodellen ensam. När samma applikationsroll behöver flera instanser, jämn distribution och autoskalning är VM Scale Sets normalt ett mer arkitektoniskt lämpligt val. Det gör compute-lagret lättare att behandla som en pool av kapacitet i stället för som en samling individuella servrar.

Kostnadsmässigt erbjuder VM-baserade lösningar flera reglage, men de kräver aktiv styrning. Reserveringar och Azure savings plans kan vara relevanta för stabil baslast, medan Spot kan passa avbrottståliga batchjobb eller byggagenter. Samtidigt kan loggning, managed disks, lastbalanserare, egress-trafik och säkerhetsverktyg påverka totalpriset mer än själva VM-storleken i större miljöer.

App Service för webbappar och API:er

Azure App Service passar när applikationen främst är en webbapp, ett API eller en bakgrundsprocess som kan köras inom en hanterad plattform. För arkitekter är den stora vinsten att mycket av driftansvaret flyttas från teamet till plattformen: runtime-hantering, inbyggd skalning, deployment slots, certifikathantering och integration med identitetstjänster blir enklare än i en VM-baserad modell.

Det betyder däremot inte att designen blir fri från begränsningar. App Service-planens storlek, nätverksintegration, filsystemets beteende, outbound connectivity och SNAT-portar måste förstås när applikationen kommunicerar med databaser, interna API:er eller tredjepartstjänster. Ett vanligt driftproblem är att VNET-integration läggs till utan att utgående trafik och NAT Gateway-planering hanteras, vilket kan skapa portbrist under hög samtidighet.

App Service är ofta rätt svar i AZ-305-scenarier där kravet är snabb och stabil webbdrift utan behov av full containerorkestrering. Om samma scenario innehåller flera oberoende mikrotjänster, avancerade sidecar-mönster eller krav på Kubernetes-native distribution kan AKS bli mer relevant. Om kravet däremot bara är att köra en webbapp med standardruntime är App Service ofta en mer proportionerlig design.

Functions för händelsedriven compute

Azure Functions lämpar sig för kod som reagerar på händelser: meddelanden i en kö, filer som landar i lagring, HTTP-anrop, timers eller integrationsflöden. I en AZ-305-design är Functions särskilt intressant när lasten är ojämn och arbetsenheten är liten nog att beskrivas som en funktion snarare än en långlivad tjänst.

Serverless-modellen kan ge effektiv resursanvändning, men plattformsgränserna är viktiga. Cold starts kan påverka svarstid, exekveringstid kan begränsa vissa jobb och nätverkskrav kan göra att en Premium-plan blir mer lämplig än en ren konsumtionsmodell. Om funktionen behöver privat åtkomst till databaser, stabil låg latens eller långvariga processer bör arkitekten granska planval, samtidighet och integrationsmönster innan tjänsten väljs.

Ett konkret scenario är en fakturaplattform i norra Europa där PDF-filer landar i Blob Storage, metadata läggs i en kö och en funktion extraherar information innan resultatet skrivs till en databas. Om datan är känslig bör funktionen använda managed identity, privat nätverksåtkomst där det behövs och loggning som skyddar personuppgifter. Compute-valet blir då inte enbart serverless för enkelhetens skull, utan en design där identitet, nätverk och observability följer med från början.

AKS när Kubernetes är en faktisk designförutsättning

Azure Kubernetes Service är relevant när applikationsplattformen verkligen behöver Kubernetes: flera containeriserade tjänster, oberoende releasecykler, avancerad trafikstyrning, service mesh-liknande mönster eller portabilitet mellan miljöer. AKS ger flexibilitet, men den flexibiliteten skapar också ett operativt ansvar som ofta underskattas i designdiskussioner.

Klusteruppgraderingar, nodpooler, autoskalning, container image-säkerhet, nätverksmodeller, ingress, policy och runtime-härdning kräver tydligt ägarskap. Om organisationen saknar plattformsteam eller etablerade DevOps-rutiner kan AKS göra en enkel applikation svårare att drifta än nödvändigt. I AZ-305-sammanhang är det därför viktigt att motivera AKS med krav, inte med teknikpreferens.

Kostnader i AKS sitter ofta i noderna och i tjänsterna runt klustret. Separata nodpooler för system- och applikationsworkloads, autoskalning och rätt dimensionering är centrala designval, men loggvolymer, container registry, lastbalansering och nätverkstrafik kan också bli betydande. Microsofts AKS-dokumentation bör användas för att kontrollera stödda regionfunktioner, klusterbegränsningar och rekommenderade driftsmönster.

Resiliens: zoner, regioner och state

Resiliens påverkar compute-valet lika mycket som språk och runtime. En applikation som måste tåla zonfel behöver en annan design än en intern tjänst som kan återställas manuellt. I Azure innebär det ofta att compute placeras över tillgänglighetszoner där regionen stödjer det, att instanser görs stateless och att state flyttas till datalager som själva har en tydlig replikering- och återställningsstrategi.

För VM-baserade lösningar innebär hög tillgänglighet vanligtvis flera instanser, lastbalansering och gärna VM Scale Sets i stället för handhanterade servrar. För App Service kan zonredundans och skalning på plattformsnivå vara relevant beroende på plan och region. För Functions beror resiliensen på både hosting-plan, triggerkällor och downstream-tjänster. För AKS krävs planering av nodpooler, pod disruption budgets, ingress och beroenden utanför klustret.

Multi-region-design bör väljas med omsorg. Aktiv-aktiv över regioner kan ge bättre regional tolerans och lägre latens för globala användare, men den ökar komplexiteten kring datareplikering, konfliktlösning, distribution och drift. Aktiv-passiv kan vara enklare att styra, men återställningstid och verifiering av failover blir centrala. Azure Front Door och Traffic Manager används ofta i sådana mönster, men valet beror på applikationstyp, DNS-beteende, HTTP-krav och hur state hanteras.

En användbar arkitekturskiss för en stateless e-handelsfront skulle beskriva två App Service-instanser i separata zoner, en regional databastjänst med egen redundansmodell, Azure Front Door framför applikationen och Key Vault åtkomligt via managed identity. Skissens poäng är att compute-lagret kan bytas eller skalas, medan data, identitet och trafikstyrning är designade för felhantering från början.

Kostnad är en arkitekturfråga

Compute-kostnad handlar inte bara om att välja billigaste tjänst. Den styrs av belastningsmönster, skalningsförmåga, drifttid, loggning, nätverk, redundans och kapacitetsreservationer. En VM som körs dygnet runt med låg nyttjandegrad kan vara dyrare än en PaaS-lösning med autoskalning, men en stabil och tung arbetslast kan i vissa fall bli mer förutsägbar med reserverad eller planerad kapacitet.

Autoskalning är ett av de viktigaste kostnadsreglagen, men det kräver att applikationen tål horisontell skalning. Stateless design, externa sessionslager och köbaserad avkoppling gör det lättare att skala in och ut utan att användarupplevelsen påverkas. Om applikationen kräver lokal state eller långa processer kan skalning bli mer begränsad, oavsett compute-tjänst.

Loggning är ett område som ofta förbises. AKS och VM-miljöer kan skapa stora mängder infrastruktur- och applikationsloggar, medan App Service och Functions snabbt kan öka observability-kostnader om allt samlas in utan filtrering. En arkitekt bör därför designa loggnivåer, retention, diagnosinställningar och larm lika avsiktligt som compute-resurserna.

Säkerhet och identitet måste designas tidigt

Compute-resurser blir snabbt riskpunkter om identitet och nätverk läggs till i efterhand. Microsoft Entra ID bör användas för identitetsstyrning, och managed identities bör prioriteras när applikationer behöver åtkomst till Azure-resurser. Det minskar beroendet av manuellt roterade hemligheter och gör behörigheter lättare att granska.

Microsoft Defender for Cloud kan ge rekommendationer för säker konfiguration, sårbarheter och skydd av arbetslaster, medan Azure Policy hjälper organisationen att styra var resurser får skapas, vilka SKU:er som används och vilka säkerhetsinställningar som krävs. För AZ-305 är det viktiga inte att räkna upp verktyg, utan att visa hur styrning påverkar arkitekturen: nätverksisolering, identitetsmodell, kryptering, patchning och övervakning behöver passa compute-valet.

En containerplattform kräver till exempel policy för image-källor, secrets-hantering och klusteråtkomst. En App Service-lösning kräver tydliga regler för deployment, managed identity, TLS, VNET-integration och privata endpoints där det behövs. En VM-miljö kräver patchstrategi, endpoint-skydd, diskåtkomst och rollbaserad åtkomstkontroll. Säker design är därför en del av compute-beslutet, inte ett separat lager som kan skjutas upp.

Så bör AZ-305-kandidater resonera i scenariobaserade frågor

AZ-305-frågor testar ofta förmågan att välja en rimlig design under begränsningar. Om scenariot beskriver ett litet team, en standardwebbapp och krav på snabb distribution är App Service ofta mer rimligt än AKS. Om scenariot beskriver befintliga servrar med särskilda OS-beroenden är VM eller VM Scale Sets mer realistiskt. Om lasten är händelsedriven och kortvarig bör Functions övervägas, men bara efter att nätverk, körtid och latenskrav har kontrollerats.

Readynez kan nämnas i sammanhanget som ett exempel på strukturerad AZ-305-förberedelse där designval tränas genom scenarier, men själva arkitekturfärdigheten byggs genom att koppla varje Azure-tjänst till krav, begränsningar och konsekvenser. Det är denna koppling som gör skillnaden mellan att känna igen en tjänst och att kunna designa en lösning.

Från provmål till hållbara arkitekturval

Den bästa vägen genom Azure Compute för AZ-305 är att tänka i arbetslaster snarare än tjänstelistor. VM och VM Scale Sets ger kontroll, App Service ger hanterad webbdrift, Functions ger händelsedriven skalning och AKS ger Kubernetes-baserad flexibilitet när komplexiteten är motiverad. Rätt val avgörs av state, trafik, runtime, driftmognad, säkerhet och kostnadsmodell.

En praktisk nästa åtgärd är att ta ett eget system och beskriva dess compute-behov med samma frågor: vad måste köras, hur skalar det, var finns state, vilka fel måste det tåla och vem ska drifta det? Den som vill träna detta mer strukturerat inför provet kan använda officiella Microsoft-mål tillsammans med en AZ-305-kurs från Readynez som stöd för scenariobaserad repetition.

FAQ

Vilka Azure Compute-lösningar är viktigast för AZ-305?

De mest centrala compute-alternativen är virtuella maskiner, VM Scale Sets, App Service, Azure Functions och AKS. Azure Virtual Desktop kan också förekomma i bredare infrastrukturscenarier, men för applikationsdesign ligger fokus ofta på hur arkitekten väljer mellan IaaS, PaaS, serverless och containerplattform.

Hur väljs rätt Azure Compute-lösning?

Börja med arbetslastens egenskaper: stateless eller stateful, jämn eller toppig trafik, runtime-krav, containerbehov, driftmognad, nätverksisolering och efterlevnad. Därefter matchas valet mot tjänstens styrkor och begränsningar. App Service passar ofta webbappar, Functions passar händelser, AKS passar Kubernetes-krav och VM eller VM Scale Sets passar kontroll- och kompatibilitetsbehov.

När är AKS rätt val jämfört med App Service?

AKS är rätt när Kubernetes är en faktisk plattformskravbild, exempelvis många containeriserade tjänster, avancerad orkestrering, separata nodpooler eller Kubernetes-native distributionsmönster. App Service är ofta mer lämpligt för vanliga webbappar och API:er där teamet vill minska driftbördan och inte behöver full klusterkontroll.

Vilka kostnadsfrågor bör ingå i designen?

Arkitekten bör granska autoskalning, baslast, reservations- eller savings-plan-möjligheter, Spot-lämplighet, nodpooler, loggvolymer, nätverkstrafik och redundans. Den billigaste enskilda compute-resursen är inte alltid den mest kostnadseffektiva lösningen när drift, säkerhet och återställning räknas in.

Hur viktig är praktisk erfarenhet för AZ-305?

Praktisk erfarenhet är viktig eftersom provet bygger på designbeslut snarare än isolerade definitioner. Kandidaten bör kunna förklara varför en tjänst passar ett scenario, vilka begränsningar valet innebär och hur lösningen påverkas av säkerhet, tillgänglighet, kostnad och drift.