Overwegingen voor onafhankelijke softwareleveranciers (ISV) voor Azure-landingszones
Voor veel organisaties vertegenwoordigt de conceptuele architectuur van Azure-landingszones de bestemming van hun cloudacceptatietraject. In de landingszones wordt beschreven hoe u een Azure-omgeving bouwt met meerdere abonnementen. Elke landingszone-accounts voor schaal, beveiliging, governance, netwerken en identiteit, en is gebaseerd op feedback en lessen die zijn geleerd van veel klanten.
Fooi
Het kan handig zijn om Azure-landingszones te beschouwen als stadsplannen. De architecturen van workloads die zijn geïmplementeerd in een landingszone zijn als plannen voor gebouwen in een stad.
De water-, gas-, elektriciteits- en transportsystemen van een stad moeten allemaal aanwezig zijn voordat gebouwen kunnen worden gebouwd. Op dezelfde manier moeten de onderdelen van een Azure-landingszone, waaronder beheergroepen, beleidsregels, abonnementen en op rollen gebaseerd toegangsbeheer (RBAC), aanwezig zijn voordat productieworkloads kunnen worden geïmplementeerd.
Als onafhankelijke softwareleverancier (ISV) die uw oplossing in Azure bouwt en gebruikt, moet u de volgende resources raadplegen tijdens het bouwen van uw Azure-omgeving:
- Azure-landingszones: biedt richtlijnen voor uw algehele Azure-omgeving.
- Azure Well-Architected Framework: biedt architectuurrichtlijnen die van toepassing zijn op alle workloads.
- Multitenant-oplossingen ontwerpen in Azure: biedt specifieke architectuurrichtlijnen voor multitenant-oplossingen in Azure.
Met de Azure-landingszones kunt u een richting kiezen voor uw algemene Azure-omgeving. Maar als ISV, SaaS-provider of startup kan uw specifieke implementatiebehoeften verschillen van meer standaard klantscenario's. Hier volgen slechts enkele verschillende voorbeelden van implementatiescenario's:
- U bouwt software die klanten implementeren in hun eigen abonnementen.
- U hebt uw eigen besturingsvlak en gebruikt automatiseringsscripts of -software om Azure-resources voor uw SaaS-oplossingen te implementeren en te configureren.
- U bent een kleine ISV of start-up en wilt beginnen met de laagste kosten en wilt mogelijk geen services zoals Azure Firewall en Azure DDoS Protection gebruiken.
- U bent een grote SaaS ISV en wilt uw SaaS-toepassing splitsen in meerdere abonnementen voor schaalaanpassing. U wilt de abonnementen ook groeperen zodat ze overeenkomen met uw ontwikkel-, test-, faserings- en productieomgevingen.
- Het operationele model van uw organisatie scheidt de rollen van uw zakelijke IT-team en uw SaaS-productteams. Het zakelijke IT-team van uw organisatie beheert mogelijk resources zoals Microsoft Office 365 en Microsoft Teams en uw SaaS-productteam is mogelijk verantwoordelijk voor het bouwen en uitvoeren van uw SaaS-product (inclusief de centrale platform- en identiteitsonderdelen).
Notitie
Soms willen ISV's beginnen met slechts één Azure-abonnement dat zowel aspecten van platform 'gedeelde services' als werkelijke workloadresources bevat. Hoewel dit technisch mogelijk is, ondervindt u later uitdagingen wanneer u resources tussen abonnementen moet verplaatsen en niet alle resourcetypen kunt verplaatsen. Bekijk de impact van ontwerpdeviaties om te begrijpen welke afwijkingen mogelijk zijn en wat de verschillende risiconiveaus zijn.
ISV-implementatiemodellen
ISV-oplossingen passen vaak in een van de drie implementatiemodellen: pure SaaS, door de klant geïmplementeerde of dual-deployment SaaS. In deze sectie worden de verschillende overwegingen van elk model voor Azure-landingszones beschreven.
Pure SaaS
In het pure SaaS-model wordt uw software alleen volledig geïmplementeerd in uw Azure-abonnementen. Eindgebruikers gebruiken uw software zonder deze te implementeren in hun eigen Azure-abonnementen. In het volgende diagram gebruiken gebruikers een pure SaaS-toepassing die wordt geleverd door een ISV:
Voorbeelden van pure SaaS-software zijn e-mail als een service, Kafka-as-a-service, clouddatawarehouse-as-a-service en veel SaaS-vermeldingen in Azure Marketplace.
Als u een kleine SaaS ISV bent, hoeft u mogelijk niet meteen meerdere Azure-abonnementen te gebruiken om uw resources te implementeren. Terwijl u schaalt, kunnen de abonnementslimieten van Azure van invloed zijn op de mogelijkheid om binnen één abonnement te schalen. Bekijk de ontwerpprincipes voor landingszones op ondernemingsniveau, met name de democratisering van abonnementen en maak kennis met de architectuurbenaderingen voor multitenancy om uw toekomstige groei te plannen.
ISV's die pure SaaS-oplossingen bouwen, moeten rekening houden met de volgende vragen:
- Moeten alle Azure-resources waaruit onze SaaS-oplossing bestaat, zich in één Azure-abonnement bevinden of worden gepartitioneerd in meerdere Azure-abonnementen?
- Moeten we elke klant hosten in een eigen toegewezen Azure-abonnement of kunnen we resources maken binnen een of enkele gedeelde abonnementen?
- Hoe kunnen we het patroon Implementatiestempel (schaaleenheid) toepassen op alle lagen van onze oplossing?
- Hoe kunnen we Azure-resourceorganisatie gebruiken in multitenant-oplossingen om te voorkomen dat we te maken krijgen met uitdagingen op schaal en limieten voor Azure-abonnementen?
Door de klant geïmplementeerd
In het door de klant geïmplementeerde model kopen uw eindklanten software van u en implementeren ze deze vervolgens in hun eigen Azure-abonnementen. Ze kunnen de implementatie starten vanuit Azure Marketplace of handmatig doen door instructies te volgen en scripts te gebruiken die u opgeeft.
In het volgende diagram biedt een ISV een softwarepakket of azure Marketplace-catalogusproduct en implementeren gebruikers die resource in hun eigen Azure-abonnementen naast hun andere workloads:
Het andere workloadelement van de klant in het diagram kan de eigen workload van een klant of een ander ISV-product vertegenwoordigen dat de klant heeft geïmplementeerd binnen hun Azure-abonnement. Klanten implementeren vaak meerdere producten van verschillende ISV's in hun Azure-abonnementen. Ze combineren deze afzonderlijke producten om oplossingen te maken. Een klant kan bijvoorbeeld een databaseproduct implementeren van de ene ISV, een virtueel netwerkapparaat van een andere ISV en een webtoepassing van een derde ISV.
Voorbeelden van door de klant geïmplementeerde ISV-producten omvatten de vele installatiekopieën van virtuele machines (zoals virtuele netwerk- en opslagapparaten) en Azure-toepassingen in Azure Marketplace.
Voor sommige door de klant geïmplementeerde oplossingen kan een organisatie beheer van en updates bieden voor de oplossing die is geïmplementeerd binnen hun Azure-abonnementen voor eindgebruikers met behulp van Azure Lighthouse of Azure Managed Applications. ISV's, Solution Integrators (SIS's) en Managed Service Providers (MSP's) kunnen deze strategie gebruiken wanneer deze voldoet aan hun specifieke behoeften.
Door de klant geïmplementeerde ISV-oplossingen worden beschouwd als een standaardtoepassingsworkload vanuit het perspectief van Azure-landingszones. Houd rekening met de richtlijnen voor Azure-landingszones wanneer u uw product ontwerpt om te werken met de ontwerpprincipes voor Azure-landingszones die uw Azure-klanten gebruiken.
Het is vooral belangrijk dat u een goed begrip hebt van de concepten van de Azure-landingszone wanneer u de workloads van uw bestaande klanten naar Azure migreert.
ISV's die door de klant geïmplementeerde oplossingen bouwen, moeten rekening houden met de volgende vragen:
- Moet een klant onze oplossing implementeren in een eigen toegewezen abonnement of in een bestaand abonnement dat gerelateerde workloads bevat?
- Hoe moeten klanten netwerkconnectiviteit tot stand brengen tussen bestaande workloads (binnen en buiten Azure) en onze oplossing?
- Biedt onze oplossing ondersteuning voor verificatiemechanismen van Microsoft Entra ID of vereisen andere protocollen, zoals LDAP of Kerberos?
- Hoe verminderen of elimineren we schendingen van Azure Policy, zoals schendingen die worden veroorzaakt door conflicten tussen onze oplossingssjablonen en het Azure-beleid van een klant?
Klant-Azure-beleid dat kan leiden tot schendingen van Azure Policy, zijn voorbeelden zoals 'Alle subnetten moeten een netwerkbeveiligingsgroep hebben' en 'Er kunnen geen openbare IP-adressen worden gekoppeld aan netwerkinterfaces in de landingszone corp'. Houd rekening met het potentieel voor dit conflictveroorzakende beleid bij het plannen van uw implementatie.
SaaS voor dubbele implementatie
Sommige SaaS-oplossingen communiceren met of gebruiken resources die zijn geïmplementeerd in de Azure-abonnementen van klanten. Dit implementatiemodel wordt ook wel saaS- of SaaS-hybride implementatie genoemd. In het volgende diagram biedt een ISV een gehoste SaaS-oplossing die communiceert met resources die zijn geïmplementeerd in het Azure-abonnement van een eindgebruiker:
Een praktijkvoorbeeld van SaaS voor dubbele implementatie is Microsoft Power BI, een SaaS-service die optioneel een on-premises Power BI-gegevensgateway kan gebruiken die is geïmplementeerd op een virtuele machine in het Azure-abonnement van een klant.
Andere voorbeelden van SaaS-scenario's voor dubbele implementatie zijn:
- Uw organisatie bouwt Virtual Desktop Manager, een product dat een SaaS-consoleinterface biedt voor het beheren van Azure Virtual Desktop-resources in het Azure-abonnement van elke klant.
- Uw organisatie biedt een SaaS-console voor gegevensanalyse en maakt en verwijdert dynamisch virtuele machines voor rekenknooppunten in het Azure-abonnement van elke klant.
Als isv voor dubbele implementatie moet u verwijzen naar de Azure-landingszone voor hulp op twee gebieden: uw eigen Azure-omgeving structureren om uw SaaS-service te hosten en ervoor te zorgen dat uw implementaties in azure-abonnementen van klanten en de landingszones van uw klanten goed worden gebruikt.
ISV's die saaS-oplossingen voor dubbele implementatie bouwen, moeten rekening houden met de volgende vragen:
- Hebben we alle overwegingen beoordeeld voor het bouwen van zowel pure SaaS- als door de klant geïmplementeerde oplossingen?
- Welke onderdelen van onze oplossing moeten worden gehost in onze Azure-abonnementen en welke onderdelen moeten door de klant worden geïmplementeerd?
- Hoe kunnen we zorgen voor veilige inrichting en interacties met resources die zijn geïmplementeerd in de Azure-abonnementen van onze klanten?
Ontwerpprincipes en implementaties voor Azure-landingszones
De ontwerpprincipes voor landingszones van Azure raden u aan om af te stemmen op de systeemeigen platformmogelijkheden van Azure, zoals Log Analytics, Azure Monitor en Azure Firewall. De richtlijnen voor landingszones bieden ook specifieke implementatieopties voor Azure-landingszones.
Als ISV kunt u besluiten uw eigen landingszoneomgevingen te implementeren. Mogelijk moet u uw eigen automatisering gebruiken om Azure-resources in abonnementen te implementeren. U kunt ook de hulpprogramma's blijven gebruiken die u al gebruikt voor logboekregistratie, bewaking en andere platformlaagservices.
Als u uw eigen landingszoneomgevingen implementeert, raden we u aan om richtlijnen en voorbeeld-implementaties van azure-landingszones te gebruiken voor referentie en om uw benadering af te stemmen op bewezen azure-landingszoneontwerpen.
Microsoft Entra-tenants
Elke Azure-landingszone en de bijbehorende beheergroephiërarchie zijn geroot in één Microsoft Entra-tenant. Dit betekent dat de eerste beslissing die u moet nemen is welke Microsoft Entra-tenant moet worden gebruikt als de bron van identiteiten voor het beheren van uw Azure-resources. Identiteiten in de Microsoft Entra-id omvatten gebruikers, groepen en service-principals.
Fooi
De Microsoft Entra-tenant die u voor uw landingszone selecteert, heeft geen invloed op de verificatie op toepassingsniveau. U kunt nog steeds andere id-providers gebruiken, zoals Azure AD B2C, ongeacht welke tenant u kiest.
De richtlijnen voor Azure-landingszones en Microsoft Entra-tenants raden ten zeerste aan om één Microsoft Entra-tenant te gebruiken. Dit is de juiste benadering voor de meeste situaties. Als SaaS ISV hebt u echter mogelijk reden om twee tenants te gebruiken.
Voor sommige SaaS ISV's beheert één team bedrijfsbronnen en een afzonderlijk team beheert de SaaS-oplossing. Deze scheiding kan om operationele redenen zijn of om te voldoen aan wettelijke vereisten. Misschien is uw it-team van uw bedrijf niet toegestaan om saaS-gerelateerde abonnementen en resources te beheren, zodat ze geen beheerders van de Microsoft Entra-tenant kunnen zijn. Als dit scenario voor u van toepassing is, kunt u overwegen om twee afzonderlijke Microsoft Entra-tenants te gebruiken: één tenant voor zakelijke IT-resources zoals Office 365 en één tenant voor Azure-resources die deel uitmaken van uw SaaS-oplossing.
Elke Microsoft Entra-tenant moet een eigen domeinnaam hebben. Als uw organisatie twee tenants gebruikt, kunt u een naam kiezen zoals contoso.com voor uw zakelijke Microsoft Entra-tenant en contoso-saas-ops.com voor uw SaaS Microsoft Entra-tenant, zoals wordt weergegeven in het volgende diagram.
Waarschuwing
Wanneer u meerdere Microsoft Entra-tenants gebruikt, neemt uw beheeroverhead toe. Als u functies van Microsoft Entra ID P1 of P2 zoals Privileged Identity Management gebruikt, moet u afzonderlijke licenties aanschaffen voor elke Microsoft Entra-tenant. Het is raadzaam om alleen meerdere Microsoft Entra-tenants te gebruiken als uw situatie dit echt vereist.
Vermijd het gebruik van afzonderlijke Microsoft Entra-tenants voor preproductie- en productieomgevingen. In plaats van twee tenants te maken, zoals contoso-saas-ops-preprod.com en contoso-saas-ops-prod.com met afzonderlijke Azure-abonnementen, moet u één Microsoft Entra-tenant maken. U kunt beheergroepen en Azure RBAC gebruiken om de toegang tot abonnementen en resources onder deze enkele tenant te beheren.
Zie azure-landingszones en meerdere Microsoft Entra-tenantsen het beveiligen van Azure-omgevingen met Microsoft Entra voor meer informatie over het gebruik van meerdere Microsoft Entra-tenants.
Beheergroepen
De conceptuele architectuur van de Azure-landingszone raadt aan een specifieke hiërarchie van beheergroepen te gebruiken. ISV's kunnen echter andere vereisten hebben dan andere organisaties. In deze sectie worden enkele manieren beschreven waarop uw ISV-organisatie kan kiezen voor verschillende procedures dan wat de conceptuele architectuur van de landingszone aanbeveelt.
Beheergroep op het hoogste niveau
Uw beheergroephiërarchie is genest onder de door Azure gemaakte tenantbeheergroep . U gebruikt de hoofdgroep Tenant niet rechtstreeks.
Een standaardorganisatie die een gecentraliseerd zakelijk IT-team heeft dat hun platform en gedeelde services beheert (zoals logboekregistratie, netwerken, identiteit en beveiliging) maakt meestal één beheergroep op het hoogste niveau onder de door Azure gemaakte tenanthoofdgroep en implementeert de rest van hun beheergroepen eronder. Deze beheergroep op het hoogste niveau heeft meestal de naam van de organisatie zelf (zoals Contoso).
Als SaaS ISV hebt u mogelijk één SaaS-product of een paar afzonderlijke SaaS-producten of -bedrijfslijnen. Hoewel u over het algemeen dezelfde Microsoft Entra-tenant moet gebruiken om Azure-resources te beheren voor al uw producten (zoals besproken in de sectie Microsoft Entra-tenants ), kunt u in sommige scenario's ervoor kiezen om meerdere beheergroephiërarchieën te implementeren.
Bedenk hoe onafhankelijk uw producten van elkaar zijn en stel uzelf het volgende:
- Gebruiken onze producten allemaal dezelfde platformen voor DevOps, identiteit, beveiliging, connectiviteit en logboekregistratie?
- Worden deze gedeelde services beheerd door één centraal team?
Als u ja hebt beantwoord op beide vragen, maakt u één SaaS-productbeheergroep op het hoogste niveau onder de hoofdgroep Tenant.
Als u in plaats daarvan nee hebt beantwoord en elk van uw SaaS-producten wordt beheerd en beheerd door afzonderlijke platformteams, kunt u een afzonderlijke beheergroep op het hoogste niveau maken voor elk product, zoals de twee beheergroepen op het hoogste niveau SaaS-product-01 en SaaS-product-02.
Fooi
Het is ongebruikelijk dat één ISV meer dan slechts een paar beheergroepen op het hoogste niveau heeft. Vaak kunnen verschillende producten samen worden gecombineerd vanwege overeenkomsten in hoe ze worden beheerd en beheerd.
Deze beheerbenadering is vergelijkbaar met de testbenadering voor landingszones op ondernemingsniveau. In plaats van Contoso en Contoso-Canary te maken onder de hoofdgroep Tenant, maakt het voorbeeldbedrijf in plaats daarvan de productspecifieke Contoso-SaaS-Product-01- Contoso-SaaS-Product-02- en Contoso-SaaS-Product-03-beheergroepen eronder. Dit scenario wordt geïllustreerd in het volgende diagram:
Platformbeheergroep
In de organisatiehiërarchie van azure-landingszones bevat de beheergroep Platform alle Azure-abonnementen die onderdelen en gedeelde services hosten die worden gebruikt door workloads in de abonnementen voor de landingszone. Voorbeelden van onderdelen die zijn geïmplementeerd in het platform en abonnementen voor gedeelde services zijn gecentraliseerde logboekregistratieinfrastructuur (zoals Log Analytics-werkruimten), DevOps, beveiliging, automatiseringsprogramma's, centrale netwerkresources (zoals hub-VNet- en DDos Protection-abonnementen) en de besturingsvlakservices van een ISV.
De platformbeheergroep wordt vaak gepartitioneerd in onderliggende groepen identiteits-, beheer- en Verbinding maken iviteit om een handige scheiding van rollen en beleid voor zakelijke klanten te bieden.
In uw organisatie hebt u mogelijk één team dat alle gedeelde platformonderdelen beheert, zoals identiteit, netwerken en beheer. Zo ja, en als u geen plannen hebt om dat beheer over meerdere teams te scheiden, kunt u overwegen om één platformbeheergroep te gebruiken.
Als u in plaats daarvan afzonderlijke teams hebt die verschillende onderdelen van uw gecentraliseerde platform beheren, moet u verdere niveaus implementeren in de hiërarchie van de beheergroep onder de platformbeheergroep . Hiermee kunt u afzonderlijke beleidsregels toewijzen voor elk deel van uw gecentraliseerde platform.
In het volgende diagram ziet u twee mogelijke implementaties van de platformbeheergroep . Optie A toont een uitgebreider scenario, waarbij de platformbeheergroep drie onderliggende beheergroepen bevat: Beheer en DevOps, Identiteit en beveiliging en Verbinding maken iviteit. Elke onderliggende beheergroep bevat een abonnement met de relevante resources. Optie B toont een eenvoudiger scenario, waarbij de platformbeheergroep één platformabonnement bevat.
Beheergroep landingszones
De beheergroep Landingszones bevat de Azure-abonnementen die de werkelijke subsystemen en workloads van uw SaaS-oplossing hosten.
Deze beheergroep bevat een of meer onderliggende beheergroepen. Elk van de onderliggende beheergroepen onder Landingszones vertegenwoordigt een workload of subsubsysteem-archetype, met consistente beleids- en toegangsvereisten die van toepassing moeten zijn op alle abonnementen. Redenen voor het gebruik van meerdere archetypen zijn:
- Naleving: Als een subsysteem van uw SaaS-product PCI-DSS-compatibel moet zijn, kunt u overwegen een PCI DSS-archetype onderliggende beheergroep onder Landingszones te maken. Alle Azure-abonnementen die resources bevatten binnen het bereik van PCI-DSS-naleving, moeten binnen die beheergroep worden geplaatst.
- Lagen: Overweeg om afzonderlijke archetypen voor landingszones te maken voor de toegewezen laagklanten en klanten van de gratis laag van uw SaaS-oplossing. Elk van de onderliggende beheergroepen bevat verschillende Azure Policy-instellingen. Het beleid in de gratis laag kan bijvoorbeeld de implementatie beperken tot alleen specifieke SKU's voor virtuele machines en het beleid in de toegewezen laag vereist dat resources in specifieke regio's worden geïmplementeerd.
Omgevingsspecifieke beheergroepen
SaaS ISV's organiseren hun cloudomgevingen vaak door hun levenscyclusomgevingen voor softwareontwikkeling in een reeks te modelleren. Dit vereist doorgaans eerst implementatie naar een ontwikkelomgeving , vervolgens naar een testomgeving , vervolgens naar een faseringsomgeving en ten slotte naar een productieomgeving .
Een veelvoorkomend verschil tussen de omgevingen is hun Azure RBAC-regels, zoals wie toegang heeft tot elke groep abonnementen. De DevOps-, SaaSOps-, ontwikkel- en testteams hebben bijvoorbeeld allemaal verschillende toegangsniveaus tot verschillende omgevingen.
Belangrijk
De meeste Azure-klanten hebben honderden toepassingen en gebruiken afzonderlijke Azure-abonnementen voor elk toepassingsteam. Als elke toepassing een eigen ontwikkel-, test-, faserings- en productiebeheergroep heeft, zou er een groot aantal beheergroepen met bijna identiek beleid zijn. Voor de meeste klanten adviseert de veelgestelde vragen over landingszones op ondernemingsniveau het gebruik van afzonderlijke beheergroepen voor elke omgeving. U wordt aangeraden in plaats daarvan afzonderlijke abonnementen binnen één beheergroep te gebruiken.
SaaS ISV's kunnen echter verschillende vereisten hebben dan de meeste andere Azure-klanten en kunnen in sommige situaties goede redenen hebben om omgevingsspecifieke beheergroepen te gebruiken.
SaaS ISV's moeten soms meerdere abonnementen groeperen die shards of partities van hetzelfde subsysteem, dezelfde toepassing of workload vertegenwoordigen. Mogelijk moet u beleidsregels of roltoewijzingen toepassen op groepen abonnementen op een merkbare andere manier dan in de archetypebeheergroep. In dit geval kunt u onderliggende beheergroepen maken die overeenkomen met elke omgeving onder de archetypebeheergroep.
In de volgende diagrammen ziet u twee mogelijke opties. Optie A toont een scenario met afzonderlijke abonnementen voor elke omgeving, maar geen omgevingsspecifieke beheergroepen. Optie B toont een SaaS ISV-scenario met omgevingsspecifieke beheergroepen onder de beheergroep Reguliere stempels . Elke omgevingsspecifieke beheergroep bevat meerdere abonnementen. Na verloop van tijd schaalt de ISV hun Azure-resources in elke omgeving in een toenemend aantal abonnementen met een gemeenschappelijke set beleidsregels en roltoewijzingen.
Selecteer elk tabblad om de twee diagrammen weer te geven.
Uit bedrijf genomen en sandbox-beheergroepen
De richtlijnen voor de resourceorganisatie van De Azure-landingszone raden u aan om beheergroepen uit bedrijf te nemen en sandboxes direct onder uw beheergroep op het hoogste niveau te plaatsen.
De uit bedrijf genomen beheergroep is een bewaringsplaats voor Azure-abonnementen die worden uitgeschakeld en die uiteindelijk worden verwijderd. U kunt een abonnement dat niet meer in gebruik is, verplaatsen naar deze beheergroep om het abonnement bij te houden totdat alle resources in het abonnement definitief worden verwijderd.
De sandboxes-beheergroep bevat meestal Azure-abonnementen die worden gebruikt voor verkenningsdoeleinden en waarop los of geen beleid is toegepast. U kunt bijvoorbeeld afzonderlijke ontwikkelaars hun eigen abonnementen bieden voor ontwikkeling en testen. U kunt voorkomen dat u het normale beleid en de normale governance toepast op deze abonnementen door ze in de sandboxes-beheergroep te plaatsen. Dit verhoogt de flexibiliteit van ontwikkelaars en stelt ze in staat om eenvoudig te experimenteren met Azure.
Belangrijk
Abonnementen in de sandboxes-beheergroep mogen geen directe verbinding hebben met de abonnementen voor de landingszone. Vermijd het verbinden van sandbox-abonnementen met productieworkloads of niet-productieomgevingen die productieomgevingen spiegelen.
In het volgende diagram ziet u twee mogelijke opties. Optie A bevat niet de uit bedrijf genomen en sandbox-beheergroepen , terwijl optie B wel.
Voorbeeld van ISV-landingszones
Deze sectie bevat twee voorbeelden van Azure-landingszonestructuren voor een SaaS ISV. Selecteer elk tabblad om de twee voorbeeldlandingszones te vergelijken.
In het volgende diagram ziet u een voorbeeld van een SaaS ISV Azure-landingszoneshiërarchie met de volgende kenmerken:
- De ISV bewaart al hun platformonderdelen in één Azure-abonnement, in plaats van ze op te splitsen in meerdere platformbeheergroepen.
- Er is slechts één beheergroep voor landingszones.
- De landingszone bevat omgevingsspecifieke beheergroepen voor het organiseren van abonnementen en het toewijzen van verschillende beleidsregels en rollen.
- De ISV heeft de beheergroepen niet opgenomen voor buiten gebruik gestelde abonnementen en sandbox-abonnementen.
Volgende stappen
- Als u een multitenant-oplossing bouwt, vindt u meer informatie over het ontwerpen van multitenant-oplossingen in Azure.
- Meer informatie over wat een Azure-landingszone is.
- Meer informatie over ontwerpgebieden voor Azure-landingszones.