Överväganden för Azure App Service och Azure Functions för flera klientorganisationer

Azure App Service är en kraftfull värdplattform för webbprogram. Med Azure Functions, som bygger på App Service-infrastrukturen, kan du enkelt skapa serverlösa och händelsedrivna beräkningsarbetsbelastningar. Båda tjänsterna används ofta i lösningar med flera klientorganisationer.

Funktioner i Azure App Service och Azure Functions som stöder flera klientorganisationer

Azure App Service och Azure Functions innehåller många funktioner som stöder flera klientorganisationer.

Egna domännamn

Med Azure App Service kan du använda jokertecken-DNS och lägga till egna jokertecken för TLS-certifikat. När du använder klientspecifika underdomäner gör dns- och TLS-certifikat med jokertecken att du enkelt kan skala lösningen till ett stort antal klienter, utan att kräva en manuell omkonfiguration för varje ny klientorganisation.

När du använder klientspecifika anpassade domännamn kan du ha ett stort antal anpassade domännamn som måste läggas till i din app. Det kan bli besvärligt att hantera många anpassade domännamn, särskilt när de kräver enskilda TLS-certifikat. App Service tillhandahåller hanterade TLS-certifikat, vilket minskar det arbete som krävs när du arbetar med anpassade domäner. Det finns dock gränser att tänka på, till exempel hur många anpassade domäner som kan tillämpas på en enda app.

Integrering med Azure Front Door

App Service och Azure Functions kan integreras med Azure Front Door för att fungera som den internetuppkopplade komponenten i din lösning. Med Azure Front Door kan du lägga till en brandvägg för webbprogram (WAF) och gränscachelagring, och det ger andra prestandaoptimeringar. Du kan enkelt konfigurera om dina trafikflöden för att dirigera trafik till olika serverdelar, baserat på ändrade affärs- eller tekniska krav.

När du använder Azure Front Door med en app med flera klienter kan du använda den för att hantera dina anpassade domännamn och avsluta dina TLS-anslutningar. App Service-programmet konfigureras sedan med ett enda värdnamn och all trafik flödar till programmet, vilket hjälper dig att undvika att hantera anpassade domännamn på flera platser.

Precis som i exemplet ovan kan Azure Front Door konfigureras för att ändra begäranderubrikenHost. Det ursprungliga Host huvudet som skickas av klienten sprids via X-Forwarded-Host rubriken och programkoden kan använda det här huvudet för att mappa begäran till rätt klientorganisation.

Du kan använda privata slutpunkter eller åtkomstbegränsningar för App Service för att säkerställa att trafiken har flödat genom Front Door innan du når din app.

Mer information om hur du använder Azure Front Door i en lösning med flera klientorganisationer finns i Använda Azure Front Door i en lösning med flera klientorganisationer

Autentisering och auktorisering

Azure App Service kan verifiera autentiseringstoken för din app. När App Service tar emot en begäran kontrollerar den om vart och ett av följande villkor uppfylls:

• Begäran innehåller en token.
• Token är giltig.
• Begäran är auktoriserad.

Om något av villkoren inte uppfylls kan App Service blockera begäran eller omdirigera användaren till din identitetsprovider så att de kan logga in.

Om dina klienter använder Microsoft Entra-ID som identitetssystem kan du konfigurera Azure App Service att använda den /common-slutpunkten för att verifiera användartoken. Detta säkerställer att deras token verifieras och godkänns oavsett användarens Microsoft Entra-klientorganisation.

Du kan också integrera Azure App Service med Azure AD B2C för autentisering av konsumenter.

Mer information:

• App Service-auktorisering
• Konfigurera autentisering i en exempelwebbapp med hjälp av Azure AD B2C
• Arbeta med Microsoft Entra-identiteter med flera klientorganisationer

Åtkomstbegränsningar

Du kan begränsa trafiken till din app med hjälp av åtkomstbegränsningar. Dessa kan användas för att ange IP-adressintervallen eller de virtuella nätverk som tillåts ansluta till appen.

När du arbetar med en lösning med flera klienter bör du vara medveten om det maximala antalet regler för åtkomstbegränsning. Om du till exempel behöver skapa en regel för åtkomstbegränsning för varje klientorganisation kan du överskrida det maximala antalet regler som tillåts. Om du behöver ett större antal regler bör du överväga att distribuera en omvänd proxy som Azure Front Door.

Isoleringsmodeller

När du arbetar med ett system med flera klientorganisationer med Hjälp av Azure App Service eller Azure Functions måste du fatta ett beslut om den isoleringsnivå som du vill använda. Se de innehavarmodeller som du bör överväga för en lösning med flera klientorganisationer och vägledningen i arkitekturmetoderna för beräkning i lösningar för flera klientorganisationer för att hjälpa dig att välja den bästa isoleringsmodellen för ditt scenario.

När du arbetar med Azure App Service och Azure Functions bör du vara medveten om följande viktiga begrepp:

• I Azure App Service representerar en plan din värdinfrastruktur. En app representerar ett enda program som körs på infrastrukturen. Du kan distribuera flera appar till en enda plan.
• I Azure Functions avgränsas även ditt värd- och program, men du har ytterligare värdalternativ för elastiska värdtjänster, där Azure Functions hanterar skalning åt dig. För enkelhetens skull refererar vi till värdinfrastrukturen som en plan i hela den här artikeln, eftersom principerna som beskrivs här gäller för både App Service och Azure Functions, oavsett vilken värdmodell du använder.

I följande tabell sammanfattas skillnaderna mellan de viktigaste modellerna för innehavarisolering för Azure App Service och Azure Functions:

