feat: Add support for predictive autoscaling policies #361

zahorniak · 2025-10-06T13:03:16Z

Description

Added support for predefined metrics
- predefined_load_metric_specification
- predefined_metric_pair_specification
- predefined_scaling_metric_specification
Added support for customized metrics
- customized_capacity_metric_specification
- customized_load_metric_specification
- customized_scaling_metric_specification

Motivation and Context

Closes Add support for predictive_scaling_policy_configuration configuration block for service autoscaling #352

Breaking Changes

No

How Has This Been Tested?

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

I have executed pre-commit run -a on my pull request

zahorniak · 2025-10-06T14:31:41Z

I want to address a naming inconsistency across target_tracking_scaling_policy_configuration.customized_metric_specification.dimensions and customized_*_specification.metric_data_query.metric_stat.metric.dimension:

Target tracking using dimensionS while all predictive scaling metrics use dimension naming. In the module configuration, I decided to use dimensions everywhere to keep the same object structure as you already have for target tracking policies:

metrics = optional(list(object({
  expression = optional(string)
  id         = string
  label      = optional(string)
  metric_stat = optional(object({
    metric = object({
      dimensions = optional(list(object({
        name  = string
        value = string
      })))
      metric_name = string
      namespace   = string
    })
    stat = string
    unit = optional(string)
  }))
  return_data = optional(bool)
})))

I believe it can help prevent mistakes or typos when using multiple scaling policies for a single service.

bryantbiggs · 2025-10-07T21:14:13Z

I want to address a naming inconsistency across target_tracking_scaling_policy_configuration.customized_metric_specification.dimensions and customized_*_specification.metric_data_query.metric_stat.metric.dimension:
* [registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimensions-1](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimensions-1)

* [registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimension-1](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_policy#dimension-1)
Target tracking using dimensionS while all predictive scaling metrics use dimension naming. In the module configuration, I decided to use dimensions everywhere to keep the same object structure as you already have for target tracking policies:
metrics = optional(list(object({
  expression = optional(string)
  id         = string
  label      = optional(string)
  metric_stat = optional(object({
    metric = object({
      dimensions = optional(list(object({
        name  = string
        value = string
      })))
      metric_name = string
      namespace   = string
    })
    stat = string
    unit = optional(string)
  }))
  return_data = optional(bool)
})))
I believe it can help prevent mistakes or typos when using multiple scaling policies for a single service.

thats due to the API - https://github.com/hashicorp/terraform-provider-aws/blob/782cca0e2343caa5ee37950708d563ef25a95aa7/internal/service/appautoscaling/policy.go#L249

vs https://github.com/hashicorp/terraform-provider-aws/blob/782cca0e2343caa5ee37950708d563ef25a95aa7/internal/service/appautoscaling/policy.go#L451

We usually try to match the underlying API since thats the easiest and least confusing, only deviating in select scenarios

bryantbiggs

great start! few changes to the structure and definitions

bryantbiggs · 2025-10-07T21:16:18Z

modules/service/main.tf

    }
  }
+
+  dynamic "predictive_scaling_policy_configuration" {


general comment, lets follow the order of fields on the AWS provider. It makes it easier to check and compare https://github.com/hashicorp/terraform-provider-aws/blob/782cca0e2343caa5ee37950708d563ef25a95aa7/internal/service/appautoscaling/policy.go#L67

bryantbiggs · 2025-10-07T21:17:25Z

modules/service/main.tf

+    for_each = each.value.policy_type == "PredictiveScaling" && each.value.predictive_scaling_policy_configuration != null ? [each.value.predictive_scaling_policy_configuration] : []
+
+    content {
+      mode                         = try(predictive_scaling_policy_configuration.value.mode, null)


with variable optional attributes, we can drop all the try() wrappings. you can refer to the target_tracking_scaling_policy_configuration for reference

bryantbiggs · 2025-10-07T21:18:47Z

modules/service/variables.tf

      scale_out_cooldown = optional(number, 60)
      target_value       = optional(number, 75)
    }))
