aws dynamodb describe-table \
  --table-name Orders \
  --output json > orders-table.json

aws dynamodb describe-table --table-name Orders --output json \
| jq '.Table | { TableName, AttributeDefinitions, KeySchema, BillingModeSummary, ProvisionedThroughput, GlobalSecondaryIndexes, LocalSecondaryIndexes, StreamSpecification, SSEDescription }' > orders-schema.json ``` You may still want to post-process this further depending on whether the destination tool expects the same field names as `describe-table` or as `create-table`. ### Export through Boto3 when you need automation If this needs to run inside a script or pipeline, Boto3 gives you the same information programmatically. ```python import boto3 import json client = boto3.client("dynamodb", region_name="us-east-1") response = client.describe_table(TableName="Orders") with open("orders-table.json", "w", encoding="utf-8") as fh: json.dump(response["Table"], fh, indent=2, default=str) ``` From there you can filter fields, normalize naming, or emit a format expected by CloudFormation, Terraform, or internal tooling. ### Know the difference between documentation and infrastructure export There are two common goals: - document what the current table looks like - generate a portable definition for recreating it Those are related but not identical. A raw `describe-table` dump is great for documentation and debugging. A recreation template usually needs cleanup, because not every returned field is accepted by `create-table` and some fields are runtime state rather than declarative schema. ### Consider Infrastructure as Code if the goal is repeatability If you routinely need to recreate DynamoDB tables, exporting ad hoc JSON from live tables may be a sign that the table definition should live in CloudFormation, CDK, Terraform, or another infrastructure-as-code system. Exporting from a live table is useful, but long-term repeatability is usually better when the schema is defined as code and the live table is the result of that code rather than the source of truth. ## Common Pitfalls - Assuming `describe-table` output can always be fed directly back into `create-table` without trimming runtime-only fields. - Exporting the schema from the wrong region or account and then wondering why the definition does not match the table you expected. - Treating operational metadata such as status timestamps as if they were part of the portable table definition. - Forgetting that index definitions and billing-related settings are part of the effective schema and need to be captured too. - Using live-table export as the only source of truth when the table should really be represented in infrastructure-as-code tooling. ## Summary - Exporting a DynamoDB schema to JSON usually means calling `describe-table` and saving the response. - The AWS CLI is the quickest path, and Boto3 is the best choice for automation. - Raw output is useful for documentation, but reusable schema artifacts usually need filtering. - Distinguish between “snapshot of the live table” and “portable recreation template.” - If repeatability matters, treat infrastructure as code as the long-term source of truth.