Företagsdistribution med Hjälp av Azure App Service-miljön

Den här referensarkitekturen visar en vanlig företagsarbetsbelastning som använder App Service-miljön version 3. Den beskriver också metodtips för att stärka säkerheten för arbetsbelastningen.

En referensimplementering för den här arkitekturen finns på GitHub.

Arkitektur

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

Arbetsflöde

Du kan distribuera App Service-miljön på två sätt:

• Som en extern App Service-miljön med en offentlig IP-adress
• Som en intern App Service-miljön med en intern IP-adress som tillhör den interna lastbalanseraren (ILB)

Den här referensarkitekturen distribuerar ett företagswebbprogram i en intern App Service-miljön, även kallat en ILB-App Service-miljön. Använd en ILB-App Service-miljön när ditt scenario kräver att du:

• Värdhantera intranätprogram med förbättrad säkerhet i molnet och få åtkomst till dem via ett plats-till-plats-VPN eller Azure ExpressRoute.
• Ange ett skyddslager för appar med hjälp av en brandvägg för webbprogram (WAF).
• Vara värd för appar i molnet som inte listas i offentliga DNS-servrar.
• Skapa internetisolerade serverdelsappar som dina klientdelsappar kan integreras med på ett mycket säkert sätt.

App Service-miljön måste alltid distribueras i ett eget undernät i det virtuella företagsnätverket för att tillåta noggrann kontroll över inkommande och utgående trafik. I det här undernätet distribueras App Service-program i en eller flera App Service-planer, vilket är en samling fysiska resurser som krävs för att köra appen. Beroende på komplexiteten och resurskravet kan en App Service-plan delas mellan flera appar. Den här referensimplementeringen distribuerar en webbapp med namnet Voting App, som interagerar med ett privat webb-API och en funktion. Den distribuerar också en dummywebbapp med namnet Test App för att demonstrera distributioner med flera appar. Varje App Service-app finns i en egen App Service-plan, så att var och en kan skalas separat om det behövs. Alla resurser som krävs av dessa värdbaserade appar, till exempel lagring och beräkning, samt skalningsbehov hanteras helt av den App Service-miljön infrastrukturen.

Med den enkla röstningsappen i den här implementeringen kan användarna visa befintliga poster, skapa nya poster och rösta på befintliga poster. Webb-API:et används för att skapa och hämta poster och röster. Själva data lagras i en SQL Server-databas. För att demonstrera asynkrona datauppdateringar köar webbappen nyligen tillagda röster i en Service Bus-instans. Funktionen hämtar röster i kö och uppdaterar SQL-databasen. Azure Cosmos DB används för att lagra en modellannons som webbappen hämtar för visning i webbläsaren. Programmet använder Azure Cache for Redis för cachehantering. En Azure Cache for Redis på Premium-nivå används, vilket gör det möjligt att konfigurera till samma virtuella nätverk som App Service-miljön i sitt eget undernät. Detta ger förbättrad säkerhet och isolering i cacheminnet.

Webbapparna är de enda komponenter som är tillgängliga för Internet via Application Gateway. API:et och funktionen är inte tillgängliga från en Internetklient. Inkommande trafik skyddas av en WAF som har konfigurerats på Application Gateway.

Komponenter

Följande tjänster är nyckeln till att låsa App Service-miljön i den här arkitekturen:

• Azure Virtual Network är ett privat Azure-molnnätverk som ägs av ett företag. Det ger förbättrad nätverksbaserad säkerhet och isolering. App Service-miljön är en App Service-distribution till ett undernät i det företagsägda virtuella nätverket. Det gör det möjligt för företaget att noggrant kontrollera det nätverksutrymmet och de resurser som det kommer åt med hjälp av nätverkssäkerhetsgrupper och privata slutpunkter.

• Application Gateway är en webbtrafiklastbalanserare på programnivå med TLS/SSL-avlastning och WAF. Den lyssnar på en offentlig IP-adress och dirigerar trafik till programslutpunkten i ILB-App Service-miljön. Eftersom det här är routning på programnivå kan den dirigera trafik till flera appar inom samma ILB-App Service-miljön. Mer information finns i Application Gateway för flera webbplatser.

• Azure Firewall används för att begränsa utgående trafik från webbprogrammet. Utgående trafik som inte går via de privata slutpunktskanalerna och en routningstabell som krävs av App Service-miljön dirigeras till brandväggsundernätet. För enkelhetens skull konfigurerar den här arkitekturen alla privata slutpunkter i tjänstundernätet.

