Azure SQL für IT-Entscheider

1. Management Summary

Azure SQL bezeichnet eine Familie von Microsofts Cloud-Datenbankdiensten, die SQL Server-Technologie in Azure als Service bereitstellen. Dazu gehören Azure SQL Database (ein einzeldatenbankbasierter PaaS-Dienst für moderne Anwendungen), Azure SQL Managed Instance (eine verwaltete SQL Server-Instanz in Azure mit hoher Kompatibilität zu on-premises SQL Server) und SQL Server auf Azure-VMs (die klassische SQL Server-Installation auf virtuellen Maschinen in Azure für volle Kontrolle). Jede Variante bietet relationale SQL-Datenbankfunktionen, unterscheidet sich jedoch in Funktionsumfang, Betriebsmodell und dem Grad der vom Kunden selbst zu verantwortenden Verwaltung.

Geschäftlicher Nutzen von Azure SQL: Durch die Nutzung dieser Dienste können Unternehmen ihre Time-to-Value verbessern – neue Datenbanken sind in Minuten einsatzbereit, ohne Anschaffung und Bereitstellung eigener Hardware. Azure übernimmt einen Großteil der Betriebsverantwortung: Patches, Sicherungen und Hochverfügbarkeits-Mechanismen laufen automatisch im Hintergrund, was den internen Administrationsaufwand deutlich reduziert. Gleichzeitig bietet Azure SQL Elastizität, um auf schwankende Anforderungen zu reagieren (Skalierung der Ressourcen nahezu in Echtzeit). Globale Verfügbarkeit ermöglicht es, Datenbanken in vielen Azure-Regionen bereitzustellen, um Latenz zu minimieren oder Compliance-Anforderungen zur Datenresidenz zu erfüllen. Die Kosten sind nutzungsbasiert und planbar – statt hoher Anfangsinvestitionen zahlen Sie monatlich für tatsächlich genutzte Kapazitäten, mit Optionen für Rabatte bei langfristiger Bindung.

Wann welche Azure-SQL-Variante? Als Faustregel gilt: Azure SQL Database eignet sich ideal für neue (cloud-native) Anwendungen oder einzelne Datenbanken, bei denen maximale PaaS-Entlastung und automatische Skalierung im Vordergrund stehen. Azure SQL Managed Instance ist optimal, wenn eine hohe Funktionsparität zu SQL Server on-premises benötigt wird (z.B. SQL-Agent-Jobs, Cross-Database-Abfragen) und bestehende Anwendungen mit minimalen Änderungen in die Cloud gebracht werden sollen. SQL Server auf Azure-VMs bietet sich an, wenn weiterhin volle Kontrolle über das Betriebssystem und die SQL-Server-Umgebung erforderlich ist – sei es aus technischen Gründen (z.B. spezielle Erweiterungen, ältere SQL-Versionen) oder für spezifische Compliance-Vorgaben – allerdings um den Preis eines höheren eigenen Verwaltungsaufwands.

Kostenlogik „auf einer Serviette“: Azure SQL-Dienste basieren heute primär auf dem vCore-Modell, bei dem Rechenleistung (vCPU/Arbeitsspeicher) und Speicher separat skaliert und abgerechnet werden. Historisch gab es ein DTU-Modell (Database Transaction Units) – ein abstraktes Maß für eine kombinierte Leistungskapazität – das jedoch als Legacy anzusehen ist und nur noch in Alt-Szenarien oder Azure SQL Elastic Pools der Basic/Standard/Premium-Klassen genutzt wird. Moderne Deployments setzen auf vCore wegen besserer Transparenz und Flexibilität. Innerhalb des vCore-Modells gibt es bereitgestellte (provisioned) Leistungsstufen, bei denen eine feste Anzahl vCores dauerhaft reserviert ist, und den Serverless-Betrieb, bei dem sich die vCores dynamisch an die Last anpassen und bei Inaktivität sogar die Datenbank pausiert – ideal zur Kostenreduktion bei stark schwankender oder sporadischer Nutzung. Elastic Pools ermöglichen es, mehrere Azure SQL Datenbanken einen gemeinsamen Ressourcenpool nutzen zu lassen, um Lastspitzen mehrerer Mandanten auszugleichen und ungenutzte Kapazität zu vermeiden. Für umfangreiche oder wachstumsstarke Daten gibt es den Hyperscale-Service-Tier, der durch eine skalierbare Architektur nahezu unbegrenzten Speicher (bis in den zweistelligen Terabyte-Bereich) und schnelle Skalierung/Backups bietet. Darüber hinaus können durch Reserved Capacity (1- oder 3-Jahres-Pläne) signifikante Kosteneinsparungen erzielt werden, indem man sich langfristig zu einer bestimmten Kapazität verpflichtet. Der Azure Hybrid Benefit (AHB) erlaubt die Anrechnung vorhandener SQL Server-Lizenzen (mit Software Assurance) auf Azure-SQL-Instanzen, wodurch der lizenzierte Teil der Cloud-Kosten entfällt. Zusammengefasst setzen sich die monatlichen Kosten typischerweise aus einer Grundgebühr für Compute (vCores pro Stunde) plus Speicherbedarf (GB pro Monat) sowie optionalen Posten für Backup-Aufbewahrung (Long-Term Retention) und ggf. Replikate (Geo-DR oder Read-Replicas) zusammen – alles klar definiert im Azure-Preismodell.

Typische Risiken und Fehlannahmen: Bei der Einführung von Azure SQL sollten IT-Entscheider einige Fallstricke kennen und vermeiden:

• Fehlannahme 1: „PaaS macht den DBA überflüssig.“ In der Praxis nimmt Azure zwar Routineaufgaben ab, doch Datenbank-Optimierung und -Überwachung bleiben wichtig. Man sollte weiterhin Abfrage-Performance, Indexierung und Kapazitätsentwicklung im Blick behalten, um keine bösen Überraschungen zu erleben.
• Fehlannahme 2: „Azure SQL verhält sich identisch wie on-premises.“ Trotz hoher Kompatibilität gibt es Funktionsunterschiede (z.B. kein Zugriff aufs Betriebssystem, teils geänderte Limits). Lösung: Vorab Kompatibilitätstests (z.B. mit dem Microsoft DMA-Tool) durchführen und Architektur oder Code an Cloud-Gegebenheiten anpassen.
• Fehlannahme 3: „Skalierung löst alle Performance-Probleme automatisch.“ Einfach mehr vCores zuzuteilen, hilft nicht immer – manchmal limitiert der Anwendungsentwurf oder ineffiziente SQL die Performance. Es gilt, Architekturpatterns (Caching, Partitionierung etc.) zu berücksichtigen und nicht allein auf die Cloud-Skalierung zu vertrauen.
• Fehlannahme 4: „Kosten in der Cloud sind automatisch geringer.“ Ohne Steuerung können Cloud-Kosten unerwartet steigen (z.B. durch vergessenes Herunterskalieren, Daten-Egress oder viele Backup-Aufbewahrungen). Abhilfe schaffen Kostenkontrollen: Budgets, Alerts, regelmäßiges Rightsizing und Nutzung von Sparoptionen (AHB, Reserved Instances).
• Fehlannahme 5: „Hochverfügbarkeit und DR sind automatisch vollständig abgedeckt.“ Azure SQL bietet hohe SLA und optionale Geo-Replikation, aber kundenseitige Planung bleibt nötig. Beispielsweise muss man Geo-Failover explizit einrichten und testen, um im Ernstfall vorbereitet zu sein. Ebenso sollten Notfallpläne (Runbooks) existieren, wer was tut, falls ein Ausfall eintritt.

Durch Beachtung dieser Hinweise und eine klare Evaluierung der eigenen Anforderungen können Unternehmen den Mehrwert von Azure SQL voll ausschöpfen, ohne von unbeabsichtigten Nebenwirkungen überrascht zu werden.

2. Azure SQL im Überblick – Architektur & Dienste

Familienüberblick: Azure SQL umfasst drei Bereitstellungsmodelle, die auf dem SQL Server-Engine-Kern aufbauen, aber unterschiedlich implementiert sind. Azure SQL Database ist ein Platform-as-a-Service (PaaS)-Angebot für einzelne Datenbanken oder Pools von Datenbanken. Microsoft verwaltet hier die darunterliegende Infrastruktur vollständig – der Nutzer erhält eine isolierte logische Datenbank mit garantierten Ressourcen und muss sich nicht um Betriebssystem, Instanzkonfiguration oder Patch-Management kümmern. Azure SQL Managed Instance (MI) hingegen ist ein PaaS-Angebot auf Instanz-Ebene: Der Dienst stellt eine nahezu vollständige SQL Server-Instanz in Azure bereit, die mehrere Datenbanken enthalten kann und viele vertraute SQL-Server-Funktionen unterstützt (Agent, Cross-DB-Abfragen etc.). MI operiert innerhalb eines vom Kunden definierten virtuellen Netzwerks (VNet) und zielt auf Migrationen bestehender SQL-Server-Umgebungen mit minimalen Änderungen. SQL Server auf Azure-VMs schließlich ist ein Infrastructure-as-a-Service (IaaS)-Ansatz – hier wird ein vollständiges Windows- oder Linux-Betriebssystem in Azure als VM betrieben, darauf ein SQL Server installiert. Dies entspricht technisch einer on-premises Installation, läuft aber in der Cloud; Verwaltung und Updates obliegen weitgehend dem Kunden (mit optionaler Unterstützung durch Azure z.B. über automatisches Update-Management oder Azure Backup für VMs).

Kernarchitektur und SLAs: Azure SQL Database und MI basieren auf einer hochverfügbaren Azure-Architektur mit integrierter Redundanz. Jeder Datenbankdienst wird in dreifacher Replikation bereitgestellt (bei Azure SQL Database je nach Tier synchron über Always-On-Technologie innerhalb einer Region, bei Managed Instance ähnlich – z.B. im Business Critical-Tarif mit synchronen sekundären Replikaten). Dies ermöglicht Microsoft, ein SLA von 99,99% Verfügbarkeit pro Datenbank bzw. Instanz zu garantieren. In Kombination mit Availability Zones (falls aktiviert und vom Tier unterstützt) kann die Fehlertoleranz weiter erhöht werden (SLA bis zu 99,995% dank verteiltem Betrieb über physisch getrennte Rechenzentren in derselben Region). Azure-VMs mit SQL Server bieten ein 99,95% SLA für die VM (bei Einzel-VM in Azure; höhere Verfügbarkeit erfordert Konfiguration von VM-Cluster oder Verfügbarkeitszonen vom Kunden). Alle Azure SQL-Varianten stehen weltweit in einer Vielzahl von Azure-Regionen zur Verfügung, was die Wahl eines standortnahen Betriebs (zur Reduktion von Latenzen und Einhaltung von Datenresidenz-Vorgaben) erleichtert. Zudem sind Dienste wie Azure SQL Database in bestimmten Spezial-Clouds verfügbar (Government-Cloud, isolierte Regionen für bestimmte Länder), falls regulatorisch nötig.

Skalierungsmodelle: Azure SQL bietet flexible Skalierungsoptionen, um Leistung und Kapazität bedarfsgerecht anzupassen. Vertikale Skalierung (Scale-Up/Down) lässt sich per Konfiguration umsetzen: die Zuweisung von vCores/DTUs, Speicher und ggf. IO-Ressourcen kann hoch- oder heruntergefahren werden, meist mit minimaler Unterbrechung. Im vCore-Modell kann z.B. eine Azure SQL Database von 4 auf 8 vCores hochskaliert werden, wenn die Last wächst; die Änderung wird in der Regel innerhalb von Sekunden bis wenigen Minuten online umgesetzt. Azure SQL Database Hyperscale geht einen Schritt weiter: Durch eine mehrschichtige Architektur mit separaten Speicher- und Rechenknoten skaliert die Datenbank nahezu unbegrenzt (aktuell bis 100+ TB) und kann zusätzliche Read-Replicas (bis zu 30) erhalten, um Lesezugriffe horizontal zu skalieren. Serverless (nur bei Azure SQL Database im General Purpose Tier verfügbar) skaliert automatisch zwischen einem konfigurierten Minimum und Maximum an vCores, je nach aktueller Auslastung – ohne manuelles Eingreifen, wodurch sich kurzfristige Lastspitzen abfangen lassen, und es pausiert die Datenbank bei längerer Inaktivität ganz, um Kosten zu sparen. Elastic Pools erlauben es, mehrere Azure SQL Datenbanken auf einem gemeinsamen Ressourcenbudget (DTUs oder vCores) zu betreiben: Dadurch können mehrere Anwendungen oder Mandanten Lastspitzen gegenseitig abfedern – Ressourcen, die eine inaktive DB nicht nutzt, stehen anderen im Pool zur Verfügung. Azure SQL Managed Instance skaliert ebenfalls vertikal (vCores rauf/runter, Speicher rauf), jedoch auf Instanz-Ebene (alle DBs in der Instanz teilen sich die Ressourcen). MI unterstützt aktuell bis zu 128 vCores und – im neuen „vNext“ General Purpose Tier – bis zu 32 TB Speicher (Standard GP bis 16 TB, Business Critical bis 4-8 TB je nach Hardware-Generation). Ein Spezialfall von Skalierung ist das Read-Scale-Out: In Azure SQL Database Business Critical steht ein kostenloser integrierter Read-Replica (eine der synchronen sekundären Kopien) für reine Lese-Workloads zur Verfügung – Entwickler können diesen durch den Verbindungsstring-Parameter ApplicationIntent=ReadOnly gezielt nutzen, um z.B. Reporting-Last vom Primärknoten fernzuhalten. In Hyperscale kann man dedizierte Read-Knoten hinzufügen. Bei Managed Instance im Business Critical-Tarif ist ebenfalls mindestens eine der HA-Replikate lesbar nutzbar. Für SQL Server auf VMs hängt die Skalierung vom VM-Größenangebot ab – man kann eine VM auf eine größere SKU hochstufen (vertikal) oder zusätzliche VMs in einen Always On-Verbund aufnehmen (horizontal scaling für Lese-Workloads via Readable Secondaries), allerdings meist verbunden mit Konfigurationsaufwand und Downtime.

Automatisierter Betrieb: Eines der Hauptmerkmale der PaaS-Angebote Azure SQL Database und MI ist die Automatisierung administrativer Aufgaben. Patch-Management (inkl. Betriebssystem-Patches und SQL-Engine-Updates) erfolgt durch Microsoft – Sicherheitsupdates werden rasch eingespielt, oft ohne Ausfallzeit durch orchestrierte Failover der unterliegenden Instanz. Bei Managed Instance kann ein optionales Wartungsfenster konfiguriert werden, in dem planbare Wartungsereignisse bevorzugt stattfinden, um geschäftskritische Zeiten zu meiden. Backup & Restore sind vollständig integriert: Jede Azure SQL-Datenbank wird automatisch regelmäßig gesichert (Full-Backup i.d.R. wöchentlich, Differential täglich, Transaktionsprotokoll alle 5-10 Minuten). Diese Backups ermöglichen Point-in-Time-Wiederherstellungen innerhalb der Aufbewahrungsdauer (standardmäßig 7 Tage, erweiterbar bis 35 Tage). Langzeitaufbewahrung (LTR) kann für einzelne Wochen-/Monats-/Jahresbackups eingerichtet werden, um z.B. Compliance-Anforderungen (Aufbewahrung bis zu 10 Jahre) abzudecken – dies geschieht, ohne dass der Benutzer eigene Backup-Jobs schreiben muss. Ein Restore läuft einfach per Portal, CLI oder PowerShell: es wird eine neue Datenbank bis zu einem gewünschten Zeitpunkt hergestellt. Azure SQL Managed Instance bietet zusätzlich die Möglichkeit, manuelle Datenbank-Backups auf Azure Blob Storage abzulegen und wiederherzustellen (z.B. für einen kontrollierten Export oder Import großer Datenbanken). Hochverfügbarkeit ist – wie erwähnt – eingebaut; der Benutzer muss keine Failover-Cluster oder Ähnliches einrichten. Im Fehlerfall (z.B. Hardwareausfall eines Knotens) übernimmt Azure automatisch ein Failover auf eine intakte Replikat-Instanz, was transparente Wiederherstellung innerhalb von Sekunden bis wenigen Minuten ermöglicht. Für Disaster Recovery über Regionsgrenzen hinweg bietet Azure SQL die Active Geo-Replication (für SQL Database) bzw. Auto-Failover-Gruppen (für SQL DB und MI). Damit können sekundäre Datenbankkopien in einer anderen Azure-Region asynchron mitlaufen. Im Ernstfall oder Test kann auf diese manuell oder automatisch (im Failover-Fall) umgeschaltet werden. Die Replikation erfolgt kontinuierlich, sodass ein RPO (Recovery Point Objective) von unter 5 Sekunden erreichbar ist (keine garantierte 0, aber typischerweise sehr geringer Datenverlust), und ein RTO (Recovery Time Objective) im einstelligen Minutenbereich für die Übernahme einer anderen Region. Solche Mechanismen muss der Kunde zwar aktiv konfigurieren, aber Azure erledigt die Datenreplikation und überwacht den Zustand. Auch Updates von Azure SQL erfolgen gestaffelt und möglichst ohne Auswirkungen: In seltenen Fällen, etwa bei Engine-Upgrades, kann ein kurzes Failover oder ein Neuverbinden der Clients auftreten – daher sollte man Azure-Wartungsankündigungen beobachten und gegebenenfalls vorbereitend handeln (z.B. Graceful Failover vorab in wartungsarmen Zeiten). In Summe reduziert Azure SQL die operativen Routineaufgaben drastisch im Vergleich zu selbst betriebenen SQL-Servern.

Sicherheit und Netzwerkintegration: Azure SQL-Dienste sind von Grund auf mit Sicherheitsfunktionen ausgestattet. Verschlüsselung ruhender Daten (Transparent Data Encryption, TDE) ist standardmäßig für alle Datenbanken aktiviert – die Datenfiles und Backups sind also ohne weiteren Aufwand geschützt. Kunden können bei Bedarf eigene Schlüssel in Azure Key Vault hinterlegen und für TDE nutzen (Bring Your Own Key), um volle Kontrolle über die Verschlüsselung zu haben. Verschlüsselung in Bewegung (TLS) ist ebenfalls erzwungen: Verbindungen zu Azure SQL erfordern eine verschlüsselte Verbindung (mindestens TLS 1.2; ältere Protokolle sind deaktiviert). Zudem lassen sich Features wie Always Encrypted nutzen, um besonders sensible Daten bereits clientseitig zu verschlüsseln, sodass der Server nur chiffrierte Werte sieht. Netzwerkzugriff: Azure SQL Database ist standardmäßig über einen öffentlichen Endpunkt erreichbar, den man per Firewall-Regeln oder VNet-Service Endpoints absichern kann. Für höhere Sicherheit kann ein Private Endpoint konfiguriert werden – dabei erhält die Datenbank (bzw. der Server) eine private IP-Adresse in Ihrem Azure-VNet, und der öffentliche Zugriff wird unterbunden. Azure SQL Managed Instance geht hier noch weiter: MI wird dediziert in einem VNet bereitgestellt (sogenannte Injektion des Dienstes in Ihr VNet). Die Instanz bekommt interne IP-Adressen; standardmäßig gibt es keinen öffentlichen Endpoint (optional einschaltbar, falls benötigt). Die Anbindung von MI an das eigene Unternehmensnetz (z.B. per VPN oder ExpressRoute) ist damit relativ einfach, da MI wie ein Server im internen Netzwerk agiert. Authentifizierung und Zugriff: Neben den klassischen SQL-Logins wird Azure AD (Microsoft Entra ID)-Integration unterstützt. Für Azure SQL Database können Azure AD-Konten als DB-User verwendet werden (sogar Azure AD-Gruppen für Rollenmitgliedschaften). Bei Managed Instance sind sowohl Azure AD-Logins auf Instanzebene als auch -Benutzer auf Datenbankebene möglich, was eine nahtlose Anbindung an bestehende Identity-Management-Prozesse erlaubt. Über Azure AD lässt sich auch Multi-Faktor-Authentifizierung und Konditionales Zugriffsmanagement für Datenbankzugriffe realisieren. Zugriffsmodelle: Im PaaS-Umfeld gibt es kein direktes Betriebssystem-Login; alle Zugriffe erfolgen über SQL-Berechtigungen. Man kann aber feingranuliert steuern, wer z.B. mit Administratorrechten (Azure AD Admin für den Server/die MI) ausgestattet ist und welche Teams nur lesenden oder schreibenden Zugriff haben. Auditing & Threat Detection: Azure SQL ermöglicht das Protokollieren von Zugriffen und Änderungen (Azure SQL Auditing schreibt z.B. Logins, Schema-Änderungen, selektive Abfragen in Logfiles oder Log Analytics). Außerdem analysiert der optionale Dienst Microsoft Defender for SQL Auffälligkeiten (z.B. ungewöhnlich viele Fehlversuche, potenzielle SQL-Injection-Muster) und meldet diese. Zusammen mit Netzwerkisolierung, Verschlüsselung und Identity-Integration bietet Azure SQL ein hohes Sicherheitsniveau out-of-the-box, erfordert aber natürlich eine bewusste Konfiguration durch den Kunden, um diese Tools richtig einzusetzen.

3. Unterschiede zu SQL Server (on-prem/VM)

Der Umstieg von einem selbst verwalteten SQL Server (sei es on-premises auf eigener Hardware oder in einer Azure-VM) zu Azure SQL PaaS bringt wesentliche Änderungen in Verantwortlichkeiten und Möglichkeiten mit sich. Hier sind die wichtigsten Unterschiede:

Verantwortungsteilung – Plattform vs. Selbstverwaltung: In Azure SQL Database und Managed Instance übernimmt Microsoft einen Großteil der traditionellen DBA-Infrastrukturaufgaben. Hardware-Bereitstellung, Betriebssysteminstallation, Netzwerk-Konfiguration des Servers, Patchen von OS und SQL-Engine, Einrichtung von Clustering für Hochverfügbarkeit, automatische Backups und mehr – all das läuft im Hintergrund als Teil des Dienstes. Ihr Team muss sich somit nicht mehr um das Installieren von Service Packs oder das Auswechseln defekter Festplatten kümmern. Bei SQL Server auf Azure-VMs hingegen ändert sich dies kaum im Vergleich zu on-prem: Zwar entfallen Anschaffung und physische Rack-Installation, aber VM-Größenwahl, OS-Pflege, SQL-Installation und Patches, Backup-Jobs, HA-Konfigurationen liegen hier in Ihrer Verantwortung (Azure bietet Tools, aber keine vollautomatische Verwaltung – es ist letztlich “Ihr Server” in der Cloud). In der Praxis bedeutet dies, dass PaaS-Kunden ihren Fokus verschieben: weg von Infrastruktur, hin zu Anwendungsnahen Aufgaben wie Schema-Design, Abfrageoptimierung und Sicherheitskonfiguration. Wichtig ist auch zu verstehen, dass im PaaS-Modell gewisse administrative Eingriffe nicht möglich oder nicht nötig sind – z.B. hat man keinen RDP-Zugriff auf einen Azure SQL-Datenbankserver und kann folglich nicht auf Betriebssystemebene etwas ändern (etwa ein spezielles Treiber-Update einspielen). Microsoft steuert die Plattform zentral, was einerseits Entlastung bedeutet, andererseits den Verlust mancher Low-Level-Kontrolle. Für viele Unternehmen ist das ein gewünschter Trade-off, da konsistente Updates und definierte SLAs vieles vereinfachen. Dennoch muss man intern die Zuständigkeiten neu justieren: z.B. wer reagiert, wenn Azure eine Wartung durchführt, welche Monitoring-Parameter man noch selbst beobachten muss (dazu später mehr im Monitoring-Abschnitt).

Feature-Nähe und Kompatibilität: Azure SQL Database basiert auf der neuesten stabilen Version der SQL Server-Engine – die meisten T-SQL-Funktionen und Datenbankfeatures verhalten sich identisch zu einer aktuellen SQL Server Edition. Dennoch gibt es einige Unterschiede bzw. Lücken, insbesondere im Vergleich zu einem vollumfänglichen on-premises SQL Server auf Instanz-Ebene. Azure SQL Database bietet keine SQL Server-Agent-Komponente innerhalb der DB: Geplante Jobs können daher nicht per sp_start_job aus der DB selbst gestartet werden. Stattdessen gibt es alternative Ansätze (Azure Elastic Jobs als Cloud-Service für Job-Scheduling über mehrere DBs, oder Nutzung von Azure Automation/Runbooks oder Logic Apps, um Jobs auszuführen). Azure SQL Managed Instance hingegen hat den SQL Server-Agent an Bord – bestehende Agent-Jobs können meist unverändert weitergenutzt werden, was ein großer Vorteil bei Migrationen ist. Linked Server und verteilte Abfragen: Azure SQL Database erlaubt es nicht, via sp_addlinkedserver klassische Linked Server auf andere Datenquellen einzurichten. Cross-Database-Queries mit Dreipunkt-Notation (server.datenbank.schema.tabelle) sind in Azure SQL DB ebenfalls nicht direkt möglich, da jede DB isoliert ist (workaround: sogenannte External Tables über Elastic Query, um eine andere Azure-SQL-DB im gleichen Server zu referenzieren). Managed Instance schließt diese Lücke größtenteils: Innerhalb einer MI können Sie datenbankübergreifende Abfragen durchführen (alle Datenbanken liegen auf derselben Instanz, ähnlich wie mehrere DBs auf einem on-prem SQL Server). Auch Linked Servers werden in MI unterstützt, allerdings mit Einschränkungen: Man kann z.B. einen Linked Server zu einem anderen SQL Server (on-prem oder VM) einrichten, sofern die Netzwerkkonnektivität gegeben ist, aber keine auf features basierenden Linked Server zu Azure SQL DB, da Azure SQL DB keine eingehenden Linked-Server-Verbindungen akzeptiert. CLR (Common Language Runtime)-Assemblies sind in Azure SQL Database nicht gestattet – Code in .NET innerhalb der DB auszuführen ist also nur via MI möglich (dort kann man CLR nutzen, jedoch ohne Zugriff auf das Dateisystem, und es muss explizit aktiviert werden). xp_cmdshell und andere erweiterte Prozeduren, die Zugriff auf das OS benötigen, sind in keiner PaaS-Variante erlaubt – in Managed Instance sind diese standardmäßig deaktiviert und weitgehend gesperrt, da ein direktes OS-Konzept für den Kunden nicht existiert. Server- und Instanzkonfigurationen: In Azure SQL Database gibt es konzeptionell keine Server-Instanz, an der man z.B. sp_configure mit bestimmten Flags setzen könnte. Einige Einstellungen sind auf Datenbankebene möglich (via ALTER DATABASE SCOPED CONFIGURATION, z.B. für MAXDOP, Query Store etc.), aber global-instanzweite Einstellungen entfallen. Managed Instance bietet hier mehr Vertrautheit – viele sp_configure-Optionen stehen zur Verfügung, aber nicht alle (Azure könnte bestimmte Einstellungen vorgeben, etwa weil sie die stabilen Betriebsparameter der Service-Umgebung betreffen). Funktionsparität insgesamt: Azure SQL Database deckt den Großteil üblicher Datenbankfunktionen ab (Transaktionen, Prozeduren, In-Memory-OLTP, Partitionierung, Columnstore, Temporal Tables, Change Tracking, sogar Change Data Capture in höheren Tiers). Einige Microsoft-Features wie PolyBase zur direkten Abfrage externer Datenquellen fehlen jedoch (PolyBase erfordert zusätzliche Services, die in Azure SQL DB nicht installierbar sind – Alternativen sind hier Azure Data Factory oder Logik über andere Dienste). Azure SQL MI wiederum unterstützt PolyBase derzeit auch nicht, ermöglicht aber Hosting der SSIS-DB und Ähnliches (Integration Runtime in Data Factory). Auch SQL Server Analysis Services (SSAS) oder Reporting Services (SSRS) sind nicht Bestandteil von Azure SQL – hier gibt es eigenständige Azure-Angebote (Azure Analysis Services bzw. Power BI Paginated Reports). MI vs. Azure VM vs. on-prem: Ein SQL Server auf Azure-VM ist von den Features nahezu 100% identisch zu on-premises SQL Server, da es das gleiche Produkt ist – Sie können also alles installieren und konfigurieren, was Sie on-prem auch könnten (inkl. veraltetem Legacy-Code oder Third-Party-Extensions). Diese Freiheit besteht bei PaaS nicht; dafür bringt PaaS neuartige Cloud-Features (z.B. ohne Downtime die Datenbank auf neuere Engine-Versionen migrieren, KI-gestützte Performancevorschläge etc.), die on-prem nur mit Aufwand umsetzbar wären. Unterm Strich sollte bei der Entscheidungsfindung analysiert werden, welche speziellen SQL-Features benötigt Ihre Anwendung wirklich? – Fehlen wichtige Punkte in Azure SQL DB, ist MI oft die Lösung. Falls sogar MI nicht alle exotischen Anforderungen deckt, bleibt die VM-Option.

Skalierung & Storage vs. klassisches Sizing: In on-premises Umgebungen wird die Leistungsfähigkeit einer SQL Server-Instanz stark von der gewählten Hardware bestimmt – CPU-Anzahl/Takt, RAM-Größe, und besonders Storage-IOPS (z.B. RAID-Level, SSD vs. HDD, SAN-Kapazität). Man dimensioniert einmal und muss bei steigenden Anforderungen Hardware nachrüsten, was zeit- und kostenintensiv ist. In Azure SQL erfolgt Skalierung on-demand und größtenteils per Klick oder Skript. Azure SQL Database kann z.B. in Minuten auf das Doppelte der vCores hochgefahren werden, wohingegen on-prem ggf. neue Server beschafft werden müssten. Storage-Kapazität lässt sich ebenfalls dynamisch erhöhen, oft ohne Downtime (bis zum Maximalwert des Tiers). IOPS und Durchsatz sind in Azure SQL an die gewählten Service Tiers gekoppelt: Im General Purpose-Tier werden Daten auf Azure Premium Storage abgelegt, das pro bereitgestellter Datenmenge gewisse IOPS-Limits hat (z.B. liefert eine 1-TB-Datenbank eine bestimmte garantierte IO-Performance; mehr IOPS erfordern größeren Speicher oder den Wechsel ins Business Critical-Tier mit local SSD). Das Business Critical-Tier hat lokale SSDs und mehrere Replikate, was sehr hohe I/O-Raten und niedrige Latenzen ermöglicht – analog einem on-premises Server mit direkt angeschlossenen NVMe-SSDs. Hyperscale entkoppelt Compute und Storage völlig: Schreib-IO wird über ein verteiltes Log Service abgewickelt, Lese-IO über speicherresidenten Page-Server – dies erlaubt linear zu skalieren, aber hat leicht höhere Lese-Latenzen als lokale SSD (ein Designtradeoff). On-premises dagegen kann man theoretisch unbegrenzt IOPS erreichen, wenn man entsprechend viele und schnelle Disks einbaut – jedoch praktisch ist man durch Budget und physische Grenzen limitiert und solche Änderungen sind nicht spontan. Azure SQL gibt klare IOPS-/Durchsatzwerte pro Tier vor, so weiß man, was man bekommt. Skalierungsgrenzen: Azure SQL Database (vCore) unterstützt aktuell bis 128 vCores pro DB und je nach Tier bis 128 TB (Hyperscale). Managed Instance geht bis 128 vCores pro Instanz und 16 TB (bald 32 TB). SQL auf VMs kann je nach VM-Größe auch in diese Regionen vordringen (z.B. eine M-Serie VM mit 128 vCPUs und TB-weise RAM). Dennoch ist die Herangehensweise anders: In PaaS skaliert man lieber breiter aus (mehrere Dienste, Sharding, etc.), während on-prem oft vertikal skaliert wurde bis zum nächsten physischen Limit. Speicherverwaltung: In Azure SQL muss man sich nicht mit Storage-Pools, LUNs oder NTFS auseinandersetzen – man konfiguriert einfach die benötigten GB. Das System verteilt Daten und Log sinnvoll auf die Infrastruktur. Auf einer VM hingegen ist der Admin wieder für die optimale Storage-Konfiguration zuständig (Stripe-Sets, Cache-Einstellungen, etc.). Bottom Line: Azure SQL bringt flexibilitätsbezogen große Vorteile beim Skalieren, aber man muss die vorgegebenen Leistungslimits kennen und beim Sizing berücksichtigen. Workloads, die z.B. extrem hohe einzelne Transaktionsraten erfordern, müssen im passenden Tier laufen – die Cloud hat Limits, die man on-prem durch Überprovisionierung von Hardware sonst absichern würde.

Betriebs- und Governance-Implikationen: Durch den Plattform-Ansatz ändern sich auch einige Betriebsabläufe und Richtlinien. Kostensteuerung ist ein Aspekt: On-premises laufen Server oft 24/7, ob genutzt oder nicht, da die Kosten fix sind. In Azure kann und sollte man Dienste abschalten oder verkleinern, wenn sie nicht gebraucht werden, um Geld zu sparen. Azure SQL Database bietet dafür den Serverless-Betrieb oder zumindest eine einfache API, um etwa abends die Leistung herunterzufahren und morgens wieder hoch (für Dev/Test-Umgebungen oder weniger kritische Systeme). Managed Instance hatte traditionell keinen Auto-Pause-Modus, aber inzwischen gibt es eine Stop/Start-Funktion – Administratoren können eine MI manuell anhalten (stoppen), z.B. übers Wochenende, wodurch nur noch Speicher statt teure vCores berechnet werden. Generell ermöglicht Azure eine feinere Granularität der Kosten (bis auf Stundenbasis), während on-prem oder VM Ressourcen immer laufen, wenn sie laufen. Allerdings erfordert dies auch Prozesse, um diese Möglichkeiten zu nutzen (z.B. Skripte/Automation für zeitgesteuertes Skalieren). Monitoring verschiebt sich: Ein on-prem DBA nutzt vielleicht PerfMon auf dem Server oder Agent-Warnungen. In Azure SQL kommen Azure Monitor Metriken (CPU%, DTU%, Speicher-IO, Log-IO, etc.), Intelligent Insights (automatische Erkennung leistungshungriger Abfragen) und Query Store vermehrt zum Einsatz. Man hat keinen low-level Zugriff auf OS-Counters, aber umfangreiche Telemetrie über DMVs und Azure-Logs. Limitierungen und Quotas müssen ebenfalls in den Betriebsrichtlinien beachtet werden: Beispielsweise hat eine einzelne Azure SQL DB eine maximale Anzahl gleichzeitiger Verbindungen und eine Transaktionslog-Ausgaberate – bei ungeplanten Lastmustern könnten diese Limits erreicht und dann Anfragen verzögert oder abgelehnt werden. Im Vorfeld sollte man also prüfen, ob Workloads in das gewählte Tier passen (z.B. hohe Bulk-Load-Raten vs. log throughput limit). Azure veröffentlicht Quotas (z.B. 30.000 gleichzeitige Verbindungen pro Datenbank, 32 GB TempDB pro vCore im Hyperscale etc.). Eine Umstellung ist hier oft mental: Das „Server“-Konzept verschwimmt bei Azure SQL DB – man managt primär Datenbanken als Ressource. Dinge wie Naming-Konventionen und Ressourcengruppen in Azure werden relevanter, damit man den Überblick behält, welche DB zu welcher Anwendung gehört, wer verantwortlich ist, etc. Rolle der IT-Governance: Da vieles per Self-Service (Portal/CLI) in Minuten geändert werden kann, sind Kontrollmechanismen ratsam: z.B. Azure Policy, um nur bestimmte Regionen oder VM-Typen zuzulassen, oder Tagging-Konventionen, um Kostenstellen zuzuordnen. Anders als on-prem, wo ein Procurement-Prozess eine Hürde darstellt, kann in Azure schnell jemand eine große MI instanziieren – hier braucht es Leitplanken (Budgetlimits, Freigabe-Workflows) damit Cloud-Vorteile nicht zu Wildwuchs führen. Zusammengefasst bringen Azure SQL PaaS-Dienste erhebliche Vereinfachungen im täglichen Betrieb, setzen aber ein Umdenken in Verwaltung und Überwachung voraus, um den vollen Nutzen zu ziehen und Risiken zu managen.

