Zum Hauptinhalt springen
Cloud / Azure / Produkte / Azure Cosmos DB: global verteilte NoSQL- & KI-Datenbank

Azure Cosmos DB: global verteilte NoSQL- & KI-Datenbank

Azure Cosmos DB: global verteilte NoSQL- und Vektordatenbank mit einstelliger Millisekunden-Latenz, 99,999% SLA und integrierter KI-Suche.

databases
Preismodell Request Units (RU/s), Autoscale oder Serverless
Verfügbarkeit Alle Azure-Regionen weltweit (Multi-Region Writes)
Datensouveränität EU-Regionen mit Datenresidenz-Garantie
Zuverlässigkeit 99,999% (Multi-Region), 99,99% (Single Region) SLA

Azure Cosmos DB ist eine vollständig verwaltete, global verteilte NoSQL- und Vektordatenbank für moderne Anwendungen. Sie liefert einstellige Millisekunden-Antwortzeiten, bis zu 99,999% Verfügbarkeit und unterstützt mehrere APIs, darunter NoSQL, MongoDB, Cassandra, Gremlin und Table. Microsoft positioniert Cosmos DB heute als zentrale KI-Datenbank: Der Dienst trägt unter anderem die ChatGPT-Workloads von OpenAI.

Was ist Azure Cosmos DB?

Azure Cosmos DB ist eine vollständig verwaltete, global verteilte NoSQL- und Vektordatenbank von Microsoft Azure für unternehmenskritische Anwendungen. Der Service garantiert einstellige Millisekunden-Antwortzeiten und bis zu 99,999% Verfügbarkeit bei Multi-Region-Deployments. Im Gegensatz zu klassischen Datenbanken bietet Cosmos DB eine horizontale Skalierung über beliebig viele Azure-Regionen hinweg, ohne dass Sie sich um Replikation oder Sharding kümmern müssen. Microsoft beschreibt den Dienst inzwischen als Unified AI Database, da er Document-, Vektor-, Key-Value-, Graph- und Table-Datenmodelle in einem Service vereint.

Ein Alleinstellungsmerkmal ist die Multi-Model-Unterstützung: Sie können dieselbe Datenbank über verschiedene APIs ansprechen, darunter NoSQL (Document), MongoDB, Cassandra, Gremlin (Graph) und Table API. Das bedeutet, Sie können bestehende MongoDB- oder Cassandra-Anwendungen ohne Code-Änderungen migrieren. Cosmos DB bietet zudem fünf konfigurierbare Konsistenzlevel (Strong, Bounded Staleness, Session, Consistent Prefix, Eventual), die einen Mittelweg zwischen strikter Konsistenz und maximaler Performance ermöglichen. Damit können Sie für jede Anwendung die passende Balance zwischen Verfügbarkeit, Latenz und Konsistenz wählen.

Für KI-Anwendungen ist die integrierte Vektorsuche entscheidend. Cosmos DB für NoSQL bietet eine allgemein verfügbare Vektorsuche mit dem DiskANN-Index, kombiniert mit Volltextsuche (BM25) und Hybridsuche über Reciprocal Rank Fusion. So speichern Sie Embeddings direkt neben Ihren operativen Daten und bauen RAG-Pipelines, KI-Agenten oder LLM-Caching, ohne eine separate Vektordatenbank zu betreiben. Optionen wie Quantisierung und Float16-Embeddings reduzieren den Speicherbedarf und beschleunigen die Vektorsuche.

Bei der Kapazitätsplanung stehen zwei Modelle zur Verfügung: Serverless eignet sich für unvorhersehbare Workloads mit sporadischem Traffic und rechnet pro Request ab, läuft aber in genau einer Azure-Region pro Konto. Provisioned Throughput (manuell oder mit Autoscale) ist dagegen für Production-Workloads mit konstantem oder planbarem Traffic und für globale Verteilung konzipiert. Autoscale passt die Request Units (RU/s) automatisch an die Last an und optimiert so Kosten bei schwankender Auslastung. Beide Modelle bieten automatische Indizierung aller Properties, Change Feed für Event-driven Architekturen und Point-in-Time Restore für bis zu 30 Tage. Für mandantenfähige und hochkardinale Workloads ermöglichen hierarchische Partition Keys (Subpartitioning) eine Skalierung über das Limit einer einzelnen logischen Partition hinaus.

