Azure Databases Azure Databases

Technische Referenz auf Level 500 für Azure SQL Database, Azure SQL Managed Instance, Azure Cosmos DB, PostgreSQL Flexible Server, MySQL Flexible Server, Azure Cache for Redis und Azure Database Migration Service. Fokus: Architekturentscheidungen, HA/DR, Kostenmodelle, Netzdesign, Sicherheit, Migration und Betrieb. Level 500 technical reference for Azure SQL Database, Azure SQL Managed Instance, Azure Cosmos DB, PostgreSQL Flexible Server, MySQL Flexible Server, Azure Cache for Redis, and Azure Database Migration Service. Focus: architecture choices, HA/DR, cost models, network design, security, migration, and operations.

Servicevergleich und Architekturrahmen Service comparison and architectural frame

Azure-Datenbankdienste unterscheiden sich nicht nur nach relational versus NoSQL. Entscheidend sind Isolationseinheit, Konnektivitätsmodell, Betriebsgrenze, Replikationssemantik und die Frage, ob die Plattform oder das Anwendungsteam das meiste Tuning tragen soll. Azure database services differ by much more than relational versus NoSQL. The critical dimensions are the isolation unit, connectivity model, operational boundary, replication semantics, and whether the platform or the application team is expected to carry most of the tuning effort.

Für Enterprise-Architekturen lohnt sich ein Vergleich entlang von RPO/RTO, Identitätsintegration, Netzwerkprivatisierung, Schema-Kompatibilität, Read/Write-Mustern und der Fähigkeit, horizontal zu skalieren. Die folgende Matrix fasst die technisch relevanten Unterschiede zusammen. For enterprise architectures it pays to compare services by RPO/RTO, identity integration, network privatization, schema compatibility, read/write patterns, and the ability to scale horizontally. The following matrix summarizes the technically relevant differences.

Azure SQL Database im Detail Azure SQL Database deep dive

Azure SQL Database ist das präziseste PaaS-Angebot für einzelne SQL-Server-Datenbanken oder Pool-Modelle. Es eignet sich hervorragend, wenn die Anwendung keine instanzweiten SQL-Server-Abhängigkeiten besitzt und das Team von automatisierter Sicherung, Patching, Telemetrie und hoher Plattformautomation profitieren will. Azure SQL Database is the most focused PaaS offering for single SQL Server databases or pool-based patterns. It works extremely well when the application has no instance-level SQL Server dependencies and the team wants to benefit from automated backup, patching, telemetry, and strong platform automation.

Architekturentscheidungen drehen sich hier vor allem um vCore versus DTU, General Purpose versus Business Critical, Hyperscale für sehr große OLTP-Systeme, sowie um die Wahl zwischen Single Database, Elastic Pool und Geo-DR-Topologien. Diese Entscheidungen prägen Kosten, Latenz und Betriebsmodell unmittelbar. Architecture decisions here revolve primarily around vCore versus DTU, General Purpose versus Business Critical, Hyperscale for very large OLTP systems, and the choice between single database, elastic pool, and geo-DR topologies. Those decisions directly shape cost, latency, and operations.