• Microsoft Entra-ID eller Microsoft Entra-ID ger åtkomsträttigheter och behörighetshantering till Azure-resurser och -tjänster. Hanterade identiteter tilldelar identiteter till tjänster och appar, som hanteras automatiskt av Microsoft Entra-ID. Dessa identiteter kan användas för att autentisera till alla tjänster som stöder Microsoft Entra-autentisering. Detta tar bort behovet av att uttryckligen konfigurera autentiseringsuppgifter för dessa appar. Den här arkitekturen tilldelar en hanterad identitet till webbappen.

• Azure Key Vault lagrar alla hemligheter och autentiseringsuppgifter som krävs av apparna. Använd det här alternativet för att lagra hemligheter direkt i programmet.

• GitHub Actions tillhandahåller funktioner för kontinuerlig integrering och kontinuerlig distribution i den här arkitekturen. Eftersom App Service-miljön finns i det virtuella nätverket används en virtuell dator som en jumpbox i det virtuella nätverket för att distribuera appar i App Service-planerna. Åtgärden skapar apparna utanför det virtuella nätverket. För förbättrad säkerhet och smidig RDP/SSH-anslutning kan du överväga att använda Azure Bastion för jumpboxen.

Konfiguration av flera platser

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

Interna App Service-miljön kan vara värd för flera webbappar och API:er med HTTP-slutpunkter. Dessa program är låsta från det offentliga Internet eftersom IP-adressen för ILB endast är tillgänglig från det virtuella nätverket. Application Gateway används för att selektivt exponera dessa program för Internet. App Service-miljön tilldelar en standard-URL till varje App Service-program som <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. En privat DNS-zon skapas som mappar App Service-miljön domännamnet till ip-adressen för App Service-miljön ILB. Detta undviker att använda en anpassad DNS för att komma åt apparna i det virtuella nätverket.

Application Gateway är konfigurerat så att en lyssnare lyssnar på HTTPS-porten efter begäranden till gatewayens IP-adress. För enkelhetens skull använder den här implementeringen inte någon offentlig DNS-namnregistrering. Det kräver att du ändrar localhost-filen på datorn så att den pekar en godtyckligt vald URL till Application Gateway-IP-adressen. För enkelhetens skull använder lyssnaren ett självsignerat certifikat för att bearbeta dessa begäranden. Application Gateway har serverdelspooler för varje App Service-programs standard-URL. En routningsregel har konfigurerats för att ansluta lyssnaren till serverdelspoolen. HTTP-inställningar skapas som avgör om anslutningen mellan gatewayen och App Service-miljön ska krypteras. De här inställningarna används också för att åsidosätta det inkommande HTTP-värdhuvudet med ett värdnamn som valts från serverdelspoolen. Den här implementeringen använder standardcertifikat som skapats för standard-App Service-miljön app-URL:er som är betrodda av gatewayen. Begäran omdirigeras till standard-URL:en för motsvarande app. Den privata DNS som är länkad till det virtuella nätverket vidarebefordrar denna begäran till ILB-IP-adressen. App Service-miljön vidarebefordrar sedan detta till den begärda apptjänsten. All HTTP-kommunikation inom App Service-miljön-appar går via den privata DNS:en. Observera att lyssnaren, serverdelspoolen, routningsregeln och HTTP-inställningarna måste konfigureras på programgatewayen för varje App Service-miljön app.

Granska appgw.bicep och dns.bicep för att lära dig hur dessa konfigurationer görs för att tillåta flera platser. Webbappen med namnet testapp är en tom app som skapats för att demonstrera den här konfigurationen. Dessa JSON-filer nås från distributionsskriptet commands_std.azcli. Dessa nås också av commands_ha.azcli, som används för en distribution med flera platser med hög tillgänglighet App Service-miljön.

Information om scenario

Azure App Service är en PaaS-tjänst som används för att vara värd för en mängd olika appar i Azure: webbappar, API-appar, funktioner och mobilappar. App Service-miljön gör det möjligt för företag att distribuera sina App Service-appar i ett undernät i sitt eget virtuella Azure-nätverk, vilket ger en isolerad, mycket skalbar och dedikerad miljö för sina molnarbetsbelastningar.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

App Service Environment

