DynamoDB Tables

Tables are declared as DynamoTableConfig entries and instantiated by AtfDynamo inside the DataStack. Because DynamoTableConfig extends Omit<TableProps>, every CDK Table prop is available — there is no ceiling.

The tricky-case matrix

The framework’s example-rest-full deliberately exercises the hard cases in two contrast tables:

• Table A — composite key (pk + sk), two GSIs (ALL projection + INCLUDE with nonKeyAttributes), stream NEW_AND_OLD_IMAGES, and TTL.
• Table B — PK-only contrast table on PROVISIONED billing (RCU/WCU).

Each is asserted in the example’s tests/synth.test.ts, so the shapes below are known-good.

Construct IDs are user-controlled here

Unlike most Axis constructs, AtfDynamo uses each table’s constructId directly as the CloudFormation logical ID — different projects declare their own tables with their own stable IDs. That makes logical-ID permanence your responsibility for tables: renaming a table’s constructId after deploy replaces the table. See Logical-ID Permanence.

Adding a table with the CLI

axs add table orders

See the axs add table reference.

SSM outputs

DataStack writes each table’s tableName, tableArn, and (when present) streamArn to SSM under /{app}/{stage}/dynamodb/{baseName}/..., so other stacks resolve them without CloudFormation exports. Lambda env tokens like {{dynamodb.mainTable.tableName}} resolve against these.

Where to go next

• AtfDynamo for the full prop surface.
• Stacks & SSM Wiring for how tables cross stack boundaries.