Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Globale Tabellen: multiaktive, regionsübergreifende Replikation
<a name="GlobalTables"></a>

*Globale Tabellen in Amazon DynamoDB* sind ein vollständig verwaltetes Feature für multiregionale und multiaktive Datenbanken, das sich durch eine benutzerfreundliche Datenbankreplikation und schnelle und lokale Lese- und Schreibvorgänge in globale Anwendungen auszeichnet.

Globale Tabellen replizieren Ihre DynamoDB-Tabellendaten automatisch kontenübergreifend AWS-Regionen und optional AWS kontenübergreifend, ohne dass Sie Ihre eigene Replikationslösung erstellen und verwalten müssen. Globale Tabellen eignen sich ideal für Anwendungen, die in mehreren Regionen bereitgestellt werden und Geschäftskontinuität sowie eine hohe Verfügbarkeit erfordern. Jedes Replikat einer globalen Tabelle kann Lese- und Schreibvorgänge ausführen. Anwendungen können eine hohe Ausfallsicherheit mit niedrigen oder ganz ohne RPO (Recovery Point Objective) erreichen, weil der Datenverkehr in eine andere Region verlagert wird, sobald die Verarbeitung durch die Anwendung in einer Region unterbrochen wird. Globale Tabellen sind in allen Regionen verfügbar, in denen auch DynamoDB verfügbar ist.

## Konsistenzmodi
<a name="GlobalTables.consistency-modes"></a>

Sie können bei der Erstellung einer globalen Tabelle den Konsistenzmodus konfigurieren. Globale Tabellen unterstützen zwei Konsistenzmodi: Multi-Region Eventual Consistency (MREC) und Multi-Region Strong Consistency (MRSC).

Wenn Sie beim Erstellen einer globalen Tabelle keinen Konsistenzmodus angeben, wird für die globale Tabelle standardmäßig der MREC-Modus verwendet. Replikate, die mit unterschiedlichen Konsistenzmodi konfiguriert wurden, sind in einer globalen Tabelle nicht zulässig. Sie können den Konsistenzmodus einer globalen Tabelle nach der Erstellung nicht mehr ändern.

## Kontokonfigurationen
<a name="GlobalTables.account-configurations"></a>

DynamoDB unterstützt jetzt zwei globale Tabellenmodelle, die jeweils für unterschiedliche Architekturmuster konzipiert wurden:
+ **Globale Tabellen mit demselben Konto** — Alle Replikate werden in einem einzigen Konto erstellt und verwaltet. AWS 
+ **Globale Tabellen mit mehreren Konten** — Replikate werden für mehrere AWS Konten bereitgestellt und sind gleichzeitig Teil einer gemeinsamen Replikationsgruppe.

Sowohl Modelle mit demselben Konto als auch mit mehreren Konten unterstützen Schreibvorgänge in mehreren Regionen, asynchrone Replikation, last-writer-wins Konfliktlösung und dasselbe Abrechnungsmodell. Sie unterscheiden sich jedoch darin, wie Konten, Berechtigungen, Verschlüsselung und Tabellen-Governance verwaltet werden.

Für MRSC konfigurierte globale Tabellen unterstützen nur Konfigurationen mit demselben Konto.

Sie können eine globale Tabelle mit der Management Console konfigurieren. AWS Globale Tabellen verwenden vorhandene DynamoDB APIs zum Lesen und Schreiben von Daten in Ihre Tabellen, sodass keine Anwendungsänderungen erforderlich sind. Sie zahlen ohne Vorauszahlungen oder Verpflichtungen nur für bereitgestellte oder verwendete Ressourcen.


| **Eigenschaften** | **Globale Tabellen für dasselbe Konto** | **Globale Tabellen mit mehreren Konten** | 
| --- | --- | --- | 
| Primärer Anwendungsfall | Resilienz in mehreren Regionen für Anwendungen innerhalb eines einzigen Kontos AWS  | Replikation für mehrere Regionen und Konten für Anwendungen, die unterschiedlichen Teams, unterschiedlichen Geschäftseinheiten oder starken Sicherheitsgrenzen zwischen Konten gehören | 
| Kontomodell | Alle Repliken wurden in einem AWS Konto erstellt und verwaltet | Replikate, die für mehrere AWS Konten innerhalb derselben Bereitstellung erstellt wurden | 
| Besitz von Ressourcen | Ein einzelnes Konto besitzt die Tabelle und alle Replikate | Jedes Konto besitzt sein lokales Replikat; die Replikationsgruppe umfasst mehrere Konten | 
| Unterstützte Version | Version 2019.11.21 (aktuell) und Version 2017.11.29 (Legacy) | Version der globalen Tabellen 2019.11.21 (Aktuell) | 
| Betrieb der Kontrollebene | Erstellen, ändern und löschen Sie Replikate über das Konto des Tabellenbesitzers | Operationen auf verteilter Steuerungsebene: Konten treten der Replikationsgruppe bei oder verlassen sie | 
| Operationen auf Datenebene | DynamoDB-Standardendpunkte pro Region | Zugriff auf Datenebene pro Konto/Region; Routing über Replikationsgruppe | 
| Sicherheitsgrenze | Eine einzige IAM- und KMS-Grenze | Separate IAM-, KMS-, Fakturierungs- und CloudTrail Verwaltungsfunktionen für jedes Konto | 
| Beste Passform | Organizations mit zentralisiertem Besitz von Tabellen | Organizations mit Verbundteams, Verwaltungsgrenzen oder Konfigurationen mit mehreren Konten | 