En intern App Service-miljön distribueras i företagets virtuella nätverk, dolt från det offentliga Internet. Det gör att företaget kan låsa sina serverdelstjänster, till exempel webb-API:er och funktioner, på nätverksnivå. Alla App Service-miljön appar med en HTTP-slutpunkt kan nås via ILB, inifrån det virtuella nätverket. Application Gateway har konfigurerats för att vidarebefordra begäranden till webbappen via ILB. Själva webbappen går via ILB för att komma åt API:et. De kritiska serverdelskomponenterna, dvs. API:et och funktionen, är i praktiken otillgängliga från det offentliga Internet.

Standardcertifikat skapas för varje apptjänst för det standarddomännamn som tilldelats av App Service-miljön. Det här certifikatet kan öka säkerheten för trafiken mellan gatewayen och appen och kan krävas i vissa scenarier. Dessa certifikat visas inte via klientwebbläsaren. Den kan bara svara på de certifikat som konfigurerats på Application Gateway.

Application Gateway

Som beskrivs i Översikt över TLS-avslutning och TLS från slutpunkt till slutpunkt med Application Gateway kan Application Gateway använda Transport Layer Security (TLS)/Secure Sockets Layer (SSL) för att kryptera och skydda all trafik från webbläsare. Kryptering kan konfigureras på följande sätt:

• Krypteringen avslutades vid gatewayen. Serverdelspoolerna i det här fallet är konfigurerade för HTTP. Krypteringen stoppas vid gatewayen och trafiken mellan gatewayen och apptjänsten är okrypterad. Eftersom kryptering är CPU-intensiv, förbättrar okrypterad trafik på serverdelen prestanda och möjliggör enklare certifikathantering. Detta ger en rimlig säkerhetsnivå eftersom serverdelen skyddas med hjälp av nätverkskonfigurationen.

• Kryptering från slutpunkt till slutpunkt. I vissa scenarier, till exempel specifika säkerhetskrav eller efterlevnadskrav, kan trafiken behöva krypteras mellan gatewayen och appen. Detta uppnås genom att använda HTTPS-anslutning och konfigurera certifikat i serverdelspoolen.

Den här referensimplementeringen använder självsignerade certifikat för Application Gateway. För produktionskod ska ett certifikat som utfärdats av en certifikatutfärdare användas. En lista över certifikattyper som stöds finns i Certifikat som stöds för TLS-avslutning. Läs Konfigurera en programgateway med TLS-avslutning med hjälp av Azure Portal för att lära dig hur du skapar gateway-avslutad kryptering. Följande kodrader i appgw.bicep konfigurerar detta programmatiskt:

httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
  frontendIPConfiguration: {
    id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
  }
  frontendPort: {
    id: '${appgwId}/frontendPorts/port_443'
  }
  protocol: 'Https'
  sslCertificate: {
    id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
  }
  hostName: item.hostName
  requireServerNameIndication: true
}
}]

Referensimplementeringen visar kryptering från slutpunkt till slutpunkt för trafik mellan Application Gateway och webbapparna på App Service-miljön. Standard-SSL-certifikat används. Serverdelspoolerna i den här implementeringen är konfigurerade för att omdirigera HTTPS-trafik med värdnamnet åsidosättat av de standarddomännamn som är associerade med webbapparna. Application Gateway litar på standard-SSL-certifikaten eftersom de har utfärdats av Microsoft. Se Konfigurera App Service med Application Gateway för information om hur dessa konfigurationer görs. Följande kod från appgw.bicep visar hur detta konfigureras i referensimplementeringen:

backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
  port: 443
  protocol: 'Https'
  cookieBasedAffinity: 'Disabled'
  pickHostNameFromBackendAddress: true
  requestTimeout: 20
  probe: {
    id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
  }
}
}]

Brandvägg för webbaserade program

Web Application Firewall (WAF) på Application Gateway skyddar webbapparna från skadliga attacker, till exempel SQL-inmatning. Den är också integrerad med Azure Monitor för att övervaka attacker med hjälp av en realtidslogg. WAF måste aktiveras på gatewayen enligt beskrivningen i Skapa en programgateway med en brandvägg för webbprogram med hjälp av Azure Portal. Referensimplementeringen aktiverar WAF programmatiskt i filen appgw.bicep med följande kodfragment:

webApplicationFirewallConfiguration: {
  enabled: true
  firewallMode: 'Detection'
  ruleSetType: 'OWASP'
  ruleSetVersion: '3.2'
}

