Freigeben über

Überlegungen unabhängiger Softwareanbieter (ISV) zu Azure-Zielzonen

  • Artikel

Für viele Unternehmen stellt die konzeptionelle Architektur der Azure-Zielzonen das Ziel ihrer Cloudeinführung dar. Die Zielzonen beschreiben, wie Sie eine Azure-Umgebung mit mehreren Abonnements erstellen. Jede Zielzone berücksichtigt Größe, Sicherheit, Governance, Netzwerk und Identität und basiert auf dem Feedback und den Erfahrungen vieler Kunden.

Tipp

Es kann hilfreich sein, sich die Azure-Zielzonen wie Stadtpläne vorzustellen. Die Architekturen der Workloads, die in einer Zielzone bereitgestellt werden, sind wie Pläne für Gebäude in einer Stadt.

Die Wasser-, Gas-, Strom- und Verkehrssysteme einer Stadt müssen alle vorhanden sein, bevor Gebäude erstellt werden können. Auch die Komponenten einer Azure-Zielzone, einschließlich Verwaltungsgruppen, Richtlinien, Abonnements und rollenbasierte Zugriffssteuerung (RBAC), müssen alle vorhanden sein, bevor Workloads für die Produktion bereitgestellt werden können.

Als unabhängiger Softwareanbieter (ISV), der seine Lösung in Azure erstellt und betreibt, sollten Sie beim Erstellen Ihrer Azure-Umgebung die folgenden Ressourcen nutzen:

Die Azure-Zielzonen helfen Ihnen, eine Richtung für Ihre gesamte Azure-Umgebung zu wählen. Aber als ISV, SaaS-Anbieter oder Startup unterscheiden sich Ihre spezifischen Implementierungsanforderungen möglicherweise von den Standardkundenszenarien. Im Folgenden finden Sie nur ein paar Beispiele für verschiedene Implementierungsszenarien:

  • Sie erstellen Software, die Kunden in ihren eigenen Abonnements bereitstellen.
  • Sie verfügen über eine eigene Steuerungsebene und verwenden Automatisierungsskripts oder Software zur Bereitstellung und Konfiguration von Azure-Ressourcen für Ihre SaaS-Lösungen.
  • Sie sind ein kleiner ISV oder ein Startup und möchten mit den geringstmöglichen Kosten beginnen und vielleicht zunächst keine Dienste wie Azure Firewall und Azure DDoS Protection verwenden.
  • Sie sind ein großer SaaS-Softwareanbieter und planen, Ihre SaaS-Anwendung zur Skalierung auf mehrere Abonnements aufzuteilen. Außerdem möchten Sie die Abonnements so gruppieren, dass sie Ihrer Entwicklungs-, Test-, Staging- und Produktionsumgebung entsprechen.
  • Das Betriebsmodell Ihres Unternehmens trennt die Rollen Ihres unternehmenseigenen IT-Teams und Ihrer SaaS-Produktteams. Das IT-Team Ihres Unternehmens könnte Ressourcen wie Microsoft Office 365 und Microsoft Teams verwalten, und Ihr SaaS-Produktteam könnte für die Erstellung und den Betrieb Ihres SaaS-Produkts (einschließlich der zentralen Plattform und der Identitätskomponenten) verantwortlich sein.

Hinweis

Manchmal möchten Softwareanbieter mit einem einzelnen Azure-Abonnement beginnen, das sowohl die freigegebenen Dienste der Plattform als auch die eigentlichen Workloadressourcen umfasst. Obwohl dies technisch möglich ist, werden Sie später vor Herausforderungen stehen, wenn Sie Ressourcen zwischen Abonnements verschieben müssen und feststellen, dass nicht alle Ressourcentypen verschoben werden können. Überprüfen Sie die Auswirkungen von Entwurfsabweichungen, um zu verstehen, welche Abweichungen möglich sind und wie hoch das Risiko ist.

ISV-Bereitstellungsmodelle