• Elastic Pools sind ideal für SaaS- oder Mandantenmuster, wenn viele Datenbanken schwankende Lasten teilen und eine einzelne Datenbank nur periodisch Spitzen erzeugt. Elastic pools are ideal for SaaS or tenant patterns where many databases share fluctuating demand and any one database peaks only periodically.
• Point-in-Time Restore ist standardmäßig mit 7 bis 35 Tagen verfügbar; Long-Term Retention deckt Monats- und Jahresaufbewahrung für Audit oder regulatorische Anforderungen ab. Point-in-time restore is available by default for 7 to 35 days; long-term retention covers monthly and yearly preservation for audit or regulatory needs.
• Maintenance Windows sollten explizit gesetzt werden, wenn Batchfenster, enge SLAs oder vendor-sensible Anwendungen planbare Wartungszeiten verlangen. Maintenance windows should be explicitly configured when batch windows, tight SLAs, or vendor-sensitive apps require predictable maintenance timing.
• Microsoft Defender for SQL liefert Bedrohungserkennung, Anomaliesignale und Schwachstellenbewertungen, ersetzt aber kein sauberes Least-Privilege-Modell. Microsoft Defender for SQL provides threat detection, anomaly signals, and vulnerability assessment, but it does not replace a sound least-privilege model.
• Azure-AD- beziehungsweise Microsoft-Entra-Authentifizierung sollte Standard für Benutzerkonten sein; SQL-Logins bleiben nur für Altanwendungen oder eng begrenzte Integrationen sinnvoll. Azure AD or Microsoft Entra authentication should be the standard for user accounts; SQL logins remain appropriate only for legacy applications or tightly bounded integrations.
• Automatic Tuning und Query Store sind besonders stark in Azure SQL, weil die Plattform Planregressionen und Indexempfehlungen direkt beobachtet. Automatic tuning and Query Store are especially strong in Azure SQL because the platform directly observes plan regressions and index opportunities.
• Connection Policy und Retry-Logik der Anwendung müssen zum Netzwerkdesign passen, insbesondere bei privaten Endpunkten, Gateways und regionalem Failover. The application connection policy and retry logic must match the network design, especially with private endpoints, gateways, and regional failover.

Azure SQL Managed Instance im Detail Azure SQL Managed Instance deep dive

Azure SQL Managed Instance richtet sich an Workloads, die zu groß, zu komplex oder zu instanznah für Azure SQL Database sind, aber trotzdem als PaaS betrieben werden sollen. Typische Kandidaten sind Vendor-Anwendungen, komplexe SQL-Agent-Topologien, Linked Servers oder Migrationen mit minimalen Codeänderungen. Azure SQL Managed Instance is aimed at workloads that are too large, too complex, or too instance-bound for Azure SQL Database, yet should still run as PaaS. Typical candidates are vendor applications, complex SQL Agent topologies, linked servers, or migrations that need minimal code changes.

Im Gegenzug für die hohe Kompatibilität bringt MI ein deutlich schwereres Netzwerk- und Lifecycle-Modell mit. Erstellungszeiten, Skalierung, DNS, Subnetzdelegation und Outbound-Abhängigkeiten sind operative Faktoren, keine Nebensachen. In exchange for that high compatibility, MI comes with a substantially heavier network and lifecycle model. Create times, scaling, DNS, subnet delegation, and outbound dependencies are operational factors, not side notes.

• Instance Failover Groups erweitern MI um echte regionale DR-Endpunkte und vereinfachen die Umschaltung ganzer Anwendungspakete. Instance failover groups add true regional DR endpoints to MI and simplify failover of entire application stacks.
• TDE ist standardmäßig aktiv; mit CMK verschiebt sich die Governance auf Key Vault, inklusive Anforderungen an Schlüsselverfügbarkeit und Rotation. TDE is enabled by default; with CMK, governance shifts to Key Vault, including requirements for key availability and rotation.
• Always Encrypted ist auf MI relevant, wenn Datenbankadministratoren keine Klartextsicht auf bestimmte Spalten erhalten dürfen. Always Encrypted matters on MI when database administrators must not have plaintext access to certain columns.
• Advanced Threat Protection beziehungsweise Microsoft Defender for SQL liefert auch auf MI Angriffs- und Fehlkonfigurationssignale. Advanced Threat Protection, now surfaced through Microsoft Defender for SQL, also provides attack and misconfiguration signals on MI.
• SQL Server Migration Assistant ist besonders wertvoll, wenn Schemakonvertierungen, Codeanalyse oder der Wechsel von Nicht-SQL-Server-Quellen ansteht. SQL Server Migration Assistant is especially valuable when schema conversions, code analysis, or migrations from non-SQL Server sources are required.
• MI-Link- und Backup-basierte Hybridmuster sollten immer mit realer Latenz und Recovery-Simulation getestet werden. MI Link and backup-based hybrid patterns should always be tested with real latency and recovery simulations.

Azure Cosmos DB im Detail Azure Cosmos DB deep dive