Virtual Network

Nätverkssäkerhetsgrupper kan associeras med ett eller flera undernät i det virtuella nätverket. Det här är säkerhetsregler som tillåter eller nekar trafik att flöda mellan olika Azure-resurser. Den här arkitekturen associerar en separat nätverkssäkerhetsgrupp för varje undernät. Detta möjliggör finjustering av dessa regler per undernät, enligt de tjänster som finns i det undernätet. Se till exempel konfigurationen för "type": "Microsoft.Network/networkSecurityGroups" i filen ase.bicep för nätverkssäkerhetsgruppen för App Service-miljön-undernätet och i filen appgw.bicep för nätverkssäkerhetsgruppen för Application Gateway-undernätet.

Privata slutpunkter möjliggör förbättrad privat anslutning mellan klienter och Azure-tjänster via ett privat nätverk. De tillhandahåller en privat tillgänglig IP-adress för Azure-tjänsten, vilket möjliggör förbättrad säkerhetstrafik till en Azure Private Link-resurs. Plattformen validerar nätverksanslutningar så att endast de som ansluter till den angivna Private Link-resursen tillåts. Privata slutpunkter stöder nätverksprinciper som nätverkssäkerhetsgrupper, användardefinierade vägar och programsäkerhetsgrupper. För att förbättra säkerheten bör du aktivera privata slutpunkter för alla Azure-tjänster som stöder dem. Du kan sedan förbättra säkerheten för tjänsten i det virtuella nätverket genom att inaktivera offentlig åtkomst, vilket effektivt blockerar all åtkomst från det offentliga Internet. Den här arkitekturen konfigurerar privata slutpunkter för de tjänster som stöder den: Azure Service Bus, SQL Server, Key Vault och Azure Cosmos DB. Du kan se konfigurationen i privatendpoints.bicep.

Om du vill aktivera privata slutpunkter måste du också konfigurera privata DNS-zoner. Mer information finns i DNS-konfiguration för privat slutpunkt i Azure.

Brandvägg

Azure Firewall och privata slutpunkter kompletterar varandra. Privata slutpunkter hjälper till att skydda resurser genom att endast tillåta trafik som kommer från ditt virtuella nätverk. Med Azure Firewall kan du begränsa utgående trafik från dina program. Vi rekommenderar att du tillåter att all utgående trafik passerar genom brandväggens undernät, inklusive privat slutpunktstrafik. Detta möjliggör bättre övervakning av utgående trafik. För enkelhetens skull konfigurerar den här referensarkitekturen alla privata slutpunkter i tjänstundernätet i stället för i brandväggsundernätet.

Information om hur Azure Firewall integreras med App Service-miljön finns i Konfigurera Azure Firewall med din App Service-miljön. All trafik som inte passerar de privata slutpunkterna och routningstabellen för virtuella nätverk övervakas och gated av brandväggen.

Microsoft Entra ID

Microsoft Entra ID tillhandahåller säkerhetsfunktioner för att autentisera program och auktorisera åtkomst till resurser. Den här referensarkitekturen använder två viktiga funktioner i Microsoft Entra-ID: hanterade identiteter och rollbaserad åtkomstkontroll i Azure.

I molnprogram måste de autentiseringsuppgifter som krävs för att autentisera till molntjänster skyddas. Helst bör autentiseringsuppgifterna aldrig visas på utvecklararbetsstationer eller checkas in i källkontrollen. Azure Key Vault är ett sätt att lagra autentiseringsuppgifter och hemligheter på ett säkert sätt, men appen måste fortfarande autentisera till Key Vault för att hämta dem. Hanterade identiteter för Azure-resurser tillhandahåller Azure-tjänster med en automatiskt hanterad identitet i Microsoft Entra-ID. Den här identiteten kan användas för att autentisera till alla tjänster som stöder Microsoft Entra-autentisering, inklusive Key Vault, utan några autentiseringsuppgifter i programmet.

Rollbaserad åtkomstkontroll i Azure (Azure RBAC) hanterar åtkomsten till Azure-resurser. Detta omfattar:

• Vilken entitet har åtkomst: användare, hanterad identitet, säkerhetsobjekt.
• Vilken typ av åtkomst den har: ägare, deltagare, läsare, administratör.
• Omfång för åtkomsten: resurs, resursgrupp, prenumeration eller hanteringsgrupp.

