Ignore Scaling Changes

Adds ignore_changes for the capacity attribute an external autoscaler owns on Auto Scaling groups, EKS node groups and ECS services.

Why this rule exists

An autoscaler changes the desired capacity many times a day. Terraform state holds the number from the last apply, so every plan reads the live value as drift and proposes setting it back, and an apply that goes through undoes the scaler.

The fix is ignore_changes on exactly that attribute, and a lifecycle block cannot be passed into an upstream module as a variable.

Related Terraform and OpenTofu issues

Limitations this rule answers

Per-module pages under Workarounds where this rule is the answer, each with the native workaround first and the diff the rule makes:

• Auto Scaling: Auto Scaling group desired_capacity reverts on every apply
• ECS: ECS service desired_count keeps resetting
• EKS: EKS node group desired_size changes on every plan

Affected resources

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: desired_capacity 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: scaling_config[0].desired_size 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: desired_count

Before and after

Before (upstream module):

resource "aws_autoscaling_group" "this" {
  # ... resource configuration ...

  tags = var.tags
}

After (with Ignore Scaling Changes applied):

resource "aws_autoscaling_group" "this" {
  # ... resource configuration ...

  tags = var.tags

  lifecycle {
    ignore_changes = [desired_capacity]
  }
}

Before (upstream module):

resource "aws_autoscaling_group" "this" {
  # ... resource configuration ...

  tags = var.tags
}

After (with Ignore Scaling Changes applied):

resource "aws_autoscaling_group" "this" {
  # ... resource configuration ...

  tags = var.tags

  lifecycle {
    ignore_changes = [scaling_config[0].desired_size]
  }
}

Before (upstream module):

resource "aws_autoscaling_group" "this" {
  # ... resource configuration ...

  tags = var.tags
}

After (with Ignore Scaling Changes applied):

resource "aws_autoscaling_group" "this" {
  # ... resource configuration ...

  tags = var.tags

  lifecycle {
    ignore_changes = [desired_count]
  }
}

The only change is the rule transformation. All existing arguments, outputs, and module behavior remain identical.

The example above is illustrative. To see this rule run for real, open it in the Rules Playground — it applies lifecycle_ignore_scaling_changes to a reviewed upstream module that actually declares the resources this rule targets, and shows the diff the registry would serve. No account needed.

Known limits

• Only the desired-capacity attribute on each of the three resource types. min_size and max_size stay managed, which is how the scaler's bounds remain under Terraform's control.
• Each attribute list is a parameter; an organization can set one to [] to contribute nothing for that resource type.
• DynamoDB capacity is a separate rule, lifecycle_ignore_autoscaling_changes.
• Only .tf and .tofu files 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.

The rule's definition

The HCL this rule is written in - its parameters, their shipped defaults, and the transformers it runs - is published at lifecycle_ignore_scaling_changes, alongside every other selectable rule.

How to enable

On a framework host, per request:

Add ?rules=lifecycle_ignore_scaling_changes to your HTTPS module source, using the id exactly as written.

module "example" {
  source = "https://soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws?version=5.0.0&rules=lifecycle_ignore_scaling_changes"
}

A ?rules= list is either all bare names, which replace your organization's rules for that download, or all - prefixed names, which subtract from them. Mixing the two is refused with a 400 rather than silently treated as a replacement. To add this rule on top of your organization's rules instead, use ?add_rules=lifecycle_ignore_scaling_changes; a bare ?rules= list cannot be combined with it, because a bare list already replaced the set there was something to add to.

The + add prefix was removed. It reached the registry only when written %2B, and a literal + in a query string decodes to a space everywhere, so ?rules=+lifecycle_ignore_scaling_changes arrived as a bare name with a leading space — one step from silently replacing your organization's rules. Any +, in either spelling, is now a 400 naming ?add_rules=.

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= and ?add_rules= are 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.

Break-glass path

On a framework host, add ?rules=-lifecycle_ignore_scaling_changes to the module source URL and run terraform init -upgrade to fetch a copy without this rule. The copy in .terraform/modules/ stays until the next upgrade, so remove the override when you are done. On your organization's host the parameter is refused with a 400 rather than ignored. The rule comes from the organization's configuration: a Baseline rule applies to every module served from the bare organization form, so an admin disables it for the duration of the operation, or keeps it out of the Baseline and in a ruleset that only the modules needing it select. On a project environment the posture is the bound snapshot and its waivers. See Baseline rules and rulesets.

Failure modes