Azure Virtual Machines-baslinjearkitektur i en Azure-landningszon

Arkitekturen i den här artikeln expanderar baslinjearkitekturen för den virtuella datorn (VM) för att hantera ändringar och förväntningar när du distribuerar den i en Azure-landningszon.

I exemplet i den här artikeln vill en organisation att en VM-baserad arbetsbelastning ska använda federerade resurser som ett plattformsteam hanterar centralt. Dessa resurser omfattar nätverksresurser för anslutning mellan platser, hantering av identitetsåtkomst och principer. Det här exemplet förutsätter att organisationen antar Azure-landningszoner för att framtvinga konsekvent styrning och kostnadseffektivitet för flera arbetsbelastningar.

Som arbetsbelastningsägare kan du avlasta hanteringen av delade resurser till centrala team, så att du kan fokusera på arbetsbelastningsutvecklingsarbetet. Den här artikeln beskriver arbetsbelastningsteamets perspektiv. Rekommendationer som gäller för plattformsteamet anges.

Artikellayout

Arkitektur	Designbeslut	Azure Well-Architected Framework-metod
▪ Arkitekturdiagram ▪ Arbetsbelastningsresurser ▪ Federerade resurser	▪ Prenumerationskonfiguration ▪ Nätverkskrav ▪ Nätverksdesign ändras från baslinjen ▪ Övervakning ▪ Korrigeringsefterlevnad ▪ Organisationsstyrning ▪ Ändringshantering	▪ Tillförlitlighet ▪ Säkerhet ▪ Kostnadsoptimering

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Komponenter

Alla Arkitekturer för Azure-landningszoner har en uppdelning av ägarskapet mellan plattformsteamet och arbetsbelastningsteamet. Programarkitekter och DevOps-team måste ha en stark förståelse för detta ansvarsfördelning för att förstå vad som är under deras direkta inflytande eller kontroll och vad som inte är det.

Teamägda arbetsbelastningsresurser

Följande resurser förblir i huvudsak oförändrade från baslinjearkitekturen.

• Azure Virtual Machines är programplattformen. Beräkningsresurserna distribueras mellan tillgänglighetszoner.

• Azure Load Balancer används för att privat lastbalansera trafik från de virtuella datorerna på klientsidan till de virtuella serverdelsdatorerna. Lastbalanseraren distribuerar trafik till virtuella datorer mellan zoner.

• Azure Application Gateway används som omvänd proxy för att dirigera användarbegäranden till de virtuella datorerna på klientsidan. Den valda SKU:n används också som värd för Azure Web Application Firewall för att skydda de virtuella datorerna på klientsidan från potentiellt skadlig trafik.

• Azure Key Vault används för att lagra programhemligheter och certifikat.

• Azure Monitor, Log Analytics och Application Insights används för att samla in, lagra och visualisera observerbarhetsdata.

• Azure Policy används för att tillämpa principer som är specifika för arbetsbelastningen.

Arbetsbelastningsteamet underhåller och uppfyller följande resurser och ansvarsområden.

• Virtuella ekernätverksundernät och nätverkssäkerhetsgrupper (NSG:er) som placeras på dessa undernät för att upprätthålla segmentering och kontrollera trafikflödet.

• Privata slutpunkter för säker anslutning till PaaS-lösningar (Plattform som en tjänst) och de privata DNS-zoner som krävs för dessa slutpunkter.

• Azure Managed Disks lagrar loggfiler på serverdelsservrarna och data behålls även när virtuella datorer startas om. Klientdelsservrarna har anslutna diskar som du kan använda för att distribuera ditt tillståndslösa program.

Plattformsteamägda resurser

Plattformsteamet äger och underhåller dessa centraliserade resurser. Den här arkitekturen förutsätter att dessa resurser är företablerade och beaktar dem beroenden.

• Azure Firewall i hubbnätverket används för att inspektera och begränsa utgående trafik. Den här komponenten ersätter standardlastbalanseraren i baslinjearkitekturen, vilket inte ger begränsningar för utgående trafik till Internet.

• Azure Bastion i hubbnätverket ger säker driftåtkomst till virtuella arbetsbelastningsdatorer. I baslinjearkitekturen äger arbetsbelastningsteamet den här komponenten.

• Det virtuella ekernätverket är där arbetsbelastningen distribueras.

• Användardefinierade vägar (UDR) används för att tvinga tunneltrafik till hubbnätverket.

• Azure Policy-baserade styrningsbegränsningar och DeployIfNotExists (DINE)-principer är en del av arbetsbelastningsprenumerationen.

Prenumerationskonfiguration

I en landningszonskontext måste arbetsbelastningsteamet informera plattformsteamet om sina specifika krav.