4. Lizenzierung & Kostenmodelle

Azure SQL Verbrauchsmodelle (vCore vs. DTU): Die wichtigsten Azure SQL Angebote (Database und Managed Instance) verwenden heute das vCore-Modell. Ein vCore („virtueller Kern“) repräsentiert eine abstrahierte CPU-Einheit (angelehnt an einen Hardware-Thread) inklusive zugeordnetem Arbeitsspeicher. Man wählt z.B. 4 vCores und erhält damit eine bestimmte Menge RAM (abhängig vom Service Tier) und IO-Leistung. Abgerechnet wird dann pro vCore und Zeiteinheit (Stundenbasis). Dieses Modell ist empfehlenswert, da es transparente Performance (vergleichbar mit CPU/RAM on-prem) bietet und Flexibilität bei Kombinationen (z.B. bestimmte Anzahlen vCores mit mehr oder weniger Speicher je nach Tier). Das ältere DTU-Modell fasste CPU, Memory und IO in einen pauschalen Einheitwert (z.B. S3 = 100 DTUs). Es vereinfachte zwar anfangs die Cloud-Einstiegsüberlegung („klein, mittel, groß“ Tier), war aber intransparent bezüglich tatsächlicher Leistung. DTUs kommen fast nur noch in Azure SQL Database Basic/Standard/Premium Tiers vor und in deren entsprechenden Elastic Pools. Microsoft hat klargestellt, dass für neue Projekte das vCore-Modell bevorzugt genutzt werden sollte. Nur wenn ein bestehendes System bereits exakt mit DTUs läuft und zufriedenstellend performt, könnte man es belassen – oder wenn man einen sehr kleinen Single-DB-Use-Case hat, in dem die Einfachheit der DTU-Level ausreichend ist. Langfristig jedoch wird vCore als Standard angesehen.

Provisioned vs. Serverless (Azure SQL Database): Innerhalb des vCore-Modells von Azure SQL Database gibt es zwei Betriebsarten: Provisioned bedeutet, dass der Dienst stets die volle konfigurierte Kapazität reserviert bereithält – Sie zahlen also für z.B. 8 vCores auch dann, wenn die DB gerade nichts zu tun hat. Diese Variante ist sinnvoll für kontinuierlich belastete oder geschäftskritische Datenbanken, wo jederzeit konsistente Leistung verfügbar sein muss. Serverless hingegen erlaubt es, die vCores automatisch zu skalieren: Man gibt einen minimalen und maximalen Wert vor (z.B. min 0,5 vCores, max 4 vCores). Azure passt dann laufend die zugeteilte CPU/RAM an die aktuelle Last an. Bei Inaktivität fällt die DB nach einer definierbaren Wartezeit in den Pause-Modus – in dieser Zeit werden keine Compute-Kosten berechnet (nur minimaler Speicherplatz für die DB-Dateien). Sobald ein neuer Query kommt, „wacht“ die DB auf und skaliert wieder hoch (was typischerweise einige Sekunden bis ca. eine Minute dauern kann – der sogenannte Kaltstart, währenddessen der erste Benutzer warten muss). Die Abrechnung im Serverless-Modus erfolgt granular nach tatsächlich verbrauchter CPU pro Sekunde. Vorteile: erhebliche Kosteneinsparungen, wenn die Nutzung z.B. nur stundenweise am Tag oder sehr ungleichmäßig ist. Nachteile: ein leichtes Performance-Latenz beim Hoch- und Runterskalieren und potenziell etwas geringere Maximalperformance, da Memory zwischendurch freigegeben wird und der Buffer Cache nach einer Pause leer ist (d.h. die ersten Zugriffe kommen von der Festplatte). Für viele Entwicklungs-, Test- oder sporadisch genutzte Anwendungen ist Serverless ideal. Für Produktion mit konstantem 24/7-Traffic bleibt Provisioned meist die bessere Wahl, um Predictability zu gewährleisten. Azure SQL Managed Instance bietet derzeit keinen automatischen Serverless-Betrieb; hier ist immer Provisioned, wobei – wie oben erwähnt – man neuerdings Instanzen manuell stoppen kann, um Kosten zu sparen, aber kein automatisches Pausieren erfolgt.

Elastic Pools: Speziell in Multi-Tenant-Szenarien oder bei vielen kleineren Datenbanken können Azure SQL Database Elastic Pools helfen, Kosten und Leistung effizienter zu gestalten. Im Pool legt man eine gewisse Anzahl vCores (oder im DTU-Modell ein Pool-Level, z.B. 100 eDTUs) fest, und bis zu Hunderte von Datenbanken teilen sich diese Ressourcen nach Bedarf. So können Peaks einzelner DBs abgefedert werden, solange nie alle gleichzeitig Maximalleistung ziehen. Wichtig dabei ist, passende Poolgrößen und Pool-Zusammenstellungen zu finden: z.B. 50 kleinere Kunden-Datenbanken, die im Schnitt wenig tun, könnte man in einen gemeinsamen Pool packen, statt 50x einzeln Leistung vorzuhalten. Kostenvorteil: Man bezahlt den Pool (z.B. 8 vCores) anstatt 50x 1 vCore einzeln – was erheblich günstiger sein kann, wenn die Auslastungsprofile asynchron sind. Pools erlauben auch eigene eDTU/vCore-Limits pro DB zu setzen, um zu verhindern, dass eine einzelne DB den ganzen Pool monopolisiert. Azure SQL Managed Instance hat kein Multi-Mandanten-Pool-Konzept – dort entspricht eine Instanz gewissermaßen einem Pool für die darin liegenden DBs (alle DBs teilen sich ja die Instanz-Ressourcen). Für MI gibt es aber das Konzept der Instanz-Pools: mehrere kleinere Managed Instances können sich einen Hardware-Host teilen, was für ein Enterprise, das viele Instanzen betreibt, Kosten sparen kann – dies ist allerdings ein spezieller Fall (nur in bestimmten Größen verfügbar) und eher für Szenarien gedacht, wo man z.B. 10 MI mit je 4 vCores effizienter als 10 einzelne MI betreiben will.

Hyperscale und Sonderfälle: Das Hyperscale-Tier in Azure SQL Database hat eine eigene Preismetrik: Man zahlt pro zugewiesenem Compute-Knoten (die sogenannten Replicas – mindestens 1 für den Primärknoten, plus optional weitere Read-Replicas). Jede hat vCore-Kosten. Der Speicher wird separat nach tatsächlich belegten GB berechnet (und wächst mit der Datenmenge). Dadurch fallen Kosten linear mit Datenwachstum an, aber man muss keine sprunghaften teuren Sprünge (wie bei Business Critical ab 1 TB Limit) befürchten. Hyperscale ist preislich oft attraktiv für große Datenbanken, weil man nicht für zig ungenutzte vCores zahlen muss, nur um mehr Speicher zu bekommen. Allerdings sollte man beachten, dass zusätzliche Read-Replicas in Hyperscale volle Compute-Kosten verursachen (eine 2. Replica verdoppelt quasi den vCore-Teil der Rechnung). In Standard-Tiers ist dagegen ein Read-Secondary bei Business Critical inklusive.

Kaufoptionen in Azure: Standardmäßig laufen Azure-Dienste im Pay-as-you-go-Modell – d.h. es gibt einen festen Stundensatz pro vCore (bzw. pro DTU), der auf die Nutzung angewendet wird. Für langfristig benötigte, dauerlaufende Datenbanken kann man via Reserved Capacity Kosten reduzieren: Hierbei verpflichtet man sich, eine bestimmte Anzahl vCores für 1 Jahr oder 3 Jahre zu bezahlen. Die Bezahlung kann upfront oder monatlich erfolgen, aber sie ist unabhängig von der tatsächlichen Nutzung – ob Sie die Datenbank nutzen oder nicht, die Kapazität ist reserviert (Use it or lose it). Dafür liegen die Preise deutlich unter Pay-as-you-go (1 Jahr ca. 30% Rabatt, 3 Jahre bis ~45% Rabatt auf den vCore-Preis). Wichtig: Reservierungen sind an Region und Leistungsklasse gebunden – z.B. “4 Business Critical vCores in West Europe”. Man kann diese zwar innerhalb der Region auf verschiedene DBs anwenden (wenn man etwa 2 DBs mit je 2 vCores betreibt, greift eine 4er-Reservation auf beide), aber nicht auf andere Regionen oder andere Servicefamilien übertragen. Sollte sich Bedarf ändern, erlaubt Azure begrenzt Austausch von Reservierungen (z.B. Upgrade auf mehr vCores mit anteiliger Neuberechnung) oder Stornierung (gegen Gebühr). Neben Reservierungen gibt es den Azure Hybrid Benefit (AHB): Dies ist eine Lizenzoption, keine Leistungsvorausbuchung. AHB kann man nutzen, wenn man vorhandene SQL Server-Lizenzen mit aktiver Software Assurance (SA) besitzt oder entsprechende Abonnements (z.B. SQL in SPLA oder bestimmte Abos). In Azure kann man dann beim Erstellen einer Azure SQL DB/MI/VM angeben “Lizenz vorhanden”. Dadurch entfällt der Lizenzkostenanteil im Azure-Preis. Für SQL Server Enterprise Edition Lizenz mit SA können Sie z.B. eine Azure SQL Database Business Critical oder eine MI General Purpose mit dem günstigeren Base Rate betreiben – je nach Lizenztyp lassen sich sogar pro Lizenz mehrere vCores abdecken (Enterprise erlaubt 4 vCores Standard Edition oder 1 vCore Enterprise Edition pro Lizenz-Core). Wichtig ist, dass AHB nicht automatisch angewendet wird – man muss im Portal oder via Script die Option aktivieren und selbstverständlich sicherstellen, dass die Lizenzrechte ausreichen und nicht doppelt genutzt werden (Lizenz Compliance bleibt in Ihrer Verantwortung). AHB und Reserved Instances sind kombinierbar – so erzielen Sie die maximalen Einsparungen, indem Sie mit AHB die Lizenzkosten abziehen und mit Reserved die Infrastruktur vergünstigen. Für Entwicklungs- und Testumgebungen stellt Microsoft darüber hinaus spezielle Dev/Test-Abonnements bereit: Diese erlauben die Nutzung von Azure SQL zu stark reduzierten Kosten, da davon ausgegangen wird, dass non-produktive Workloads laufen. Voraussetzung ist in der Regel, dass Ihr Unternehmen über Visual-Studio-Abonnements (MSDN) verfügt und die Azure Subscription als Dev/Test deklariert wird. In solch einem Fall können z.B. Azure SQL Instanzen ohne Lizenzkosten betrieben werden (ähnlich dem AHB, aber explizit für nicht-produktiven Gebrauch, sodass MS darauf vertraut, dass keine Produktivdatenbanken darüber laufen). Auch eigenständige SQL Developer Edition auf Azure-VMs wäre eine Option für Tests (diese Edition ist kostenlos, darf aber nicht produktiv eingesetzt werden).

Kostentreiber identifizieren: Die Gesamtkosten einer Azure SQL Lösung setzen sich aus mehreren Komponenten zusammen. Hauptfaktor ist meist der Compute-Preis – also Anzahl vCores * Preis pro vCore-Stunde * Nutzungsdauer. Ein kontinuierlicher 24/7-Betrieb von 4 vCores resultiert in ~730 Stunden pro Monat Abrechnung. Wenn Sie hingegen nur 180 Stunden im Monat (z.B. Geschäftszeiten) nutzen, zahlen Sie entsprechend weniger (sofern Serverless oder manuelles Stoppen genutzt wird). Der zweite Faktor ist der Speicher: Für Datenfiles und ggf. log werden pro belegtem GB monatliche Raten berechnet. In vielen Tiers ist ein gewisses Kontingent an Speicher inklusive (z.B. X GB pro vCore); zusätzlicher Speicher wird dann extra berechnet. Auch Backup Storage kann relevant werden: Die Point-in-Time-Wiederherstellungs-Backups bis 7/35 Tage sind oft bis zu 100% der Datenbankgröße gratis (d.h. solange Ihre DB 100 GB hat und Sie nicht mehr als 100 GB an kumulierten Backups haben, zahlt man nichts). Aber insbesondere Long-Term Retention (LTR) und sehr lange Aufbewahrung erzeugen Speicherbedarf, der in Rechnung gestellt wird. Wenn Sie z.B. 5 Jahre lang jeden Monat einen 100 GB Backup aufbewahren, kommen 60 * 100 GB = 6.000 GB an Speicher zusammen, die mit ein paar Cent pro GB/Monat berechnet werden – auf Dauer spürbar. I/O-Profile treiben die Kosten indirekt: Zwar bezahlt man bei Azure SQL nicht direkt pro I/O (kein separater IO-Meter), aber das Workloadprofil beeinflusst die notwendige Leistungsstufe. Ein IO-lastiges System wird ggf. den Wechsel ins teurere Business Critical nötig machen, was Kosten erhöht. Netzwerk-Egress: Ein oft übersehener Kostenpunkt. Daten, die aus Azure herausfließen (z.B. aus der DB übers Internet zum Endbenutzer oder per ExpressRoute ins on-prem Rechenzentrum), verursachen Azure-typische Datenausgangsgebühren pro GB. Hohe Exportvolumina (Backups aus Azure herunterladen, große Resultsets regelmäßig extern weiterleiten) können so zusätzliche Kosten erzeugen. Datenverkehr innerhalb derselben Azure-Region ist kostenfrei, ebenso eingehende Daten. Geo-Replikation hingegen erzeugt interregionale Transfers, die als Egress berechnet werden. Hochverfügbarkeits- und Read-Replikate: Bei Azure SQL zahlt man in der Regel für zusätzliche regionale Replikate den vollen Preis (eine aktive Geo-Secondary ist eine eigenständige Datenbankinstanz mit gleichen vCores, ergo denselben Kosten wie die Primärinstanz). Ausnahme: der genannte Read-Secondary im Business Critical Tier (gleiche Region) ist inbegriffen. Trotzdem: wer aus Gründen der Lastverteilung 3 zusätzliche Read-Replicas in Hyperscale betreibt, vervierfacht seine Compute-Kosten. Dies sollte bewusst einkalkuliert werden. Zusatzservices: Eventuell kommen weitere Kosten aus dem Umfeld hinzu, etwa Azure Traffic Manager / Front Door für globale Endpoint-Verteilung bei Multi-Region-Deployments, oder Azure Monitor Log Analytics Kosten für umfangreiche Telemetriedaten über die DBs. Diese sind zwar nicht direkt Teil der „SQL-Rechnung“, aber im Gesamtbild relevant.

Beispielkalkulation: Als grobe Formel kann man sich Monatskosten etwa so vorstellen:

Monatskosten ≈ (vCores × Stunden × vCore-Preis) + (genutzter Speicher in GB × Speicher-Preis) + (Backup/LTR-Speicher in GB × Backup-Preis) + (Anzahl zusätzlicher Replikate × jeweilige vCore-Kosten) + (Datenabgang in GB × Egress-Tarif).

In Worte: Eine Azure SQL Datenbank mit bestimmter Größe und Laufzeit summiert aus Compute-Zeit, Speicherplatz und optionalen Posten ihre Kosten. Für ein genaues Angebot nutzt man am besten den Azure Pricing Calculator, aber IT-Entscheider sollten das Grundprinzip – laufende nutzungsabhängige Betriebskosten statt einmaliger Investition – verinnerlichen. Wichtig: Durch Reserved Capacity und Azure Hybrid Benefit kann der (vCores × Stunden × vCore-Preis) Anteil drastisch sinken (bis >50% Ersparnis möglich). Diese Rabatte lohnen, sobald man absehen kann, dass eine Instanz lange laufen wird und man entsprechende Lizenzen besitzt.

Governance der Kosten: Mit der Cloud entstehen neue Möglichkeiten, die Kosten aktiv zu steuern. Ein paar bewährte Praktiken: Budget setzen und überwachen: In Azure Cost Management kann man monatliche Budgetlimits definieren und Warnungen erhalten, falls Ausgaben diese erreichen. So behält man Überraschungen im Blick. Tags verwenden: Alle Azure SQL-Ressourcen (Server, MI, einzelne DBs) können mit Tags versehen werden (z.B. Environment=Prod/Test, Department=Finance, Project=XYZ). Das ermöglicht eine saubere Zuordnung von Kosten im Reporting und vereinfacht Aufteilungen an Geschäftsbereiche. Auto-Pause und Auto-Scale nutzen: Für wenig genutzte Datenbanken aktivieren Sie serverless mit kurzer Auto-Pause-Dauer (z.B. 1 Stunde oder inzwischen bis minimal 15 Minuten möglich) – die Einsparungen sind erheblich, wenn die DB oft längere Zeit idle ist. Zeitgesteuertes Skalieren: Wenn Workloads vorhersehbare Zyklen haben (z.B. Reporting-DB braucht Ende des Monats mehr Leistung), kann man per Automation runbook oder Azure Functions den Tier hoch- und wieder runtersetzen nach einem Zeitplan. Oder Entwickler-Testumgebungen jeden Abend abschalten und morgens anschalten per Skript. Übergrößen vermeiden: In der Cloud ist „Reserve für alle Eventualitäten“ teuer – Provisionieren Sie nicht prophylaktisch doppelt so viel, sondern starten Sie knapp und erhöhen bei Bedarf. Die Skalierbarkeit macht dies möglich, man muss nicht wie on-prem Überkapazität für 3 Jahre im Voraus kaufen. Überwachen und Nachjustieren: Prüfen Sie vierteljährlich, ob Reservierungen optimal genutzt werden, ob vielleicht eine DB komplett idle war (und man sie löschen/zusammenlegen kann), ob neue Features wie auto-stop für MI verfügbar sind und Nutzen bringen, etc. Cloud-Kostenoptimierung ist ein kontinuierlicher Prozess, für den es in großen Unternehmen sogar dedizierte FinOps-Teams gibt. Ihr Ziel sollte sein, die Vorteile der Cloud – variable Kosten an tatsächliche Nutzung anpassen – voll auszuschöpfen, was diszipliniertes Vorgehen erfordert.

5. Vergleichstabelle

Nachfolgend eine kompakte Gegenüberstellung der vier besprochenen Varianten: Azure SQL Database, Azure SQL Managed Instance, SQL Server auf Azure-VMs und klassischer SQL Server on-premises. Diese Tabelle hilft, die wichtigsten Kriterien für Entscheidungen nebeneinander abzuwägen:

6. Fünf typische Einsatzszenarien

Im folgenden Kapitel betrachten wir fünf repräsentative Anwendungsszenarien für Azure SQL. Jedes Szenario wird mit Ausgangslage, empfohlener Azure-SQL-Variante und praktischen Hinweisen von der Architektur bis zum Betrieb durchgespielt. So erhalten IT-Entscheider ein Gefühl, welches Azure-SQL-Modell sich wann anbietet und worauf besonders zu achten ist.

Szenario 1: Cloud-native OLTP-Anwendung mit schwankender Last (Azure SQL Database, serverless/Elastic Pool)

A) Ausgangslage & Ziele: Ein Software-Startup entwickelt eine neue webbasierte OLTP-Anwendung (Online Transaction Processing) – beispielsweise eine Plattform für Event-Buchungen. Die Anwendung läuft komplett in der Cloud und soll ohne großen Infrastrukturaufwand weltweit verfügbar sein. Da mit Werbekampagnen und Saisonalität zu rechnen ist, wird das Lastprofil sehr volatil sein: Phasen mit tausenden Transaktionen pro Minute können auf Phasen minimaler Nutzung folgen. Gleichzeitig ist schnelles Time-to-Market wichtig, das Team will sich primär auf die Implementierung von Features konzentrieren und möglichst wenig mit dem Datenbankbetrieb beschäftigen. Kosten sollen sich der Nutzung anpassen, da Umsätze anfangs unsicher sind. Das Ziel ist also eine skalierbare, wartungsarme Datenbanklösung, die Lastspitzen automatisch handhabt und in ruhigen Zeiten kostengünstig ist.

B) Empfohlene Azure-SQL-Variante + Begründung: Für dieses Szenario bietet sich Azure SQL Database im Serverless-Betrieb an. Diese Option erfüllt den PaaS-Gedanken voll – das Team muss keine Server administrieren, und Azure kümmert sich um Patching, Backups etc. Serverless erlaubt es zudem, Lastspitzen dynamisch abzufangen, ohne dauerhaft für Spitzenleistung zahlen zu müssen. In Stoßzeiten skaliert die Datenbankautomatik z.B. von 1 vCore auf bis zu 8 vCores hoch; bei geringer Nachfrage sinkt sie auf nahezu 0 (und pausiert komplett, falls konfiguriert). Dadurch werden Betriebskosten direkt an die Nutzung gekoppelt, was das Budget schont. Alternativ – falls die Anwendung multi-tenant ausgelegt ist, also z.B. pro Kunde eine eigene Datenbank nutzt – käme ein Elastic Pool mit mehreren Azure SQL Databases in Frage. Im Elastic Pool könnte man z.B. 50 Kunden-Datenbanken hosten, die sich Ressourcen teilen, um effizient mit den unterschiedlichen Nutzungsmustern umzugehen. Beide Ansätze (Serverless für eine DB oder Pools für viele) minimieren den Betriebsaufwand und bieten hohe Elastizität. Azure SQL Database deckt alle Standard-OLTP-Funktionen ab; besondere SQL-Features, die eventuell fehlen (Agent-Jobs, Cross-DB Abfragen), sind in einem Cloud-Neubau ohnehin nicht relevant, da die App neu entwickelt wird und entsprechend gebaut werden kann, um diese nicht zu benötigen. Außerdem passt Azure SQL gut ins DevOps-Konzept: Das Team kann per Azure CLI/ARM Templates die DB Deployment automatisieren, und Entwicklungstools wie EF Core arbeiten problemlos damit.

C) Referenzarchitektur (Kurzbeschreibung): Die Zielarchitektur könnte wie folgt aussehen: Die Anwendung läuft auf Azure App Services oder in Containern auf Azure Kubernetes Service (AKS). Die Azure SQL Database (serverless) fungiert als transaktionaler Datenspeicher. Eine Azure Private Endpoint Integration stellt sicher, dass die Kommunikation zwischen App und DB intern im Azure-Netzwerk bleibt (für höhere Sicherheit, optional). Für globale Reichweite könnte die App auf mehrere Regionen verteilt werden, wobei jede Region eine eigene Azure SQL Database hat, die entweder über Geo-Replikation synchronisiert oder partitioniert betrieben wird (in diesem Szenario vorerst vermutlich nur eine Region, Multi-Region käme später). Azure Key Vault speichert die DB-Zugangsdaten (Connection-Strings), sodass keine Credentials im Code liegen. Durch Query-Optimierung in der App (ORM-Tuning etc.) wird die Last auf der DB minimiert, aber wenn Last kommt, kann Azure SQL automatisch parallel mehr Compute bereitstellen. Die Architektur verzichtet bewusst auf virtuelle Maschinen oder komplexe Netzwerke – es ist alles serverless/PaaS, was schnelle Implementierung und kontinuierliche Deployment-Pipelines (CI/CD) begünstigt. Skalierung der App-Schicht (App Service Plan hoch/runter, AKS Knoten skalieren) und der DB-Schicht (vCores automatisch) erfolgen unabhängig, aber koordiniert nach Last. Diese Referenzarchitektur ermöglicht es, mit kleinem Footprint zu starten (z.B. minimal 0,5 vCores, die kaum Kosten erzeugen) und im Erfolgsfall linear mit dem Bedarf zu wachsen.

D) Migration & Betrieb: Da es sich um eine neu entwickelte Anwendung handelt, gibt es keine Altdatenbank zu migrieren – der Fokus liegt auf dem initialen Aufbau und anschließendem reibungslosem Betrieb. In der Entwicklungsphase wird vermutlich eine separate Azure SQL Database (oder ein weniger stark dimensioniertes Tier) in einer Dev- und Test-Umgebung verwendet. Infrastructure as Code (IaC) kommt zum Einsatz, um alle Komponenten (inkl. DB-Server, Firewallregeln, Ausführungsmodus serverless etc.) reproduzierbar bereitzustellen – z.B. via Azure Resource Manager (ARM) Templates oder Terraform. Im Betrieb profitiert man stark von Azure SQLs Automatisierung: Backups sind konfiguriert, Punkt-in-Time Restore könnte bei einem Fehler schnell erfolgen (das Team sollte das zumindest einmal pro Quartal üben, z.B. Test-Datenbank wiederherstellen um zu sehen, wie lang es dauert). Das Monitoring wird über Azure Monitor eingerichtet: Metriken wie DTU-/CPU-Auslastung, Arbeitsspeicher und vor allem Auto-Pause/Resume Events gilt es zu verfolgen. Gerade bei Serverless ist das Thema Kaltstart im Blick zu behalten – die Entwickler implementieren ein einfaches Warm-Up, z.B. ein regelmäßiger Ping an die DB, falls man absolute Minimallatenz braucht. Application Insights auf der App-Seite misst ebenfalls DB-Abfragezeiten, so erkennt man, wenn z.B. nach einer Pause eine Verzögerung auftritt. Insgesamt ist der Betrieb weitgehend hands-off: Microsoft sorgt für Verfügbarkeit, im Falle von Patches wird eventuell eine kurze Wiederverbindung nötig sein – daher sollte die App eine robuste Verbindungslogik mit Retries haben. Das Team konzentriert sich auf Schema-Updates via DevOps-Pipeline (z.B. DACPAC Deployments), Performance-Analysen (die Query Performance Insight im Azure Portal kann z.B. die top CPU-Verbraucher zeigen) und natürlich das Handling der Applikationslogik. Durch die PaaS-Natur sind Deployments ins nächste Azure-Rechenzentrum oder Skalierungen nach oben bzw. unten schnell getestet und durchgeführt, was Agilität im Betrieb verleiht.

E) Kostenhebel: In diesem Cloud-nativen Szenario lassen sich die Kosten sehr fein steuern. Der größte Hebel ist die Serverless-Automatik selbst: Sie sorgt dafür, dass bei Null-Last faktisch keine Compute-Kosten anfallen. Wichtig ist, die Auto-Pause-Delay sinnvoll zu setzen – z.B. 1 Stunde. Wenn die Anwendung nachts kaum genutzt wird, pausiert die DB und spart ~8 Stunden * vCore-Kosten pro Tag, was ~1/3 des Tagespreises einspart. Sollte doch ein steter Strom an Minimal-Requests vorhanden sein (z.B. regelmäßiges Pollen), könnte man im Code diese reduzieren, um Pausen zu ermöglichen. Ein weiterer Hebel ist die Maximale vCore-Zahl: Setzt man sie passend (z.B. 4 vCores bei erwartetem Peak von 3 vCores Last), verhindert man unnötig hohe Skalierung darüber (die nur Kosten erzeugen würde, falls mal ein Ausreißer-Query käme). Wenn die Anwendung wächst und Last planbarer wird, könnte man überlegen, vom reinen Serverless auf einen kleinen Provisioned Elastic Pool umzusteigen, falls man mehrere DBs hat, oder auf ein Reserved vCore Modell, sollte die Auslastung ab einem gewissen Punkt quasi permanent hoch sein – das wäre jedoch erst bei signifikantem Wachstum (stabiler Vollauslastung) der Fall. Für den Start sind Pay-go und Serverless optimal. Reserved Capacity könnte man mittelfristig nutzen: z.B. sobald klar ist, dass mindestens 4 vCores Last tagsüber immer gebraucht werden, lohnt ein 1-Jahres-Reservierung für 4 vCores (ca. 30% Ersparnis auf diesen Anteil). Da Startups oft unsichere Zukunft haben, würde man Reservierungen anfangs meiden. Azure Hybrid Benefit ist hier nicht relevant, da vermutlich keine bestehenden SQL-Lizenzen vorliegen (das Team setzt auf die included license). Ein weiterer Kostenfaktor, den man beachten sollte: Datenausgang. Wenn diese OLTP-App viele Daten an Kunden-Apps oder Reporting-Tools außerhalb von Azure sendet, entstehen Egress-Kosten. Lösung: möglichst App und DB in derselben Region halten und Clients nah an Azure haben (im Idealfall läuft alles serverseitig in Azure und nur Endnutzer ziehen minimal Daten). Und zuletzt: Die Logik für Backups – standard 7-14 Tage PITR sind kostenfrei für moderate DB-Größe, aber sollte das Team aus Compliancegründen LTR aktivieren (z.B. Monatsbackups für 1 Jahr), steigt der gespeicherte Datenumfang. Hier kann man Kosten reduzieren, indem man nicht zu viele LTR-Punkte wählt (vielleicht quartalsweise statt monatlich, falls zulässig) und regelmäßig ausmistet, was nicht mehr gebraucht wird.

F) Risiken & Gegenmaßnahmen: Trotz aller Vorteile gibt es einige Risiken in diesem Szenario: Performance-Risiko: Durch die automatischen Skalierungs- und Pausevorgänge könnten Latenzspitzen auftreten (z.B. erster Benutzer morgens wartet 30 Sekunden auf DB-Resume). Gegenmaßnahme: im Frontend oder durch leichte Keep-Alive-Jobs (sofern vertretbar) solche Pausen bewusst steuern, oder falls das nicht reicht, den min. vCore-Wert etwas höher setzen, um die DB nie ganz kalt werden zu lassen. Kostenrisiko: Theoretisch könnte eine unerwartete Dauerlast (z.B. Bug im Code, Endlosschleife) die DB konstant hochtakten und Kosten verursachen. Hier hilft Azure Budget Alerts – wenn z.B. monatliche Kosten plötzlich über Prognose steigen, wird das Finance/DevOps-Team alarmiert und kann reagieren (vielleicht Performanceproblem fixen). Skalierungsgrenzen: Auch Serverless hat Limits (max 16 vCores Stand heute). Falls ein viraler Erfolg die Last weit darüber treibt, müsste man kurzfristig auf ein höheres Tier (Provisioned General Purpose mit mehr vCores oder Business Critical) wechseln – das erfordert dann kurze Downtime. Das Team sollte Monitoring so aufsetzen, dass es frühzeitig erkennt, wenn Auslastung dauerhaft an der Obergrenze kratzt, um proaktiv skalieren zu können. Security/Compliance: Gerade Startups könnten geneigt sein, sich rein auf Azure-Defaults zu verlassen. Risiko: offener DB-Endpoint im Internet, schwaches Passwort. Gegenmaßnahmen: Gleich von Anfang an Private Endpoint oder strenge Firewallregeln nutzen, AD-Authentifizierung aktivieren, und Security-Center-Empfehlungen folgen. Damit bleibt die Datenbank sicher. Lock-in-Bedenken: Eventuell fragen Investoren, was passiert, wenn man Cloud wechseln oder on-prem gehen will. Lösung: Datenbankschema standardisiert halten, notfalls regelmäßige Bacpacs exportieren. Für den laufenden Betrieb aber kein akutes Thema. Insgesamt ist Szenario 1 mit Azure SQL Database serverless gut beherrschbar und bringt enorme Agilitätsvorteile für die jungen OLTP-Anwendung.

Szenario 2: Modernisierung bestehender SQL-Instanzen mit hoher Feature-Nähe (Azure SQL Managed Instance)

A) Ausgangslage & Ziele: Ein mittelständisches Unternehmen betreibt bislang mehrere SQL Server-Instanzen on-premises, die über Jahre gewachsen sind. Darauf laufen interne Anwendungen (z.B. ein ERP-System, eine Buchhaltungs-DB, selbst entwickelte Reporting-Tools), teils stark verzahnt mit SQL-Server spezifischen Funktionen. So werden beispielsweise SQL Agent-Jobs genutzt, um nächtlich Daten zu aggregieren, es gibt Cross-Database Views zwischen den Datenbanken, und einige Anwendungen nutzen sogar CLR-basierten Code für Spezialberechnungen. Die Hardware ist in die Jahre gekommen, ein Rechenzentrums-Refresh steht an. Gleichzeitig gibt es den Wunsch der Geschäftsleitung, in die Cloud zu gehen, um langfristig Wartungskosten zu sparen und von höherer Ausfallsicherheit zu profitieren. Die Ziele sind: Lift & Shift der bestehenden Datenbanken mit minimalem Codeänderungsaufwand, Outsourcing der Basis-Administration (HW, Backups, Patching), aber Beibehaltung möglichst aller SQL-Features, die die Anwendungen aktuell nutzen. Downtime für die Migration soll so kurz wie möglich sein, da die Systeme geschäftskritisch sind. Compliance-Vorgaben erlauben Cloud grundsätzlich, solange Netzwerkschutz und Verschlüsselung gewährleistet sind.

B) Empfohlene Azure-SQL-Variante + Begründung: Hier drängt sich Azure SQL Managed Instance (MI) als die optimale Variante auf. MI wurde genau für solche “Hebt-und-schiebt”-Szenarien entwickelt, in denen eine SQL-Server-Instanz nahezu unverändert in Azure betrieben werden soll. Im Gegensatz zur Single Database PaaS bietet MI fast volle SQL Server-Kompatibilität: Der SQL Server Agent ist verfügbar, was bedeutet, dass die existierenden Agent-Jobs (z.B. Wartungspläne, ETL-Jobs) weiterhin laufen können – eventuell nach geringfügiger Anpassung der Verbindungsstrings, aber kein komplettes Neuentwickeln. Cross-Database-Abfragen innerhalb der Instanz funktionieren wie gewohnt, sodass keine aufwendige Umstellung auf z.B. externe Tabellen nötig ist. Sogar CLR-Assemblies können (nachdem man sie neu in MI registriert hat) weiterverwendet werden, da MI das Laden von .NET-Code (unter bestimmten Sicherheitsrichtlinien) erlaubt. Darüber hinaus ermöglicht MI Netzwerkintegration in das Firmennetz, was für viele Bestandsanwendungen wichtig ist – z.B. falls Applikationsserver noch on-prem bleiben, können diese über VPN auf die MI zugreifen, als wäre es ein interner SQL Server (gleiches Protokoll, gleiche Ports). Damit können wir das Ziel “Cloud ja, aber möglichst keine Änderungen für Applikationen” erreichen. MI übernimmt Patchen, Backup und Hochverfügbarkeit, so entlasten wir die DBAs deutlich, behalten aber wichtige Kontrollpunkte: man kann z.B. ein Wartungsfenster definieren, oder bestimmte Instanz-Einstellungen (Collation, MAXDOP global) setzen, was bei Single DB nicht ginge. Alternativ käme nur SQL Server auf Azure-VM in Frage, aber dann würde man die gesamte Serverwartung weiter selbst machen müssen – also mehr Aufwand. MI ist ideal, weil es PaaS-Entlastung mit on-prem-Ähnlichkeit kombiniert. Zudem bietet MI die Möglichkeit, via Azure Hybrid Benefit vorhandene Lizenzen mitzunehmen, was das Unternehmen kostenseitig nutzen kann, da es sicherlich SQL Server Lizenzen mit Software Assurance besitzt. Auch in Sachen Performance kann MI überzeugen: es stehen ähnliche Ressourcen zur Verfügung wie ein dedizierter Server (bis 128 vCores), und im Business Critical-Tier bekommt man lokale SSD-Performance, falls nötig. Summiert: MI erfüllt die Kernbedingung “möglichst gleiche Funktionalität, minimalinvasive Migration”.