ISV-Lösungen lassen sich häufig einem von drei Bereitstellungsmodellen zuordnen: reines SaaS-Modell, kundenseitig bereitgestelltes Modell oder SaaS-Modell mit dualer Bereitstellung. In diesem Abschnitt werden die verschiedenen Überlegungen zu den Azure-Zielzonen für jedes Modell beschrieben.

Reines SaaS-Modell

Beim reinen SaaS-Modell wird Ihre Software nur in Ihren Azure-Abonnements vollständig bereitgestellt. Endkunden konsumieren Ihre Software, ohne sie in ihren eigenen Azure-Abonnements bereitstellen zu müssen. Im folgenden Diagramm verwenden die Benutzer eine reine SaaS-Anwendung, die von einem ISV bereitgestellt wird:

Diagram that shows a pure SaaS deployment model. A user directly uses the application deployed into the I S V's Azure subscription.

Beispiele für reine SaaS-Software sind E-Mail-as-a-Service, Kafka-as-a-Service, Cloud-Data-Warehouse-as-a-Service und viele SaaS-Angebote im Azure Marketplace.

Wenn Sie ein kleiner SaaS-ISV sind, müssen Sie vielleicht nicht gleich mehrere Azure-Abonnements für die Bereitstellung Ihrer Ressourcen verwenden. Aber wenn Sie eine Skalierung durchführen, können die Abonnementgrenzwerte von Azure Ihre Fähigkeit zur Skalierung innerhalb eines Einzelabonnements beeinträchtigen. Überprüfen Sie die Entwurfsprinzipien für Zielzonen auf Unternehmensniveau, insbesondere die Demokratisierung von Abonnements, und machen Sie sich mit den Architekturansätzen für die Mehrinstanzenfähigkeit vertraut, um Ihr zukünftiges Wachstum zu planen.

Softwareanbieter, die reine SaaS-Lösungen erstellen, sollten die folgenden Fragen berücksichtigen:

  • Sollten alle Azure-Ressourcen, aus denen unsere SaaS-Lösung besteht, in einem Azure-Abonnement enthalten sein oder über mehrere Azure-Abonnements verteilt werden?
  • Sollten wir jeden Kunden in seinem eigenen dedizierten Azure-Abonnement hosten, oder können wir Ressourcen innerhalb eines oder mehrerer freigegebener Abonnements erstellen?
  • Wie können wir das Muster Bereitstellungsstempel (Skalierungseinheit) auf alle Ebenen unserer Lösung anwenden?
  • Wie können wir eine Azure-Ressourcenorganisation in mehrinstanzenfähigen Lösungen verwenden, um uns vor Skalierungsproblemen und Azure-Abonnementgrenzwerten zu schützen?

Kundenseitig bereitgestelltes Modell

Beim kundenseitig bereitgestellten Modell erwerben Ihre Kunden die Software von Ihnen und stellen sie dann in ihren eigenen Azure-Abonnements bereit. Sie können die Bereitstellung über den Azure Marketplace initiieren oder sie manuell durchführen, indem sie die Anweisungen befolgen und die von Ihnen bereitgestellten Skripts verwenden.

Im folgenden Diagramm stellt ein Softwareanbieter ein Softwarepaket oder ein Azure Marketplace-Katalogprodukt bereit, und die Benutzer stellen diese Ressource in ihren eigenen Azure-Abonnements neben ihren anderen Workloads bereit:

Diagram that shows a customer-deployed deployment model. A customer deploys resources provided by the ISV into their own Azure subscription, and users use those resources.

Das Element Andere Workload des Kunden im Diagramm kann entweder die eigene Workload eines Kunden oder ein anderes ISV-Produkt darstellen, das der Kunde im Rahmen seines Azure-Abonnements bereitgestellt hat. Kunden stellen häufig mehrere Produkte von verschiedenen ISVs in ihren Azure-Abonnements bereit. Sie kombinieren diese einzelnen Produkte, um Lösungen zu erstellen. Ein Kunde könnte z. B. ein Datenbankprodukt von einem ISV, ein virtuelles Netzwerkgerät von einem anderen ISV und eine Webanwendung von einem dritten ISV bereitstellen.