Arbetsbelastningsteamet måste innehålla detaljerad information om det nätverksutrymme som din arbetsbelastning behöver, så att plattformsteamet kan allokera nödvändiga resurser. Ditt team fastställer kraven och plattformsteamet bestämmer ip-adresserna som ska tilldelas i det virtuella nätverket och den hanteringsgrupp som prenumerationen har tilldelats.

Plattformsteamet tilldelar en lämplig hanteringsgrupp baserat på arbetsbelastningens affärskritiskhet och tekniska krav, till exempel om en arbetsbelastning exponeras för Internet. Organisationen avgör konfigurationen av dessa hanteringsgrupper och plattformsteamet implementerar dem.

Till exempel beaktas hanteringsgrupperna i programscenarierna för baslinjearkitekturen:

• Privata program, till exempel interna verksamhetsspecifika program eller kommersiella cots-lösningar (off-the-shelf), som ofta finns under corp-hanteringsgruppen för Azure-landningszoner.

• Offentliga program, som i internetuppkopplade program, som ofta ingår i Corp- eller Online-hanteringsgruppen.

Plattformsteamet ansvarar också för att konfigurera en prenumeration eller en grupp prenumerationer för arbetsbelastningsdistributionen.

Följande avsnitt innehåller vägledning om den inledande prenumerationskonfigurationen. Plattformsteamet gör dock vanligtvis ändringar i de centraliserade tjänsterna för att hantera missade eller ändrade krav. Plattformsändringar har en bredare effekt på alla arbetsbelastningsteam.

Därför måste plattformsteamet se till att alla VM-arbetsbelastningar är förberedda för eventuella ändringar, och de måste vara medvetna om livscykeln för den VM-baserade lösningen och testcykeln. Mer information finns i Hantera ändringar över tid.

Krav och uppfyllanden av arbetsbelastningar

Arbetsbelastningsteamet och plattformsteamen har två huvudsakliga ansvarsområden: tilldelning av hanteringsgrupp och nätverkskonfiguration. För den här arkitekturen bör du överväga följande nätverkskrav som du bör kommunicera med plattformsteamet. Använd dessa punkter som exempel för att förstå diskussionen och förhandlingen mellan de två teamen när du implementerar en liknande arkitektur.

• Antalet virtuella ekernätverk: I den här arkitekturen krävs bara en dedikerad eker. De distribuerade resurserna behöver inte sträcka sig över flera nätverk och är samlokaliserade i ett enda virtuellt nätverk.

• Ekernätverkets storlek: Ta hänsyn till driftkraven och den förväntade tillväxten av arbetsbelastningen. Om du till exempel planerar att implementera blå/gröna eller kanariebaserade uppdateringar bör den maximala storleken ta hänsyn till det utrymme som krävs för dina distributioner sida vid sida.

  Framtida ändringar kan kräva mer IP-utrymme, vilket kan justeras fel med den aktuella allokeringen. Integreringen av dessa utrymmen kan medföra extra komplexitet. Var proaktiv och begär tillräckligt med nätverksresurser i förväg för att säkerställa att det allokerade utrymmet kan hantera framtida expansion.

• Distributionsregionen: Det är viktigt att ange de regioner där arbetsbelastningen ska distribueras. Plattformsteamet kan använda den här informationen för att säkerställa att de virtuella eker- och navnätverken etableras i samma region. Nätverk i olika regioner kan leda till problem med svarstid på grund av trafik som passerar regionala gränser och kan också medföra extra bandbreddskostnader.

• Arbetsbelastningens egenskaper och designval: Förmedla dina designval, komponenter och egenskaper till ditt plattformsteam. Om du till exempel förväntar dig att din arbetsbelastning ska generera ett stort antal samtidiga anslutningar till Internet (chattigt) bör plattformsteamet se till att det finns tillräckligt med tillgängliga portar för att förhindra överbelastning. De kan lägga till IP-adresser i den centraliserade brandväggen för att stödja trafiken eller konfigurera en NAT-gateway (Network Address Translation) för att dirigera trafiken via en alternativ sökväg.

  Om du däremot förväntar dig att din arbetsbelastning ska generera minimal nätverkstrafik (bakgrundsbrus) bör plattformsteamet använda resurser effektivt i hela organisationen.

  Plattformsteamet måste tydligt förstå eventuella beroenden. Din arbetsbelastning kan till exempel behöva åtkomst till en databas som ett annat team äger, eller så kan din arbetsbelastning ha trafik mellan olika platser. Har din arbetsbelastning beroenden utanför Azure? Sådan information är viktig för plattformsteamet att känna till.