**Topics**
+ [Konsistenzmodi](#GlobalTables.consistency-modes)
+ [Kontokonfigurationen](#GlobalTables.account-configurations)
+ [Kernkonzepte globaler Tabellen](globaltables-CoreConcepts.md)
+ [DynamoDB-Tabelle für dasselbe Konto](globaltables-SameAccount.md)
+ [DynamoDB-Tabellen für mehrere Konten](globaltables-MultiAccount.md)
+ [Grundlegendes zur Amazon DynamoDB-Fakturierung für globale Tabellen](global-tables-billing.md)
+ [Versionen von globalen DynamoDB-Tabellen](V2globaltables_versions.md)
+ [Bewährte Methoden für globale Tabellen](globaltables-bestpractices.md)

# Kernkonzepte globaler Tabellen
<a name="globaltables-CoreConcepts"></a>

In den folgenden Abschnitten werden die Konzepte und das Verhalten globaler Tabellen in Amazon DynamoDB beschrieben.

## Konzepte
<a name="globaltables-CoreConcepts.KeyConcepts"></a>

*Globale Tabellen* sind eine DynamoDB-Funktion, die Tabellendaten regionsübergreifend repliziert. AWS 

Eine *Replikattabelle* (oder kurz ein Replikat) ist eine einzelne DynamoDB-Tabelle, die als Teil einer globalen Tabelle fungiert. Eine globale Tabelle besteht aus zwei oder mehr Replikattabellen in verschiedenen Regionen. AWS Jede globale Tabelle kann nur über eine Replikattabelle je AWS -Region verfügen. Alle Replikate in einer globalen Tabelle verwenden denselben Tabellennamen, dasselbe Primärschlüsselschema und dieselben Elementdaten.

Wenn eine Anwendung Daten in eine Replikattabelle in einer Region schreibt, verteilt DynamoDB den Schreibvorgang automatisch auf die anderen Replikattabellen in der globalen Tabelle. Weitere Informationen zu den ersten Schritten mit globalen Tabellen finden Sie unter [Tutorials: Erstellen von globalen Tabellen](V2globaltables.tutorial.md) oder[Tutorials: Globale Tabellen mit mehreren Konten erstellen](V2globaltables_MA.tutorial.md).

## Versionen
<a name="globaltables-CoreConcepts.Versions"></a>

Es gibt zwei Versionen von globalen DynamoDB-Tabellen: [Version 2019.11.21 (Aktuell)](GlobalTables.md) und [Version 2017.11.29 (Legacy) der globalen Tabellen](globaltables.V1.md). Sie sollten nach Möglichkeit Global Tables Version 2019.11.21 (Aktuell) verwenden. Die Informationen in diesem Abschnitt der Dokumentation gelten für die Version 2019.11.21 (Aktuell). Weitere Informationen finden Sie unter Ermitteln der Version einer globalen Tabelle. [Ermitteln der Version einer globalen Tabelle](V2globaltables_versions.md#globaltables.DetermineVersion)

## Verfügbarkeit
<a name="globaltables-CoreConcepts.availability"></a>

Globale Tabellen tragen zur Verbesserung der Geschäftskontinuität bei, da sie die Implementierung einer hoch verfügbaren Architektur für mehrere Regionen erleichtern. Wenn eine Arbeitslast in einer einzelnen AWS Region beeinträchtigt wird, können Sie den Anwendungsdatenverkehr in eine andere Region verlagern und Lese- und Schreibvorgänge in einer anderen Replikattabelle in derselben globalen Tabelle durchführen.

Jede Replikattabelle in einer globalen Tabelle bietet dieselbe Stabilität und Verfügbarkeit wie eine DynamoDB-Tabelle mit einer Region. Globale Tabellen bieten ein [Service Level Agreement (SLA)](https://aws.amazon.com//dynamodb/sla/) mit einer Verfügbarkeit von 99,999 %, im Gegensatz zur Verfügbarkeit von 99,99 % bei Tabellen mit einer einzelnen Region.

## Testen mit Fehlerinjektionen
<a name="fault-injection-testing"></a>

Sowohl die globalen MREC- als auch die MRSC-Tabellen sind in den [AWSAWS Fault Injection Service](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) (FIS) integriert, einen vollständig verwalteten Dienst zur Durchführung kontrollierter Fehlerinjektionsexperimente zur Verbesserung der Ausfallsicherheit einer Anwendung. Mit AWS FIS können Sie:
+ Erstellen Sie Versuchsvorlagen, die spezifische Fehlerszenarien definieren.
+ Injizieren Sie Fehler, um die Ausfallsicherheit von Anwendungen zu überprüfen, indem Sie die Regionsisolierung simulieren (d. h. die Replikation zu und von einem ausgewählten Replikat unterbrechen), um die Fehlerbehandlung, Wiederherstellungsmechanismen und das Verhalten bei Störungen in einer Region zu testen. AWS 

In einer globalen Tabelle mit Replikaten in USA Ost (Nord-Virginia), USA Ost (Ohio) und USA West (Oregon) können Sie beispielsweise ein Experiment in USA Ost (Ohio) durchführen, um die dortige Regionsisolierung zu testen, während USA Ost (Nord-Virginia) und USA West (Oregon) ihren normalen Betrieb fortsetzen. Diese kontrollierten Tests helfen Ihnen dabei, potenzielle Probleme zu identifizieren und zu lösen, bevor sie sich auf den Produktions-Workload auswirken. 

Eine vollständige Liste der von *AWS FIS unterstützten Aktionen und [regionsübergreifender Konnektivität zum Anhalten der DynamoDB-Replikation zwischen Regionen](https://docs.aws.amazon.com/fis/latest/userguide/cross-region-scenario.html) finden Sie unter [Aktionsziele](https://docs.aws.amazon.com/fis/latest/userguide/action-sequence.html#action-targets) im AWS FIS-Benutzerhandbuch*.

*Informationen zu globalen Tabellenaktionen von Amazon DynamoDB, die in AWS FIS verfügbar sind, finden Sie unter [DynamoDB Global Tables Actions Reference](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dynamodb-actions-reference) im FIS-Benutzerhandbuch.AWS *

Informationen zu den ersten Schritten mit der Durchführung von Fault-Injection-Experimenten finden Sie unter [Planung Ihrer AWS FIS-Experimente im FIS-Benutzerhandbuch](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.html). AWS 

**Anmerkung**  
Bei AWS FIS Experimenten in MRSC sind eventuell konsistente Lesevorgänge zulässig, Aktualisierungen der Tabelleneinstellungen — wie z. B. das Ändern des Abrechnungsmodus oder die Konfiguration des Tabellendurchsatzes — sind jedoch nicht zulässig, ähnlich wie bei MREC. Weitere Informationen [`FaultInjectionServiceInducedErrors`](metrics-dimensions.md#FaultInjectionServiceInducedErrors)zum Fehlercode finden Sie in der CloudWatch Metrik.

## Time to Live (TTL)
<a name="global-tables-ttl"></a>

In globalen Tabellen mit MREC-Konfiguration kann die Konfiguration von [Time To Live](TTL.md) (TTL) gelöscht werden. Die TTL-Einstellungen werden automatisch für alle Replikate einer globalen Tabelle synchronisiert. Wenn TTL ein Element aus einem Replikat in einer Region löscht, wird der Löschvorgang auf alle anderen Replikate in der globalen Tabelle repliziert. TTL verbraucht keine Schreibkapazität; das Löschen von TTL wird Ihnen in der Region, in der der Löschvorgang stattgefunden hat, nicht in Rechnung gestellt. In allen anderen Regionen, deren globale Tabelle ein Replikat enthält, wird Ihnen jedoch der replizierte Löschvorgang in Rechnung gestellt.

Die Replikation eines TTL-Löschvorgangs verbraucht Schreibkapazität in den Replikaten, in die der Löschvorgang repliziert wird. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Schreibdurchsatz und TTL-Löschdurchsatz die bereitgestellte Schreibkapazität überschreitet.

Globale Tabellen mit MRSC-Konfiguration unterstützen die Konfiguration des TTL-Löschvorgangs nicht.

## Streams
<a name="global-tables-streams"></a>

Globale Tabellen mit MREC-Konfiguration replizieren Änderungen, indem sie diese aus einem [DynamoDB-Stream](Streams.md) in einer Replikattabelle auslesen und auf alle anderen Replikattabellen anwenden. Streams sind daher standardmäßig für alle Replikate in einer globalen MREC-Tabelle aktiviert und können in diesen Replikaten nicht deaktiviert werden. Der MREC-Replikationsprozess kann mehrere Änderungen in einem kurzen Zeitraum zu einem einzigen replizierten Schreibvorgang kombinieren, was dazu führt, dass der Stream jedes Replikats Datensätze enthält, die sich geringfügig unterscheiden. Streams-Datensätze auf MREC-Replikaten behalten die Reihenfolge für alle Änderungen am selben Objekt bei, aber die relative Reihenfolge der Änderungen an verschiedenen Elementen kann je nach Replikat variieren.

Wenn Sie eine Anwendung schreiben möchten, die Streams-Datensätze für Änderungen verarbeitet, die in einer bestimmten Region, aber nicht in anderen Regionen in einer globalen Tabelle vorgenommen wurden, können Sie jedem Element ein Attribut hinzufügen, das definiert, in welcher Region die Änderung für dieses Element stattgefunden hat. Sie können dieses Attribut verwenden, um Streams-Datensätze nach Änderungen zu filtern, die in anderen Regionen aufgetreten sind und hierzu auch Lambda-Ereignisfilter verwenden, um Lambda-Funktionen nur für Änderungen in einer bestimmten Region aufzurufen.

Globale Tabellen mit MRSC-Konfiguration verwenden keine DynamoDB Streams für die Replikation, sodass Streams in MRSC-Replikaten standardmäßig nicht aktiviert sind. Streams können in einem MRSC-Replikat aktiviert werden. Streams-Datensätze in MRSC-Replikaten sind für jedes Replikat identisch, auch in Bezug auf ihre Reihenfolge.

## Transaktionen
<a name="global-tables-transactions"></a>

In einer globalen Tabelle mit MREC-Konfiguration sind DynamoDB-Transaktionsoperationen ([https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html) und [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html)) nur innerhalb der Region, in der der Vorgang aufgerufen wurde, unteilbar. Schreibtransaktionen werden nicht als Einheit regionsübergreifend repliziert, was bedeutet, dass nur einige Schreibvorgänge in einer Transaktion zu einem bestimmten Zeitpunkt durch Lesevorgänge in anderen Replikaten zurückgegeben werden können.

Wenn Sie beispielsweise eine globale Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) nutzen und eine `TransactWriteItems`-Operation in der Region USA Ost (Ohio) durchführen, sind unter Umständen partiell durchgeführte Transaktionen in der Region USA West (Oregon) zu beobachten, während die Änderungen repliziert werden. Die Änderungen werden erst in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden.

Globale Tabellen mit MRSC-Konfiguration unterstützen keine Transaktionsvorgänge und geben einen Fehler zurück, wenn solche Operationen in einem MRSC-Replikat aufgerufen werden.

## Lese- und Schreibdurchsatz
<a name="globaltables-CoreConcepts.Throughput"></a>

### Modus bereitgestellter Kapazität
<a name="gt_throughput.provisioned"></a>

Eine Replikation verbraucht Schreibkapazität. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Anwendungsschreibdurchsatz und Replikationsschreibdurchsatz die bereitgestellte Schreibkapazität überschreitet. Bei globalen Tabellen, die den Bereitstellungsmodus verwenden, werden die Auto Scaling-Einstellungen für Lese- und Schreibkapazitäten zwischen den Replikaten synchronisiert.

Sie können die Lesekapazitätseinstellungen für jedes Replikat in einer globalen Tabelle unabhängig konfigurieren, indem Sie den [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html)Parameter auf Replikatebene verwenden. Standardmäßig werden Änderungen an der bereitgestellten Lesekapazität auf alle Replikate in der globalen Tabelle angewendet. Beim Hinzufügen eines neuen Replikats zu einer globalen Tabelle wird die Lesekapazität der Quelltabelle oder des Replikats als Anfangswert verwendet, sofern nicht ausdrücklich eine Überschreibung auf Replikatebene angegeben ist.

### On-Demand-Modus
<a name="gt_throughput.on-demand"></a>

Bei globalen Tabellen, die für den On-Demand-Modus konfiguriert sind, wird die Schreibkapazität automatisch über alle Replikate hinweg synchronisiert. DynamoDB passt die Kapazität automatisch an den Datenverkehr an, und es müssen keine replikatspezifischen Lese- oder Schreibkapazitätseinstellungen verwaltet werden.

## Überwachen globaler Tabellen
<a name="monitoring-global-tables"></a>

In globalen Tabellen, die für Multi-Region Eventual Consistency (MREC) konfiguriert sind, wird die Metrik veröffentlicht. [`ReplicationLatency`](metrics-dimensions.md#ReplicationLatency) CloudWatch Diese Metrik misst die verstrichene Zeit zwischen dem Schreiben eines Elements in eine Replikattabelle und dem Erscheinen dieses Elements in einem anderen Replikat in der globalen Tabelle. `ReplicationLatency` wird in Millisekunden ausgedrückt und für jedes Paar aus Quell- und Zielregion ausgegeben. 

Typische `ReplicationLatency` Werte hängen von der Entfernung zwischen den ausgewählten AWS Regionen sowie von anderen Variablen wie Workload-Typ und Durchsatz ab. Beispiel: Ein Quellreplikat in der Region USA West (Nordkalifornien) (us-west-1) weist im Vergleich zur Region Afrika (Kapstadt) (af-south-1) einen niedrigeren Wert für `ReplicationLatency` auf als die Region USA West (Oregon) (us-west-2).

Ein erhöhter Wert für `ReplicationLatency` könnte darauf hinweisen, dass Updates von einem Replikat nicht in einem angemessenen Zeitraum an andere Replikattabellen verteilt werden. In diesem Fall können Sie die Lese- und Schreibaktivität Ihrer Anwendung vorübergehend in eine andere AWS Region umleiten.

Globale Tabellen mit MRSC-Konfiguration veröffentlichen keine `ReplicationLatency`-Metrik.

## Überlegungen zur Verwaltung globaler Tabellen
<a name="management-considerations"></a>

Sie können eine Tabelle, die zum Hinzufügen des neuen Replikats einer globalen Tabelle verwendet wurde, erst 24 Stunden nach der Erstellung des neuen Replikats löschen.

Wenn Sie eine AWS Region deaktivieren, die globale Tabellenreplikate enthält, werden diese Replikate 20 Stunden nach der Deaktivierung der Region dauerhaft in Tabellen mit nur einer Region konvertiert.

# DynamoDB-Tabelle für dasselbe Konto
<a name="globaltables-SameAccount"></a>

Globale Tabellen mit demselben Konto replizieren Ihre DynamoDB-Tabellendaten automatisch regionsübergreifend innerhalb AWS eines einzigen Kontos. AWS Globale Tabellen mit demselben Konto bieten das einfachste Modell für die Ausführung von Anwendungen mit mehreren Regionen, da alle Replikate dasselbe Kontogrenzen-, Eigentums- und Berechtigungsmodell verwenden. Wenn Sie die AWS Regionen für Ihre Replikattabellen auswählen, übernehmen globale Tabellen die gesamte Replikation automatisch. Globale Tabellen sind in allen Regionen verfügbar, in denen auch DynamoDB verfügbar ist.

Globale Tabellen mit demselben Konto bieten die folgenden Vorteile:
+ Automatisches Replizieren von DynamoDB-Tabellendaten in allen AWS Regionen Ihrer Wahl, um Daten näher an Ihren Benutzern zu finden
+ Höhere Anwendungsverfügbarkeit bei regionaler Isolierung oder Auslagerung von Daten
+ Verwenden Sie die integrierte Konfliktlösung, damit Sie sich auf die Geschäftslogik Ihrer Anwendung konzentrieren können
+ Wenn Sie eine globale Tabelle für dasselbe Konto erstellen, können Sie entweder oder wählen [Multi-Region Eventual Consistency (MREC)](V2globaltables_HowItWorks.md#V2globaltables_HowItWorks.consistency-modes.mrec) [Multi-Region Strong Consistency (MRSC)](V2globaltables_HowItWorks.md#V2globaltables_HowItWorks.consistency-modes.mrsc)

**Topics**
+ [So funktionieren globale DynamoDB-Tabellen](V2globaltables_HowItWorks.md)
+ [Tutorials: Erstellen von globalen Tabellen](V2globaltables.tutorial.md)
+ [Sicherheit von globalen DynamoDB-Tabellen](globaltables-security.md)

# So funktionieren globale DynamoDB-Tabellen
<a name="V2globaltables_HowItWorks"></a>

In den folgenden Abschnitten werden die Konzepte und das Verhalten globaler Tabellen in Amazon DynamoDB beschrieben.

## Konzepte
<a name="V2globaltables_HowItWorks.KeyConcepts"></a>

*Globale Tabellen* sind eine DynamoDB-Funktion, die Tabellendaten regionsübergreifend repliziert. AWS 

Eine *Replikattabelle* (oder kurz ein Replikat) ist eine einzelne DynamoDB-Tabelle, die als Teil einer globalen Tabelle fungiert. Eine globale Tabelle besteht aus zwei oder mehr Replikattabellen in verschiedenen Regionen. AWS Jede globale Tabelle kann nur über eine Replikattabelle je AWS -Region verfügen. Alle Replikate in einer globalen Tabelle verwenden denselben Tabellennamen, dasselbe Primärschlüsselschema und dieselben Elementdaten.

Wenn eine Anwendung Daten in eine Replikattabelle in einer Region schreibt, verteilt DynamoDB den Schreibvorgang automatisch auf die anderen Replikattabellen in der globalen Tabelle. Weitere Informationen über die ersten Schritte mit globalen Tabellen finden Sie unter [Tutorials: Erstellen von globalen Tabellen](V2globaltables.tutorial.md).

## Versionen
<a name="V2globaltables_HowItWorks.versions"></a>

Es gibt zwei Versionen von globalen DynamoDB-Tabellen: Version 2019.11.21 (Aktuell) und [Version 2017.11.29 (Legacy)](globaltables.V1.md). Sie sollten nach Möglichkeit die Version 2019.11.21 (Aktuell) verwenden. Die Informationen in diesem Abschnitt der Dokumentation gelten für die Version 2019.11.21 (Aktuell). Weitere Informationen finden Sie unter [Ermitteln der Version einer globalen Tabelle](V2globaltables_versions.md#globaltables.DetermineVersion).

## Verfügbarkeit
<a name="V2globaltables_HowItWorks.availability"></a>

Globale Tabellen tragen zur Verbesserung der Geschäftskontinuität bei, da sie die Implementierung einer hoch verfügbaren Architektur für mehrere Regionen erleichtern. Wenn eine Arbeitslast in einer einzelnen AWS Region beeinträchtigt wird, können Sie den Anwendungsdatenverkehr in eine andere Region verlagern und Lese- und Schreibvorgänge in einer anderen Replikattabelle in derselben globalen Tabelle durchführen.

Jede Replikattabelle in einer globalen Tabelle bietet dieselbe Stabilität und Verfügbarkeit wie eine DynamoDB-Tabelle mit einer Region. Globale Tabellen bieten ein [Service Level Agreement (SLA)](https://aws.amazon.com//dynamodb/sla/) mit einer Verfügbarkeit von 99,999 %, im Gegensatz zur Verfügbarkeit von 99,99 % bei Tabellen mit einer einzelnen Region.

## Konsistenzmodi
<a name="V2globaltables_HowItWorks.consistency-modes"></a>

Sie können bei der Erstellung einer globalen Tabelle den Konsistenzmodus konfigurieren. Globale Tabellen unterstützen zwei Konsistenzmodi: Multi-Region Eventual Consistency (MREC) und Multi-Region Strong Consistency (MRSC).

Wenn Sie beim Erstellen einer globalen Tabelle keinen Konsistenzmodus angeben, wird für die globale Tabelle standardmäßig der MREC-Modus verwendet. Replikate, die mit unterschiedlichen Konsistenzmodi konfiguriert wurden, sind in einer globalen Tabelle nicht zulässig. Sie können den Konsistenzmodus einer globalen Tabelle nach der Erstellung nicht mehr ändern.

### Multi-Region Eventual Consistency (MREC)
<a name="V2globaltables_HowItWorks.consistency-modes.mrec"></a>

Der Standardmodus für globale Tabellen ist der MREC-Modus (Multi-Region Eventual Consistency). Elementänderungen im Replikat einer globalen MREC-Tabelle werden asynchron für alle anderen Replikate repliziert, normalerweise innerhalb von maximal einer Sekunde. In dem unwahrscheinlichen Fall, dass ein Replikat in einer globalen MREC-Tabelle isoliert ist oder beeinträchtigt wird, werden alle Daten, die noch nicht in andere Regionen repliziert wurden, repliziert, sobald das Replikat fehlerfrei ist.

Wenn dasselbe Element in mehreren Regionen gleichzeitig geändert wird, löst DynamoDB den Konflikt, indem die Änderung mit dem neuesten internen Zeitstempel pro Element verwendet wird; diese Konfliktlösungsmethode wird als „Last Writer Wins“ bezeichnet. Letztendlich stimmt ein Element in allen Replikaten mit der Version überein, die beim letzten Schreibvorgang erstellt wurde.

[Strikt konsistente Lesevorgänge](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html#DDB-GetItem-request-ConsistentRead) geben die jeweils aktuelle Version eines Elements zurück, wenn dieses zuletzt in der Region aktualisiert wurde, in der der Lesevorgang stattgefunden hat. Hierbei können jedoch veraltete Daten zurückgegeben werden, wenn das Element zuletzt in einer anderen Region aktualisiert wurde. Bei bedingten Schreibvorgängen wird der Bedingungsausdruck mit der Version des Elements in der Region verglichen.

Sie erstellen eine globale MREC-Tabelle, indem Sie einer vorhandenen DynamoDB-Tabelle ein Replikat hinzufügen. Das Hinzufügen eines Replikats hat keine Auswirkungen auf die Leistung vorhandener DynamoDB-Tabellen mit einer einzigen Region oder von Replikaten globaler Tabellen. Sie können einer globalen MREC-Tabelle Replikate hinzufügen, um die Anzahl der Regionen zu erhöhen, in denen Daten repliziert werden, oder Replikate aus einer globalen MREC-Tabelle entfernen, wenn sie nicht mehr benötigt werden. Eine globale MREC-Tabelle kann ein Replikat in jeder Region haben, in der DynamoDB verfügbar ist, und sie kann so viele Replikate enthalten, wie es Regionen in der [AWS -Partition](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/partitions.html) gibt.

### Multi-Region Strong Consistency (MRSC)
<a name="V2globaltables_HowItWorks.consistency-modes.mrsc"></a>

Sie können bei der Erstellung einer globalen Tabelle den MRSC-Modus (Multi-Region Strong Consistency) konfigurieren. Elementänderungen im Replikat einer globalen MRSC-Tabelle werden synchron in mindestens eine andere Region repliziert, bevor der Schreibvorgang eine erfolgreiche Antwort zurückgibt. Strikt konsistente Lesevorgänge für ein beliebiges MRSC-Replikat geben immer die neueste Version eines Elements zurück. Bei bedingten Schreibvorgängen wird immer der Bedingungsausdruck mit der aktuellen Version des Elements verglichen.

Eine globale MRSC-Tabelle muss in genau drei Regionen bereitgestellt werden. Sie können eine globale MRSC-Tabelle mit drei Replikaten oder zwei Replikaten und einem Witness konfigurieren. Ein Zeuge ist eine Komponente einer globalen MRSC-Tabelle, die in globale Tabellenreplikate geschriebene Daten enthält und eine optionale Alternative zu einem vollständigen Replikat darstellt und gleichzeitig die Verfügbarkeitsarchitektur von MRSC unterstützt. Sie können für einen Witness keine Lese- oder Schreibvorgänge ausführen. Ein Witness befindet sich in einer anderen Region als die beiden Replikate. Wenn Sie eine globale MRSC-Tabelle erstellen, wählen Sie bei ihrer Erstellung die Regionen sowohl für die Bereitstellung der Replikate als auch für den Witness aus. Sie können anhand der Ausgabe der [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTable.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTable.html)-API bestimmen, ob und in welcher Region für eine globale MRSC-Tabelle ein Witness konfiguriert ist. Der Zeuge gehört DynamoDB und wird von DynamoDB verwaltet, und der Zeuge wird nicht in Ihrem AWS Konto in der Region angezeigt, in der er konfiguriert ist.

Die globalen MRSC-Tabellen sind in den folgenden Regionsgruppen verfügbar: US-Regionengruppe (USA Ost Nord-Virginia, USA Ost-Ohio, USA West Oregon), EU-Regionengruppe (Europa Irland, Europa London, Europa Paris, Europa Frankfurt) und AP-Regionengruppe (Asien-Pazifik Tokio, Asien-Pazifik Seoul und Asien-Pazifik Osaka). Globale MRSC-Tabellen dürfen sich nicht über verschiedene Region-Sets erstrecken (z. B. darf eine globale MRSC-Tabelle nicht gleichzeitig Replikate aus US- und EU-Regionen enthalten).

Sie erstellen eine globale MRSC-Tabelle, indem Sie einer vorhandenen DynamoDB-Tabelle, die keine Daten enthält, ein Replikat und einen Witness oder zwei Replikate hinzufügen. Wenn Sie eine bestehende Tabelle mit einer einzigen Region in eine globale MRSC-Tabelle konvertieren, müssen Sie sicherstellen, dass die Tabelle leer ist. Die Konvertierung einer Tabelle mit nur einer Region in eine globale MRSC-Tabelle mit vorhandenen Elementen wird nicht unterstützt. Stellen Sie sicher, dass während des Konvertierungsvorgangs keine Daten in die Tabelle geschrieben werden. Sie können einer vorhandenen globalen MRSC-Tabelle keine zusätzlichen Replikate hinzufügen. Ein einzelnes Replikat oder ein Witness kann nicht aus einer globalen MRSC-Tabelle gelöscht werden. Sie können zwei Replikate oder ein Replikat und einen Witness aus einer globalen MRSC-Tabelle löschen und das verbleibende Replikat in eine DynamoDB-Tabelle mit einer einzigen Region umwandeln.

Bei einem Schreibvorgang tritt der Fehler `ReplicatedWriteConflictException` auf, wenn versucht wird, ein Element zu ändern, das bereits in einer anderen Region geändert wird. Schreibvorgänge, die mit dem fehlschlagen, `ReplicatedWriteConflictException` können wiederholt werden und sind erfolgreich, wenn das Element in einer anderen Region nicht mehr geändert wird.

Für globale MRSC-Tabellen gelten die folgenden Überlegungen:
+ Die Funktion „Time to Live“ (TTL) wird von globalen MRSC-Tabellen nicht unterstützt.
+ Lokale sekundäre Indizes (LSIs) werden für globale MRSC-Tabellen nicht unterstützt.
+ CloudWatch Contributor Insights-Informationen werden nur für die Region gemeldet, in der ein Vorgang stattgefunden hat.

## Auswählen eines Konsistenzmodus
<a name="V2globaltables_HowItWorks.choosing-consistency-mode"></a>

Das Hauptkriterium für die Auswahl eines Konsistenzmodus für mehrere Regionen ist, ob die Anwendung Schreibvorgängen mit geringer Latenz und strikt konsistente Lesevorgänge oder der globalen strikten Konsistenz Priorität einräumt.

Globale MREC-Tabellen weisen im Vergleich zu globalen MRSC-Tabellen Schreib- und strikt konsistente Lesevorgänge mit geringen Latenzen auf. Globale MREC-Tabellen haben ein Recovery Point Objective (RPO), das der Replikationsverzögerung zwischen Replikaten entspricht, die je nach Replikatregion in der Regel einige Sekunden beträgt.

In folgenden Fällen sollten Sie den MREC-Modus verwenden:
+ Ihre Anwendung kann veraltete Daten tolerieren, die von strikt konsistenten Lesevorgängen zurückgegeben werden, wenn diese Daten in einer anderen Region aktualisiert wurden.
+ Schreib- und strikt konsistente Lesevorgänge mit geringer Latenz haben Vorrang vor der Konsistenz von multiregionalen Lesevorgängen.
+ Gemäß Ihrer Strategie für Hochverfügbarkeit für mehrere Regionen ist ein RPO über null zulässig.

Globale MRSC-Tabellen weisen im Vergleich zu globalen MREC-Tabellen Schreib- und strikt konsistente Lesevorgänge mit höheren Latenzen auf. Globale MRSC-Tabellen unterstützen einen Recovery Point Objective (RPO) von null.

In folgenden Fällen sollten Sie den MRSC-Modus verwenden:
+ Sie benötigen strikt konsistente Lesevorgänge über mehrere Regionen hinweg.
+ Die globale Konsistenz von Lesevorgängen hat Vorrang gegenüber Schreibvorgängen mit geringer Latenz.
+ Gemäß Ihrer Strategie für Hochverfügbarkeit für mehrere Regionen ist ein RPO von null erforderlich.

## Überwachen globaler Tabellen
<a name="monitoring-global-tables"></a>

In globalen Tabellen, die für Multi-Region Eventual Consistency (MREC) konfiguriert sind, wird die Metrik veröffentlicht. [`ReplicationLatency`](metrics-dimensions.md#ReplicationLatency) CloudWatch Diese Metrik misst die verstrichene Zeit zwischen dem Schreiben eines Elements in eine Replikattabelle und dem Erscheinen dieses Elements in einem anderen Replikat in der globalen Tabelle. `ReplicationLatency` wird in Millisekunden ausgedrückt und für jedes Paar aus Quell- und Zielregion ausgegeben. 

Typische `ReplicationLatency` Werte hängen von der Entfernung zwischen den ausgewählten AWS Regionen sowie von anderen Variablen wie Workload-Typ und Durchsatz ab. Beispiel: Ein Quellreplikat in der Region USA West (Nordkalifornien) (us-west-1) weist im Vergleich zur Region Afrika (Kapstadt) (af-south-1) einen niedrigeren Wert für `ReplicationLatency` auf als die Region USA West (Oregon) (us-west-2).

Ein erhöhter Wert für `ReplicationLatency` könnte darauf hinweisen, dass Updates von einem Replikat nicht in einem angemessenen Zeitraum an andere Replikattabellen verteilt werden. In diesem Fall können Sie die Lese- und Schreibaktivität Ihrer Anwendung vorübergehend in eine andere AWS Region umleiten.

Globale Tabellen mit MRSC-Konfiguration veröffentlichen keine `ReplicationLatency`-Metrik.

## Testen mit Fehlerinjektionen
<a name="fault-injection-testing"></a>

Sowohl die globalen MREC- als auch die MRSC-Tabellen sind in den [AWSAWS Fault Injection Service](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) (FIS) integriert, einen vollständig verwalteten Dienst zur Durchführung kontrollierter Fehlerinjektionsexperimente zur Verbesserung der Ausfallsicherheit einer Anwendung. Mit AWS FIS können Sie:
+ Erstellen Sie Versuchsvorlagen, die spezifische Fehlerszenarien definieren.
+ Injizieren Sie Fehler, um die Ausfallsicherheit von Anwendungen zu überprüfen, indem Sie die Regionsisolierung simulieren (d. h. die Replikation zu und von einem ausgewählten Replikat unterbrechen), um die Fehlerbehandlung, Wiederherstellungsmechanismen und das Verhalten bei Störungen in einer Region zu testen. AWS 

In einer globalen Tabelle mit Replikaten in USA Ost (Nord-Virginia), USA Ost (Ohio) und USA West (Oregon) können Sie beispielsweise ein Experiment in USA Ost (Ohio) durchführen, um die dortige Regionsisolierung zu testen, während USA Ost (Nord-Virginia) und USA West (Oregon) ihren normalen Betrieb fortsetzen. Diese kontrollierten Tests helfen Ihnen dabei, potenzielle Probleme zu identifizieren und zu lösen, bevor sie sich auf den Produktions-Workload auswirken. 

Eine vollständige Liste der von *AWS FIS unterstützten Aktionen und [regionsübergreifender Konnektivität zum Anhalten der DynamoDB-Replikation zwischen Regionen](https://docs.aws.amazon.com/fis/latest/userguide/cross-region-scenario.html) finden Sie unter [Aktionsziele](https://docs.aws.amazon.com/fis/latest/userguide/action-sequence.html#action-targets) im AWS FIS-Benutzerhandbuch*.

*Informationen zu globalen Tabellenaktionen von Amazon DynamoDB, die in AWS FIS verfügbar sind, finden Sie unter [DynamoDB Global Tables Actions Reference](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dynamodb-actions-reference) im FIS-Benutzerhandbuch.AWS *

Informationen zu den ersten Schritten mit der Durchführung von Fault-Injection-Experimenten finden Sie unter [Planung Ihrer AWS FIS-Experimente im FIS-Benutzerhandbuch](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.html). AWS 

**Anmerkung**  
Bei AWS FIS Experimenten in MRSC sind eventuell konsistente Lesevorgänge zulässig, Aktualisierungen der Tabelleneinstellungen — wie z. B. das Ändern des Abrechnungsmodus oder die Konfiguration des Tabellendurchsatzes — sind jedoch nicht zulässig, ähnlich wie bei MREC. Weitere Informationen [`FaultInjectionServiceInducedErrors`](metrics-dimensions.md#FaultInjectionServiceInducedErrors)zum Fehlercode finden Sie in der CloudWatch Metrik.

## Time to Live (TTL)
<a name="global-tables-ttl"></a>

In globalen Tabellen mit MREC-Konfiguration kann die Konfiguration von [Time To Live](TTL.md) (TTL) gelöscht werden. Die TTL-Einstellungen werden automatisch für alle Replikate einer globalen Tabelle synchronisiert. Wenn TTL ein Element aus einem Replikat in einer Region löscht, wird der Löschvorgang auf alle anderen Replikate in der globalen Tabelle repliziert. TTL verbraucht keine Schreibkapazität; das Löschen von TTL wird Ihnen in der Region, in der der Löschvorgang stattgefunden hat, nicht in Rechnung gestellt. In allen anderen Regionen, deren globale Tabelle ein Replikat enthält, wird Ihnen jedoch der replizierte Löschvorgang in Rechnung gestellt.

Die Replikation eines TTL-Löschvorgangs verbraucht Schreibkapazität in den Replikaten, in die der Löschvorgang repliziert wird. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Schreibdurchsatz und TTL-Löschdurchsatz die bereitgestellte Schreibkapazität überschreitet.

Globale Tabellen mit MRSC-Konfiguration unterstützen die Konfiguration des TTL-Löschvorgangs nicht.

## Streams
<a name="global-tables-streams"></a>

Globale Tabellen mit MREC-Konfiguration replizieren Änderungen, indem sie diese aus einem [DynamoDB-Stream](Streams.md) in einer Replikattabelle auslesen und auf alle anderen Replikattabellen anwenden. Streams sind daher standardmäßig für alle Replikate in einer globalen MREC-Tabelle aktiviert und können in diesen Replikaten nicht deaktiviert werden. Der MREC-Replikationsprozess kann mehrere Änderungen in einem kurzen Zeitraum zu einem einzigen replizierten Schreibvorgang kombinieren, was dazu führt, dass der Stream jedes Replikats Datensätze enthält, die sich geringfügig unterscheiden. Streams-Datensätze in MREC-Replikaten werden immer elementweise sortiert, wobei die Reihenfolge zwischen den Elementen sich von Replikat zu Replikat unterscheiden kann.

Globale Tabellen mit MRSC-Konfiguration verwenden keine DynamoDB Streams für die Replikation, sodass Streams in MRSC-Replikaten standardmäßig nicht aktiviert sind. Streams können in einem MRSC-Replikat aktiviert werden. Streams-Datensätze in MRSC-Replikaten sind für jedes Replikat identisch, auch in Bezug auf ihre Reihenfolge.

Wenn Sie eine Anwendung schreiben möchten, die Streams-Datensätze für Änderungen verarbeitet, die in einer bestimmten Region, aber nicht in anderen Regionen in einer globalen Tabelle vorgenommen wurden, können Sie jedem Element ein Attribut hinzufügen, das definiert, in welcher Region die Änderung für dieses Element stattgefunden hat. Sie können dieses Attribut verwenden, um Streams-Datensätze nach Änderungen zu filtern, die in anderen Regionen aufgetreten sind und hierzu auch Lambda-Ereignisfilter verwenden, um Lambda-Funktionen nur für Änderungen in einer bestimmten Region aufzurufen.

## Transaktionen
<a name="global-tables-transactions"></a>

In einer globalen Tabelle mit MREC-Konfiguration sind DynamoDB-Transaktionsoperationen ([https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html) und [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html)) nur innerhalb der Region, in der der Vorgang aufgerufen wurde, unteilbar. Schreibtransaktionen werden nicht als Einheit regionsübergreifend repliziert, was bedeutet, dass nur einige Schreibvorgänge in einer Transaktion zu einem bestimmten Zeitpunkt durch Lesevorgänge in anderen Replikaten zurückgegeben werden können.

Wenn Sie beispielsweise eine globale Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) nutzen und eine `TransactWriteItems`-Operation in der Region USA Ost (Ohio) durchführen, sind unter Umständen partiell durchgeführte Transaktionen in der Region USA West (Oregon) zu beobachten, während die Änderungen repliziert werden. Die Änderungen werden erst in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden.

Globale Tabellen mit MRSC-Konfiguration unterstützen keine Transaktionsvorgänge und geben einen Fehler zurück, wenn solche Operationen in einem MRSC-Replikat aufgerufen werden.

## Lese- und Schreibdurchsatz
<a name="V2globaltables_HowItWorks.Throughput"></a>

### Modus bereitgestellter Kapazität
<a name="gt_throughput.provisioned"></a>

Eine Replikation verbraucht Schreibkapazität. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Anwendungsschreibdurchsatz und Replikationsschreibdurchsatz die bereitgestellte Schreibkapazität übersteigt. Bei globalen Tabellen, die den Bereitstellungsmodus verwenden, werden die Auto Scaling-Einstellungen für Lese- und Schreibkapazitäten zwischen den Replikaten synchronisiert.

Sie können die Lesekapazitätseinstellungen für jedes Replikat in einer globalen Tabelle unabhängig konfigurieren, indem Sie den [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html)Parameter auf Replikatebene verwenden. Standardmäßig werden Änderungen an der bereitgestellten Lesekapazität auf alle Replikate in der globalen Tabelle angewendet. Beim Hinzufügen eines neuen Replikats zu einer globalen Tabelle wird die Lesekapazität der Quelltabelle oder des Replikats als Anfangswert verwendet, sofern nicht ausdrücklich eine Überschreibung auf Replikatebene angegeben ist.

### On-Demand-Modus
<a name="gt_throughput.on-demand"></a>

Bei globalen Tabellen, die für den On-Demand-Modus konfiguriert sind, wird die Schreibkapazität automatisch über alle Replikate hinweg synchronisiert. DynamoDB passt die Kapazität automatisch an den Datenverkehr an, und es müssen keine replikatspezifischen Lese- oder Schreibkapazitätseinstellungen verwaltet werden.

## Synchronisierung von Einstellungen
<a name="V2globaltables_HowItWorks.setting-synchronization"></a>

Einstellungen in globalen DynamoDB-Tabellen sind Konfigurationsparameter, mit denen verschiedene Aspekte des Tabellenverhaltens und der Replikation gesteuert werden können. Diese Einstellungen werden über die DynamoDB-Steuerebene verwaltet APIs und können beim Erstellen oder Ändern globaler Tabellen konfiguriert werden. In globale Tabellen werden bestimmte Einstellungen für alle Replikate automatisch synchronisiert, um die Konsistenz zu wahren und gleichzeitig Flexibilität für regionsspezifische Optimierungen zu ermöglichen. Wenn Sie wissen, welche Einstellungen synchronisiert werden und wie sich diese verhalten, können Sie Ihre globale Tabelle effizient konfigurieren. Je nach Art ihrer replikatsübergreifenden Synchronisation lassen sich diese Einstellungen in drei Hauptkategorien unterteilen.

Die folgenden Einstellungen werden immer zwischen Replikaten in einer globalen Tabelle synchronisiert:
+ Kapazitätsmodus (bereitgestellte oder On-Demand-Kapazität)
+ Bereitgestellte Schreibkapazität der Tabelle
+ Schreib-Auto-Scaling der Tabelle
+ Attributdefinition des Schlüsselschemas
+ Definition des globalen sekundären Index (GSI)
+ Bereitgestellte Schreibkapazität des GSI
+ Schreib-Auto-Scaling des GSI
+ Typ der serverseitigen Verschlüsselung (Server-Side Encryption, SSE)
+ Streams-Definition im MREC-Modus
+ Time to Live (TTL)
+ Warmdurchsatz
+ Maximaler On-Demand-Schreibdurchsatz

Die folgenden Einstellungen werden zwischen Replikaten synchronisiert, können jedoch für ein Replikat außer Kraft gesetzt werden:
+ Von der Tabelle bereitgestellte Lesekapazität
+ Auto-Scaling für Tabellenlesevorgänge
+ Vom GSI bereitgestellte Lesekapazität
+ Auto-Scaling für GSI-Lesevorgänge
+ Tabellenklasse
+ Maximaler On-Demand-Lesedurchsatz

**Anmerkung**  
Überschreibbare Werte werden geändert, wenn die Einstellung in einem anderen Replikat geändert wird. Sie haben zum Beispiel eine globale MREC-Tabelle mit Replikaten in USA Ost (Nord-Virginia) und USA West (Oregon). Für das Replikat „USA Ost“ (Nord-Virginia) wurde ein Lesedurchsatz von 200 bereitgestellt. RCUs Für das Replikat in der Region USA West (Oregon) wurde der bereitgestellte Lesedurchsatz auf 100 festgelegt. RCUs Wenn Sie die Einstellung für den bereitgestellten Lesedurchsatz auf dem Replikat USA Ost (Nord-Virginia) von 200 RCUs auf 300 aktualisieren RCUs, wird der neue Wert für den bereitgestellten Lesedurchsatz auch auf das Replikat in USA West (Oregon) angewendet. Dadurch wird die Einstellung für den bereitgestellten Lesedurchsatz für das Replikat USA West (Oregon) vom überschriebenen Wert 100 auf den neuen Wert 300 geändert. RCUs RCUs

Die folgenden Einstellungen werden niemals zwischen Replikaten in einer globalen Tabelle synchronisiert:
+ Löschschutz
+ Point-in-time Wiederherstellung
+ Tags (Markierungen)
+ Aktivierung von Table CloudWatch Contributor Insights
+ Aktivierung von GSI Contributor Insights CloudWatch 
+ Definition der Kinesis-Datenströme
+ Ressourcenrichtlinien
+ Streams-Definition im MREC-Modus

Alle anderen Einstellungen werden nicht zwischen Replikaten synchronisiert.

## DynamoDB Accelerator (DAX)
<a name="V2globaltables_HowItWorks.dax"></a>

Bei Schreibvorgängen in Replikate von globalen Tabellen wird DynamoDB unter Umgehung von DynamoDB Accelerator (DAX) direkt aktualisiert. In der Folge kann es zu veralteten DAX-Caches kommen, da der DAX-Cache nicht durch die Schreibvorgänge aktualisiert wird. DAX-Caches, die für Replikate von globalen Tabellen konfiguriert sind, werden erst bei Ablauf der TTL des Cache aktualisiert.

## Überlegungen zur Verwaltung globaler Tabellen
<a name="management-considerations"></a>

Sie können eine Tabelle, die zum Hinzufügen des neuen Replikats einer globalen Tabelle verwendet wurde, erst 24 Stunden nach der Erstellung des neuen Replikats löschen.

Wenn Sie eine AWS Region deaktivieren, die globale Tabellenreplikate enthält, werden diese Replikate 20 Stunden nach der Deaktivierung der Region dauerhaft in Tabellen mit nur einer Region konvertiert.

# Tutorials: Erstellen von globalen Tabellen
<a name="V2globaltables.tutorial"></a>

Dieser Abschnitt enthält step-by-step Anweisungen zum Erstellen globaler DynamoDB-Tabellen, die für Ihren bevorzugten Konsistenzmodus konfiguriert sind. Wählen Sie je nach Anforderungen der Anwendung entweder den Modus „Multi-Region Eventual Consistency (MREC)“ oder „Multi-Region Strong Consistency (MRSC)“ aus.

Globale MREC-Tabellen bieten eine geringere Schreiblatenz und sorgen letztendlich für Konsistenz über alle AWS-Regionen hinweg. Globale MRSC-Tabellen bieten strikt konsistente Lesevorgänge in allen Regionen und ermöglichen etwas höhere Schreiblatenzen als MREC-Tabellen. Wählen Sie den Konsistenzmodus, der den Anforderungen Ihrer Anwendung an Datenkonsistenz, Latenz und Verfügbarkeit am ehesten entspricht.

**Topics**
+ [Erstellen einer globalen Tabelle, die für den MREC-Modus konfiguriert ist](#V2creategt_mrec)
+ [Erstellen einer globalen Tabelle, die für den MRSC-Modus konfiguriert ist](#create-gt-mrsc)

## Erstellen einer globalen Tabelle, die für den MREC-Modus konfiguriert ist
<a name="V2creategt_mrec"></a>

In diesem Abschnitt erfahren Sie, wie Sie eine globale Tabelle im MREC-Modus (Multi-Region Eventual Consistency) erstellen. MREC ist der Standard-Konsistenzmodus für globale Tabellen und ermöglicht Schreibvorgänge mit geringer Latenz und asynchroner Replikation über alle AWS-Regionen hinweg. Änderungen, die in einer Region an einem Element vorgenommen werden, werden in der Regel innerhalb einer Sekunde auf alle anderen Regionen repliziert. Dadurch eignet sich der MREC-Modus ideal für Anwendungen, die einer geringen Schreiblatenz Priorität einräumen und tolerieren können, dass aus verschiedenen Regionen kurzzeitig Datenversionen mit geringen Unterschieden zurückgegeben werden.

Sie können globale MREC-Tabellen mit Replikaten in jeder AWS Region erstellen, in der DynamoDB verfügbar ist, und jederzeit Replikate hinzufügen oder entfernen. In den folgenden Beispielen wird gezeigt, wie eine globale DynamoDB-Tabelle mit Replikaten in mehreren Regionen erstellt wird.

### Erstellen einer globalen Tabelle im MREC-Modus mit der DynamoDB-Konsole
<a name="mrec-console"></a>

Gehen Sie wie folgt vor, um eine globale Tabelle mit der AWS-Managementkonsole zu erstellen. Im folgenden Beispiel wird eine globale Tabelle mit Replikattabellen in den USA und Europa erstellt.

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)

1. Wählen Sie für dieses Beispiel in der Regionsauswahl in der Navigationsleiste die Region **USA Ost (Ohio)** aus.

1. Klicken Sie im Navigationsbereich auf der linken Seite der Konsole auf **Tabellen**.

1. Wählen Sie **Tabelle erstellen** aus.

1. Gehen Sie auf der Seite **Tabelle erstellen** wie folgt vor:

   1. Geben Sie unter **Tabellenname** **Music** ein.

   1. Geben Sie unter **Partitionsschlüssel** den Wert **Artist** ein.

   1. Geben Sie unter **(Sortierschlüssel)** den Wert **SongTitle** ein.

   1. Behalten Sie die übrigen Standardeinstellungen bei und wählen Sie **Tabelle erstellen** aus.

      Diese neue Tabelle dient als erste Replikattabelle in einer neuen globalen Tabelle. Sie stellt den Prototyp für andere Replikattabellen dar, die Sie später hinzufügen.

1. Gehen Sie folgendermaßen vor, wenn die Tabelle aktiv wird:

   1. Wählen Sie in der Tabellenliste die Tabelle **Musik** aus.

   1. Wählen Sie die Registerkarte **Globale Tabellen** aus.

   1. Wählen Sie die Option **Replikat erstellen** aus.

1. Wählen Sie in der Dropdown-Liste **Verfügbare Replikationsregionen** den Eintrag **USA West (Oregon) us-west-2** aus.

   Die Konsole stellt sicher, dass die ausgewählte Region keine Tabelle mit demselben Namen enthält. Wenn eine Tabelle mit demselben Namen vorhanden ist, müssen Sie die vorhandene Tabelle löschen, bevor Sie eine neue Replikattabelle in der betreffenden Region erstellen können.

1. Wählen Sie die Option **Replikat erstellen** aus. Dies startet den Prozess der Erstellung von Tabellen in der Region „USA West (Oregon) us-west-2“.

   Die Registerkarte **Globale Tabelle** für die Tabelle **Music** (und für alle anderen Replikattabellen) zeigt, dass die Tabelle in mehreren Regionen repliziert wurde.

1. Fügen Sie eine weitere Region hinzu, indem Sie die vorherigen Schritte wiederholen, aber als Region **Europa (Frankfurt) eu-central-1** auswählen.

1. So testen Sie die Replikation:

   1. Stellen Sie sicher, dass Sie die AWS-Managementkonsole Region USA Ost (Ohio) verwenden.

   1. Wählen Sie **Tabellenelemente erkunden** aus.

   1. Wählen Sie **Element erstellen** aus.

   1. Geben Sie **item\$11** für **Künstler** und **Song Value 1** für ein **SongTitle**.

   1. Wählen Sie **Element erstellen** aus.

1. Überprüfen Sie die Replikation, indem Sie zu den anderen Regionen wechseln:

   1. Wählen Sie in der Regionsauswahl in der rechten oberen Ecke **Europa (Frankfurt)** aus.

   1. Vergewissern Sie sich, dass die Tabelle **Music** das von Ihnen erstellte Objekt enthält.

   1. Wiederholen Sie die Überprüfung für **USA West (Oregon)**.

### Erstellen einer globalen MREC-Tabelle mit AWS CLI oder Java
<a name="mrec-cli-java"></a>

------
#### [ CLI ]

Das folgende Codebeispiel zeigt, wie globale DynamoDB-Tabellen mit letztendlicher multiregionaler Konsistenz (Multi-Region Eventual Consistency, MREC) verwaltet werden.
+ Erstellen Sie eine Tabelle mit multiregionaler Replikation (MREC).
+ Fügen Sie Elemente in eine Replikattabelle ein und rufen Sie sie ab.
+ Entfernen Sie Replikate one-by-one.
+ Führen Sie eine Bereinigung durch Löschen der Tabelle aus.

**AWS CLI mit Bash-Skript**  
Erstellen Sie eine Tabelle mit multiregionaler Replikation.  

```
# Step 1: Create a new table (MusicTable) in US East (Ohio), with DynamoDB Streams enabled (NEW_AND_OLD_IMAGES)
aws dynamodb create-table \
    --table-name MusicTable \
    --attribute-definitions \
        AttributeName=Artist,AttributeType=S \
        AttributeName=SongTitle,AttributeType=S \
    --key-schema \
        AttributeName=Artist,KeyType=HASH \
        AttributeName=SongTitle,KeyType=RANGE \
    --billing-mode PAY_PER_REQUEST \
    --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
    --region us-east-2

# Step 2: Create an identical MusicTable table in US East (N. Virginia)
aws dynamodb update-table --table-name MusicTable --cli-input-json \
'{
  "ReplicaUpdates":
  [
    {
      "Create": {
        "RegionName": "us-east-1"
      }
    }
  ]
}' \
--region us-east-2

# Step 3: Create a table in Europe (Ireland)
aws dynamodb update-table --table-name MusicTable --cli-input-json \
'{
  "ReplicaUpdates":
  [
    {
      "Create": {
        "RegionName": "eu-west-1"
      }
    }
  ]
}' \
--region us-east-2
```
Beschreiben Sie die multiregionale Tabelle.  

```
# Step 4: View the list of replicas created using describe-table
aws dynamodb describe-table \
    --table-name MusicTable \
    --region us-east-2 \
    --query 'Table.{TableName:TableName,TableStatus:TableStatus,MultiRegionConsistency:MultiRegionConsistency,Replicas:Replicas[*].{Region:RegionName,Status:ReplicaStatus}}'
```
Fügen Sie Elemente in eine Replikattabelle ein.  

```
# Step 5: To verify that replication is working, add a new item to the Music table in US East (Ohio)
aws dynamodb put-item \
    --table-name MusicTable \
    --item '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
    --region us-east-2
```
Rufen Sie Elemente aus Replikattabellen ab.  

```
# Step 6: Wait for a few seconds, and then check to see whether the item has been 
# successfully replicated to US East (N. Virginia) and Europe (Ireland)
aws dynamodb get-item \
    --table-name MusicTable \
    --key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
    --region us-east-1

aws dynamodb get-item \
    --table-name MusicTable \
    --key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
    --region eu-west-1
```
Entfernen Sie Replikate.  

```
# Step 7: Delete the replica table in Europe (Ireland) Region
aws dynamodb update-table --table-name MusicTable --cli-input-json \
'{
  "ReplicaUpdates":
  [
    {
      "Delete": {
        "RegionName": "eu-west-1"
      }
    }
  ]
}' \
--region us-east-2

# Delete the replica table in US East (N. Virginia) Region
aws dynamodb update-table --table-name MusicTable --cli-input-json \
'{
  "ReplicaUpdates":
  [
    {
      "Delete": {
        "RegionName": "us-east-1"
      }
    }
  ]
}' \
--region us-east-2
```
Führen Sie eine Bereinigung durch Löschen der Tabelle aus.  

```
# Clean up: Delete the primary table
aws dynamodb delete-table --table-name MusicTable --region us-east-2

echo "Global table demonstration complete."
```
+ Weitere API-Informationen finden Sie in den folgenden Themen der *AWS CLI -Befehlsreferenz*.
  + [CreateTable](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/CreateTable)
  + [DeleteTable](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/DeleteTable)
  + [DescribeTable](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/DescribeTable)
  + [GetItem](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/GetItem)
  + [PutItem](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/PutItem)
  + [UpdateTable](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/UpdateTable)

------
#### [ Java ]

Im folgenden Codebeispiel wird gezeigt, wie globale DynamoDB-Tabellen mit Replikaten in mehreren Regionen erstellt und verwaltet werden.
+ Erstellen Sie eine Tabelle mit einem globalen sekundären Index und DynamoDB Streams.
+ Fügen Sie Replikate in verschiedenen Regionen hinzu, um eine globale Tabelle zu erstellen.
+ Entfernen Sie Replikate aus einer globalen Tabelle.
+ Fügen Sie Testelemente hinzu, um die regionsübergreifende Replikation zu überprüfen.
+ Beschreiben Sie die globale Tabellenkonfiguration und den Replikatstatus.

**SDK für Java 2.x**  
Erstellen Sie eine Tabelle mit Global Secondary Index und DynamoDB Streams mithilfe von. AWS SDK for Java 2.x  

```
    public static CreateTableResponse createTableWithGSI(
        final DynamoDbClient dynamoDbClient, final String tableName, final String indexName) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (indexName == null || indexName.trim().isEmpty()) {
            throw new IllegalArgumentException("Index name cannot be null or empty");
        }

        try {
            LOGGER.info("Creating table: " + tableName + " with GSI: " + indexName);

            CreateTableRequest createTableRequest = CreateTableRequest.builder()
                .tableName(tableName)
                .attributeDefinitions(
                    AttributeDefinition.builder()
                        .attributeName("Artist")
                        .attributeType(ScalarAttributeType.S)
                        .build(),
                    AttributeDefinition.builder()
                        .attributeName("SongTitle")
                        .attributeType(ScalarAttributeType.S)
                        .build())
                .keySchema(
                    KeySchemaElement.builder()
                        .attributeName("Artist")
                        .keyType(KeyType.HASH)
                        .build(),
                    KeySchemaElement.builder()
                        .attributeName("SongTitle")
                        .keyType(KeyType.RANGE)
                        .build())
                .billingMode(BillingMode.PAY_PER_REQUEST)
                .globalSecondaryIndexes(GlobalSecondaryIndex.builder()
                    .indexName(indexName)
                    .keySchema(KeySchemaElement.builder()
                        .attributeName("SongTitle")
                        .keyType(KeyType.HASH)
                        .build())
                    .projection(
                        Projection.builder().projectionType(ProjectionType.ALL).build())
                    .build())
                .streamSpecification(StreamSpecification.builder()
                    .streamEnabled(true)
                    .streamViewType(StreamViewType.NEW_AND_OLD_IMAGES)
                    .build())
                .build();

            CreateTableResponse response = dynamoDbClient.createTable(createTableRequest);
            LOGGER.info("Table creation initiated. Status: "
                + response.tableDescription().tableStatus());

            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to create table: " + tableName + " - " + e.getMessage());
            throw e;
        }
    }
```
Warten Sie, bis eine Tabelle aktiv wird mit. AWS SDK for Java 2.x  

```
    public static void waitForTableActive(final DynamoDbClient dynamoDbClient, final String tableName) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }

        try {
            LOGGER.info("Waiting for table to become active: " + tableName);

            try (DynamoDbWaiter waiter =
                DynamoDbWaiter.builder().client(dynamoDbClient).build()) {
                DescribeTableRequest request =
                    DescribeTableRequest.builder().tableName(tableName).build();

                waiter.waitUntilTableExists(request);
                LOGGER.info("Table is now active: " + tableName);
            }

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to wait for table to become active: " + tableName + " - " + e.getMessage());
            throw e;
        }
    }
```
Fügen Sie ein Replikat hinzu, um eine globale Tabelle zu erstellen oder zu erweitern mit AWS SDK for Java 2.x.  

```
    public static UpdateTableResponse addReplica(
        final DynamoDbClient dynamoDbClient,
        final String tableName,
        final Region replicaRegion,
        final String indexName,
        final Long readCapacity) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (replicaRegion == null) {
            throw new IllegalArgumentException("Replica region cannot be null");
        }
        if (indexName == null || indexName.trim().isEmpty()) {
            throw new IllegalArgumentException("Index name cannot be null or empty");
        }
        if (readCapacity == null || readCapacity <= 0) {
            throw new IllegalArgumentException("Read capacity must be a positive number");
        }

        try {
            LOGGER.info("Adding replica in region: " + replicaRegion.id() + " for table: " + tableName);

            // Create a ReplicationGroupUpdate for adding a replica
            ReplicationGroupUpdate replicationGroupUpdate = ReplicationGroupUpdate.builder()
                .create(builder -> builder.regionName(replicaRegion.id())
                    .globalSecondaryIndexes(ReplicaGlobalSecondaryIndex.builder()
                        .indexName(indexName)
                        .provisionedThroughputOverride(ProvisionedThroughputOverride.builder()
                            .readCapacityUnits(readCapacity)
                            .build())
                        .build())
                    .build())
                .build();

            UpdateTableRequest updateTableRequest = UpdateTableRequest.builder()
                .tableName(tableName)
                .replicaUpdates(replicationGroupUpdate)
                .build();

            UpdateTableResponse response = dynamoDbClient.updateTable(updateTableRequest);
            LOGGER.info("Replica addition initiated in region: " + replicaRegion.id());

            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to add replica in region: " + replicaRegion.id() + " - " + e.getMessage());
            throw e;
        }
    }
```
Entfernen Sie ein Replikat aus einer globalen Tabelle mit. AWS SDK for Java 2.x  

```
    public static UpdateTableResponse removeReplica(
        final DynamoDbClient dynamoDbClient, final String tableName, final Region replicaRegion) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (replicaRegion == null) {
            throw new IllegalArgumentException("Replica region cannot be null");
        }

        try {
            LOGGER.info("Removing replica in region: " + replicaRegion.id() + " for table: " + tableName);

            // Create a ReplicationGroupUpdate for removing a replica
            ReplicationGroupUpdate replicationGroupUpdate = ReplicationGroupUpdate.builder()
                .delete(builder -> builder.regionName(replicaRegion.id()).build())
                .build();

            UpdateTableRequest updateTableRequest = UpdateTableRequest.builder()
                .tableName(tableName)
                .replicaUpdates(replicationGroupUpdate)
                .build();

            UpdateTableResponse response = dynamoDbClient.updateTable(updateTableRequest);
            LOGGER.info("Replica removal initiated in region: " + replicaRegion.id());

            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to remove replica in region: " + replicaRegion.id() + " - " + e.getMessage());
            throw e;
        }
    }
```
Fügen Sie Testelemente hinzu, um die Replikation mithilfe von AWS SDK for Java 2.x zu überprüfen.  

```
    public static PutItemResponse putTestItem(
        final DynamoDbClient dynamoDbClient, final String tableName, final String artist, final String songTitle) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (artist == null || artist.trim().isEmpty()) {
            throw new IllegalArgumentException("Artist cannot be null or empty");
        }
        if (songTitle == null || songTitle.trim().isEmpty()) {
            throw new IllegalArgumentException("Song title cannot be null or empty");
        }

        try {
            LOGGER.info("Adding test item to table: " + tableName);

            Map<String, software.amazon.awssdk.services.dynamodb.model.AttributeValue> item = new HashMap<>();
            item.put(
                "Artist",
                software.amazon.awssdk.services.dynamodb.model.AttributeValue.builder()
                    .s(artist)
                    .build());
            item.put(
                "SongTitle",
                software.amazon.awssdk.services.dynamodb.model.AttributeValue.builder()
                    .s(songTitle)
                    .build());

            PutItemRequest putItemRequest =
                PutItemRequest.builder().tableName(tableName).item(item).build();

            PutItemResponse response = dynamoDbClient.putItem(putItemRequest);
            LOGGER.info("Test item added successfully");

            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to add test item to table: " + tableName + " - " + e.getMessage());
            throw e;
        }
    }
```
Beschreiben Sie die globale Tabellenkonfiguration und die Verwendung von AWS SDK for Java 2.x Replikaten.  

```
    public static DescribeTableResponse describeTable(final DynamoDbClient dynamoDbClient, final String tableName) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }

        try {
            LOGGER.info("Describing table: " + tableName);

            DescribeTableRequest request =
                DescribeTableRequest.builder().tableName(tableName).build();

            DescribeTableResponse response = dynamoDbClient.describeTable(request);

            LOGGER.info("Table status: " + response.table().tableStatus());
            if (response.table().replicas() != null
                && !response.table().replicas().isEmpty()) {
                LOGGER.info("Number of replicas: " + response.table().replicas().size());
                response.table()
                    .replicas()
                    .forEach(replica -> LOGGER.info(
                        "Replica region: " + replica.regionName() + ", Status: " + replica.replicaStatus()));
            }

            return response;

        } catch (ResourceNotFoundException e) {
            LOGGER.severe("Table not found: " + tableName + " - " + e.getMessage());
            throw e;
        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to describe table: " + tableName + " - " + e.getMessage());
            throw e;
        }
    }
```
Vollständiges Beispiel für globale Tabellenoperationen unter Verwendung von AWS SDK for Java 2.x.  

```
    public static void exampleUsage(final Region sourceRegion, final Region replicaRegion) {

        String tableName = "Music";
        String indexName = "SongTitleIndex";
        Long readCapacity = 15L;

        // Create DynamoDB client for the source region
        try (DynamoDbClient dynamoDbClient =
            DynamoDbClient.builder().region(sourceRegion).build()) {

            try {
                // Step 1: Create the initial table with GSI and streams
                LOGGER.info("Step 1: Creating table in source region: " + sourceRegion.id());
                createTableWithGSI(dynamoDbClient, tableName, indexName);

                // Step 2: Wait for table to become active
                LOGGER.info("Step 2: Waiting for table to become active");
                waitForTableActive(dynamoDbClient, tableName);

                // Step 3: Add replica in destination region
                LOGGER.info("Step 3: Adding replica in region: " + replicaRegion.id());
                addReplica(dynamoDbClient, tableName, replicaRegion, indexName, readCapacity);

                // Step 4: Wait a moment for replica creation to start
                Thread.sleep(5000);

                // Step 5: Describe table to view replica information
                LOGGER.info("Step 5: Describing table to view replicas");
                describeTable(dynamoDbClient, tableName);

                // Step 6: Add a test item to verify replication
                LOGGER.info("Step 6: Adding test item to verify replication");
                putTestItem(dynamoDbClient, tableName, "TestArtist", "TestSong");

                LOGGER.info("Global table setup completed successfully!");
                LOGGER.info("You can verify replication by checking the item in region: " + replicaRegion.id());

                // Step 7: Remove replica and clean up table
                LOGGER.info("Step 7: Removing replica from region: " + replicaRegion.id());
                removeReplica(dynamoDbClient, tableName, replicaRegion);
                DeleteTableResponse deleteTableResponse = dynamoDbClient.deleteTable(
                    DeleteTableRequest.builder().tableName(tableName).build());
                LOGGER.info("MREC global table demonstration completed successfully!");

            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                throw new RuntimeException("Thread was interrupted", e);
            } catch (DynamoDbException e) {
                LOGGER.severe("DynamoDB operation failed: " + e.getMessage());
                throw e;
            }
        }
    }
```
+ Weitere API-Informationen finden Sie in den folgenden Themen der *AWS SDK for Java 2.x -API-Referenz*.
  + [CreateTable](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/CreateTable)
  + [DescribeTable](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/DescribeTable)
  + [PutItem](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/PutItem)
  + [UpdateTable](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/UpdateTable)

------

## Erstellen einer globalen Tabelle, die für den MRSC-Modus konfiguriert ist
<a name="create-gt-mrsc"></a>

In diesem Abschnitt erfahren Sie, wie Sie eine globale Tabelle im MRSC-Modus (Multi-Region Strong Consistency) erstellen. Globale MRSC-Tabellen replizieren geänderte Elemente synchron über Regionen hinweg und stellen so sicher, dass durch strikt konsistente Lesevorgänge in jedem Replikat immer die aktuelle Version eines Elements zurückgegeben wird. Wenn Sie eine Tabelle mit einer einzigen Region in eine globale MRSC-Tabelle konvertieren, müssen Sie sicherstellen, dass die Tabelle leer ist. Die Konvertierung einer Tabelle mit nur einer Region in eine globale MRSC-Tabelle mit vorhandenen Elementen wird nicht unterstützt. Stellen Sie sicher, dass während des Konvertierungsvorgangs keine Daten in die Tabelle geschrieben werden.

Sie können eine globale MRSC-Tabelle mit drei Replikaten oder zwei Replikaten und einem Witness konfigurieren. Beim Erstellen einer globalen MRSC-Tabelle wählen Sie die Regionen aus, in denen Replikate und ein optionaler Witness bereitgestellt werden. Im folgenden Beispiel wird eine globale MRSC-Tabelle mit Replikaten in den Regionen USA Ost (Nord-Virginia) und USA Ost (Ohio) und einem Witness in der Region USA West (Oregon) erstellt.

**Anmerkung**  
Stellen Sie vor dem Erstellen einer globalen Tabelle sicher, dass die Service-Quota-Durchsatzgrenzwerte in allen Zielregionen einheitlich sind, da dies für die Erstellung einer globalen Tabelle erforderlich ist. Weitere Informationen zu den Grenzwerten für den Durchsatz für globale Tabellen finden Sie unter [Globale Tabellenkontingente](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html#gt-limits-throughput).

### Erstellen einer globalen Tabelle im MRSC-Modus mit der DynamoDB-Konsole
<a name="mrsc_console"></a>

Gehen Sie wie folgt vor, um eine globale Tabelle mit der AWS-Managementkonsole zu erstellen.

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)

1. Wählen Sie in der Navigationsleiste Regionsauswahl eine Region aus, in der globale Tabellen mit MRSC [unterstützt werden](V2globaltables_HowItWorks.md#V2globaltables_HowItWorks.consistency-modes), wie z. B. **us-east-2**.

1. Wählen Sie im Navigationsbereich **Tables** (Tabellen) aus.

1. Wählen Sie **Create table** (Tabelle erstellen) aus.

1. Gehen Sie auf der Seite **Tabelle erstellen** wie folgt vor:

   1. Geben Sie unter **Tabellenname** **Music** ein.

   1. Geben Sie unter **Partitionsschlüssel** den Wert **Artist** ein und behalten Sie die Standardeinstellung **Zeichenfolge** bei.

   1. Geben Sie unter **Sortierschlüssel** den Wert **SongTitle** ein und behalten Sie die Standardeinstellung **Zeichenfolge** bei.

   1. Behalten Sie die übrigen Standardeinstellungen bei und wählen Sie **Tabelle erstellen** aus.

      Diese neue Tabelle dient als erste Replikattabelle in einer neuen globalen Tabelle. Sie stellt den Prototyp für andere Replikattabellen dar, die Sie später hinzufügen.

1. Warten Sie, bis die Tabelle aktiv wird, und wählen Sie sie dann aus der Tabellenliste aus.

1. Wählen Sie die Registerkarte **Globale Tabellen** und anschließend **Replikat erstellen** aus.

1. Gehen Sie auf der Seite **Replikat erstellen** wie folgt vor:

   1. Wählen Sie unter **Multiregionale Konsistenz** die Option **Starke Konsistenz** aus.

   1. Wählen Sie unter **Replikationsregion 1** die Option **US East (N. Virginia) us-east-1** aus.

   1. Wählen Sie unter **Replikationsregion 2** die Option **US West (Oregon) us-west-2** aus.

   1. Aktivieren Sie Option **Als Witness konfigurieren** für die Region „USA West (Oregon)“.

   1. Wählen Sie die Option **Replikat erstellen** aus.

1. Warten Sie, bis der Vorgang zur Erstellung des Replikats und des Witness abgeschlossen ist. Der Replikatstatus lautet **Aktiv**, wenn die Tabelle einsatzbereit ist.

### Erstellen einer globalen MRSC-Tabelle mit oder Java AWS CLI
<a name="mrsc-cli-java"></a>

Bevor Sie beginnen, stellen Sie sicher, dass Ihr IAM-Prinzipal über die erforderlichen Berechtigungen verfügt, um eine globale MRSC-Tabelle mit einer Witness-Region zu erstellen.

Mit der folgenden IAM-Beispielrichtlinie können Sie eine DynamoDB-Tabelle (`MusicTable`) in der Region „USA Ost (Ohio)“ mit einem Replikat in der Region „USA Ost (Nord-Virginia)“ und einer Witness-Region in der Region „USA West (Oregon)“ erstellen:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:CreateTable",
                "dynamodb:CreateTableReplica",
                "dynamodb:CreateGlobalTableWitness",
                "dynamodb:DescribeTable",
                "dynamodb:UpdateTable",
                "dynamodb:DeleteTable",
                "dynamodb:DeleteTableReplica",
                "dynamodb:DeleteGlobalTableWitness",
                "dynamodb:Scan",
                "dynamodb:Query",
                "dynamodb:UpdateItem",
                "dynamodb:PutItem",
                "dynamodb:GetItem",
                "dynamodb:DeleteItem",
                "dynamodb:BatchWriteItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-east-1:123456789012:table/MusicTable",
                "arn:aws:dynamodb:us-east-2:123456789012:table/MusicTable",
                "arn:aws:dynamodb:us-west-2:123456789012:table/MusicTable"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "arn:aws:iam::*:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication",
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName": "replication.dynamodb.amazonaws.com"
                }
            }
        }
    ]
}
```

------

In den folgenden Codebeispielen wird gezeigt, wie globale DynamoDB-Tabellen mit Multi-Region Strong Consistency (MRSC) erstellt und verwaltet werden.
+ Erstellen einer Tabelle mit multiregionaler starker Konsistenz
+ Überprüfen Sie die MRSC-Konfiguration und den Replikatstatus.
+ Testen Sie die starke Konsistenz in allen Regionen mit sofortigen Lesevorgängen.
+ Führen Sie bedingte Schreibvorgänge mit MRSC-Garantien durch.
+ Bereinigen Sie die globalen MRSC-Tabellenressourcen.

------
#### [ Bash ]

**AWS CLI mit Bash-Skript**  
Erstellen Sie eine Tabelle mit multiregionaler starker Konsistenz (Multiregion Strong Consistency, MRSC).  

```
# Step 1: Create a new table in us-east-2 (primary region for MRSC)
# Note: Table must be empty when enabling MRSC
aws dynamodb create-table \
    --table-name MusicTable \
    --attribute-definitions \
        AttributeName=Artist,AttributeType=S \
        AttributeName=SongTitle,AttributeType=S \
    --key-schema \
        AttributeName=Artist,KeyType=HASH \
        AttributeName=SongTitle,KeyType=RANGE \
    --billing-mode PAY_PER_REQUEST \
    --region us-east-2

# Wait for table to become active
aws dynamodb wait table-exists --table-name MusicTable --region us-east-2

# Step 2: Add replica and witness with Multi-Region Strong Consistency
# MRSC requires exactly three replicas in supported regions
aws dynamodb update-table \
    --table-name MusicTable \
    --replica-updates '[{"Create": {"RegionName": "us-east-1"}}]' \
    --global-table-witness-updates '[{"Create": {"RegionName": "us-west-2"}}]' \
    --multi-region-consistency STRONG \
    --region us-east-2
```
Überprüfen Sie die MRSC-Konfiguration und den Replikatstatus.  

```
# Verify the global table configuration and MRSC setting
aws dynamodb describe-table \
    --table-name MusicTable \
    --region us-east-2 \
    --query 'Table.{TableName:TableName,TableStatus:TableStatus,MultiRegionConsistency:MultiRegionConsistency,Replicas:Replicas[*],GlobalTableWitnesses:GlobalTableWitnesses[*].{Region:RegionName,Status:ReplicaStatus}}'
```
Testen Sie die starke Konsistenz mit sofortigen Lesevorgängen in allen Regionen.  

```
# Write an item to the primary region
aws dynamodb put-item \
    --table-name MusicTable \
    --item '{"Artist": {"S":"The Beatles"},"SongTitle": {"S":"Hey Jude"},"Album": {"S":"The Beatles 1967-1970"},"Year": {"N":"1968"}}' \
    --region us-east-2

# Read the item from replica region to verify strong consistency (cannot read or write to witness)
# No wait time needed - MRSC provides immediate consistency
echo "Reading from us-east-1 (immediate consistency):"
aws dynamodb get-item \
    --table-name MusicTable \
    --key '{"Artist": {"S":"The Beatles"},"SongTitle": {"S":"Hey Jude"}}' \
    --consistent-read \
    --region us-east-1
```
Führen Sie bedingte Schreibvorgänge mit MRSC-Garantien durch.  

```
# Perform a conditional update from a different region
# This demonstrates that conditions work consistently across all regions
aws dynamodb update-item \
    --table-name MusicTable \
    --key '{"Artist": {"S":"The Beatles"},"SongTitle": {"S":"Hey Jude"}}' \
    --update-expression "SET #rating = :rating" \
    --condition-expression "attribute_exists(Artist)" \
    --expression-attribute-names '{"#rating": "Rating"}' \
    --expression-attribute-values '{":rating": {"N":"5"}}' \
    --region us-east-1
```
Bereinigen Sie die globalen MRSC-Tabellenressourcen.  

```
# Remove replica tables (must be done before deleting the primary table)
aws dynamodb update-table \
    --table-name MusicTable \
    --replica-updates '[{"Delete": {"RegionName": "us-east-1"}}]' \
    --global-table-witness-updates '[{"Delete": {"RegionName": "us-west-2"}}]' \
    --region us-east-2

# Wait for replicas to be deleted
echo "Waiting for replicas to be deleted..."
sleep 30

# Delete the primary table
aws dynamodb delete-table \
    --table-name MusicTable \
    --region us-east-2
```
+ Weitere API-Informationen finden Sie in den folgenden Themen der *AWS CLI -Befehlsreferenz*.
  + [CreateTable](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/CreateTable)
  + [DeleteTable](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/DeleteTable)
  + [DescribeTable](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/DescribeTable)
  + [GetItem](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/GetItem)
  + [PutItem](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/PutItem)
  + [UpdateItem](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/UpdateItem)
  + [UpdateTable](https://docs.aws.amazon.com/goto/aws-cli/dynamodb-2012-08-10/UpdateTable)

------
#### [ Java ]

**SDK für Java 2.x**  
Erstellen Sie eine regionale Tabelle, die für die MRSC-Konvertierung bereit ist, mit. AWS SDK for Java 2.x  

```
    public static CreateTableResponse createRegionalTable(final DynamoDbClient dynamoDbClient, final String tableName) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }

        try {
            LOGGER.info("Creating regional table: " + tableName + " (must be empty for MRSC)");

            CreateTableRequest createTableRequest = CreateTableRequest.builder()
                .tableName(tableName)
                .attributeDefinitions(
                    AttributeDefinition.builder()
                        .attributeName("Artist")
                        .attributeType(ScalarAttributeType.S)
                        .build(),
                    AttributeDefinition.builder()
                        .attributeName("SongTitle")
                        .attributeType(ScalarAttributeType.S)
                        .build())
                .keySchema(
                    KeySchemaElement.builder()
                        .attributeName("Artist")
                        .keyType(KeyType.HASH)
                        .build(),
                    KeySchemaElement.builder()
                        .attributeName("SongTitle")
                        .keyType(KeyType.RANGE)
                        .build())
                .billingMode(BillingMode.PAY_PER_REQUEST)
                .build();

            CreateTableResponse response = dynamoDbClient.createTable(createTableRequest);
            LOGGER.info("Regional table creation initiated. Status: "
                + response.tableDescription().tableStatus());

            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to create regional table: " + tableName + " - " + e.getMessage());
            throw DynamoDbException.builder()
                .message("Failed to create regional table: " + tableName)
                .cause(e)
                .build();
        }
    }
```
Konvertiert eine regionale Tabelle in eine MRSC-Tabelle mit Replikaten und Zeugen unter Verwendung von. AWS SDK for Java 2.x  

```
    public static UpdateTableResponse convertToMRSCWithWitness(
        final DynamoDbClient dynamoDbClient,
        final String tableName,
        final Region replicaRegion,
        final Region witnessRegion) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (replicaRegion == null) {
            throw new IllegalArgumentException("Replica region cannot be null");
        }
        if (witnessRegion == null) {
            throw new IllegalArgumentException("Witness region cannot be null");
        }

        try {
            LOGGER.info("Converting table to MRSC with replica in " + replicaRegion.id() + " and witness in "
                + witnessRegion.id());

            // Create replica update using ReplicationGroupUpdate
            ReplicationGroupUpdate replicaUpdate = ReplicationGroupUpdate.builder()
                .create(CreateReplicationGroupMemberAction.builder()
                    .regionName(replicaRegion.id())
                    .build())
                .build();

            // Create witness update
            GlobalTableWitnessGroupUpdate witnessUpdate = GlobalTableWitnessGroupUpdate.builder()
                .create(CreateGlobalTableWitnessGroupMemberAction.builder()
                    .regionName(witnessRegion.id())
                    .build())
                .build();

            UpdateTableRequest updateTableRequest = UpdateTableRequest.builder()
                .tableName(tableName)
                .replicaUpdates(List.of(replicaUpdate))
                .globalTableWitnessUpdates(List.of(witnessUpdate))
                .multiRegionConsistency(MultiRegionConsistency.STRONG)
                .build();

            UpdateTableResponse response = dynamoDbClient.updateTable(updateTableRequest);
            LOGGER.info("MRSC conversion initiated. Status: "
                + response.tableDescription().tableStatus());
            LOGGER.info("UpdateTableResponse full object: " + response);
            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to convert table to MRSC: " + tableName + " - " + e.getMessage());
            throw DynamoDbException.builder()
                .message("Failed to convert table to MRSC: " + tableName)
                .cause(e)
                .build();
        }
    }
```
Beschreiben Sie eine globale MRSC-Tabellenkonfiguration mit. AWS SDK for Java 2.x  

```
    public static DescribeTableResponse describeMRSCTable(final DynamoDbClient dynamoDbClient, final String tableName) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }

        try {
            LOGGER.info("Describing MRSC global table: " + tableName);

            DescribeTableRequest request =
                DescribeTableRequest.builder().tableName(tableName).build();

            DescribeTableResponse response = dynamoDbClient.describeTable(request);

            LOGGER.info("Table status: " + response.table().tableStatus());
            LOGGER.info("Multi-region consistency: " + response.table().multiRegionConsistency());

            if (response.table().replicas() != null
                && !response.table().replicas().isEmpty()) {
                LOGGER.info("Number of replicas: " + response.table().replicas().size());
                response.table()
                    .replicas()
                    .forEach(replica -> LOGGER.info(
                        "Replica region: " + replica.regionName() + ", Status: " + replica.replicaStatus()));
            }

            if (response.table().globalTableWitnesses() != null
                && !response.table().globalTableWitnesses().isEmpty()) {
                LOGGER.info("Number of witnesses: "
                    + response.table().globalTableWitnesses().size());
                response.table()
                    .globalTableWitnesses()
                    .forEach(witness -> LOGGER.info(
                        "Witness region: " + witness.regionName() + ", Status: " + witness.witnessStatus()));
            }

            return response;

        } catch (ResourceNotFoundException e) {
            LOGGER.severe("Table not found: " + tableName + " - " + e.getMessage());
            throw DynamoDbException.builder()
                .message("Table not found: " + tableName)
                .cause(e)
                .build();
        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to describe table: " + tableName + " - " + e.getMessage());
            throw DynamoDbException.builder()
                .message("Failed to describe table: " + tableName)
                .cause(e)
                .build();
        }
    }
```
Fügen Sie mit AWS SDK for Java 2.x Testelemente hinzu, um die starke Konsistenz von MRSC zu überprüfen.  

```
    public static PutItemResponse putTestItem(
        final DynamoDbClient dynamoDbClient,
        final String tableName,
        final String artist,
        final String songTitle,
        final String album,
        final String year) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (artist == null || artist.trim().isEmpty()) {
            throw new IllegalArgumentException("Artist cannot be null or empty");
        }
        if (songTitle == null || songTitle.trim().isEmpty()) {
            throw new IllegalArgumentException("Song title cannot be null or empty");
        }

        try {
            LOGGER.info("Adding test item to MRSC global table: " + tableName);

            Map<String, AttributeValue> item = new HashMap<>();
            item.put("Artist", AttributeValue.builder().s(artist).build());
            item.put("SongTitle", AttributeValue.builder().s(songTitle).build());

            if (album != null && !album.trim().isEmpty()) {
                item.put("Album", AttributeValue.builder().s(album).build());
            }
            if (year != null && !year.trim().isEmpty()) {
                item.put("Year", AttributeValue.builder().n(year).build());
            }

            PutItemRequest putItemRequest =
                PutItemRequest.builder().tableName(tableName).item(item).build();

            PutItemResponse response = dynamoDbClient.putItem(putItemRequest);
            LOGGER.info("Test item added successfully with strong consistency");

            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to add test item to table: " + tableName + " - " + e.getMessage());
            throw DynamoDbException.builder()
                .message("Failed to add test item to table: " + tableName)
                .cause(e)
                .build();
        }
    }
```
Lesen Sie Elemente mit konsistenten Lesevorgängen aus MRSC-Replikaten unter Verwendung von. AWS SDK for Java 2.x  

```
    public static GetItemResponse getItemWithConsistentRead(
        final DynamoDbClient dynamoDbClient, final String tableName, final String artist, final String songTitle) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (artist == null || artist.trim().isEmpty()) {
            throw new IllegalArgumentException("Artist cannot be null or empty");
        }
        if (songTitle == null || songTitle.trim().isEmpty()) {
            throw new IllegalArgumentException("Song title cannot be null or empty");
        }

        try {
            LOGGER.info("Reading item from MRSC global table with consistent read: " + tableName);

            Map<String, AttributeValue> key = new HashMap<>();
            key.put("Artist", AttributeValue.builder().s(artist).build());
            key.put("SongTitle", AttributeValue.builder().s(songTitle).build());

            GetItemRequest getItemRequest = GetItemRequest.builder()
                .tableName(tableName)
                .key(key)
                .consistentRead(true)
                .build();

            GetItemResponse response = dynamoDbClient.getItem(getItemRequest);

            if (response.hasItem()) {
                LOGGER.info("Item found with strong consistency - no wait time needed");
            } else {
                LOGGER.info("Item not found");
            }

            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to read item from table: " + tableName + " - " + e.getMessage());
            throw DynamoDbException.builder()
                .message("Failed to read item from table: " + tableName)
                .cause(e)
                .build();
        }
    }
```
Führen Sie bedingte Aktualisierungen mit MRSC-Garantien durch, indem Sie. AWS SDK for Java 2.x  

```
    public static UpdateItemResponse performConditionalUpdate(
        final DynamoDbClient dynamoDbClient,
        final String tableName,
        final String artist,
        final String songTitle,
        final String rating) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (artist == null || artist.trim().isEmpty()) {
            throw new IllegalArgumentException("Artist cannot be null or empty");
        }
        if (songTitle == null || songTitle.trim().isEmpty()) {
            throw new IllegalArgumentException("Song title cannot be null or empty");
        }
        if (rating == null || rating.trim().isEmpty()) {
            throw new IllegalArgumentException("Rating cannot be null or empty");
        }

        try {
            LOGGER.info("Performing conditional update on MRSC global table: " + tableName);

            Map<String, AttributeValue> key = new HashMap<>();
            key.put("Artist", AttributeValue.builder().s(artist).build());
            key.put("SongTitle", AttributeValue.builder().s(songTitle).build());

            Map<String, String> expressionAttributeNames = new HashMap<>();
            expressionAttributeNames.put("#rating", "Rating");

            Map<String, AttributeValue> expressionAttributeValues = new HashMap<>();
            expressionAttributeValues.put(
                ":rating", AttributeValue.builder().n(rating).build());

            UpdateItemRequest updateItemRequest = UpdateItemRequest.builder()
                .tableName(tableName)
                .key(key)
                .updateExpression("SET #rating = :rating")
                .conditionExpression("attribute_exists(Artist)")
                .expressionAttributeNames(expressionAttributeNames)
                .expressionAttributeValues(expressionAttributeValues)
                .build();

            UpdateItemResponse response = dynamoDbClient.updateItem(updateItemRequest);
            LOGGER.info("Conditional update successful - demonstrates strong consistency");

            return response;

        } catch (ConditionalCheckFailedException e) {
            LOGGER.warning("Conditional check failed: " + e.getMessage());
            throw e;
        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to perform conditional update: " + tableName + " - " + e.getMessage());
            throw DynamoDbException.builder()
                .message("Failed to perform conditional update: " + tableName)
                .cause(e)
                .build();
        }
    }
```
Warten Sie, bis MRSC-Repliken und Zeugen die Nutzung aktivieren. AWS SDK for Java 2.x  

```
    public static void waitForMRSCReplicasActive(
        final DynamoDbClient dynamoDbClient, final String tableName, final int maxWaitTimeSeconds)
        throws InterruptedException {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (maxWaitTimeSeconds <= 0) {
            throw new IllegalArgumentException("Max wait time must be positive");
        }

        try {
            LOGGER.info("Waiting for MRSC replicas and witnesses to become active: " + tableName);

            final long startTime = System.currentTimeMillis();
            final long maxWaitTimeMillis = maxWaitTimeSeconds * 1000L;
            int backoffSeconds = 5; // Start with 5 second intervals
            final int maxBackoffSeconds = 30; // Cap at 30 seconds

            while (System.currentTimeMillis() - startTime < maxWaitTimeMillis) {
                DescribeTableResponse response = describeMRSCTable(dynamoDbClient, tableName);

                boolean allActive = true;
                StringBuilder statusReport = new StringBuilder();

                if (response.table().multiRegionConsistency() == null
                    || !MultiRegionConsistency.STRONG
                        .toString()
                        .equals(response.table().multiRegionConsistency().toString())) {
                    allActive = false;
                    statusReport
                        .append("MultiRegionConsistency: ")
                        .append(response.table().multiRegionConsistency())
                        .append(" ");
                }
                if (response.table().replicas() == null
                    || response.table().replicas().isEmpty()) {
                    allActive = false;
                    statusReport.append("No replicas found. ");
                }
                if (response.table().globalTableWitnesses() == null
                    || response.table().globalTableWitnesses().isEmpty()) {
                    allActive = false;
                    statusReport.append("No witnesses found. ");
                }

                // Check table status
                if (!"ACTIVE".equals(response.table().tableStatus().toString())) {
                    allActive = false;
                    statusReport
                        .append("Table: ")
                        .append(response.table().tableStatus())
                        .append(" ");
                }

                // Check replica status
                if (response.table().replicas() != null) {
                    for (var replica : response.table().replicas()) {
                        if (!"ACTIVE".equals(replica.replicaStatus().toString())) {
                            allActive = false;
                            statusReport
                                .append("Replica(")
                                .append(replica.regionName())
                                .append("): ")
                                .append(replica.replicaStatus())
                                .append(" ");
                        }
                    }
                }

                // Check witness status
                if (response.table().globalTableWitnesses() != null) {
                    for (var witness : response.table().globalTableWitnesses()) {
                        if (!"ACTIVE".equals(witness.witnessStatus().toString())) {
                            allActive = false;
                            statusReport
                                .append("Witness(")
                                .append(witness.regionName())
                                .append("): ")
                                .append(witness.witnessStatus())
                                .append(" ");
                        }
                    }
                }

                if (allActive) {
                    LOGGER.info("All MRSC replicas and witnesses are now active: " + tableName);
                    return;
                }

                LOGGER.info("Waiting for MRSC components to become active. Status: " + statusReport.toString());
                LOGGER.info("Next check in " + backoffSeconds + " seconds...");

                tempWait(backoffSeconds);

                // Exponential backoff with cap
                backoffSeconds = Math.min(backoffSeconds * 2, maxBackoffSeconds);
            }

            throw DynamoDbException.builder()
                .message("Timeout waiting for MRSC replicas to become active after " + maxWaitTimeSeconds + " seconds")
                .build();

        } catch (DynamoDbException | InterruptedException e) {
            LOGGER.severe("Failed to wait for MRSC replicas to become active: " + tableName + " - " + e.getMessage());
            throw e;
        }
    }
```
Bereinigen Sie MRSC-Replikate und Zeugen mithilfe von. AWS SDK for Java 2.x  

```
    public static UpdateTableResponse cleanupMRSCReplicas(
        final DynamoDbClient dynamoDbClient,
        final String tableName,
        final Region replicaRegion,
        final Region witnessRegion) {

        if (dynamoDbClient == null) {
            throw new IllegalArgumentException("DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (replicaRegion == null) {
            throw new IllegalArgumentException("Replica region cannot be null");
        }
        if (witnessRegion == null) {
            throw new IllegalArgumentException("Witness region cannot be null");
        }

        try {
            LOGGER.info("Cleaning up MRSC replicas and witnesses for table: " + tableName);

            // Remove replica using ReplicationGroupUpdate
            ReplicationGroupUpdate replicaUpdate = ReplicationGroupUpdate.builder()
                .delete(DeleteReplicationGroupMemberAction.builder()
                    .regionName(replicaRegion.id())
                    .build())
                .build();

            // Remove witness
            GlobalTableWitnessGroupUpdate witnessUpdate = GlobalTableWitnessGroupUpdate.builder()
                .delete(DeleteGlobalTableWitnessGroupMemberAction.builder()
                    .regionName(witnessRegion.id())
                    .build())
                .build();

            UpdateTableRequest updateTableRequest = UpdateTableRequest.builder()
                .tableName(tableName)
                .replicaUpdates(List.of(replicaUpdate))
                .globalTableWitnessUpdates(List.of(witnessUpdate))
                .build();

            UpdateTableResponse response = dynamoDbClient.updateTable(updateTableRequest);
            LOGGER.info("MRSC cleanup initiated - removing replica and witness. Response: " + response);

            return response;

        } catch (DynamoDbException e) {
            LOGGER.severe("Failed to cleanup MRSC replicas: " + tableName + " - " + e.getMessage());
            throw DynamoDbException.builder()
                .message("Failed to cleanup MRSC replicas: " + tableName)
                .cause(e)
                .build();
        }
    }
```
Vollständige Demonstration des MRSC-Workflows mithilfe von. AWS SDK for Java 2.x  

```
    public static void demonstrateCompleteMRSCWorkflow(
        final DynamoDbClient primaryClient,
        final DynamoDbClient replicaClient,
        final String tableName,
        final Region replicaRegion,
        final Region witnessRegion)
        throws InterruptedException {

        if (primaryClient == null) {
            throw new IllegalArgumentException("Primary DynamoDB client cannot be null");
        }
        if (replicaClient == null) {
            throw new IllegalArgumentException("Replica DynamoDB client cannot be null");
        }
        if (tableName == null || tableName.trim().isEmpty()) {
            throw new IllegalArgumentException("Table name cannot be null or empty");
        }
        if (replicaRegion == null) {
            throw new IllegalArgumentException("Replica region cannot be null");
        }
        if (witnessRegion == null) {
            throw new IllegalArgumentException("Witness region cannot be null");
        }

        try {
            LOGGER.info("=== Starting Complete MRSC Workflow Demonstration ===");

            // Step 1: Create an empty single-Region table
            LOGGER.info("Step 1: Creating empty single-Region table");
            createRegionalTable(primaryClient, tableName);

            // Use the existing GlobalTableOperations method for basic table waiting
            LOGGER.info("Intermediate step: Waiting for table [" + tableName + "] to become active before continuing");
            GlobalTableOperations.waitForTableActive(primaryClient, tableName);

            // Step 2: Convert to MRSC with replica and witness
            LOGGER.info("Step 2: Converting to MRSC with replica and witness");
            convertToMRSCWithWitness(primaryClient, tableName, replicaRegion, witnessRegion);

            // Wait for MRSC conversion to complete using MRSC-specific waiter
            LOGGER.info("Waiting for MRSC conversion to complete...");
            waitForMRSCReplicasActive(primaryClient, tableName);

            LOGGER.info("Intermediate step: Waiting for table [" + tableName + "] to become active before continuing");
            GlobalTableOperations.waitForTableActive(primaryClient, tableName);

            // Step 3: Verify MRSC configuration
            LOGGER.info("Step 3: Verifying MRSC configuration");
            describeMRSCTable(primaryClient, tableName);

            // Step 4: Test strong consistency with data operations
            LOGGER.info("Step 4: Testing strong consistency with data operations");

            // Add test item to primary region
            putTestItem(primaryClient, tableName, "The Beatles", "Hey Jude", "The Beatles 1967-1970", "1968");

            // Immediately read from replica region (no wait needed with MRSC)
            LOGGER.info("Reading from replica region immediately (strong consistency):");
            GetItemResponse getResponse =
                getItemWithConsistentRead(replicaClient, tableName, "The Beatles", "Hey Jude");

            if (getResponse.hasItem()) {
                LOGGER.info("✓ Strong consistency verified - item immediately available in replica region");
            } else {
                LOGGER.warning("✗ Item not found in replica region");
            }

            // Test conditional update from replica region
            LOGGER.info("Testing conditional update from replica region:");
            performConditionalUpdate(replicaClient, tableName, "The Beatles", "Hey Jude", "5");
            LOGGER.info("✓ Conditional update successful - demonstrates strong consistency");

            // Step 5: Cleanup
            LOGGER.info("Step 5: Cleaning up resources");
            cleanupMRSCReplicas(primaryClient, tableName, replicaRegion, witnessRegion);

            // Wait for cleanup to complete using basic table waiter
            LOGGER.info("Waiting for replica cleanup to complete...");
            GlobalTableOperations.waitForTableActive(primaryClient, tableName);

            // "Halt" until replica/witness cleanup is complete
            DescribeTableResponse cleanupVerification = describeMRSCTable(primaryClient, tableName);
            int backoffSeconds = 5; // Start with 5 second intervals
            while (cleanupVerification.table().multiRegionConsistency() != null) {
                LOGGER.info("Waiting additional time (" + backoffSeconds + " seconds) for MRSC cleanup to complete...");
                tempWait(backoffSeconds);

                // Exponential backoff with cap
                backoffSeconds = Math.min(backoffSeconds * 2, 30);
                cleanupVerification = describeMRSCTable(primaryClient, tableName);
            }

            // Delete the primary table
            deleteTable(primaryClient, tableName);

            LOGGER.info("=== MRSC Workflow Demonstration Complete ===");
            LOGGER.info("");
            LOGGER.info("Key benefits of Multi-Region Strong Consistency (MRSC):");
            LOGGER.info("- Immediate consistency across all regions (no eventual consistency delays)");
            LOGGER.info("- Simplified application logic (no need to handle eventual consistency)");
            LOGGER.info("- Support for conditional writes and transactions across regions");
            LOGGER.info("- Consistent read operations from any region without waiting");

        } catch (DynamoDbException | InterruptedException e) {
            LOGGER.severe("MRSC workflow failed: " + e.getMessage());
            throw e;
        }
    }
```
+ Weitere API-Informationen finden Sie in den folgenden Themen der *AWS SDK for Java 2.x -API-Referenz*.
  + [CreateTable](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/CreateTable)
  + [DeleteTable](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/DeleteTable)
  + [DescribeTable](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/DescribeTable)
  + [GetItem](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/GetItem)
  + [PutItem](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/PutItem)
  + [UpdateItem](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/UpdateItem)
  + [UpdateTable](https://docs.aws.amazon.com/goto/SdkForJavaV2/dynamodb-2012-08-10/UpdateTable)

------

# Sicherheit von globalen DynamoDB-Tabellen
<a name="globaltables-security"></a>

Globale Tabellenreplikate sind DynamoDB-Tabellen. Sie verwenden also dieselben Methoden zur Steuerung des Zugriffs auf Replikate wie für Tabellen mit einer einzelnen Region, einschließlich AWS Identity and Access Management (IAM-) Identitätsrichtlinien und ressourcenbasierter Richtlinien.

In diesem Thema wird beschrieben, wie Sie globale DynamoDB-Tabellen mithilfe von IAM-Berechtigungen und AWS Key Management Service ()AWS KMS-Verschlüsselung sichern. Sie erfahren mehr über die serviceverknüpften Rollen (SLR), die regionsübergreifende Replikation und auto-scaling ermöglichen, über die IAM-Berechtigungen, die zum Erstellen, Aktualisieren und Löschen globaler Tabellen erforderlich sind, und über die Unterschiede zwischen Multi-Region Eventual Consistency (MREC) und Multi-Region Strong Consistency (MRSC) -Tabellen. Außerdem erfahren Sie mehr über Verschlüsselungsschlüssel, mit denen Sie die regionsübergreifende Replikation sicher verwalten können. AWS KMS 

## Mit Diensten verknüpfte Rollen für globale Tabellen
<a name="globaltables-slr"></a>

Globale DynamoDB-Tabellen basieren auf serviceverknüpften Rollen (SLRs), um regionsübergreifende Replikations- und Autoskalierungsfunktionen zu verwalten.

Sie müssen diese Rollen nur einmal pro Konto einrichten. AWS Nach der Erstellung dienen dieselben Rollen für alle globalen Tabellen in Ihrem Konto. Weitere Informationen zu serviceverknüpften Rollen finden Sie unter [Verwenden serviceverknüpfter Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) im *IAM-Benutzerhandbuch*.

### Mit dem Replikationsservice verknüpfte Rolle
<a name="globaltables-replication-slr"></a>

Amazon DynamoDB erstellt automatisch die `AWSServiceRoleForDynamoDBReplication` serviceverknüpfte Rolle (SLR), wenn Sie Ihre erste globale Tabelle erstellen. Diese Rolle verwaltet die regionsübergreifende Replikation für Sie.

Wenn Sie ressourcenbasierte Richtlinien auf Replikate anwenden, stellen Sie sicher, dass Sie dem SLR-Prinzipal keine der im SLR-Prinzipal definierten Berechtigungen verweigern, da dadurch die Replikation unterbrochen wird. `AWSServiceRoleForDynamoDBReplicationPolicy` Wenn Sie die erforderlichen SLR-Berechtigungen verweigern, wird die Replikation zu und von den betroffenen Replikaten beendet, und der Status der Replikattabelle ändert sich in `REPLICATION_NOT_AUTHORIZED`.
+ Bei globalen Multi-Region Eventual Consistency (MREC) -Tabellen gilt: Wenn ein Replikat länger als 20 Stunden im `REPLICATION_NOT_AUTHORIZED` Status verbleibt, wird das Replikat unwiderruflich in eine DynamoDB-Tabelle mit nur einer Region konvertiert.
+ Bei globalen Tabellen mit starker Konsistenz in mehreren Regionen (Multiregion Strong Consistency, MRSC) führt das Verweigern der erforderlichen Berechtigungen zu Schreib- und stark konsistenten Lesevorgängen. `AccessDeniedException` Bleibt ein Replikat länger als sieben Tage im `REPLICATION_NOT_AUTHORIZED` Status, kann nicht mehr auf das Replikat zugegriffen werden, und Schreib- und Strongly Consistent-Lesevorgänge schlagen weiterhin mit einem Fehler fehl. Einige Managementoperationen wie das Löschen von Replikaten werden erfolgreich abgeschlossen.

### Mit dem Auto Scaling Service verknüpfte Rolle
<a name="globaltables-autoscaling-slr"></a>

Bei der Konfiguration einer globalen Tabelle für den Modus mit bereitgestellter Kapazität muss Auto Scaling für die globale Tabelle konfiguriert werden. DynamoDB Auto Scaling verwendet den AWS Application Auto Scaling Scaling-Dienst, um die bereitgestellte Durchsatzkapazität auf Ihren globalen Tabellenreplikaten dynamisch anzupassen. Der Application Auto Scaling Scaling-Dienst erstellt eine serviceverknüpfte Rolle (SLR) mit dem Namen. [https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) Diese serviceverknüpfte Rolle wird automatisch in Ihrem AWS Konto erstellt, wenn Sie Auto Scaling für eine DynamoDB-Tabelle zum ersten Mal konfigurieren. Es ermöglicht Application Auto Scaling, die bereitgestellte Tabellenkapazität zu verwalten und CloudWatch Alarme zu erstellen. 

 Achten Sie bei der Anwendung ressourcenbasierter Richtlinien auf Replikate darauf, dass Sie keine im SLR-Prinzipal für Application Auto Scaling definierten Berechtigungen verweigern, da dadurch die Auto Scaling-Funktionalität unterbrochen wird. [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSApplicationAutoscalingDynamoDBTablePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSApplicationAutoscalingDynamoDBTablePolicy.html)

### Beispiel für IAM-Richtlinien für serviceverknüpfte Rollen
<a name="globaltables-example-slr"></a>

Eine IAM-Richtlinie mit der folgenden Bedingung hat keine Auswirkungen auf die erforderlichen Berechtigungen für die DynamoDB-Replikations-SLR und AWS Auto Scaling SLR. Diese Bedingung kann zu ansonsten weitgehend restriktiven Richtlinien hinzugefügt werden, um zu verhindern, dass Replikation oder Auto Scaling unbeabsichtigt unterbrochen werden.

#### Ausgenommen der erforderlichen SLR-Berechtigungen aus den Verweigerungsrichtlinien
<a name="example-exclude-slr-policy"></a>

Das folgende Beispiel zeigt, wie servicebezogene Rollenprinzipale von Deny-Statements ausgeschlossen werden können:

```
"Condition": {
    "StringNotEquals": {
        "aws:PrincipalArn": [
            "arn:aws::iam::111122223333:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication",
            "arn:aws::iam::111122223333:role/aws-service-role/dynamodb.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable"
        ]
    }
}
```

## Wie globale Tabellen IAM verwenden AWS
<a name="globaltables-iam"></a>

In den folgenden Abschnitten werden die erforderlichen Berechtigungen für verschiedene globale Tabellenoperationen beschrieben und Richtlinienbeispiele bereitgestellt, die Ihnen bei der Konfiguration des entsprechenden Zugriffs für Ihre Benutzer und Anwendungen helfen sollen.

**Anmerkung**  
Alle beschriebenen Berechtigungen müssen auf die spezifische Tabellenressource ARN in den betroffenen Regionen angewendet werden. Die Tabellenressource ARN folgt dem Format`arn:aws:dynamodb:region:account-id:table/table-name`, in dem Sie Ihre tatsächlichen Werte für Region, Konto-ID und Tabellennamen angeben müssen.

**Topics**
+ [Globale Tabellen erstellen und Replikate hinzufügen](#globaltables-creation-iam)
+ [Aktualisieren von globalen Tabellen](#globaltables-update-iam)
+ [Löschen globaler Tabellen und Entfernen von Replikaten](#globaltables-delete-iam)

### Globale Tabellen erstellen und Replikate hinzufügen
<a name="globaltables-creation-iam"></a>

Globale DynamoDB-Tabellen unterstützen zwei Konsistenzmodi: Multi-Region Eventual Consistency (MREC) und Multi-Region Strong Consistency (MRSC). Globale MREC-Tabellen können mehrere Replikate in einer beliebigen Anzahl von Regionen enthalten und sorgen so für Konsistenz. Globale MRSC-Tabellen erfordern genau drei Regionen (drei Replikate oder zwei Replikate und ein Zeuge) und bieten eine hohe Konsistenz mit einem Nullpunktziel (RPO).

Die zum Erstellen globaler Tabellen erforderlichen Berechtigungen hängen davon ab, ob Sie eine globale Tabelle mit oder ohne Zeugen erstellen.

#### Berechtigungen für die Erstellung globaler Tabellen
<a name="globaltables-creation-iam-all-types"></a>

Die folgenden Berechtigungen sind sowohl für die anfängliche Erstellung globaler Tabellen als auch für das spätere Hinzufügen von Replikaten erforderlich. Diese Berechtigungen gelten sowohl für globale Tabellen mit Multi-Region Eventual Consistency (MREC) als auch für Multi-Region Strong Consistency (MRSC).
+ Globale Tabellen erfordern eine regionsübergreifende Replikation, die DynamoDB über die [`AWSServiceRoleForDynamoDBReplication`](#globaltables-replication-slr)serviceverknüpfte Rolle (SLR) verwaltet. Die folgende Berechtigung ermöglicht DynamoDB, diese Rolle automatisch zu erstellen, wenn Sie zum ersten Mal eine globale Tabelle erstellen:
  + `iam:CreateServiceLinkedRole`
+ Um mithilfe der [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html)API eine globale Tabelle zu erstellen oder ein Replikat hinzuzufügen, benötigen Sie die folgende Berechtigung für die Quelltabellenressource:
  + `dynamodb:UpdateTable`
+ Sie benötigen die folgenden Berechtigungen für die Tabellenressource in den Regionen, damit die Replikate hinzugefügt werden können:
  + `dynamodb:CreateTable`
  + `dynamodb:CreateTableReplica`
  + `dynamodb:Query`
  + `dynamodb:Scan`
  + `dynamodb:UpdateItem`
  + `dynamodb:PutItem`
  + `dynamodb:GetItem`
  + `dynamodb:DeleteItem`
  + `dynamodb:BatchWriteItem`

#### Zusätzliche Berechtigungen für globale MRSC-Tabellen, die einen Zeugen verwenden
<a name="globaltables-creation-iam-witness"></a>

Wenn Sie eine globale MRSC-Tabelle (Multi-Region Strong Consistency) mit einer Zeugenregion erstellen, benötigen Sie die folgenden Berechtigungen für die Tabellenressource in allen beteiligten Regionen (einschließlich der Replikatregionen und der Zeugenregion):
+ `dynamodb:CreateGlobalTableWitness`

#### Beispiel für IAM-Richtlinien zum Erstellen globaler Tabellen
<a name="globaltables-creation-iam-example"></a>

##### Erstellung einer globalen MREC- oder MRSC-Tabelle für drei Regionen
<a name="globaltables-creation-iam-example-three-regions"></a>

Die folgende identitätsbasierte Richtlinie ermöglicht es Ihnen, eine globale MREC- oder MRSC-Tabelle mit dem Namen „users“ in drei Regionen zu erstellen, einschließlich der Erstellung der erforderlichen mit dem DynamoDB-Replikationsdienst verknüpften Rolle.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCreatingUsersGlobalTable",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateTable",
        "dynamodb:CreateTableReplica",
        "dynamodb:UpdateTable",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:UpdateItem",
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/users",
        "arn:aws:dynamodb:us-east-2:123456789012:table/users",
        "arn:aws:dynamodb:us-west-2:123456789012:table/users"
      ]
    },
    {
      "Sid": "AllowCreatingSLR",
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication"
      ]
    }
  ]
}
```

------

##### Beschränken Sie die Erstellung globaler MREC- oder MRSC-Tabellen auf bestimmte Regionen
<a name="globaltables-creation-iam-example-restrict-regions"></a>

Die folgende identitätsbasierte Richtlinie ermöglicht es Ihnen, mithilfe des RequestedRegion Bedingungsschlüssels [aws:](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion) globale DynamoDB-Tabellen in bestimmten Regionen zu erstellen, einschließlich der Erstellung der erforderlichen mit dem DynamoDB-Replikationsdienst verknüpften Rolle.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowAddingReplicasToSourceTable",
      "Effect": "Allow",
      "Action": [
        "dynamodb:UpdateTable"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-1"
          ]
        }
      }
    },
    {
      "Sid": "AllowCreatingReplicas",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateTable",
        "dynamodb:CreateTableReplica",
        "dynamodb:UpdateTable",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:UpdateItem",
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-2",
            "us-west-2"
          ]
        }
      }
    },
    {
      "Sid": "AllowCreatingSLR",
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication"
      ]
    }
  ]
}
```

------

##### Erstellen einer globalen MRSC-Tabelle mit Zeuge
<a name="globaltables-creation-iam-example-witness"></a>

Die folgende identitätsbasierte Richtlinie ermöglicht es Ihnen, eine globale DynamoDB-MRSC-Tabelle mit dem Namen „users“ mit Replikaten in us-east-1 und us-east-2 und einem Zeugen in us-west-2 zu erstellen, einschließlich der Erstellung der erforderlichen mit dem DynamoDB-Replikationsdienst verknüpften Rolle.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCreatingUsersGlobalTableWithWitness",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateTable",
        "dynamodb:CreateTableReplica",
        "dynamodb:CreateGlobalTableWitness",
        "dynamodb:UpdateTable",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:UpdateItem",
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/users",
        "arn:aws:dynamodb:us-east-2:123456789012:table/users"
      ]
    },
    {
      "Sid": "AllowCreatingSLR",
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication"
      ]
    }
  ]
}
```