Du kan låsa åtkomsten till App Service-miljön program genom att noggrant kontrollera den roll som krävs och typen av åtkomst för varje app. På så sätt kan flera appar distribueras på samma App Service-miljön från olika utvecklingsteam. Klientdelen kan till exempel hanteras av ett team och serverdelen av en annan. Azure RBAC kan användas för att begränsa varje teams åtkomst till de appar som det arbetar med. Utforska anpassade Azure-roller för att skapa roller som passar din organisation.

Key Vault

Vissa tjänster stöder hanterade identiteter och använder Azure RBAC för att konfigurera behörigheter för appen. Se till exempel de inbyggda Service Bus-rollerna och Azure RBAC i Azure Cosmos DB. Administratörsåtkomst till prenumerationen krävs för att bevilja dessa behörigheter, även om personal med deltagaråtkomst kan distribuera dessa tjänster. För att göra det möjligt för ett bredare team av utvecklare att kunna köra distributionsskripten är alternativet att använda intern åtkomstkontroll som tillhandahålls av tjänsterna:

• För Service Bus är det signaturer för delad åtkomst.
• För Azure Cosmos DB är det nycklar.

Om arbetsbelastningen behöver tjänstbaserad åtkomst bör dessa i förväg delade hemligheter lagras i Key Vault. Själva valvet ska nås via webbprogrammets hanterade identitet.

Hemligheter som lagras i Key Vault används av apparna, som refererar till nyckel/värde-paret för Key Vault. Detta görs i filen sites.bicep , som följande kod för Röstningsappen visar:

properties: {
  enabled: true
  hostingEnvironmentProfile: {
    id: aseId
  }
  serverFarmId: votingWebPlanName.id
  siteConfig: {
    appSettings: [
      {
        name: 'ASecret'
        value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
      }
    ]
  }
}

Skalbarhet

Utforma skalbara appar

Programmet i den här referensarkitekturen är strukturerat så att enskilda komponenter kan skalas baserat på användning. Varje webbapp, API och funktion distribueras i en egen App Service-plan. Du kan övervaka varje app för eventuella flaskhalsar i prestanda och sedan skala upp den om det behövs.

Autoskalning av Application Gateway

Autoskalning kan aktiveras på Azure Application Gateway V2. På så sätt kan Application Gateway skala upp eller ned baserat på trafikbelastningsmönstren. Den här referensarkitekturen konfigureras autoscaleConfiguration i filen appgw.bicep för att skala mellan noll och 10 ytterligare instanser. Mer information finns i Skala Application Gateway och WAF v2 .

Distribution

Distributionsskripten i den här referensarkitekturen används för att distribuera App Service-miljön, andra tjänster och programmen i App Service-miljön. När dessa program har distribuerats kanske företag vill ha en plan för kontinuerlig integrering och distribution för appunderhåll och uppgraderingar. Det här avsnittet visar några av de vanliga sätt som utvecklare använder för CI/CD för App Service-miljön program.

Appar kan distribueras till en intern App Service-miljön endast inifrån det virtuella nätverket. Följande tre metoder används ofta för att distribuera App Service-miljön appar:

• Manuellt i det virtuella nätverket: Skapa en virtuell dator i det App Service-miljön virtuella nätverket med de verktyg som krävs för distributionen. Öppna RDP-anslutningen till den virtuella datorn med hjälp av en NSG-konfiguration. Kopiera dina kodartefakter till den virtuella datorn, skapa och distribuera till App Service-miljön undernätet. Det här är ett enkelt sätt att konfigurera en inledande bygg- och testutvecklingsmiljö. Det rekommenderas dock inte för produktionsmiljön eftersom det inte kan skala det nödvändiga distributionsdataflödet.

• Punkt-till-plats-anslutning från den lokala arbetsstationen: På så sätt kan du utöka ditt App Service-miljön virtuella nätverk till utvecklingsdatorn och distribuera därifrån. Det här är ett annat sätt att konfigurera en inledande utvecklingsmiljö och rekommenderas inte för produktion.

• Via Azure Pipelines: Detta implementerar en fullständig CI/CD-pipeline som slutar med en agent som finns i det virtuella nätverket. Detta är idealiskt för produktionsmiljöer som kräver högt dataflöde för distribution. Bygg-pipelinen förblir helt utanför det virtuella nätverket. Distributionspipelinen kopierar de inbyggda objekten till byggagenten i det virtuella nätverket och distribueras sedan till App Service-miljön undernätet. Mer information finns i den här diskussionen om den lokala byggagenten mellan Pipelines och det App Service-miljön virtuella nätverket.

