Describe the issue
The aws provider (6.x) deprecates hash_key/range_key on aws_dynamodb_table in favour of key_schema. Every AFT plan/apply currently emits:
Warning: Argument is deprecated
with module.aft.module.aft_account_request_framework.aws_dynamodb_table.aft_request_metadata,
on modules/aft-account-request-framework/ddb.tf line 5
hash_key is deprecated. Use key_schema instead.
Notably, the warning count grew from 2 to 4 with 1.21.1: the newly added aft-customizations-audit table also uses the deprecated arguments — new code is still being written in the old style, which suggests this isn't on the migration radar yet.
Why it matters
Deprecation in 6.x is the pre-announcement of removal in the next major. When that lands, terraform plan fails outright for every AFT deployment until the module ships a fix — and the module currently declares aws >= 6.0.0, < 7.0.0, so consumers can't get ahead of it either. This is the same shape as #630 (module code broken by provider movement within/at the declared constraint range): the affected workspace is typically an organisation's management-account bootstrap, where a broken plan has the worst recovery story.
Expected behavior
Migrate the aws_dynamodb_table resources (four sites incl. the new audit table) to key_schema, ideally before the provider's next major forces it under time pressure.
Environment
- AFT version: 1.21.1
- aws provider: 6.56/6.57 (warning present across 6.x)
Happy to raise a PR — the migration is mechanical and plan-neutral (same key schema, new syntax).
Describe the issue
The aws provider (6.x) deprecates
hash_key/range_keyonaws_dynamodb_tablein favour ofkey_schema. Every AFT plan/apply currently emits:Notably, the warning count grew from 2 to 4 with 1.21.1: the newly added
aft-customizations-audittable also uses the deprecated arguments — new code is still being written in the old style, which suggests this isn't on the migration radar yet.Why it matters
Deprecation in 6.x is the pre-announcement of removal in the next major. When that lands,
terraform planfails outright for every AFT deployment until the module ships a fix — and the module currently declaresaws >= 6.0.0, < 7.0.0, so consumers can't get ahead of it either. This is the same shape as #630 (module code broken by provider movement within/at the declared constraint range): the affected workspace is typically an organisation's management-account bootstrap, where a broken plan has the worst recovery story.Expected behavior
Migrate the
aws_dynamodb_tableresources (four sites incl. the new audit table) tokey_schema, ideally before the provider's next major forces it under time pressure.Environment
Happy to raise a PR — the migration is mechanical and plan-neutral (same key schema, new syntax).