------

##### Beschränkung der Erstellung von MRSC-Zeugen auf bestimmte Regionen
<a name="globaltables-creation-iam-example-restrict-witness-regions"></a>

Diese identitätsbasierte Richtlinie ermöglicht es Ihnen, eine globale MRSC-Tabelle mit Replikaten zu erstellen, die auf bestimmte Regionen beschränkt sind, indem Sie den RequestedRegion Bedingungsschlüssel [aws:](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion) verwenden und uneingeschränkte Zeugenerstellung für alle Regionen verwenden, einschließlich der Erstellung der erforderlichen, mit dem DynamoDB-Replikationsdienst verknüpften Rolle.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCreatingReplicas",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateTable",
        "dynamodb:CreateTableReplica",
        "dynamodb:UpdateTable",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:UpdateItem",
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-east-2"
          ]
        }
      }
    },
    {
      "Sid": "AllowCreatingWitness",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateGlobalTableWitness"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowCreatingSLR",
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication"
      ]
    }
  ]
}
```

------

### Aktualisieren von globalen Tabellen
<a name="globaltables-update-iam"></a>

Um die Replikateinstellungen für eine bestehende globale Tabelle mithilfe der [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html)API zu ändern, benötigen Sie die folgende Berechtigung für die Tabellenressource in der Region, in der Sie den API-Aufruf tätigen:
+ `dynamodb:UpdateTable`

Sie können auch andere globale Tabellenkonfigurationen aktualisieren, z. B. Richtlinien für auto Skalierung und Time-to-Live-Einstellungen. Für diese zusätzlichen Aktualisierungsvorgänge sind die folgenden Berechtigungen erforderlich:
+ Um eine Replica-Auto-Scaling-Richtlinie mit der [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTableReplicaAutoScaling.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTableReplicaAutoScaling.html)API zu aktualisieren, benötigen Sie die folgenden Berechtigungen für die Tabellenressource in allen Regionen, die Replikate enthalten:
  + `application-autoscaling:DeleteScalingPolicy`
  + `application-autoscaling:DeleteScheduledAction`
  + `application-autoscaling:DeregisterScalableTarget`
  + `application-autoscaling:DescribeScalableTargets`
  + `application-autoscaling:DescribeScalingActivities`
  + `application-autoscaling:DescribeScalingPolicies`
  + `application-autoscaling:DescribeScheduledActions`
  + `application-autoscaling:PutScalingPolicy`
  + `application-autoscaling:PutScheduledAction`
  + `application-autoscaling:RegisterScalableTarget`
+ Um die Time-to-Live-Einstellungen mit der [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTimeToLive.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTimeToLive.html)API zu aktualisieren, benötigen Sie die folgenden Berechtigungen für die Tabellenressource in allen Regionen, die Replikate enthalten:
  + `dynamodb:UpdateTimeToLive`

  Beachten Sie, dass Time to Live (TTL) nur für globale Tabellen unterstützt wird, die mit Multi-Region Eventual Consistency (MREC) konfiguriert sind. Weitere Informationen zur Funktionsweise globaler Tabellen mit TTL finden Sie unter [So funktionieren globale DynamoDB-Tabellen](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.html).

### Löschen globaler Tabellen und Entfernen von Replikaten
<a name="globaltables-delete-iam"></a>

Um eine globale Tabelle zu löschen, müssen Sie alle Replikate entfernen. Die für diesen Vorgang erforderlichen Berechtigungen hängen davon ab, ob Sie eine globale Tabelle mit oder ohne Zeugenregion löschen.

#### Berechtigungen zum Löschen globaler Tabellen und zum Entfernen von Replikaten
<a name="globaltables-delete-iam-all-types"></a>

Die folgenden Berechtigungen sind sowohl für das Entfernen einzelner Replikate als auch für das vollständige Löschen globaler Tabellen erforderlich. Durch das Löschen einer globalen Tabellenkonfiguration wird nur die Replikationsbeziehung zwischen Tabellen in verschiedenen Regionen entfernt. Die zugrunde liegende DynamoDB-Tabelle in der letzten verbleibenden Region wird nicht gelöscht. Die Tabelle in der letzten Region existiert weiterhin als standardmäßige DynamoDB-Tabelle mit denselben Daten und Einstellungen. Diese Berechtigungen gelten sowohl für globale Tabellen mit Multi-Region Eventual Consistency (MREC) als auch für Multi-Region Strong Consistency (MRSC). 
+ Um mithilfe der [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html)API Replikate aus einer globalen Tabelle zu entfernen, benötigen Sie die folgende Berechtigung für die Tabellenressource in der Region, von der aus Sie den API-Aufruf tätigen:
  + `dynamodb:UpdateTable`
+ Sie benötigen die folgenden Berechtigungen für die Tabellenressource in jeder Region, in der Sie ein Replikat entfernen:
  + `dynamodb:DeleteTable`
  + `dynamodb:DeleteTableReplica`

#### Zusätzliche Berechtigungen für globale MRSC-Tabellen, die einen Zeugen verwenden
<a name="globaltables-delete-iam-witness"></a>

Um eine globale MRSC-Tabelle (Multiregion Strong Consistency) mit einem Zeugen zu löschen, benötigen Sie in allen beteiligten Regionen (einschließlich der Replikatregionen und der Zeugenregion) die folgenden Berechtigungen für die Tabellenressource:
+ `dynamodb:DeleteGlobalTableWitness`

#### Beispiele für IAM-Richtlinien zum Löschen globaler Tabellenreplikate
<a name="globaltables-delete-iam-example"></a>

##### Löschen globaler Tabellenreplikate
<a name="globaltables-delete-replicas-iam-example"></a>

Diese identitätsbasierte Richtlinie ermöglicht es Ihnen, eine globale DynamoDB-Tabelle mit dem Namen „users“ und ihre Replikate in drei Regionen zu löschen:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:UpdateTable",
        "dynamodb:DeleteTable",
        "dynamodb:DeleteTableReplica"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/users",
        "arn:aws:dynamodb:us-east-2:123456789012:table/users",
        "arn:aws:dynamodb:us-west-2:123456789012:table/users"
      ]
    }
  ]
}
```