Azure Cosmos DB ist kein relationaler Ersatz, sondern eine global verteilte Datenplattform mit expliziter Throughput-Währung, kontrollierter Konsistenz und API-spezifischen Programmiermodellen. Die drei wichtigsten Architekturentscheidungen sind API-Auswahl, Partition Key und Throughput-Strategie. Azure Cosmos DB is not a relational substitute but a globally distributed data platform with an explicit throughput currency, controlled consistency, and API-specific programming models. The three most important architecture decisions are API choice, partition key, and throughput strategy.

Teams unterschätzen häufig, dass RU/s nicht einfach Last abbildet, sondern die Kosten von Reads, Writes, Queries, Indexierung und Speicherzugriffen über das physische Partitionsmodell repräsentiert. Ein fachlich plausibler, aber technisch schlechter Partition Key zerstört Skalierung und Kostenmodell zugleich. Teams often underestimate that RU/s is not a simple load number; it prices reads, writes, queries, indexing, and storage access through the physical partition model. A partition key that looks sensible to the business but poor technically breaks both scale and cost efficiency.

• RU/s müssen immer zusammen mit Indexing Policy, Item-Größe, Konsistenzgrad und Hot-Partition-Risiko geplant werden. RU/s must always be planned together with indexing policy, item size, consistency level, and hot-partition risk.
• Autoscale skaliert die bereitgestellte Leistung automatisch bis zum konfigurierten Maximum; typisch ist ein Wirkbereich zwischen 10 % und 100 % des Maximalwerts. Autoscale automatically scales provisioned throughput up to the configured maximum; the practical operating band is typically 10% to 100% of that maximum.
• Serverless eignet sich für niedrige Durchschnittslast, Entwicklung, sporadische Integrationen oder kleine produktive Spikeworkloads ohne dauerhaft reservierte RU/s. Serverless fits low average demand, development, sporadic integrations, or small spiky workloads without permanently reserved RU/s.
• Change Feed liefert einen geordneten Änderungsstrom pro logischer Partition und ist die Basis für Event-getriebene Folgeprozesse, Materialized Views oder CDC-nahe Integrationen. Change feed provides an ordered stream of changes per logical partition and forms the basis for event-driven downstream processing, materialized views, or CDC-like integrations.
• Analytical Store und Synapse Link entkoppeln analytische Abfragen vom transaktionalen RU-Budget und sind deshalb oft günstiger als ETL-Kopien auf Anforderung. Analytical store and Synapse Link decouple analytical queries from the transactional RU budget and are therefore often cheaper than ad-hoc ETL copies.
• TTL automatisiert das Auslaufen von Daten und ist besonders wertvoll für Session-, Telemetrie- oder Eventdaten mit klarer Aufbewahrungslogik. TTL automates data expiry and is especially valuable for session, telemetry, or event data with clear retention logic.
• CMK und Private Endpoints gehören in regulierten Umgebungen ebenso zum Standard wie Entra-RBAC für datennahe Operatorrollen. CMK and private endpoints belong in regulated environments just as much as Entra RBAC for data-adjacent operator roles.
• Multi-Region-Writes verbessern globale Latenz, verlangen aber bewusste Konfliktregeln und Idempotenz auf Anwendungsebene. Multi-region writes improve global latency but require deliberate conflict rules and application-level idempotency.
• 429-Throttling ist kein reiner Performancefehler, sondern ein Signal für falsch dimensionierte RU/s, Hot Partitions oder ineffiziente Query-/Indexmuster. 429 throttling is not merely a performance fault; it signals poorly sized RU/s, hot partitions, or inefficient query and indexing patterns.

PostgreSQL Flexible Server im Detail PostgreSQL Flexible Server deep dive

Azure Database for PostgreSQL - Flexible Server ist heute das bevorzugte PaaS-Ziel für PostgreSQL-Workloads in Azure. Der Dienst kombiniert weitgehende PostgreSQL-Kompatibilität mit zonenfähiger Hochverfügbarkeit, geplanter Wartung, nativer Replikation und moderner Netzwerkisolation. Azure Database for PostgreSQL - Flexible Server is the preferred PaaS target for PostgreSQL workloads in Azure today. It combines strong PostgreSQL compatibility with zone-aware high availability, planned maintenance, native replication, and modern network isolation.