Beispiele für kundenseitig bereitgestellte ISV-Produkte sind die zahlreichen Images virtueller Computer (wie virtuelle Netzwerk- und Speichergeräte) und Azure-Anwendungen im Azure Marketplace.

Bei einigen kundenseitig bereitgestellten Lösungen kann ein Unternehmen die Verwaltung und Aktualisierung der Lösung, die im Rahmen seiner Azure-Abonnements für Endkunden bereitgestellt wird, mithilfe von Azure Lighthouse oder Azure Managed Applications übernehmen. ISVs, Lösungsintegratoren (Solution Integrators, SIs) und Anbieter verwalteter Dienste (Managed Service Providers, MSPs) können diese Strategie verwenden, wenn sie ihren speziellen Anforderungen entspricht.

Kundenseitig bereitgestellte ISV-Lösungen werden aus Sicht der Azure-Zielzonen als Standardanwendungsworkload betrachtet. Beachten Sie den Leitfaden für Azure-Zielzonen, wenn Sie Ihr Produkt so gestalten, dass es mit den Entwurfsprinzipien für Azure-Zielzonen Ihrer Azure-Kunden funktioniert.

Es ist besonders wichtig, dass Sie die Konzepte der Azure-Zielzonen gut verstehen, wenn Sie die Workloads Ihrer bestehenden Kunden zu Azure migrieren.

Softwareanbieter, die kundenseitig bereitgestellte Lösungen erstellen, sollten die folgenden Fragen berücksichtigen:

  • Sollte ein Kunde unsere Lösung in einem eigenen Abonnement oder in einem bestehenden Abonnement bereitstellen, das verwandte Workloads enthält?
  • Wie sollten Kunden die Netzwerkkonnektivität zwischen bestehenden Workloads (innerhalb und außerhalb von Azure) und unserer Lösung herstellen?
  • Unterstützt unsere Lösung Authentifizierungsmechanismen von Microsoft Entra ID oder erfordert sie andere Protokolle wie LDAP oder Kerberos?
  • Wie können wir Verstöße gegen Azure-Richtlinien, z. B. durch Konflikte zwischen unseren Lösungsvorlagen und den Azure-Richtlinien eines Kunden, reduzieren oder beseitigen?

Zu den Azure-Richtlinien des Kunden, die zu Verstößen gegen die Azure-Richtlinien führen können, gehören z. B. „Alle Subnetze müssen über eine Netzwerksicherheitsgruppe verfügen“ und „An Netzwerkschnittstellen in der Zielzone des Unternehmens können keine öffentlichen IP-Adressen angefügt werden“. Denken Sie bei der Planung Ihrer Bereitstellung an das Potenzial dieser Richtlinien, die Konflikte verursachen können.

SaaS-Modell mit dualer Bereitstellung

Einige SaaS-Lösungen interagieren mit Ressourcen oder verwenden Ressourcen, die in den Azure-Abonnements der Kunden bereitgestellt werden. Dieses Bereitstellungsmodell wird manchmal als SaaS mit dualer Bereitstellung oder SaaS-Hybrid bezeichnet. Im folgenden Diagramm stellt ein ISV eine gehostete SaaS-Lösung bereit, die mit Ressourcen interagiert, die im Azure-Abonnement eines Kunden bereitgestellt werden:

Diagram that shows a dual deployment SaaS deployment model.

Ein praktisches Beispiel für SaaS mit dualer Bereitstellung ist Microsoft Power BI, ein SaaS-Dienst, der optional ein lokales Power BI-Datengateway verwenden kann, das auf einer VM im Azure-Abonnement eines Kunden bereitgestellt wird.

Andere Beispiele für SaaS-Szenarien mit dualer Bereitstellung sind:

  • Ihr Unternehmen erstellt Virtual Desktop Manager, ein Produkt, das eine SaaS-Konsolenschnittstelle zur Steuerung von Azure Virtual Desktop-Ressourcen im Azure-Abonnement eines jeden Kunden bietet.
  • Ihr Unternehmen stellt eine SaaS-Konsole für die Datenanalyse bereit und erstellt und löscht dynamisch virtuelle Computeknotencomputer im Azure-Abonnement eines jeden Kunden.