C) Referenzarchitektur (Kurzbeschreibung mit Komponenten): In der Zielarchitektur werden die bisherigen on-premises SQL Server Instanzen schrittweise durch Azure SQL Managed Instances ersetzt. Wahrscheinlich wird man pro bisherigem SQL-Server eine entsprechende MI bereitstellen, um die gleiche Trennung nach Instanzen zu haben (man könnte auch mehrere on-prem Instanzen in einer MI konsolidieren, falls sinnvoll, aber oft hält man 1:1 Entsprechungen bei). Diese MIs werden innerhalb eines Azure Virtual Network in einem Subnetz (genannt Managed Instance Subnet) bereitgestellt. Über eine VPN-Verbindung oder ExpressRoute sind das Firmenlan und das Azure-VNet gekoppelt, sodass alle bestehenden App-Server weiterhin via internen IPs die Datenbank erreichen. Aus Applikationssicht ändert sich nur der Servername (z.B. sqlmi-prod.company.local statt bisher sql01.intern.local – man kann ggf. DNS so konfigurieren, dass es transparent bleibt). Falls die Anwendungen ebenfalls nach Azure wandern, könnte man z.B. App-Services oder Azure VMs in dasselbe VNet setzen – wichtig ist: MI kommuniziert stets übers private Netzwerk. In puncto Sicherheit wird Network Security Groups (NSGs) auf dem MI-Subnetz eingesetzt, um nur die erlaubten Quellen (App-Subnetze, bestimmte on-prem IP-Ranges) durchzulassen. Azure Private DNS löst den MI-Namen auf die interne IP auf. Für die Verwaltung kann der DBA via SSMS über eine Jumpbox-VM oder per On-Prem-PC (über VPN) die MI ansprechen – die bekannten Tools funktionieren (SSMS, Azure Data Studio etc.). In der Architektur wird man auch Azure Monitor mit Log Analytics integrieren, damit die MI Diagnostikdaten (Logs, Deadlocks, CPU, etc.) ähnlich wie früher im eigenen Monitoring, jetzt in Azure gesammelt werden. Key Vault kann für Rotation von Verbindungskennwörtern eingesetzt werden. Für HA ist MI out-of-the-box in einer Azure Region redundant. Falls ein Geo-DR gewünscht ist, würde man eine zweite MI in einer anderen Region einrichten und eine Failover Group konfigurieren (z.B. Primary MI in “North Europe”, Secondary MI in “West Europe”). Dadurch stünde im Notfall eine synchronisierte Kopie aller DBs bereit. Somit umfasst die Architektur: On-premises oder Azure-basierte App-Server -> Netzwerk (VPN/ExpressRoute) -> Azure VNet mit MI -> optional zweites Region VNet mit MI (DR). Das Design stellt sicher, dass bestehende Anwendungsteile (z.B. ein altes .NET-Framework-Frontend auf einem Windows Server) weiter genutzt werden können und mit minimalen Konfigurationsänderungen einfach auf die Cloud-DB zugreifen.

D) Migration & Betrieb: In der Migrationsphase müssen zunächst Kompatibilitätsprüfungen erfolgen. Hier kommt das Data Migration Assistant (DMA) Tool ins Spiel: Es scannt eine vorhandene SQL Server Instanz und meldet Inkompatibilitäten oder Features, die in MI nicht unterstützt werden. Typische Punkte könnten sein: Verwendung von FILESTREAM (wird in MI nicht unterstützt), Verwendung von veralteten System-Prozeduren, oder extreme Logins/Serverrollen, die angepasst werden müssen. Aufgrund der hohen MI-Kompatibilität wird aber in den meisten Fällen nur wenig Kritisches gefunden. Das Unternehmen plant dann die Datenübertragung. Für moderate DB-Größen kann man evtl. ein einfaches Backup auf URL und Restore in MI durchführen (MI erlaubt RESTORE DATABASE … FROM URL = ‚Azure Blob‘). Ist die Datenmenge groß und die Downtime begrenzt, bietet Microsoft den Managed Instance Link: Wenn die on-prem SQL Server Version 2019+ ist, könnte man eine Distributed Availability Group zwischen dem on-prem Server und MI einrichten, wodurch die Daten nahezu in Echtzeit synchron gehalten werden. Dadurch lässt sich ein Minimale Downtime Cutover realisieren – man initiiert einen kontrollierten Failover auf die MI, wenn alles repliziert ist, und die Clients verbinden sich dann zur MI. Alternativ kann auch Azure DMS (Database Migration Service) im Online-Modus genutzt werden, der im Hintergrund kontinuierlich Änderungen mit synchronisiert und dann umschaltet. Die Downtime reduziert sich so auf Sekunden/Minuten, was für geschäftskritische Anwendungen ideal ist. Nachdem die Datenbanken auf MI laufen, wird noch sichergestellt, dass alle SQL Agent Jobs migriert sind. Der DBA kann via Skript die Jobs aus msdb auslesen und auf MI anlegen – oft funktioniert das 1:1, solange Pfade etc. stimmen. Falls ein Job bisher z.B. eine exe auf dem Server gestartet hat (via CmdExec), muss man hier umdenken, da MI keine lokale Pfadausführung kann – solche Jobs müssten auf Azure Automation oder andere Dienste ausgelagert werden. Im Betrieb übernimmt MI nun Patches und Backups, aber das Unternehmen sollte dennoch Überwachungen einrichten: z.B. Alerts, wenn ein Job fehlschlägt (lässt sich via DB Mail nicht machen, da MI kein DB Mail hat – stattdessen Telemetrie / Azure Monitor Alarm verwenden). Performance-Monitoring: MI bietet Query Store und Performance Insights, der DBA kann diese nutzen wie gewohnt. Zudem sollte man evtl. das Azure SQL Analytics Workbook aufsetzen, um Verlaufsdaten zentral zu speichern. Da MI immer eine komplette Instanz repräsentiert, wird man pro MI die Ressourcenauslastung beobachten (ähnlich wie CPU/RAM on-prem). Skalieren geht einfacher: Wenn absehbar wird, dass 8 vCores GP nicht reichen, initiiert man in einem Wartungsfenster eine Skalierung auf 16 vCores – MI führt das mit minimaler Downtime durch (paar Sekunden Verbindungsabbruch). Der Betrieb wird somit planbarer, Upgrades passieren ohne dass die DBAs Nachtschichten einlegen müssen – MI updates werden von Azure gemanagt. Für die DBAs ändert sich die Rolle: Weg von “Server am Laufen halten” hin zu “Optimierung, Kapazitätsplanung, Sicherheitskontrolle”. Sie sollten auch neue Azure-Features ausnutzen, etwa Auto-Tuning für Indexe (MI unterstützt manche autonomen Tuning-Funktionen, wie automatische Index-Empfehlungen, was on-prem manuell war). Als neue Routine kommt ggf. das Kostenmonitoring hinzu – vorher fielen SQL-Kosten als amortisierte Serverhardware an, jetzt sieht man monatlich die Azure-Beträge. Das Finanzteam will sicher Reports, also sollte IT engmaschig nachverfolgen, wie sich z.B. nach Migration die Kosten vs. Nutzen entwickeln, und ggf. optimieren (z.B. über Reservierung oder AHB-Einsatz, s.u.).

E) Kostenhebel: In diesem Szenario hat das Unternehmen bereits SQL-Lizenzen – darum unbedingt Azure Hybrid Benefit aktivieren: Für eine MI mit etwa 8 vCores Enterprise Edition benötigt man 8 on-premises Core-Lizenzen mit aktiver SA, um den vollen AHB-Vorteil zu erhalten (Enterprise erlaubt pro Core einen vCore in MI Business Critical oder 4 vCores in GP, je nach Nutzung – hier würden sie vermutlich Enterprise nutzen wegen Features, also 1:1). AHB reduziert sofort die Azure-Rechnung um den Lizenzanteil (kann ~30-40% ausmachen). Weiterer Hebel: Reserved Capacity. Da diese Datenbanken dauerhaft laufen werden, macht eine 3-Jahres-Reservierung Sinn, sofern das Unternehmen die Cloud-Strategie langfristig festlegt. Drei Jahre Reserved bringen nahe 35-40% Rabatt auf den Compute-Teil. Kombiniert mit AHB erreicht man so ggf. ~65% Gesamtersparnis gegenüber dem Listen-Preis, was erheblich ist. Natürlich bindet man sich damit – aber beim Modernisieren einer Kern-Infrastruktur hat man ja ohnehin einen mehrjährigen Planungshorizont. MI hat keinen auto-pause, aber falls z.B. Nicht-Produktivinstanzen existieren (Test/QA), kann man überlegen diese Abends und am Wochenende manuell zu stoppen (neue Stop/Start-Funktion), um Kosten zu sparen. Das sollte dann automatisiert werden, damit es nicht vergessen geht (Azure Automation: abends “Stop MI” – morgens “Start MI”). Durch Stop zahlt man nur Storage, keine Compute-Stunden – ideal für Dev/QA, die nachts nicht gebraucht werden. Ein weiterer Kostenfaktor: Business Critical vs. General Purpose. Das Unternehmen sollte genau prüfen, ob alle MI in der teureren Business Critical Edition laufen müssen. BC bietet niedrigere Latenz (lokale SSD), hochverfügbare Sync-Replikate und einen Read-Secondary. Wenn die Workloads aber primär Standard-OLTP mit moderaten IO sind, kann General Purpose ausreichen, was deutlich günstiger ist. Evtl. wird nur für die ganz anspruchsvollen DBs (z.B. ERP mit hohen Transaktionsraten) eine BC-MI gewählt und die restlichen auf GP belassen. MI erlaubt Mischbetrieb indirekt, indem man unterschiedliche Instanzen einrichtet. Größenoptimierung: Anders als on-prem kann man mit MI auch mal testweise runter skalieren: Vielleicht stellt sich raus, dass 8 vCores nur 30% ausgelastet sind – dann kann man auf 4 vCores reduzieren und schauen, ob Performance ok bleibt, womit Kosten halbiert werden. Solche Rightsizings sollte man nach einigen Monaten Daten ziehen durchführen. Außerdem Konsolidierung: Wenn man vorher 5 SQL Server betrieben hat mit je halber Hardware-Auslastung, könnte man jetzt eventuell 2 MI statt 5 betreiben und mehrere DBs zusammenlegen (sofern keine Konflikte). Weniger Instanzen = weniger Grundkosten. Hier aber Vorsicht, dass nicht Applikationen dadurch gestört werden; es ist eine Option, um Overhead zu verringern. Backup und LTR: Die LTR-Policen sollte man kostenbewusst setzen – z.B. behält man vielleicht auf MI nicht mehr jede wöchentliche Sicherung 10 Jahre, sondern nur Quartalsweise, um Storage-Kosten gering zu halten, sofern das die Compliance zulässt. Insgesamt bietet Azure viele Stellschrauben, mit denen die laufenden Kosten im Zaum gehalten werden können, wenn man die initiierten Migrationseinsparungen maximieren möchte.

F) Risiken & Gegenmaßnahmen: Bei einer Migration auf Managed Instance gibt es einige Risiken, die adressiert werden sollten: Kompatibilitätsrisiko: Trotz hoher Kompatibilität kann es sein, dass einzelne Funktionen nicht laufen – etwa ein in SQL Server 2005 deprecated Feature, das on-prem noch ging, aber Azure SQL blockiert. Beispiel: Verwendung von UNSAFE CLR oder Extended Stored Procedures. Lösung: Vorher umfangreich testen. Einsatz einer Pilotmigration mit Tests aller wichtigen Geschäftsprozesse. DMA-Berichte gründlich auswerten. Ggf. Microsoft oder einen Migrationsexperten hinzuziehen bei Spezialfällen. Netzwerk/Latenz-Risiko: Verbindungen zu MI laufen übers Internet/VPN – Latenzen können höher sein als im lokalen LAN. Anwendungen, die sehr latenzempfindlich sind (Chatty DB-Calls über WAN) könnten Performanceprobleme bekommen. Gegenmaßnahme: Möglichst Applikationsserver mit in Azure ziehen (Data Gravity), oder ExpressRoute für stabil niedrigere Latenz implementieren. In der Entwicklung kann man Tools wie Azure Network Emulator (AzPing) nutzen, um Latenzen vorab zu messen. Betriebsprozess-Umstellung: DBAs müssen sich an neue Tools gewöhnen. Manche On-prem-Methoden (Profiler, PerfMon) gehen nicht mehr. Hier droht Risiko, dass Probleme anfangs übersehen werden, weil Monitoring nicht optimal eingestellt ist. Gegenmaßnahme: Schulung der DBAs in Azure-Tools, gemeinsame Erarbeitung neuer Runbooks, u.a. wie man in Azure “Fehler sucht”. Sicherheitsrisiko: MI bringt neue Aspekte (z.B. wer darf Azure-Admin der MI sein?). Man sollte aufpassen, keine Überprivilegierung zu machen – oft wird anfangs der einfachheit halber ein generisches Admin-Konto genutzt. Besser: Azure AD Admin als Gruppe definieren, regelmäßige Überprüfung der Logins in MI, etc. Und: Alte Logins (Windows Auth) müssen auf Azure AD umgestellt werden oder in SQL Auth persistieren – falls man das vergisst, könnten User ausgesperrt sein. Hier hilft viel Testing. Kostenrisiko: Es kann vorkommen, dass nach Migration die Azure-Kosten höher sind als gedacht (vielleicht weil man aus Performancevorsicht große MIs wählte). Das Management könnte überrascht reagieren. Daher: Transparenz vorab schaffen, TCO rechnen, und nach Migration optimieren. Oft zeigt sich, dass durch Wegfall von on-prem Aufwänden (HW, Strom, Personalstunden) die Cloud-Kosten okay sind – aber das muss belegt werden. Lock-in/Exit: Wenn MI genutzt wird, was ist, wenn man unzufrieden ist? MI bietet zwar Backup heraus, aber ein Rückweg on-prem ist etwas aufwendiger (Backup von MI laden erfordert gleichwertige SQL-Version etc.). Das sollte aber kein großes Risiko sein, sofern man plant zu bleiben – dennoch kann man vorausschauend regelmäßige Backups extern sichern, um im worst case wieder On-prem gehen zu können. Funktionsstand: Der ständig aktualisierte Engine in MI kann auch bedeuten, dass Änderungen (neue Version, verändertes Abfrageverhalten) früher eintreffen als on-prem. Risiko, dass Abfragen plötzlich anderen Plan nehmen. Mit Query Store und plan forcing kann man hier notfalls eingreifen, aber DBA müssen wachsam sein, wenn Azure ein Major-Update macht (Ankündigungen lesen!). Alles in allem minimiert MI die Migrationsrisiken verglichen mit einem kompletten Redevelopment, dennoch erfordert sie sorgfältige Planung und Tests, damit der Übergang reibungslos gelingt.

Szenario 3: Leistungsintensive Spezial-Workloads mit voller OS/SQL-Kontrolle (SQL Server auf Azure-VMs, BYOL/AHB)

A) Ausgangslage & Ziele: Ein Unternehmen aus dem Finanzsektor betreibt ein Data Warehousing-System, das stark angepasst ist: Der SQL Server hostet eine über Jahre gewachsene DWH-Datenbank (> 5 TB), nutzt speziell konfigurierte TempDB auf gestreiften NVMe-SSDs, hat bestimmte Trace Flags aktiviert und sogar ein Drittanbieter-Backup-Tool im Einsatz, das auf dem Server installiert ist. Zusätzlich laufen auf demselben Server ETL-Prozesse in SSIS und eine Instanz von SQL Server Analysis Services (SSAS) für OLAP. Kurz: ein komplexes, hochperformantes Setup, bei dem jeder Aspekt feinjustiert wurde. Das Rechenzentrum-Vertrag des Unternehmens läuft aus, man will aber ungern an der bewährten Softwarearchitektur viel ändern – zu riskant und zu teuer, da auch externe Dienstleister dran hängen. Trotzdem möchte man von Cloud-Vorteilen profitieren: Bessere Skalierbarkeit (z.B. mal testweise mehr RAM geben können), keine Sorgen um Hardwaredefekte, und den Azure-Backbone für globale Erreichbarkeit. Außerdem lockt, dass man per Azure leichter Test- und Dev-Umgebungen klonen könnte (Snapshots von VMs etc.). Das Ziel ist also, diesen Spezial-Workload in Azure zu hosten, aber möglichst 1:1 die Umgebung abzubilden, einschließlich aller Freiheiten bei Konfiguration und Zusatzsoftware. Performance darf nicht schlechter werden – im Idealfall eher besser durch neueste VM-Typen. Und es bestehen bereits umfangreiche SQL Server Enterprise-Lizenzen, die man weiterverwenden will.

B) Empfohlene Azure-SQL-Variante + Begründung: Für dieses Szenario ist SQL Server auf Azure-VM (IaaS) die richtige Wahl. Nur ein VM-basiertes Deployment bietet die volle Kontrolle über Betriebssystem und SQL Server-Instanz. Alle Spezialanpassungen – vom eigenem TempDB-LAYOUT über spezifische Windows-Einstellungen (Lock Pages in Memory etc.) bis zum Einsatz von SSIS/SSAS auf dem gleichen Host – sind ausschließlich in einer VM-Umgebung möglich, da PaaS-Dienste solch einen Coupled-Betrieb nicht erlauben (Azure SQL MI z.B. unterstützt kein SSAS oder kundenseitige Softwareinstallation). Mit einer Azure-VM kann man die gleiche SQL Server Version und Patchstand betreiben, wie man möchte – wenn die jetzige On-Prem-Version z.B. 2016 ist und man (aus Anwendungskompatibilitätsgründen) noch nicht upgraden will, geht das in einer VM weiter so. Man kann die VM-Größe so wählen, dass sie ausreichend CPU/RAM hat und via Premium- oder Ultra-Disks die nötige IO liefert (Azure bietet speziell optimierte VM-Serien wie Lsv2 mit sehr hohem Disk-Durchsatz, die hier relevant wären). Azure Hybrid Benefit kann angewandt werden, um die vorhandenen Lizenzen zu nutzen (BYOL), was lizenzkostenseitig attraktiv ist. Ein weiterer Vorteil: Die Admins behalten ihre vertrauten Tools und Skripte – der Übergang ist minimal, da es eben “ihr Server” bleibt, nur im MS-Rechenzentrum. Zielerreichung: The workload kriegt Cloud-Vorteile (schnelles Hardware-Ändern, Hochverfügbarkeit via Azure Mechanismen, globaler Zugang) aber man muss an der Architektur nichts fundamental neu erfinden. Zwar gehen gewisse PaaS-Annehmlichkeiten verloren (kein automatisches Patching), aber angesichts der Komplexität wäre PaaS hier eh nicht passend oder würde zu starke Kompromisse erfordern. Daher ist die IaaS-Variante klar angezeigt.

C) Referenzarchitektur (Kurzbeschreibung mit Komponenten): Die Architektur wird mehrere Azure-Komponenten umfassen: Im Kern steht eine Azure Virtual Machine (oder mehrere) mit installiertem SQL Server. Angesichts der Performance-Anforderungen wählt man z.B. eine VM-Größe der Lasv3-Serie (hoher Durchsatz NVMe, viele vCPUs) oder Ev5-Serie (viel RAM pro vCPU), je nach ob CPU- oder Memory-Bottlenecks vorherrschen. Die VM läuft in einem Azure VNet, Subnetz mit passender NSG (Port 1433 etc. offen nur für App-Subnetze). Da es sich um einen einzelnen wichtigen Server handelt, wird man für Verfügbarkeit sorgen: Entweder die VM wird in einer Availability Zone platziert (Azure garantiert dann, dass bei AZ-Ausfall ein Recovery möglich ist), oder es wird gleich eine Always On Availability Group mit zwei VMs in unterschiedlichen Zonen aufgebaut. Nehmen wir an, hier wird eine Windows Failover Cluster (2 Knoten) mit AG aufgebaut, um HA und ggf. ein lesbares Secondary zu haben. Für Backups kann man Azure Backup nutzen (speziell VM-Level Backup oder SQL-spezifisches Backup via Azure Backup Service), oder man behält das bewährte Drittanbieter-Backup und speichert Backups in Azure Blob Storage. Datendisks: die VM bekommt mehrere Premium SSD Managed Disks oder Ultra Disks (für das Daten- und Logvolume), um die IOPS und Durchsatz-Anforderungen zu erfüllen. z.B. 4x P30 (je 5000 IOPS) im Storage Pool für Data, 2x P20 für Logs, etc. Dies muss entsprechend dimensioniert und getestet werden. Die Referenzarchitektur beinhaltet auch optional einen Azure Load Balancer (für eine Always On Listener IP falls AG), und Azure Monitor Agent auf der VM, um Performancecounter, Logs etc. an Log Analytics zu senden. Die VMs werden in einer Verfügbarkeitsgruppe oder -zone betrieben, und ein Recovery Services Vault ist konfiguriert, falls man Azure Backup für schnelle VM-Wiederherstellung nutzen will (z.B. bei Komplettausfall). Zusätzlich kann ein Azure Automation Account eingerichtet werden, um Patch-Management oder Start/Stop-Scripts (z.B. nightly maintenance) orchestriert durchzuführen. Die Anwender greifen – wie gehabt – via die Applikationsserver oder BI-Tools auf die SQL-Server-FQDN zu, nur dass dieser jetzt auf die Azure VM zeigt. In Summe sieht das aus wie eine on-premises High-End SQL Cluster Umgebung, nur dass die “Hardware” in Azure steckt. Bei Bedarf kann diese Architektur in Zukunft leichter skaliert werden: z.B. neue VM-Size wählen, mehr Disks anfügen, oder weitere Read-Replicas in Azure (in AG). Das Ganze ist jedoch klar eine kundenspezifische Lösung auf IaaS, mit vielen konfigurierbaren Teilen, und nicht schlüsselfertig wie PaaS.

D) Migration & Betrieb: Die Migration dieses Systems in eine VM ist relativ geradlinig, aber erfordert sorgfältige Planung, da es geschäftskritisch ist. Eine Möglichkeit: Azure Site Recovery (ASR) – man könnte die physische Maschine (oder VM) per ASR kontinuierlich in Azure replizieren und dann einen geplanten Failover ausführen. Das hätte minimalen Ausfall (ASR synchronisiert letzte Änderungen, dann cutover). Alternativ: Backup & Restore – man nimmt ein volles Backup vor, stellt es auf dem Azure-VM SQL Server wieder her. Oder, falls es eilt, man baut eine Always On Replikation auf: z.B. richtet man die Azure VM als neuen Knoten im On-Prem-AG ein, lässt ihn sync werden, dann führt man ein Failover durch, Azure ist neuer Primary, und dann trennt man On-Prem ab. Nach Migration gilt es, die neue Umgebung intensiv zu testen: Stimmt die Performance? Sind alle Konfigurationen (TempDB, Collation, etc.) identisch? Wurden möglicherweise beim Umzug Pfade geändert (z.B. UNC-Pfade in Jobs) und müssen angepasst werden? Der Betrieb auf Azure-VM erfordert weiterhin die typischen DBA-Aufgaben: Windows und SQL Patchen – hier kann man aber Azure Update Management nutzen, um Patches zu orchestrieren, oder Wartungsfenster definieren in denen Azure (mit dem Automanage Service) Updates einspielt. Monitoring bleibt umfassend nötig: Die IT kann aber Tools wie Azure Monitor / Log Analytics einsetzen, die out-of-the-box Metriken aus VMs sammeln (z.B. PerfCounter für CPU, Memory, Disk IO, plus SQL Server Telemetrie via OMS Solutions). Man kann auch bestehende Monitoring-Lösungen (SCOM, Splunk etc.) weiter nutzen, indem man die Agents auf der VM installiert. Backup-Strategie: Entweder weiter mit dem bestehenden Tool – dann in Azure anpassen, dass es z.B. auf Azure Blob speichert. Oder Azure Backup für SQL: hier würde ein Backup-Agent DB-spezifische Backups in Vault laden. Wichtig: die Recovery Strategie definieren – evtl. sind zweite Region Offsite-Backups sinnvoll, oder ein Kaltstandby im anderen Region. Im laufenden Betrieb kann man experimentieren, ob neue Azure-Features helfen: z.B. Accelerated Networking auf der VM aktivieren (reduziert NIC Latenz), oder Proximity Placement Groups falls VM und App-VM eng beieinander stehen sollen. Man hat vollen Zugriff auf OS, also kann man Feintuning betreiben (z.B. BIOS-ähnliche Einstellungen, VMware-Analogien entfallen, aber Azure erlaubt einige Tuning wie CPU Pinning in speziellen VMs etc.). Skalierung im Betrieb muss man manuell anstoßen: z.B. in einem Wartungsfenster VM herunterfahren, auf nächstgrößere Größe hochskalieren, wieder starten (das kann 10-15 Minuten dauern). Oder, wenn man Always On hat, Rolling Upgrade von Knoten: erst Secondary größer machen, failover, dann anderen größer machen – geht mit minimaler Auszeit. Das Team sollte Dokumentation pflegen, da nun eine neue Infrastruktur im Spiel ist (Azure-spezifische Feinheiten, z.B. Disk Throttling, die es on-prem so nicht gab). Kostenüberwachung ist wichtig: Abrechnung kommt nun monatlich, und man muss drauf achten, dass z.B. VMs nicht aus Versehen in teurer Series laufen als nötig. Aber vor allem: ensure Performance stability – mit denselben Perf Counters vergleicht man, ob Azure alles packt. Falls nicht, kann man schneller reagieren (größere VM anfordern, statt On-Prem neue Hardware beschaffen). Für den Betrieb sind Tools wie Azure Advisor hilfreich – dieser gibt VMs-Empfehlungen (z.B. “Ihre VM ist nur 10% ausgelastet, evtl. downgraden”). So kann man fortlaufend optimieren.

E) Kostenhebel: Da IaaS in Azure die meiste Flexibilität, aber auch laufende Kosten mit sich bringt, sollte man diese gut optimieren: Erstens, Azure Hybrid Benefit (AHB) nutzen – das Unternehmen besitzt Enterprise SQL Lizenzen, vermutlich mit SA, also kann es in Azure VMs diese lizenzmäßig einsetzen. Bei Azure VM kann man beim Marketplace-Image entweder ein “SQL Server inklusive Lizenz”-Image wählen (pay-as-you-go-Lizenz) oder ein “Bring-your-own-license” Image. Das Unternehmen wählt BYOL und hinterlegt, dass es AHB nutzt. So zahlt es nur für die VM Compute/OS, nicht aber extra für SQL. Zweitens, Reserved Instances (RI): Gerade bei VMs, die 24/7 laufen, lohnt sich eine 3-Jahres-Reservierung massiv (bis ~40% auf VM-Preis). Man muss nur sicher sein, die VM (oder eine gleichartige in derselben Region) 3 Jahre zu betreiben. Hier ist man allerdings flexibler: Wenn man z.B. doch die VM-Größe wechselt, kann man die RI anpassen (Konvertieren oder stornieren mit etwas Verlust). Für einen Kern-DWH-Server ist 3Y RI aber fast gesetzt, man wird ihn so schnell nicht abschalten. Kombiniert mit AHB hat man dann die laufenden Cloud-Kosten gut reduziert. Drittens, Storage-Kosten optimieren: Ultra Disk vs. Premium Disk – Ultra bietet höhere IOPS gegen mehr Kosten. Vielleicht reichen Premium P30/60er Disks in Striping statt Ultra. Oder auch Azure Blob Storage für historische Daten auslagern (falls im DWH alte Partitionen selten benötigt werden, könnten sie in ein Data Lake verschoben werden). Auch Auto-Shutdown: Für Prod hier irrelevant (muss 24/7), aber für etwaige Dev/QA VMs könnte man Auto-Shutdown nachts aktivieren, um Compute zu sparen. Viertens, VM-Rechtegröße: Azure bietet VM-Advisor Tools – nach ein paar Wochen sollte man schauen, ob die VM überdimensioniert ist. Wenn CPU stets unter 20%, kann man eine kleinere wählen und Kosten sparen. Umgekehrt, wenn IO-Limit fast erreicht, vielleicht besser auf größere VM mit mehr Durchsatz wechseln, bevor es limitiert. Fünftens, Scaling out für Kosten?: Theoretisch könnte man schwankende Last damit abfangen, dass man an Spitzentagen eine zusätzliche VM ins AG nimmt und sonst herunterfährt – praktisch eher schwierig manuell. Meist wählt man feste sizing. Ein Trick: Falls es Batch-Fenster gibt, kann man VM kurzzeitig hochskalieren (Azure berechnet per Minute). Beispiel: Ein monatlicher ETL braucht viel CPU -> man erhöht VM-Size an dem Tag, danach wieder zurück, zahlt also die hohe SKU nur stundenweise. Das erfordert etwas Scripting aber ist machbar und kann Kosten verringern bei Peaks. Lizenzkosten sind mit AHB abgedeckt, aber beachten: SQL Enterprise erlaubt ein passives Secondary ohne zusätzliche Lizenz on-prem bei SA. In Azure VMs kann man das ähnlich auslegen – laut Microsoft darf ein offline Secondary (keine Nutzung außer Failover) auch unter AHB ohne extra Lizenz laufen. Trotzdem muss man da sauber lizenzieren. Wenn z.B. 16-Core License vorhanden, darf man 16 vCPUs Primary plus 16 vCPUs Secondary (passiv) betreiben. So kann man HA ohne doppelten Lizenzkostenaufwand haben. Das muss die IT mit Licensing Team klären, spart aber erheblich. Networking: Egress-Daten aus dem DWH (z.B. Berichte die extern gehen) könnten Gebühren erzeugen – hierfür ggf. Kompression oder Aggregation nutzen, sodass weniger Volumen rausgeht, oder Content näher bei den consumers cachen. Das beeinflusst zwar Cloud-Kosten minimal, ist aber Best Practice. Alles in allem sind VMs von den Cloud-Optionen am ehesten vergleichbar mit on-prem in Sachen Fixkostenlauf, aber Azure bietet immerhin Tools, diese nachträglich zu justieren, die man nutzen sollte.

F) Risiken & Gegenmaßnahmen: Bei IaaS-Workloads liegen viele Risiken analog zum on-prem Betrieb in Kundenhand: Betriebsrisiko: Ein Fehlkonfiguriertes OS (z.B. vergessen, Auto-Patch abzuschalten vor monatlichem Data Load) kann Ausfälle produzieren – daher exakte Betriebsprocedures definieren, wer was wann updatet. Sicherheitsrisiko: Eine VM, die ins Internet gelangt (z.B. wenn NSG falsch gesetzt, Port 1433 offen) kann Angriffsfläche sein. Unbedingt Netzwerk und Firewall korrekt einstellen, eventuell Azure Defender for Cloud aktivieren, das VMs auf Schwachstellen scannt. Performance-Risiko: Falls die gewählte VM oder Disk in Azure nicht die gleiche Performance liefert, kann das System leiden. Daher möglichst PoC vor produktiver Migration: Echte Lasttests auf vergleichbarer Azure VM durchführen. Azure Support kann Benchmarks an die Hand geben. Z.B. manchmal limitieren VMs IOPS per VM oder pro Disk – das muss zum Profil passen (in diesem Fall lieber mehr kleinere Disks stripen um Limit pro Disk auszuweiten). Kostenrisiko: VM laufen lassen ohne Optimierung kann teuer sein – was on-prem egal war (Server läuft halt), tut in Azure finanziell weh. Gegenmaßnahme: Cost Monitoring einrichten, z.B. Warnung wenn VM x unerwartet hohe Kosten erzeugt (kann passieren, wenn z.B. jemand versehentlich eine sehr große Instanz startet). Komplexitätsrisiko: Durch die Migration in Azure könnte man geneigt sein, “mal schnell” neue VMs, Testumgebungen etc. zu machen. Plötzlich gibt es mehrere Umgebungen – das kann Komplexität erhöhen. Um dem entgegenzuwirken, sollte man Infrastructure as Code auch hier einsetzen: VMs per ARM oder Terraform definieren, Standard-Images, sodass Reproduzierbarkeit da ist und man nicht versehentlich divergierende Setups hat. HA im Notfall: Wenn kein PaaS, liegt Failover in der Verantwortung der Admins. Also unbedingt Failover-Tests durchführen: z.B. bei Always On Simulieren, ob auch der Listener in Azure richtig reagiert, ob nach Zone-Failover die IP umschwenkt etc. Hier lernt man oft Feinheiten (z.B. Azure ILB for AG Listener muss so konfiguriert sein, dass probefunktion läuft). Tooling-Abhängigkeit: Das Drittanbieter-Backup und Tools müssen auch in Azure supported sein. Im Vorfeld klären: Ist die Version Cloud-kompatibel? Muss lizenziert werden auf Cloud-VM neu? Nicht dass hinterher Backups nicht gehen, weil das Tool den Blob Storage nicht ansprechen kann. Lock-In: Hier geringes Problem – es ist Standard-VM, die kann man auch wieder on-prem bringen, aber beachten: Datenvolumen (5TB) Transfer falls zurück muss, aufwändig. Plan: evtl. gelegentlich offsite backups on-prem lagern. Compliance: In Finanzsektor muss man Cloud-Einsatz genehmigen lassen (BaFin etc. in DE). MI und PaaS hätten komplexere Shared Responsibility Diskurse – bei VM kann man argumentieren, man kontrolliert OS. Dennoch, dokumentieren, dass Azure BSI-C5 etc. zertifiziert ist. Gegenmaßnahme: von Anfang an Compliance einbinden, Logging so einrichten, dass man Audit- und Zugriffsprotokolle hat (z.B. wer hat die VM administriert – Azure liefert Azure AD Based Access Logs). Summiert: Szenario 3 ist ein geringes Migrationsrisiko (technisch) aber erfordert weiterhin viel eigene Betriebsdisziplin*, eben wie ein normaler SQL Server, nur in neuer Umgebung.

Szenario 4: Multi-Tenant-SaaS mit tausenden Mandanten (Azure SQL Database + Elastic Pools + Hyperscale)