Die zentralen Designhebel sind Compute-Tier, HA-Modus, Connection Pooling, Extension-Kompatibilität und das Verhältnis von Arbeitssatz zu verfügbarem RAM. In PostgreSQL entscheidet guter Plattformbetrieb oft stärker über Erfolg als der reine Migrationsmechanismus. The central design levers are compute tier, HA mode, connection pooling, extension compatibility, and the ratio of working set to available RAM. For PostgreSQL, sound platform operations often matter more to success than the migration mechanism.

• Point-in-Time Restore ist mit 7 bis 35 Tagen verfügbar und stellt den Dienst als neuen Server zu einem exakten Zeitpunkt bereit. Point-in-time restore is available for 7 to 35 days and restores the service as a new server at an exact timestamp.
• Automatische Patches und geplante Wartungsfenster reduzieren Betriebsaufwand, verlangen aber dennoch Kompatibilitätstests für Extensions und Treiber. Automatic patching and planned maintenance windows reduce operational overhead, but still require compatibility testing for extensions and drivers.
• Query Performance Insight und pg_stat_statements sollten gemeinsam genutzt werden, um Top-SQL, Wait-Muster und Planänderungen zu verstehen. Query Performance Insight and pg_stat_statements should be used together to understand top SQL, wait patterns, and plan changes.
• Private DNS Zones sind bei privatem Zugriff kein Detail, sondern Voraussetzung für zuverlässige Namensauflösung aus App-Subnets und Hybridnetzen. Private DNS zones are not an implementation detail under private access; they are a prerequisite for reliable name resolution from app subnets and hybrid networks.
• Delegierte Subnetze beziehungsweise VNet-Integration müssen gemeinsam mit Routing, NSG und ausgehenden Abhängigkeiten geplant werden. Delegated subnets and VNet integration must be designed together with routing, NSGs, and outbound dependencies.
• Read Replicas sind für Reporting wertvoll, ersetzen aber kein robustes Backup- und PITR-Konzept. Read replicas are valuable for reporting, but they do not replace a robust backup and PITR strategy.

MySQL Flexible Server im Detail MySQL Flexible Server deep dive

Azure Database for MySQL - Flexible Server ist das verwaltete Ziel für moderne MySQL-Anwendungen in Azure. Besonders im Web-, CMS-, SaaS- und E-Commerce-Umfeld profitieren Teams von automatischer Sicherung, planbarer Wartung, privater Netzwerkintegration und HA ohne Aufbau eigener Replikationstopologien. Azure Database for MySQL - Flexible Server is the managed destination for modern MySQL applications in Azure. In web, CMS, SaaS, and e-commerce scenarios especially, teams benefit from automatic backup, predictable maintenance, private networking, and HA without building their own replication topology.

Wichtige Unterschiede zu selbstverwaltetem MySQL liegen in Netzwerkpfaden, TLS-Erzwingung, Backup-Semantik, Maintenance Windows und im Limitsmodell für Verbindungen und Replikate. Erfolgreiche Migrationen testen diese Unterschiede vor dem ersten Produktionscutover. Key differences from self-managed MySQL lie in network paths, TLS enforcement, backup semantics, maintenance windows, and the limits model for connections and replicas. Successful migrations test those differences before the first production cutover.