Als ISV mit dualer Bereitstellung sollten Sie sich in zwei Bereichen an der Azure-Zielzone orientieren: Strukturierung Ihrer eigenen Azure-Umgebung zum Hosten Ihres SaaS-Diensts und Sicherstellung einer ordnungsgemäßen Interaktion zwischen Ihren Bereitstellungen in den Azure-Abonnements der Kunden und den Zielzonen Ihrer Kunden.

Softwareanbieter, die SaaS-Lösungen mit dualer Bereitstellung erstellen, sollten die folgenden Fragen berücksichtigen:

  • Haben wir alle Überlegungen zum Erstellen von reinen SaaS-Lösungen sowie von kundenseitig bereitgestellten Lösungen überprüft?
  • Welche Komponenten unserer Lösung sollten in unseren Azure-Abonnements gehostet werden, und welche Komponenten sollten vom Kunden bereitgestellt werden?
  • Wie können wir eine sichere Bereitstellung und Interaktion mit Ressourcen sicherstellen, die in den Azure-Abonnements unserer Kunden bereitgestellt werden?

Entwurfsprinzipien und Implementierungen von Azure-Zielzonen

Die Entwurfsprinzipien für Azure-Zielzonen empfehlen die Ausrichtung auf Azure-native Plattformfunktionen wie Log Analytics, Azure Monitor und Azure Firewall. Die Anleitung für Zielzonen bietet auch spezifische Implementierungsoptionen für Azure-Zielzonen.

Als ISV könnten Sie sich entscheiden, Ihre eigenen Zielzonenumgebungen zu implementieren. Möglicherweise müssen Sie Ihre eigene Automatisierung verwenden, um Azure-Ressourcen abonnementübergreifend bereitzustellen. Vielleicht möchten Sie aber auch weiterhin Tools verwenden, die Sie bereits für die Protokollierung, Überwachung und andere Dienste auf der Plattformebene einsetzen.

Wenn Sie Ihre eigenen Zielzonenumgebungen implementieren, empfehlen wir Ihnen, die Anleitung für Azure-Zielzonen und Beispiele als Referenz zu verwenden und Ihren Ansatz an bewährten Azure-Zielzonenentwürfen auszurichten.

Microsoft Entra-Mandanten

Jede Azure-Zielzone und ihre Verwaltungsgruppenhierarchie sind in einem einzelnen Microsoft Entra-Mandanten verankert. Das bedeutet, dass Sie zunächst entscheiden müssen, welchen Microsoft Entra-Mandanten Sie als Quelle für die Identitäten zur Verwaltung Ihrer Azure-Ressourcen verwenden möchten. Zu den Identitäten in Microsoft Entra ID gehören Benutzer, Gruppen und Dienstprinzipale.

Tipp

Der Microsoft Entra-Mandant, den Sie für Ihre Zielzone auswählen, hat keinen Einfluss auf die Authentifizierung auf Anwendungsebene. Sie können weiterhin andere Anbieter wie Azure AD B2C verwenden, unabhängig davon, welchen Mandanten Sie wählen.

In der Anleitung für Azure-Zielzonen und Microsoft Entra-Mandanten wird dringend empfohlen, einen einzelnen Microsoft Entra-Mandanten zu verwenden, und dies ist in den meisten Fällen auch der richtige Ansatz. Als SaaS-ISV haben Sie jedoch möglicherweise Grund, zwei Mandanten zu verwenden.