A) Ausgangslage & Ziele: Ein Softwareanbieter bietet ein Software-as-a-Service (SaaS)-Produkt an, z.B. eine CRM-Lösung für KMUs. Aktuell wird für jeden Neukunden eine separate Datenbank eingerichtet – on-prem waren das oft separate Schema in einer großen SQL-DB oder einzelne DBs auf einem Server. Die Kundenanzahl wächst rasant, man rechnet mit tausenden von Mandanten-Datenbanken in den nächsten Jahren. Problem on-prem: Man stößt an Serverlimits (max DBs pro Instanz) und es wird ineffizient – manche Kundendatenbanken sind winzig und selten genutzt, andere sehr aktiv, alle liegen aber auf gleicher Hardware. Das Unternehmen will in die Cloud, um diese hohe Mandantenzahl leichter zu managen und dynamisch Ressourcen zuzuteilen. Wichtige Anforderungen sind: Mandantentrennung (jeder Kunde isoliert, kein Zugriff untereinander), gute Skalierbarkeit auch bei Ausreißer-Kunden (wenn ein Kunde plötzlich deutlich wächst), und Automatisierung in Bereitstellung und Betrieb (neue Kunden-DB schnell anlegen, Upgrades synchron einspielen, Monitoring pro Tenant). Kosten sollen linear zur Kundenzahl skalieren – das heißt ein Modell, wo kleine inaktive Kunden fast nichts kosten, aber große aktive entsprechend mehr, aber möglichst ohne dass jeder Kunde dedizierte Fixkosten erzeugt. Zudem gibt es Kunden, die sehr große Datenmengen speichern (einige TB), was auf on-prem mit Standard Edition limitiert war. Man möchte also auch große Mandanten bedienen können ohne separate Spezialserver.

B) Empfohlene Azure-SQL-Variante + Begründung: Für dieses Szenario ist Azure SQL Database als einzelnes PaaS-DB-Modell ideal, in Kombination mit Elastic Pools und ggf. dem Hyperscale-Service-Tier. Azure SQL Database erlaubt es, jede Mandanten-Datenbank separat zu betreiben, aber zentral verwaltet über logische Server oder Pools. Mit Elastic Pools kann man Gruppen von Datenbanken bilden, die sich Ressourcen teilen – das passt perfekt, da erfahrungsgemäß nie alle Tausend Mandanten gleichzeitig Volllast erzeugen. So können z.B. 100 kleine Kunden-DBs auf einem Pool mit 8 vCores laufen, anstatt 100×1 vCore bereitzuhalten. Das erhöht die Ressourcenauslastungseffizienz erheblich und spart Kosten. Für die Handvoll sehr großer Mandanten (die vielleicht >500 GB oder sogar >1 TB Daten haben) wählt man das Hyperscale Tier: Diese Mandanten bekommen eigene DB-Instanzen in Hyperscale, damit sie praktisch unbegrenztes Wachstum haben und gute Performance auch bei hoher Größe (Hyperscale hat Vorteile wie schnelleres Backup, mehrere read-scale nodes falls needed für Reporting pro Big Customer). Die anderen “normalen” Mandanten bleiben im vCore General Purpose oder Business Critical Tier, je nach Performance-Bedarf, möglicherweise aber alle in Pools. Azure SQL bringt zudem Features wie shard map management (via Azure Elastic Database Tools) oder Serverless (für extrem selten genutzte DBs könnte man sogar serverless pro DB überlegen, aber Pools sind vermutlich besser in Administration). Wichtig: Azure SQL isoliert Mandanten streng – jede DB hat separate logins/Users. Und die PaaS-Eigenschaften sind bei tausenden DBs Gold wert: man muss sich nicht um 50 SQL Server-VMs kümmern, sondern Azure handhabt die Infrastruktur. Das Unternehmen kann stattdessen in Automatisierung investieren: Provisioning-Skripte für neue DBs, Unit-Tests für Schema-Updates, etc., all das via Azure APIs. Ein alternatives Design – alle Mandanten in einer einzigen großen DB mit TenantID-Spalte – wurde verworfen, denn hier will man ja pro Kunde getrennte DB aus Compliance und Flexibilitätsgründen (einige Kunden kriegen z.B. DB-Backup ausgeliefert – leichter pro DB). Azure SQL single DB Modell ist dafür gedacht: sehr gut skalierbar in Anzahl DBs (ein logical server kann bis 5000 DBs hosten, Pools ähnlich). Summiert: Mit Azure SQL + Elastic Pools kann man Skaleneffekte heben (viele kleine auf einer Ressource) und mit Hyperscale die Ausnahmefälle (riesige DB) versorgen. Außerdem lassen sich neue Regionen einfach erschließen – z.B. falls man das SaaS in Nordamerika wie in EU anbieten will, einfach Pools in entsprechenden Regions erstellen und Mandanten dort anlegen.

C) Referenzarchitektur: Die SaaS-Anwendung selbst läuft vermutlich auf Azure App Service oder in Containern, verteilt auf mehrere Regionen für Nähe zum Kunden. Der Datenbank-Layer wird über Azure SQL realisiert: Man hat pro Region einen oder mehrere Azure SQL Server (logical). Darunter sind Elastic Pools wie “Pool-Small-Clients-1” etc., in denen je ~100-500 Mandanten-DBs liegen (diese Pools nach Kriterien wie Kundengröße oder Nutzungsmuster gruppiert – z.B. ein Pool für Trial-Kunden mit sehr geringer Last, ein anderer für Standard-Kunden mit mittlerer Nutzung, etc.). Azure bietet Metriken, mit denen man Pools überwachen kann, um notfalls DBs umzuverteilen, falls ein Pool zu ausgelastet. Für die heavy customers hat man evtl. eigenständige DBs im Hyperscale Tier (nicht in Pools, da Hyperscale derzeit einzeln betrieben wird). Die Anwendungsschicht nutzt einen Tenant-Router: Das heißt, anhand des Users oder URL ermittelt das SaaS, welche DB angesprochen werden soll (z.B. hat es eine Mapping von TenantID -> Verbindungs-String in einer kleinen Zentraldatenbank oder im Azure App Config/Key Vault). Es öffnet dann dynamisch die Connection zur jeweiligen Azure SQL DB. Microsoft bietet Patterns für dieses Sharding Pattern, inkl. Libraries zur Verwaltung. Alle DBs haben identisches Schema (mandanten-spezifische Daten sind nur inhaltlich unterschiedlich). Continuous Deployment: Schema-Änderungen müssen auf alle DBs ausgerollt werden – hier kann man Azure Elastic Job Agents oder einfach Script-Automation verwenden, um in Schleife jede DB zu aktualisieren. Eine Herausforderung sind Monitoring und Telemetry: Hier nutzt man Azure Monitor, der Metriken pro DB liefert, evtl. werden kritische Perf-Data (DTU-Auslastung, blocking etc.) aus allen DBs zentral in Log Analytics aggregiert (es gibt eine Azure SQL Analytics Lösung, die auf einen Blick zeigt, welche DBs z.B. hohe CPU verbrauchen). Für datenschutzkonforme Mandantentrennung wird jeder DB ein eigenes Login (User) gegeben und die App verwendet diese entsprechend – oder man wählt ein zentrales Login, aber isoliert via Row-level security (eher unsauber bei getrennten DBs, man bräuchte nicht). Besser: pro DB ein Service-User mit minimalen Rechten. Geo-Redundanz: Falls das SaaS ein global verteiltes System braucht, überlegt man, ob man Active-Active fährt (Kunden wählen Region, Daten bleiben dort) oder Active-Passive (eher untypisch bei SaaS). Wahrscheinlich hat man pro Kontinent Pools und versucht Mandanten in ihrer Nähe zu halten. Ein globales Failover aller DBs wäre extrem aufwendig (tausende DBs), daher plant man Redundanz pro Region (Azure selber hat 99,99% in Region, plus Backups). Falls ein echter Regionsausfall: man könnte entscheidende große Mandanten via Geo-Replication eine Sekundär-DB in anderer Region spendieren (z.B. Premium Geo-Replica for large tenant who pays for DR). Aber für alle 1000 DBs ist das oft zu viel Overhead – man setzt auf Backup-Restore im Notfall, oder Failover Groups für die Top 5% Kunden die es brauchen. Die Architektur hat also: App -> Azure SQL (Pools + single DBs) -> optional DR region with select failover group DBs. Für jedes Land mit strengen Residenz-Vorgaben könnten separate logical server bereitstehen (Azure hat z.B. in DE eigene Region, oder in CH). Networking: Das Backend kann via Private Link an App VNet angebunden sein, oder man belässt es Public but secured by firewall (wenn App Service no VNet, dann IP allow). Wahrscheinlich nutzt man Private Link, weil das SaaS Backend auch in Azure ist. Summiert: Hochgradig modularer DB-Layer, mandantengenau isoliert, aber orchestriert via Pools.

D) Migration & Betrieb: Wenn dieses SaaS bereits existiert on-prem, steht eine Migration an. Je nachdem wie Mandanten aktuell gespeichert sind: Falls es bereits separate SQL DBs pro Kunde gibt, kann man diese stückweise migrieren (z.B. pro Kunde Bacpac export/import in Azure). Das kann man mit Skripten und Azure DMS (im Offline-Mode) tun. Die Herausforderung ist hier vor allem Downtime-Planung und Datenkonsistenz: Vermutlich kann man nicht alle 1000 auf einmal in einem kurzen Fenster umziehen, also staffelt man es. Evtl. bietet man einer Test-Kundengruppe als erstes die Cloud-Version, um zu prüfen, ob Latenzen und alles akzeptabel sind. Im Idealfall kann man parallel betreiben und Mandanten selektiv in Cloud umschalten (die App leitet dann eben die an Cloud-SQL statt an on-prem). Wenn Mandanten in einer einzigen DB bisher waren (Multi-tenancy in single DB), wäre Migration viel komplexer (dann müsste man Daten per Skript auf einzelne Azure DBs aufteilen – sehr fehleranfällig). Aber im Szenario klang es eher nach einzelne DBs oder einfach isolierbar. Nach der Migration läuft der Betrieb komplett in Azure: Durch die große Anzahl an DBs muss man auf Automatisierung setzen. Bereitstellung neuer Kunden: Das Sales-Portal sollte automatisch eine neue Azure SQL DB anlegen können – z.B. via Azure Functions oder DevOps Pipeline, die Standard-DB vom Template erstellt (vielleicht mithilfe von CREATE DATABASE AS COPY OF einer Template-DB um Schema schnell hinzukriegen). Upgrades: alle DBs brauchen denselben Schema-Stand. Dafür evtl. Deployment-Skripts so schreiben, dass sie auf einem logical Server “execute against all DBs” funktionieren (via Elastic Jobs). Monitoring und Support: Bei tausenden DBs kann man nicht jede einzeln manuell checken. Man muss Schwellen definieren: z.B. Alarm, wenn eine einzelne DB >80% DTU im Schnitt / > X DTUs dauerhaft nutzt (vielleicht ist diese DB zu groß geworden für Pool). Dann könnte man diese DB aus dem Pool herausnehmen oder ihr mehr Pool-Ressourcen zuweisen. Solches Load Balancing der Mandanten wird Teil des operativen Geschäfts: regelmäßig auswerten, ob Pools noch gut segmentiert sind – eventuell einige DBs zwischen Pools verschieben (geht indem man die DB kurz aus Pool rausnimmt und in anderen Pool legt, was schnell geht). Betrieb heißt auch: Cost Management pro Tenant – vlt. will man intern nachhalten, ob ein Kunde profitabel ist (z.B. einer nutzt extrem viel DB-Ressourcen aber zahlt Standardpreis). Azure zeigt Kosten pro DB/Pools, so kann man das berechnen. Evtl. Modell anpassen (Großverbraucher zahlen Zuschlag). Backup & Restore: Standard PITR deckt viel ab. Aber, es ist realistisch, dass mal ein Kunde anruft “Ich habe gestern Datensatz X gelöscht, könnt ihr DB von gestern wiederherstellen?”. Azure ermöglicht Point-in-time Restore auf Einzel-DB-Ebene: Der Betreiber kann dann die DB Tenant123 zu einem Zeitpunkt gestern wiederherstellen (als neue DB Tenant123_restore), dort den Datensatz rausholen und dem Kunden zurückspielen. Das ist sehr nützlich. Der Betrieb sollte entsprechende SOPs haben dafür. On-prem war das mühsam, im Azure PaaS ist es schneller. Security Multi-tenant: Der Betreiber muss streng auf isolierte logins achten; kein Kunde darf per Direktverbindung DB eines anderen sehen. Evtl. gibt man Kunden gar keinen DB-Zugang (SaaS üblich), sondern alles läuft über App. Dann interne Logins nur. Jedenfalls sind Tools wie Azure Security Center auch hier sinnvoll – sie scannen z.B. bei DBs config schwächen (Public open etc.). Im Übrigen muss man auch ans Schema-Management denken: Ein Fehler im Deployment-Script auf viele DBs kann zig Mandanten lahmlegen. Daher zuerst immer in Staging Pools testen. Vielleicht Blue-Green-Deployment: Pools hälftig updaten, schauen ob gut, dann rest. So minimiert man Risiko, dass ein Schema-Bug alle trifft. ClientVerbindungen: Falls mal ein Pool klemmt (z.B. Azure Wartung), nur Teil der Kunden betroffen, aber Support sollte vorbereitet sein (die Pools dokumentieren, wer wo ist, damit man Kommunikation gezielt steuern kann).

E) Kostenhebel: In diesem Multi-Tenant-Szenario ist Kostenoptimierung zentral, da die Marge der SaaS auch von effizienten Cloud-Kosten abhängt. Größter Hebel: Elastic Pools statt Einzeldatenbanken. Durch Pools teilt man Kapazitäten: Der Betreiber sollte aktiv Pooling-Strategien verfolgen. Beispielsweise Pool-Größe an durchschnittliche Summenlast anpassen, nicht an Peak. Wenn die Summepeak doch mal höher wird, kurzzeitig können Queries etwas warten – für manche SaaS ok, ansonsten kann man Pools auch bei Erreichen 80% manuell skalieren (auch Pools sind skalierbar!). Pools können als vCore oder DTU Pools kommen. vCore Pools sind flexibler neu, aber mancher nutzt noch DTU-Pools (Simple small usage). Ein Optimierungshebel ist die Dynamik: Pools erlauben tier-Wechsel on the fly. Könnte man z.B. nachts Pools auf kleineres Tier schalten wenn alle Mandanten schlafen (Zeitzonenbasiert)? Wenn global, schlafen nie alle, aber regional könnte man. Serverless pro DB vs Pools: Man könnte für extrem sporadische Mandanten (die vllt. nur 1x im Monat reingehen) auch Serverless DBs nutzen statt Pools – die würden dann autopausieren. Aber bei Tausenden ist Pools administrativ einfacher. Evtl. eine Kombi: z.B. Trials oder Free-tier Kunden in einen serverless Tier packen, der pausiert wenn keiner da. Muss man abwägen. Reserved Capacity: Wenn bekannt ist, dass sagen wir insgesamt 100 vCores an Leistung über alle Pools permanent gebraucht werden (im Mittel), kann man dafür Reserved Capacity buchen. Hier tricky: Pools können verteilt sein, aber man kann z.B. pro Region x vCores reservieren. SaaS-Betrieber, sobald last stabiler, sollten mind. 1 Jahr Reserved machen. Evtl. erstmal keine, um flexibel zu bleiben, aber nach einem Jahr Daten -> ja. AHB: In Azure SQL Database vCore kann man auch AHB nutzen, falls man entsprechende SQL licences hat – oft hat SaaS-Anbieter aber keine, weil sie neu sind. Wenn doch (z.B. von alten Prod, EA Verträge), könnte man AHB toggeln um die Kosten zu senken. Hyperscale Kosten: Hyperscale rechnet Storage separat – für sehr große Mandanten sollte man die storage usage genau tracken und ggf. dem Kunden weiterberechnen (z.B. “mehr als 1TB, Aufpreis X/GB”). Denn diese verursachen signifikante Azure-Kosten. Egress: Falls Mandanten große Exporte ziehen, Data egress – monetarisieren oder minimieren. Dev/Test Pools: Vermutlich hat der SaaS-Anbieter auch Testsystem mit vielen dummy Tenants – die kann man kleiner dimensionieren, auto-pausen, etc., damit nicht gleiche Kosten. Automation: Automatismen verhindern “vergessene” DBs (z.B. ein Testkunde hat gekündigt – DB noch da -> zahlen). Also Retention-Jobs zum Löschen inaktive Tenants, das spart. Und last but not least: Richtig dimensionieren: Business Critical Tier bietet bessere Performance aber kostet ~3x GP. Lohnt nur für latenzkritische Workloads. Wenn man Pools uses BC, dann vielleicht nur, wenn wirklich nötig (like for tenants doing heavy IO where BC’s local SSD helps). Standard-Kunden vllt. auf GP belassen. Das mischen kann man je nach Tier: z.B. Premium Pools vs Standard Pools als analogon in DTU Welt – im vCore das gleiche mit BC Pools vs GP Pools. Unterm Strich erreicht man so, dass Kleinste Kunden nur Cent-Beträge** kosten (weil hunderte teilen sich paar vCores), während große Kunden mehr Ressourcen ziehen und daher entweder eigen stehen oder zu höheren Tier zugeordnet werden. Diese Kostenstruktur kann man deckungsgleich mit dem Pricing-Modell des SaaS machen (z.B. Enterprise Plan Kunden -> bekommt dedizierte DB oder Premium-Pool, zahlen mehr). Das bringt Profitabilität.

F) Risiken & Gegenmaßnahmen: Komplexitätsrisiko: Der Betrieb von tausenden DBs kann komplex werden. Risiko, dass Administration unübersichtlich wird (wer ist wo, welche Version wo). Gegenmaßnahmen: Automatisierung und Inventarisierung. Ein zentrales Register (Datenbank der Datenbanken) pflegen, welches Mandant in welchem Pool auf welchem Server ist, inkl. Metadaten (Plan, Size). Bei jedem Provisioning/Deprovisioning muss das up-to-date gehalten werden. Skalierungsgrenzen: Azure hat Limit z.B. max 5000 DBs pro logical server. Wenn man zigtausend Mandanten erwartet, muss man verteilen (z.B. pro 5000 ein Server). Das ist okay, aber wenn eine Region 20000 Kunden hat, 4 logical server nötig. Hier risk: man muss Sharding auf Server-Ebene auch managen. Gegenmaßnahme: Planen von Start an, wie man Mandanten auf mehrere Server verteilt (z.B. moduloregeln: TenantID%4 -> Server). Das sollte im Routing beachtet werden. Noisy Neighbor: In Pools kann ein Mandant viel Leistung ziehen und andere verlangsamen. Azure Pools mitigieren das nur bedingt (wenn er nicht die eDTU cap überschreitet, kann er eine Menge schlucken). Gegenmaßnahmen: Pool-Einteilung so dass ähnliche Größen zusammen sind. Und Azure bietet an, pro DB im Pool ein min und max eDTU zu setzen (im vCore-Pool entsprechend in preview). Also dem heavy user ggf. Max 50% vom Pool zuweisen, sodass nie alles blockt. Falls das nicht reicht: schweren Nutzer isolieren in eigenes Tier. Service downtime Auswirkung: Wenn Azure oder ein Pool mal Problem hat (z.B. regional outage), betrifft das viele Mandanten gleichzeitig. Das kann Support fluten. Man sollte also Statuskommunikation parat haben: Wenn Region down, Info an Kunden “Wir haben Technical issues in Region X, Team working – ihre Daten sicher, aber Service temporaer offline”. Das ist im SaaS unabdingbar. Datenbank-Schema-Drift: Bei so vielen DBs besteht Risiko, dass nicht alle auf identischem Stand sind (vielleicht ein Deployment hat ein paar DBs ausgelassen wegen Fehler). Das kann später Probleme machen (App erwartet Spalte X, aber in DB fehlt sie). Daher strikte Deployment Logs führen, bei Fehler neu ansetzen, ggf. Tools wie liquibase oder Flyway, die Schema versions tracken, nutzen. Und Monitoring: e.g. in Application on connect check a SchemaVersion table per DB to ensure it’s current. Security: Mehr Oberflächen (viele DBs) können mehr potenzielle Lücken bedeuten (z.B. alle DBs sollten TDE on, falls mal eins off – Lücke). Daher Policy Enforcement: Azure Policy kann z.B. gewährleisten, dass alle SQL Server TDE an, auditing an etc. Und Minimierung von admin users: nicht jeder DBA direkt mit sysadmin auf Pools rumfummeln, lieber über Script. Costs out of control: Pools erleichtern Kosten, aber man muss immer noch überwachen ob Auslastung stimmt – wenn Pools dauerhaft 90% -> Latenz, oder Pools zu groß -> ineffizient. Lösen: monatliches Cost Perf Review Teammeeting, FinOps involvement. Vendor Lock-in: Das System nutzt stark Azure-spezifische PaaS, das Lock-in ist hoch – tausende DBs lassen sich schwer auf eine andere Plattform heben ohne enorme Mühe. Man muss sich dessen bewusst sein. Für Notfall (Exit) solle man zumindest konzeptionell wissen, wie man die Daten rausholt (z.B. Bacpac per automation), aber realistisch ist Weg zurück on-prem keine Option sobald so implementiert. Das Unternehmen muss davon überzeugt sein, dass Azure langfristig passt. Limits: Standard-Pools haben DB-size limits (General Purpose ~ 4TB per DB, Business Critical 1TB). Hyperscale löst es, aber Hyperscale Pools gibt es nicht (Stand heute). Also ein Hyperscale Mandant kann nicht im Pool sein, ergo kann seine Ressourcen nicht teilen – er hat dedizierte cost. Das kann Mgmnt stören (“warum zahlt uns Kunde X so viel, weil er 10TB hat?” – ggf. richtig bepreisen). Man muss also Strategie für “Riesen-Mandanten” definieren (dedicated environment vs run as hyper DB plus surcharge etc). Upgrades und Compatibility: Azure SQL Engine updates might appear and possibly break something. Test environment with subset of DBs under ring-based rollout can catch issues early. Also making use of Azure’s Version Pin (not possible in PaaS) is not an option – but usually minor risk since T-SQL mostly backward compat. Ops Team Overload: mit so vielen DBs, das Team muss gut Tools nutzen, sonst droht Burnout. Provide training in automation, invest in internal tools to quickly answer questions like “which pool is slow currently?” etc. The platform approach means building some internal portal possibly. Insgesamt aber ist Azure SQL prädestiniert für Multi-Tenancy-Lösungen – Microsoft selbst hat SaaS Reference Implementations mit Azure SQL.

Szenario 5: DR/Business Continuity für on-prem SQL (Managed Instance Link / Geo-Replikation als Fallback)

A) Ausgangslage & Ziele: Ein Finanzdienstleister betreibt eine geschäftskritische SQL Server-Datenbank on-premises, z.B. für Zahlungsverkehr. Aus Compliance-Gründen und Latenz zur Core-Banking-Umgebung bleibt der primäre Betrieb on-prem im eigenen Rechenzentrum. Allerdings gibt es Bedenken bezüglich Desaster-Szenarien: Was, wenn das Rechenzentrum ausfällt (Brand, Überschwemmung) oder durch Cyberangriff alle Server verschlüsselt werden? Man braucht eine ausgelagerte Notfall-Instanz der Datenbank, um im Ernstfall den Betrieb fortzuführen. Bisher hat der Finanzdienstleister dafür ein zweites RZ in 300 km Entfernung, wo via Log-Shipping eine Kopie läuft. Aber dieses Konzept ist teuer (zweite Hardware, Backup-Tapes transportieren etc.) und wurde nie real getestet – es besteht Unsicherheit, ob im Disasterfall die RTO/RPO eingehalten würden. Nun überlegt man, Azure als sicheres Fallback-Rechenzentrum zu nutzen. Die Ziele: Eine möglichst aktuelle Kopie der Produktionsdatenbank in Azure bereithalten (RPO minimal), die im Notfall schnell aktiviert werden kann (RTO niedrig, ideal unter 1 Stunde). Gleichzeitig soll diese Kopie im Normalbetrieb keine Abfragen bedienen (schließlich sind die Daten sensibel und sollen nicht in der Cloud genutzt werden, nur als Standby) – d.h. Lizenzkosten und Risiken sollen minimiert werden. Die Lösung muss mit den strengen Regulatorien konform sein: Daten in Azure – selbst als Kopie – müssen verschlüsselt, kontrolliert und nachweisbar geschützt sein. Und regelmäßig will man Notfallübungen durchführen können, um Vertrauen in den DR-Plan zu gewinnen.

B) Empfohlene Azure-SQL-Variante + Begründung: Für dieses DR-Szenario ist Azure SQL Managed Instance in Kombination mit dem Managed Instance Link die optimale Lösung. Der MI Link (verfügbar für SQL Server 2019+ und Azure SQL MI) ermöglicht eine nahezu Echtzeit-Replikation einer Datenbank von on-premises zu einer MI in Azure, basierend auf der Distributed Availability Groups Technologie. Dadurch kann die on-prem DB als Primär replizieren und die MI-DB als Secondary (read-only) aktuell halten, mit sehr geringem Lag (typisch Sekunden). Im Disasterfall könnte dann die MI-DB zum Primär hochgestuft werden. Warum MI? Weil MI von allen Azure-Angeboten am engsten an on-prem SQL Server dran ist und explizit für solche Hybrid-Szenarien (via Link) ausgelegt. Azure SQL Database (Single) könnte zwar auch mit Azure Arc oder Transactional Replication als DR-Ziel dienen, aber das ist komplizierter und mit Einschränkungen behaftet. MI erlaubt es, auch komplexe DBs (viele Dateien, Agent etc.) nahezu identisch zu führen. Zudem kann MI in einer isolierten VNet-Umgebung laufen, die via ExpressRoute ans Unternehmen angebunden ist – so bleiben die Daten auf einem privaten Pfad. Geo-Replikation in dem Sinne, dass MI optional noch eine Kopie in zweite Azure Region hat, wäre auch denkbar, aber primär geht es hier um cross-environment replication. MI hat den Vorteil, dass man dort ggf. im Notfall weiter alle gewohnten SQL-Features hat (z.B. falls Batch-Jobs laufen müssen, kann man Agent-Jobs definieren, oder falls Applikation verteilte Transaktionen benutzt, hat MI den Support). Die MI im DR-Fall fungiert dann quasi als Ersatz-Rechenzentrum mit minimaler betrieblichen Umstellung. Ein Alternatives Setup mit SQL Server auf Azure-VM (z.B. Always On AG zwischen on-prem und Azure VM) wäre ebenfalls machbar, aber das bedeutete, eine VM kontinuierlich zu pflegen. Mit MI entfallen OS-Pflege und man kann sicher sein, dass Azure die Instanz robust hält. MI Link orchestriert auch das Failover so, dass man beim Zurückschwenken in hybriden Setup unterstützt wird. Außerdem: MI-Lizenzen kann man mit AHB/DR benefit unter Umständen lizenztechnisch als „Passive“ anrechnen (Enterprise SA erlaubt passive Secondaries ohne extra Lizenz, worunter ein MI-DR-Knoten fallen kann). Das reduziert Kosten (muss aber geprüft werden, ob MS das in dem Fall anerkennt, oft ja, solange sie not serving data to clients). Insgesamt also: Azure als DR-Standort via MI Link gibt modernste Tech (DAG) plus entlastet von zu viel Pflege, passt ins Hybridmodell.

C) Referenzarchitektur: Im on-premises RZ läuft ein SQL Server 2022 auf Windows Cluster (Primär) mit eventuell High-Availability vor Ort (z.B. Failover-Cluster in dem RZ). Diese Primär-DB wird via Managed Instance Link zu einer Azure SQL Managed Instance (Sekundär) verbunden. Der MI Link nutzt intern ein Distributed Availability Group: d.h. On-prem Always On AG (oder einzelne DB) -> Azure MI AG. Architektonisch braucht man eine Direct Network Connectivity: via ExpressRoute (empfohlen für Finanzen, wegen privat & robust) oder site-to-site VPN, damit der On-prem SQL die MI erreichen kann (MI hat privates VNet-Endpunkt im Azure Cloud VNet). Die MI ist in Azure Region z.B. “Azure West Europe” in einem Subnetz. Beide Seiten (on-prem und Azure) tauschen kontinuierlich Transaktionslog aus. Die Azure MI bleibt im Read-only Zustand (kann, muss aber nicht, es ist rein DR, also es greifen keine Apps drauf zu). Option: Für Reporting könnte man die MI-Secondary abfragen, aber hier wohl nicht gewünscht (Compliance). Um Sicherheit zu gewährleisten, sind alle Daten verschlüsselt: TDE auf DB plus IPSec/VPN auf Transport. Azure MI speichert Daten standardmäßig verschlüsselt und in RA-GRS Storage (so die Backups sind ausfallsicher). Zusätzlich wird vielleicht Azure Key Vault mit Customer Managed Key für TDE verwendet, damit der Kunde notfalls den Key zurückziehen kann (Theoretisch). Die Architektur beinhaltet auch ein Runbook bzw. Automation: Im DR-Fall, wenn on-prem down, muss man innerhalb z.B. 15 Minuten den Failover einleiten. Das könnte man skripten oder manuell in Notfall durchführen: MI Link supports forced or planned failover. Anwender und Applikationen müssten dann auf die MI umgeschwenkt werden. Hier hat man wahrscheinlich in der App-Schicht bereits einen Plan: Evtl. nutzt man DNS Alias für SQL Server (z.B. sqlprod.company), und im Failoverfall zeigt dieser CNAME auf die MI-FQDN. Das umzustellen sollte Teil der DR-Plan-Doku sein. Azure DNS oder on-prem DNS je nachdem. Die Referenzarchitektur zeigt also: Prod DB -> replicating to Cloud DB -> Failover capability. Zusätzlich wird regelmäßiges Test-Failover geübt: Im Plan würde man z.B. vierteljährlich die Replikation mal kurz trennen und testweise in Azure die DB online nehmen, Testclients dranhängen, dann verwerfen. Für die Compliance werden sicher Berichte gebraucht: z.B. Nachweis, dass Daten im Ruhezustand in Cloud verschlüsselt, Protokoll wer auf MI Zugriff hat etc. Azure bietet hierfür Audit-Logs. Diese MI wird vielleicht in einer separaten Azure Subscription gehalten, zu der nur wenige Admins Zugang haben (um Risiko von Fehlbedienung zu minimieren). Im Normalbetrieb ist Ressourcennutzung minimal (die MI arbeitet nur als secondary, also keine Nutzertransaktionen). Um RTO zu verbessern, könnte man im Applikationsstack bereits die MI als Secondary in Verbindungsstrings konfigurieren (wenn MultiSubnet Failover = true, aber cross-env vllt. lieber manuell). Der Plan belässt es aber oft bei manuellem Failover aus Sicherheitsgründen.

D) Migration & Betrieb: Hier ist initial keine klassische Migration, sondern Einrichtung einer Replikation. Vorgehen: Zuerst die Azure Managed Instance bereitstellen mit kompatiblen Einstellungen (SQL Collation, max. vCores >= On-prem etc.). Dann ggf. ein Initial Backup der on-prem DB erstellen und diese auf MI wiederherstellen (MI erlaubt Backup/Restore). Oder man nutzt den MI Link Setup, der intern initial Backup/Seeding macht. Nach dem Seeding wird der Link aktiviert, und ab dann fließen log records fortlaufend. Der on-prem DB Betrieb geht normal weiter. Administratoren beobachten eine Weile die Latenz (MI Link Dashboard zeigt, ob Link behind). Unter normalen Bedingungen über ExpressRoute sollte die Verzögerung minimal sein. Dann wird in den Betriebsdokumenten festgehalten: Wir haben jetzt ein “Azure DR”. Es wird definiert: Was löst Failover aus? (ganze RZ Ausfall, oder z.B. falls Ransomware im Netz). Wer entscheidet Failover? (Krisenstab ruft DB-Admin Team, die startet). Wie schwenken Anwendungen um? (DNS, config change etc.). Der Betrieb im Alltag: On-prem DBAs müssen überwachen, dass Link gesund ist. MI Link schließt Lücken selbst, aber z.B. falls Netz weg, kann Lag entstehen. Also Alarm definieren: Link lag > X min => Notify. Man wird auch regemäßig (mind. jährlich) einen DR-Test fahren: ideal geht das so, ohne Prod zu gefährden: man kann den Link “klonen”. Oder einfach an einem Wochenende: Kappen, MI zum Primär, Testqueries, dann verwerfen, On-prem weiterhin Primär (a proper DR test might involve downtime though). Alternativ nutzt man Failover ohne switchover: In DAG kann man vlt. Secondary read testen, aber A/B test ist schwierig ohne cut. Im Betrieb gilt es auch, MI up-to-date zu halten: Azure patched MI eigenständig (kann man plan window setzen). Darauf achten, dass on-prem SQL Version nicht hinterher hinkt: MI gets updates aligning to latest CU, ensure on-prem not older incompatible (they must be within same major version and within 2-3 CUs typically). Wenn On-prem mal upgraded (z.B. 2022 to 2025 in Zukunft), MI muss vorher upgrade (Azure likely already on that version by then). Also, die Lizenzierung: Wenn on-prem Enterprise SA, kann die MI als passive im Rahmen der HA rights laufen – man sollte das formal dokumentieren. Der Betrieb sollte kostengünstig sein, aber MI generiert trotzdem Azure usage (compute + storage). Evtl. kann man MI kleiner dimensionieren als Prod, um Kosten zu sparen, und im Failover dann schnell hochskalieren. Das ginge, aber muss getestet. Zum Bsp: Prod 16 cores, DR MI nur 8 cores (billiger). Im Notfall (bevor user drauf) auf 16 hochskalieren (dauert 30 min?), dann umschwenken. Das erhöht RTO, muss man gegen Kosten abwägen. Falls RTO sehr streng, MI muss in voller Kapazität laufen always.

E) Kostenhebel: Der schöne Aspekt: Wenn MI als reine DR-Instanz passiv dient, kann man via Azure Hybrid Benefit die Lizenzkosten vermeiden, falls die on-prem-Lizenz SA die DR-Nutzung abdeckt. Microsofts Lizenzguide: ein passive sekundär (nicht zugänglich ausser DR test) erfordert keine zusätzliche Lizenz. In Azure ist das graubereich, aber MS hat bestätigt, dass AHB erlaubt, MI as standby no license cost – im Portal setzt man AHB=Yes (was erfordert Lizenz, aber man hat ja on-prem Lizenzen, also ok). Reserved Capacity: Falls der Plan ist, MI bleibt auf Jahre in Bereitschaft, kann man 1y Reserved anstreben, aber vlt. unsicher ob MIG-Plan lang bleibt. Möglicherweise eher PayGo, weil man die MI vlt. nur saisonal will? Aber nein, DR muss immer an sein. Um Geld zu sparen, könnte man MI an Wochentagen belassen und Wochenenden stoppen (aber Katastrophen kennen kein Wochenende, also schlecht). Daher MI wohl 24/7. Also 1-year Reserved macht Sinn (3y nur, wenn man super committed). Compute-Kosten sind Hauptanteil. Größe optimieren: wie erwähnt, man könnte MI kleiner dimensionieren als Prod. Der Link wird auch funktionieren, solange log shipping in time. Wenn Crash, dann muss man nach dem Failover hochstufen und wird kurz knapp an Perf, aber besser als hohe Kosten immer. Müssen RPO vs Perf vs Kosten abwägen. Vmtl. moderate sizing. Backup Storage: MI wird Backups in Azure lagern. Standard 7 Tage + LTR if any. Das kostet was. Minimieren: LTR aus auf MI (nur on-prem hat LTR?), oder LTR auf MI nur 1wk (man will vlt. gar nicht Cloud LTR). Wobei vielleicht gut, Cloud as backup, aber egal. Minimieren Egress: Der Link sendet log, aber das ist gratis inbound Azure. Nur wenn Failback (downloading data back) fällt egress an. Das nur einmal in DR end, also vernachlässigbar. Dev/Test on MI: Evtl. kann dieselbe MI in Friedenszeiten als Test-Umgebung read-only Dumps etc. dienen, aber meist aus Security NICHT, sie soll isoliert sein. Sonst ABOternativ: Man hat auf MI eine DB Kopie, könnte man für Reporting authorized People connect. Falls doch, dann müsste man MI lizenz als aktive kennzeichnen, was Kosten/Compliance ändert. Besser wirklich passive belassen. Kosten/Nutzen: Im Business Case muss man argumentieren: Cloud-DR (monatl. X €) vs zweites Rechenzentrum (CapEx Y + OpEx). Oft Cloud-DR ist günstiger, vor allem flexibel (kein Hrdwr Idle) – aber 24/7 MI mit 8-16 cores hat auch guten Preis. Mit AHB & reserved aber okay. Finetuning via smaller instance offpeak ist vlt. overhead. Besser fix small and scale when needed. Also, falls das Budget eng: vlt. only replicate critical DBs, nicht alle. Legt priorität. Das kann cost save.