Delade appar

Du kan distribuera ett delat program i en enda plan och använda det delade programmet för alla dina klienter.

Detta tenderar att vara det mest kostnadseffektiva alternativet, och det kräver minst driftkostnader eftersom det finns färre resurser att hantera. Du kan skala den övergripande planen baserat på belastning eller efterfrågan, och alla klienter som delar planen drar nytta av den ökade kapaciteten.

Det är viktigt att vara medveten om App Service-kvoter och -gränser, till exempel det maximala antalet anpassade domäner som kan läggas till i en enda app och det maximala antalet instanser av en plan som kan etableras.

För att kunna använda den här modellen måste programkoden vara multitenancy-medveten.

Appar per klientorganisation med delade planer

Du kan också välja att dela din plan mellan flera klienter, men distribuera separata appar för varje klientorganisation. Detta ger dig logisk isolering mellan varje klientorganisation, och den här metoden ger dig följande fördelar:

• Kostnadseffektivitet: Genom att dela din värdinfrastruktur kan du i allmänhet minska dina totala kostnader per klientorganisation.
• Konfigurationsavgränsning: Varje klients app kan ha egna domännamn, TLS-certifikat, åtkomstbegränsningar och tokenauktoriseringsprinciper.
• Uppdelning av uppgraderingar: Varje klients program binärfiler kan uppgraderas oberoende av andra appar i samma plan.

Men eftersom planens beräkningsresurser delas kan apparna bli föremål för problem med den bullriga grannen. Dessutom finns det gränser för hur många appar som kan distribueras till en enda plan.

Abonnemang per klientorganisation

Den starkaste isoleringsnivån är att distribuera en dedikerad plan för en klientorganisation. Den här dedikerade planen säkerställer att klientorganisationen har full användning av alla serverresurser som har allokerats till planen.

Med den här metoden kan du skala din lösning för att tillhandahålla prestandaisolering för varje klientorganisation och för att undvika problemet Med bullriga grannar. Men den har också en högre kostnad eftersom resurserna inte delas med flera klienter. Du måste också överväga det maximala antalet planer som kan distribueras till en enda Azure-resursgrupp.

Värd-API:er

Du kan vara värd för API:er på både Azure App Service och Azure Functions. Valet av plattform beror på vilka specifika funktionsuppsättningar och skalningsalternativ du behöver.

Oavsett vilken plattform du använder som värd för ditt API bör du överväga att använda Azure API Management framför ditt API-program. API Management innehåller många funktioner som kan vara till hjälp för lösningar med flera klientorganisationer, inklusive följande:

• En centraliserad punkt för all autentisering. Detta kan inkludera att fastställa klientidentifieraren från ett tokenanspråk eller andra metadata för begäran.
• Routningsbegäranden till olika API-serverdelar, som kan baseras på begärans klientidentifierare. Detta kan vara användbart när du är värd för flera distributionsstämplar med sina egna oberoende API-program, men du måste ha en enda API-URL för alla begäranden.

Nätverk och flera klientorganisationer

IP-adresser

Många program med flera klienter måste ansluta till klientorganisationens lokala nätverk för att skicka data.

Om du behöver skicka utgående trafik från en känd statisk IP-adress eller från en uppsättning kända statiska IP-adresser bör du överväga att använda en NAT Gateway. Mer information om hur du använder NAT Gateway i lösningar med flera klienter finns i Överväganden för Azure NAT Gateway för flera klientorganisationer. App Service ger vägledning om hur du integrerar med en NAT Gateway.

Om du inte behöver en statisk utgående IP-adress, men i stället behöver kontrollera IP-adressen som programmet använder för utgående trafik, kan du fråga de aktuella IP-adresserna för App Service-distributionen.

Säljbudgetar

Eftersom App Service i sig är en tjänst för flera klientorganisationer måste du vara försiktig med hur du använder delade resurser. Nätverk är ett område som du måste vara särskilt uppmärksam på, eftersom det finns gränser som påverkar hur programmet kan fungera med både inkommande och utgående nätverksanslutningar, inklusive SNAT-portgränser (source network address translation) och TCP-portgränser.

Om ditt program ansluter till ett stort antal databaser eller externa tjänster kan din app riskera SNAT-portöverbelastning. I allmänhet indikerar SNAT-portöverbelastning att koden inte återanvänder TCP-anslutningar korrekt, och även i en lösning med flera klientorganisationer bör du se till att du följer de rekommenderade metoderna för återanvändning av anslutningar.

I vissa lösningar med flera klientorganisationer kan dock antalet utgående anslutningar till distinkta IP-adresser resultera i SNAT-portöverbelastning, även när du följer bra kodningsmetoder. I dessa scenarier bör du överväga något av följande alternativ:

• Distribuera NAT Gateway för att öka antalet SNAT-portar som är tillgängliga för ditt program att använda. Mer information om hur du använder NAT Gateway i lösningar med flera klienter finns i Överväganden för Azure NAT Gateway för flera klientorganisationer.
• Använd tjänstslutpunkter när du ansluter till Azure-tjänster för att kringgå lastbalanseringsgränser .

Även med de här kontrollerna på plats kan du närma dig gränser med ett stort antal klienter, så du bör planera att skala till ytterligare App Service-planer eller distributionsstämplar.

Deltagare

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

Huvudförfattare:

• John Downs | Huvudprogramtekniker

Övriga medarbetare:

• Thiago Almeida | Principal Program Manager, Azure Functions
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

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

Nästa steg

Granska Resurser för arkitekter och utvecklare av lösningar för flera klientorganisationer.