• Brandväggskonfigurationen: Plattformsteamet måste vara medvetna om trafik som lämnar ekernätverket och som skickas ut till hubbnätverket. Brandväggen i hubben kan inte blockera den trafiken.

  Om din arbetsbelastning till exempel behöver komma åt Windows-uppdateringar för att förbli korrigerad bör en brandvägg inte blockera dessa uppdateringar. Om det finns övervakaragenter som har åtkomst till specifika slutpunkter bör en brandvägg inte blockera trafiken eftersom den kan störa övervakningsdata för din arbetsbelastning. Programmet kan kräva åtkomst till slutpunkter från tredje part. Oavsett, använd en centraliserad brandvägg för att skilja mellan förväntad och obefogad trafik.

• Operatörsåtkomst: Om det finns Microsoft Entra ID-säkerhetsgrupper som operatörer använder för att få åtkomst till de virtuella datorerna via Azure Bastion informerar du plattformsteamet. Azure Bastion är vanligtvis en central resurs. Det är viktigt att se till att säkerhetsgrupperna och de virtuella datorerna stöder det säkra protokollet.

  Informera dessutom plattformsteamet om DE IP-intervall som innehåller de virtuella datorerna. Den här informationen är nödvändig för att konfigurera NSG:er runt Azure Bastion i hubbnätverket.

• Offentliga IP-adresser: Informera plattformsteamet om inkommande trafikprofil, inklusive eventuella förväntade offentliga IP-adresser. I den här arkitekturen är det bara internetbaserad trafik som riktar sig mot den offentliga IP-adressen på Application Gateway. Plattformsteamet bör informera arbetsbelastningsteamet om dessa IP-adresser omfattas av en Azure DDoS Protection-plan eller om det är arbetsbelastningsteamets ansvar.

  I den här arkitekturen finns det en annan offentlig IP-adress för driftåtkomst via Azure Bastion. Plattformsteamet äger den här offentliga IP-adressen och registreras i en tjänst, till exempel DDoS Protection, som även plattformsteamet hanterar.

Designval för virtuella datorer

De virtuella dator-SKU:erna och diskvalen förblir desamma som baslinjearkitekturen.

En organisation kan införa efterlevnadskrav för arbetsbelastningsteamet som kräver användning av specifika VM-avbildningar. Med tanke på sådana krav kan plattformsteamet hantera en uppsättning standardiserade bilder, som ofta kallas gyllene bilder, som skapas för användning i hela organisationen.

Plattformsteamet kan använda ett hanterat erbjudande som Azure Compute Gallery eller en privat lagringsplats för att lagra godkända OS-avbildningar eller arbetsbelastningsartefakter. När du väljer en OS-avbildning för virtuella datorer kan du kontakta ditt plattformsteam om bildkällor, uppdateringsfrekvens och användningsförväntningar. Se också till att avbildningarna kan uppfylla de affärskrav som arbetsbelastningen uppfyller.

Nätverk

I baslinjearkitekturen etableras arbetsbelastningen i ett enda virtuellt nätverk. Arbetsbelastningsteamet hanterar det virtuella nätverket.

I den här arkitekturen bestämmer plattformsteamet nätverkstopologin. Topologin hub-spoke antas i den här arkitekturen.

Ladda ned en Visio-fil med den här arkitekturen.

• Virtuellt navnätverk: En regional hubb innehåller centraliserade tjänster som kommunicerar med arbetsbelastningsresurser i samma region. Mer information finns i Plattformsteamägda resurser. Vi rekommenderar att du placerar hubben i anslutningsprenumerationen.

• Virtuellt ekernätverk: I den här arkitekturen är det enda virtuella nätverket från baslinjearkitekturen ekernätverket. Den är peer-kopplad till hubbnätverket, som innehåller de centraliserade tjänsterna. Plattformsteamet äger och hanterar det här ekernätverket. Det här nätverket innehåller arbetsbelastningsresurserna. Arbetsbelastningsteamet äger resurserna i det här nätverket, inklusive dess undernät.

Se till att du förmedlar arbetsbelastningskraven till plattformsteamet och granska dem regelbundet.

Undernät för virtuellt nätverk

I det virtuella ekernätverket skapar och allokerar arbetsbelastningsteamet undernäten. Att placera kontroller för att begränsa trafik in och ut ur undernäten hjälper till att tillhandahålla segmentering. Den här arkitekturen använder samma undernätstopologi som baslinjearkitekturen, som har dedikerade undernät för Application Gateway, virtuella datorer på klientsidan, lastbalanseraren, virtuella serverdelsdatorer och privata slutpunkter.

När du distribuerar din arbetsbelastning i en Azure-landningszon måste du fortfarande implementera nätverkskontroller. Organisationer kan införa begränsningar för att skydda mot dataexfiltrering och säkerställa synlighet för SOC (Central Security Operations Center) och IT-nätverksteamet.