• Automatische Minor-Version-Upgrades reduzieren Patchaufwand, müssen aber mit Treibern, ORM-Versionen und SQL-Modus getestet werden. Automatic minor version upgrades reduce patch effort, but must be tested with drivers, ORM versions, and SQL mode.
• Im Stopped State pausiert die Compute-Abrechnung, während Storage und Backups weiterhin Kosten verursachen können. In the stopped state, compute billing pauses while storage and backups can continue to incur cost.
• PITR von 1 bis 35 Tagen deckt operative Fehler gut ab, ersetzt aber keine Langzeitarchivierung oder fachliche Exportpflichten. One to 35 days of PITR covers operational mistakes well, but does not replace long-term archiving or business export obligations.
• Slow Query Logs und Performance-Metriken sollten früh aktiviert werden, damit nach dem Cutover sofort echte Tuningdaten vorliegen. Slow query logs and performance metrics should be enabled early so real tuning data is available immediately after cutover.
• CMK ist in regulierten Umgebungen relevant, weil Schlüsselrotation und Sperrung dann in den Governance-Prozess des Kunden integriert werden. CMK matters in regulated environments because key rotation and key disablement then integrate into the customer's governance process.
• Azure-AD- beziehungsweise Microsoft-Entra-Authentifizierung reduziert lokale Passwortkonten und verbessert die Nachvollziehbarkeit von Adminzugriffen. Azure AD or Microsoft Entra authentication reduces local password accounts and improves traceability of admin access.
• Read Replicas sollten mit echter Anwendungslast getestet werden, weil ORM-Patterns und schreibabhängige Reads häufig unerwartete Konsistenzannahmen enthalten. Read replicas should be tested with real application load because ORM patterns and write-dependent reads often carry hidden consistency assumptions.

Azure Cache for Redis im Detail Azure Cache for Redis deep dive

Azure Cache for Redis ist kein Ersatz für eine Primärdatenbank, sondern ein Beschleunigungs- und Entkopplungsdienst für Sitzungsspeicher, Token, Konfigurationsdaten, Suchstrukturen, Ranglisten, Materialized Views und Queue-nahe Muster. Architekturfehler entstehen oft dann, wenn Redis als dauerhaft verlässlicher System of Record behandelt wird. Azure Cache for Redis is not a replacement for a primary database but an acceleration and decoupling service for session storage, tokens, configuration, search structures, leaderboards, materialized views, and queue-adjacent patterns. Architectural mistakes often appear when Redis is treated as a permanently reliable system of record.

Die wesentlichen Entwurfsfragen sind Tierwahl, Persistenzbedarf, Clusterfähigkeit, Modulnutzung, Private Networking und Eviction-Strategie. Für Enterprise-Designs sind diese Punkte genauso wichtig wie reiner Speicherbedarf. The essential design questions are tier choice, persistence needs, clusterability, module usage, private networking, and eviction strategy. For enterprise designs, these points matter as much as raw memory capacity.

• Zonenredundanz sollte für kritische Produktionscaches geprüft werden, sofern SKU und Region dies unterstützen. Zone redundancy should be evaluated for critical production caches where the SKU and region support it.
• Private Endpoints sind der bevorzugte Zugangspfad; bei Premium kann zusätzlich VNet-Injection für engere Netzsteuerung relevant sein. Private endpoints are the preferred access path; Premium can additionally use VNet injection where tighter network control is needed.
• Deaktivieren Sie den Non-SSL-Port standardmäßig und validieren Sie TLS auf allen Clients, Build Agents und Batchprozessen. Disable the non-SSL port by default and validate TLS across all clients, build agents, and batch processes.
• Persistenz braucht Restore-Tests; ein aktivierter Haken allein beantwortet keine RPO/RTO-Frage. Persistence requires restore tests; an enabled checkbox alone does not answer the RPO/RTO question.
• Clustering beeinflusst Key-Design, Lua, Pub/Sub und Multi-Key-Operationen; diese Wechselwirkungen müssen Entwicklerteams kennen. Clustering affects key design, Lua, Pub/Sub, and multi-key operations; engineering teams must understand those interactions.
• Cache-Hit-Rate, Evictions und Memory Fragmentation sind die drei wichtigsten Frühwarnsignale für Fehlgröße oder falsche Datenstrukturen. Cache hit rate, evictions, and memory fragmentation are the three most important early warning signals for poor sizing or wrong data structures.

Azure Database Migration Service im Detail Database Migration Service deep dive

Azure Database Migration Service beschleunigt Migrationsprojekte, indem es Assessment, Datenkopie, Online-Synchronisierung und Statuskontrolle in einen verwalteten Dienst verlagert. Der Dienst ersetzt jedoch keine Zielarchitektur und auch kein sauberes Cutover-Playbook. Azure Database Migration Service accelerates migration projects by moving assessment, data copy, online synchronization, and status control into a managed service. It does not, however, replace target architecture work or a sound cutover playbook.

