Skip to content

Conversation

@xnick123
Copy link

@xnick123 xnick123 commented Dec 3, 2025

Description

Added support for ignoring AWS-managed warm throughput drift in DynamoDB tables using PAY_PER_REQUEST billing mode. This change introduces a new ignore_warm_throughput_changes variable and a fourth resource variant (warm_throughput_ignore) that uses lifecycle rules to ignore only warm throughput attribute changes while still detecting other configuration drift.
Closes #112

Motivation and Context

When using PAY_PER_REQUEST billing mode, AWS automatically adjusts warm throughput values (read_units_per_second and write_units_per_second) for tables and GSIs based on usage patterns at no additional cost. This causes perpetual Terraform drift where the module detects changes even though no intentional modifications were made to the configuration.

According to AWS documentation: "Warm throughput values are available by default for all tables and GSIs at no cost" and "DynamoDB will automatically adjust warm throughput values as your usage increases."

This change addresses the issue by:

  • Following the existing module pattern (similar to ignore_changes_global_secondary_index)
  • Providing granular control - ignores only warm throughput drift, not all GSI changes
  • Allowing users to opt-in via ignore_warm_throughput_changes = false (default)
  • Supporting intentional warm throughput changes when needed (for pre-warming before peak events)

Related issue: [Link to issue if created]

Breaking Changes

No breaking changes. This is a new opt-in feature with ignore_warm_throughput_changes defaulting to false, maintaining backward compatibility.

Note: Enabling ignore_warm_throughput_changes on an existing table requires a state move operation:
terraform state mv module.dynamodb_table.aws_dynamodb_table.this module.dynamodb_table.aws_dynamodb_table.warm_throughput_ignore

How Has This Been Tested?

I wanted to avoid the effort of testing, in case i oversaw something and my request is not applicable or wanted in the context of the module. Let me know if i shall proceed and happy to go through below

  • I have updated at least one of the examples/* to demonstrate and validate my change(s)
  • I have tested and validated these changes using one or more of the provided examples/* projects
  • Tested with existing PAY_PER_REQUEST table experiencing warm throughput drift
  • Verified that setting ignore_warm_throughput_changes = true eliminates drift
  • Confirmed other GSI changes (name, hash_key, projection_type) are still detected
  • Validated state move operation when enabling the flag on existing tables
  • I have executed pre-commit run -a on my pull request

Changes Made

  1. main.tf:

    • Updated locals.dynamodb_table_arn to include new warm_throughput_ignore resource
    • Modified first resource condition to exclude when ignore_warm_throughput_changes = true
    • Added aws_dynamodb_table.warm_throughput_ignore resource with lifecycle block that ignores only the warm_throughput attribute changes in global secondary indexes and at the table level, while still detecting changes to other GSI properties. The lifecycle block includes indices [0] through [19] to cover all possible GSIs, as AWS allows a maximum of 20 global secondary indexes per DynamoDB table.
  2. variables.tf:

    • Added ignore_warm_throughput_changes variable (default: false)
  3. README.md:

    • Added warning section explaining AWS-managed warm throughput drift
    • Documented the state move command required when enabling the flag
    • Included guidance for intentional warm throughput changes (pre-warming scenarios)

@xnick123 xnick123 changed the title Drift on warm throughput Closes #112 Drift on warm throughput Dec 3, 2025
@bryantbiggs
Copy link
Member

thank you, but we are not going to take this approach - we will wait for #112 (comment)

@bryantbiggs bryantbiggs closed this Dec 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Drift on warm throughput

2 participants