{
  "content": "# DynamoDB Global Tables: What It Is and When to Use It\n\n## Definition\n\n[Amazon DynamoDB](/terms/dynamodb) Global Tables is a fully managed, multi-active, and multi-Region database feature that replicates table data automatically across your choice of [AWS Region](/terms/region)s. It solves the problem of providing fast, low-latency data access to globally distributed users and building highly available, resilient applications that can withstand a full Region outage.\n\n## How It Works\n\nDynamoDB Global Tables are built on a multi-active architecture, meaning there is no single primary Region. An application can perform both read and write operations to any of the replica tables in any of the associated AWS Regions.\n\nWhen an application writes a new item or updates an existing one in a replica table, DynamoDB automatically propagates that write to all other replica tables in the global table. This replication process is asynchronous and typically completes within a second, a metric that can be monitored via [Amazon CloudWatch](/terms/cloudwatch).\n\nFor situations where applications in different Regions write to the same item at nearly the same time, conflicts are resolved using a \"last writer wins\" mechanism. DynamoDB uses the timestamp of the modification to determine the most recent update, and all replicas will eventually converge on that final version, ensuring eventual consistency across all Regions.\n\n## Key Features and Limits\n\n*   **Multi-Active Replication:** Read and write to any replica table in any Region, providing low-latency performance for global users.\n*   **High Availability:** Designed for 99.999% availability. If a single AWS Region becomes unavailable, your application can redirect traffic to another Region without needing a database failover.\n*   **Consistency Models:** Global tables can be configured with either multi-Region eventual consistency (the default) or multi-Region strong consistency. The consistency mode cannot be changed after the table is created.\n*   **Automatic Replication:** DynamoDB handles the complexity of replicating data and resolving conflicts, with no application code changes required to use the feature.\n*   **Multi-Account Support:** Replicas can be deployed across multiple AWS accounts, which is ideal for organizations that use multi-account strategies for security isolation and disaster recovery.\n*   **Item Size Limit:** Like standard DynamoDB tables, items in a Global Table cannot exceed 400 KB.\n*   **Global Secondary Indexes (GSIs):** GSIs are supported and are also replicated across all Regions. Each GSI has its own throughput settings.\n*   **Prerequisites:** To convert a single-Region table to a global table, [DynamoDB Streams](/terms/dynamodb-streams) must be enabled with the `NEW_AND_OLD_IMAGES` view type.\n\n## Common Use Cases\n\n*   **Globally Distributed Applications:** Serve a global user base with fast, local read and write performance by placing data closer to the users, reducing latency for applications like social media, e-commerce, and content platforms.\n*   **Disaster Recovery and High Availability:** Build applications that can withstand the failure of an entire AWS Region. With a multi-active architecture, traffic can be seamlessly routed to a healthy Region, ensuring business continuity.\n*   **Real-Time Gaming:** Power applications like gaming leaderboards where real-time updates from players around the world need to be captured and reflected globally with minimal delay.\n*   **Content Delivery and Media:** Replicate user-generated content, metadata, and user profiles across the globe to ensure a consistent and fast experience for all users of a streaming or content platform.\n*   **Data Sovereignty and Compliance:** While data is replicated globally, applications can be architected to write and read sensitive data primarily from a specific "home" Region to help meet regulatory and data locality requirements.\n\n## Pricing Model\n\nThe cost of DynamoDB Global Tables has several components, and you pay only for the resources you use with no upfront fees.\n\n*   **Storage:** You are billed for the storage used by the table in *each* replica Region.\n*   **Reads:** Standard DynamoDB read charges (per million Read Request Units or per provisioned Read Capacity Unit-hour) apply in each Region where reads are performed.\n*   **Replicated Writes:** Instead of standard Write Capacity Units (WCUs), Global Tables use replicated Write Capacity Units (rWCUs). You are charged for rWCUs in *each* replica Region. For example, a write to a table with three replicas will incur rWCU charges in all three Regions.\n*   **Cross-Region Data Transfer:** Standard AWS data transfer charges apply for the data replicated between your chosen Regions.\n*   **Global Secondary Indexes (GSIs):** Writes to GSIs on a global table are billed as standard WCUs in each replica region, which can be a significant cost multiplier.\n*   **Reserved Capacity:** Replicated Write Capacity Units (rWCUs) are not eligible for Reserved Capacity discounts. However, the newer Database Savings Plans (launched in late 2025) may offer some savings.\n\nFor detailed estimates, use the official AWS Pricing Calculator.\n\n## Pros and Cons\n\n**Pros:**\n*   **Low Latency:** Provides single-digit millisecond read and write latency for global users by serving requests from the nearest AWS Region.\n*   **Extreme Resilience:** The multi-active architecture provides a robust solution for disaster recovery and high availability, often with a Recovery Point Objective (RPO) near zero.\n*   **Fully Managed:** AWS manages all the underlying infrastructure and replication logic, eliminating significant operational overhead compared to self-managed solutions.\n*   **Scalability:** Inherits the massive scalability of the standard DynamoDB service.\n\n**Cons:**\n*   **Increased Cost:** Replicating writes and storing data in multiple Regions incurs higher costs for throughput, storage, and data transfer compared to a single-Region table.\n*   **Eventual Consistency:** While replication is fast, it is asynchronous. Applications must be designed to handle a brief period where data may not be fully consistent across all Regions.\n*   **\"Last Writer Wins\" Conflict Resolution:** The default conflict resolution model is simple but may not be suitable for all workloads. Applications requiring complex conflict resolution logic (e.g., commutative counters) need to implement it in the application layer.\n*   **Transactional Limitations:** ACID transactions are supported but are only atomic within the Region where the transaction is initiated. They are not replicated as a single atomic unit to other Regions.\n\n## Comparison with Alternatives\n\n**DynamoDB Global Tables vs. Amazon [Aurora Global Database](/terms/aurora-global-database):**\n\nThe primary alternative for a managed, multi-Region database on AWS is [Amazon Aurora](/terms/aurora) Global Database. The choice depends fundamentally on the data model required.\n\n*   **Data Model:** DynamoDB is a NoSQL (key-value and document) database, ideal for flexible schemas and high-velocity, unstructured data. Aurora is a relational SQL database (MySQL and PostgreSQL compatible), suited for structured data with complex relationships, joins, and transactional integrity.\n*   **Write Architecture:** DynamoDB Global Tables have a **multi-active** (or multi-master) architecture, allowing writes to any Region. Aurora Global Database uses a **single-master** model; writes can only be sent to the primary Region, while secondary Regions serve as low-latency read replicas.\n*   **Failover:** Failover in DynamoDB is handled by the application, which can simply redirect traffic to another active Region. In Aurora, a secondary Region must be manually promoted to become the new primary, a process that typically takes under a minute but is not automatic.\n\n## Exam Relevance\n\nDynamoDB Global Tables are a frequent topic on several AWS certification exams, particularly those focused on architecture and development.\n\n*   **AWS Certified Solutions Architect - Associate (SAA-C03):** Questions often focus on selecting Global Tables to meet requirements for low-latency global access, high availability, and disaster recovery.\n*   **AWS Certified Solutions Architect - Professional (SAP-C02):** Expect more in-depth scenarios involving complex multi-Region architectures, conflict resolution strategies, and cost-benefit analysis compared to other solutions like Aurora Global Database.\n*   **AWS Certified Developer - Associate (DVA-C02):** Questions may test your understanding of how to use Global Tables from an application perspective, including consistency models and the implications of the \"last writer wins\" behavior.\n\nExaminees should know the core use cases, the multi-active architecture, the eventual consistency model, and how it differs from a single-master solution like Aurora Global Database.\n\n## Frequently Asked Questions\n\n### Q: How does conflict resolution work in DynamoDB Global Tables?\nA: DynamoDB Global Tables use a \"last writer wins\" approach to resolve conflicts. If two different applications write to the same item in two different Regions at nearly the same time, DynamoDB determines the winner based on the write with the latest timestamp. All replica Regions will then converge on this winning version.\n\n### Q: Can I add a new AWS Region to an existing global table?\nA: Yes, you can add new replica tables in different AWS Regions to an existing global table at any time. DynamoDB will automatically stream the existing data to the new replica and then keep it in sync with ongoing changes. This allows you to expand your application's global footprint without downtime.\n\n### Q: What is the difference between replication with Global Tables and using DynamoDB Streams?\nA: DynamoDB Global Tables is a fully managed feature that uses DynamoDB Streams under the hood to handle replication automatically. While you could build a custom replication solution using DynamoDB Streams and [AWS Lambda](/terms/lambda) functions, this would require you to write, manage, and maintain the replication logic, error handling, and conflict resolution yourself. Global Tables abstract away all that complexity, providing a robust, out-of-the-box solution for multi-Region replication.\n\n---\n*This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the [official AWS documentation](https://docs.aws.amazon.com/) before making production decisions.*",
  "contentPlain": "# DynamoDB Global Tables: What It Is and When to Use It\n\n## Definition\n\nAmazon DynamoDB Global Tables is a fully managed, multi-active, and multi-Region database feature that replicates table data automatically across your choice of AWS Regions. It solves the problem of providing fast, low-latency data access to globally distributed users and building highly available, resilient applications that can withstand a full Region outage.\n\n## How It Works\n\nDynamoDB Global Tables are built on a multi-active architecture, meaning there is no single primary Region. An application can perform both read and write operations to any of the replica tables in any of the associated AWS Regions.\n\nWhen an application writes a new item or updates an existing one in a replica table, DynamoDB automatically propagates that write to all other replica tables in the global table. This replication process is asynchronous and typically completes within a second, a metric that can be monitored via Amazon CloudWatch.\n\nFor situations where applications in different Regions write to the same item at nearly the same time, conflicts are resolved using a \"last writer wins\" mechanism. DynamoDB uses the timestamp of the modification to determine the most recent update, and all replicas will eventually converge on that final version, ensuring eventual consistency across all Regions.\n\n## Key Features and Limits\n\n*   **Multi-Active Replication:** Read and write to any replica table in any Region, providing low-latency performance for global users.\n*   **High Availability:** Designed for 99.999% availability. If a single AWS Region becomes unavailable, your application can redirect traffic to another Region without needing a database failover.\n*   **Consistency Models:** Global tables can be configured with either multi-Region eventual consistency (the default) or multi-Region strong consistency. The consistency mode cannot be changed after the table is created.\n*   **Automatic Replication:** DynamoDB handles the complexity of replicating data and resolving conflicts, with no application code changes required to use the feature.\n*   **Multi-Account Support:** Replicas can be deployed across multiple AWS accounts, which is ideal for organizations that use multi-account strategies for security isolation and disaster recovery.\n*   **Item Size Limit:** Like standard DynamoDB tables, items in a Global Table cannot exceed 400 KB.\n*   **Global Secondary Indexes (GSIs):** GSIs are supported and are also replicated across all Regions. Each GSI has its own throughput settings.\n*   **Prerequisites:** To convert a single-Region table to a global table, DynamoDB Streams must be enabled with the `NEW_AND_OLD_IMAGES` view type.\n\n## Common Use Cases\n\n*   **Globally Distributed Applications:** Serve a global user base with fast, local read and write performance by placing data closer to the users, reducing latency for applications like social media, e-commerce, and content platforms.\n*   **Disaster Recovery and High Availability:** Build applications that can withstand the failure of an entire AWS Region. With a multi-active architecture, traffic can be seamlessly routed to a healthy Region, ensuring business continuity.\n*   **Real-Time Gaming:** Power applications like gaming leaderboards where real-time updates from players around the world need to be captured and reflected globally with minimal delay.\n*   **Content Delivery and Media:** Replicate user-generated content, metadata, and user profiles across the globe to ensure a consistent and fast experience for all users of a streaming or content platform.\n*   **Data Sovereignty and Compliance:** While data is replicated globally, applications can be architected to write and read sensitive data primarily from a specific \"home\" Region to help meet regulatory and data locality requirements.\n\n## Pricing Model\n\nThe cost of DynamoDB Global Tables has several components, and you pay only for the resources you use with no upfront fees.\n\n*   **Storage:** You are billed for the storage used by the table in *each* replica Region.\n*   **Reads:** Standard DynamoDB read charges (per million Read Request Units or per provisioned Read Capacity Unit-hour) apply in each Region where reads are performed.\n*   **Replicated Writes:** Instead of standard Write Capacity Units (WCUs), Global Tables use replicated Write Capacity Units (rWCUs). You are charged for rWCUs in *each* replica Region. For example, a write to a table with three replicas will incur rWCU charges in all three Regions.\n*   **Cross-Region Data Transfer:** Standard AWS data transfer charges apply for the data replicated between your chosen Regions.\n*   **Global Secondary Indexes (GSIs):** Writes to GSIs on a global table are billed as standard WCUs in each replica region, which can be a significant cost multiplier.\n*   **Reserved Capacity:** Replicated Write Capacity Units (rWCUs) are not eligible for Reserved Capacity discounts. However, the newer Database Savings Plans (launched in late 2025) may offer some savings.\n\nFor detailed estimates, use the official AWS Pricing Calculator.\n\n## Pros and Cons\n\n**Pros:**\n*   **Low Latency:** Provides single-digit millisecond read and write latency for global users by serving requests from the nearest AWS Region.\n*   **Extreme Resilience:** The multi-active architecture provides a robust solution for disaster recovery and high availability, often with a Recovery Point Objective (RPO) near zero.\n*   **Fully Managed:** AWS manages all the underlying infrastructure and replication logic, eliminating significant operational overhead compared to self-managed solutions.\n*   **Scalability:** Inherits the massive scalability of the standard DynamoDB service.\n\n**Cons:**\n*   **Increased Cost:** Replicating writes and storing data in multiple Regions incurs higher costs for throughput, storage, and data transfer compared to a single-Region table.\n*   **Eventual Consistency:** While replication is fast, it is asynchronous. Applications must be designed to handle a brief period where data may not be fully consistent across all Regions.\n*   **\"Last Writer Wins\" Conflict Resolution:** The default conflict resolution model is simple but may not be suitable for all workloads. Applications requiring complex conflict resolution logic (e.g., commutative counters) need to implement it in the application layer.\n*   **Transactional Limitations:** ACID transactions are supported but are only atomic within the Region where the transaction is initiated. They are not replicated as a single atomic unit to other Regions.\n\n## Comparison with Alternatives\n\n**DynamoDB Global Tables vs. Amazon Aurora Global Database:**\nThe primary alternative for a managed, multi-Region database on AWS is Amazon Aurora Global Database. The choice depends fundamentally on the data model required.\n\n*   **Data Model:** DynamoDB is a NoSQL (key-value and document) database, ideal for flexible schemas and high-velocity, unstructured data. Aurora is a relational SQL database (MySQL and PostgreSQL compatible), suited for structured data with complex relationships, joins, and transactional integrity.\n*   **Write Architecture:** DynamoDB Global Tables have a **multi-active** (or multi-master) architecture, allowing writes to any Region. Aurora Global Database uses a **single-master** model; writes can only be sent to the primary Region, while secondary Regions serve as low-latency read replicas.\n*   **Failover:** Failover in DynamoDB is handled by the application, which can simply redirect traffic to another active Region. In Aurora, a secondary Region must be manually promoted to become the new primary, a process that typically takes under a minute but is not automatic.\n\n## Exam Relevance\n\nDynamoDB Global Tables are a frequent topic on several AWS certification exams, particularly those focused on architecture and development.\n\n*   **AWS Certified Solutions Architect - Associate (SAA-C03):** Questions often focus on selecting Global Tables to meet requirements for low-latency global access, high availability, and disaster recovery.\n*   **AWS Certified Solutions Architect - Professional (SAP-C02):** Expect more in-depth scenarios involving complex multi-Region architectures, conflict resolution strategies, and cost-benefit analysis compared to other solutions like Aurora Global Database.\n*   **AWS Certified Developer - Associate (DVA-C02):** Questions may test your understanding of how to use Global Tables from an application perspective, including consistency models and the implications of the \"last writer wins\" behavior.\n\nExaminees should know the core use cases, the multi-active architecture, the eventual consistency model, and how it differs from a single-master solution like Aurora Global Database.\n\n## Frequently Asked Questions\n\n### Q: How does conflict resolution work in DynamoDB Global Tables?\nA: DynamoDB Global Tables use a \"last writer wins\" approach to resolve conflicts. If two different applications write to the same item in two different Regions at nearly the same time, DynamoDB determines the winner based on the write with the latest timestamp. All replica Regions will then converge on this winning version.\n\n### Q: Can I add a new AWS Region to an existing global table?\nA: Yes, you can add new replica tables in different AWS Regions to an existing global table at any time. DynamoDB will automatically stream the existing data to the new replica and then keep it in sync with ongoing changes. This allows you to expand your application's global footprint without downtime.\n\n### Q: What is the difference between replication with Global Tables and using DynamoDB Streams?\nA: DynamoDB Global Tables is a fully managed feature that uses DynamoDB Streams under the hood to handle replication automatically. While you could build a custom replication solution using DynamoDB Streams and AWS Lambda functions, this would require you to write, manage, and maintain the replication logic, error handling, and conflict resolution yourself. Global Tables abstract away all that complexity, providing a robust, out-of-the-box solution for multi-Region replication.\n\n---\n*This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the [official AWS documentation](https://docs.aws.amazon.com/) before making production decisions.*",
  "faq": [
    {
      "question": "How does conflict resolution work in DynamoDB Global Tables?",
      "answer": "DynamoDB Global Tables use a \"last writer wins\" approach to resolve conflicts. If two different applications write to the same item in two different Regions at nearly the same time, DynamoDB determines the winner based on the write with the latest timestamp. All replica Regions will then converge on this winning version."
    },
    {
      "question": "Can I add a new AWS Region to an existing global table?",
      "answer": "Yes, you can add new replica tables in different AWS Regions to an existing global table at any time. DynamoDB will automatically stream the existing data to the new replica and then keep it in sync with ongoing changes. This allows you to expand your application's global footprint without downtime."
    },
    {
      "question": "What is the difference between replication with Global Tables and using DynamoDB Streams?",
      "answer": "DynamoDB Global Tables is a fully managed feature that uses DynamoDB Streams under the hood to handle replication automatically. While you could build a custom replication solution using DynamoDB Streams and AWS Lambda functions, this would require you to write, manage, and maintain the replication logic, error handling, and conflict resolution yourself. Global Tables abstract away all that complexity, providing a robust, out-of-the-box solution for multi-Region replication."
    }
  ]
}