F) Risiken & Gegenmaßnahmen: Replikationsrisiko: Technisch neu – MI Link muss robust sein. Risiko: Sync bricht ab (Netzwerk, version mismatch). Muss intensiv im Setup getestet werden. Ggf. fallback plan: if link fails and cannot catch up, full backup sync again. Mit Routine bereithalten. Securityrisiko: Daten in Cloud als Kopie – streng isolieren (Private link, NSG, no user queries). Keys in Key Vault, so im worst case kann man key revoke to render data unreadable (Kunde demonstriert Control). Failover-Fähigkeit ungeübt: Wenn man nie echt failover geübt hat, Team im Ernstfall unsicher. Abhilfe: DR-Drills mind. 1x Jahr. Evtl. Wochenend Übung: Schalte Prod ab (Simulate), Azure hoch, Testclient zugreifen, dann zurück, re-initiate link. So kriegt man Routine. DNS/Connectivity nach Failover: Clients müssen Cloud erreichen. Das erfordert netzwerktechnisch, dass Applikationsserver evtl. ins Azure VNet gehen (wenn App selber on-prem). Also Teil Plan: App failover auch? Oder Apps always dual connect? Hier muss genau definiert: Vlt. Applikationsfailover mit VMs in Azure as well. In DR-Fall, DB alone up is not enough, business processes need connecting apps. Mit Az DR DB hat man halbe Miete – muss darauf achten, Applikationen (die vllt. behind firewall on-prem) im Notfall via VPN zu Azure DB kommen. Also check connectivity in drills. Datenkonistenz & Split-Brain: Gefahr, dass versehentlich Failover eingeleitet obwohl on-prem noch aktiv => doppelte Primär, divergierende Daten. Das wäre fatal. Daher glasklar: Failover nur, wenn on-prem garantiert offline (im Zweifel Strom ab im DC bevor Cloud online). Oder falls geplanter Failover (z.B. DC-Wartung) dann on-prem -> MI properly so no divergence. Sonst risk of needing conflict merge, was kaum geht. Wiederzurück (Failback) nach DR: Muss auch geübt. Ist Outage fix -> wie Prod DB updaten? MI Link kann auch Reverse (promote MI to primary, add on-prem as secondary). Muss orchestriert: After event, apply differential or link back. Wichtig im Plan: Achieve failback with minimal data loss. Evtl. treat Azure as new primary permanently if on-prem down war. Je nach damage. Compliance: Finanzbereich will audit, was in Cloud. Also MI logs (Azure Audit) an SIEM, nach DR test dem Auditor zeigen, dass nur im test user X data accessed. Minimierung of PII risk. Also Cloud region maybe must be same country for regs, ensure region chosen properly (z.B. Switzerland region if needed). License compliance: Hatten wir, Passive licensing must be valid. Feature Limitations: MI must support everything needed. If on-prem uses some unsupported (rare in 2019 vs MI), e.g. Filestream, not replication. Probably fine, but check e.g. cross DB transactions maybe cause trouble – DAG replicates per DB, cross db consistency not given. But in DR mode, this accepted. Alternative path if MI unreachable: If Azure region outage, ironically your DR down. Possibly have second DR? Unlikely needed, as on-prem main. But one could host MI in a different Azure region than primary DC region if worry of region scale disasters. But probability both on-prem DC and Azure region fail same time extremely low. So tolerated. Also consider scenario: on-prem partially up but DB corrupted (cyber). They might failover to azure intentionally as clean copy. Good to plan such usage too (with caution the data currency if replication might replicate corruption – here point in time restore in MI could be used if discovered quickly). The plan should incorporate that.

7. Entscheidungsleitfaden & Checkliste

Jede Datenbank-Modernisierung erfordert eine wohlüberlegte Entscheidung, welche Plattform die beste Balance aus Anforderungen, Kosten und Aufwand bietet. Nachfolgend ein einfacher Entscheidungsbaum in Textform, der Ihnen hilft, basierend auf zentralen Kriterien einzugrenzen:

• Funktionale Anforderungen: Prüfen Sie zuerst die benötigten SQL-Features.
  Wenn Ihre Anwendung spezielle Instanz-Features erfordert – etwa SQL Agent-Jobs, Cross-Database-Transaktionen, CLR oder heterogene Linked Servers – und Sie diese beibehalten möchten, dann scheidet Azure SQL Database (Single) vermutlich aus. Azure SQL Managed Instance oder eine VM kommen in Frage.
  Wenn hingegen nur Standard-T-SQL und Datenbank-spezifische Features genutzt werden (z.B. Prozeduren, Indizes, Basis-Security), dann können Sie problemlos eine Azure SQL Database einsetzen.
• Kontrolle vs. Betriebsentlastung: Entscheiden Sie, wie viel Kontrollbedarf es gibt.
  Wenn Sie volle Kontrolle über das OS, Dateisystem, bestimmte Patches oder Drittsoftware benötigen (z.B. spezieller Treiber, Agent-Erweiterungen), werden Sie um eine SQL Server auf VM Lösung nicht herumkommen.
  Falls Sie dagegen so viel Betrieb wie möglich an Azure abgeben wollen und mit gewissen Vorgaben leben können (kein OS-Zugriff, Azure-gesteuerter Wartungszeitpunkt), dann sind Azure SQL PaaS-Dienste ideal.
• Netzwerk & Isolation: Betrachten Sie Netzwerk-/Compliance-Anforderungen.
  Muss die Datenbank in ein bestehendes VNet integriert sein, etwa weil Applikationen im gleichen Netzwerk laufen oder strikte Isolation gefordert wird? Dann ist Managed Instance oft im Vorteil (natürliche VNet-Integration).
  Azure SQL Database kann via Private Endpoint auch isoliert werden, aber wenn z.B. ein Legacy-App-Server per Windows-Authentifizierung die DB ansprechen muss, ist MI leichter integrierbar.
  Wenn Daten das Unternehmensnetz nie verlassen dürfen, prüfen Sie auch Azure Arc Data Services (SQL managed on your hardware) – jedoch ist das ein Sonderfall.
• Migrationsaufwand & Zeitfenster: Schätzen Sie Ihre Migrationsbereitschaft realistisch ein.
  Haben Sie die Möglichkeit, Ihre Anwendung anzupassen und einige Downtime einzuplanen? Wenn ja, Azure SQL Database (Single/Pools) belohnt das mit langfristig weniger Verwaltung – aber kurzfristig höherem Anpassungsaufwand.
  Benötigen Sie eine sehr schnelle Migration mit minimaler Code-Änderung? Dann ist SQL Managed Instance oder notfalls eine VM der Weg, da Sie dort quasi 1:1 umziehen.
  Auch das Downtime-Fenster zählt: Für <1h Downtime bei DB-Move sind Optionen wie Log Shipping oder Online Migration notwendig – diese werden von MI und teils Azure SQL DB (DMS mit minimalem Cutover) unterstützt, VMs erlauben sogar Replikation. Planen Sie entsprechend, was praktikabel ist.*
• Kosten- und Skalierungssteuerung: Überlegen Sie, wie dynamisch die Last und Kosten sein sollen.
  Ist Ihr Workload relativ konstant und gut planbar? – Dann können alle Optionen funktionieren.
  Haben Sie extreme Lastschwankungen oder viele kleine Einzel-Datenbanken, bei denen sich ein PaaS-Pricing mit Auto-Scale/Pooling anbietet? – Dann sind Azure SQL Database (mit serverless oder Pools) unschlagbar in Flexibilität und granularer Abrechnung.
  Wollen Sie hingegen fix kalkulierbare monatliche Kosten und sind bereit, dafür ggf. in Spitzen etwas ungenutzte Kapazität vorzuhalten? – Eine Reserved VM oder dedizierte MI kann hier sinnvoll sein.

Oft ergibt sich schon ein recht klares Bild: Neue Cloud-Projekte ohne Altlasten tendieren zu Azure SQL Database, klassische Legacy-Lifts mit hohen Anforderungen an Kompatibilität zu MI oder VM. Nicht zuletzt können Compliance-Vorgaben (Zertifizierungen, Datensouveränität) die Wahl beeinflussen – z.B. erfordert manch ein Regulator physische Isolation, was auf VM hinausläuft, während Standard-Datenschutz mit PaaS ebenso erfüllbar ist.

Hier noch eine Checkliste von Punkten, die Sie vor der endgültigen Entscheidung durchgehen sollten:

• Region und Datenresidenz: Sind die gewünschten Azure SQL Dienste in der benötigten Azure-Region verfügbar? Erfüllt die Region die gesetzlichen Vorgaben zur Datenhaltung (Land/Zone)? Denken Sie an Latenz: Benutzer sollten möglichst in der Nähe ihrer Daten bedient werden.
• Verfügbarkeitsziel: Welchen SLA bzw. welcher Grad an Hochverfügbarkeit wird benötigt? Reichen die 99,99% von PaaS (ggf. plus Zonenredundanz) aus? Müssen wir eine Multi-Region-Strategie einbeziehen? On-Prem hatte man oft 99,9% – PaaS verbessert das, aber prüfen Sie, ob Applikationen zusätzliche HA brauchen.
• Wiederherstellungsziele (RPO/RTO): Welche RPO/RTO sind im Desasterfall gefordert? Wenn nahe Null, planen Sie Geo-Redundanz (z.B. Auto-Failover Gruppen). Wenn ein paar Stunden vertretbar, reichen Backups in Azure. Stellen Sie sicher, dass das gewählte Modell entsprechende DR-Optionen bietet (Azure SQL DB und MI: ja, VMs: self-build).
• Lastprofil & Skalierungsbedarf: Analysieren Sie das Nutzungsprofil Ihrer DBs. Kontinuierliche Last -> feste Allokation (VM/MI) vs. periodische Peaks -> flexible Skalierung (serverless/Pools). Auch Maximalgrößen: Wenige sehr große DBs (> 4 TB) deuten auf Hyperscale/VM, viele kleine auf Pools.
• Automatisierung & Infrastructure as Code: Können/wollen Sie Ihre DB-Deployment und Konfiguration als Code verwalten? PaaS fügt sich leichter in IaC (Azure Resource Manager, Terraform) da keine OS-Konfiguration. VM erfordert zusätzliches Scripting für OS/SQL-Install. Überlegen Sie, ob Ihr Team das mittragen kann oder ob Einfachheit wichtiger ist.
• Kosten & Abrechnung: Haben Sie bereits SQL Lizenzen (Enterprise/Standard mit SA), die Sie mittels Azure Hybrid Benefit einsetzen können? Gibt es Budgetvorgaben (Capex vs Opex)? Planen Sie, Reserved Instances zu nutzen? Entspricht das Kostenmodell (variable Monatspreise vs. fixe Abschreibung) Ihrer Finanzstrategie? Berücksichtigen Sie auch interne Leistungsverrechnung: mit Tags können Sie Cloud-Kosten projektscharf zuordnen – manchmal ein Vorteil gegenüber Sammelkosten on-prem.
• Betrieb & Monitoring: Ist Ihr Operations-Team auf die neue Betriebsform vorbereitet? Für PaaS sollten Sie Cloud-Monitoring (Azure Monitor) beherrschen und wissen, welche Metriken wichtig sind (DTU, vCore-Auslastung, throttling events). Für VMs müssen klassische Überwachung (Disk voll, CPU hoch) weiterhin eingerichtet werden, ggfs. mit Azure-eigenen Tools. Klären Sie auch, wer welche Zugriffsrechte bekommt und wie Sie im Cloud-Betrieb ITSM-Prozesse abbilden (Tickets, Incidents mit Azure Support etc.).

Durch Abhaken dieser Fragen sind Sie in der Lage, eine fundierte Wahl zu treffen. Meist kristallisiert sich eine Lösung klar heraus – falls nicht, kann ein Proof-of-Concept (PoC) in Azure helfen: Testen Sie Ihr System für einige Tage sowohl auf einer Azure SQL Database als auch auf einer MI/VM, um Performance, Aufwand und Kosten selbst zu vergleichen, bevor Sie sich final binden.

8. Betrieb, Sicherheit & Compliance

Nach der Entscheidung für eine Azure SQL-Variante beginnt die eigentliche Arbeit: Der produktive Betrieb muss etabliert werden, und zwar sicher und regelkonform. Im Folgenden beleuchten wir wichtige Betriebs-, Sicherheits- und Governance-Aspekte.

Backup und Wiederherstellung

Auch wenn Azure SQL automatische Backups durchführt, bleibt Backups & Recovery ein zentraler Verantwortungsbereich – im Sinne von Überwachung und Tests. Für Azure SQL Database und MI sollten Sie zunächst Ihre Aufbewahrungsrichtlinien definieren: Standardmäßig sind 7 Tage PITR (Point-In-Time-Restore) eingestellt, anhebbar bis 35 Tage. Überlegen Sie, wie lange Sie welche Backups aus Compliance-Gründen vorhalten müssen (z.B. 7 Jahre Monatssicherungen?). Azure bietet LTR (Long Term Retention): aktivieren Sie diese gezielt pro Datenbank für wöchentliche/monatliche/jährliche Backups, die entsprechend lange gespeichert werden. Beachten Sie, dass lange Aufbewahrung Kosten verursacht; setzen Sie also nicht blind “alles 10 Jahre”, sondern nur was benötigt wird. Vor allem aber: Testen Sie die Wiederherstellung. Ein Backup ist nur so gut wie die Fähigkeit, es im Notfall zu nutzen. Planen Sie regelmäßige Übungen, z.B. quartalsweise: Stellen Sie eine Produktions-Datenbank als neues Exemplar in einer non-produktiven Umgebung wieder her und prüfen Sie, ob die Daten konsistent sind und der Restore-Vorgang wie erwartet klappt. Dokumentieren Sie dabei die Dauer der Wiederherstellung – bei sehr großen Datenbanken kann ein Restore Stunden dauern; das muss ins Notfallkonzept (RTO) passen. Bei Azure SQL kann es sinnvoll sein, automatisierte Restore-Validierungen einzurichten: Azure ermöglicht Scripts, die etwa nach jeder Sicherung einen schnellen Datenbank-Integrity-Check (DBCC CHECKDB) auf einem Restore durchführen (man cloniert DBs oder nutzt ein Hyperscale-Snapshot dazu). So identifizieren Sie potenzielle Probleme früh. Für SQL Server auf VMs sollten Sie weiterhin Ihren Backup-Plan pflegen: nutzen Sie Azure Backup VM-Erweiterungen oder das bewährte SQL Maintenance Plan Script – Hauptsache konsistente, offsite gespeicherte Backups. Stellen Sie sicher, dass Backups verschlüsselt sind (TDE schützt schon DBs, aber z.B. bei VM-Backups sollte Verschlüsselung via Tool oder speicherseitig erfolgen). Und nicht zuletzt: klären Sie die Verantwortlichkeiten – wer wird alarmiert, wenn ein automatisches Backup fehlschlägt? Azure sendet keine Person aktiv eine Mail, das müssen Sie via Azure Monitor Alerts selbst konfigurieren (z.B. EventHub- oder Log Analytics-Alert auf “Backup failed”). Mit solider Backup- und Restore-Strategie untermauern Sie Ihre Business Continuity deutlich.

Performance-Überwachung und Kapazitätsplanung

Performance-Monitoring ist im Cloud-Zeitalter ebenso wichtig wie on-prem, auch wenn man keine eigenen PerfMon-Sessions auf dem DB-Server mehr laufen lassen kann. Azure SQL stellt vielfältige Telemetrie bereit: Metriken wie DTU-Verbrauch (bei legacy Tiers), CPU%, Data IO, Log IO, Memory sowie Wait Statistics per DMV, all das kann und sollte überwacht werden. Aktivieren Sie den Query Store (in Azure SQL Database per Default ON) für jede wichtige Datenbank – er zeichnet Abfragepläne und Laufzeiten im Zeitverlauf auf. Dies ist das erste Mittel, um bei “Die DB ist heute langsam” den Schuldigen zu finden (z.B. Plan Change für eine bestimmte Query). Azure bietet mit Intelligent Insights eine automatisierte Analyse, die ungewöhnliche Performance-Degradationen erkennt und im Azure Portal Meldungen generiert (etwa “Abfrage X ist plötzlich 30% langsamer seit Datum Y”). Nutzen Sie diese Hinweise, sie verkürzen Troubleshooting enorm. Zudem können Sie Automatic Tuning aktivieren (auf Azure SQL DB im Portal), was z.B. automatisch ineffiziente Ausführungspläne zurückrollt oder fehlende Indexe erstellt – aber führen Sie so etwas zunächst in non-prod ein, um Vertrauen zu sammeln, bevor Sie es produktiv schalten. Kapazitätsplanung verläuft in Azure anders: Da man theoretisch jederzeit hochskalieren kann, könnte man versucht sein, Planung zu vernachlässigen. Doch Vorsicht – unbegrenztes Hochskalieren ist zwar möglich, aber hat Grenzen (Zeitfenster, Budget). Besser ist es, anhand von Metriken wie CPU-Trend und DB Size Wachstum proaktiv zu handeln: z.B. wenn Ihre Datenbank monatlich um 10% wächst, prognostizieren Sie, wann sie das Limit Ihres Tiers erreicht (z.B. 4 TB bei GP). Azure Monitor kann Sie alarmieren, wenn z.B. 80% Storage erreicht. Dann können Sie frühzeitig Hyperscale migrieren oder erweitern. Für CPU/DTU likewise: Langsam steigende Last evtl. durch neue Kunden? Planen Sie ein Scale-Up ein bevor die Nutzer Beschwerden spüren. Im Bereich Workload Management bietet Azure SQL auch Tools: z.B. Resource Governor gibt es in MI (wie on-prem) – damit könnte man einen besonders ressourcenhungrigen Tenant drosseln um andere zu schützen. In Azure SQL Database (Single) sind multi-tenant Limits eher via Elastic Pools gesteuert. Kennen Sie diese Optionen und setzen Sie sie ein, falls zutreffend. Und denken Sie an Ausnahmefälle: Was tun bei plötzlichem Performance-Einbruch? – Hier hilft ein definierter Prozess: z.B. erstens Portal Metriken checken (hohe CPU oder spiking log IO?), zweitens Query Store Top Queries prüfen, drittens ggf. schnell skaliere vCores hoch, um Impact abzufangen, viertens tiefer analysieren (vielleicht hat ein Entwickler vergessen, Index im Plan auszurollen etc.). Schreiben Sie solche Abläufe grob in Ihre Runbooks. Dank Cloud können Sie manchmal den kurzfristigen Schraubenschlüssel ansetzen (Scale-out/in) und dann in Ruhe die Ursache beheben – on-prem war man ausgeliefert. Allerdings: cloudscale kostet Geld, also gleichzeitig immer prüfen, ob z.B. ein wildgewordener Abfrageplan der Grund ist statt wirklich Notwendigkeit dauerhaft mehr HW.

Sicherheit und Zugriffssteuerung

Security ist “job zero” – auch in Azure bleibt die Datenbank oft das Kronjuwel, das es zu schützen gilt. Zum Glück bietet die Plattform zahlreiche Sicherheitsfunktionen. Zunächst sollten Sie eine Least Privilege Zugriffsstrategie umsetzen: Nutzen Sie Azure AD-Authentifizierung für Administratorzugriff, möglichst via Gruppen (z.B. eine AD-Gruppe “DBAs Prod” wird als Azure SQL Admin hinterlegt, statt einen generischen User). So können Sie zentral via AD die Teammitgliedschaft verwalten und haben Multi-Factor-Auth im Spiel. Vermeiden Sie dauerhafte Nutzung des SQL Server sa Kontos in Azure VM oder der serveradmin Logins in PaaS – diese sind zwar vorhanden, aber versuchen Sie Standard-User zu nutzen und administrative Operationen separat. Row-Level Security, Dynamic Data Masking, Always Encrypted: Falls Sie Mandantenfähigkeit oder Schutz sensibler Daten umsetzen müssen, greifen Sie auf diese Features zurück. Azure SQL DB/MI haben sie analog zu on-prem. Always Encrypted erlaubt es, z.B. besonders schützenswerte Spalten (Kreditkartennummern) nur verschlüsselt in der DB zu halten, Entschlüsselung erfolgt erst in der App – so ist ein DBA ohne den Schlüssel nicht in der Lage, Klartext zu sehen. Das Key-Management (CMK) kann via Azure Key Vault geschehen. Verschlüsselung im Allgemeinen: TDE sollte an bleiben (Standard in Azure), für MI/VM mit BYOK erwägen Sie eigene Schlüssel. Netzwerk-Sicherheit: Wenn möglich, setzen Sie auf Private Verbindungen. Eine Azure SQL Managed Instance sollten Sie grundsätzlich ohne öffentlichen Endpoint betreiben (es sei denn, es gibt zwingende Gründe). Für Azure SQL Database nutzen viele standardmäßig den öffentlichen Endpoint mit Firewall – das ist sicher, sollte aber auf minimale IP-Ranges beschränkt sein (z.B. App Server IPs only). Besser noch: Implementieren Sie Private Link – dann gibt es eine private IP im VNet, und Sie können alle öffentliche Zugriffe blockieren. Das macht die Architektur etwas komplexer (DNS-Konfiguration etc.), erhöht aber die Isolation. Firewall und NSGs: Nutzen Sie sie! Konfigurieren Sie Azure SQL Firewall-Regeln restriktiv (im besten Fall “deny all”, da Sie über private Link arbeiten). Bei MI regeln NSGs im Subnetz den Verkehr – erlauben Sie nur, was nötig (z.B. Ports 1433/3342 von App/OnPrem subnets, deny Internet). Überwachung/Auditing: Schalten Sie das SQL Auditing ein, um nachzuvollziehen, wer wann was zugreift. In Azure kann Auditing auf Log Analytics oder Azure Storage schreiben. Mindestens für Produktionsdatenbanken sollten Sie protokollieren: Anmeldeversuche, Schema-Änderungen, selektive Zugriff auf sensible Tabellen. Das erzeugt viele Logs, daher definieren Sie klare Aufbewahrung (vielleicht 90 Tage on hot). Bei Verdacht können Sie so zurückverfolgen, z.B. welcher Login Daten exfiltriert hat. Threat Detection (im Defender for SQL) geht einen Schritt weiter: es alarmiert bei atypischen Mustern (z.B. viele Fehlversuche, Anfragen von unbekannter IP, SQL-Injection-Muster). Aktivieren Sie das und richten Sie Alerts an Ihr Security-Team – so haben Sie eine quasi “Alarmanlage” an der DB. Zugriffsmodelle: Stellen Sie wo möglich auf Azure AD-Zugriff um, auch für Anwendungen (Managed Identity). Das erleichtert Passwörter-Management (kein Hardcoding). Für DBAs mit SSMS geht’s gut via AD Auth auf Azure SQL. Service Principals oder Managed Identities kann man in AAD Gruppen packen, die als DB-User wirken. Dann spart man sich Secrets. Schlüsselverwaltung: Falls Sie Key Vault integrieren (für TDE oder Always Encrypted), sorgen Sie für Redundanz der Vault (Geo-redundant keys) und Break-Glass Zugriff (falls AD down, gibt’s einen Notfallaccount?). Compliance-Aspekte: Azure SQL ist HIPAA, ISO27001 etc. zertifiziert – das hilft, aber Sie sind dafür verantwortlich, Ihre Konfiguration compliance-gerecht zu gestalten. Das bedeutet: z.B. Personal Data nur in Region speichern, die genehmigt ist; Zugriffskontrollen dokumentieren; Datenklassifizierung verwenden (Azure SQL bietet ein Data Discovery & Classification Tool, um Felder als “Confidential” zu labeln – damit Admins bewusst ist, wo sensible Daten liegen). Manche Branchen verlangen Verschlüsselung von Daten in Bewegung – TLS1.2 ist Standard, aber vielleicht wollen Sie zusätzlich VPN isolieren. Überlegen Sie auch Zugriff von Admins: vielleicht muss jeder Prod-Zugriff im Ticket geloggt sein; implementieren Sie also, dass Prod-DBs nur via Jumpbox erreichbar und dort alle Queries auditiert werden. Das geht mit tools, in Azure gibts ggf. die “Just in time” Access Polices. Penetration Testing: Ja, lassen Sie auch im Cloud Setup von Zeit zu Zeit einen Pentest laufen – Standard Ports etc., ob irgendein vergessenes Public Endpoint existiert oder ein ex-admin noch Zugang hat. Azure bietet “Azure Defender External Attack Surface” scans. Zusammengefasst: Security erfordert einen umfassenden, vielschichtigen Ansatz, aber Azure liefert viele Bausteine – nutzen Sie sie konsequent.

Governance und Compliance

In Cloud-Umgebungen ist Governance entscheidend, um Wildwuchs und Kontrollverlust zu vermeiden. Beginnen Sie mit klaren Namenskonventionen für alle Azure SQL Ressourcen: z.B. Servernamen, MI-Namen sollten Präfixe für Umgebung (prod/test), Region und Zweck enthalten (etwa prod-euw-crm-mi1 für Production, Europe West, CRM MI Instance 1). Ebenso Datenbanken – gerade bei vielen DBs ist es hilfreich, z.B. Mandanten-DBs mit Kunde oder ID im Namen zu führen oder zumindest per Tag zu markieren. Tags sind überhaupt ein zentrales Governance-Tool: Definieren Sie Pflicht-Tags wie Environment, BusinessUnit, Owner, CostCenter. Azure Policy kann erzwingen, dass neue Ressourcen diese Tags haben oder aus der Resource Group erben. So können Sie jederzeit einen Report ziehen, welche Kosten z.B. auf Abteilung X entfallen, oder wer der verantwortliche Ansprechpartner für eine DB ist. Achten Sie ebenfalls auf Rollen und Berechtigungen auf Azure-Ebene: Das Prinzip der minimalen Rechte (Least Privilege) gilt auch hier. Gewähren Sie Entwicklern z.B. vielleicht Leserechte auf Performance Insights, aber keine Möglichkeit, Ressourcen in Prod zu löschen. Nutzen Sie vordefinierte Azure RBAC-Rollen (z.B. SQL DB Contributor, Reader, etc.) und custom Rollen, um genau zuzuteilen, wer was darf. Definieren Sie intern einen RACI (Responsible, Accountable, Consulted, Informed) für die Cloud-Datenbanken: Beispielsweise könnte Accountable der Datenbank-Service-Owner (vielleicht der Head of DBA Team) sein, Responsible für Betrieb das CloudOps Team, Consulted die Applikationsentwickler bei Performance Issues, Informed das Security-Team bei Changes. Dieses Modell hilft, Verantwortlichkeiten zu klären. Budgetkontrolle hatten wir bereits erwähnt – Governance sollte Schwellenwerte definieren, ab wann wer informiert wird (z.B. wenn Testumgebung über x € geht). Tools wie Azure Cost Alerts, aber auch Azure Advisor (der Optimierungspotenziale vorschlägt, z.B. ungenutzte DB auf lower tier) sollten fest ins Betriebsprozedere eingehen. Lifecycle-Management: Definieren Sie, wie lange Ressourcen leben dürfen, insbesondere in non-prod: z.B. darf eine Dev-Datenbank, die 60 Tage idle ist, gelöscht werden? Man kann Mechanismen einführen (Automation runbook, das solche findet und meldet oder entfernt). Für Prod-DBs: legen Sie fest, wann ein Backup ins Archiv darf, wann Datenbanken archiviert werden (z.B. wenn Projekt endet, DB read-only ablegen?). Compliance-Audits: Machen Sie sich mit dem Azure Compliance Manager vertraut und den Berichten, die Azure liefert (z.B. DSGVO-Compliance-Guide). Intern sollte Ihr Compliance Officer Zugriff auf Audit-Logs haben (vielleicht via Log Analytics Reader) und regelmäßig prüfen, ob Policies eingehalten werden (Azure Policy kann technische Richtlinien checken, z.B. “TDE = Enabled” – so etwas unbedingt einsetzen, damit keine DB unverschlüsselt bleibt). Last but not least: Dokumentation. Halten Sie Architektur- und Betriebsdokumente aktuell. Speziell bei PaaS, wo vieles “unsichtbar” im Hintergrund passiert, sollte man in einem Betriebs-Handbuch festhalten, welche automatischen Tasks laufen (z.B. “Azure patcht Dienst nachts in Wartungsfenster So 02-05 Uhr, potenzieller Failover kann passieren”), damit alle im Team das Verständnis teilen. Dokumentieren Sie auch die “Knöpfe”, die es bei Abweichungen zu drücken gilt (z.B. “Wie skalieren wir eine MI manuell hoch? Schritt-für-Schritt und wer Freigabe erteilen muss.”). Eine sauber geführte Governance und Compliance-Kultur stellt sicher, dass Sie auch in der Cloud jederzeit die Kontrolle über Ihre SQL-Umgebungen behalten und gegenüber Prüfern und Management nachweisen können, dass alles regelkonform und effizient gemanagt wird.

9. Migration & Modernisierung

Die eigentliche Migration Ihrer Datenbanken nach Azure – sei es als Teil einer Modernisierung oder reiner Lift & Shift – sollte methodisch geplant und durchgeführt werden. Hier ein Leitfaden durch die Phasen:

Bewertungs- und Planungsphase

Am Anfang steht die Bestandsaufnahme und Bewertung. Nutzen Sie Tools wie die Microsoft Data Migration Assistant (DMA), um Ihre existierenden SQL Server Instanzen zu analysieren. Der DMA-Report zeigt auf, ob objektive Inkompatibilitäten mit Azure SQL bestehen (z.B. verwendete Features, die in Azure SQL DB nicht verfügbar sind) und gibt Empfehlungen. Gehen Sie diese Findings systematisch durch: Markieren Sie, welche Anpassungen nötig wären – z.B. Entfernen einer XP_CMDSHELL-Nutzung oder Ersetzen eines cross-DB Joins durch ein alternatives Pattern. Auch prüfen: Datenbankschemakompatibilität (Azure SQL uses latest engine, ggf. Compatibility Level setzen?), Kollationen (unterschiedliche Standardkollation? Dann angleichen), Größe (passt DB-Größe in gewünschtes Tier?). Parallel dazu bewerten Sie Nicht-technische Aspekte: Welche Downtime ist tolerabel? Gibt es ein festes Zeitfenster (z.B. ein Wochenende) für die Umstellung? Müssen wir ein Rollback-Szenario vorhalten, falls nach Umzug Probleme auftauchen? Planen Sie auch, in der Phase alle Stakeholder einzubinden – Applikationsteams, die Geschäftsseite (für Test und Abnahme), ggf. Kunden, falls spürbare Änderungen.

Basierend auf der Analyse entscheiden Sie sich für einen Migrationsansatz: Entweder offline (größeres Downtime-Fenster in Kauf nehmen, dafür simpler Weg) oder online (komplexere Synchronisation, dafür minimale Auszeit). Legen Sie auch fest, ob Sie etappenweise (z.B. erst Nebenanwendungen, dann Kernsystem) migrieren oder Big-Bang. Wichtig: Erstellen Sie einen Projektplan, der alle Schritte umfasst – inklusive Puffer für Troubleshooting und Abnahme. Verproben Sie kritische Pfade vorab: z.B. extrahieren Sie mal ein Full-Backup der größten DB und laden es testweise in Azure, um zu sehen, wie lange das dauert; simulieren Sie einen kleinen Schemawechsel unter Azure-Bedingungen, um Sicherzugehen, Deploy Pipeline funktioniert.

Migrationspfade und Durchführung

Für den eigentlichen Umzug haben Sie diverse Methoden, je nach Quell- und Zieltyp:

• Offline Migration (Bacpac/Backup-Restore): Für Azure SQL Database (Single) nutzen Sie i.d.R. BACPAC-Dateien. Dabei werden Schema und Daten exportiert (z.B. via SSMS oder Azure DMS) und dann in Azure importiert. Das erfordert einen Ausfall für die Dauer des Exports + Imports. Dieser Weg ist einfach, aber bei >100 GB Daten kann der Import lange dauern. Prüfen Sie Tools wie SqlPackage, um Bacpacs in Batch an Azure zu schicken. Alternativ, falls Azure SQL DB das Ziel: Azure Database Migration Service (DMS) im Offline Modus – es automatisiert Bacpac-Extraktion und Einspielen, mit Logging. Für Managed Instance oder SQL-VM ist es einfacher: nutzen Sie Backup to URL – erstellen Sie ein Full Backup Ihrer DB auf Azure Blob Storage, und stellen Sie es auf der MI/VM mit RESTORE DATABASE wieder her. Diese Methode ist meist schneller als Bacpac (da keine DATEN -> JSON Konvertierung). Sie müssen aber die DB im Quell in einen read-only Zustand bringen (Backup erfordert log chain final).
• Online Migration (Minimal Downtime): Für Situationen, wo Sie nur wenige Minuten Auszeit erlauben können, sind Online-Methoden ideal. Azure DMS im Online-Modus nutzt unter der Haube Transactional Replication (bei Azure SQL DB Ziel) oder Log Shipping/CDC (bei MI). Ablauf: Es wird ein Anfangssnapshot übertragen, währenddessen die Quelle normal weiterläuft; dann werden fortlaufend Änderungen repliziert. Am Ende gibt es einen kurzen Cutover: Quelle in read-only, letzte Änderungen rüber, dann Clients auf Ziel umstellen. So können Downtimes < 30 min erreicht werden, selbst bei großen DBs. Voraussetzung: Quell-DB muss Replikation zulassen (z.B. PKs auf allen Tabellen, keine sehr veraltete Version). Für MI gibt es den Link (falls Quelle SQL 2019+), was noch weniger Downtime bringt, da es im Prinzip AG-Failover macht. Für VMs: Evtl. VM-Replikation (z.B. Azure Site Recovery) – dort wird gesamte VM mit SQL repliziert und man startet in Azure, auch minimal down.
• Cutover & Datenabgleich: Planen Sie den Moment des Umschaltens genau. Kommunizieren Sie Endbenutzern, wann ein Wartungsfenster stattfindet. Während des Migrationsprozesses sollten Sie eine finale Validierung der Daten durchführen: z.B. Row Counts von Haupttabellen Quelle vs Ziel vergleichen, Stichproben checken (DMS kann optional einen Konsistenzcheck ausführen). Nur wenn das passt, finalisieren Sie das Cutover. Das beinhaltet: Applikationen/Verbindungen auf die neue DB zeigen lassen (Connection Strings ändern, DNS umbiegen, etc.), sowie ein Freeze der alten Umgebung (um Verwirrung zu vermeiden – ideal schaltet man alte DB schreibgeschützt). Halten Sie das alte System noch nicht sofort offline, bis Sie sicher sind, dass Neues läuft, aber verhindern Sie Doppelbuchungen oder divergente Änderungen.