+    predictive_scaling_policy_configuration = optional(object({


and same here, lets follow the order of fields on the AWS provider which also follows the order of the implementation in this module

bryantbiggs · 2025-10-07T21:19:52Z

modules/service/variables.tf

+      max_capacity_buffer          = optional(number)
+      max_capacity_breach_behavior = optional(string)
+      scheduling_buffer_time       = optional(number)
+      metric_specification = object({


this should be of type list(object{ ... per https://github.com/hashicorp/terraform-provider-aws/blob/782cca0e2343caa5ee37950708d563ef25a95aa7/internal/service/appautoscaling/policy.go#L84-L85

bryantbiggs · 2025-10-07T21:21:05Z

modules/service/variables.tf

+          }))
+        }))
+        customized_scaling_metric_specification = optional(object({
+          metric_data_query = list(object({


outer type should change to optional(object{... per https://github.com/hashicorp/terraform-provider-aws/blob/782cca0e2343caa5ee37950708d563ef25a95aa7/internal/service/appautoscaling/policy.go#L416-L417

bryantbiggs · 2025-10-07T21:22:19Z

modules/service/variables.tf

+                  value = string
+                })))
+                metric_name = string
+                namespace   = string


Suggested change

namespace = string

namespace = optional(string)

bryantbiggs · 2025-10-07T21:22:57Z

modules/service/variables.tf

+            return_data = optional(bool)
+          }))
+        }))
+        customized_capacity_metric_specification = optional(object({


same type as the corrected customized_scaling_metric_specification

bryantbiggs · 2025-10-07T21:23:05Z

modules/service/variables.tf

+          predefined_metric_type = string
+          resource_label         = optional(string)
+        }))
+        customized_load_metric_specification = optional(object({


same type as the corrected customized_scaling_metric_specification

bryantbiggs · 2025-10-07T21:24:23Z

modules/service/variables.tf

      target_value       = optional(number, 75)
    }))
+    predictive_scaling_policy_configuration = optional(object({
+      mode                         = optional(string, "ForecastAndScale")


whats the reasoning behind this default value?

bryantbiggs · 2025-10-07T21:25:18Z

variables.tf

        scale_out_cooldown = optional(number)
        target_value       = optional(number)
      }))
+      predictive_scaling_policy_configuration = optional(object({


update this once the corrections to module/service/variables.tf are made

zahorniak added 4 commits September 15, 2025 20:21

wip

14b4bca

Merge remote-tracking branch 'origin/master' into predictive-scaling

84bf38e

add predefined metrics

78a8bd6

add customized metrics support

06b0616

zahorniak marked this pull request as ready for review October 6, 2025 14:34

zahorniak changed the title ~~wip: Add support for predictive autoscaling~~ feat: Add support for predictive autoscaling policies Oct 6, 2025

fix pre-commit

1bcc81f

bryantbiggs reviewed Oct 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

feat: Add support for predictive autoscaling policies #361

feat: Add support for predictive autoscaling policies #361

zahorniak commented Oct 6, 2025 •

edited

Loading

Uh oh!

zahorniak commented Oct 6, 2025

Uh oh!

bryantbiggs commented Oct 7, 2025

Uh oh!

bryantbiggs left a comment

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

bryantbiggs Oct 7, 2025

Uh oh!

Uh oh!

Uh oh!

feat: Add support for predictive autoscaling policies #361

Are you sure you want to change the base?

feat: Add support for predictive autoscaling policies #361

Conversation

zahorniak commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Motivation and Context

Breaking Changes

How Has This Been Tested?

Uh oh!

zahorniak commented Oct 6, 2025

Uh oh!

bryantbiggs commented Oct 7, 2025

Uh oh!

bryantbiggs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

zahorniak commented Oct 6, 2025 •

edited

Loading