Die Erfolgsfaktoren liegen typischerweise außerhalb des Dienstes selbst: Netzwerkreichweite, DNS, Rechte auf Quelle und Ziel, Validierung von nicht unterstützten Features sowie ein realistisches Testfenster mit Produktionsdatenvolumen. DMS ist ein Verstärker guter Planung, kein Ersatz dafür. The success factors typically lie outside the service itself: network reachability, DNS, permissions on source and target, validation of unsupported features, and a realistic test window with production-scale data. DMS amplifies good planning; it does not replace it.

• SSMA ist für Schema- und Codekonvertierung oft das notwendige Vorwerkzeug, während DMS den Datentransfer und die Synchronisierung übernimmt. SSMA is often the required front-end tool for schema and code conversion while DMS handles data transfer and synchronization.
• Die Azure Database Migration Guide sollte früh konsultiert werden, um engine-spezifische Blocker, Versionspfade und bekannte Einschränkungen zu erkennen. The Azure Database Migration Guide should be consulted early to surface engine-specific blockers, version paths, and known constraints.
• Der Cutover-Schritt muss als eigener Runbook-Abschnitt geplant werden, inklusive finalem Sync, Anwendungspause, Smoke Tests und Backout-Entscheidung. The cutover step must be planned as its own runbook section including final sync, application pause, smoke tests, and a backout decision.
• Online-Migrationen mit minimaler Downtime funktionieren nur, wenn Replikationslag, Änderungsrate und Anwendungsschreibmuster vorher gemessen wurden. Minimal-downtime online migrations work only when replication lag, change rate, and application write patterns have been measured up front.
• Für große BLOB- oder LOB-Daten lohnt sich ein Pilot mit echter Netzbandbreite und realer Paketgröße, da theoretische Throughput-Zahlen wenig aussagen. For large BLOB or LOB datasets, run a pilot with real network bandwidth and actual packet sizes because theoretical throughput numbers say little.
• DMS-Projekte sollten immer Telemetrie nach Log Analytics oder zumindest in ein zentrales Projektboard zurückschreiben, damit Teams nicht nur auf Portal-Screenshots angewiesen sind. DMS projects should always push telemetry into Log Analytics or at least a central project board so teams are not relying on portal screenshots alone.

HA, Backup und Disaster Recovery HA, backup, and disaster recovery

Nicht jeder Azure-Datenbankdienst versteht HA, Backup und DR gleich. Manche Dienste replizieren primär für Verfügbarkeit, andere für globale Latenz, wieder andere nur für Read Scale-out. Daraus folgen unterschiedliche RPO-, RTO- und Teststrategien. Not every Azure database service treats HA, backup, and DR the same way. Some replicate primarily for availability, others for global latency, and still others only for read scale-out. That leads to very different RPO, RTO, and testing strategies.

Sicherheit und Networking Security and networking

Datenbanksicherheit in Azure ist ein Zusammenspiel aus Identität, Netzwerk, Verschlüsselung, Telemetrie und kontrollierten Verwaltungsgrenzen. Wer nur auf TDE oder nur auf Firewall-Regeln schaut, baut keine belastbare Datenplattform. Database security in Azure is the combination of identity, networking, encryption, telemetry, and controlled administrative boundaries. Looking only at TDE or only at firewall rules does not create a resilient data platform.