Kernfunktionen

  • Globale Verteilung mit Multi-Region Writes: Replizieren Sie Daten mit einem Klick in beliebige Azure-Regionen und aktivieren Sie Active-Active-Schreibvorgänge mit automatischem Failover und 99,999% SLA.
  • Integrierte KI-Suche: Vektorsuche mit DiskANN-Index, Volltextsuche mit BM25 und Hybridsuche über Reciprocal Rank Fusion: alles direkt neben Ihren operativen Daten.
  • Flexible Datenmodelle über mehrere APIs: NoSQL, MongoDB (RU und vCore), Cassandra, Gremlin, Table und PostgreSQL in einem Service.
  • Elastische Kapazität: Serverless, Provisioned Throughput und Autoscale skalieren Durchsatz und Storage unabhängig voneinander, auch bei unvorhersehbaren Lastspitzen.
  • Tunable Consistency: Fünf Konsistenzlevel von Strong bis Eventual erlauben pro Anwendung die passende Balance aus Latenz, Verfügbarkeit und Konsistenz.
  • Change Feed und HTAP: Event-driven Architekturen über den Change Feed sowie No-ETL-Analytics über Azure Synapse Link und Fabric Mirroring.

Typische Anwendungsfälle

KI-Anwendungen, RAG und KI-Agenten

Generative-KI-Anwendungen speichern Embeddings und operative Daten gemeinsam in Cosmos DB. Die integrierte Vektorsuche mit DiskANN liefert relevante Kontexte für Retrieval Augmented Generation (RAG), während Hybridsuche semantische und keyword-basierte Treffer kombiniert. KI-Agenten greifen auf Live-Daten zu, und LLM-Caching reduziert Kosten und Latenz. Da Vektoren und Anwendungsdaten in einer Datenbank liegen, entfällt die Synchronisation mit einer separaten Vektordatenbank.

Global verteilte E-Commerce-Plattformen

Online-Shops mit weltweiter Kundschaft nutzen Cosmos DB für Produktkataloge, Warenkörbe und Bestellhistorien. Durch Multi-Region-Writes können Kunden in Asien, Europa und Amerika gleichzeitig einkaufen, während lokale Replikate für niedrige Latenzen sorgen. Session-Konsistenz garantiert, dass ein Kunde seine eigenen Änderungen sofort sieht, auch wenn globale Replikation einige Sekunden dauert.

IoT-Telemetrie und Zeitreihendaten

Millionen von IoT-Geräten senden kontinuierlich Sensordaten an Cosmos DB. Die Serverless-Option eignet sich für unregelmäßige Datenströme, während Autoscale bei konstanten Schreiblasten Kosten optimiert. Change Feed ermöglicht Stream-Processing über Azure Functions, um Anomalien in Echtzeit zu erkennen. Die automatische Indizierung aller Properties erlaubt Ad-hoc-Queries ohne Schema-Design.

Personalisierungs- und Recommendation-Engines

Streaming-Dienste und Content-Plattformen speichern Nutzerprofile, Watch-History und Präferenzen in Cosmos DB. Die Graph API (Gremlin) modelliert Beziehungen zwischen Nutzern, Inhalten und Tags für kollaborative Filter. Mit Session-Konsistenz sehen Nutzer ihre Interaktionen sofort, während Eventual Consistency für globale Recommendations ausreicht. Sub-10ms-Latenzen ermöglichen Echtzeit-Personalisierung während des Browsings.

Gaming-Leaderboards und Session-Stores

Multiplayer-Games nutzen Cosmos DB für Echtzeit-Ranglisten, Spielerstände und Matchmaking-Daten. Die niedrige Latenz ist entscheidend für Gameplay-Features wie Live-Turniere. Multi-Region-Deployments reduzieren Ping-Zeiten für Spieler weltweit. Die Table API bietet einfache Key-Value-Zugriffe für Session-Daten, während NoSQL API komplexe Spielerprofile unterstützt.

Real-Time Analytics und Dashboards

Business-Intelligence-Anwendungen aggregieren Daten aus verschiedenen Quellen in Cosmos DB für Live-Dashboards. Change Feed triggert Azure Functions, die Metriken berechnen und in Power BI visualisieren. Bounded Staleness Consistency garantiert, dass Analysten maximal X Sekunden alte Daten sehen. Autoscale passt sich automatisch an Spitzenzeiten an, etwa bei Monats-Reports.

Mobile Apps mit Offline-Sync