------

##### Löschen einer globalen MRSC-Tabelle mit einem Zeugen
<a name="globaltables-delete-witness-iam-example"></a>

Mit dieser identitätsbasierten Richtlinie können Sie das Replikat und den Zeugen einer globalen MRSC-Tabelle mit dem Namen „users“ löschen:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:UpdateTable",
        "dynamodb:DeleteTable",
        "dynamodb:DeleteTableReplica",
        "dynamodb:DeleteGlobalTableWitness"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/users",
        "arn:aws:dynamodb:us-east-2:123456789012:table/users"
      ]
    }
  ]
}
```

------

## Wie verwenden globale Tabellen AWS KMS
<a name="globaltables-kms"></a>

Wie alle DynamoDB-Tabellen verschlüsseln Replikate Daten im Ruhezustand immer mit Verschlüsselungsschlüsseln, die im AWS Key Management Service () gespeichert sind.AWS KMS

Alle Replikate in einer globalen Tabelle müssen mit demselben Typ von KMS-Schlüssel (AWS -eigener Schlüssel, von AWS verwalteter Schlüssel oder kundenseitig verwalteter Schlüssel) konfiguriert werden.

**Wichtig**  
DynamoDB benötigt Zugriff auf den Verschlüsselungsschlüssel des Replikats, um ein Replikat zu löschen. Wenn Sie einen kundenseitig verwalteten Schlüssel, der zur Verschlüsselung eines Replikats verwendet wird, deaktivieren oder löschen möchten, weil Sie das Replikat löschen, sollten Sie zuerst das Replikat löschen, warten, bis sich der Tabellenstatus in einem der verbleibenden Replikate in `ACTIVE` ändert, und dann den Schlüssel deaktivieren oder löschen.

Wenn Sie bei einer globalen MREC-Tabelle den Zugriff von DynamoDB auf einen kundenseitig verwalteten Schlüssel, der zur Verschlüsselung eines Replikats verwendet wird, deaktivieren oder entziehen, wird die Replikation zum und vom Replikat beendet und der Replikatstatus ändert sich in `INACCESSIBLE_ENCRYPTION_CREDENTIALS`. Wenn ein Replikat in einer globalen MREC-Tabelle länger als 20 Stunden im Status `INACCESSIBLE_ENCRYPTION_CREDENTIALS` verbleibt, wird das Replikat unwiderruflich in eine DynamoDB-Tabelle mit einer einzelnen Region konvertiert.

Wenn Sie bei einer globalen MRSC-Tabelle den Zugriff von DynamoDB auf einen kundenseitig verwalteten Schlüssel, der zur Verschlüsselung eines Replikats verwendet wird, deaktivieren oder entziehen, wird die Replikation zum und vom Replikat beendet, bei dem Versuch, strikt konsistente Lesevorgänge in das Replikat zu schreiben, tritt ein Fehler auf, und der Replikatstatus ändert sich in `INACCESSIBLE_ENCRYPTION_CREDENTIALS`. Wenn ein Replikat in einer globalen MRSC-Tabelle länger als sieben Tage im `INACCESSIBLE_ENCRYPTION_CREDENTIALS` Status verbleibt, wird das Replikat je nach den widerrufenen Berechtigungen archiviert oder es kann dauerhaft nicht mehr darauf zugegriffen werden.

# DynamoDB-Tabellen für mehrere Konten
<a name="globaltables-MultiAccount"></a>

Globale Tabellen mit mehreren Konten replizieren Ihre DynamoDB-Tabellendaten automatisch über mehrere AWS Regionen und mehrere AWS Konten hinweg, um die Ausfallsicherheit zu verbessern, Workloads auf Kontoebene zu isolieren und unterschiedliche Sicherheits- und Governance-Kontrollen anzuwenden. Jede Replikattabelle befindet sich in einem eigenen AWS Konto, wodurch eine Fehlerisolierung sowohl auf Regions- als auch auf Kontoebene ermöglicht wird. Sie können Replikate auch an Ihre AWS Organisationsstruktur anpassen. Globale Tabellen mit mehreren Konten bieten zusätzliche Isolations-, Verwaltungs- und Sicherheitsvorteile im Vergleich zu globalen Tabellen mit demselben Konto.

Globale Tabellen mit mehreren Konten bieten die folgenden Vorteile:
+ Automatisches Replizieren von DynamoDB-Tabellendaten für Konten und Regionen Ihrer AWS Wahl
+ Verbessern Sie Sicherheit und Governance, indem Sie Daten kontenübergreifend mit unterschiedlichen Richtlinien, Richtlinien und Compliance-Grenzen replizieren
+ Verbessern Sie die betriebliche Stabilität und die Fehlerisolierung auf Kontoebene, indem Sie Replikate auf separaten Konten platzieren AWS 
+ Richten Sie die Workloads nach Geschäftseinheit oder Eigentümer aus, wenn Sie eine Strategie für mehrere Konten verwenden
+ Vereinfachen Sie die Kostenzuweisung, indem Sie jedes Replikat seinem jeweiligen Konto in Rechnung stellen AWS 

Weitere Informationen finden Sie unter [Vorteile der Verwendung mehrerer AWS Konten](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html). Wenn für Ihre Workloads keine Replikation mehrerer Konten erforderlich ist oder Sie eine einfachere Replikatverwaltung mit lokalen Überschreibungen wünschen, können Sie weiterhin globale Tabellen mit demselben Konto verwenden.

Sie können globale Tabellen mit mehreren Konten konfigurieren. [Multi-Region Eventual Consistency (MREC)](V2globaltables_HowItWorks.md#V2globaltables_HowItWorks.consistency-modes.mrec) Für konfigurierte globale Tabellen unterstützen das Modell mit mehreren Konten [Multi-Region Strong Consistency (MRSC)](V2globaltables_HowItWorks.md#V2globaltables_HowItWorks.consistency-modes.mrsc) nicht.

**Topics**
+ [So funktionieren globale DynamoDB-Tabellen](V2globaltables_MA_HowItWorks.md)
+ [Tutorials: Globale Tabellen mit mehreren Konten erstellen](V2globaltables_MA.tutorial.md)
+ [Sicherheit von globalen DynamoDB-Tabellen](globaltables_MA_security.md)

# So funktionieren globale DynamoDB-Tabellen
<a name="V2globaltables_MA_HowItWorks"></a>

Globale Tabellen mit mehreren Konten erweitern die vollständig verwalteten, serverlosen, regionsübergreifenden und multiaktiven Funktionen von DynamoDB auf mehrere Konten. AWS Globale Tabellen mit mehreren Konten replizieren Daten über AWS Regionen und Konten hinweg und bieten dieselbe aktive/aktive Funktionalität wie globale Tabellen mit demselben Konto. Wenn Sie in ein Replikat schreiben, repliziert DynamoDB die Daten auf alle anderen Replikate.

Zu den wichtigsten Unterschieden zu globalen Tabellen mit demselben Konto gehören:
+ Die Replikation mehrerer Konten wird für globale Tabellen mit Multi-Region Eventual Consistency (MREC) unterstützt.
+ Sie können Replikate nur hinzufügen, indem Sie mit einer Tabelle mit einer einzigen Region beginnen. Die Konvertierung einer vorhandenen globalen Tabelle mit demselben Konto in eine Konfiguration mit mehreren Konten wird nicht unterstützt. Um zu migrieren, müssen Sie vorhandene Replikate löschen, um zu einer Tabelle mit nur einer Region zurückzukehren, bevor Sie eine neue globale Tabelle mit mehreren Konten erstellen.
+ Jedes Replikat muss sich in einem separaten Konto befinden. AWS *Für eine globale Tabelle mit mehreren Konten und *N* Replikaten benötigen Sie N Konten.*
+ Globale Tabellen mit mehreren Konten verwenden standardmäßig einheitliche Tabelleneinstellungen für alle Replikate. Alle Replikate verwenden automatisch dieselbe Konfiguration (wie Durchsatzmodus und TTL), und im Gegensatz zu globalen Tabellen mit demselben Konto können diese Einstellungen nicht pro Replikat außer Kraft gesetzt werden.
+ Kunden müssen in ihren Ressourcenrichtlinien Replikationsberechtigungen für den DynamoDB-Dienstprinzipal für globale Tabellen bereitstellen.

Globale Tabellen mit mehreren Konten verwenden dieselbe zugrunde liegende Replikationstechnologie wie globale Tabellen mit demselben Konto. Tabelleneinstellungen werden automatisch auf alle regionalen Replikate repliziert, und Kunden können die Einstellungen nicht für jedes Replikat überschreiben oder anpassen. Dies gewährleistet eine konsistente Konfiguration und ein vorhersehbares Verhalten für mehrere AWS Konten, die an derselben globalen Tabelle teilnehmen.

Einstellungen in globalen DynamoDB-Tabellen definieren, wie sich eine Tabelle verhält und wie Daten regionsübergreifend repliziert werden. Diese Einstellungen werden während der Tabellenerstellung oder APIs beim Hinzufügen eines neuen regionalen Replikats über die DynamoDB-Steuerebene konfiguriert.

Bei der Erstellung einer globalen Tabelle mit mehreren Konten müssen Kunden `GlobalTableSettingsReplicationMode = ENABLED` für jedes regionale Replikat Einstellungen vornehmen. Dadurch wird sichergestellt, dass in einer Region vorgenommene Konfigurationsänderungen automatisch auf alle anderen Regionen übertragen werden, die Teil der globalen Tabelle sind.

Sie können die Replikation der Einstellungen nach der Tabellenerstellung aktivieren. Dies unterstützt das Szenario, in dem eine Tabelle ursprünglich als regionale Tabelle erstellt und später zu einer globalen Tabelle mit mehreren Konten aktualisiert wurde.

**Synchronisierte Einstellungen**

Die folgenden Tabelleneinstellungen werden immer für alle Replikate in einer globalen Tabelle mit mehreren Konten synchronisiert:

**Anmerkung**  
Im Gegensatz zu globalen Tabellen mit demselben Konto lassen globale Tabellen mit mehreren Konten keine regionsspezifischen Überschreibungen für diese Einstellungen zu. Die einzige Ausnahme besteht darin, dass Überschreibungen für Richtlinien zur auto-scaling von Lesevorgängen (Tabellen und GSIs) zulässig sind, da es sich um separate externe Ressourcen handelt.
+ Kapazitätsmodus (bereitgestellte oder On-Demand-Kapazität)
+ Von der Tabelle bereitgestellte Lese- und Schreibkapazität
+ auto Skalierung beim Lesen und Schreiben von Tabellen
+ Definition des lokalen sekundären Index (LSI)
+ Definition des globalen sekundären Index (GSI)
+ Von GSI bereitgestellte Lese- und Schreibkapazität
+ GSI Auto Scaling mit Lese- und Schreibzugriff
+ Streams-Definition im MREC-Modus
+ Time to Live (TTL)
+ Warmdurchsatz
+ Maximaler Lese- und Schreibdurchsatz auf Abruf

**Nicht synchronisierte Einstellungen**

Die folgenden Einstellungen werden nicht zwischen Replikaten synchronisiert und müssen für jede Replikattabelle in jeder Region unabhängig konfiguriert werden.
+ Tabellenklasse
+ Typ der serverseitigen Verschlüsselung (Server-Side Encryption, SSE)
+ Point-in-time Wiederherstellung
+ KMS-Schlüssel-ID für serverseitige Verschlüsselung (SSE)
+ Löschschutz
+ Kinesis Data Streams (KDSD)
+ Tags (Markierungen)
+ Ressourcenrichtlinie
+ Tabelle Cloudwatch-Contributor Insights (CCI)
+ Einblicke in GSI Cloudwatch Contributor (CCI)

## Überwachen
<a name="V2globaltables_MA_HowItWorks.monitoring"></a>

In globalen Tabellen, die für Multi-Region Eventual Consistency (MREC) konfiguriert sind, wird die Metrik veröffentlicht. [`ReplicationLatency`](metrics-dimensions.md#ReplicationLatency) CloudWatch Diese Metrik misst die verstrichene Zeit zwischen dem Schreiben eines Elements in eine Replikattabelle und dem Erscheinen dieses Elements in einem anderen Replikat in der globalen Tabelle. `ReplicationLatency` wird in Millisekunden ausgedrückt und für jedes Paar aus Quell- und Zielregion ausgegeben.

Typische `ReplicationLatency` Werte hängen von der Entfernung zwischen den ausgewählten AWS Regionen sowie von anderen Variablen wie Workload-Typ und Durchsatz ab. Beispiel: Ein Quellreplikat in der Region USA West (Nordkalifornien) (us-west-1) weist im Vergleich zur Region Afrika (Kapstadt) (af-south-1) einen niedrigeren Wert für `ReplicationLatency` auf als die Region USA West (Oregon) (us-west-2).

Ein erhöhter Wert für `ReplicationLatency` könnte darauf hinweisen, dass Updates von einem Replikat nicht in einem angemessenen Zeitraum an andere Replikattabellen verteilt werden. In diesem Fall können Sie die Lese- und Schreibaktivität Ihrer Anwendung vorübergehend in eine andere AWS Region umleiten.

**Behandlung von Problemen mit der Replikationslatenz in globalen Tabellen mit mehreren Konten**

Wenn aufgrund von vom Kunden verursachten Problemen mit einer Replikattabelle `ReplicationLatency` mehr als 3 Stunden vergangen sind, sendet DynamoDB eine Benachrichtigung, in der der Kunde aufgefordert wird, das zugrunde liegende Problem zu beheben. Zu den häufigsten kundenbedingten Problemen, die eine Replikation verhindern können, gehören:
+ Entfernen der erforderlichen Berechtigungen aus der Ressourcenrichtlinie der Replikattabelle
+ Abmeldung von einer AWS Region, in der ein Replikat der globalen Tabelle mit mehreren Konten gehostet wird
+ Verweigerung der zum Entschlüsseln von Daten erforderlichen AWS KMS-Schlüsselberechtigungen für die Tabelle

DynamoDB sendet innerhalb von 3 Stunden bei erhöhter Replikationslatenz eine erste Benachrichtigung, gefolgt von einer zweiten Benachrichtigung nach 20 Stunden, falls das Problem weiterhin besteht. Wenn das Problem nicht innerhalb des erforderlichen Zeitfensters behoben wird, trennt DynamoDB das Replikat automatisch von der globalen Tabelle. Das betroffene Replikat wird dann in eine regionale Tabelle konvertiert.

# Tutorials: Globale Tabellen mit mehreren Konten erstellen
<a name="V2globaltables_MA.tutorial"></a>

Dieser Abschnitt enthält step-by-step Anweisungen zum Erstellen globaler DynamoDB-Tabellen, die sich über mehrere AWS Konten erstrecken.

## Erstellen Sie mit der DynamoDB-Konsole eine globale Tabelle mit mehreren Konten
<a name="create-ma-gt-console"></a>

Gehen Sie wie folgt vor, um eine globale Tabelle mit mehreren Konten mithilfe von zu erstellen. AWS-Managementkonsole Im folgenden Beispiel wird eine globale Tabelle mit Replikattabellen in den Vereinigte Staaten erstellt.

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)für das erste Konto (sagen wir*111122223333*).

1. Wählen Sie für dieses Beispiel in der Regionsauswahl in der Navigationsleiste die Region **USA Ost (Ohio)** aus.

1. Klicken Sie im Navigationsbereich auf der linken Seite der Konsole auf **Tabellen**.

1. Wählen Sie **Tabelle erstellen** aus.

1. Gehen Sie auf der Seite **Tabelle erstellen** wie folgt vor:

   1. Geben Sie unter **Tabellenname** **MusicTable** ein.

   1. Geben Sie unter **Partitionsschlüssel** den Wert **Artist** ein.

   1. Geben Sie unter **(Sortierschlüssel)** den Wert **SongTitle** ein.

   1. Behalten Sie die übrigen Standardeinstellungen bei und wählen Sie **Tabelle erstellen** aus.

1. Fügen Sie der Tabelle die folgende Ressourcenrichtlinie hinzu

------
#### [ JSON ]

****  

   ```
   {
   "Version":"2012-10-17",		 	 	 
   "Statement": [
       {
           "Sid": "DynamoDBActionsNeededForSteadyStateReplication",
           "Effect": "Allow",
           "Action": [
               "dynamodb:ReadDataForReplication",
               "dynamodb:WriteDataForReplication",
               "dynamodb:ReplicateSettings"
           ],
           "Resource": "arn:aws:dynamodb:us-east-2:111122223333:table/MusicTable",
           "Principal": {"Service": ["replication.dynamodb.amazonaws.com"]},
           "Condition": {
               "StringEquals": {
                   "aws:SourceAccount": ["444455556666","111122223333"],
                   "aws:SourceArn": [
                       "arn:aws:dynamodb:us-east-1:444455556666:table/MusicTable",
                       "arn:aws:dynamodb:us-east-2:111122223333:table/MusicTable"
                   ]
               }
           }
       },
       {
           "Sid": "AllowTrustedAccountsToJoinThisGlobalTable",
           "Effect": "Allow",
           "Action": [
               "dynamodb:AssociateTableReplica"
           ],
           "Resource": "arn:aws:dynamodb:us-east-2:111122223333:table/MusicTable",
           "Principal": {"AWS": ["444455556666"]}
       }
   ]
   }
   ```

------

1. Diese neue Tabelle dient als erste Replikattabelle in einer neuen globalen Tabelle. Sie stellt den Prototyp für andere Replikattabellen dar, die Sie später hinzufügen.

1. Warten Sie, bis die Tabelle **aktiv** wird. Navigieren Sie für die neu erstellte Tabelle auf der Registerkarte **Globale Tabellen** zu **Einstellungen > Replikation** und klicken Sie auf **Aktivieren**.

1. Melden Sie sich von diesem Konto ab (*111122223333*hier).

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)für das zweite Konto (z. B.). *444455556666*

1. Wählen Sie für dieses Beispiel in der Navigationsleiste in der Regionsauswahl die Option **US East (Nord-Virginia)** aus.

1. Die Konsole stellt sicher, dass die ausgewählte Region keine Tabelle mit demselben Namen enthält. Wenn eine Tabelle mit demselben Namen vorhanden ist, müssen Sie die vorhandene Tabelle löschen, bevor Sie eine neue Replikattabelle in der betreffenden Region erstellen können.

1. Wählen Sie in der Dropdownliste neben **Tabelle erstellen** die Option **Aus einem anderen Konto erstellen**

1. Gehen Sie auf der Seite **Tabelle aus einem anderen Konto erstellen** wie folgt vor:

   1. Fügen Sie **arn:aws:dynamodb:us-east-2:*111122223333*:table/MusicTable** als Tabelle arn für die Quelltabelle hinzu.

   1. Fügen Sie in der **Replikattabelle ARNs** erneut **arn:aws:dynamodb:us-east-2:*111122223333*:table/MusicTable** den ARN der Quelltabelle hinzu. Wenn bereits mehrere Replikate als Teil einer globalen Tabelle mit mehreren Konten vorhanden sind, müssen Sie jedes vorhandene Replikat dem ReplicaTable ARN hinzufügen.

   1. **Behalten Sie die anderen Standardeinstellungen bei und wählen Sie Submit.**

1. Auf der Registerkarte „**Globale Tabellen**“ für die Tabelle „Musik“ (und für alle anderen Replikattabellen) wird angezeigt, dass die Tabelle in mehreren Regionen repliziert wurde.

1. So testen Sie die Replikation:

   1. Sie können jede Region, in der ein Replikat vorhanden ist, für diese Tabelle verwenden

   1. Wählen Sie **Tabellenelemente erkunden** aus.

   1. Wählen Sie **Element erstellen** aus.

   1. Geben Sie **item\$11** für **Künstler** und **Song Value 1** für ein **SongTitle**.

   1. Wählen Sie **Element erstellen** aus.

   1. Überprüfen Sie die Replikation, indem Sie zu den anderen Regionen wechseln:

   1. Vergewissern Sie sich, dass die Tabelle Music das von Ihnen erstellte Objekt enthält.

## Erstellen Sie eine globale Tabelle mit mehreren Konten mithilfe der AWS CLI
<a name="ma-gt-cli"></a>

Die folgenden Beispiele zeigen, wie Sie mit dem eine globale Tabelle mit mehreren Konten erstellen. AWS CLI Diese Beispiele veranschaulichen den vollständigen Arbeitsablauf für die Einrichtung der kontenübergreifenden Replikation.

------
#### [ CLI ]

Verwenden Sie die folgenden AWS CLI Befehle, um eine globale Tabelle mit mehreren Konten und kontenübergreifender Replikation zu erstellen.

```
# STEP 1: Setting resource policy for the table in account 111122223333