Användning av Azure Pipelines rekommenderas för produktionsmiljöer. Skriptning av CI/CD med hjälp av Azure Pipelines YAML-schema hjälper till att automatisera bygg- och distributionsprocesserna. Azure-pipelines.yml implementerar en sådan CI/CD-pipeline för webbappen i den här referensimplementeringen. Det finns liknande CI/CD-skript för webb-API:et samt funktionen. Läs Använda Azure Pipelines för att lära dig hur dessa används för att automatisera CI/CD för varje program.

Vissa företag kanske inte vill ha en permanent byggagent i det virtuella nätverket. I så fall kan du välja att skapa en byggagent i DevOps-pipelinen och ta bort den när distributionen är klar. Detta lägger till ytterligare ett steg i DevOps, men det minskar komplexiteten med att underhålla den virtuella datorn. Du kan till och med överväga att använda containrar som byggagenter i stället för virtuella datorer. Byggagenter kan också undvikas helt genom att distribuera från en zippad fil som placeras utanför det virtuella nätverket, vanligtvis i ett lagringskonto. Lagringskontot måste vara tillgängligt från App Service-miljön. Pipelinen ska kunna komma åt lagringen. I slutet av versionspipelinen kan en zippad fil släppas i bloblagringen. App Service-miljön kan sedan hämta den och distribuera den. Tänk på följande begränsningar i den här metoden:

• Det finns en frånkoppling mellan DevOps och den faktiska distributionsprocessen, vilket leder till problem med övervakning och spårning av eventuella distributionsproblem.
• I en låst miljö med säker trafik kan du behöva ändra reglerna för att få åtkomst till den zippade filen på lagringen.
• Du måste installera specifika tillägg och verktyg på App Service-miljön för att kunna distribuera från zip-filen.

Mer information om hur apparna kan distribueras till App Service-planerna finns i App Service-artiklarna som fokuserar på distributionsstrategier.

Kostnadsoptimering

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Andra överväganden beskrivs i avsnittet Kostnad i Microsoft Azure Well-Architected Framework. Med Azure Reservations kan du spara pengar genom att registrera dig för en 1- eller 3-årsplan för flera Azure-resurser. Läs mer i artikeln Köp en reservation.

Här följer några saker att tänka på för några av de viktigaste tjänsterna som används i den här arkitekturen.

App Service-miljön v3

Det finns olika prisalternativ för App Service. En App Service-miljön distribueras med hjälp av den isolerade v2-tjänstplanen. I den här planen finns det flera alternativ för CPU-storlekar, från I1v2 till I6v2. Den här referensimplementeringen använder tre I1v2 per instans.

Application Gateway

Priser för Application Gateway innehåller olika prisalternativ. Den här implementeringen använder SKU:n Application Gateway Standard v2 och WAF v2, som stöder automatisk skalning och zonredundans. Mer information om prismodellen som används för den här SKU:n finns i Skala Application Gateway v2 och WAF v2 .

Azure Cache for Redis

Prissättningen för Azure Cache for Redis innehåller de olika prisalternativen för den här tjänsten. Den här arkitekturen använder Premium SKU för stöd för virtuella nätverk.

Följande är prissättningssidor för andra tjänster som används för att låsa App Service-miljön:

• Prissättning för Azure Firewall

• Priser för Key Vault

• Priser för Microsoft Entra

Distribuera det här scenariot

Information om hur du distribuerar referensimplementeringen för den här arkitekturen finns i GitHub-readme och följer skriptet för standarddistribution.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• Dhanashri Kshirsagar | Senior Content PM

Övriga medarbetare:

• Deep Bhattacharya | Molnlösningsarkitekt
• Suhas Rao | Molnlösningsarkitekt

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Kör din app i Azure App Service direkt från ett ZIP-paket
• YAML-schema för Azure Pipelines
• Hämta dina hanteringsadresser från API:et
• Azure Key Vault
• Azure Pipelines

Relaterade resurser

Mer information om hur du utökar den här arkitekturen för att stödja hög tillgänglighet finns i Appdistribution med hög tillgänglighet med App Services Environment.