Mobile Banking-, CRM- und Field-Service-Apps synchronisieren Daten zwischen Geräten und Cloud. Die MongoDB API ermöglicht Offline-First-Architekturen mit lokalen Datenbanken auf dem Device. Conflict Resolution Policies lösen Merge-Konflikte automatisch. Strong Consistency für kritische Transaktionen kombiniert mit Eventual für unkritische Daten optimiert Performance und Compliance.

Multi-Region SaaS-Plattformen

B2B-SaaS-Anbieter hosten mandantenfähige Anwendungen in Cosmos DB mit Data Residency pro Region. EU-Kunden werden ausschließlich in europäischen Regionen gespeichert, US-Kunden in amerikanischen. Partition Keys nach Tenant-ID isolieren Daten logisch. Provisioned Throughput mit Reserved Capacity senkt Kosten bei planbaren SaaS-Workloads um bis zu 63%.

Vorteile

  • Vorhersehbare Performance weltweit: Einstellige Millisekunden-Latenz bei Punkt-Reads und SLA-gestützte Garantien für Latenz, Durchsatz und Verfügbarkeit.
  • Eine Datenbank für KI und Operativbetrieb: Vektorsuche, Volltextsuche und Dokumentdaten in einem Service senken Architektur-Komplexität und Betriebsaufwand.
  • Geringer Betriebsaufwand: Vollständig verwalteter Dienst mit automatischer Indizierung, Patching und Skalierung, ohne Server- oder Shard-Verwaltung.
  • Kostenkontrolle: Serverless für sporadische Workloads, Autoscale für Lastspitzen und Reserved Capacity mit bis zu 63% Rabatt für planbare Baseline-Last.
  • Enterprise-Sicherheit und Compliance: Encryption at Rest und in Transit, Customer-Managed Keys, Azure RBAC und Managed Identities sowie Data Residency über die Region-Wahl.
  • Tiefe Azure-Integration: Native Anbindung an Azure Functions, Synapse Link, AI Foundry, Event Grid und Azure Monitor für End-to-End-Architekturen.

Azure Cosmos DB vs. Alternativen

Bei der Wahl einer Cloud-Lösung stellt sich oft die Frage nach Alternativen. Azure Cosmos DB konkurriert mit vergleichbaren Services anderer Cloud-Provider:

  • AWS: DynamoDB
  • Google Cloud: Firestore

Während die Funktionalität oft ähnlich ist, unterscheiden sich die Services in Pricing-Modellen, regionaler Verfügbarkeit und Integrations-Ökosystem. Azure punktet besonders bei Enterprise-Kunden mit Microsoft-Stack und Hybrid-Cloud-Szenarien.

Best Practices für Azure Cosmos DB

Konsistenzlevel strategisch wählen

Verwenden Sie nicht pauschal Strong Consistency. Session Consistency ist für die meisten Anwendungen ausreichend und bietet bessere Latenz bei Multi-Region-Deployments. Strong nur für Finanztransaktionen oder Inventar-Management. Eventual für Analytics und Reporting. Bounded Staleness als Mittelweg, wenn Sie maximale Staleness-Zeit definieren müssen (z.B. max 5 Minuten alte Daten).

Partition Key Design von Anfang an planen

Der Partition Key ist die wichtigste Design-Entscheidung und kann nachträglich nicht geändert werden. Wählen Sie einen Key mit hoher Kardinalität (viele eindeutige Werte) und gleichmäßiger Verteilung der Requests. Vermeiden Sie Hot Partitions durch Zeitstempel als Key. Beispiel: Bei E-Commerce nicht productId (wenige Bestseller), sondern userId oder Composite Key userId-date.

Serverless vs. Provisioned bewusst entscheiden

Serverless eignet sich für Dev/Test-Umgebungen, Prototypen und sporadische Workloads unter 50 GB. Production-Systeme mit konstantem Traffic fahren mit Provisioned günstiger. Autoscale ist ideal für schwankende, aber planbare Workloads (z.B. Business-Hours). Berechnen Sie den Break-Even: Ab ca. 100 RU/s Dauerlast ist Provisioned günstiger als Serverless.

Indexing Policies optimieren

Nutzen Sie Custom Indexing Policies, um Kosten und Performance zu optimieren. Schließen Sie Pfade aus, die nie abgefragt werden (z.B. große Binärdaten oder interne IDs). Composite Indexes beschleunigen Multi-Property-Queries. Spatial Indexes nur aktivieren, wenn Sie Geo-Queries nutzen. Jeder zusätzliche Index erhöht Write-Kosten um 10-20%.

