Produktkategorien im Azure Markplatz: Infrastruktur vs. Azure Application/Azure Service vs. Managed Service

Sicher ist Ihnen bei einem Blick in den Azure-Marketplace aufgefallen, dass es dort verschiedene Angebotstypen gibt, neben „Infrastucture“ (Software-Lösungen, deren Betrieb auf der Bereitstellung auf virtuellen Maschinen basiert), gibt es auch „Managed Services“, „Azure Service“, „Azure Application“ und „SaaS“. Insbesondere im Kurs „Entwerfen von Microsoft Azure-Infrastrukturlösungen“, aber auch in meinem Kurs (Azure Cloud Architect) interessieren sich Teilnehmer für die Unterschiede. Übrigens berührt dieses Thema mittelbar auch die Frage, wie Sie als Dienstleister oder ISV, Azure-basierte Lösungen für Ihre eigenen Kunden bereitstellen und abrechnen können. Ein interessanter Ansatz für MSPs ist z. B. Azure Lighthouse.

Zu Anfang ein Beispiel: Suchen Sie im Azure Markplatz nach einer Backup-Lösungen, erhalten Sie ein Ergebnis, wie in folgender Abbildung:

Die einzelnen Service-Typen haben konkret folgende Bedeutung:

IaaS (Infrastructure as a Service)

• Bedeutung: Virtuelle Maschinen, Images, Netzwerkinfrastruktur, Firewalls etc., also klassische Infrastruktur-Komponenten.
• Wo entstehen die Ressourcen?-Azure: In Ihrer Azure-Subscription, d. h. Sie u deployen z. B. ein VM-Image in einer Ressource-Gruppe.
  -Entra ID (Ihr Tenant): Keine
  -Beim Anbieter: keine, bzw. nicht zutreffend
• Abrechnung:-Meist Pay-as-you-go über IhreAzure-Rechnung
  –Kosten für die VM + evtl. Lizenz-Aufschläge des Marketplace-Anbieters.
• Beispiel: Windows Server VM-Image mit zusätzlicher Software.

Azure Application

• Bedeutung: Eine Lösung, die direkt in Azure läuft und sich in Ihre Umgebung integriert (z. B. App Services, Azure Firewall, Application Gateway).
• Wo entstehen die Ressourcen?-Azure: App-Komponenten, z. B. App Service, Azure SQL, Azure Functions. (wird als ARM-Template oder Managed App bereitgestellt)
  -Entra ID (Ihr Tenant): App-Registrierung in Ihrem Tenant für Authentifizierung
  -Beim Anbieter: Anbieter kann eigene Ressourcen für Steuerung/Updates haben
• Abrechnung:
  -Über Ihre Azure-Rechnung
  -Lizenzkosten des Anbieters können zusätzlich anfallen.
• Beispiel: Web-App für Datenanalyse, die Sie in Ihrer Azure-Subscription installieren.

Azure Service

• Bedeutung: Erweiterungen oder Add-ons für bestehende Azure-Dienste (z. B. Security-Scanner für Azure Storage).
• Wo entstehen die Ressourcen?–Azure: Erweiterung für Storage oder Security
  –Entra ID (Ihr Tenant): Oft App-Registrierung für API-Zugriff
  -Beim Anbieter: Anbieter betreibt Backend für die Service-Logik
• Abrechnung:
  -Über Ihre Azure-Rechnung-
  -Oft nutzungsbasiert (z. B. pro Scan, pro GB).

Managed Services

• Bedeutung: Ein Partner übernimmt Betrieb/Management Ihrer Azure-Ressourcen (z. B. Monitoring, Backup, Security).
• Wo entstehen die Ressourcen?-Azure: Es entstehen Ressourcen Ihrer Azure-Subscription, aber der Anbieter hat delegierte Rechte (über Azure Lighthouse).
  -Entra ID (Ihr Tenant): Es entstehen delegierte Rollen via Azure Lighthouse, sowie evtl. Service-Principals und eine App Registration zur Authentifizierung
  -Beim Anbieter: Anbieter (MSP) hat eigene Subscription für Management-Tools) z. B. zwecks Steuerung, Updates oder Lizenzprüfung.
  
• Abrechnung:-Meist monatliche Servicegebühr (pro Ressource oder pauschal).
  -Zusätzlich zu Ihren normalen Azure-Kosten.
• Besonderheit: Sie behalten die Kontrolle, aber der Anbieter verwaltet die Ressourcen Für Sie.

SaaS (Software as a Service)

• Bedeutung: Vollständig vom Anbieter gehostete Anwendung (z. B. CRM, Monitoring-Plattform).
  
• Wo entstehen die Ressourcen?
  -Azure: Keine in Ihrer Azure-Subscription
  -Entra ID (Ihr Tenant): Keine in Ihrem Tenant,
  –Beim Anbieter: Auschließlich im Tenant des Anbieters, wie z. B. App-Registrierung für Single Sign-On, OAuth). Sie erhalten lediglich Zugriff via API
   oder Portal. Alle Workloads laufen im Anbieter-Tenant. 