Med den här metoden kan plattformsteamet optimera organisationens totala utgifter med hjälp av centraliserade tjänster i stället för att distribuera redundanta säkerhetskontroller för varje arbetsbelastning i hela organisationen. I den här arkitekturen är Azure Firewall ett exempel på en central tjänst. Det är inte kostnadseffektivt eller praktiskt för varje arbetsbelastningsteam att hantera sin egen brandväggsinstans. Vi rekommenderar en centraliserad metod för brandväggshantering.

Inkommande trafik

Inkommande trafikflöde förblir detsamma som baslinjearkitekturen.

Arbetsbelastningsägaren ansvarar för alla resurser som är relaterade till offentlig internetanslutning i din arbetsbelastning. I den här arkitekturen placeras till exempel Application Gateway och dess offentliga IP-adress i ekernätverket och inte i hubbnätverket. Vissa organisationer kan placera resurser med inkommande trafik i en anslutningsprenumeration med hjälp av en centraliserad demilitariserad (DMZ) implementering. Integrering med den specifika topologin ligger utanför omfånget för den här artikeln.

Utgående trafik

I baslinjearkitekturen har vm-skalningsuppsättningar för arbetsbelastning åtkomst till det offentliga Internet via Azure Load Balancer, men trafiken är inte begränsad.

Den designen är annorlunda i den här arkitekturen. All trafik som lämnar det virtuella ekernätverket dirigeras via peer-kopplat hubbnätverk via en utgående brandvägg. En väg är kopplad till alla möjliga undernät i ekernätverket som dirigerar all trafik för IP-adresser som inte hittas i det lokala virtuella nätverket (0.0.0.0/0) till hubbens Azure Firewall.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsbelastningskommunikation till den privata slutpunkten för Key Vault-åtkomst förblir densamma som baslinjearkitekturen. Den sökvägen utelämnas från föregående diagram för korthet.

Arbetsbelastningsteamet måste identifiera, dokumentera och kommunicera alla nödvändiga utgående trafikflöden för infrastruktur- och arbetsbelastningsåtgärderna. Plattformsteamet tillåter den trafik som krävs och all okommunicerad utgående trafik nekas sannolikt.

Att kontrollera utgående trafik är mer än att bara se till att den förväntade trafiken tillåts. Det handlar också om att se till att endast förväntad trafik tillåts. Okommunikerad utgående trafik nekas sannolikt som standard, men det ligger i arbetsbelastningens bästa säkerhetsintresse att se till att trafiken dirigeras korrekt.

Kommunicera eventuella unika krav på utgående trafik till plattformsteamet. Om din arbetsbelastning till exempel upprättar flera samtidiga anslutningar till externa nätverksslutpunkter informerar du plattformsteamet. Sedan kan plattformsteamet antingen etablera en lämplig Azure NAT Gateway-implementering eller lägga till fler offentliga IP-adresser i den regionala brandväggen för att åtgärda problemet.

Din organisation kan ha krav som avråder från att använda arkitekturmönster, som använder arbetsbelastningsägda offentliga IP-adresser för utgående trafik. I så fall kan du använda Azure Policy för att neka offentliga IP-adresser på nätverkskort för virtuella datorer och andra offentliga IP-adresser, förutom dina välkända ingresspunkter.

Privata DNS-zoner

Arkitekturer som använder privata slutpunkter behöver privata DNS-zoner för att fungera med DNS-providern. Arbetsbelastningsteamet måste ha en tydlig förståelse för kraven och hanteringen av privata DNS-zoner i prenumerationen som plattformsteamet tillhandahåller. Privat DNS zoner hanteras vanligtvis i stor skala med DINE-principer, vilket gör att Azure Firewall kan fungera som en tillförlitlig DNS-proxy och stödja fullständigt kvalificerade domännamnsnätverksregler (FQDN).

I den här arkitekturen säkerställer plattformsteamet tillförlitlig privat DNS-matchning för privata länkslutpunkter. Samarbeta med ditt plattformsteam för att förstå deras förväntningar.

Anslut ivitetstestning

För VM-baserade arkitekturer finns det flera testverktyg som kan hjälpa dig att fastställa problem med nätverkssyn, routning och DNS. Du kan använda traditionella felsökningsverktyg, till exempel netstat, nslookupeller tcping. Dessutom kan du undersöka nätverkskortets DHCP-inställningar (Dynamic Host Configuration Protocol) och DNS. Om det finns nätverkskort har du fler felsökningsfunktioner som gör att du kan utföra anslutningskontroller med hjälp av Azure Network Watcher.

Operatoråtkomst

Precis som baslinjearkitekturen stöds driftåtkomst via Azure Bastion i den här arkitekturen.

Baslinjearkitekturen distribuerar dock Azure Bastion som en del av arbetsbelastningen. För en typisk organisation som använder Azure-landningszoner distribuerar de Azure Bastion som centrala resurser för varje region. Plattformsteamet äger och underhåller Azure Bastion, och alla arbetsbelastningar i organisationen delar den. För att visa det användningsfallet i den här arkitekturen finns Azure Bastion i hubbnätverket i anslutningsprenumerationen.