• Defender for SQL und ähnliche Security-Produkte sollten in ein zentrales SOC- oder SIEM-Modell eingebunden werden, statt isoliert im Datenbankteam zu bleiben. Defender for SQL and similar security products should feed a central SOC or SIEM model rather than remain isolated in the database team.
• Advanced Threat Protection ergänzt Signaturen und Anomalieerkennung, ersetzt aber weder RBAC noch Private Networking. Advanced Threat Protection adds signatures and anomaly detection, but replaces neither RBAC nor private networking.
• Auditing nach Log Analytics oder Storage liefert die forensische Grundlage für Zugriffs-, Change- und Compliance-Auswertungen. Auditing to Log Analytics or Storage provides the forensic foundation for access, change, and compliance investigations.
• Transparent Data Encryption schützt ruhende Daten auf Medienebene und sollte als Basiskontrolle überall aktiv sein. Transparent Data Encryption protects data at rest at the media layer and should be enabled everywhere as a baseline control.
• Always Encrypted ist relevant, wenn Datenbankadministratoren, Cloud-Operatoren oder Outsourcing-Partner keinen Klartext sehen dürfen. Always Encrypted matters when database administrators, cloud operators, or outsourcing partners must not see plaintext.
• Dynamic Data Masking ist ein Komfortfeature für reduzierte Sichtbarkeit, aber kein kryptographischer Schutzmechanismus. Dynamic Data Masking is a convenience feature for reduced visibility, not a cryptographic protection mechanism.
• Private DNS, Split-Horizon-Design und Namensauflösung über Hybridnetze sollten in Security Reviews explizit geprüft werden. Private DNS, split-horizon design, and name resolution across hybrid networks should be explicitly reviewed in security assessments.

PowerShell und Azure CLI PowerShell and Azure CLI

Automatisierung ist für Azure-Datenbanken kein Luxus, sondern Standard. Bereitstellung, Failover, Inventarisierung und Compliance-Prüfungen sollten reproduzierbar per Skript oder IaC erfolgen, damit Änderungen über Regionen und Umgebungen hinweg konsistent bleiben. Automation is not a luxury for Azure databases but the norm. Provisioning, failover, inventory, and compliance checks should be reproducible through scripts or IaC so changes remain consistent across regions and environments.

Get-AzSqlDatabase -ResourceGroupName "rg-data-prod" -ServerName "sqlsrv-prod-01" |
Select-Object DatabaseName, Edition, RequestedServiceObjectiveName, CurrentServiceObjectiveName, ZoneRedundant

New-AzSqlDatabaseFailoverGroup `
  -ResourceGroupName "rg-data-prod" `
  -ServerName "sqlsrv-primary-01" `
  -PartnerResourceGroupName "rg-data-dr" `
  -PartnerServerName "sqlsrv-dr-01" `
  -FailoverGroupName "fg-orders" `
  -FailoverPolicy Automatic `
  -GracePeriodWithDataLossHours 1 `
  -Database @("orders", "billing")
        

az sql db create \
  --resource-group rg-data-prod \
  --server sqlsrv-prod-01 \
  --name appdb01 \
  --service-objective GP_Gen5_4 \
  --backup-storage-redundancy Geo

az cosmosdb create \
  --name cos-global-prod01 \
  --resource-group rg-data-prod \
  --kind GlobalDocumentDB \
  --locations regionName=westeurope failoverPriority=0 isZoneRedundant=true \
  --locations regionName=northeurope failoverPriority=1 \
  --default-consistency-level Session \
  --enable-multiple-write-locations true
        

resource ordersContainer 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers@2024-05-15' = {
  name: '${cosmosAccount.name}/${sqlDatabaseName}/orders'
  properties: {
    resource: {
      id: 'orders'
      partitionKey: {
        paths: [
          '/tenantId'
        ]
        kind: 'Hash'
      }
      defaultTtl: 2592000
    }
    options: {
      autoscaleSettings: {
        maxThroughput: 20000
      }
    }
  }
}
        

Monitoring und Betrieb Monitoring and operations

Betriebsqualität hängt in Azure-Datenbanken davon ab, wie gut Plattformmetriken, Query-Telemetrie, Sicherheitslogs und Fehlermuster in ein gemeinsames Observability-Modell einfließen. Isolierte Portalsichten reichen für größere Flotten nicht aus. Operational quality in Azure databases depends on how well platform metrics, query telemetry, security logs, and failure patterns feed a shared observability model. Isolated portal views are not enough for larger fleets.

Migrationsprozess Migration process