• Abrechnung:
  -Meist pro Benutzer / pro Monat oder nutzungsbasiert.
  -Abrechnung erfolgt über Azure Marketplace, aber die Ressourcen liegen beim Anbieter. 
• Beispiel:
  SaaS-Backup-Lösung mit CommVault, die Ihre Azure-Daten sichert, aber selbst extern läuft.

Ressourcen Standort und Abrechnung

Ressourcen-Standort differenziert nach Azure-Subscription und Entra ID

Perspektiven im Azure-Ökosystem

Sollten Sie selbst in Erwägung ziehen, Dienstleistungen auf Basis von Azure anzubieten, ergeben sich im Zusammenhang mit den oben ausgeführten Details folgende Perspektiven oder Geschäftsmodelle: 

Selbst Anbieter im Azure Marketplace

• Rolle: Produkte oder Services über den Marketplace anbieten, die Kunden direkt buchen können.
• Typische Modelle:
  • IaaS-Angebote: VM-Images, die im Kundentenant laufen.
  • Managed Apps: Lösungspakete, die in Kundensubscription deployt werden, aber vom Anbieter verwaltet werden können.
  • SaaS: Vollständig extern gehostet, Kunde zahlt über Azure Marketplace, nutzt API/Portal.
• Abrechnung: Über Microsoft (Azure Marketplace), Anbieter erhält Umsatzanteil.

Consulting  / MSP

• Rolle: Betrieb, Management und Support für Kunden-Workloads.
• Modelle:
  1. Delegated Management (Azure Lighthouse):
     • Ressourcen bleiben im Kunden-Tenant.
     • MSP erhält delegierte Rechte.
     • Kunde zahlt Azure direkt, MSP berechnet Servicegebühr.
  2. Hosting im MSP-Tenant:
     • MSP erstellt eigene Subscription, hostet Kunden-Workloads.
     • MSP stellt Gesamtpaket in Rechnung (Azure + Service).
     • Kunde hat keine direkte Azure-Rechnung.
• Abrechnung: Entweder direkt durch Microsoft (bei Lighthouse) oder über MSP (bei eigenem Hosting).

CSP (Cloud Solution Provider)

• Rolle: Reseller für Microsoft-Cloud-Dienste.
• Funktionen:
  • Verkauft Azure-Subscriptions an Kunden.
  • MSP/CSP übernimmt Abrechnung → Kunde zahlt an CSP, nicht an Microsoft.
  • CSP kann Marge und zusätzliche Services berechnen.
• Typische Szenarien:
  • Kunde hat eigene Azure-Subscription, aber unter CSP-Vertrag.
  • CSP kann auch Managed Services anbieten.

Übersicht Hosting- und Dienstleistungsmodelle

Sollten Sie tatsächlich darüber nachdenken, selbst als Anbieter zu agieren, beantworten Sie am besten für sich folgende typische Fragen:

• Wo läuft meine Lösung? Kunden-Tenant vs. Anbieter-Tenant.
• Wer stellt Rechnung? Microsoft, CSP oder Anbieter.
• Wie skaliere ich? Multi-Tenant-Architektur oder Managed Apps.
• Wie sichere ich Governance? Landing Zones, Azure Policy, RBAC.

Was ist Azure Lighthouse ?

Azure Lighthouse ist eine Azure-Dienstfunktion, die speziell für Managed Service Provider (MSP) und große Organisationen entwickelt wurde, um mandantenübergreifendes Management zu ermöglichen – ohne Ressourcen aus dem Kunden-Tenant herauszubewegen. Besonders im Fokus steht dabei die delegierte Verwaltung, d. h. MSPs oder Partner können Ressourcen in Kunden-Subscriptions verwalten, ohne dass diese Ressourcen in den MSP-Tenant verschoben werden. Azure Lighthouse nutzt als technische Basis das so genannte Azure Delegated Resource Management, d. h. der Zugriff wird über Azure RBAC und Azure AD gesteuert:

• Mandantenübergreifende Sicht: MSP kann mehrere Kunden gleichzeitig verwalten.
• Sicherheit: Kunde behält Ownership, MSP bekommt nur die vereinbarten Rechte.
• Automatisierung: MSP kann Skripte und Policies über alle Kunden ausrollen.

Typische Szenarien

• MSP übernimmt:
  • Monitoring (Azure Monitor, Security Center)
  • Patch-Management
  • Backup und Disaster Recovery
• Kunde:
  • Behält Subscription und Abrechnung erfolgt bei Microsoft.
  • Kann jederzeit Rechte entziehen.

Azure Lighthouse selbst ist kostenlos, denn der MSP berechnet Servicegebühren separat. Die normalen Azure-Kosten laufen weiterhin über den Kunden. Damit ergeben sich folgende Vorteile gegenüber dem eigenem Hosting

• Kein Risiko für MSP (kein Azure-Kostenrisiko).
• Kunde behält Compliance und Kontrolle.
• Skalierbar für viele Kunden.