cat > /tmp/source-resource-policy.json << 'EOF'
{
    "Version": "2012-10-17", 		 	 	 
    "Statement": [
        {
            "Sid": "DynamoDBActionsNeededForSteadyStateReplication",
            "Effect": "Allow",
            "Action": [
                "dynamodb:ReadDataForReplication",
                "dynamodb:WriteDataForReplication",
                "dynamodb:ReplicateSettings"
            ],
            "Resource": "arn:aws:dynamodb:us-east-2:111122223333:table/MusicTable",
            "Principal": {"Service": ["replication.dynamodb.amazonaws.com"]},
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": ["444455556666","111122223333"],
                    "aws:SourceArn": [
                        "arn:aws:dynamodb:us-east-1:444455556666:table/MusicTable",
                        "arn:aws:dynamodb:us-east-2:111122223333:table/MusicTable"
                    ]
                }
            }
        },
        {
            "Sid": "AllowTrustedAccountsToJoinThisGlobalTable",
            "Effect": "Allow",
            "Action": [
                "dynamodb:AssociateTableReplica"
            ],
            "Resource": "arn:aws:dynamodb:us-east-2:111122223333:table/MusicTable",
            "Principal": {"AWS": ["444455556666"]}
        }
    ]
}
EOF

# Step 2: Create a new table (MusicTable) in US East (Ohio), 
#   with DynamoDB Streams enabled (NEW_AND_OLD_IMAGES),
#   and Settings Replication ENABLED on the account 111122223333