Bei einigen SaaS-ISVs verwaltet ein Team die Unternehmensressourcen und ein separates Team betreibt die SaaS-Lösung. Diese Trennung kann aus betrieblichen Gründen oder zur Einhaltung gesetzlicher Anforderungen erfolgen. Vielleicht darf Ihr unternehmenseigenes IT-Team keine SaaS-bezogenen Abonnements und Ressourcen verwalten, sodass es keine Administratoren des Microsoft Entra-Mandanten sein können. Wenn dieses Szenario auf Sie zutrifft, sollten Sie zwei separate Microsoft Entra-Mandanten verwenden: einen Mandanten für IT-Ressourcen des Unternehmens wie Office 365 und einen Mandanten für Azure-Ressourcen, die Ihre SaaS-Lösung bilden.

Jeder Microsoft Entra-Mandant muss über einen eigenen Domänennamen verfügen. Wenn Ihr Unternehmen zwei Mandanten verwendet, könnten Sie einen Namen wie contoso.com für Ihren Microsoft Entra-Unternehmensmandanten und contoso-saas-ops.com für Ihren Microsoft Entra-SaaS-Mandanten auswählen, wie im folgenden Diagramm dargestellt.

Diagram that shows Microsoft Entra tenant options for ISVs with a single corporate tenant or separation between corporate and SaaS Ops tenants.

Warnung

Wenn Sie mehrere Microsoft Entra-Mandanten verwenden, erhöht sich ihr Verwaltungsaufwand. Wenn Sie Microsoft Entra ID P1- oder P2-Features wie Privileged Identity Management verwenden, müssen Sie einzelne Lizenzen für jeden Microsoft Entra-Mandanten erwerben. Verwenden Sie am besten nur dann mehrere Microsoft Entra-Mandanten, wenn Ihre Situation dies wirklich erfordert.

Vermeiden Sie die Verwendung separater Microsoft Entra-Mandanten für Vorproduktions- und Produktionsumgebungen. Anstatt zwei Mandanten wie contoso-saas-ops-preprod.com und contoso-saas-ops-prod.com mit jeweils separaten Azure-Abonnements zu erstellen, sollten Sie einen Microsoft Entra-Mandanten erstellen. Sie können Verwaltungsgruppen und Azure RBAC verwenden, um den Zugriff auf Abonnements und Ressourcen unter diesem einzelnen Mandanten zu steuern.

Weitere Informationen zur Verwendung mehrerer Microsoft Entra-Mandanten finden Sie im Whitepaper Azure-Zielzonen und mehrere Microsoft Entra-Mandanten und Sichern von Azure-Umgebungen mit Microsoft Entra.

Verwaltungsgruppen

Die konzeptionelle Architektur der Azure-Zielzone empfiehlt, eine bestimmte Verwaltungsgruppenhierarchie zu verwenden. ISVs können jedoch andere Anforderungen aufweisen als andere Organisationen. In diesem Abschnitt werden einige Möglichkeiten beschrieben, wie Ihr ISV-Unternehmen andere Praktiken anwenden könnte als die, die in der konzeptionellen Architektur der Zielzone empfohlen werden.

Verwaltungsgruppe auf oberster Ebene

Ihre Verwaltungsgruppenhierarchie ist unter der von Azure erstellten Verwaltungsgruppe Mandantenstammgruppe geschachtelt. Sie verwenden die Mandantenstammgruppe nicht direkt.

Ein Standardunternehmen mit einem zentralisierten IT-Team, das seine Plattform und freigegebenen Dienste (wie Protokollierung, Netzwerk, Identität und Sicherheit) verwaltet, erstellt in der Regel eine Verwaltungsgruppe auf oberster Ebene unter der von Azure erstellten Mandantenstammgruppe und stellt die übrigen Verwaltungsgruppen darunter bereit. Diese Verwaltungsgruppe der obersten Ebene ist in der Regel nach dem Unternehmen selbst benannt (z. B. Contoso).

Als SaaS-ISV haben Sie vielleicht nur ein SaaS-Produkt oder Sie verfügen über mehrere separate SaaS-Produkte oder Geschäftsbereiche. Während Sie im Allgemeinen denselben Microsoft Entra-Mandanten verwenden sollten, um Azure-Ressourcen für alle Ihre Produkte zu verwalten (wie im Abschnitt Microsoft Entra-Mandanten beschrieben), können Sie in einigen Szenarien mehrere Verwaltungsgruppenhierarchien bereitstellen.

