Ignore Autoscaling Changes
Adds ignore_changes = [read_capacity, write_capacity] to DynamoDB tables. Prevents Terraform from reverting autoscaler adjustments.
When to use this rule
Use this when: Your DynamoDB tables use Application Auto Scaling for read/write capacity, and every terraform plan shows capacity diffs.
Do not use this when: Your DynamoDB tables use PAY_PER_REQUEST (on-demand) billing mode, which has no read/write capacity attributes. Or you manually manage provisioned capacity without auto scaling.
Why this rule exists
DynamoDB tables with auto scaling enabled have their read and write capacity adjusted continuously by AWS Application Auto Scaling. Terraform sees these changes on every plan and proposes reverting them.
The fix is straightforward (add ignore_changes) but requires modifying every DynamoDB resource in every module. With upstream terraform-aws-modules, you cannot add this without forking.
Related Terraform and OpenTofu issues
| Repository | Issue | Title |
|---|---|---|
| hashicorp/terraform | #27360 | A method to override configuration and meta arguments within a module |
Affected resources
| Resource | Service | Why |
|---|---|---|
aws_dynamodb_table | Amazon DynamoDB | Capacity attributes managed by Application Auto Scaling |
What this rule does
Adds a lifecycle { ignore_changes = [...] } block to each matching resource. Terraform and OpenTofu will ignore external changes to the listed attributes on subsequent plans.
Ignored attributes: read_capacity, write_capacity
Before and after
Before (upstream module):
resource "aws_dynamodb_table" "this" {
# ... resource configuration ...
tags = var.tags
}After (with Ignore Autoscaling Changes applied):
resource "aws_dynamodb_table" "this" {
# ... resource configuration ...
tags = var.tags
lifecycle {
ignore_changes = [read_capacity, write_capacity]
}
}The only change is the rule transformation. All existing arguments, outputs, and module behavior remain identical.
Real-world scenario
A DynamoDB table with auto scaling adjusted read capacity from 5 to 50 during a traffic spike. The next terraform plan proposed reverting capacity back to 5, which would have caused throttling during peak hours.
Known limits
- Only affects
aws_dynamodb_table. Does not coveraws_dynamodb_global_tableor other DynamoDB resources. - Does not ignore changes to other auto-scaled attributes like GSI capacity.
- Only
.tfand.tofufiles are read. Modules written in JSON syntax (.tf.json,.tofu.json) are left untouched. - Only the module's own directory and its first-level
modules/*submodules are processed. Modules that this module calls by source URL are separate downloads and are handled on their own request.
Default configuration
These are the values the rule ships with. They are not settable from a module source URL: ?rules= carries rule names only, so a per-request enable uses exactly the defaults below. Your organization sets them per rule, in its Baseline or in a ruleset, from the Operational Rules page; see Baseline rules and rulesets.
| Parameter | Type | Default | Description |
|---|---|---|---|
ignore_changes | list(string) | ["read_capacity", "write_capacity"] | Lifecycle attributes to ignore |
resource_types | list(string) | ["aws_dynamodb_table"] | Target resource type patterns |
How to enable
On a framework host, per request:
Add ?rules=lifecycle_ignore_autoscaling_changes to your HTTPS module source. Use the full namespaced id. A bare lifecycle_ignore_autoscaling_changes matches no rule: it is skipped server-side and your terraform init still succeeds, without the rule.
module "example" {
source = "https://soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws?version=5.0.0&rules=lifecycle_ignore_autoscaling_changes"
}On your organization's host:
Add the rule to the organization's Baseline, which applies to every module served from the bare organization form <alias>.compliance.tf/<namespace>/<name>/<provider>, or to a named ruleset that one module selects with ?ruleset=<name> on the HTTPS form of that address. A project environment (<alias>.compliance.tf/<project>/<env>/<module>) serves the rules frozen in its bound snapshot instead: there the rule goes into the config draft and reaches the environment by promotion. On both organization forms ?rules= is refused with a 400 — including the subtractive - prefix — rather than dropped, so you cannot mistake an ignored override for an applied one. Change the configuration, not the URL. See Baseline rules and rulesets for the configuration flow, and registry resolution for how the address forms differ.
Failure modes
| Scenario | Result |
|---|---|
| Applied to a PAY_PER_REQUEST table | The lifecycle block is still added, and the configuration stays valid. On-demand tables set no provisioned capacity, so there is nothing for the rule to suppress. |
| You switch from PROVISIONED to PAY_PER_REQUEST | The ignore_changes block has no effect on PAY_PER_REQUEST tables. No action needed. |
Terraform and OpenTofu compatible
This rule works with both Terraform (1.x+) and OpenTofu (1.6+). It reads ordinary HCL, and anything it changes stays ordinary HCL, so the module behaves the same under either tool.
Help us improve this page
Operational Rules are a new feature. We'd love your feedback on this rule page — what's useful, what's missing, what's confusing. Share feedback.