aws dynamodb create-table \
    --table-name MusicTable \
    --attribute-definitions \
        AttributeName=Artist,AttributeType=S \
        AttributeName=SongTitle,AttributeType=S \
    --key-schema \
        AttributeName=Artist,KeyType=HASH \
        AttributeName=SongTitle,KeyType=RANGE \
    --billing-mode PAY_PER_REQUEST \
    --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
    --global-table-settings-replication-mode ENABLED \
    --resource-policy file:///tmp/source-resource-policy.json \
    --region us-east-2 


# Step 3: Creating replica table in account 444455556666

# Resource policy for account 444455556666
cat > /tmp/dest-resource-policy.json << 'EOF'
{
    "Version": "2012-10-17", 		 	 	 
    "Statement": [
        {
            "Sid": "DynamoDBActionsNeededForSteadyStateReplication",
            "Effect": "Allow",
            "Action": [
                "dynamodb:ReadDataForReplication",
                "dynamodb:WriteDataForReplication",
                "dynamodb:ReplicateSettings"
            ],
            "Resource": "arn:aws:dynamodb:us-east-1:444455556666:table/MusicTable",
            "Principal": {"Service": ["replication.dynamodb.amazonaws.com"]},
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": ["444455556666","111122223333"],
                    "aws:SourceArn": [
                        "arn:aws:dynamodb:us-east-1:444455556666:table/MusicTable",
                        "arn:aws:dynamodb:us-east-2:111122223333:table/MusicTable"
                    ]
                }
            }
        }
    ]
}
EOF

# Execute the replica table creation
aws dynamodb create-table \
    --table-name MusicTable \
    --global-table-source-arn "arn:aws:dynamodb:us-east-2:111122223333:table/MusicTable" \
    --resource-policy file:///tmp/dest-resource-policy.json \
    --global-table-settings-replication-mode ENABLED \
    --region us-east-1

# Step 4: View the list of replicas created using describe-table
aws dynamodb describe-table \
    --table-name MusicTable \
    --region us-east-2 \
    --query 'Table.{TableName:TableName,TableStatus:TableStatus,MultiRegionConsistency:MultiRegionConsistency,Replicas:Replicas[*].{Region:RegionName,Status:ReplicaStatus}}'

# Step 5: To verify that replication is working, add a new item to the Music table in US East (Ohio)
aws dynamodb put-item \
    --table-name MusicTable \
    --item '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
    --region us-east-2

# Step 6: Wait for a few seconds, and then check to see whether the item has been 
# successfully replicated to US East (N. Virginia) and Europe (Ireland)
aws dynamodb get-item \
    --table-name MusicTable \
    --key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
    --region us-east-1

aws dynamodb get-item \
    --table-name MusicTable \
    --key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
    --region us-east-2

# Step 7: Delete the replica table in US East (N. Virginia) Region
aws dynamodb delete-table \
    --table-name MusicTable \
    --region us-east-1

# Clean up: Delete the primary table
aws dynamodb delete-table \
    --table-name MusicTable \
    --region us-east-2