Überlegen Sie, wie unabhängig Ihre Produkte voneinander sind, und fragen Sie sich selbst:

  • Verwenden unsere Produkte alle die gleichen Plattformen für DevOps, Identität, Sicherheit, Konnektivität und Protokollierung?
  • Werden diese freigegebenen Dienste von einem einzelnen zentralen Team betrieben?

Wenn Sie beide Fragen mit Ja beantwortet haben, erstellen Sie eine einzelne Verwaltungsgruppe SaaS-Produkt der obersten Ebene unter der Mandantenstammgruppe.

Wenn Sie stattdessen mit Nein geantwortet haben und jedes Ihrer SaaS-Produkte von separaten Plattformteams verwaltet und betrieben wird, sollten Sie in Erwägung ziehen, für jedes Produkt eine eigene Verwaltungsgruppe auf oberster Ebene zu erstellen, wie die beiden Verwaltungsgruppen auf oberster Ebene SaaS Product-01 und SaaS Product-02.

Tipp

Es ist ungewöhnlich, dass ein ISV mehr als nur ein paar Verwaltungsgruppen auf oberster Ebene hat. Oft können mehrere Produkte miteinander kombiniert werden, da sie sich in der Art und Weise, wie sie verwaltet und betrieben werden, ähneln.

Dieser Verwaltungsansatz ähnelt dem Testansatz für Zielzonen auf Unternehmensniveau. Anstatt jedoch Contoso und Contoso-Canary unter der Mandantenstammgruppe zu erstellen, würde das Beispielunternehmen bei diesem Ansatz stattdessen darunter die produktspezifischen Verwaltungsgruppen Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 und Contoso-SaaS-Product-03 der obersten Ebene erstellen. Dieses Szenario ist in der folgenden Abbildung dargestellt:

Diagram that shows top-level management group options with a single management group and separate management groups for each of the SaaS products

Plattformverwaltungsgruppe

In der Ressourcenorganisationshierarchie der Azure-Zielzone enthält die Verwaltungsgruppe Plattform alle Azure-Abonnements, die Komponenten und freigegebene Dienste hosten, die von Workloads in den Zielzonenabonnements verwendet werden. Beispiele für Komponenten, die in der Plattform und den freigegebenen Diensten bereitgestellt werden, sind eine zentralisierte Protokollierungsinfrastruktur (z. B. Log Analytics-Arbeitsbereiche), DevOps, Sicherheit, Automatisierungstools, zentrale Netzwerkressourcen (z. B. Hub-VNet- und DDos-Schutzpläne) und die Dienste der Steuerungsebene eines Softwareanbieters.

Die Verwaltungsgruppe Plattform wird häufig in die untergeordneten Gruppen Identität, Verwaltung und Konnektivität unterteilt, um eine bequeme Trennung von Rollen und Richtlinien für Unternehmenskunden zu ermöglichen.

In Ihrem Unternehmen gibt es vielleicht ein einzelnes Team, das alle freigegebenen Plattformkomponenten wie Identität, Netzwerk und Verwaltung verwaltet. Ist dies der Fall und Sie haben nicht vor, diese Verwaltung auf mehrere Teams aufzuteilen, sollten Sie eine einzelne Verwaltungsgruppe vom Typ Plattform verwenden.

Wenn Sie stattdessen getrennte Teams verwenden werden, die verschiedene Teile Ihrer zentralisierten Plattform verwalten, sollten Sie weitere Ebenen in der Verwaltungsgruppenhierarchie unter der Verwaltungsgruppe vom Typ Plattform bereitstellen. Auf diese Weise können Sie für jeden Teil Ihrer zentralisierten Plattform eigene Richtlinien zuweisen.