Test, Cutover und Rollback

Testing darf bei einer Migration niemals zu kurz kommen. Führen Sie mindestens einen Probelauf in einer Testumgebung durch, der die Migration simuliert: dazu kann man z.B. ein Backup der Prod-DB nehmen und in Azure Test MI restaurieren, dann Applikation in Test gegen Azure laufen lassen und schauen, ob alles funktioniert (Performance, Funktionalität). Nutzen Sie diese Generalprobe, um unerwartete Fehler zu finden (z.B. Code, der auf Windows-Kollation sensitive war, oder ein Dritttool, das keinen Zugriff hat). Testen Sie auch Nichtfunktionales: z.B. ob Monitoring-Alarme ausgelöst werden wie gewünscht, ob Logs ankommen.

Beim finalen Cutover (dem Produktivwechsel) sollten alle Beteiligten anwesend oder erreichbar sein: DBAs, App-Entwickler, Netzwerk, etc., um bei Problemen schnell einzugreifen. Arbeiten Sie nach einem Runbook mit definierten Schritten: z.B. “18:00 Uhr – Users abmelden; 18:05 – DB Quelle in Read-Only; 18:10 – letzte Logs migrieren; 18:20 – App config Switch; 18:30 – Smoke-Test der Anwendung; 18:45 – Freigabe durch Fachseite, Migration success.” Halten Sie alle Zwischenergebnisse fest. Wenn etwas schiefgeht und nicht schnell behebbar ist, scheuen Sie nicht den Rollback: Es ist besser, alt wieder online zu nehmen als ein halbgare neue Prod. Daher behalten Sie die Quelle intakt, bis Erfolg bestätigt. Rollback bedeutet: Applikationen auf alte DB zurück, ggf. Nachtragen der inzwischen angefallenen Daten (man hatte ja Read-Only – es sollte nichts angefallen sein im Ideal). Das Team sollte ein Zeitfenster definieren: “Wenn bis 19:00 nicht alles grün, dann Rollback.” – und auch diesen Pfad geübt haben. In der Praxis braucht man das selten, aber sicher ist sicher.

Nach erfolgreichem Cutover gibt es oft eine Hypercare-Phase: Lassen Sie die Projekt-/Migrationsexperten noch 1-2 Wochen engmaschig überwachen, ob alles ordentlich läuft (Performance, Fehler). Oft kommen noch Nacharbeiten ans Licht – z.B. ein Wartungsskript, das auf dem alten Server lief und nun ersetzt werden muss durch Azure Automation. Planen Sie Kapazitäten dafür ein und heben Sie diese Punkte zeitnah aus.

Nachbereitung und Optimierung

Nach der technischen Umstellung ist vor der Optimierung. Jetzt gilt es, den Betrieb zu normalisieren und Vorteile der neuen Plattform auszureizen:

• Performance-Finetuning: Vergleichen Sie die Leistungsdaten vor und nach der Migration. Falls Queries auf Azure langsamer laufen, identifizieren Sie die Gründe – manchmal fehlen bestimmte Indexe (die on-prem irrelevant waren, aber in Cloud-Umgebung mit anderer IO-Latenz wichtiger sind). Nutzen Sie Query Store und ggf. Azure SQL Performance Recommendations, um solche Indexvorschläge umzusetzen. Aber implementieren Sie diese kontrolliert, nicht blind. Überprüfen Sie auch Einstellungen wie z.B. MAXDOP oder Parameter Sniffing-Phänomene, da Azure evtl. neuere Cardinality Estimator nutzt als Ihr altes System.
• Kosteneinstellungen justieren: Schauen Sie sich nach einem vollen Nutzungsmonat die Azure-Kosten im Detail an. Möglicherweise stellen Sie fest, dass ein Tier zu hoch dimensioniert ist – dann können Sie verkleinern und Kosten sparen. Oder dass man von Pay-as-you-go auf Reserved wechseln sollte, jetzt da alles stabil läuft, um Rabatte mitzunehmen. Falls Sie Pools oder mehrere DBs haben: überprüfen Sie die Poolauslastung, evtl. DBs umschichten um Kosten optimal zu verteilen.
• Betriebsdokumentation aktualisieren: Ihr Runbook für reguläre Operationen (Backup, Patching, Monitoring) muss an die neue Umgebung angepasst sein. Schreiben Sie sauber nieder, wie man z.B. einen Punkt-in-Time-Restore in Azure anstößt (Prozedur abweichend von on-prem), oder wie neue Benutzer angelegt werden (z.B. Azure AD Gruppen statt Windows Auth). Schließen Sie Wissenslücken im Team mit gezielten Trainings: z.B. ein Workshop “typische DBA-Aufgaben nun in Azure erledigen” – die Tools sind anders (Azure Portal, Powershell, CLI, etc.), das muss jeder verinnerlichen.
• Abschalten Legacy-Umgebung: Sobald sicher ist, dass das neue System stabil läuft und keine ungeahnten Probleme mehr aufpoppen, planen Sie die Stilllegung der alten Umgebung. Dazu gehört, verbleibende Daten zu archivieren (alte Server Backups vielleicht noch aufbewahren für definierte Zeit), die Server herunterzufahren, Lizenzen ggf. umzunutzen (AHB), und vor allem: die Connectivity zu alten DBs zu kappen, damit niemand aus Versehen noch gegen alte DB schreibt. Kommunizieren Sie auch an alle, dass Altsystem außer Betrieb ist.
• Weiterführende Modernisierung: Nutzen Sie den Cloud-Einstieg als Sprungbrett, um weitere Modernisierung zu prüfen. Beispiel: Jetzt, wo die DB in Azure ist, könnte man einfacher Analytics drauf betreiben – vielleicht per Azure Synapse Link oder via PowerBI mit VNet Integration. Oder man plant den Schritt von einer SQL VM zu einer Managed Instance, oder von MI zu Azure SQL DB (wenn nach Bereinigung der App doch PaaS möglich wird). Die Cloud bietet ständig Neuerungen – halten Sie sich informiert (Azure Updates für SQL). Möglicherweise gibt es künftig neue Service Tiers oder Features, die Ihre Kosten senken oder Performance erhöhen (etwa der “serverless Hyperscale” falls sowas kommt). Führen Sie also regelmäßig Architecture Reviews durch: ist unser Setup noch “State of the Art” oder können wir optimieren?

Durch sorgfältiges Migrationsvorgehen und eine lernbereite Nachbereitung holen Sie das Beste aus Ihrer neuen Azure SQL Umgebung heraus und legen den Grundstein für einen dauerhaft robusten, effizienten Datenbankbetrieb in der Cloud.

10. FAQ

Abschließend ein Fragenkatalog mit häufig auftretenden Fragestellungen rund um Azure SQL, jeweils mit prägnanter Antwort:

Frage: Welche Anforderungen gibt es für den Azure Hybrid Benefit?
Antwort: Sie benötigen aktive Software Assurance (SA) für Ihre SQL-Server-Lizenzen (oder entsprechende Abonnements). Mit SA dürfen Sie Azure Hybrid Benefit nutzen, d.h. in Azure angeben, dass Sie eine gültige Lizenz mitbringen. Azure rechnet dann nur die reduzierten “Base Rate” Kosten (ohne Lizenzanteil) ab. Wichtig ist, dass die Edition der Lizenz zur Azure-Nutzung passt (z.B. eine Enterprise Edition Lizenz kann einen vCore in Business Critical abdecken oder bis zu 4 vCores in General Purpose). Ohne SA oder qualifizierte Subscription ist AHB nicht zulässig. Stellen Sie auch sicher, dies im Azure-Portal für die jeweilige Ressource explizit einzuschalten, da es nicht automatisch erfolgt.

Frage: Wann ist das DTU-Modell noch sinnvoll?
Antwort: Das DTU-Modell (Basic/Standard/Premium) ist heute eher legacy und in wenigen Fällen angebracht. Sinnvoll kann es sein, wenn Sie eine einfach gehaltene, kleine Datenbank haben und sich nicht mit vCores beschäftigen möchten – etwa für Prototypen oder sehr kostensensitive Mini-Workloads. Auch bestehende Elastic Pools in DTU (z.B. Web/App Edition Pools aus früheren Zeiten) kann man weiter nutzen, solange sie den Bedarf decken. Für neue Projekte empfiehlt Microsoft aber klar das vCore-Modell, da es transparenter und flexibler ist (z.B. Auswahl von Compute-Generationen, separate Speicher/IO-Skalierung, Hyperscale-Verfügbarkeit etc.). Ein realer Anwendungsfall für DTU heute: Vielleicht eine einzelne 5€-Datenbank im Basic Tier für eine kleine Website – hier kann man aus Einfachheit DTU nehmen. Sobald aber Performance-Tuning oder Skalierungsthemen auftreten, stößt man mit DTU an Grenzen der Nachvollziehbarkeit. Insgesamt: Nur nutzen, wenn absolute Einfachheit und kleiner Standard-Use-Case, sonst lieber vCore.

Frage: Was sind die Unterschiede zwischen Hyperscale und General Purpose?
Antwort: Hyperscale und General Purpose sind zwei Dienstebenen von Azure SQL mit unterschiedlichen Architekturen:
– General Purpose (GP) verwendet eine klassische Speicherarchitektur – die Daten liegen auf Remote-Storage (Premium SSD) und jede Compute-Instanz hat einen lokalen SSD-Cache. Es skaliert bis zu 4 TB (SQL DB) bzw. 16 TB (Managed Instance) und bietet solide Performance für typische Workloads. Lese- und Schreibvorgänge gehen über das Netz zum Speicher, was leicht höhere Latenz bedeutet, aber für OLTP oft ausreichend ist. GP ist kostengünstiger als Business Critical, aber bietet keine Read-Scale-Out (ohne extra Geo-Replica).
– Hyperscale bricht die traditionelle Architektur auf: Es gibt separate Page Server für Datenseiten, einen Log Service für Transaktionen und beliebig skalierbare Compute-Knoten. Dadurch kann Hyperscale eine sehr große DB-Größe (derzeit bis 100 TB+) unterstützen. Backups sind quasi Sofort-Snapshots (sehr schnell, egal wie groß die DB), und man kann bis zu 30 sekundäre Compute-Replicas hinzufügen, etwa für Lesen oder isolierte Zwecke. Hyperscale hat bei Schreibmustern mit hohem Durchsatz Vorteile, weil das Log-Service entkoppelt skaliert. Allerdings ist die Lese-Latenz pro Abfrage eventuell etwas höher, weil Daten über das Netzwerk von Page-Servern geholt werden (diese halten aber viel im RAM Cache). Auch sind manche Features in Hyperscale anders – z.B. Anfangs kein native Change Data Capture (inzwischen aber unterstützt) und bestimmte sehr speichernahe Operationen könnten minimal anders performen.
Fazit: Hyperscale für sehr große oder schnell wachsende Datenbanken und Szenarien mit vielen parallelen Reads (durch verteilbare Replicas) – es bietet extrem viel Headroom. General Purpose für klassische Workloads bis mittlere Größen, bei denen vor allem Kosten und Einfachheit zählen. Beide haben die gleichen 99.99% SLA. Preislich zahlt man bei Hyperscale getrennt für Speicher, was bei hohen Datenmengen vorteilhaft sein kann.

Frage: Wie funktionieren Auto-Pause und die Kaltstartzeiten bei Azure SQL Serverless?
Antwort: Im Serverless-Betrieb einer Azure SQL Database gibt man ein Auto-Pause-Intervall vor (Minimum derzeit 15 Minuten, Standard z.B. 60 Minuten). Ist die Datenbank so lange inaktiv (keine Nutzerabfragen, nur minimale Hintergrundlast), fährt Azure sie herunter: Der Compute-Teil wird freigegeben – Sie zahlen dann nur noch Storage-Kosten. Beim ersten neuen Verbindungsversuch “wacht” die DB automatisch wieder auf. Diese Wiederanlaufzeit ist der Kaltstart. In der Regel dauert das etwa 30–60 Sekunden, kann aber je nach Last und Aufwärmen der Daten bis zu ein paar Minuten betragen. Während dieser Zeit bekommt der anfragende Client einen Verbindungsversuch, der verzögert ist (ggf. Timeout, wenn nicht entsprechend konfiguriert). Nach dem Resume stehen sämtliche Daten unverändert bereit, aber Caches (Buffer Cache) sind leer, sodass anfänglich Abfragen etwas langsamer laufen, bis das Working Set wieder im Memory ist. Man kann den Kaltstart etwas mildern, indem man Minimale vCores nicht auf 0 setzt (d.h. die DB nicht komplett schlafen legt, sondern z.B. min 0,5 vCore belässt – dann entfallen echte Pause und Kaltstart, es wird nur dynamisch skaliert). Aber dann zahlt man natürlich diese Mindestleistung durchgehend. Zusammengefasst: Auto-Pause spart viel Kosten bei Idle-Zeiten, aber man muss den etwa einmaligen Latenzschub beim Wiederaufwachen in Kauf nehmen; für interaktive Anwendungen sollte man einen entsprechenden Retry-Mechanismus im Verbindungsaufbau implementieren.

Frage: Wie wird LTR (Long-Term Retention) abgerechnet und wie lange kann man Backups aufbewahren?
Antwort: Bei Azure SQL ist die Kurzzeit-Aufbewahrung (PITR) bis 7/14/35 Tage inklusive im Dienst. Long-Term Retention (LTR) – also Wochen-, Monats-, Jahresbackups über längere Zeit – wird primär nach dem genutzten Speicherplatz abgerechnet. Jedes LTR-Backup (ein vollständiges DB-Backup) kostet pro GB und Monat (Preis variiert je nach Speicher-Art, meist Standard RA-GRS Storage-Kosten). Azure bietet bis zu 10 Jahre Aufbewahrung für LTR-Backups. Konkret kann man konfigurieren: z.B. behalte jede Wochen-Sicherung 12 Wochen, jede Monats-Sicherung 12 Monate, jede Jahres-Sicherung 5 Jahre – entsprechend werden diese Kopien aufbewahrt und belegen Speicher. Die Abrechnung summiert die Größe all dieser Backups. Es gibt kein zusätzliches “Transaktionsgebühr” – nur der Storage. Wenn Ihre Datenbank z.B. 100 GB groß ist und Sie pro Jahr eine Jahresbackup 5 Jahre aufheben, zahlen Sie grob 5100 GB an Storage (plus Replikation Overhead falls RA-GRS). Achten Sie darauf, nicht unnötig viele Backups aufzubewahren – überlegen Sie, ob Wochenbackups nach X Monaten gelöscht werden können wenn Monatsbackup vorhanden etc., um Speicher zu sparen. In der Praxis definieren Unternehmen oft: Wöchentlich 4 Wochen, monatlich 12 Monate, jährlich 7 Jahre (typische Compliance). LTR-Backups werden komprimiert gespeichert, was etwas Platz spart, aber planen Sie eher konservativ, Speicher kostet übers Jahre sonst doch spürbar. Tipp: Überwachen Sie den LTR Storage Usage* (Azure zeigt an, wie viel GB pro DB verwendet werden), damit keine Überraschungen entstehen. In Sachen Aufbewahrungslimits: 10 Jahre ist Maximum in Azure. Falls Sie darüber hinaus aufbewahren müssen (z.B. 30 Jahre Archiv), müssten Sie Backups herunterladen und off-site archivieren, was aber selten erforderlich ist.

Frage: Kann ich SQL Agent-Jobs in Azure nutzen – wo und wie?
Antwort: Ja, aber es hängt vom Azure SQL-Modell ab:
– In Azure SQL Managed Instance ist der SQL Server Agent voll verfügbar. Sie können Ihre bestehenden Jobs (Wartung, ETL usw.) praktisch unverändert dort einrichten. Managed Instance unterstützt auch SQL Agent Alerts und Operatoren wie on-prem (z.B. E-Mail via Database Mail – letzteres muss ggf. anders konfiguriert werden, da DB Mail in MI keinen offenen SMTP nach extern zulässt, aber interne Weiterleitung geht). Kurz: MI ≙ instanzäres SQL, Agent da.
– In Azure SQL Database (Single/Elastic Pools) gibt es keinen eingebauten SQL Agent. Hier müssen Sie alternative Wege nutzen: Microsoft bietet den Elastic Job Agent, einen Dienst, den man einmal pro Server (bzw. Ressourcengruppe) einrichten kann. Dieser kann ähnliche Aufgaben wie Agent übernehmen – Sie definieren Jobs mit T-SQL-Schritten, die dann nach Zeitplan auf Ziel-Datenbanken ausgeführt werden. Insbesondere für Multi-DB-Szenarien (z.B. alle DBs eines Pools indexieren) ist das geeignet. Der Elastic Job Agent läuft in einer eigenen kleinen DB (Job DB) und führt die Steps asynchr. aus. Alternativ kann man Azure Automation mit PowerShell-Runbooks einsetzen, um periodisch T-SQL Skripte gegen die DB zu feuern. Oder Azure Logic Apps/Functions falls man lieber in Event-driven Code geht. Auch Drittanbieter-Tools am Markt (z.B. scheduling über Orchestratoren) sind nutzbar. Es hängt davon ab, ob der Job rein DB-intern ist (dann Elastic Jobs ideal) oder komplexere Aktionen orchestriert (dann Automation).
– Auf SQL Server auf Azure-VMs bleibt alles beim Alten: der SQL Agent ist Bestandteil der SQL Server Installation und läuft wie gewohnt. Man kann hier sogar, wenn gewünscht, den Agent als zentralen Scheduler für Azure SQL DB nutzen, indem die VM via Linked Server oder direkten Connector auf die PaaS-DB zugreift – aber das mischt die Welten unnötig, besser PaaS-intern bleiben.

Zusammengefasst: Managed Instance – Agent nativ verfügbar. Azure SQL DB – Ausweichen auf Elastic Jobs oder Automation. In vielen Fällen lässt sich damit fast alles abbilden, was Agent konnte (Backups sind in PaaS eh auto, Index Maintenance können Ola Hallengren-Skripte via Elastic Job laufen, etc.). Die Einrichtung erfordert einmalig etwas Aufwand, aber Microsoft hat Vorlagen dafür.

Frage: Gibt es Grenzen bei Cross-Database-Queries oder Linked Servern in Azure SQL?
Antwort: Ja, besonders bei Azure SQL Database gibt es Einschränkungen:
– Cross-Database-Queries: In Azure SQL Database (Single), jeder Datenbank ist isoliert. Dreiteilige Namen (Server.DB.Schema.Tabelle) funktionieren nicht wie on-prem (es gibt kein gemeinsames Instanz-Katalog). Allerdings können Sie per Elastic Query arbeiten: Man kann eine externe Datenquelle einrichten (etwa eine andere Azure SQL DB oder sogar SQL Managed Instance) und dann in einer DB External Tables definieren, die auf die andere verweisen. Dies ermöglicht selektive Cross-DB-Abfragen, aber es ist etwas umständlicher und nicht so nahtlos wie “USE AndereDB; SELECT …”. Transaktionen über externe Tabellen hinweg sind eingeschränkt. In Managed Instance hingegen können Sie nahezu wie on-prem arbeiten: alle Datenbanken auf der MI sind über drei-teilige Namen ansprechbar und unterliegen derselben Instanz. Cross-DB-Transaktionen werden unterstützt (Verteilung auf mehrere Datenbanken in einer Transaction Unit).
– Linked Server: In Azure SQL Database (Single) gibt es keine Linked Server-Funktionalität. Sie können keine OLE DB-Verknüpfungen einrichten. Der Weg wäre wiederum externe Datenquellen (für Azure SQL) oder auf App-Ebene zu integrieren. In Managed Instance sind Linked Server zu bestimmten Zielen möglich: z.B. man kann einen Linked Server zu einer anderen SQL Managed Instance oder einem on-prem SQL Server einrichten, sofern die Netzverbindung besteht (MI erlaubt Ausgehend auch SQL-Verbindungen). Nicht alle Treiber sind erlaubt – z.B. einen Linked Server auf eine Access-DB geht natürlich nicht, da MI keine ACE-Engine hat. Externe Datenquellen mit PolyBase (für Oracle, Teradata etc.) sind in MI ebenfalls (derzeit) nicht verfügbar, da PolyBase Service fehlt. Linked Server zwischen zwei DBs auf derselben MI ist gar nicht nötig (kann direkt query), aber zu anderen MI oder SQL-VMs wird in manchen Migrationsszenarien genutzt (z.B. um Schrittweise zu migrieren). Beachten: MI unterstützt kein MSDTC für verteile Transaktionen nach extern – Cross-db intern ja, cross-server nein (zumindest Stand SQL 2019).
Fazit: Planen Sie mit dem Grundsatz „Azure SQL Database: keine direkten Cross-DB oder Linked Server – Alternative Patterns nötig; Azure SQL MI: Cross-DB intern ja, Linked Server eingeschränkt extern ja, aber verteile Transaktionen eher nein.“ Falls Ihre Anwendung massiv auf Linked Server Logik baut, ist MI fast zwingend, oder eben VM.

Frage: Welche Hochverfügbarkeits-Optionen sind “managed” in Azure, und was muss ich selbst bauen?
Antwort: In Azure SQL Database und Managed Instance sind lokale Hochverfügbarkeit (in der Region) und automatische Failover größtenteils vom Service gemanagt. Jede Datenbank/Instanz hat standardmäßig HA mittels gestreamter Redundanz (basierend auf AlwaysOn-Technologie): Ein Hardware-Ausfall führt zu failover auf eine Sekundärkopie innerhalb von ~30 Sekunden bis 1-2 Minuten, ohne Ihr Zutun. Sie können diese HA noch verbessern, indem Sie Zone Redundancy aktivieren (wenn verfügbar), womit die Kopien in unterschiedlichen Availability Zones liegen – das schützt gegen Rechenzentrums-Ausfall in der Region (Azure SQL DB: per Toggle in Premium/BusinessCritical; MI: BC Tier standard zones, GP Tier optional preview). Das ist alles managed – Sie müssen keine Listener, Cluster oder dergleichen konfigurieren. Für regionale Ausfälle (Desasterfall) hingegen liefert Azure zwar Features, aber Sie müssen sie selbst einrichten: In Azure SQL DB nennt es sich Active Geo-Replication (bis zu 4 sekundäre DBs in anderen Regionen), bzw. in beiden PaaS-Services gibt es Auto-Failover Groups (zusammenfassende Replikation und failover Mechanismus für mehrere DBs / MI). Diese Konfiguration (Zielregion, Read/Write, FailoverPolicy etc.) liegt in Ihrer Verantwortung – Azure kümmert sich dann wieder um die Replikation und Failover-Mechanik, sobald eingerichtet, aber “out of the box” passiert Geo-DR nicht ohne Ihr Zutun. Sie müssen auch Ihre App so bauen, dass im Failoverfall der Wechsel erfolgt (z.B. durch nutzung des .database.windows.net-Sekundärendpunktes).
Auf VMs oder on-premises ist gar nichts managed: Sie müssen, wie gehabt, entweder Failover Cluster Instances oder Always On AGs aufbauen, oder simpler: SQL Log Shipping, Replikation etc. Azure bietet hier nur Bausteine: z.B. Azure Shared Disk + WSFC falls Sie FCI in Azure VM wollen, oder Templates für AG-Setups. Es gibt auch den SQL VM Marketplace-Image mit HA-Config, wo etwas Automatisierung passiert (gibt Deploy-Skript), aber im Betrieb liegen Patches, Failover etc. bei Ihnen. Auch Backup müssen Sie auf VMs selbst verwalten (Azure Backup kann helfen, aber es ist Ihr Plan).
Zusammengefasst: Managed (plattformgesteuert) HA: Innerhalb Region: immer gegeben bei PaaS. Multi-Region DR: möglich über Azure-Funktionen, aber Einrichtung und Test durch Kunde. Self-build: ALLES bei SQL auf Azure VM und on-prem: Clustering, Mirroring (früher), AGs, etc. Azure kann das Umfeld (VMs, LB, witness in Cloud etc.) stellen, doch die Konfiguration obliegt Ihnen.
Noch ein Nebenaspekt: Datensicherungen sind auch Teil von HA/DR – hier sind PaaS Backups managed (inkl. full/diff/log). Bei VMs müssen Sie Sicherungen selbst planen. Und Monitoring der HA: bei PaaS erhalten Sie z.B. Alerts, falls Failover stattfand, aber es ist im großen eine interne Automatik – Sie können sich drauf verlassen. Bei eigenem AG sollten Sie selbst Monitorings setzen (AG Role Change Alerts, Queue length etc.).

Frage: Geo-Replikation: Was sind typische RPO/RTO, Kosten und wie teste ich das?
Antwort: Geo-Replikation (Active Geo-Replication bei SQL DB, Failover Groups bei DB oder MI) arbeitet asynchron. In der Praxis bedeutet das:
– RPO (Recovery Point Objective): Im Normalfall liegt der Rückstand im Sekundenbereich, oft < 5 s, da Azure über hochoptimierte Netzwerke repliziert. Es gibt aber keine garantierte 0-Sekunden-RPO, da asynchron – bei einem abrupten Primärausfall können die letzten Transaktionen fehlen. Microsoft spricht von typ. < 30s. Planen Sie also konservativ eine RPO von einigen Sekunden bis zu 1-2 Minuten ein, falls mal Netzprobleme waren.
– RTO (Recovery Time Objective): Wenn Sie manuell Failover auslösen, ist die Ziel-DB sofort verfügbar, es muss nur DNS umschalten (bei Failover Group) oder Connectionstring geändert. Das dauert Sekunden. Automatisches Failover (in Failover Groups optional) detektiert Ausfall und schwenkt in ~1 Minute um. Insgesamt kann man mit unter 1-2 Minuten RTO rechnen in besten Fällen. Aber sicherer: unter 5 Minuten, falls Verbindungsversuche etc. neu aufbauen. Für Business Continuity gilt das als sehr gut.
Kosten: Jede Geo-sekundäre Datenbank oder MI kostet genauso viel wie die primäre (da es quasi eine vollständige Instanz ist). Es gibt keinen Rabatt für passive Kopie – sie ist ja nutzbar (readable). Das heißt, wenn Sie z.B. eine 8 vCore DB in West-Europa haben und eine Geo-Replica in Nord-Europa einrichten, verdoppeln sich die Compute-Kosten (plus etwas Datenübertragungskosten für die Replikation – diese werden als Outbound Traffic vom Primär berechnet; innerhalb EU aber moderate Gebühren pro GB). Wenn Sie in Failover Group Modus sind, können Sie die Secondary auf read-only belasten (z.B. Reporting), dann schöpfen Sie Wert daraus. Wenn nicht, zahlen Sie für Bereitstellung im Leerlauf. Daher sind Geo-DR-Kopien oft nur für mission-critical DBs sinnvoll, bei denen Downtime große Schäden verursacht.
Testen: Sie sollten regelmäßig das DR-Szenario testen. Dazu gehört ein geplantes Failover: Azure erlaubt, aktiv ein Failover auszulösen (im Portal oder PowerShell). Tun Sie das z.B. vierteljährlich in einer kontrollierten Downtime: Verbindungen trennen, Failover klicken, Ihre App auf neue Region zeigen – läuft alles? Danach können Sie wieder zurück failovern (bzw. Azure macht auto-fallback nicht, müssten manuell zurückschalten – planen Sie auch das). So gewinnen Sie Sicherheit in Ablauf und Dauer. Azure Failover Groups haben einen Feature “Failover testen” indirekt, aber meist macht man es einfach. Achten Sie darauf, dass beim Test keine Daten verloren gehen – d.h. wenn möglich, simulieren Sie nur oder nutzen eine Test-DB. In Prod kann man es aber auch riskieren, wenn man z.B. ne Wartung ausnutzt.
Zusätzlich sollten Sie auch Verbindung und Konfiguration testen: z.B. sind in Secondary alle Logins/Sicherheitsobjekte vorhanden (Azure AD user replicieren sich z.B. in Failover Group automatisch mit, aber klassische Logins bei MI müssen Sie auf beiden Seiten anlegen)? Und prüfen Sie, ob Ihre Anwendung die failoverbedingte neue Serveradresse verträgt (bei Failover Groups bleibt der DNS-Name gleich, das ist ideal, bei Einzel-GeoReplica muss Connectionstring angepasst werden). Simulieren Sie auch mal einen ungeplanten Ausfall (z.B. killen Sie in Test die primäre DB), und schauen ob die App sauber Fehler handhabt bis Failover passiert. Solche Drills sind Gold wert für Vertrauen.

Frage: Private Endpoints vs. öffentliches Endpoint-Modell – was ist der Unterschied?
Antwort: Azure SQL Database bietet standardmäßig ein öffentliches Endpoint: das bedeutet, Ihr Server hat eine URL yourserver.database.windows.net und ist unter einer öffentlichen IP erreichbar. Zugriffe werden durch die SQL Firewall (IP-Zulassungsliste) und ggf. SQL Logins/AAD authentifiziert abgesichert. Im öffentlichen Modell können Clients aus dem Internet (oder Azure VM etc.) verbinden, sofern ihre IP freigeschaltet ist. Private Endpoint hingegen ermöglicht es, eine private IP im eigenen Azure VNet für den Azure SQL Server zu erhalten. Wenn eingerichtet, wird der Datenverkehr über das Azure Backbone in Ihr VNet getunnelt, und die öffentliche Adresse ist – je nach Konfiguration – nicht mehr nötig oder erreichbar. Praktisch haben Sie dann z.B. yourserver.privatelink.database.windows.net alias, der auf eine 10.x.x.x Adresse in Ihrem VNet zeigt. Der Vorteil: Keine Exposition im Internet, selbst mit Firewall. Außerdem können Sie so von On-Prem via ExpressRoute/VPN direkt die private IP ansteuern, ohne über öffentlichen DNS zu gehen. Unterschiede/Besonderheiten: Mit Private Endpoint müssen Sie auch das DNS anpassen – Sie brauchen entweder Custom DNS-Server oder Hostfile-Einträge, damit yourserver.database.windows.net auf die private IP zeigt (Azure bietet dafür einen privaten DNS-Zone Mechanismus). Weiterhin gilt: Private Endpoint ist pro Server/MI einzeln einzurichten; bei MI allerdings nutzt man oft die native VNet-Integration, was ähnliches Ergebnis hat (dort ist per se privat). Ein Public Endpoint plus Firewall “AllowAllAzureServices” war früher eine Option, aber unsicherer. Private Endpoints sind deutlich sicherer, weil man selbst im Azure Rechenzentrum isoliert (es wird ein NIC in Ihrem VNet gehostet; Traffic muss z.B. Ihren NSGs und Policies entsprechen). Public Endpoint modul ist simpler in Erstverbindung (Portal etc.), aber man sollte streng die IP-Firewall setzen. Für echte Produktionsdaten, vor allem wenn auch Compliance es will, sind Private Endpoints heute Best Practice. Zusammengefasst: Public Endpoint – erreichbar über Internet, gesteuert per FW, einfacher Setup; Private Endpoint – End-to-End privates Netzwerk, erfordert DNS/Netz-Konfig, bietet maximale Isolation.

Frage: Wie messe ich meinen I/O-Bedarf und wähle das richtige Leistungs-Tier?
Antwort: Ihren I/O-Bedarf messen Sie idealerweise auf dem bestehenden System im Alltag. Nutzen Sie PerfMon oder DMVs auf dem SQL Server, um Kennzahlen zu sammeln: Transaktionslog-Ausgabe (MB/sek), Datenbank-Lese-/Schreib-IOPS, Durchschnittliche Latenz der Platten, Arbeitsspeicher-Cache-Hitrate etc. Tools wie das Microsoft MAP Toolkit oder DMA können auch helfen, eine Workload-Kategorie zu empfehlen. Wenn Sie schon auf Azure VM sind, schauen Sie in die Disk Metrics. Für die Auswahl in Azure: Die Service Tiers unterscheiden sich u.a. in I/O-Leistung:
– General Purpose (vCore): Basiert auf Remote-Storage. Die IOPS sind ungefähr begrenzt durch max 36 MB/s pro vCore (lesend) und 20 MB/s pro vCore (schreibend) – das sind ~288 Mb/s bei 8 vCores lesend. Für viele OLTP-Anwendungen reicht das, aber wenn Sie z.B. >50k IOPS Spitzen haben oder viel intensives Schreiblogging, könnte es eng werden. Außerdem GP hat höhere Latenz (2-5ms plus) bei IO.
– Business Critical (vCore): Hat lokal SSD und 3 synchron Replikate – Sie bekommen sehr viel I/O-Headroom. Microsoft gibt grob an: mehrere 100k IOPS möglich, und Latenzen <1ms intern. Daher: Wenn Ihr aktuelles System High-End SAN oder Local SSD brauchte, um IOPS-Bedarf zu decken, ist BC wahrscheinlich nötig.
– Hyperscale: Hier skaliert IO mit Anzahl Page-Server: i.d.R. sehr hohe Read-Durchsätze möglich (viele parallel Reader), Schreibdurchsatz gut parallelisierbar, aber einzelne Tansaktionen latenzseitig in etwa wie GP oder leicht höher. Also, Hyperscale glänzt, wenn große MB/s Durchsätze und viele gleichzeitige Readstreams gefordert sind (Datawarehouse artig).
– DTU-Modelle (Basic/Standard/Premium): Hier sind DTUs eine Kombikennzahl – ein S3 hat z.B. 120 DTUs ~ IOPS im niedrigen Tausenderbereich. Premium P15 ~ 5000 DTU hat ~ 75k IOPS. Microsoft hat Tabellen publiziert, wir würden es aber hier nicht vertiefen, da vCore präferiert.
Also, messen Sie z.B. in Stoßzeiten: Peak Log Bytes Flushed/sec. Ist der Wert > 20 MB/s, könnte GP limit erreicht werden (GP hat ~ 22 MB/s per DB log limit). Dann tendiert man zu BC. Messen IOPS – wenn Spitzen > 5000, auch Richtung BC oder Hyperscale. Oft ist es aber auch eine Option, in GP mehr vCores bereitzustellen als nur wegen CPU nötig, um IO-Quota zu erhöhen. Das kostet, aber kann Lücke schließen. Insbesondere MI GP hat je nach Gen Begrenzungen (8TB mit ~5k IOPS pro 1TB Disk – ergo bei 8TB ~40k IOPS max, aber pro vCore Log 4.5MB/s). Wenn Sie unsicher sind, starten Sie lieber mit höherem Tier (BC) und downgraden später – Performance-Probleme sind kritischer. Sie können auch Azure Benchmark Tools in einer Test-MI laufen lassen (z.B. Diskspd in MI via xp_cmdshell geht zwar nicht, aber man kann ein Insert-Test etc. machen). Im Zweifel, konsulieren Sie Azure Advisor oder den DMS Assessment, der mittlerweile auch tier-Empfehlung gibt. Zusammengefasst: IO-intensiv (viele writes, viele concurrent reads) -> Business Critical/Hyperscale; moderate IO -> General Purpose.

