This error occurs when attempting to create a DynamoDB global table with a name that already exists in your AWS account. Global tables require unique names within the same AWS account and cannot be duplicated.
The GlobalTableAlreadyExistsException is thrown by DynamoDB when you call the CreateGlobalTable API with a table name that has already been used for an existing global table. Global tables create replication relationships between two or more DynamoDB tables with the same table name across different AWS regions. Since global table names must be unique within your AWS account, attempting to create a second global table with the same name will fail. This error is specific to global tables and differs from regular table creation errors. It typically happens when infrastructure-as-code tools like CloudFormation, CDK, or Terraform attempt to create a global table that already exists, or when manual API calls are made without first checking for existing global tables. Note that AWS recommends using Global Tables version 2019.11.21 (Current) rather than the legacy 2017.11.29 version, as the current version provides greater flexibility, higher efficiency, and consumes less write capacity.
First, verify whether the global table exists in your AWS account. Use the AWS CLI to list all global tables:
aws dynamodb list-global-tables --region us-east-1Or check for a specific table:
aws dynamodb describe-global-table --global-table-name YourTableName --region us-east-1If the table exists and is the one you want to use, skip the creation step and reference the existing table instead.
If the global table already exists and meets your requirements, modify your infrastructure code to reference it instead of creating a new one.
For AWS CDK (TypeScript):
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
// Reference existing global table instead of creating new one
const existingTable = dynamodb.TableV2.fromTableName(
this,
'ExistingGlobalTable',
'YourTableName'
);For CloudFormation, remove the AWS::DynamoDB::GlobalTable resource and use the table name directly in your application configuration.
If you need to recreate the global table with different settings, delete the existing one first. WARNING: This will delete all data in the table across all regions.
# Delete the global table
aws dynamodb delete-table --table-name YourTableName --region us-east-1After deletion, wait 2-5 minutes before attempting to recreate the table with the same name. DynamoDB needs time to fully clean up the table and its replicas across regions.
Verify deletion:
aws dynamodb describe-table --table-name YourTableName --region us-east-1
# Should return ResourceNotFoundException when fully deletedIf you deleted a global table but still get this error, replicas may exist in other regions. Check all regions where the table had replicas:
# Check each region where replicas existed
aws dynamodb describe-table --table-name YourTableName --region us-west-2
aws dynamodb describe-table --table-name YourTableName --region eu-west-1
aws dynamodb describe-table --table-name YourTableName --region ap-southeast-1If orphaned replicas exist, delete them manually:
aws dynamodb delete-table --table-name YourTableName --region us-west-2
aws dynamodb delete-table --table-name YourTableName --region eu-west-1Wait a few minutes after deleting all replicas before attempting to recreate the global table.
If you cannot delete the existing global table (e.g., it's in use by production systems), choose a different name for your new global table.
Update your infrastructure code with the new name:
// CDK example
const globalTable = new dynamodb.TableV2(this, 'NewGlobalTable', {
tableName: 'YourTableName-v2', // Different name
partitionKey: { name: 'pk', type: dynamodb.AttributeType.STRING },
replicas: [
{ region: 'us-west-2' },
{ region: 'eu-west-1' },
],
});Remember to update your application code to use the new table name.
To prevent future occurrences, add logic to check if the table exists before attempting creation.
For AWS CDK, use a custom resource:
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as cr from 'aws-cdk-lib/custom-resources';
// Check if table exists
const checkTable = new cr.AwsCustomResource(this, 'CheckTable', {
onUpdate: {
service: 'DynamoDB',
action: 'describeTable',
parameters: {
TableName: 'YourTableName',
},
ignoreErrorCodesMatching: 'ResourceNotFoundException',
},
policy: cr.AwsCustomResourcePolicy.fromSdkCalls({
resources: cr.AwsCustomResourcePolicy.ANY_RESOURCE,
}),
});
// Create table only if it doesn't exist
const tableExists = checkTable.getResponseField('Table.TableName');For Terraform, use data sources to check existence before creation.
Global Tables Version Differences: AWS offers two versions of global tables. The legacy version (2017.11.29) and the current version (2019.11.21). The current version is strongly recommended as it provides better performance, lower write capacity consumption, and simpler configuration. When creating new global tables, always use the 2019.11.21 version.
Global Table Name Scope: Global table names must be unique within an AWS account, but they can exist in multiple regions as replicas. The name collision check is account-wide, not region-specific.
DeletionPolicy for CloudFormation: When using CloudFormation, consider setting DeletionPolicy: Retain on global table resources to prevent accidental deletion when stacks are removed. This is especially important for production tables.
Multi-Environment Strategies: For multiple environments (dev, staging, production), use environment-specific prefixes or suffixes in table names (e.g., prod-users-table, dev-users-table) to avoid naming conflicts.
Global Table Migration: If you need to migrate from a regular DynamoDB table to a global table, you cannot simply "convert" it if a global table with that name already exists. You must either delete the existing global table first or use a different name for the new configuration.
API Throttling: When creating or deleting global tables programmatically, be aware of DynamoDB API rate limits. Creating multiple global tables in quick succession may trigger throttling errors. Implement exponential backoff in your automation scripts.
ImportConflictException: There was a conflict when attempting to import to the table
How to fix 'ImportConflictException: There was a conflict when attempting to import to the table' in DynamoDB
ResourceNotFoundException: Requested resource not found
How to fix "ResourceNotFoundException: Requested resource not found" in DynamoDB
TrimmedDataAccessException: The requested data has been trimmed
How to fix "TrimmedDataAccessException: The requested data has been trimmed" in DynamoDB Streams
GlobalTableNotFoundException: Global Table not found
How to fix "GlobalTableNotFoundException: Global Table not found" in DynamoDB
InvalidExportTimeException: The specified ExportTime is outside of the point in time recovery window
How to fix "InvalidExportTimeException: The specified ExportTime is outside of the point in time recovery window" in DynamoDB