```

------

# Sicherheit von globalen DynamoDB-Tabellen
<a name="globaltables_MA_security"></a>

Globale Tabellenreplikate sind DynamoDB-Tabellen. Sie verwenden also dieselben Methoden zur Steuerung des Zugriffs auf Replikate wie für Tabellen mit einer einzelnen Region, einschließlich AWS Identity and Access Management (IAM-) Identitätsrichtlinien und ressourcenbasierter Richtlinien. In diesem Thema wird beschrieben, wie Sie globale DynamoDB-Tabellen mit mehreren Konten mithilfe von IAM-Berechtigungen und AWS Key Management Service () -Verschlüsselung sichern.AWS KMS Sie erfahren mehr über die ressourcenbasierten Richtlinien und serviceverknüpften Rollen (SLR), die eine regionsübergreifende kontenübergreifende Replikation und auto-scaling ermöglichen, sowie über die IAM-Berechtigungen, die zum Erstellen, Aktualisieren und Löschen globaler Tabellen für MREC-Tabellen (Multi-Region Eventual Consistency) erforderlich sind. Außerdem erfahren Sie mehr über Verschlüsselungsschlüssel, mit denen Sie die regionsübergreifende Replikation sicher verwalten können. AWS KMS 

Es enthält detaillierte Informationen zu den ressourcenbasierten Richtlinien und Berechtigungen, die für die Einrichtung der konto- und regionsübergreifenden Tabellenreplikation erforderlich sind. Das Verständnis dieses Sicherheitsmodells ist für Kunden, die sichere, kontoübergreifende Datenreplikationslösungen implementieren müssen, von entscheidender Bedeutung.

## Serviceprinzipalautorisierung für die Replikation
<a name="globaltables_MA_service_principal"></a>

Die globalen Tabellen von DynamoDB mit mehreren Konten verwenden einen eigenen Autorisierungsansatz, da die Replikation über Kontogrenzen hinweg durchgeführt wird. Dies erfolgt mithilfe des Replikationsdienstprinzipals von DynamoDB:. `replication.dynamodb.amazonaws.com` Jedes teilnehmende Konto muss diesen Prinzipal in der Ressourcenrichtlinie der Replikattabelle explizit zulassen und ihm damit Berechtigungen geben, die durch Quellkontextbedingungen für Schlüssel wie`aws:SourceAccount`, `aws:SourceArn` usw. auf bestimmte Replikate beschränkt werden können. Weitere Informationen finden Sie unter [AWS globale Bedingungsschlüssel](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html). Die Berechtigungen sind bidirektional, was bedeutet, dass sich alle Replikate gegenseitig ausdrücklich Berechtigungen gewähren müssen, bevor die Replikation für ein bestimmtes Replikatpaar eingerichtet werden kann.

Die folgenden Dienstprinzipalberechtigungen sind für die kontenübergreifende Replikation unerlässlich:
+ `dynamodb:ReadDataForReplication`gewährt die Möglichkeit, Daten für Replikationszwecke zu lesen. Mit dieser Berechtigung können Änderungen an einem Replikat gelesen und an andere Replikate weitergegeben werden.
+ `dynamodb:WriteDataForReplication`ermöglicht das Schreiben replizierter Daten in Zieltabellen. Mit dieser Berechtigung können Änderungen zwischen allen Replikaten in der globalen Tabelle synchronisiert werden.
+ `dynamodb:ReplicateSettings`ermöglicht die Synchronisation von Tabelleneinstellungen zwischen Replikaten und sorgt so für eine konsistente Konfiguration in allen beteiligten Tabellen.

Jedes Replikat muss allen anderen Replikaten und sich selbst die oben genannten Berechtigungen gewähren — d. h. die Quellkontextbedingungen müssen den gesamten Satz von Replikaten umfassen, aus dem die globale Tabelle besteht. Diese Berechtigungen werden für jedes neue Replikat überprüft, wenn es zu einer globalen Tabelle mit mehreren Konten hinzugefügt wird. Dadurch wird überprüft, ob Replikationsvorgänge nur vom autorisierten DynamoDB-Dienst und nur zwischen den vorgesehenen Tabellen ausgeführt werden.

## Mit Diensten verknüpfte Rollen für globale Tabellen mit mehreren Konten
<a name="globaltables_MA_service_linked_roles"></a>

DynamoDB-Tabellen mit mehreren Konten replizieren Einstellungen über alle Replikate hinweg, sodass jedes Replikat identisch eingerichtet wird, einen konsistenten Durchsatz aufweist und ein nahtloses Failover-Erlebnis bietet. Die Replikation von Einstellungen wird über die `ReplicateSettings` Berechtigungen des Dienstprinzipals gesteuert, aber wir verlassen uns auch auf dienstverknüpfte Rollen (SLRs), um bestimmte kontenübergreifende Funktionen für die regionsübergreifende Replikation und auto-scaling zu verwalten. Diese Rollen werden nur einmal pro Konto eingerichtet. AWS Nach der Erstellung dienen dieselben Rollen für alle globalen Tabellen in Ihrem Konto. Weitere Informationen zu serviceverknüpften Rollen finden Sie unter [Verwenden von serviceverknüpften Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html) im IAM-Benutzerhandbuch.

### Mit dem Dienst verknüpfte Rolle für die Verwaltung von Einstellungen
<a name="globaltables_MA_settings_management_slr"></a>

Amazon DynamoDB erstellt automatisch die AWSService RoleForDynamo DBGlobal TableSettingsManagement serviceverknüpfte Rolle (SLR), wenn Sie Ihr erstes globales Tabellenreplikat mit mehreren Konten im Konto erstellen. Diese Rolle verwaltet die kontoübergreifende regionsübergreifende Replikation von Einstellungen für Sie.

Wenn Sie ressourcenbasierte Richtlinien auf Replikate anwenden, stellen Sie sicher, dass Sie keine der im SLR-Prinzipal definierten Berechtigungen verweigern, da dies die Einstellungsverwaltung beeinträchtigen und die Replikation beeinträchtigen könnte, wenn der Durchsatz zwischen den Replikaten nicht übereinstimmt oder. `AWSServiceRoleForDynamoDBGlobalTableSettingsManagement` GSIs Wenn Sie die erforderlichen SLR-Berechtigungen verweigern, wird die Replikation zu und von den betroffenen Replikaten möglicherweise beendet, und der Status der Replikattabelle ändert sich auf. `REPLICATION_NOT_AUTHORIZED` Wenn bei globalen Tabellen mit mehreren Konten ein Replikat länger als 20 Stunden im `REPLICATION_NOT_AUTHORIZED` Status verbleibt, wird das Replikat unwiderruflich in eine DynamoDB-Tabelle mit einer einzigen Region konvertiert. Die Spiegelreflexkamera hat die folgenden Berechtigungen:
+ `application-autoscaling:DeleteScalingPolicy`
+ `application-autoscaling:DescribeScalableTargets`
+ `application-autoscaling:DescribeScalingPolicies`
+ `application-autoscaling:DeregisterScalableTarget`
+ `application-autoscaling:PutScalingPolicy`
+ `application-autoscaling:RegisterScalableTarget`

### Mit dem Auto Scaling Service verknüpfte Rolle
<a name="globaltables_MA_autoscaling_slr"></a>

Bei der Konfiguration einer globalen Tabelle für den Modus mit bereitgestellter Kapazität muss Auto Scaling für die globale Tabelle konfiguriert werden. DynamoDB Auto Scaling verwendet den AWS Application Auto Scaling Scaling-Dienst, um die bereitgestellte Durchsatzkapazität auf Ihren globalen Tabellenreplikaten dynamisch anzupassen. Der Application Auto Scaling Scaling-Dienst erstellt eine serviceverknüpfte Rolle (SLR) mit dem Namen. [AWSServiceRoleForApplicationAutoScaling\$1DynamoDBTable](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) Diese serviceverknüpfte Rolle wird automatisch in Ihrem AWS Konto erstellt, wenn Sie Auto Scaling für eine DynamoDB-Tabelle zum ersten Mal konfigurieren. Es ermöglicht Application Auto Scaling, die bereitgestellte Tabellenkapazität zu verwalten und CloudWatch Alarme zu erstellen.

Wenn Sie ressourcenbasierte Richtlinien auf Replikate anwenden, stellen Sie sicher, dass Sie dem Application Auto Scaling SLR-Prinzipal keine in der [AWSApplicationAutoscalingDynamoDBTableRichtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSApplicationAutoscalingDynamoDBTablePolicy.html) definierten Berechtigungen verweigern, da dadurch die Auto-Scaling-Funktionalität unterbrochen wird.

## AWS Wie globale Tabellen IAM verwenden
<a name="globaltables_MA_iam"></a>

In den folgenden Abschnitten werden die erforderlichen Berechtigungen für verschiedene globale Tabellenoperationen beschrieben und Richtlinienbeispiele bereitgestellt, die Ihnen bei der Konfiguration des entsprechenden Zugriffs für Ihre Benutzer und Anwendungen helfen sollen.

**Anmerkung**  
Alle beschriebenen Berechtigungen müssen auf die spezifische Tabellenressource ARN in den betroffenen Regionen angewendet werden. Die Tabellenressource ARN folgt dem Format`arn:aws:dynamodb:region:account-id:table/table-name`, in dem Sie Ihre tatsächlichen Werte für Region, Konto-ID und Tabellennamen angeben müssen.

Die folgenden step-by-step Themen behandeln wir in den folgenden Abschnitten:
+ Globale Tabellen mit mehreren Konten erstellen und Replikate hinzufügen
+ Aktualisierung einer globalen Tabelle mit mehreren Konten
+ Löschen globaler Tabellen und Entfernen von Replikaten

### Globale Tabellen erstellen und Replikate hinzufügen
<a name="globaltables_MA_creating"></a>

#### Berechtigungen für die Erstellung globaler Tabellen
<a name="globaltables_MA_creating_permissions"></a>

Wenn ein neues Replikat zu einer regionalen Tabelle hinzugefügt wird, um eine globale Tabelle mit mehreren Konten zu bilden, oder zu einer vorhandenen globalen Tabelle mit mehreren Konten, muss der IAM-Prinzipal, der die Aktion ausführt, von allen vorhandenen Mitgliedern autorisiert werden. Alle vorhandenen Mitglieder müssen in ihrer Tabellenrichtlinie die folgenden Berechtigungen erteilen, damit das Replikat erfolgreich hinzugefügt werden kann:
+ `dynamodb:AssociateTableReplica`- Mit dieser Berechtigung können Tabellen zu einer globalen Tabellenkonfiguration zusammengefügt werden. Dies ist die grundlegende Berechtigung, die den anfänglichen Aufbau der Replikationsbeziehung ermöglicht.

Durch diese präzise Steuerung können nur autorisierte Konten an der globalen Tabelleneinrichtung teilnehmen.

#### Beispiel für IAM-Richtlinien zum Erstellen globaler Tabellen
<a name="globaltables_MA_creating_examples"></a>

##### Beispiel für IAM-Richtlinien für ein Setup mit zwei Replikaten
<a name="globaltables_MA_2replica_example"></a>

Die Einrichtung globaler Tabellen mit mehreren Konten folgt einem bestimmten Autorisierungsablauf, der eine sichere Replikation gewährleistet. Lassen Sie uns anhand eines praktischen Szenarios untersuchen, wie dies in der Praxis funktioniert, in dem ein Kunde eine globale Tabelle mit zwei Replikaten einrichten möchte. Das erste Replikat (ReplicA) befindet sich in Konto A in der Region ap-east-1, während sich das zweite Replikat (ReplicAB) in Konto B in der Region eu-south-1 befindet.
+ Im Quellkonto (Konto A) beginnt der Prozess mit der Erstellung der primären Replikattabelle. Der Kontoadministrator muss dieser Tabelle eine ressourcenbasierte Richtlinie beifügen, die dem Zielkonto (Konto B) ausdrücklich die erforderlichen Berechtigungen erteilt, um die Zuordnung durchzuführen. Diese Richtlinie autorisiert auch den DynamoDB-Replikationsdienst, wichtige Replikationsaktionen durchzuführen.
+ Das Zielkonto (Konto B) folgt einem ähnlichen Prozess, indem es beim Erstellen des Replikats eine entsprechende ressourcenbasierte Richtlinie anhängt und auf den ARN der Quelltabelle verweist, der zur Erstellung des Replikats verwendet werden soll. Diese Richtlinie spiegelt die von Konto A erteilten Berechtigungen wider und schafft so eine vertrauenswürdige bidirektionale Beziehung. Bevor die Replikation eingerichtet wird, validiert DynamoDB diese kontoübergreifenden Berechtigungen, um sicherzustellen, dass die richtige Autorisierung vorhanden ist.

So richten Sie dieses Setup ein:
+ Der Administrator von Konto A muss zuerst die ressourcenbasierte Richtlinie an ReplicAA anhängen. Diese Richtlinie gewährt Konto B und dem DynamoDB-Replikationsdienst ausdrücklich die erforderlichen Berechtigungen.
+ In ähnlicher Weise muss der Administrator von Konto B im Aufruf create table Replica B, das auf Replikat A als Quelltabelle verweist, eine entsprechende Richtlinie an Replicab anhängen, wobei die Kontoreferenzen umgekehrt werden, um Konto A die entsprechenden Berechtigungen zu gewähren.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "DynamoDBActionsNeededForSteadyStateReplication",
            "Effect": "Allow",
            "Action": [
                "dynamodb:ReadDataForReplication",
                "dynamodb:WriteDataForReplication",
                "dynamodb:ReplicateSettings"
            ],
            "Resource": "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
            "Principal": {"Service": ["replication.dynamodb.amazonaws.com"]},
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": [ "111122223333", "444455556666" ],
                    "aws:SourceArn": [
                        "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
                        "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB"
                    ]
                }
            }
        },
        {
            "Sid": "AllowTrustedAccountsToJoinThisGlobalTable",
            "Effect": "Allow",
            "Action": [
                "dynamodb:AssociateTableReplica"
            ],
            "Resource": "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
            "Principal": {"AWS": ["444455556666"]}
        }
    ]
}
```

------

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "DynamoDBActionsNeededForSteadyStateReplication",
            "Effect": "Allow",
            "Action": [
                "dynamodb:ReadDataForReplication",
                "dynamodb:WriteDataForReplication",
                "dynamodb:ReplicateSettings"
            ],
            "Resource": "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB",
            "Principal": {"Service": ["replication.dynamodb.amazonaws.com"]},
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": [ "111122223333", "444455556666" ],
                    "aws:SourceArn": [
                        "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
                        "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB"
                    ]
                }
            }
        }
    ]
}
```

------

##### Beispiel für IAM-Richtlinien für ein Setup mit drei Replikaten
<a name="globaltables_MA_3replica_example"></a>

In diesem Setup haben wir jeweils 3 Replikate ReplicA, Replicab und ReplicaC in Konto A, Konto B und Konto C. Replikat A ist das erste Replikat, das als regionale Tabelle beginnt und der dann Replicab und ReplicaC hinzugefügt werden.
+ Der Administrator von Konto A muss zuerst ReplicA die ressourcenbasierte Richtlinie zuordnen, sodass die Replikation mit allen Mitgliedern möglich ist und den IAM-Prinzipalen von Konto B und Konto C das Hinzufügen von Replikaten ermöglicht wird.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "DynamoDBActionsNeededForSteadyStateReplication",
            "Effect": "Allow",
            "Action": [
                "dynamodb:ReadDataForReplication",
                "dynamodb:WriteDataForReplication",
                "dynamodb:ReplicateSettings"
            ],
            "Resource": "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
            "Principal": {"Service": ["replication.dynamodb.amazonaws.com"]},
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": [ "111122223333", "444455556666", "123456789012" ],
                    "aws:SourceArn": [
                        "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
                        "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB",
                        "arn:aws:dynamodb:us-east-1:123456789012:table/ReplicaC"
                    ]
                }
            }
        },
        {
            "Sid": "AllowTrustedAccountsToJoinThisGlobalTable",
            "Effect": "Allow",
            "Action": [
                "dynamodb:AssociateTableReplica"
            ],
            "Resource": "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
            "Principal": { "AWS": [ "444455556666", "123456789012" ] }
        }
    ]
}
```

------
+ Der Administrator von Konto B muss ein Replikat (Replikat B) hinzufügen, das auf Replica A als Quelle verweist. Für Replikat B gilt die folgende Richtlinie, die die Replikation zwischen allen Mitgliedern ermöglicht und es Konto C ermöglicht, ein Replikat hinzuzufügen:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "DynamoDBActionsNeededForSteadyStateReplication",
            "Effect": "Allow",
            "Action": [
                "dynamodb:ReadDataForReplication",
                "dynamodb:WriteDataForReplication",
                "dynamodb:ReplicateSettings"
            ],
            "Resource": "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB",
            "Principal": {"Service": ["replication.dynamodb.amazonaws.com"]},
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": [ "111122223333", "444455556666", "123456789012" ],
                    "aws:SourceArn": [
                        "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
                        "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB",
                        "arn:aws:dynamodb:us-east-1:123456789012:table/ReplicaC"
                    ]
                }
            }
        },
        {
            "Sid": "AllowTrustedAccountsToJoinThisGlobalTable",
            "Effect": "Allow",
            "Action": [
                "dynamodb:AssociateTableReplica"
            ],
            "Resource": "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB",
            "Principal": { "AWS": [ "123456789012" ] }
        }
    ]
}
```

------
+ Schließlich erstellt der Administrator von Konto C ein Replikat mit der folgenden Richtlinie, die Replikationsberechtigungen zwischen allen Mitgliedern gewährt. Die Richtlinie erlaubt nicht, dass weitere Replikate hinzugefügt werden.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "DynamoDBActionsNeededForSteadyStateReplication",
            "Effect": "Allow",
            "Action": [
                "dynamodb:ReadDataForReplication",
                "dynamodb:WriteDataForReplication",
                "dynamodb:ReplicateSettings"
            ],
            "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/ReplicaC",
            "Principal": {"Service": ["replication.dynamodb.amazonaws.com"]},
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": [ "111122223333", "444455556666" ],
                    "aws:SourceArn": [
                        "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
                        "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB"
                    ]
                }
            }
        }
    ]
}
```

------

### Aktualisierung einer globalen Tabelle mit mehreren Konten
<a name="globaltables_MA_updating"></a>

Um die Replikateinstellungen für eine bestehende globale Tabelle mithilfe der UpdateTable API zu ändern, benötigen Sie die folgende Berechtigung für die Tabellenressource in der Region, in der Sie den API-Aufruf tätigen: `dynamodb:UpdateTable`

Sie können auch andere globale Tabellenkonfigurationen aktualisieren, z. B. Richtlinien für auto Skalierung und Time-to-Live-Einstellungen. Für diese zusätzlichen Aktualisierungsvorgänge sind die folgenden Berechtigungen erforderlich:

Um die Time-to-Live-Einstellungen mit der `UpdateTimeToLive` API zu aktualisieren, benötigen Sie die folgenden Berechtigungen für die Tabellenressource in allen Regionen, die Replikate enthalten: `dynamodb:UpdateTimeToLive`

Um eine Replica-Auto-Scaling-Richtlinie mit der `UpdateTableReplicaAutoScaling` API zu aktualisieren, benötigen Sie die folgenden Berechtigungen für die Tabellenressource in allen Regionen, die Replikate enthalten:
+ `application-autoscaling:DeleteScalingPolicy`
+ `application-autoscaling:DeleteScheduledAction`
+ `application-autoscaling:DeregisterScalableTarget`
+ `application-autoscaling:DescribeScalableTargets`
+ `application-autoscaling:DescribeScalingActivities`
+ `application-autoscaling:DescribeScalingPolicies`
+ `application-autoscaling:DescribeScheduledActions`
+ `application-autoscaling:PutScalingPolicy`
+ `application-autoscaling:PutScheduledAction`
+ `application-autoscaling:RegisterScalableTarget`

**Anmerkung**  
Sie müssen `dynamodb:ReplicateSettings` Berechtigungen für alle Replikatregionen und Konten bereitstellen, damit die Aktualisierungstabelle erfolgreich aktualisiert werden kann. Wenn ein Replikat nicht berechtigt ist, Einstellungen auf ein beliebiges Replikat in der globalen Tabelle mit `AccessDeniedException` mehreren Konten zu replizieren, schlagen alle Aktualisierungsvorgänge für alle Replikate fehl, bis die Berechtigungen repariert sind.

### Löschen globaler Tabellen und Entfernen von Replikaten
<a name="globaltables_MA_deleting"></a>

Um eine globale Tabelle zu löschen, müssen Sie alle Replikate entfernen. Im Gegensatz zu Global Table mit demselben Konto können Sie diese Option nicht verwenden, `UpdateTable` um eine Replikattabelle in einer entfernten Region zu löschen. Jedes Replikat muss über die `DeleteTable` API aus dem Konto gelöscht werden, das es steuert.

#### Berechtigungen zum Löschen globaler Tabellen und zum Entfernen von Replikaten
<a name="globaltables_MA_deleting_permissions"></a>

Die folgenden Berechtigungen sind sowohl für das Entfernen einzelner Replikate als auch für das vollständige Löschen globaler Tabellen erforderlich. Durch das Löschen einer globalen Tabellenkonfiguration wird nur die Replikationsbeziehung zwischen Tabellen in verschiedenen Regionen entfernt. Die zugrunde liegende DynamoDB-Tabelle in der letzten verbleibenden Region wird nicht gelöscht. Die Tabelle in der letzten Region existiert weiterhin als standardmäßige DynamoDB-Tabelle mit denselben Daten und Einstellungen.

Sie benötigen die folgenden Berechtigungen für die Tabellenressource in jeder Region, in der Sie ein Replikat entfernen:
+ `dynamodb:DeleteTable`
+ `dynamodb:DeleteTableReplica`

## Wie verwenden globale Tabellen AWS KMS
<a name="globaltables_MA_kms"></a>

Wie alle DynamoDB-Tabellen verschlüsseln globale Tabellenreplikate Daten im Ruhezustand immer mit Verschlüsselungsschlüsseln, die im AWS Key Management Service () gespeichert sind.AWS KMS

**Anmerkung**  
Im Gegensatz zu globalen Tabellen mit demselben Konto können verschiedene Replikate in einer globalen Tabelle mit mehreren Konten mit unterschiedlichen Schlüsseltypen konfiguriert werden (AWS eigener Schlüssel oder vom Kunden AWS KMS verwalteter Schlüssel). Globale Tabellen mit mehreren Konten unterstützen keine verwalteten Schlüssel. AWS 

Globale Tabellen mit mehreren Konten, die verwendet werden, CMKs erfordern, dass die Schlüsselrichtlinie jedes Replikats dem DynamoDB-Replikationsdienstprinzipal (`replication.dynamodb.amazonaws.com`) Berechtigungen für den Zugriff auf den Schlüssel für die Replikation und die Einstellungsverwaltung erteilt. Die folgenden Berechtigungen sind erforderlich:
+ `kms:Decrypt`
+ `kms:ReEncrypt*`
+ `kms:GenerateDataKey*`
+ `kms:DescribeKey`

**Wichtig **

DynamoDB benötigt Zugriff auf den Verschlüsselungsschlüssel des Replikats, um ein Replikat zu löschen. Wenn Sie einen vom Kunden verwalteten Schlüssel, der zur Verschlüsselung eines Replikats verwendet wird, deaktivieren oder löschen möchten, weil Sie das Replikat löschen, sollten Sie zuerst das Replikat löschen, warten, bis die Tabelle aus der Replikationsgruppe entfernt wurde, indem Sie describe in einem der anderen Replikate aufrufen, und dann den Schlüssel deaktivieren oder löschen.

Wenn Sie den Zugriff von DynamoDB auf einen vom Kunden verwalteten Schlüssel, der zur Verschlüsselung eines Replikats verwendet wird, deaktivieren oder entziehen, wird die Replikation zum und vom Replikat beendet und der Replikatstatus wird auf geändert`INACCESSIBLE_ENCRYPTION_CREDENTIALS`. Wenn ein Replikat länger als 20 Stunden im `INACCESSIBLE_ENCRYPTION_CREDENTIALS` Status verbleibt, wird das Replikat irreversibel in eine DynamoDB-Tabelle mit einer einzigen Region konvertiert.

### Beispiel für eine Richtlinie AWS KMS
<a name="globaltables_MA_kms_example"></a>

Die AWS KMS Richtlinie ermöglicht DynamoDB den Zugriff auf beide AWS KMS Schlüssel für die Replikation zwischen den Replikaten A und B. Die AWS KMS Schlüssel, die dem DynamoDB-Replikat in jedem Konto zugeordnet sind, müssen mit der folgenden Richtlinie aktualisiert werden:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": { "Service": "replication.dynamodb.amazonaws.com" },
        "Action": [
            "kms:Decrypt",
            "kms:ReEncrypt*",
            "kms:GenerateDataKey*",
            "kms:DescribeKey"
        ],
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "aws:SourceAccount": [ "111122223333", "444455556666" ],
                "aws:SourceArn": [
                    "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
                    "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB"
                ]
            }
        }
      }
   ]
 }