Das folgende Diagramm veranschaulicht zwei mögliche Implementierungen der Verwaltungsgruppe vom Typ Plattform. Option A zeigt ein umfassenderes Szenario, bei dem die Verwaltungsgruppe vom Typ Plattform drei untergeordnete Verwaltungsgruppen enthält: Verwaltung und DevOps, Identität und Sicherheit und Konnektivität. Jede untergeordnete Verwaltungsgruppe enthält ein Abonnement mit den entsprechenden Ressourcen. Option B zeigt ein einfacheres Szenario, bei dem die Verwaltungsgruppe vom Typ Plattform ein einzelnes Plattformabonnement enthält.

Diagram that shows two management group hierarchies. Option A shows separate platform management groups for management, connectivity, and identity. Option B includes a platform management group option with a single management group.

Verwaltungsgruppe für Zielzonen

Die Verwaltungsgruppe Zielzonen enthält die Azure-Abonnements, die die eigentlichen Subsysteme und Workloads Ihrer SaaS-Lösung hosten.

Diese Verwaltungsgruppe enthält eine oder mehrere untergeordnete Verwaltungsgruppen. Jede der untergeordneten Verwaltungsgruppen unter Zielzonen repräsentiert eine Workload oder einen Archetypen des Subsystems, mit einheitlichen Richtlinien und Zugriffsanforderungen, die für alle Abonnements gelten sollten. Es gibt mehrere Gründe, mehrere Archetypen zu verwenden:

  • Konformität: Wenn ein Subsystem Ihres SaaS-Produkts PCI-DSS-konform sein muss, sollten Sie eine untergeordnete Verwaltungsgruppe des Archetyps PCI DSS unter Zielzonen erstellen. Alle Azure-Abonnements, die Ressourcen enthalten, die in den Geltungsbereich der PCI-DSS-Konformität fallen, sollten in diese Verwaltungsgruppe aufgenommen werden.
  • Ebenen: Ziehen Sie in Erwägung, getrennte Zielzonenarchetypen für die dedizierten Kunden Ihrer SaaS-Lösung und die Kunden mit Free-Tarif zu erstellen. Jede der untergeordneten Verwaltungsgruppen enthält unterschiedliche Azure Policy-Einstellungen. Beispielsweise können die Richtlinien des Free-Tarifs die Bereitstellung auf bestimmte SKUs für virtuelle Computer beschränken, während die Richtlinien des dedizierten Tarifs die Bereitstellung von Ressourcen in bestimmten Regionen erfordern können.

Umgebungsspezifische Verwaltungsgruppen

SaaS-ISVs organisieren ihre Cloudumgebungen oft, indem sie ihre Umgebungen für die Lebenszyklen der Softwareentwicklung in einer Sequenz modellieren. Dies erfordert in der Regel die Bereitstellung zunächst in einer Entwicklungsumgebung, dann in einer Testumgebung, anschließend in einer Stagingumgebung und schließlich in einer Produktionsumgebung.

Ein allgemeiner Unterschied zwischen den Umgebungen sind die Azure RBAC-Regeln, z. B. wer auf die einzelnen Abonnementgruppen zugreifen darf. So haben beispielsweise die DevOps-, SaaSOps-, Entwicklungs- und Testteams möglicherweise unterschiedliche Zugriffsebenen für verschiedene Umgebungen.

Wichtig

Die meisten Azure-Kunden haben Hunderte von Anwendungen und verwenden separate Azure-Abonnements für jedes Anwendungsteam. Wenn jede Anwendung ihre eigenen Verwaltungsgruppen für Entwicklung, Test, Staging und Produktion hätte, gäbe es eine große Anzahl von Verwaltungsgruppen mit nahezu identischen Richtlinien. Für die meisten Kunden raten die häufig gestellten Fragen zu Zielzonen auf Unternehmensniveau davon ab, separate Verwaltungsgruppen für jede Umgebung zu verwenden. Stattdessen wird empfohlen, separate Abonnements in einer einzelnen Verwaltungsgruppe zu verwenden.

SaaS-ISVs können jedoch andere Anforderungen aufweisen als die meisten anderen Azure-Kunden und in manchen Situationen gute Gründe haben, um umgebungsspezifische Verwaltungsgruppen zu verwenden.