Query-Performance durch Design verbessern

Vermeiden Sie Cross-Partition-Queries in Hot Paths. Denormalisieren Sie Daten, um Joins zu eliminieren. Nutzen Sie Projections, um nur benötigte Properties zu laden. Implementieren Sie Continuation Tokens für Pagination statt OFFSET. Change Feed statt Polling für Änderungserkennung. Monitoren Sie RU-Verbrauch pro Query im Azure Portal.

Multi-Region Writes gezielt einsetzen

Aktivieren Sie Multi-Region Writes nur wenn nötig, da es Kosten verdoppelt und Conflict Resolution erfordert. Für read-heavy Workloads reicht Single-Write-Region mit read-only Replicas. Definieren Sie explizite Conflict Resolution Policies (Last-Write-Wins, Custom Merge, oder Application-Level). Testen Sie Konfliktszenarien vor Production-Deployment.

Kosten mit Autoscale und Reserved Capacity optimieren

Nutzen Sie Autoscale statt manueller Skalierung, um Idle-Zeiten zu vermeiden. Reserved Capacity bietet bis zu 63% Rabatt bei 1-3-Jahres-Commitment. Kombinieren Sie beides: Reserved für Baseline-Load, Autoscale für Peaks. Monitoren Sie Normalized RU Consumption im Portal, um Über-Provisionierung zu erkennen. Löschen Sie alte Daten mit TTL statt manueller Cleanup-Jobs.

Häufig gestellte Fragen zu Azure Cosmos DB

Welches Konsistenzlevel sollte ich wählen?

Für die meisten Anwendungen ist Session Consistency optimal: Sie garantiert, dass ein Nutzer seine eigenen Schreibvorgänge sofort liest, während andere Nutzer eventuelle Konsistenz erfahren. Strong Consistency benötigen Sie nur für Finanztransaktionen, Inventar-Systeme oder Auktionen. Eventual ist ausreichend für Analytics, Caching oder soziale Features. Bounded Staleness bietet einen Mittelweg mit garantierter maximaler Verzögerung (z.B. max 10 Sekunden alt).

Wie designe ich den richtigen Partition Key?

Der Partition Key ist die wichtigste Entscheidung und kann nachträglich nicht geändert werden. Wählen Sie eine Property mit hoher Kardinalität (viele eindeutige Werte) und gleichmäßiger Request-Verteilung. Vermeiden Sie Status-Felder (wenige Werte) oder Timestamps (Hot Partitions). Gute Beispiele: userId, tenantId, deviceId. Schlechte Beispiele: category, createdDate, status. Bei ungleichmäßiger Verteilung nutzen Sie synthetische Keys wie userId-region.

Was kostet Azure Cosmos DB wirklich?

Das Preismodell basiert auf Request Units (RU/s), Storage (GB) und Multi-Region-Replikation. Ein Punkt-Read (1 KB) kostet 1 RU, ein Write 5 RU. Provisioned Throughput rechnet pro provisionierter RU/s und Stunde ab, Serverless pro verbrauchter Million RU. Multi-Region-Replikation erhöht die Kosten je nach Anzahl der Regionen. Reserved Capacity (1-3 Jahre) spart bis zu 63%. Eine lebenslange kostenlose Stufe bietet 1.000 RU/s und 25 GB Storage. Nutzen Sie den Azure Pricing Calculator für exakte Berechnungen basierend auf Ihrem Workload.

Ist die MongoDB API vollständig kompatibel?

Es gibt zwei Modelle. Cosmos DB für MongoDB (RU) unterstützt das MongoDB Wire Protocol (bis Version 4.2) mit horizontaler Skalierung über RU/s. Azure Cosmos DB für MongoDB vCore skaliert vertikal über vCores, bietet höhere Kompatibilität für komplexe Aggregation Pipelines und Multi-Document-Transaktionen und benötigt keinen Shard Key. Der Wechsel von RU zu vCore ist kostenlos über das Azure-Portal möglich. Testen Sie Ihre spezifische Anwendung vor der Production-Migration, da Edge Cases existieren können.

Wie funktioniert der Change Feed?