Operatoridentitet

Den här arkitekturen använder samma autentiseringstillägg som baslinjearkitekturen.

Börja alltid med principen om lägsta behörighet och detaljerad åtkomst till en uppgift i stället för långvarig åtkomst. I kontexten för landningszonen kan du dra nytta av jit-stöd (just-in-time) som plattformsteamet hanterar.

Korrigeringsefterlevnad och OS-uppgraderingar

Baslinjearkitekturen beskriver en autonom metod för korrigering och uppgraderingar. När arbetsbelastningen är integrerad med landningszoner kan den metoden ändras. Plattformsteamet kan diktera korrigeringsåtgärderna så att alla arbetsbelastningar är kompatibla med organisationens krav.

Kontrollera att korrigeringsprocessen innehåller alla komponenter som du lägger till i arkitekturen. Om du till exempel väljer att lägga till virtuella build agent-datorer för att automatisera distribution, skalning och hantering av program måste de virtuella datorerna uppfylla plattformskraven.

Övervakning

Azure-landningszonens plattform tillhandahåller delade observerbarhetsresurser som en del av hanteringsprenumerationen. Vi rekommenderar dock att du etablerar dina egna övervakningsresurser för att underlätta ägarskapet för arbetsbelastningen. Den här metoden är konsekvent med baslinjearkitekturen.

Arbetsbelastningsteamet etablerar övervakningsresurserna, bland annat:

• Application Insights som tjänst för programprestandaövervakning (APM) för arbetsbelastningsteamet.

• Log Analytics-arbetsytan som enhetlig mottagare för alla loggar och mått som samlas in från arbetsbelastningsägda Azure-resurser och programkoden.

Ladda ned en Visio-fil med den här arkitekturen.

På samma sätt som baslinjen är alla resurser konfigurerade för att skicka Azure Diagnostics-loggar till Log Analytics-arbetsytan som arbetsbelastningsteamet etablerar som en del av IaC-distributionen (infrastruktur som kod) för resurserna. Du kan också behöva skicka loggar till en central Log Analytics-arbetsyta. I Azure-landningszoner finns den arbetsytan i hanteringsprenumerationen.

Plattformsteamet kan också ha DINE-principer som de kan använda för att konfigurera diagnostik för att skicka loggar till deras centraliserade hanteringsprenumerationer. Det är viktigt att se till att implementeringen inte begränsar de ytterligare loggflödena.

Korrelera data från flera mottagare

Arbetsbelastningens loggar och mått och dess infrastrukturkomponenter lagras på arbetsbelastningens Log Analytics-arbetsyta. Loggar och mått som centraliserade tjänster, till exempel Azure Firewall, Microsoft Entra ID och Azure Bastion, genererar lagras dock på en central Log Analytics-arbetsyta. Att korrelera data från flera mottagare kan vara en komplex uppgift.

Korrelerade data används ofta under incidenthantering. Om det uppstår problem med att korrelera data från flera mottagare kontrollerar du att triage-runbooken för den här arkitekturen åtgärdar den och inkluderar organisationskontaktpunkter om problemet sträcker sig utanför arbetsbelastningsresurserna. Arbetsbelastningsadministratörer kan behöva hjälp från plattformsadministratörer för att korrelera loggposter från företagsnätverk, säkerhet eller andra plattformstjänster.

Azure Policy

Plattformsteamet tillämpar sannolikt principer som påverkar arbetsbelastningsdistributionen. De tillämpar ofta DINE-principer för att hantera automatiserade distributioner i en prenumeration på en programlandningszon. DINE-principer kan ändra arbetsbelastningsresurser eller lägga till resurser i distributionen, vilket kan leda till en avvikelse mellan de resurser som deklarativt distribueras via arbetsbelastningsmallen och de resurser som bearbetningsbegäranden faktiskt använder. En vanlig lösning är att åtgärda dessa ändringar med imperativa metoder, som inte är idealiska.

Undvik den avvikelsen genom att i förebyggande syfte införliva och testa de plattformsinitierade ändringarna i dina IaC-mallar. Om plattformsteamet använder Azure-principer som står i konflikt med programmets krav kan du förhandla fram en lösning med plattformsteamet.

Hantera ändringar över tid

Tjänster och åtgärder som tillhandahålls av plattformen betraktas som externa beroenden i den här arkitekturen. Plattformsteamet fortsätter att tillämpa ändringar, registrera användare och tillämpa kostnadskontroller. Plattformsteamet som betjänar organisationen kanske inte prioriterar enskilda arbetsbelastningar. Ändringar i dessa beroenden, oavsett om de är gyllene bildändringar, brandväggsändringar, automatisk korrigering eller regeländringar, kan påverka flera arbetsbelastningar.