Frage: Welche Azure-Region soll ich wählen bezüglich Datenresidenz/Compliance?
Antwort: Wählen Sie die Region primär dort, wo Ihre Daten gesetzlich liegen dürfen und wo Ihre Nutzer sie brauchen. In der Regel nimmt man die geografisch nächstgelegene Azure-Region, um geringe Latenz zu erzielen. Gleichzeitig müssen Sie z.B. DSGVO beachten – für EU-Personendaten eine Region innerhalb der EU (z.B. “West Europe” in NL oder “Germany West Central” etc.). Manche Länder haben eigene Anforderungen – z.B. Schweiz: es gibt Switzerland North/West für Daten, die im Land bleiben müssen. Wenn Sie global tätig sind, könnten Sie z.B. Daten von EU-Kunden in EU-Region hosten, US-Kunden in USA-Region. Azure bietet viele Regionen, aber nicht jede Dienstvariante ist überall verfügbar – prüfen Sie vorab (z.B. MI gab es anfangs nicht in kleinen Regionen). Compliance: Für streng regulierte Bereiche (Öffentlicher Sektor, Verteidigung) gibt es separate Clouds/Regionen wie Azure Government (USA) oder Azure Deutschland (das alte isolierte – wird aber kaum noch genutzt). In den meisten Fällen reichen die Public-Cloud-Regionen mit den einschlägigen Zertifizierungen. Also: Wenn Daten innerhalb eines Rechtsraums bleiben sollen (EU, UK, CH etc.), wählen Sie entsprechende Region. Berücksichtigen Sie auch Resilienz: Wenn Sie DR einrichten wollen, wählen Sie ein Regionen-Paar – z.B. primär “North Europe”, sekundär “West Europe” (Azure hat definierte Paare). So bleiben auch in DR die Daten im gleichen Raum und MS garantiert, diese Paar regionen werden nicht gleichzeitig updaten etc. Für Multi-National: es kann Sinn machen, separate Instanzen in mehreren Regionen aufzubauen, wenn z.B. Latenz über Ozean ein Problem ist. Und final: Halten Sie schriftlich fest, warum Sie welche Region wählten – Auditoren fragen das. Azure gibt in seinem Compliance Doku an, wo Daten physisch liegen (z.B. Meta-Daten, Backups – i.d.R. innerhalb Region oder deren Pair). Alles in allem haben Sie viel Wahl, aber oft ist “West Europe” ein guter Default für EU-Kunden und “Switzerland” für CH-lokale Daten etc., je nach Ihrem Sitz und Kundschaft.

Frage: Wie setzt man Mandantenfähigkeit mit Elastic Pools am besten um – gibt es Best Practices?
Antwort: Ja, bei Multi-Tenant-Apps mit Elastic Pools haben sich einige Best Practices etabliert:
– Mandanten-Isolation: Geben Sie jedem Mandanten eine eigene Datenbank (das ist ja der Pool-Ansatz). So sind Daten sauber getrennt und können nicht versehentlich vermischt werden.
– Pool-Gruppe nach Lastprofil: Gruppieren Sie Mandanten mit ähnlichem Nutzungsverhalten in denselben Pool. Z.B. ein Pool für “Free/Trial”-Tenants, die meist inaktiv sind – dieser Pool kann klein dimensioniert sein, weil die Wahrscheinlichkeit, dass alle gleichzeitig aktiv sind, gering ist. Einen anderen Pool für “Enterprise”-Tenants, die größere Daten und höhere Grundlast haben – dieser Pool bekommt mehr Ressourcen. Wichtig ist: vermeiden Sie, einen “lauten” Tenant mit vielen “leisen” im selben kleinen Pool, sonst riskieren Sie Noisy Neighbor. Besser heavy user in eigenen (oder mit Gleichgesinnten).
– Pool-Größe überwachen: Starten Sie mit vernünftigen Annahmen (z.B. 1 Pool mit 4 vCores für 50 kleinere Kunden). Überwachen Sie dann den Pool’s CPU/DTU% und eDTU max consumption. Wenn oft am Limit, skalieren Sie Pool rauf oder verteilen in zwei Pools. Pools können online skaliert werden – nutzen Sie das z.B. zu Stoßzeiten (monatl. Reports) temporär erhöhen, danach wieder reduzieren – so sparen Sie Geld.
– Einzel-DB Grenzen verwenden: In Pools kann man für jede DB ein eDTU-Minimum und -Maximum setzen (im DTU-Pool verfügbar, im vCore-Pool Preview). Setzen Sie ein Max pro Tenant, um zu verhindern, dass einer den gesamten Pool frisst. Beispiel: Pool 100 eDTUs, setzen: kein DB darf >50 eDTUs ziehen. So bleibt auch bei einem Ausreißer die Hälfte für andere.
– Mandantenzuordnung verwalten: Führen Sie ein Verzeichnis (Mapping), welcher Tenant in welchem Pool ist. So können Sie leicht herausfinden, wenn ein bestimmter Tenant Performanceprobleme hat, ob sein Pool knapp ist. Sie können dann Tenant X in einen anderen Pool verschieben (manuell via Create DB Copy in neuen Pool, altes droppen – etwas Aufwand, aber machbar). Halten Sie Pools flexibel – das heißt das Umziehen sollte seltener Fall sein, aber designen Sie so, dass App damit umgehen kann (z.B. ConnectionString pro Tenant aus Config holen, anstatt fest verdrahtet).
– Schema Management: Alle Tenant-DBs sollten das gleiche Schema haben (Versionierung). Pflegen Sie Schemaupdates per Skript über alle DBs – z.B. via Elastic Job Agent, der gegen eine Tag- oder Namensliste iteriert. Automatisieren Sie das, sonst wird es unwartbar.
– Überwachung pro Tenant: Nutzen Sie Azure Monitor Diagnostic: Es kann Metriken pro Datenbank (auch im Pool) erfassen. Legen Sie z.B. ein Alert: “Wenn Datenbank CPU >80% 5min” – mit dynamischem Kriterium auf alle DBs im Pool. So bekommen Sie mit, falls ein einzelner Tenant ständig Hochlast hat – evtl. Kandidat für eigenes Tier.
– Optimierung der Kosten: Pools lohnen sich, wenn nicht alle DBs gleichzeitig Spitzenlast haben. Sollte Ihr SaaS mal Phase haben, wo sehr viele Tenants zugleich aktiv sind (z.B. Montags 9 Uhr), stellen Sie sicher, Pools sind groß genug oder segmentiert nach Zeitzone etc., um dem Druck standzuhalten. Sonst drohen Pools throttling. Bei extremer Auslastung aller könnte es günstiger sein, einige aus dem Pool zu lösen und dediziert laufen zu lassen. Überprüfen Sie daher periodisch die Utilisation.
– Namenskonvention: Geben Sie Tenant-DBs z.B. den Namen des Kunden oder eine ID im Namen. Das erleichtert die Zuordnung im Portal/Monitoring. Wenn Anonymisierung nötig (Mandanten nicht nach außen zeigen), nutzen Sie interne ID mit Mapping.
– Sicherheit: Stellen Sie sicher, dass Mandanten nicht auf DBs anderer zugreifen können: Verwenden Sie separate Logins pro DB (so kann sich ein Tenant nur in seine DB verbinden). In der App-Seite sollte Verbindungsstring kein Server-level admin sein, sondern definieren Sie SQL User pro DB. So selbst wenn ConnectionString bekannt würde, kein Zugriff auf fremde. Azure hat kein Konzept, das isoliert in Pools schiefgehen könnte, aber auf Applayer streng isolieren.
– Skalierung: Falls ein Tenant wächst über Pool-Fähigkeit (z.B. Daten > Pool-DB Limit, oder ständige hohe Last): Planen Sie ein “graduation”. D.h. Tenant raus aus Pool, entweder in eigene Azure SQL DB (vCore, reserved etc.) oder auf MI/VM wenn nötig. Das kann Teil Ihres Offering sein (“Sehr großer Kunde bekommt dedizierte Instanz”).
– Dokumentation & Kommunikation: Informieren Sie Kunden, dass ihre Daten isoliert sind (gut für Vertrauen). Aber erwähnen Sie ggf. nicht zu detailliert Pools, das ist intern. Stellen Sie sicher, Mandantenperformance ist Teil Ihres SLO – Pools sind Mittel zum Zweck.

Kurz: Elastic Pools sind großartig für Multi-Tenant SaaS, wenn Sie sie aktiv managen und überwachen. So erreichen Sie hohe Ressourceneffizienz und dennoch Mandantenzufriedenheit.

Frage: Wie vermeide ich Kostenfallen wie Egress, Replikate oder übermäßige LTR-Speicherung?
Antwort: Mehrere Aspekte:
– Daten-Egress: Das ist die Gebühr für ausgehenden Datenverkehr aus Azure-Rechenzentren ins Internet oder on-prem. Vermeiden können Sie es durch Lokalität: Platzieren Sie Ihre App-Server in derselben Region wie die DB, dann sind Abfragen innerhalb Azure kostenlos. Wenn Clients Berichte ziehen, überlegen Sie, ob Sie Caching oder Komprimierung nutzen – je weniger Rohdaten raus, desto weniger Egress. Ein typischer Stolperstein: Wenn man Azure SQL an on-prem ETL anbindet, und täglich riesige Datensätze runterlädt – hier wäre es besser, den ETL auch in Azure zu fahren oder Ergebnisse aggregiert zu übertragen. Also: Daten so weit wie möglich innerhalb Azure halten. Tracken Sie egress im Azure Cost Management, es lässt sich dem SQL-Account nicht direkt ansieht, aber über Netzwerk abrufen.
– Replikate (Geo- oder Read-Replicas): Jedes zusätzliche Replikat kostet fast wie ein zweites DB. Daher: Nur einsetzen, wenn Mehrwert. Z.B. das kostenlose Read-Secondary in Business Critical nutzen (why not, ist includiert!). Aber ein extra named replica in Hyperscale – brauchen wir 4 oder reicht 1? Bescheiden planen. Bei Geo-DR nicht default alle DBs replizieren, sondern nur wirklich kritische – die Kosten für lauter selten genutzte Geo-Kopien summieren sich. Und falls Sie Replikate haben: Abschalten, sobald nicht mehr nötig. Beispiel: Ein Projekt hatte Zweigstelle in USA, daher Geo-Replica in USA. Später keine aktive Nutzung mehr dort – dann kann man diese auflösen. Also regelmäßig prüfen: “Brauchen wir das Replikat noch?”
– Long Term Retention (LTR): Wie oben erwähnt, jeder aufbewahrte Backup kostet. Kostenfalle: man klickt LTR an und vergisst es, nach 2 Jahren hat man zig TB an Backups (gerade bei wachsender DB). Dagegen hilft: Policy mit Ablauf: z.B. nicht jede Woche ewig, sondern nach 1 Jahr raus. Azure LTR erlaubt Feinsteuerung (z.B. keep 1 yearly per X). Nutzen Sie das. Und monitoren Sie den Storage. Vielleicht halten Sie initial zu viel vor (Freitag jeder Woche 5 Jahre -> 260 full Backups!). Reduzieren Sie auf notwendige (vielleicht letzter Freitag im Monat nur, Wochen nur 2 Monate etc.). Wenn Regulierung “bis 10 Jahre alles” – dann budgetieren Sie das bewusst, da vermeidbar ist es nicht.
– Überdimensionierung: Das ist wohl die größte Cloud-Kostenfalle: man bucht lieber zu groß, “um safe zu sein”, und vergisst, wieder runterzuskalen. Vermeidung: Setzen Sie Alerts auf niedrige Auslastung (z.B. “DTU durchschnitt < 5% seit 7 Tagen” => vielleicht Overkill Tier). Machen Sie quartalsweise Cost Review, um solche Dinge zu finden.
– Unnötig laufende Ressourcen: Auto-pause und planmäßiges Stoppen von Testsystemen einführen, damit keine VM/MI 24/7 läuft wenn’s abends keiner braucht.
– Datenbankanzahl vs. Pool: Viele Einzel-DBs auf hoher Tier summieren sich – Pools nutzen kann Kosten sparen. Andersrum: Pools mit nur 1-2 DBs können ineffizient sein – dann lieber einzelne vCore DBs. Also “Rightsize” Pools vs Single DB je nach count.
– Netzwerk-Peering-Kosten: Bei manchen Architekturen fällt auch VNet Peering Traffic an (z.B. App in VNet A, DB in VNet B, dazwischen minimaler Preis). Nicht riesig, aber grosser Traffic intern kann auch was kosten. Hier möglichst alles in ein VNet oder minimal Traffic.
– Monitoring/Logs: Wenn Sie alle Telemetriedaten in Log Analytics ewig speichern, zahlen Sie auch dafür. Hier auf rationales Niveau einstellen (z.B. Detail-Query-Logging nur bei Bedarf).

Im Kern: Regelmäßig Kosten analysieren, herausfinden “wofür zahlen wir am meisten” und fragen “ist das nötig, gibt’s Alternative?”. Oft kann man dann Stellschrauben wie oben finden.

Frage: Wie skaliere ich geordnet, z.B. zeitgesteuert oder aufgrund von Ereignissen?
Antwort: Es gibt ein paar Mechanismen, um Azure SQL Ressourcen geordnet hoch- oder runterzuskalieren:
– Zeitgesteuert (Schedule): Wenn Ihre Lastprofile bekannt sind (z.B. werktags 8-18 Uhr hoch, nachts gering), können Sie mittels Azure Automation oder Azure Functions mit Timer-Trigger Skripte ausführen, die die Dienstebene ändern. Azure stellt REST-APIs/PowerShell für “Update SQL Server” bereit, worüber man z.B. vCore-Anzahl anpasst. Beispiel: Ein Automation Runbook, das jeden Abend 20 Uhr Set-AzSqlDatabase -Name X -ComputeGeneration Gen5 -VCore 4 (runterskalieren) und morgens -VCore 16 (hochskalieren) durchführt. Das sollten Sie natürlich langsam und in wartungsarmen Zeiten machen, da eine kurze Verbindungsunterbrechung auftreten kann. Mit solcher festen Zeitplan-Skalierung sparen viele Kunden bares Geld für z.B. Dev/Test oder weniger kritische Workloads.
– Ereignis-/lastbasiert (Auto-Scale): In Azure SQL Database Single gibt es Serverless, was dies automatisch übernimmt – d.h. reagiert auf CPU/Anfragen. Außerhalb von serverless gibt es (Stand heute) kein eingebautes Auto-Scale. Aber Sie können selbst triggers setzen: Azure Monitor kann z.B. Alarm “CPU > 80% 15min” auslösen, dieser Alarm kann via Action Group ein Azure Function anstoßen, die die Skalierung durchführt. Das ist eigenbau, aber machbar. Microsoft hat für VMs und AppService solche AutoScale-Rules out-of-box, für SQL nicht, wohl wegen der potenziellen Komplexität. Trotzdem realisieren manche diese Logik: z.B. wenn abends Batch startet und CPU > 90% 10min, dann Skaliere von GP 8 vCores auf 16. Mit dem SDK kein Problem – nur sollten Sie orchestrieren, dass nicht hin und her flip-flop (Hysterese einbauen, z.B. erst runterskalen wieder wenn 2h unter 30%).
– Manuell geordnet: Ein geordneter Ansatz ist auch, bei bekannten Ereignissen manuell zu skalieren. Beispiel: Black Friday Sale kommt – man weiß im Vorfeld, Onlineshop DB braucht mehr Power. Also plant das Team mittags vor Sale-Beginn: DB to BusinessCritical 8vCores (upgrade). Nach Ende Event: wieder zurück auf 4 vCores GP (downgrade). Manuell aber im Plan = geordnet.
– Using DevOps pipeline: Eine nette Variante: Integration in Release-Pipelines. Wenn z.B. ein bestimmter Job starten soll (etwa wöchentlich ETL), könnte der orchestrator zunächst API-Call ans DB machen „scale up“, dann ETL, dann „scale down“. Das ist fortgeschritten, spart aber Overprovisioning.
– Pools: Mit Elastic Pools hat man quasi auto-verteilung, aber man kann Pools an sich auch schedulen (z.B. nachts weniger eDTUs, falls tenants nachts offline).
Wichtig: Skalierungsvorgänge bei Azure SQL sind online, aber es kommt oft zu einem kurzen Disconnect (<1 Minute) beim Switch, je nach Tier (GP<->GP minor might be seamless, GP->BC requires file move -> einige Minuten offline). Planen Sie daher skaliert während Minimallast oder informieren Sie die App (Retry logic). MI Skalierung kann mehrere Minuten dauern und DB ist währenddessen read-only – daher MI nicht spontan auf Lastpeak skalieren, eher im Wartungsfenster.
Insgesamt: Mit Skripten & Plan kann man sehr granular Kapazität an Bedarf anpassen, man muss nur Team/Prozesse darauf ausrichten (und Testen!).

Frage: Was unterscheidet den Serverless-Betrieb in der Praxis?
Antwort: Serverless Azure SQL Database unterscheidet sich von provisionierten Instanzen in folgenden Punkten:
– Automatische Skalierung: Serverless passt die vCore-Anzahl laufend an die aktuelle Last an. In der Praxis sieht man, wie bei steigenden Abfragen die CPU anfangs hochgeht, dann fügt Azure mehr vCores hinzu (bis Max), CPU% sinkt auf normallevel, Abfragen schaffen mehr Durchsatz. Umgekehrt bei Idle werden vCores reduziert. Diese Skalierung erfolgt in kurzen Intervallen (Sekunden bis wenige Minuten). Für den Nutzer bedeutet das: Performance kann dynamisch schwanken, aber Sie müssen nicht manuell eingreifen.
– Auto-Pause/Resume: Bei längerer Inaktivität wird die DB gestoppt (Compute = 0). Das bemerken Sie daran, dass die nächste Query deutlich länger braucht (Kaltstart). Sonst im laufenden Betrieb merkt man wenig – außer an der Rechnung (0€ für Compute während Pause). Im Monitoring sehen Sie einen Status “Paused”.
– Abrechnung: Im Serverless fallen Kosten pro genutzte CPU-Sekunde an. D.h. wenn DB 30 min nichts tat, zahlen Sie 0 für Compute. Wenn sie 30 min 50% der max CPU zog, zahlen Sie die halbe vCore-Kosten für 30 min. Dies ist granular und kann Kosten verringern, wenn die Nutzung sprunghaft ist.
– Limits: Serverless aktuell nur im General Purpose Tier bis 40 vCores max (Stand Nov 2025). Es steht nicht für Hyperscale oder Business Critical zur Verfügung. Auch nicht für Managed Instance, dort gibt es (noch) kein serverless.
– Memory Verhalten: Bei serverless wird bei Inaktivität auch Buffer Cache geleert (um RAM freizugeben). Nach Resume muss erst wieder gepaged werden von Storage. Das heißt, eine provisionierte DB, die ständig läuft, hat vielleicht oft ihre heißesten Daten im RAM – eine serverless, die häufig pau siert, muss öfter “von Null” laden. In der Praxis merkt man das als etwas ungleichmäßigere Performance bei sporadischer Nutzung. Für dauerhafte High-Load-Sachen ist serverless weniger sinnvoll (kostet dann meist mehr als provisioned und hat Overhead).
– Use Cases: Praktisch bewährt hat sich serverless für unvorhersehbare oder sehr wechselhafte Workloads. Z.B. Entwickler-Testumgebungen, digitale Behördendienste die nur tagsüber genutzt werden, Lernplattformen mit Stoßzeiten etc. Weniger geeignet ist serverless, wenn man harte Performance-Consistency braucht (z.B. in Trading app – dort will man kein Cold Start Risiko) oder durchgehend >50% CPU hat (dann zahlt man eh ständig Max).
Im Betrieb müssen Sie sich bei serverless um weniger kümmern: kein ständiges Rauf/Runter-Skalieren manuell. Aber Sie sollten das Min/Max gut wählen: Min nicht zu niedrig, sonst nach jeder kurzen Pause Cold Start; Max nicht unnötig hoch, sonst könnte eine plötzliche Last kostspielig ausarten (man kann aber ein eBudget definieren od. Alert).

Frage: Wie teste ich Wiederherstellungen regelmäßig?
Antwort: Durch Simulieren von Restore-Vorgängen in einer kontrollierten Umgebung. Konkret: Richten Sie eine dedizierte Azure SQL Test-Server/MI ein, auf der Sie Test-Restores durchführen können (zur Not auch in Prod-Server, aber mit anderer DB-Namens). Vorgehen:
– PITR-Tests: Nehmen Sie z.B. vierteljährlich ein zufälliges Datum in der Vergangenheit (z.B. “Restore Stand von vor 10 Tagen um 14:00 Uhr”). Nutzen Sie das Azure Portal oder PowerShell Restore-AzSqlDatabase mit -PointInTime. Stellen Sie die DB als neue DB her, z.B. “RestoreTestDB”. Überprüfen Sie dann: Sind Daten in kritischen Tabellen auf dem Stand von vor 10 Tagen (Sie brauchen Vergleich, etwa via Archiv oder anhand manuell bekannter Änderungen). Notieren Sie die Dauer, die das Restore gebraucht hat, von Befehl bis DB online. Nach dem Test können Sie die Restore-DB wieder löschen.
– LTR-Tests: Wenn Sie langfristige Backups aufbewahren, sollten Sie auch diese mal prüfen. Azure erlaubt Restore aus LTR genauso (Portal LTR auswählen, Restore). Testen Sie z.B. einmal im Jahr die älteste Jahresbackup – lässt sie sich sauber wiederherstellen? Manchmal entdeckt man, dass z.B. die Backup-Datei defekt ist (selten, aber möglich). Besser jetzt als im Ernstfall.
– Restore auf anderer Server/Region: Probieren Sie auch aus, ein Backup auf einen anderen Server wiederherzustellen (z.B. Szenario: Prod Server komplett weg, wir müssen auf neuen Server in anderer Region restoren). Azure erleichtert das – man gibt beim Restore einfach einen anderen Zielserver an. Aber check: existieren Logins etc. auf dem Ziel? Machen Sie solche Probedurchläufe.
– Automatisierung: Sie könnten automatisiert monatlich einen Restore-Test fahren: z.B. via Azure Automation Skript, das eine kleine DB aus Backup wiederherstellt, dann DBCC CHECKTABLE ausführt und Ergebnis loggt. So was machen Unternehmen, um lückenlos sicher zu sein.
– Dokumentation & Verfahren: Halten Sie in einem Runbook fest: “Im Desaster X tun wir Y, Z”. Z.B. “Wenn Produktions-DB gelöscht (versehentlich), führen wir PITR auf Stand -5min aus.” – haben Sie gemessen, wie lange das dauert? Im Plan schreiben.
– Team-Schulung: Lassen Sie auch Kollegen die Restore-Tests durchführen, nicht nur einen Spezialisten. Jeder im DBA-Team sollte mal einen Azure SQL Restore via Portal/PS gemacht haben, um im Notfall keine Zeit zu verlieren.
Behandeln Sie also Test-Restore als Teil Ihres regelmäßigen Wartungskalenders. Das gibt Sicherheit und oft entdeckt man dabei auch Verbesserungspotenziale (z.B. „Mensch, 1 TB DB Restore dauerte 3 Stunden – evtl. Hyperscale künftig in Betracht ziehen, um das zu verkürzen.”).

Frage: Welche Limits/Quotas sind in Azure SQL kritisch?
Antwort: Einige Azure SQL Grenzwerte sollte man kennen, um keine Überraschungen zu erleben:
– Max. Datenbankgröße: Allgemein bis 4 TB (General Purpose Single DB), 1-4 TB (Business Critical, je nach vCores), 100 TB (Hyperscale). Managed Instance: GP bis 16 TB (bald 32 TB in neuem Tier), BC bis 4-8 TB. Überschreiten Sie diese, geht’s nicht weiter – also bei Wachstum vor Erreichen planen (z.B. Partition auslagern oder Hyperscale wechseln).
– Max. vCores: 128 vCores pro DB oder MI. Wenn Sie mehr brauchen (sehr unwahrscheinlich für OLTP), müssen Sie sharden.
– Max. Databases pro Server/Instance: Azure SQL logical server: bis 5000 DBs (inkl. Azure SQL und Hyperscale). MI: bis 100 DBs (Standard), neuere Gen evtl. 500 DBs. Wenn Sie Multitenant >5000 bräuchten, mehrere logical server nutzen. Pools ebenfalls, Pools können aber auch max ~1000 DBs pro Pool (im DTU 100, im vCore 1000).
– Concurrent Logins/Connections: Azure SQL DB hat Standardbegrenzung von 30.000 gleichzeitigen Verbindungen pro DB (sehr hoch, normal kein Thema – aber wer Webapp mit so vielen uses hat, muss evtl. verteilen). MI: ähnlich wie SQL Enterprise (32767 sessions etc.).
– Transaction Log Rate: Es gibt ein Log throughput Limit pro Datenbank: ca. 48 MB/s bei Gen5 Business Critical 8vCores (skaliert mit vCores), und ~ 96 MB/s bei 16 vCores etc. Hyperscale hat ~100 MB/s global. Wenn man diese Rate überschreitet (z.B. Bulk-Inserts, Massendelete), wird die Operation gedrosselt (fühlt sich langsam an). Also plan für Bulk loads evtl. aufteilen.
– TempDB Größe: In MI ist TempDB begrenzt (64GB per vCore bis max 1TB). Azure SQL DB hat TempDB per DB in it (automange), limit 32GB per vCore bis 2.5TB (Hyperscale). Falls Workload sehr TempDB-intensiv (Sorts, spools), Limit im Auge behalten.
– Query Parallelität: In Azure SQL DB sind parallele Prozesse je nach Tier begrenzt – e.g. MaxDOP in serverless auto auf 8 begrenzt. In MI default 0 like on-prem, aber Monitor, ob CXPACKET waite. Hier keine harten Quota, aber performance consider.
– Requests/sec und Worker Threads: Auf PaaS vom Tier abhängig. Standard (GP) hat weniger Worker threads pro vCore als BC. Wenn Sie extrem viele concurrent queries haben, vlt BC better.
– Quotas pro Subscription: Es gibt Azure Subscription Quotas, z.B. max. 5400 DTUs pro Server (erweiterbar per Request), oder vCore quotas (z.B. maximal 200 vCores in Region X per Subscription standard). Wenn Sie mehr Instanzen hochfahren wollen, Azure Support Ticket needed zum Erhöhen. Also wenn Sie hunderte DBs clusters planen, Quotas check timely.
– Managed Instance spezifisch: Max 8 TB DB file size, Max 100 DBs (bald 500 im new tier). Linked Servers max 32.
Die kritischsten in Praxis: Größe und IO/Log Rate. Die meisten normalen Workloads stoßen nicht an Verbindungs- oder thread-Limits. Ach ja, DTU Limits: Basic tier hat max 5 DTU (sehr low), Standard Sx hat Limits z.B. S4 = 200 IOPS etc. Wer DTU nutzt, studieren.
Lösung bei Limit: oft Scale up (mehr vCores = heben viele Limits linear), oder Wechsel Tier* (GP->Hyperscale für mehr size). Quota-limits → MS Support, die heben an.
Wissen Sie um Limits, überwachen Sie entsprechende Indikatoren (Log queue, file prct full etc.), dann können Sie gegensteuern bevor es knallt.

Frage: Wann brauche ich weiterhin eine VM-basierte SQL-Instanz?
Antwort: Immer dann, wenn Anforderungen bestehen, die in PaaS nicht erfüllbar sind oder volle Kontrolle unumgänglich ist:
– Betriebssystem-/Softwareabhängigkeiten: Wenn Sie Software auf dem DB-Server selbst installieren müssen (z.B. ein spezieller Agent, ein Virenscanner, ein Treiber für PolyBase zu Oracle), dann ist VM der Weg – PaaS lässt keine benutzerdefinierte Installation zu.
– Veraltete SQL Server-Versionen: Falls Ihre App nur mit SQL 2012 oder 2008R2 läuft (Kompatibilität), PaaS bietet nur neueste Engine. Auf VM können Sie Legacy-Version betreiben (allerdings ohne Managed Updates etc.).
– Funktionen, die PaaS nicht hat: Etwa FILESTREAM / FileTable, CLR mit unsafen Assemblies, Cross-Instance Distributed Transactions, Database Mail (MI hat keinen einfachen SMTP), Service Broker (zwischen DBs) – einige davon gehen auf MI, aber nicht alle. Für komplexe Integration via MSMQ o.Ä. bleibt VM.
– Spezielle Performance-Tuning: In VM können Sie at low level configen: Laufwerksausrichtung, eigene TempDB-Laufwerke, Trace Flags systemweit etc. PaaS ist da starr. Wenn Sie also eine extrem feingetunte OLTP-Engine brauchen, wo z.B. -T4199 oder -T1117 Pflicht sind, MI hat manches, aber nicht alles.
– SQL Server Reporting Services (SSRS) oder Analysis Services (SSAS): Diese laufen nicht in PaaS (SSRS kann nur in VM gehostet oder Power BI Report Service Alternative). Wenn Sie zwingend ein Reporting Services brauchen im gleichen DB Kontext, nutzen Sie VM.
– Compliance/Isolation: Manche Richtlinien verlangen physisch dedizierte Maschinen (Mandantenfähige PaaS teilt unter Umständen Hardware). Azure bietet zwar Dedicated Host etc., aber einfacher: VM auf dedicated host = eigen Blech – PaaS geht da nicht.
– Customization & Extended Support: Wenn Sie Logging am OS brauchen (z.B. tiefe Perfmon, Custom Auditing am OS-Level) oder reines “Wir kennen es so und wollen volles Eigentum”, VM ist klassisch.
– Tooling & Skills: Falls Ihr Team nicht umsteigen kann/möchte und lieber traditionell Administriert, evtl. VM – wobei das eher kein Muss-Kriterium, eher ein Softes.
In Summe: Brauchen Sie etwas, was nur eine “eigene Box” liefern kann (spezielles Feature, OS-Zugriff, alter Version), dann VM. Sonst bitte PaaS wählen, um von Platform-Vorteilen zu profitieren. Manchmal bleibt VM als Übergangslösung: man nimmt VM zunächst (z.B. weil viele Agent-Jobs), modernisiert dann Applikation in Phase 2 und wechselt dann auf PaaS – das ist okay.
Ganz klare Cases: Legacy 3rd-Party Apps – wenn ein Hersteller nur Betrieb auf “SQL Server Standard Edition, Windows 2016 VM” zertifiziert, dann eben so.
Sehr hohe CPU/RAM Bedürfnisse jenseits PaaS – z.B. 256 vCores und 2TB RAM, PaaS hat da Limit, VM (M-Serie) könnte liefern.

Frage: Wie ist die Lizenzierung zwischen Dev/Test und Produktion zu unterscheiden?
Antwort: Microsoft erlaubt deutlich günstigere oder kostenlose Nutzung von SQL in Nicht-Produktionsumgebungen, aber man muss es korrekt einsetzen:
– In Azure gibt es spezielle Dev/Test-Angebote: Wenn Sie eine Azure Dev/Test Subscription (verfügbar mit Visual Studio (MSDN) Abos) nutzen, zahlen Sie für Azure SQL keine Lizenzkosten. Das heißt, ein Azure SQL Database oder MI kostet dort ~50% weniger (ungefähr dem AHB-Preis). Voraussetzung: diese Subscription darf nur für Entwicklung, Test, QA genutzt werden, nicht für Produktionsdaten oder -Benutzer. Also sehr klar trennen.
– Alternativ, wenn kein solches Abo: Sie können aber auch in normaler Sub AHB für Dev umsetzen, indem Sie einfach AHB aktivieren (verlangt aber, dass Sie on-prem Dev-Lizenzen haben – normalerweise hat man aber Dev/Test recht durch Visual Studio).
– Auf VMs können Sie SQL Server Developer Edition installieren – diese ist kostenlos (entspricht Enterprise Feature-Set, aber nur nicht-prod!). Perfekt für Test-VMs, CI/CD etc. In Prod müssen Sie Standard/Enterprise lizensieren oder eben AHB angeben. Developer Edition ist lizenzrechtlich nicht erlaubt, Prod-Daten zu bedienen.
– Unterschiede Prod vs. Dev liegen rein im Lizenz-/Kostenbereich – leistungsmäßig sind die Dienste gleich. Also nutzen Sie ruhig Dev/Test Offerten, um viel Geld zu sparen in Ihrem Lebenszyklus.
– Ach ja, Lizenzierung Dev-Teams: Falls Sie Self-Hosted Azure (Arc) oder On-Prem Dev nutzen, Developer Edition deckt es ab.
– Visual Studio (MSDN) Subscriber: Diese Leute haben via MSDN-Abos oft “Azure Credits” und können in speziellen Dev/Test Subscriptions Ressourcen ohne Lizenz aufbauen (AHB assumed). Das ist ideal für agile Teams.
– Was man nicht tun sollte: Prod-Workloads in eine Dev-Sub schummeln – wenn das rauskommt, Lizenzverstoß. Microsoft trennt streng nach Nutzung.
Fazit: In der Cloud nutzen Sie nach Möglichkeit die Dev/Test Tarife für alles was kein echtes Production-System ist. Das spart erheblich (bis zu 55% auf SQL PaaS). Und in on-prem/VM-Welt nutzen Sie Developer Edition für non-prod, die ist kostenlos und voll funktional.

Frage: Wie funktionieren Reserved Capacity (Reservierungen): Bindung, Wechsel, Kombination mit AHB?
Antwort: Reserved Capacity bedeutet, Sie verpflichten sich, eine bestimmte Menge an Azure SQL Ressourcen für 1 oder 3 Jahre zu bezahlen. Im Gegenzug erhalten Sie einen merklichen Rabatt. Wichtige Punkte:
– Bindung: Sie sind vertraglich verpflichtet, die Reservierung zu zahlen, auch wenn Sie die Ressource nicht nutzen. Es ist quasi eine Vorauszahlung. Allerdings dürfen Sie die Reservierung flexibel auf passende Ressourcen anwenden. Beispiel: Sie reservieren 8 vCores in West Europe Gen5 General Purpose für 3 Jahre. Azure wird nun immer, wenn Sie eine AZ SQL DB oder MI in West Europe GP Gen5 betreiben, bis 8 vCores davon “gratis” (schon bezahlt) laufen lassen. Wenn Sie mal keine entsprechende DB haben, verfällt die Zeit, Geld dennoch weg (Use it or lose it).
– Wechsel/Änderung: Azure erlaubt Austausch oder Stornierung von Reservierungen begrenzt: Sie können eine bestehende Reservation stornieren (max 50k$ pro Jahr ohne Penalty, darüber mit 12% Fee) oder sie umtauschen in eine andere gleichwertige/höhere. Umtausch praktisch: Wenn Sie merken, Sie brauchen doch BC statt GP, können Sie eine neue BC Reserve kaufen und die alte ggf. refund (anteilig). Das geht über das Portal (unter Reservations -> Exchange). Microsoft ist da fair flexibel, aber es gibt Limits.
– Kombination mit AHB: Ja, das geht. Reserved Capacity deckt den Compute-Preis, Azure Hybrid Benefit deckt die Lizenz. Diese Rabatte addieren sich. Sie aktivieren AHB auf Ihrer Ressource (nachweis eigener Lizenz) – damit entfällt der Lizenzanteil. Dann kaufen Sie Reserve für die vCores – damit sinkt der Compute-Preis. Unterm Strich zahlen Sie dann nur ~30% des Payg-Preises. Dies ist die günstigste Option, sofern man Lizenzen hat und 3 Jahre Planungshorizont.
– Granularität: Reservierungen gelten z.B. für Azure SQL Database vCore (Shared) oder Managed Instance. Es gibt separate Reservierungs-Pools – Sie müssen richtig kaufen. Z.B. MI General Purpose Reservation kann nicht auf SQL DB GP angewandt werden (sind separate). Achten Sie im Kaufdialog auf Scope (Subscription oder Shared) und Resource Type.
– Abrechnung: Sie können wahlweise upfront alles zahlen oder monatlich (ohne Aufpreis, so streckt sich aber die Verpflichtung trotzdem).
– Kapazitätsverwaltung: Wenn Sie z.B. 8 vCores reserviert haben und 12 vCores nutzen, zahlen Sie 8 mit Rabatt, 4 normal. Wenn Sie irgendwann nur 4 nutzen, bleiben 4 ungenutzt (Verfall). Daher kann man mehrere kleinere Reservations vorziehen, um modulieren zu können (z.B. zwei 4-vCore statt eine 8, falls Variation).
– Dev/Test: AHB gilt nicht in Dev/Test Subs (dort eh free lic). Reservation kann aber in Dev/test Sub genutzt werden, aber oft Dev Umgebungen fahren man abends runter – vlt. keine 24/7 Auslastung -> Reserve fraglich.
– Storno: Falls sich Business ändert, Sie können mit ~12% Penalty Restwert zurückgeben (Stand Policies – MS kann da anpassen, bisher aber möglich).
Also, Reservierung* = Commitment, aber adaptierbar begrenzt. In Praxis: wir empfehlen 1-Jahr Reserve zu Beginn (15-30% off, weniger Bindung). Später evtl. 3-Jahr (bis 45% off) wenn Plan sicher. Und AHB immer wenn Lizenzen da.