Change Feed ist ein persistenter Log aller Änderungen in Ihrem Container in chronologischer Reihenfolge. Jede Create- und Update-Operation wird erfasst (Deletes nur mit All Versions Mode). Nutzen Sie Azure Functions, Logic Apps oder eigene Consumer für Event-Driven Architekturen: Echtzeit-Synchronisation, Materialized Views, Event Sourcing, Stream Analytics. Change Feed speichert Änderungen für die TTL-Dauer Ihres Containers.

Serverless oder Provisioned Throughput?

Serverless eignet sich für sporadische Workloads, Dev/Test, Prototypen und Apps mit unvorhersehbarem Traffic. Ein Serverless-Konto läuft in genau einer Azure-Region und garantiert keinen vorhersehbaren Durchsatz oder Latenz. Ein Serverless-Container startet mit 5.000 RU/s pro physischer Partition und skaliert mit zunehmender Partitionszahl. Provisioned (manuell oder Autoscale) ist für Production-Systeme und globale Verteilung gedacht: vorhersehbare Performance, SLA-Garantien und Multi-Region-Support. Der Break-Even liegt bei ca. 100 RU/s Dauerlast. Autoscale kombiniert Flexibilität mit Kostenkontrolle und passt RU/s automatisch zwischen 10% und 100% an.

Was kostet Multi-Region-Replikation?

Jede zusätzliche Region erhöht die Storage- und Throughput-Kosten entsprechend, da Daten und provisionierte RU/s in jede Region repliziert werden. Bei Multi-Region Writes (Active-Active) fallen die RU/s-Kosten pro Schreib-Region an. Für eine reine Read-Region bleibt der provisionierte Durchsatz pro Region erhalten, Sie zahlen aber zusätzlichen Storage und Replikation. Network Egress zwischen Regionen kommt hinzu. Für read-heavy Workloads reichen oft read-only Replicas. Nutzen Sie den Azure Pricing Calculator für eine exakte Kalkulation Ihrer Region-Topologie.

Wie funktioniert Backup und Point-in-Time Restore?

Cosmos DB bietet zwei Backup-Modi: Periodic (alle 4 Stunden, kostenlos, Retention 8 Stunden bis 30 Tage) und Continuous (PITR, kostenpflichtig, Restore auf beliebige Sekunde der letzten 30 Tage). Continuous Backup kostet ca. 20% der Storage-Kosten zusätzlich. Restore erfolgt in einen neuen Container, nicht in-place. Geo-Redundante Backups schützen vor Region-Ausfall. Testen Sie Restore-Prozeduren regelmäßig.

Ist Azure Cosmos DB DSGVO-konform?

Ja, wenn Sie europäische Azure-Regionen wählen (West Europe, North Europe, Germany West Central). Microsoft bietet Data Processing Addendum (DPA) und Standard Contractual Clauses (SCC). Sie kontrollieren Data Residency durch Region-Wahl. Encryption at Rest und in Transit ist Standard. Customer-Managed Keys (CMK) für zusätzliche Kontrolle. Audit Logs über Azure Monitor für Compliance-Nachweise. Achten Sie darauf, keine Multi-Region-Replikation außerhalb der EU zu aktivieren.

Wie integriert sich Cosmos DB mit anderen Azure-Services?

Native Integration über Managed Identities eliminiert Secrets-Management. Azure Functions triggern auf Change Feed. Logic Apps für No-Code-Workflows. Synapse Link und Fabric Mirroring für Analytics ohne ETL. Event Grid für Event-Driven Architekturen. Azure Monitor für Observability. Über Azure AI Foundry und das Cosmos DB MCP Toolkit binden Sie Cosmos DB direkt in KI-Agenten ein. Terraform und Bicep für Infrastructure as Code. SDKs für .NET, Java, Python, Node.js, Go und Rust.

Integration mit innFactory

Als Microsoft Azure Partner unterstützt innFactory Sie bei der Integration und Optimierung von Azure Cosmos DB. Wir helfen bei Architektur, Migration, Betrieb und Kostenoptimierung.

Kontaktieren Sie uns für eine unverbindliche Beratung zu Azure Cosmos DB und Microsoft Azure.

Verfügbare Varianten & Optionen

Serverless

Stärken
  • Bezahlung pro Anfrage
  • Kein Provisioning erforderlich
  • Ideal für sporadische Workloads
Einschränkungen
  • Höhere Kosten pro Anfrage
  • Nur eine Azure-Region pro Konto
  • Keine garantierte Latenz/Throughput

Typische Anwendungsfälle