Därför måste arbetsbelastnings- och plattformsteam kommunicera effektivt och i tid för att hantera alla externa beroenden. Det är viktigt att testa ändringar, så att de inte påverkar arbetsbelastningar negativt.

Plattformsändringar som påverkar arbetsbelastningen

I den här arkitekturen hanterar plattformsteamet följande resurser. Ändringar av dessa resurser kan potentiellt påverka arbetsbelastningens tillförlitlighet, säkerhet, åtgärder och prestandamål. Det är viktigt att utvärdera dessa ändringar innan plattformsteamet börjar tillämpa dem för att avgöra hur de påverkar arbetsbelastningen.

• Azure-principer: Ändringar i Azure-principer kan påverka arbetsbelastningsresurser och deras beroenden. Det kan till exempel finnas direkta principändringar eller förflyttning av landningszonen till en ny hanteringsgruppshierarki. Dessa ändringar kan gå obemärkt förbi tills det finns en ny distribution, så det är viktigt att noggrant testa dem.

• Brandväggsregler: Ändringar av brandväggsregler kan påverka arbetsbelastningens virtuella nätverk eller regler som tillämpas brett över all trafik. Dessa ändringar kan resultera i blockerad trafik och till och med fel i tyst process, till exempel misslyckad tillämpning av OS-korrigeringar. Dessa potentiella problem gäller både utgående Azure-brandväggen och Azure Virtual Network Manager-tillämpade NSG-regler.

• Delade resurser: Ändringar i SKU eller funktioner på delade resurser kan påverka arbetsbelastningen.

• Routning i hubbnätverket: Ändringar i den transitiva typen av routning i hubben kan potentiellt påverka arbetsbelastningsfunktionerna om en arbetsbelastning är beroende av routning till andra virtuella nätverk.

• Azure Bastion-värd: Ändringar i tillgängligheten eller konfigurationen för Azure Bastion-värden kan påverka arbetsbelastningsåtgärderna. Se till att ändringar i jump box-åtkomstmönstret har effektiv rutin, ad hoc- och nödåtkomst.

• Ägarskapsändringar: Meddela eventuella ändringar i ägarskapet och kontaktpunkterna till arbetsbelastningsteamet eftersom de kan påverka hanterings- och supportbegäranden för arbetsbelastningen.

Arbetsbelastningsändringar som påverkar plattformen

Följande exempel är arbetsbelastningsändringar i den här arkitekturen som du bör kommunicera med plattformsteamet. Det är viktigt att plattformsteamet validerar plattformstjänstens tillförlitlighets-, säkerhets-, drifts- och prestandamål mot de nya arbetsbelastningsteamets ändringar innan de träder i kraft.

• Utgående nätverk: Övervaka en betydande ökning av nätverksutgången för att förhindra att arbetsbelastningen blir en bullrig granne på nätverksenheter. Det här problemet kan potentiellt påverka prestanda- eller tillförlitlighetsmålen för andra arbetsbelastningar.

• Offentlig åtkomst: Ändringar i den offentliga åtkomsten till arbetsbelastningskomponenter kan kräva ytterligare testning. Plattformsteamet kan flytta arbetsbelastningen till en annan hanteringsgrupp.

• Klassificering av affärskritiskhet: Om arbetsbelastningens serviceavtal ändras kan du behöva en ny samarbetsmetod mellan plattforms- och arbetsbelastningsteamen.

• Ägarskapsändringar: Kommunicera ändringar i ägarskap och kontaktpunkter till plattformsteamet.

Ändringar i arbetsbelastningens affärskrav

För att upprätthålla servicenivåmål (SLO) för arbetsbelastningen kan plattformsteamet behöva delta i ändringar i arbetsbelastningsarkitekturen. Dessa ändringar kan kräva ändringshantering från plattformsteamet eller validering av att befintlig styrning stöder de ändrade kraven.

Du kan till exempel kommunicera ändringar i ett tidigare otillåtet utgående flöde så att plattformsteamet kan lägga till flödet i brandväggen, Virtual Network Manager eller andra komponenter för att stödja den trafik som krävs. Om ett tidigare tillåtet utgående flöde inte längre behövs bör plattformsteamet blockera flödet för att upprätthålla arbetsbelastningens säkerhet. Kommunicera även ändringar i routning till andra virtuella nätverk eller lokala slutpunkter eller ändringar i arkitekturkomponenterna. Varje resurs omfattas av principer och potentiellt utgående brandväggskontroll.

Tillförlitlighet

Den här arkitekturen överensstämmer med tillförlitlighetsgarantierna i baslinjearkitekturen.

Tillförlitlighetsmål