```

------

# Grundlegendes zur Amazon DynamoDB-Fakturierung für globale Tabellen
<a name="global-tables-billing"></a>

In diesem Leitfaden wird die Funktionsweise der DynamoDB-Fakturierung für globale Tabellen beschrieben und es werden die Komponenten ermittelt, die zu den Kosten globaler Tabellen beitragen, und anhand eines Beispiels veranschaulicht. 

[Globale Amazon-DynamoDB-Tabellen](GlobalTables.md) sind eine vollständig verwaltete, serverlose, multiregionale und multiaktive Datenbank. Globale Tabellen sind auf eine [Verfügbarkeit von 99,999 %](https://aws.amazon.com/dynamodb/sla/) ausgelegt und sorgen so für stabilere Anwendungen und eine höhere Geschäftskontinuität. Globale Tabellen replizieren Ihre DynamoDB-Tabellen automatisch in den AWS Regionen Ihrer Wahl, sodass Sie eine schnelle, lokale Lese- und Schreibleistung erzielen können. 

## Funktionsweise
<a name="global-tables-billing-how-it-works"></a>

Das Fakturierungsmodell für globale Tabellen unterscheidet sich von dem für DynamoDB-Tabellen mit einer Region. Schreibvorgänge in DynamoDB-Tabellen mit einer Region werden in den folgenden Einheiten abgerechnet:
+ Write Request Units (WRUs) für den On-Demand-Kapazitätsmodus, bei dem für jeden Schreibvorgang bis zu 1 KB eine WRU berechnet wird
+ Schreibkapazitätseinheiten (WCUs) für den Bereitstellungsmodus, bei dem eine WCU einen Schreibvorgang pro Sekunde für bis zu 1 KB ermöglicht

Wenn Sie eine globale Tabelle durch Hinzufügen einer Replikattabelle zu einer vorhandenen Tabelle mit einer Region erstellen, wird die Tabelle mit einer Region in eine Replikattabelle umgewandelt. Das bedeutet, dass sich auch die Einheiten für die Abrechnung von Schreibvorgängen in die Tabelle ändern. Schreibvorgänge in Replikattabellen mit einer Region werden in den folgenden Einheiten abgerechnet: 
+ Replicated Write Request Units (rWRUs) für den On-Demand-Kapazitätsmodus, bei dem für jeden Schreibvorgang bis zu 1 KB eine RWRU pro Replikattabelle berechnet wird
+ Replizierte Schreibkapazitätseinheiten (rWCUs) für den Bereitstellungskapazitätsmodus, bei dem eine WCU pro Replikattabelle einen Schreibvorgang pro Sekunde für bis zu 1 KB ermöglicht

Aktualisierungen globaler sekundärer Indizes (GSIs) werden mit denselben Einheiten abgerechnet wie DynamoDB-Tabellen mit einer Region, auch wenn es sich bei der Basistabelle für die GSI um eine Replikattabelle handelt. Aktualisierungsvorgänge für GSIs werden anhand der folgenden Einheiten abgerechnet:
+ Write Request Units (WRUs) für den On-Demand-Kapazitätsmodus, bei dem für jeden Schreibvorgang bis zu 1 KB eine WRU berechnet wird
+ Schreibkapazitätseinheiten (WCUs) für den Bereitstellungsmodus, bei dem eine WCU einen Schreibvorgang pro Sekunde für bis zu 1 KB ermöglicht

Für replizierte Schreibeinheiten (r WCUs und rWRUs) gilt der gleiche Preis wie für Schreibeinheiten mit einer Region (und). WCUs WRUs Für globale Tabellen fallen Gebühren für multiregionale Datenübertragungen an, da Daten regionsübergreifend repliziert werden. Gebühren für replizierte Schreibvorgänge (rWCU oder rWRU) fallen in jeder Region an, deren globale Tabelle eine Replikattabelle enthält.

Für Lesevorgänge aus Tabellen mit nur einer Region und aus Replikattabellen werden die folgenden Einheiten verwendet:
+ Read Request Units (RRUs) für den On-Demand-Kapazitätsmodus, bei dem für jeden stark konsistenten Lesevorgang bis zu 4 KB eine RRU berechnet wird
+ Lesekapazitätseinheiten (RCUs) für bereitgestellte Tabellen, bei denen eine RCU einen stark konsistenten Lesevorgang pro Sekunde für bis zu 4 KB ermöglicht

## Konsistenzmodi und Fakturierung
<a name="global-tables-billing-consistency-modes"></a>

Die replizierten Schreibeinheiten (r WCUs und rWRUs), die zur Abrechnung von Schreibvorgängen verwendet werden, sind sowohl für die Modi Multi-Region Strong Consistency (MRSC) als auch für Multi-Region Eventual Consistency (MREC) identisch. Für globale Tabellen, die den MRSC-Modus (Multi-Region Strong Consistency) verwenden und mit einem Zeugen konfiguriert sind, fallen keine Kosten für replizierte Schreibeinheiten (r WCUs und rWRUs), Speicherkosten oder Datenübertragungskosten für die Replikation zum Zeugen an.

## Beispiel für die Fakturierung von DynamoDB-Tabellen
<a name="global-tables-billing-example"></a>

Im Folgenden sehen Sie ein Beispielszenario über mehrere Tage, das die Abrechnung von Schreibanforderungen in globalen Tabellen in der Praxis darstellt. (Beachten Sie, dass hier nur Schreibanforderungen berücksichtigt werden und keine Gebühren für die Tabellenwiederherstellung und die regionsübergreifende Datenübertragung, die im vorliegenden Beispiel zusätzlich anfallen würden):

**Tag 1 – Tabelle mit einer Region:** Sie haben eine DynamoDB-On-Demand-Tabelle mit einer Region namens „Table\$1A“ in der Region „us-west-2“. Sie schreiben 100 Elemente mit 1 KB in Table\$1A. Für diese Schreibvorgänge mit nur einer Region wird eine Schreibanforderungseinheit (WRU) je 1 KB berechnet. Für Tag 1 fallen demnach folgende Gebühren an:
+ 100 WRUs in der Region US-West-2 für Schreibvorgänge in einer Region

**Die Gesamtzahl der am ersten Tag berechneten Anforderungseinheiten: 100. WRUs**

**Tag 2 – Erstellen einer globalen Tabelle:** Sie erstellen eine globale Tabelle, indem Sie Table\$1A in der Region „us-east-2“ ein Replikat hinzufügen. Table\$1A ist jetzt eine globale Tabelle mit zwei Replikattabellen: eine in der Region „us-west-2“ und eine in der Region „us-east-2“. Sie schreiben 150 Elemente mit 1 KB in die Replikattabelle in der Region „us-west-2“. Für Tag 2 fallen demnach folgende Gebühren an:
+ 150 r WRUs in der Region US-West-2 für replizierte Schreibvorgänge
+ 150 r WRUs in der Region us-east-2 für replizierte Schreibvorgänge

**Gesamtzahl der am zweiten Tag berechneten Anforderungseinheiten: 300 r. WRUs**

**Tag 3 – Hinzufügen eines globalen sekundären Index:** Sie fügen der Replikattabelle in der Region „us-east-2“ einen globalen sekundären Index (GSI) hinzu, der alle Attribute aus der Basistabelle (Replikattabelle) projiziert. Die globale Tabelle erstellt automatisch den globalen Index für die Replikattabelle in der Region „us-west-2“ für Sie. Sie schreiben 200 Elemente mit 1 KB in die Replikattabelle in der Region „us-west-2“. Für Tag 3 fallen demnach folgende Gebühren an:
+ • 200 r WRUs in der Region US-West-2 für replizierte Schreibvorgänge
+ • 200 WRUs in der Region US-West-2 für GSI-Updates
+ • 200 r WRUs in der Region us-east-2 für replizierte Schreibvorgänge
+ • 200 WRUs in der Region US-East-2 für GSI-Updates

Gesamtzahl der am 3. Tag berechneten Schreibanforderungseinheiten: **400 WRUs und 400 r. WRUs**

Die gesamten Gebühren für Schreibeinheiten für alle drei Tage betragen 500 WRUs (100 WRU an Tag 1 \$1 400 WRUs an Tag 3) und 700 R WRUs (300 R WRUs an Tag 2 \$1 400 R WRUs an Tag 3).

Zusammenfassend lässt sich sagen, dass Schreibvorgänge in Replikattabellen in allen Regionen, die eine Replikattabelle enthalten, in replizierten Schreibeinheiten abgerechnet werden. Wenn Sie über globale Sekundärindizes verfügen, werden Ihnen Schreibeinheiten für Aktualisierungen GSIs in allen Regionen berechnet, die einen globalen Index enthalten (was in einer globalen Tabelle für alle Regionen steht, die eine Replikattabelle enthalten). 

# Versionen von globalen DynamoDB-Tabellen
<a name="V2globaltables_versions"></a>

Es gibt zwei Versionen von globalen DynamoDB-Tabellen: Version 2019.11.21 (Aktuell) und Version 2017.11.29 (Legacy). Wir empfehlen für globale Tabellen die Verwendung der Version 2019.11.21 (Aktuell), da sie einfacher zu verwenden ist, in mehr Regionen unterstützt wird und für die meisten Workloads kostengünstiger ist als Version 2017.11.29 (Legacy).

## Ermitteln der Version einer globalen Tabelle
<a name="globaltables.DetermineVersion"></a>

### Ermitteln der Version mit dem AWS CLI
<a name="globaltables.CLI"></a>

#### Identifizieren des Replikats einer globalen Tabelle der Version 2019.11.21 (Aktuell)
<a name="globaltables.CLI.current"></a>

Rufen Sie den Befehl `describe-table` auf, um festzustellen, ob es sich bei einer Tabelle um ein Replikat von Version 2019.11.21 (Aktuell) handelt. Wenn die Ausgabe das `GlobalTableVersion`-Attribut mit dem Wert „2019.11.21“ enthält, handelt es sich bei der Tabelle um das Replikat einer globalen Tabelle der Version 2019.11.21 (Aktuell).

Beispiel eines CLI-Befehls für `describe-table`:

```
aws dynamodb describe-table \
--table-name users \
--region us-east-2
```

Wenn die (verkürzte) Ausgabe das `GlobalTableVersion`-Attribut mit dem Wert „2019.11.21“ enthält, handelt es sich bei der Tabelle um das Replikat einer globalen Tabelle der Version 2019.11.21 (Aktuell).

```
{
    "Table": {
        "AttributeDefinitions": [
            {
                "AttributeName": "id",
                "AttributeType": "S"
            },
            {
                "AttributeName": "name",
                "AttributeType": "S"
            }
        ],
        "TableName": "users",
        ...
        "GlobalTableVersion": "2019.11.21",
        "Replicas": [
            {
                "RegionName": "us-west-2",
                "ReplicaStatus": "ACTIVE",
            }
        ],
        ...
    }
}
```

#### Identifizieren des Replikats einer globalen Tabelle der Version 2017.11.29 (Legacy)
<a name="globaltables.CLI.legacy"></a>

Die Version 2017.11.29 (Legacy) verwendet einen speziellen Befehlssatz für die Verwaltung der globalen Tabelle. Rufen Sie den Befehl `describe-global-table` auf, um festzustellen, ob es sich bei einer Tabelle um ein Replikat von Version 2017.11.29 (Legacy) handelt. Wenn Sie eine erfolgreiche Antwort erhalten, handelt es sich bei der globalen Tabelle um ein Replikat der Version 2017.11.29 (Legacy). Wenn der Befehl `describe-global-table` den Fehler `GlobalTableNotFoundException` zurückgibt, handelt es sich bei der Tabelle nicht um ein Replikat der Version 2017.11.29 (Legacy).

Beispiel eines CLI-Befehls für `describe-global-table`:

```
aws dynamodb describe-global-table \
--table-name users \
--region us-east-2
```

Wenn der Befehl eine erfolgreiche Antwort zurückgibt, handelt es sich bei der globalen Tabelle um ein Replikat der Version 2017.11.29 (Legacy).

```
{
    "GlobalTableDescription": {
        "ReplicationGroup": [
            {
                "RegionName": "us-west-2"
            },
            {
                "RegionName": "us-east-2"
            }
        ],
        "GlobalTableArn": "arn:aws:dynamodb::123456789012:global-table/users",
        "CreationDateTime": "2025-06-10T13:55:53.630000-04:00",
        "GlobalTableStatus": "ACTIVE",
        "GlobalTableName": "users"
    }
}
```

### Ermitteln der Version mithilfe der DynamoDB-Konsole
<a name="globaltables.console"></a>

Gehen Sie wie folgt vor, um die Version des Replikats einer globalen Tabelle zu ermitteln:

1. [Öffnen Sie die DynamoDB-Konsole zu Hausehttps://console.aws.amazon.com/dynamodb/.](https://console.aws.amazon.com/dynamodb/home)

1. Klicken Sie im Navigationsbereich auf der linken Seite der Konsole auf **Tabellen**.

1. Wählen Sie die globale Tabelle aus, deren Version Sie ermitteln möchten.

1. Wählen Sie die Registerkarte **Globale Tabellen** aus.

   Im Abschnitt *Zusammenfassung* wird die Version der verwendeten globalen Tabellen angezeigt.

## Unterschiede im Verhalten zwischen der Legacy- und der aktuellen Version
<a name="DiffLegacyVsCurrent"></a>

In der folgenden Liste werden die Verhaltensunterschiede zwischen der Legacy-Version und der aktuellen Version globaler Tabellen beschrieben.
+ Version 2019.11.21 (Aktuell) verbraucht im Vergleich zu Version 2017.11.29 (Legacy) bei mehreren Operationen in DynamoDB-Datenbanken weniger Schreibkapazität und ist daher für die meisten Kunden kostengünstiger. Die Unterschiede in Bezug auf DynamoDB-Operationen im Einzelnen:
  + Das Aufrufen [PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html)eines 1-KB-Elements in einer Region und das Replizieren in andere Regionen erfordert 2 r WRUs pro Region für 2017.11.29 (Legacy), aber nur 1 RWRU für 2019.11.21 (Aktuell).
  + [UpdateItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html)Zum Aufrufen eines 1-KB-Elements sind 2 r WRUs in der Quellregion und 1 RWRU pro Zielregion für 2017.11.29 (Legacy) erforderlich, aber nur 1 RWRU für Quell- und Zielregion für 2019.11.21 (Aktuell).
  + Der Aufruf [DeleteItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteItem.html)für ein 1-KB-Element erfordert 1 RWRU in der Quellregion und 2 r WRUs pro Zielregion für 2017.11.29 (Legacy), aber nur 1 RWRU sowohl für die Quell- als auch für die Zielregion für 2019.11.21 (Aktuell).

  Die folgende Tabelle zeigt den rWRU-Verbrauch der Tabellen-Versionen 2017.11.29 (Legacy) und 2019.11.21 (Aktuell) für ein 1 KB großes Element in zwei Regionen.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/V2globaltables_versions.html)
+ Version 2017.11.29 (Legacy) ist nur in Version 11 verfügbar. AWS-Regionen Version 2019.11.21 (Aktuell) hingegen ist in allen AWS-Regionen verfügbar.
+ Sie erstellen globale Tabellen der Version 2017.11.29 (Legacy), indem Sie zuerst einen Satz leerer Regionaltabellen erstellen und dann die API aufrufen, um die [CreateGlobalTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateGlobalTable.html)globale Tabelle zu bilden. Sie erstellen globale Tabellen der Version 2019.11.21 (aktuell), indem Sie die [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html)API aufrufen, um einer vorhandenen Regionaltabelle ein Replikat hinzuzufügen.
+ Version 2017.11.29 (Legacy) erfordert, dass Sie alle Replikate in der Tabelle leeren, bevor Sie einer neuen Region (auch während ihrer Erstellung) ein Replikat hinzufügen. Version 2019.11.21 (Aktuell) unterstützt Sie beim Hinzufügen und Entfernen von Replikaten zu Regionen in einer Tabelle, die bereits Daten enthält.
+ Version 2017.11.29 (Legacy) verwendet die folgenden speziellen Steuerungsebenen für die Verwaltung von Replikaten: APIs 
  + [CreateGlobalTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateGlobalTable.html)
  + [DescribeGlobalTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeGlobalTable.html)
  + [DescribeGlobalTableSettings](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeGlobalTableSettings.html)
  + [ListGlobalTables](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ListGlobalTables.html)
  + [UpdateGlobalTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateGlobalTable.html)
  + [UpdateGlobalTableSettings](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateGlobalTableSettings.html)

  Version 2019.11.21 (Aktuell) verwendet das und zur Verwaltung von Replikaten. [DescribeTable[UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html)](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTable.html) APIs 
+ In Version 2017.11.29 (Legacy) werden zwei DynamoDB-Streams-Datensätze für jeden Schreibvorgang veröffentlicht. In Version 2019.11.21 (Aktuell) wird nur ein DynamoDB-Streams-Datensatz für jeden Schreibvorgang veröffentlicht.
+ In Version 2017.11.29 (Legacy) werden die Attribute `aws:rep:deleting`, `aws:rep:updateregion` und `aws:rep:updatetime` gefüllt und aktualisiert. In Version 2019.11.21 (Aktuell) werden dieser Attribute nicht gefüllt und aktualisiert.
+ In Version 2017.11.29 (Legacy) werden die [Verwenden von Time to Live (TTL) in DynamoDB](TTL.md)-Einstellungen nicht replikatsübergreifend synchronisiert. In Version 2019.11.21 (Aktuell) werden die TTL-Einstellungen replikatsübergreifend synchronisiert.
+ In Version 2017.11.29 (Legacy) werden TTL-Löschvorgänge nicht auf andere Replikate übertragen. In Version 2019.11.21 (Aktuell) werden TTL-Löschvorgänge auf alle Replikate übertragen.
+ In Version 2017.11.29 (Legacy) werden die [Auto-Scaling](AutoScaling.md)-Einstellungen nicht replikatsübergreifend synchronisiert. In Version 2019.11.21 (Aktuell) werden die Auto-Scaling-Einstellungen replikatsübergreifend aktualisiert.
+ In Version 2017.11.29 (Legacy) werden die Einstellungen für den [globalen sekundären Index (GSI)](GSI.md) nicht replikatsübergreifend synchronisiert. In Version 2019.11.21 (Aktuell) werden die GSI-Einstellungen replikatsübergreifend synchronisiert.
+ In Version 2017.11.29 (Legacy) werden die Einstellungen für die [Verschlüsselung im Ruhezustand](encryption.usagenotes.md) nicht replikatsübergreifend synchronisiert. In Version 2019.11.21 (Aktuell) werden die Einstellungen für die Verschlüsselung im Ruhezustand replikatsübergreifend synchronisiert.
+ In Version 2017.11.29 (Legacy) wird die `PendingReplicationCount`-Metrik veröffentlicht. In Version 2019.11.21 (Aktuell) wird diese Metrik nicht veröffentlicht.

## Aktualisieren auf die aktuelle Version
<a name="upgrading-to-current-version"></a>

### Erforderliche Berechtigungen für die Aktualisierung von globalen Tabellen
<a name="V2globaltables_versions.Notes-permissions"></a>

Für eine Aktualisierung auf die Version 2019.11.21 (Aktuell) aktualisieren müssen Sie in allen Regionen mit Replikaten über die Berechtigung `dynamodb:UpdateGlobalTableversion` verfügen. Diese Berechtigungen werden zusätzlich zu den Berechtigungen benötigt, die für den Zugriff auf die DynamoDB-Konsole und die Anzeige von Tabellen erforderlich sind.

Über die folgende IAM-Richtlinie werden Berechtigungen zum Aktualisieren einer globalen Tabelle auf Version 2019.11.21 (Aktuell) erteilt.

```
{
    "version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:UpdateGlobalTableversion",
            "Resource": "*"
        }
    ]
}
```

Über die folgende IAM-Richtlinie wird die Berechtigung erteilt, nur die globale Tabelle `Music` mit Replikaten in zwei Regionen auf die Version 2019.11.21 (Aktuell) zu aktualisieren.

```
{
    "version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:UpdateGlobalTableversion",
            "Resource": [
                "arn:aws:dynamodb::123456789012:global-table/Music",
                "arn:aws:dynamodb:ap-southeast-1:123456789012:table/Music",
                "arn:aws:dynamodb:us-east-2:123456789012:table/Music"
            ]
        }
    ]
}
```

### Informationen Fakten zum Ablauf der Aktualisierung
<a name="V2GlobalTablesUpgradeExpectations"></a>
+ Während der Aktualisierung wird in allen Replikaten globaler Tabellen die Verarbeitung des Lese- und Schreibdatenverkehr fortgesetzt.
+ Die Aktualisierung dauert je nach Tabellengröße und Anzahl der Replikate zwischen einigen Minuten und mehreren Stunden.
+ Während des Upgrade-Vorgangs ändert sich der Wert von von [TableStatus](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TableDescription.html#DDB-Type-TableDescription-TableStatus)auf. `ACTIVE` `UPDATING` Sie können den Status der Tabelle anzeigen, indem Sie die [DescribeTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DescribeTable.html)API aufrufen oder die **Tabellenansicht** in der DynamoDB-Konsole verwenden.
+ Die Einstellungen für die bereitgestellte Kapazität für eine globale Tabelle werden während der Aktualisierung vom Auto-Scaling-Prozess nicht angepasst. Es wird dringend empfohlen, während der Aktualisierung der Tabelle den Modus [On-Demand-Kapazität](capacity-mode.md#capacity-mode-on-demand) zu verwenden.
+ Wenn Sie sich bei der Aktualisierung für den Modus [bereitgestellter Kapazität](provisioned-capacity-mode.md) mit Auto Scaling entscheiden, müssen Sie in Ihren Richtlinien den minimalen Lese- und Schreibdurchsatz erhöhen, um dem erwarteten Anstieg des Datenverkehrs während der Dauer der Aktualisierung Rechnung zu tragen.
+ Es kann vorkommen, dass die Metrik `ReplicationLatency` vorübergehend Latenzspitzen meldet oder dass die Meldung von Metrikdaten während der Aktualisierung ganz ausbleibt. Weitere Informationen finden Sie unter [ReplicationLatency](metrics-dimensions.md#ReplicationLatency). 
+ Sobald der Aktualisierungsvorgang abgeschlossen ist, wird der Status der Tabelle zurück zu `ACTIVE`.

### Verhalten von DynamoDB Streams vor, während und nach der Aktualisierung
<a name="V2GlobalTablesUpgradeDDBStreamsBehavior"></a>

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/V2globaltables_versions.html)

### Aktualisieren auf Version 2019.11.21 (Aktuell)
<a name="V2globaltables_versions.upgrade"></a>

Führen Sie die folgenden Schritte aus, um Ihre Version für globale DynamoDB-Tabellen mithilfe der AWS-Managementkonsole zu aktualisieren.

**So aktualisieren globale Tabellen auf Version 2019.11.21 (Aktuell)**

1. [Öffnen Sie die DynamoDB-Konsole zu Hausehttps://console.aws.amazon.com/dynamodb/.](https://console.aws.amazon.com/dynamodb/home) 

1. Wählen Sie im Navigationsbereich auf der linken Seite der Konsole die Option **Tabellen** und dann die globale Tabelle aus, die Sie auf Version 2019.11.21 (Aktuell) aktualisieren möchten. 

1. Wählen Sie die Registerkarte **Globale Tabellen** aus.

1. Wählen Sie **Update version** (Version aktualisieren) aus.  
![\[Screenshot der Konsole mit der Schaltfläche „Update version“ (Version aktualisieren)\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/GlobalTables-upgrade.png)

1. Lesen Sie sich die neuen Anforderungen durch und stimmen Sie ihnen zu, wählen Sie dann **Update version** Version aktualisieren.

1. Nach Abschluss des Aktualisierungsvorgangs wird die in der Konsole angezeigte Version für globale Tabellen in **2019.11.21** geändert.

# Bewährte Methoden für globale Tabellen
<a name="globaltables-bestpractices"></a>

In den folgenden Abschnitten werden bewährte Methoden für die Bereitstellung und Verwendung globaler Tabellen beschrieben.

## Version
<a name="globaltables-bestpractices-version"></a>

Es gibt zwei Versionen von globalen DynamoDB-Tabellen: Version 2019.11.21 (Aktuell) und [Version 2017.11.29 (Legacy)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables.V1.html). Sie sollten nach Möglichkeit die Version 2019.11.21 (Aktuell) verwenden. 

## Löschschutz
<a name="globaltables-bestpractices-deletionprotection"></a>

Sie sollten den Löschschutz für globale Tabellenreplikate aktivieren, die Sie vor versehentlichem Löschen schützen möchten. Sie müssen den Löschschutz für jedes Replikat aktivieren.

## Benutzen AWS CloudFormation
<a name="globaltables-bestpractices-cloudformation"></a>

CloudFormation unterstützt derzeit nicht die stapelübergreifende Koordination von Ressourcen wie globalen Tabellen. Wenn Sie jedes Replikat einer globalen Tabelle in einem separaten regionalen Stack definieren, treten Fehler auf, die auf festgestellte Abweichungen zwischen den Stacks bei der Durchführung von Replikataktualisierungen zurückzuführen sind. Um dieses Problem zu vermeiden, sollten Sie eine Region als Referenzregion für die Bereitstellung der globalen Tabellen auswählen und alle Replikate der globalen Tabelle im Stack dieser Region definieren.

**Wichtig**  
Sie können eine Ressource des Typs `AWS::DynamoDB::Table` nicht in eine Ressource des Typs `AWS::DynamoDB::GlobalTable` konvertieren, indem Sie den Typ in Ihrer Vorlage ändern. Der Versuch, eine Tabelle mit einer einzigen Region in eine globale Tabelle zu konvertieren, indem ihr CloudFormation Ressourcentyp geändert wird, kann dazu führen, dass Ihre DynamoDB-Tabelle gelöscht wird.

Stattdessen können Sie die `AWS::DynamoDB::GlobalTable`-Ressource verwenden, um eine neue Tabelle in einer einzelnen Region zu erstellen. Diese Tabelle wird wie jede andere Tabelle mit einer einzelnen Region bereitgestellt. Wenn Sie den Stack später aktualisieren, um einer Ressource weitere Regionen hinzuzufügen, werden der Tabelle Replikate hinzugefügt, und sie wird sicher in eine globale Tabelle konvertiert.

Wenn Sie bereits über eine `AWS::DynamoDB::Table`-Ressource verfügen, die Sie in eine `AWS::DynamoDB::GlobalTable`-Ressource konvertieren möchten, werden folgende Schritte zur Konvertierung des Ressourcentyps empfohlen:

1. Legen Sie die Richtlinie zum Löschen von `AWS::DynamoDB::Table` fest, die beibehalten werden soll.

1. Entfernen Sie die Tabelle aus der Stack-Definition.

1. Fügen Sie der Tabelle mit einer Region in der AWS Konsole Replikate hinzu und konvertieren Sie sie in eine globale Tabelle.

1. Importieren Sie die globale Tabelle als neue `AWS::DynamoDB::GlobalTable`-Ressource in den Stack.

## Backups und Wiederherstellung Point-in-Time
<a name="globaltables-bestpractices-backups"></a>

Die Aktivierung von Automated Backups and Point-in-Time Recovery (PITR) für ein Replikat in einer globalen Tabelle kann ausreichen, um Ihre Disaster Recovery-Ziele zu erreichen. Mit -Backup erstellte AWS Replikat-Backups können automatisch regionsübergreifend repliziert werden, um die Ausfallsicherheit zu erhöhen. Berücksichtigen Sie bei der Wahl der Backup- und PITR-Strategie die Ziele des Notfallwiederherstellungsplans vor dem Hintergrund der Hochverfügbarkeit in mehreren Regionen.

## Planen einer hohen Verfügbarkeit in mehreren Regionen
<a name="globaltables-bestpractices-multiregion"></a>

Vorgeschriebene Anleitungen zur Bereitstellung globaler Tabellen finden Sie unter [Best Practices for DynamoDB global table design](bp-global-table-design.md).