Frage: Muss ich trotz PaaS noch Monitoring und Wartung betreiben?
Antwort: Ja, auf jeden Fall. PaaS nimmt Ihnen viele Infrastruktur-Wartungsaufgaben ab (OS patch, DB Backup etc.), aber Datenbank-spezifische Betreuung bleibt nötig. Sie müssen z.B. weiterhin:
– Performance überwachen: Niemand außer Ihnen weiß, welche Abfrage wichtig ist. Azure stellt Metriken, aber Sie müssen drauf schauen oder Alerts definieren. Auch Indexfragmentierung, Query Plans, Parameter-Sniffing-Probleme – all das kann auch in PaaS auftreten und bedarf menschlicher Analyse und Optimierung. Azure kann Vorschläge geben (Auto Tuning), aber kritische Entscheidungen (neues Indexdesign, Partitionierungsstrategie) liegen bei Ihnen.
– Sicherheitsmanagement: Sie müssen Benutzer, Rollen, Berechtigungen verwalten, Sicherheitsvorfälle auswerten. Azure bietet Tools (Defender), aber die Interpretation und Reaktion (z.B. kompromittierter Login sperren) macht Ihr Team.
– Compliancechecks: Logging, DSGVO-Anfragen (“lösche meine Daten”) – all diese betrieblichen Themen hat PaaS keine Kenntnis. Sie müssen weiterhin Audit-Reports ziehen und Bewerten.
– Routine Wartung: Zwar kein DBCC im Sinne defragment needed (Azure auto reindex? Nicht ganz, Sie sollten weiterhin reorganize idx falls fragmentation >X% – oder azure auto-tuning on), aber z.B. Stats-Updates laufen automatisch, trotzdem vielleicht kontrollieren (in MI muss man classic jobs).
– Version Upgrades: Azure macht Engine Updates, aber wenn z.B. neue Feature kommt, müssen Sie die Kompatibilitätsstufe anheben oder Code anpassen, das tut Azure nicht selbst.
– Kostenkontrolle: PaaS würde stumpf weiter laufen – Sie müssen budsjet und optimize.
– Incident Response: Wenn z.B. plötzlich Query Timeout – Azure garantiert Verfügbarkeit, aber Root Cause Analyse bei App Issues -> Sie. Sie können Azure Support einbeziehen bei z.B. “I/O system slow”, aber initial Monitoring und Eskalation liegt bei Ihnen.
– Schemapflege & Release Management: Nach wie vor, DB-Änderungen müssen Sie planen, skripten, deployen.
– Backuptests: Wie betont, PaaS backup can fail rarely, Sie monitoren und üben restore.
– Hochverfügbarkeit Auslegung: Azure deckt Standard-HA. Aber Business-Continuity-Plan (wann failover, wie in App) ist Ihr Job.
PaaS entlastet enorm im “Undifferentiated Heavy Lifting” – also Routine und Basis. Aber die Verantwortung für die Daten und Performance bleibt Shared – Microsoft für Platform, Sie für Daten & Usage. Dieses Shared Responsibility Model sollte Ihr Team verinnerlichen. In Kurzform: Everything in your database is your responsibility, everything under it (OS, Hardware) Microsoft’s.

Frage: Wie gehe ich mit temporären Lastspitzen um?
Antwort: Temporäre Lastspitzen – etwa unerwartet hohe Nutzerzugriffe oder Batch-Jobs – kann man in Azure SQL recht flexibel abfangen:
– Skalierungs-Puffer einplanen: Lassen Sie etwas Luft nach oben bei der normalen Dimensionierung. Wenn Ihre DB bei Peak bisher 70% CPU erreicht, sollten Sie nicht exakt minimal dimensionieren, sondern z.B. Reserve, sodass Peak eher 50% auslastet. Dieser Headroom absorbiert kleinere Spitzen ohne sofort Drosselung.
– On-Demand Scaling: Für absehbare Spitzen (z.B. Monatsende-Reporting) können Sie vorab skalieren (hoch), nachher zurück. Das Minimiert Impact. Falls unvorhergesehen aber spürbar, können Sie auch ad-hoc skalieren – im Portal oder via CLI – das dauert oft nur 1-5 Minuten, aber in der Zeit und beim Switch gibt’s kurzen Hänger. Wenn Spitze z.B. 1h dauern soll, könnte man es in Kauf nehmen (besser 1 min Freeze als 60 min Slow).
– Serverless / AutoScale: Wenn Sie im Serverless-Modus sind, macht Azure das für Sie – es erhöht vCores kurzfristig. Nachteil: kalter Start falls zu Null vorher. Aber für sporadische Last sehr passend.
– Queuing & Throttling in App: Entkoppeln Sie wo möglich Last. Z.B. eingehende Massentransaktionen erstmal in eine Queue (Azure Service Bus o.ä.) und die Worker ziehen und schreiben gemächlicher in DB. Dann sieht DB gleichmäßigere Last statt Peak all auf einmal. Das glättet Spitzen.
– Read Scale-Out nutzen: Falls Spitzen v.a. Leseabfragen sind (z.B. Berichtswelle), nutzen Sie Features wie den Readable Secondary (in Premium tier) oder geo-verteilen die Reads. So verteilt sich Last. Bei Hyperscale kann man on demand ein Read-Replica hochfahren, es an Load Balancer hängen, nach Peak wieder entfernen (man zahlt dann nur stundenweise).
– Kurzfristig tolerieren: Azure SQL bewirbt sog. Burstable Perf (bes. in DTU/Pools): Kurze Spitzen (Sekunden) werden vom System oft bedient selbst über Limit, indem Credits verbraucht werden (in Pools) oder CPU vorübergehend >100% drawn, solange danach Idle (in serverless Redwood?). Also ein paar Minuten Peak werden oft noch verkraftet. Wenn’s länger als Min/ wenige min, dann wie gesagt, Mechanismen.
– Testen Sie Limits: Kennen Sie Ihr throttling-Verhalten: z.B. es gibt wait type RESOURCE_SEMAPHORE bei CPU saturiert etc. Erstellen Sie in nonprod eine Situation, wo DB an Limit geht, um zu sehen, wie App reagiert (TimeOut? oder Retries?). Passen Sie App an: Implementieren Sie Retries bei Transient Fehlern (z.B. Verbindungsabbruch oder Throttling error 10928). Das Azure .NET Library macht z.B. Retries automatisch in default.
– Langfristig lessons learned: Falls Spitzen regelmäßig auftreten, erhöhen Sie dauerhaft Kapazität oder architekturieren Sie neu. Z.B. wenn jedes Montag 9:00 Crash wegen Reports – vielleicht Reports asynchron generieren oder second DB.
In kurz: für temporäre Peaks haben Sie die Cloud-Vorteile: schnell nachregeln, bezahlen nur was notwendig. Im Applikationsdesign aber auch muster einbauen, dass Cloud-spezifische Effekte (kurze Freeze beim Scale, oder TooManyRequests error) abgefedert werden.

Frage: Wie kann man ein Multi-Region-Design realisieren – Abwägung Latenz vs. Resilienz?
Antwort: Multi-Region-Design zielt darauf ab, Ausfallsicherheit über Regions-Grenzen zu bekommen, aber bringt das Problem der Latenz mit sich (weite Strecken = langsamere Kommunikation). Hier ein paar Ansätze:
– Active-Passive (Primär/DR): Häufigste Lösung: Die DB läuft in Region A, Region B hat ein asynchrones Standby (via Failover Group). Der Clou: Applikation läuft normal nur gegen Region A -> minimale Latenz für die dortigen Nutzer. Region B ist Idle, bekommt Daten nach, aber Nutzer spüren es nicht (solange kein Failover). Beim Desaster in A schwenkt man um – dann haben Nutzer in B etwas höhere Latenz (wenn Nutzer geographisch weit weg, aber dann sind die primär-nutzer vermutlich eh offline und nur B-nutzer aktiv). This yields best performance in steady state, und Resilienz ist da, aber RPO>0 (async). Für weltweites Business gut.
– Active-Active (Multi-Master): Azure SQL unterstützt kein Multi-Master in versch. Region out-of-box (keine verteilte writeable DB). Man könnte mit Cosmos DB auf Multi-Master ausweichen, aber als SQL nicht trivial. Also richtiger Active/Active mit synchroner Replikation ist nicht möglich über Regions (Latenz wäre auch hunderte ms, kaum nutzbar). Wenn Active-Active gewünscht, muss man in App-Ebene sharden: z.B. US-Kunden in US-DB, EU-Kunden in EU-DB – jede DB aktiv in Region mit local latency. Bei Überschneidungen (z.B. globaler Report) muss Applikation beide lesen oder synchronisieren. Das Komplexität, wird nur gemacht, wenn streng latenzkritisch.
– Lesende Georeplikation: Manche machen Region B als Read-Only farm (reporting from a secondary), und Writes nur in Region A. Das gibt gewisse Active-Active illusions (one region writes, other reads). Latenz kritische Reads können so von näherer Region bedient werden. Aber wenn Reader region Kunden schrieben, geht’s doch nach A (Cross region, langsam).
– Zonen vs. Regionen: Beachten Sie, Azure Availability Zones sind enger beieinander als Region, Latenz ~ <2ms. Multi-Region (z.B. EU <-> US 100ms). Also, wenn’s um Ausfall Rechenzentrum aber nicht geo-weites Desaster geht, nutzen Sie Zonen, das hat kaum Performance-Auswirkung. Multi-Region sollte man nur einsetzen, wenn man wirklich Schutz vor Region-Blackout braucht oder globale verteilte Users.
– Latenz vs. Konsistenz trade-off: Asynchrone Replikation (Azure’s method) akzeptiert, dass die neueste Transaktion vlt. 1-2s hinterherhängt drüben, dadurch Haupt-Workload keine Wartezeit. Würde man synchron (um RPO=0) machen, müssten alle Transaktionen warten auf Commit in die andere Region – das fügt je nach Distanz 50-200ms pro Transaktion hinzu. Für OLTP oft inakzeptabel (Kill throughput). Daher sync cross-region wird vermieden.
– Netzwerk: Schaffen Sie gute Netzwerkanbindung zwischen Regionen (Azure Regions untereinander sehr gute 10-20 Gbit Links, Latenz physikalisch minimal, kann man nicht weiter verbessern). Wenn On-prem im Mix, ExpressRoute wähl, ggf. Global ER.
– Entscheidung: Also, Priorität meist: Für niedrige Latenz -> hoste DB nah bei User, für hohe Verfügbarkeit -> zweites Standby wo anders. Wenn man global user hat, in manchen Systemen fährt man Multi-Write via separate DBs und dann Data Sync asynchronously – aber das erfordert custom conflict handling. Azure hat SQL Data Sync (deprecated 2027), das war Hub-Spoke Sync, aber Multi-Writes kann es auch (Konflikte managend). Nicht ideal für hohe Transaktion.
Für viele ist goldene Mitte: Primär pro Region (shard by region), und zusätzlich in jeder region standby der anderen – z.B. EU primary replicates to US passive, US primary to EU passive. Bei Ausfall einer Region, die andere übernimmt double duty. Das ist komplex, man bräuchte Multi Failover Groups die sich wechselseitig tracken, aktuell geht das mit separate sets. Ach man, sehr advanced.
– Azure Arc: Klammer am Rande, Azure Arc SQL MI kann auf on-prem Kubernetes DB Instances orchestrieren, theoretisch könnte man damit Multi-Cloud/Multi-DC synchron cluster – aber noch nicht gängig.
Zusammengefasst: Absolute Konsistenz? Bleib bei single region (plus passive DR). Minimale Latenz global? Partitioniere Daten regional, vermeide cross-ozean calls.

Frage: Wie gehe ich mit sehr großen Datenbanken (> 1 TB) um – ist Hyperscale die Lösung?
Antwort: Ja, Hyperscale wurde speziell für sehr große DBs in Azure SQL Database entwickelt. Vorteile für große DB:
– Unbegrenzter Speicher: Hyperscale skaliert hoch in die zig Terabytes, wo Standard vCore Tiers auf 4-8 TB limitiert sind. D.h. wenn Sie 5, 10, 50 TB brauchen, ist Hyperscale (fast) alternativlos in PaaS.
– Schnellere Backups/Restores: Statt stundenlang 1+ TB aus dem Storage zu kopieren, nutzt Hyperscale Snapshots – ein Restore (z.B. auf Stand von vor 5 min) dauert nur wenige Minuten (es wird ein Snapshot-Pointer eingerichtet). Das ist extrem wertvoll, wenn man riesige DB hat und sonst ewig offline wäre bei Wiederherstellung.
– Skalierbarkeit: Bei großen DB hat man oft auch Performance Anforderungen. Hyperscale erlaubt horizontale Skalierung (bis 30 readonly Replicas). Wenn z.B. Reporting gegen 5 TB Datawarehouse, kann man 5 Replicas aufspannen, die je Teil der Last nehmen. Oder auch eine Prod + 1 replica to offload read.
– Einschränkungen: Hyperscale ist nur Single Database (kein MI). Außerdem unterstützt es einige Features (z.B. Transparent Data Encryption, In-Memory OLTP) – ja TDE & InMemory now supported. Aber z.B. PolyBase External Tables? Evtl. nicht alle. Und Hyperscale hat ggf. höheres Kosten baseline, weil man mehrere VMs im Hintergrund hat (Page servers etc. verrechnet als minimal 2-3 compute replicas).
Wenn Sie on-prem eine fette SQL haben, vllt. lieber auf 2-3 modulare System verteilen? In Cloud mit Hyperscale geht monolith aber okay.
– Alternative: Falls Workload eher Data Warehouse, überlegen Sie an Azure Synapse (die MPP-Lösung) – aber das ist andere Welt (keine 100% SQL Server kompatibel, gut für analytisch).
– Managed Instance: Hier sind 16 TB Limit (bald 32), das deckt moderate “große” DB. Aber >32 TB geht dann nur Hyperscale (oder SQL auf VM, da können Sie Storage Pools viel packen, aber manage overhead).
– Migration: Hyperscale Migration von on-prem geht via Backup->Hyperscale (jetzt supported) oder bacpac, aber große DB bacpac ineffizient. Besser do split backup to url, create Hyperscale from it (coming feature?), oder use DMS with minimal downtime. Es gab initial constraints, aber jetzt kann man MIGRATE MIGRATE from MI/GP to Hyperscale fairly easily (Portal has a button for online convert).
In Summe: Hyperscale ist ideal, wenn DB-Größe und agility (fast backup/restore) im Vordergrund stehen. Für OLTP < 1-2 TB ist General Purpose oft okay. Ab ~ 4 TB region fängt man an Hyperscale ernsthaft zu erwägen.
One caution: Hyperscale kann (derzeit) nicht down-tier zurück auf GP. Also es’s one way – was aber fine, wenn DB so gross, in other tier ginge eh nicht.

Frage: Welche Möglichkeiten gibt es für Read-Scale-Out?
Antwort: Mehrere:
– In Azure SQL Database Business Critical/Premium Tier: Sie erhalten automatisch eine readable Secondary in der gleichen Region. Nutzen: Sie können Ihre App oder Reports mit ApplicationIntent=ReadOnly im Connection String verbinden, dann schickt Azure die Abfrage an die Read-Replik (eine der synchronen Kopien). So können Sie z.B. Reporting-Last abkoppeln. Achtung: das ist nur im Premium/Business Critical Tier, nicht in General Purpose. Kostet nichts extra. Der Read-Secondary ist best-effort (kann minimal hinterherhängen, aber i.d.R. synchron, da es ja im gleichen AG ist).
– In Hyperscale: Sie können bis zu 30 Named Replicas hinzufügen. Das sind separate Compute-Instances, die denselben Datensatz per Page-Server beziehen. Diese Replicas können Sie gezielt ansteuern (Connection per Replica name). So kann man massiv parallele Lese-Workloads verteilen. Sie zahlen aber pro Replica (fast wie eigene DB vCore Kosten). Man kann Replicas auch in verschiedenen Regions hosten (Cross-region replicas supported?), zZ nur same region? Actually Hyperscale named Replicas as of 2025 likely same region, cross region via failover group only. Jedenfalls within region, ideal for read scale.
– In Managed Instance Business Critical: MI hat 3 synchron Replikate (AG) + primary. Standardmäßig war lange nur Primary nutzbar, aber mittlerweile kann man auch in MI den Readable Secondary nutzen (Connection string ApplicationIntent=ReadOnly, MI leitet dann an einen Secondary – diese Funktion kam ~2021). Also MI BC hat 1 freie Read-Replica im Cluster. MI General Purpose hat keine.
– Geo-Replicas (Active GeoReplication): Sie können eine Azure SQL DB in anderer Region als Readable Secondary definieren (bis 4). Diese kann auch im Normalbetrieb z.B. globale read queries bedienen (mit dann jedoch etwas Latenz und eventual consistency, asnyc replication). Bsp: EU und US Team je lokal lesen von eigenem Replica – writes gehen aber nur an primary in EU. So entlastet man Primary etwas und verteilt read-latency. Kostet vollen Preis pro Replica.
– Failover Group Secondary: analog, aber auch group-floating, prinzipiell als read-intent nutzbar.
– SQL on VM / on-prem: Bewährte Methode: Always On Availability Groups mit Readable Secondary. Sie können in der AG konfigurieren, welche Sec. read-only annimmt. Dann via Listener mit ReadIntent=ReadOnly connect, es leitet auf Sec. Und für mehr scale-out: mehrere Sec. (AG bis 8 nodes, 5 readable?), oder Transactional Replication zu mehreren Subscriber DBs (eher historisch, aber möglich, auch Cross version).
– Azure Synapse Link for SQL (neues Feature): in SQL 2022/Azure MI gibt’s Möglichkeit, near real-time replicate certain tables to Synapse for analytics, that’s more for separate anal.
– Cache Layer: Ausserhalb DB, z.B. Azure Cache for Redis – entlastet DB reads by caching results in memory. Das skaliert reads massiv, aber ist eventual consistent (Cache invalidation needed).
Um read-scale-out zu wählen: Für PaaS easiest: Switch auf Business Critical (bekommt freebiesec) oder Hyperscale (dann add replic). Für VM: Always On.
Wichtig: Applikation anpassen, dass sie reads auf readonly replica schicken kann. Viele ORMs unterstützen ReadOnly flag on context.
Zudem bedenken: Der Read-Secondary kann nur read queries, keine writes, aber evtl. auch keine Temp table create (some require MASTER access? – in AO, sec can do temp table yes, just not mod data).
Summe: Sie haben eine Palette – PaaS hat integrierte (BC/hyperscale), bring a little cost or just upgrade. On VM in-house building.

Frage: Gibt es T-SQL-Kompatibilitätsunterschiede in Azure SQL, und welche Fallstricke treten auf?
Antwort: Im Großen und Ganzen ist T-SQL in Azure SQL identisch zum neuest verfügbaren SQL Server (derzeit 2022). Dennoch gibt es einige Differenzen:
– Nicht unterstützte Befehle: Alles was mit Betriebssystem zu tun hat wie xp_cmdshell, sp_configure für server-weite Dinge (nur subset in MI), DBCC PAGE (in Azure SQL DB nicht erlaubt), ALTER SERVER … (keine server im Single DB), CREATE CERTIFICATE … FROM FILE (kein Filezugriff) etc. Diese werfen Fehler. In MI manches erlaubt, aber in DB meist nicht. Also Admin T-SQL teils anders.
– Differenzen in Funktionen: Z.B. NEWID() und NEWSEQUENTIALID() – in Hyperscale generiert NewSequentialID pseudo-random (da kein monotonic disk page), kleiner Unterschied, i.d.R. egal. Oder DATEDIFF_BIG – neu in Azure, auf altem SQL gibts vllt. nicht.
– Sortierung/Collation: Azure SQL DB hat keine Server-Collation – jede DB hat eigen Collation. Wenn Ihre Anwendung früher relyte auf TempDB Collation = server collation, kann Minor differences. Usually fix by explicitly collate.
– SQL Agent & DBMail procs: Wenn Code ruft msdb.dbo.sp_send_dbmail – in Azure SQL DB gibts kein msdb, bricht. Oder sp_start_job – nicht vorhanden. In MI gibt’s msdb, aber DBMail muss via External SMTP configured.
– Cross-DB Pfade: SELECT * FROM OtherDB.dbo.Table – in Azure SQL DB fails. Also Code, der davon ausging, muss geändert (z.B. Application combine or external table).
– Transaktionen über DBs/Server: in Azure SQL DB, keine distributed transactions (MSDTC) support. Also 2 DBs in one transaction geht nicht. In MI, Cross-DB in same MI geht, aber cross-Instance (with linked server) => DTC needed, MI hat (derzeit) kein MSDTC Support, also geht nicht.
– CLR Assemblies: In Azure SQL DB verboten (auch SAFE). Wenn Code create assembly – geht nicht. In MI geht, aber must set TRUSTWORTHY etc. Also falls App used CLR UDF, in DB Not poss, must remove or move to MI.
– System Metadata und DMVs: Viele DMVs verhalten sich gleich, aber manche Felder sind anders. Z.B. sys.dm_os_sys_info – CPU count zeigt vCore etc, memory etc. sys.master_files – in MI you see, in DB there’s virtualization of files. Also Tools expecting certain values evtl. passen.
– Version und Kompatibilität: Azure SQL ist quasi “SQL Server 2022+”. Es gibt Features, die es on-prem erst in vNext geben wird, z.B. im Laufe der Zeit kamen Sachen erst in Azure. Also Script SELECT @@version – liefert was wie 12.x.x.x (for azure, it used to always show 12.x). Besser SELECT DATABASEPROPERTYEX(db, ‚ProductVersion‘) – in Azure DB v12 always, MI shows actual engine (16.x for 2022). Kompatibilitätsgrad: Standard new DB=150 or 160, you can lower to 140 etc. Aber up to you.
Fallstricke: Die häufigsten Migration-Bugs sind:
– UDF/Prozeduren referencing objects in other DB -> fail.
– Code using EXECUTE AS LOGIN or trying to set server-level permissions -> fails (no control).
– Bulk import from local path (BULK INSERT expects file share – on Azure DB only supports Azure Blob via SAS). So load data must adapt (use Azure Storage).
– Ansbieten, DMVs: some admin code (like capturing wait stats) runs, but on azure DB you might need different rights (VIEW DATABASE STATE vs server state not exist).
– Collation differences cause Cannot resolve collation conflict if code joins temp table (temp in default collation) with table (diff collation). On-prem often server collations matched DB, not always on azure.
Test thoroughly and read MS doc “TSQL differences Azure SQL vs SQL Server” for comprehensive list.

Frage: Wie diagnostiziere ich Performance-Probleme ohne Zugriff auf das Betriebssystem?
Antwort: Azure gibt Ihnen zahlreiche alternativen Diagnosetools intern zur Hand:
– Dynamic Management Views (DMVs): Sie können per T-SQL auf DMVs wie sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_waiting_tasks, sys.dm_exec_query_stats, sys.dm_db_resource_stats usw. zugreifen. Diese liefern Infos zu laufenden Abfragen, Wartegründen, historische Nutzung. Ohne OS PerfMon kann man aus DMVs fast alles erhalten (z.B. Page IO Latch Waits = IO Engpässe, CPU-bound = high SOS_SCHEDULER_YIELD etc.).
– Query Store: Perf Probleme oft auf bestimmte Queries zurückzuführen – Query Store (im Azure Portal als “Performance Insight” aufbereitet) zeigt Top CPU/Duration Abfragen und deren Ausführungspläne. Damit kann man schnell die heavy queries identifizieren.
– Extended Events: Anstelle von SQL Profiler (der auf OS-Side .trc schreibt), nutzen Sie Extended Events, die in Azure verfügbar sind. Sie können z.B. eine Session auf sqlserver.rpc_completed & sqlserver.sql_batch_completed anlegen mit Filter > X ms und das im ring buffer loggen. Dann via DMX query das auslesen. Oder nutzen Azure Data Studio’s XEvent UI. So können Sie individuell sehr tief analysieren (deadlocks tracken etc.).
– Azure Monitor Metriken: Im Portal “Metrics” gibt’s Graphen für CPU, DTU, Data IO, Log IO, Memory, #Connections, etc. Hier sehen Sie trends, wann was peaked, das hilft Korrelation (z.B. oh CPU peaked um 3pm – deckt sich mit user complaint, ergo CPU bottleneck).
– Automatic Tuning und Advisor: Azure SQL kann selbst z.B. sagen “Index X ist ineffizient” oder “Plan Changed caused regression, forced last good plan”. Schauen Sie in Intelligent Performance (Portal) ob es solche Hinweise gibt.
– Third-Party APM: Tools wie AppInsights oder NewRelic an App-Seite messen Query times und can pinpoint slow DB calls. Indirekt Diagnose ohne OS.
– SQL Insights (Azure): Azure Monitor bietet ein Template “SQL Insights” mit vordef. Queries, das Telemetrie in Log Analytics speichert – ein fertiges Dashboard vom MS. Das umfasst Wait Stats, CPU, top queries, etc. Das kann man einschalten und dann in Log Analytics gut auswerten.
– No PerfMon/TaskMgr: Was OS-spezifisch wäre (e.g. CPU per core, OS memory) – diese Infos gibt’s in DMVs (like sys.dm_os_sys_info for CPU count, SQL memory clerk usage for mem). Disk queue etc. Azure hides, aber man sieht an Wait Stats (WRITE_LOG waits -> log disk slow).
– Proactives: Use Query Store hinting or plan forcing if needed (lack OS not hamper that).
Also to mention: On MI or VM, you do have OS, MI not (just limited via DM). On VM of course you use Windows tools normal.
So in summary: Nutzen Sie DMVs, Query Store und Azure Monitor anstelle von OS-Perfmon. Es erfordert etwas Umdenken, ist aber gleich effizient. In vielen Fällen sogar besser, weil z.B. QStore gibt aggregated data historically, was on OS so leicht nie war.

Frage: Was ändert sich bei der Backup-Strategie gegenüber on-prem?
Antwort: In on-premises Umfeld hat man typischerweise Full Backups (z.B. nachts), Differential (vielleicht alle 12h) und Log backups (alle 15min), mit eigenen Scripten oder Tools. Man muss Speichermedien verwalten, Offsite bringen, etc. In Azure SQL PaaS wird all das automatisch erledigt:
– Backup-Frequenz: Full Weekly, Diff ~12-24h, Log ~5-10min (genaue Intervalle managt Azure adaptiv). Sie können es nicht anpassen (nur retention). Also das “Backup-Scheduling” entfällt.
– Speicherort: Backups landen in geo-redundantem Storage (wenn Sie keine andere Option wählen). Das heißt, sie sind offsite (andere Region) vorhanden per default – etwas, das man on-prem oft manuell tun musste (Bänder etc.).
– Verfügbarkeit: Sie können jederzeit im Portal ein Point-in-Time wählen und Restore-Knopf drücken – kein Suchen nach richtigen Backup-Dateien, kein manuelles Übertragen. Das beschleunigt Wiederherstellung enorm.
– Kein Backup-Zeitpunkt-Fenster: Da Azure im Hintergrund Snapshots/differential durchführt, gibt es keinen spürbaren Performanceeinbruch beim Backup (on-prem hatte man oft IO-Load nachts). Hier ist es verteilt und optimiert.
– Kein manueller Eingriff nötig: Sie definieren nur retention (7-35 Tage PITR, plus LTR if needed). Azure sorgt stets dafür, dass genügend Backups zum Erfüllen vorhanden, alte löscht es.
Was ändert sich also für Sie? Sie müssen eher in Richtung Überwachung und Policy denken: Sind die Aufbewahrungsfristen compliance-gerecht? Muss ich LTR aktivieren? Wann und wie teste ich Restores (siehe oben – neu wichtig, weil man den Mechanismus ja nicht selbst ausführt, will aber sicher sein, dass er funktioniert).
Änderung im Worst-Case: Früher hat man Archive evtl. jahrelang behalten und Offline entnommen. Mit Azure LTR kann man bis 10 J. in Azure halten. Wenn darüber, müsste man in Azure Backup Vault etc. Hier bei extremer long retention vllt. mal Backup lokal runterladen (z.B. Bacpac export 1x, in BLOB archiv).
Schnelligkeit: Aus Azure-Backups restore geht fix, aber auch hier – sehr große DB (TBs) aus geo-storage restoren dauert. Hyperscale hat da Riesenvorteil. On-prem musste man I/O auf Tape etc.
Kultur: Sie werden sich mehr darauf verlassen, dass Azure seinen Job macht. Das erfordert Vertrauen, daher emphasizen wir: Monitoring + periodische Tests.
Keine Wahl vom Backup-Tool: Fancy Tools (Rubrik, NetBackup) nicht nötig – erspart Lizenz und Komplexität.
Datenbank Kopien: In on-prem hat man manchmal DB detach/attach oder copy backup to refresh test. In Azure kann man direkter CREATE DATABASE AS COPY OF Prod – wesentlich simpler.
Downlevel Moves: Bedenken Sie, es gibt kein concept wie log shipping in PaaS – wenn Sie z.B. regelmäßig on-prem copy wollen, nutzen Sie Bacpac or replication. Aber interne Speichershift simpler via copy.
In Kurz: Backup-Management wird in Azure stärker zum Backup-Validation-Management**. Fokussieren Sie auf “können wir wiederherstellen?” statt “Backup läuft?” – Letzteres tut’s meist.
Auf VMs natürlich bleibt es wie on-prem, dort ändert sich nichts, außer dass man Azure Backup Service in Anspruch nehmen kann, was Ähnliches on top regelt.

Frage: Wie sieht eine Exit-Strategie aus – kann ich zurück on-prem oder in andere Clouds migrieren?
Antwort: Eine berechtigte Frage – Vendor Lock-in vermeiden. Grundsätzlich sind Azure SQL-Datenbanken portierbar, da sie auf SQL Server-Technologie basieren:
– Zurück on-premises: Sie können jederzeit ein Backup/Bacpac Ihrer Azure SQL-Datenbank nehmen und in einem lokalen SQL Server wieder einspielen. Für Azure SQL DB Single/Elastic wäre das via BACPAC (für Schema+Data), weil .bak Export wird nicht bereitgestellt (kein BACKUP TO DISK auf user side). Tools wie Azure SQL Migration Wizard oder Export in SSMS unterstützen das. Bei Managed Instance können Sie sogar ein Backup zur URL erstellen (BACKUP DATABASE … TO URL=’Azure Blob‘) und diese .bak dann auf on-prem SQL Server RESTOREn. Das erleichtert MIG raus. Die Schema- und TSQL-Kompatibilität ist hoch – sofern Ihr on-prem Server eine Version >= Azure Compat (z.B. Azure war vNext mit Features, vlt. muss man dort Abwärtskompat einstellen, aber i.d.R. sollte es auf neuem on-prem problemlos laufen).
– In andere Clouds: Im Prinzip ähnlich: Sie können z.B. einen Bacpac oder Backup ziehen und in einer SQL Server-Instanz in AWS EC2 oder Google Compute Engine laden. Oder in einen AWS RDS for SQL Server (das nimmt native .bak my EFS share). Bacpac geht auch auf AWS RDS (gibt Tools). Also es ist machbar – no technical blockade. Das aufwändigste ist eben, die Daten (ggf. viele GB/TB) rauszuschaffen: do it via Azure Blob (download), or replicate for minimal downtime.
– Achtung bei speziellen Features: Wenn Sie Azure-spezifische Features genutzt haben, kann der Weg zurück steiniger sein: z.B. eine App verlässt sich auf Azure AD-Authentifizierung – on-prem muss man dann AAD integrated auth via AD sync oder so nachbauen. Oder Hyperscale (100 TB DB) – on-prem Standard-Edition kommt mit 100 TB vllt. nicht gut klar (Filegroups etc. needed). Also solche Ultra-Scale-Szenarien sind schwerer portierbar (theoretisch mit sharded on prem cluster).
– Vorbereitung: Als Teil Exit-Plan sollten Sie z.B. regelmäßige Bacpacs/Backups extern sichern, so haben Sie stets einen einigermaßen aktuellen Stand offline. Einige Unternehmen machen z.B. monatlich Bacpac aller Cloud-DBs und legen sie auf eigenes Storage – falls mal abrupt Cloud kündigen müssen, hat man was (beachten: sensible, encryption).
– Verbundene Dienste: Wenn Sie heavy Platform Services (z.B. Azure Functions triggers on SQL events, etc.) verwendeten, muss man bei Exit diese Funktion in anderer Cloud neu aufsetzen – nur DB mitzunehmen reicht nicht, auch Applogik muss portiert. DB-Seitig aber – es ist Standard-SQL.
– Kosten/zeit: Je größer DB, desto latenter / evtl. teure Egress-Kosten. Planen Sie dafür (bei 10 TB DB downzuladen – not trivial im allowed maintenance window). Option: Azure Data Box – man könnte auch per Harddisk export.
In Summe: Exit ist möglich und relativ geradlinig auf technischer Ebene (Backup/Bacpac). Die eigentliche Challenge sind anwendungsspezifische Anpassungen und der Datenlogistik. Bewahren Sie deshalb Kompatibilität soweit es geht (z.B. nicht unnötig Stored Procedures mit Azure-specific DMVs vollstopfen, oder reliant on azure-only features), damit im Fall der Fälle Code portabel bleibt. Viele fahren eh Hybrid, sodass man Kopie on-prem testet – so hat man pfad zurück.

Damit hoffen wir, einen umfassenden Leitfaden zu Azure SQL bereitgestellt zu haben – von den strategischen Überlegungen bis zu ganz praktischen Tipps für den Alltag im Betrieb. Viel Erfolg bei Ihren Azure SQL Projekten!

Weitere Beiträge zum Thema SQL Server