Den maximala möjliga sammansatta SLO:n är lägre än baslinjens sammansatta SLO på grund av komponenter som utgående nätverkskontroll. Dessa komponenter, som är vanliga i landningszonmiljöer, är inte unika för den här arkitekturen. SLO:et minskas på samma sätt om arbetsbelastningsteamet direkt styr dessa Azure-tjänster.

Trots ett lägre högsta möjliga SLO är den viktigaste tillförlitlighetsaspekten divisionen av arbetsbelastningskomponenter mellan funktionella team. Med den här metoden drar arbetsbelastningsteamet nytta av ett specialiserat team som fokuserar på att driva kritisk infrastruktur som den här arbetsbelastningen och andra arbetsbelastningar använder.

Mer information finns i Rekommendationer för att definiera tillförlitlighetsmål.

Kritiska beroenden

Visa alla funktioner som arbetsbelastningen utför i plattforms- och programlandningszonen som beroenden. Incidenthanteringsplaner kräver att arbetsbelastningsteamet känner till punkt- och metod för kontaktinformation för dessa beroenden. Inkludera även dessa beroenden i arbetsbelastningens analys av felläge (FMA).

För den här arkitekturen bör du tänka på följande beroenden:

• Utgående brandvägg: Den centraliserade utgående brandväggen, som delas av flera arbetsbelastningar, genomgår ändringar som inte är relaterade till arbetsbelastningen.

• Nätverksportsöverbelastning: Toppar i användningen från alla arbetsbelastningar som delar nätverksenheten kan leda till nätverksmättnad eller portöverbelastning i utgående brandvägg.

• DINE-principer: DINE-principer för privata DNS-zoner i Azure DNS (eller andra beroenden som tillhandahålls av plattformen) är bäst, utan serviceavtal vid körning. En fördröjning i DNS-konfigurationen kan orsaka fördröjningar i beredskapen för ett program för att hantera trafik.

• Hanteringsgruppsprinciper: Konsekventa principer mellan miljöer är viktiga för tillförlitlighet. Se till att förproduktionsmiljöer liknar produktionsmiljöer för att tillhandahålla korrekt testning och för att förhindra miljöspecifika avvikelser som kan blockera en distribution eller skala. Mer information finns i Hantera programutvecklingsmiljöer i Azure-landningszoner.

Många av dessa överväganden kan finnas utan Azure-landningszoner, men arbetsbelastnings- och plattformsteamen måste samarbeta för att lösa dessa problem för att säkerställa att behoven uppfylls.

Mer information finns i Rekommendationer för analys av felläge.

Säkerhet

Säkerhetsövervägandena för den här arkitekturen överförs från baslinjearkitekturen. Rekommendationerna i följande avsnitt baseras på checklistan för granskning av säkerhetsdesign i well-architected Framework.

Nätverkskontroller

Konfigurera nätverkskontroller korrekt för att säkerställa att arbetsbelastningen är säker.

Inkommande trafik

Du kan isolera din arbetsbelastning från andra arbetsbelastningsekrar i din organisation via NSG:er i dina undernät eller den icke-transitiva karaktären eller kontrollerna i den regionala hubben. Skapa omfattande NSG:er som endast tillåter kraven på inkommande nätverk för ditt program och dess infrastruktur. Vi rekommenderar att du inte enbart förlitar dig på hubbnätverkets icke-överföringskaraktär för säkerhet.

Plattformsteamet implementerar sannolikt Azure-principer för att säkerställa att Application Gateway har brandväggen för webbprogram inställd på neka-läge, för att begränsa antalet offentliga IP-adresser som är tillgängliga för din prenumeration och andra kontroller. Utöver dessa principer bör arbetsbelastningsteamet ansvara för att distribuera arbetsbelastningscentrerade principer som förstärker ingresssäkerhetsstatusen.

I följande tabell visas exempel på ingresskontroller i den här arkitekturen.

Source	Purpose	Arbetsbelastningskontroll	Plattformskontroll
Internet	Användartrafikflöden	Trattar alla begäranden via en NSG, brandvägg för webbprogram och routningsregler innan offentlig trafik tillåts övergå till privat trafik som kommer in i de virtuella datorerna på klientsidan	Ingen
Azure Bastion	Operatoråtkomst till virtuella datorer	NSG på virtuella datorundernät som blockerar all trafik till fjärråtkomstportar, såvida den inte kommer från plattformens avsedda Azure Bastion-undernät	Ingen
Andra ekrar	Ingen	Blockerad via NSG-regler	Icke-överföringsroutning eller Azure Firewall-regler när det gäller en Azure Virtual WAN-skyddad hubb

Utgående trafik