Migrationen scheitern selten an einem einzelnen Tool. Sie scheitern an fehlender Zielarchitektur, ungeprüften Netzpfaden, nicht getesteter Authentifizierung, unklaren Cutover-Kriterien oder fehlender Verantwortung nach dem Go-Live. Ein guter Prozess minimiert genau diese Risiken. Migrations rarely fail because of a single tool. They fail because the target architecture is unclear, network paths are untested, authentication is unvalidated, cutover criteria are vague, or ownership after go-live is missing. A good process minimizes exactly those risks.

Limits und Quoten Limits and quotas

Cloud-Datenbanken skalieren weit, aber nie unbegrenzt. Die relevanten Grenzen liegen oft nicht im Marketing-SKU, sondern in Partitionen, Verbindungen, Replikationslag, Managementzeiten oder im Verhalten angrenzender Netzwerkkomponenten. Cloud databases scale far, but never infinitely. The relevant boundaries often lie not in the marketing SKU but in partitions, connections, replication lag, management times, or the behavior of adjacent network components.

Empfohlene Praktiken Recommended practices

Die folgenden Empfehlungen haben sich in realen Enterprise-Landing-Zones bewährt, weil sie Fehlentscheidungen bei Sizing, Sicherheit, DR und Migrationen früh abfangen. The following recommendations have proven themselves in real enterprise landing zones because they catch poor decisions around sizing, security, DR, and migrations early.

• Treffen Sie die Servicereise nicht nach Markenname, sondern nach Datenmodell, Latenzprofil, Konsistenz und Betriebsgrenzen. Choose the service based on data model, latency profile, consistency, and operational boundaries rather than the product label.
• Planen Sie Identität zuerst: Microsoft Entra ID, verwaltete Identitäten und rollenbasierte Trennung reduzieren Geheimnisse und Rotationsaufwand. Design identity first: Microsoft Entra ID, managed identities, and role separation reduce secrets and rotation effort.
• Nutzen Sie Private Endpoints oder delegierte Subnetze als Standard und behandeln Sie Firewall-Allowlisten nur als Übergangsmechanismus. Use private endpoints or delegated subnets by default and treat firewall allowlists only as a transition mechanism.
• Testen Sie Restore, Geo-Failover und Schlüsselrotation regelmäßig; ungeprüfte DR-Pläne sind nur Dokumente. Test restore, geo-failover, and key rotation regularly; untested DR plans are only documents.
• Vermeiden Sie übereilte Serverless- oder Autoscale-Entscheidungen ohne Messwerte zu Idle-Zeit, Burst-Verhalten und Resume-Latenz. Avoid rushed serverless or autoscale decisions without metrics on idle time, burst behavior, and resume latency.
• Modellieren Sie Partition Keys in Cosmos DB anhand realer Zugriffs- und Schreibmuster, nicht nach rein fachlichen Entitäten. Model Cosmos DB partition keys based on real access and write patterns, not purely on business entities.
• Verwenden Sie Query Store, Query Performance Insight und strukturierte Baselines vor jeder größeren Migration oder Tuning-Maßnahme. Use Query Store, Query Performance Insight, and structured baselines before every major migration or tuning exercise.
• Planen Sie bei SQL Managed Instance und privaten PaaS-Diensten DNS, UDR, NSG und Outbound-Abhängigkeiten gemeinsam mit dem Netzwerkteam. Plan DNS, UDR, NSG, and outbound dependencies jointly with the networking team for SQL Managed Instance and private PaaS services.
• Nutzen Sie Redis nicht als einzige Quelle geschäftskritischer Daten, solange Persistenz, Rebuild-Logik und DR nicht explizit definiert sind. Do not use Redis as the sole source of critical business data unless persistence, rebuild logic, and DR are explicitly defined.
• Bewerten Sie Migrationserfolg nicht nur nach technischer Replikation, sondern nach fachlicher Validierung, Performance und Betriebsübergabe. Measure migration success not only by technical replication but also by business validation, performance, and operational handoff.

Glossar Glossary

Das Glossar bündelt Schlüsselbegriffe, die in Azure-Datenbankprojekten regelmäßig in Architekturdiagrammen, Runbooks, Supportfällen und Kostenmodellen auftauchen. The glossary captures key terms that appear repeatedly in Azure database projects, architecture diagrams, runbooks, support cases, and cost models.