RAG, KI-Agenten und Vektorsuche für LLM-Anwendungen
Echtzeit-Personalisierung und Empfehlungen
IoT und Zeitreihendaten
Global verteilte Web- und Mobile-Apps
Retail und E-Commerce Kataloge
Gaming-Ranglisten und Session Stores

Technische Spezifikationen

Ai search Integrierte Vektorsuche (DiskANN), Volltextsuche (BM25), Hybridsuche (RRF)
Apis NoSQL, MongoDB (RU & vCore), Cassandra, Gremlin, Table, PostgreSQL
Backup Continuous Backup und Point-in-Time Restore (PITR)
Change feed Latest- und All-Versions-and-Deletes-Modus für Event-driven Architekturen
Consistency models Strong, Bounded Staleness, Session, Consistent Prefix, Eventual
Indexing Automatische Indizierung aller Properties mit anpassbaren Indizierungs-Policies
Latency Einstellige Millisekunden (P99) bei Punkt-Reads
Modes Serverless oder Provisioned (Manuell/Autoscale)
Multi region Active-Active Multi-Region Writes mit Conflict Resolution
Partitioning Hierarchische Partition Keys (Subpartitioning) für hohe Kardinalität

Häufig gestellte Fragen

Eignet sich Azure Cosmos DB als Vektordatenbank für KI-Anwendungen?

Ja. Cosmos DB für NoSQL bietet eine integrierte Vektorsuche mit dem DiskANN-Index (allgemein verfügbar). Sie speichern Embeddings direkt neben Ihren operativen Daten und kombinieren sie über Hybridsuche (Reciprocal Rank Fusion) mit Volltextsuche. Das macht Cosmos DB zur Grundlage für RAG, KI-Agenten und LLM-Caching, ohne separate Vektordatenbank.

Welches Konsistenzlevel sollte ich wählen?

Für die meisten Anwendungen ist Session Consistency optimal: Nutzer lesen ihre eigenen Schreibvorgänge sofort, andere erfahren eventuelle Konsistenz. Strong Consistency benötigen Sie nur für Finanztransaktionen oder Inventar-Systeme. Eventual reicht für Analytics und Caching. Bounded Staleness bietet einen Mittelweg mit garantierter maximaler Verzögerung.

Wie designe ich den richtigen Partition Key?

Wählen Sie eine Property mit hoher Kardinalität und gleichmäßiger Request-Verteilung, etwa userId, tenantId oder deviceId. Vermeiden Sie Status-Felder oder Timestamps, da diese Hot Partitions erzeugen. Für mandantenfähige Workloads bieten hierarchische Partition Keys (Subpartitioning) eine Skalierung über das Limit einer einzelnen logischen Partition hinaus.

Serverless oder Provisioned Throughput?

Serverless eignet sich für sporadische, schwer planbare Workloads, Dev/Test und Prototypen und läuft in genau einer Azure-Region pro Konto. Provisioned (manuell oder Autoscale) ist für Production-Systeme mit konstantem oder planbarem Traffic und für globale Verteilung gedacht. Der Break-Even liegt bei etwa 100 RU/s Dauerlast.

Welche MongoDB-Kompatibilität bietet Cosmos DB?

Es gibt zwei Modelle: Cosmos DB für MongoDB (RU) mit horizontaler Skalierung und MongoDB-Wire-Protocol-Kompatibilität sowie Azure Cosmos DB für MongoDB vCore mit vertikaler Skalierung und höherer Kompatibilität für komplexe Aggregation Pipelines. Der Wechsel von RU zu vCore ist über das Azure-Portal möglich.

Ist Azure Cosmos DB DSGVO-konform?

Ja, wenn Sie europäische Azure-Regionen wählen (z.B. West Europe, North Europe, Germany West Central). Microsoft stellt Data Processing Addendum und Standardvertragsklauseln bereit. Sie kontrollieren die Data Residency über die Region-Wahl, Encryption at Rest und in Transit ist Standard, und Customer-Managed Keys bieten zusätzliche Kontrolle.

Microsoft Solutions Partner

innFactory ist Microsoft Solutions Partner. Wir bieten Beratung, Implementierung und Managed Services für Azure.

Microsoft Solutions Partner Microsoft Data & AI

Bereit, mit Azure Cosmos DB: global verteilte NoSQL- & KI-Datenbank zu starten?

Unsere zertifizierten Azure Experten helfen bei Architektur, Integration und Optimierung.

Beratung vereinbaren