Tillämpa NSG-regler som uttrycker de krav på utgående anslutning som krävs för din lösning och nekar allt annat. Förlita dig inte bara på hubbnätverkskontrollerna. Som arbetsbelastningsoperator har du ansvaret att stoppa oönstrade utgående trafik så nära källan som möjligt.

Tänk på att även om du äger din underindelning i det virtuella nätverket skapade plattformsteamet förmodligen brandväggsregler för att specifikt representera dina insamlade krav som en del av din prenumerationsförsäljning process. Se till att ändringar i undernät och resursplacering under arkitekturens livslängd fortfarande är kompatibla med din ursprungliga begäran. Eller så kan du arbeta med ditt nätverksteam för att säkerställa kontinuitet för utgående kontroll med minst åtkomst.

I följande tabell visas exempel på utgående i den här arkitekturen.

Slutpunkt	Syfte	Arbetsbelastningskontroll (NSG)	Plattformskontroll (hubb)
ntp.ubuntu.com	Network Time Protocol (NTP) för virtuella Linux-datorer	UDP/123 till Internet i undernätet för den virtuella datorn på klientsidan (utgående brandvägg begränsar den här breda öppningen)	Regeltilldelning för brandväggsnätverk för samma som arbetsbelastningskontrollen
Windows Update-slutpunkter	Windows Update-funktioner från Microsoft-servrar	TCP/443 och TCP/80 till Internet på serverdels-VM-undernätet (utgående brandvägg begränsar den här breda öppningen)	Brandväggsregel med FQDN-tagg för WindowsUpdate
Övervaka agentslutpunkter	Nödvändig trafik för monitortillägget på virtuella datorer	TCP/443 till Internet på båda de virtuella datorundernäten (den utgående brandväggen begränsar den här breda öppningen)	Nödvändiga brandväggsapplikationsregler för alla specifika FQDN:er på TCP/443
nginx.org	Så här installerar du Nginx (ett exempel på en programkomponent) direkt från leverantören	TCP/443 till Internet på undernätet för den virtuella datorn på klientsidan (den utgående brandväggen begränsar den här breda öppningen)	Nödvändig regeltilldelning för brandväggsprogram för nginx.org på TCP/443
Key Vault	Importera TLS-certifikat (Transport Layer Security) i Application Gateway och virtuella datorer	- TCP/443 till ett privat slutpunktsundernät från båda undernäten för virtuella datorer till ett privat undernät för slutpunkter - TCP/443 till ett privat slutpunktsundernät från ett Application Gateway-undernät - TCP/443 från virtuella datorer taggade med en obligatorisk asg-beteckning (application security group) och Application Gateway-undernät	Ingen

DDoS Protection

Ta reda på vem som ansvarar för att tillämpa DDoS Protection-planen som täcker alla dina lösningars offentliga IP-adresser. Plattformsteamet kan använda IP-skyddsplaner eller kanske till och med använda Azure Policy för att tillämpa planer för skydd av virtuella nätverk. Den här arkitekturen bör ha täckning eftersom den omfattar en offentlig IP-adress för ingress från Internet.

Mer information finns i Rekommendationer för nätverk och anslutning.

Hemlighetshantering

För hemlig hantering följer den här arkitekturen baslinjearkitekturen.

Som arbetsbelastningsteam fortsätter du att behålla dina hemligheter i din Key Vault-instans. Distribuera fler instanser efter behov för att stödja dina program- och infrastrukturåtgärder.

Mer information finns i Rekommendationer för att skydda programhemligheter.

Kostnadsoptimering

För arbetsbelastningsresurserna gäller även strategierna för kostnadsoptimering i baslinjearkitekturen för den här arkitekturen.

Den här arkitekturen drar stor nytta av Plattformsresurser för Azure-landningszoner. Även om du använder dessa resurser via en återbetalningsmodell är den extra säkerheten och anslutningen mellan platser mer kostnadseffektiv än självhantering av dessa resurser.

Plattformsteamet hanterar följande resurser i den här arkitekturen. Dessa resurser är ofta förbrukningsbaserade (återbetalning) eller potentiellt kostnadsfria för arbetsbelastningsteamet.

• Azure Firewall
• Säkerhetsinformations- och händelsehantering (SIEM)
• Azure Bastion-värdar
• Anslutning mellan platser, till exempel ExpressRoute

Dra nytta av andra centraliserade erbjudanden från ditt plattformsteam för att utöka dessa fördelar till din arbetsbelastning utan att äventyra dess mål för SLO, återställningstid (RTO) eller mål för återställningspunkt (RPO).

Mer information finns i Rekommendationer för att samla in och granska kostnadsdata.

Distribuera det här scenariot

En distribution för denna referensarkitektur finns på GitHub.

Gå vidare

Granska samarbetet och den tekniska information som delas mellan ett arbetsbelastningsteam och plattformsteam.

Prenumerationsautomater