SaaS-ISVs müssen manchmal mehrere Abonnements gruppieren, die Shards oder Partitionen desselben Subsystems, derselben Anwendung oder derselben Workload darstellen. Möglicherweise müssen Sie Richtlinien oder Rollenzuweisungen auf Gruppen von Abonnements auf eine deutlich andere Weise anwenden als in der Verwaltungsgruppe für Archetypen. In diesem Fall sollten Sie erwägen, untergeordnete Verwaltungsgruppen zu erstellen, die jeder Umgebung unter der Verwaltungsgruppe für Archetypen entsprechen.

Die folgenden Diagramme veranschaulichen zwei mögliche Optionen. Option A zeigt ein Szenario mit separaten Abonnements für jede Umgebung, aber ohne umgebungsspezifische Verwaltungsgruppen. Option B zeigt ein SaaS-ISV-Szenario mit umgebungsspezifischen Verwaltungsgruppen unter der Verwaltungsgruppe Reguläre Stempel. Jede umgebungsspezifische Verwaltungsgruppe enthält mehrere Abonnements. Im Laufe der Zeit skaliert der ISV seine Azure-Ressourcen in jeder Umgebung über eine zunehmende Anzahl von Abonnements mit einem gemeinsamen Satz von Richtlinien und Rollenzuweisungen.

Wählen Sie jede Registerkarte aus, um die beiden Diagramme anzuzeigen.

Verwaltungsgruppen für den Typ „Außerbetriebnahme“ und „Sandboxes“

Der Leitfaden zur Ressourcenorganisation für die Azure-Zielzone empfiehlt, die Verwaltungsgruppen vom Typ Außerbetriebnahme und Sandboxes direkt unterhalb Ihrer Verwaltungsgruppe auf oberster Ebene einzubeziehen.

Die Verwaltungsgruppe Außerbetriebnahme ist ein Aufbewahrungsort für Azure-Abonnements, die deaktiviert und schließlich gelöscht werden sollen. Sie können ein Abonnement, das nicht mehr verwendet wird, in diese Verwaltungsgruppe verschieben, um es nachzuverfolgen, bis alle Ressourcen des Abonnements endgültig gelöscht sind.

Die Verwaltungsgruppe Sandboxes enthält in der Regel Azure-Abonnements, die zu Erkundungszwecken verwendet werden und auf die keine oder nur lockere Richtlinien angewendet werden. Sie könnten z. B. einzelnen Entwicklern eigene Abonnements für Entwicklung und Tests zur Verfügung stellen. Sie können die Anwendung der normalen Richtlinien und Governance auf diese Abonnements vermeiden, indem Sie sie in der Verwaltungsgruppe Sandboxes platzieren. Dies erhöht die Agilität der Entwickler und ermöglicht es ihnen, problemlos mit Azure zu experimentieren.

Wichtig

Abonnements in der Verwaltungsgruppe Sandboxes sollten keine direkte Verbindung zu den Abonnements der Zielzone haben. Vermeiden Sie die Verbindung von Sandbox-Abonnements mit Produktionsworkloads oder mit Nicht-Produktionsumgebungen, die Produktionsumgebungen spiegeln.

Das folgende Diagramm veranschaulicht zwei mögliche Optionen. Option A enthält nicht die Verwaltungsgruppen Außerbetriebnahme und Sandboxes, Option B hingegen schon.

Diagram that shows the Decommissioned and Sandboxes management groups on the same level as the Platform and Landing Zones management groups.

Beispiel für ISV-Zielzonen

Dieser Abschnitt enthält zwei Beispielstrukturen für Azure-Zielzonen für einen SaaS-ISV. Wählen Sie jede Registerkarte aus, um die beiden Zielzonen zu vergleichen.

Das folgende Diagramm zeigt eine Beispielhierarchie für Azure-Zielzonen eines SaaS-ISVs mit den folgenden Merkmalen:

Diagram that shows an example Azure landing zone hierarchy for an ISV. Most of the components from this article are omitted.

Nächste Schritte