Skill

configuring-auto-scaling-policies

Configures auto-scaling policies for AWS ASG, GCP MIG, Azure VMSS, and Kubernetes HPA. Generates Terraform, YAML, or CLI configs with metric thresholds and cooldowns.

AWS

GCP

From auto-scaling-configurator

Install

Run in your terminal

npx claudepluginhub nickloveinvesting/nick-love-plugins --plugin auto-scaling-configurator

Tool Access

This skill is limited to using the following tools:

ReadWriteEditGrepGlobBash(cmd:*)

Supporting Assets

View in Repository

assets/README.md

assets/config_template.yaml

assets/example_aws_scaling_policy.json

assets/example_hpa.yaml

references/README.md

scripts/README.md

scripts/generate_config.py

Skill Content

Similar Skills

ui-ux-pro-max

Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.

ui-ux-pro-max

57.6k

context7-mcp

Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.

context7-plugin

51.4k

market-sizing-analysis

2 files

Calculates TAM/SAM/SOM using top-down, bottom-up, and value theory methodologies for market sizing, revenue estimation, and startup validation.

startup-business-analyst

32.9k

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitMar 20, 2026

Actions

View Source View Plugin View on GitHub View README

Configuring Auto-Scaling Policies

Overview

Configure auto-scaling policies for cloud workloads across AWS Auto Scaling Groups, GCP Managed Instance Groups, Azure VMSS, and Kubernetes Horizontal Pod Autoscaler (HPA). Generate scaling configurations based on CPU, memory, request rate, or custom metrics with appropriate thresholds, cooldown periods, and scale-in protection.

Prerequisites

Cloud provider CLI installed and authenticated (aws, gcloud, or az)
For Kubernetes HPA: kubectl configured with cluster access and metrics-server deployed
Baseline performance data for the target workload (average CPU, memory, request rate)
Understanding of traffic patterns (steady, bursty, scheduled)
IAM permissions to create/modify scaling policies and CloudWatch/Stackdriver alarms

Instructions

Identify the scaling target: EC2 Auto Scaling Group, GCP MIG, Azure VMSS, or Kubernetes Deployment
Analyze current workload metrics to establish baseline utilization and peak patterns
Define scaling boundaries: minimum instances/pods, maximum instances/pods, desired count
Select scaling metric(s): CPU utilization, memory, request count, queue depth, or custom metrics
Set target thresholds: scale-out trigger (e.g., CPU > 70%), scale-in trigger (e.g., CPU < 30%)
Configure cooldown periods to prevent flapping (typically 300s scale-out, 600s scale-in)
Add scale-in protection for stateful workloads or leader nodes if needed
Generate the scaling policy configuration in the appropriate format (Terraform, YAML, or CLI commands)
Validate by simulating load and confirming scaling events fire correctly

Output

Terraform HCL for AWS ASG scaling policies with CloudWatch alarms
Kubernetes HPA manifests (YAML) with resource or custom metric targets
GCP autoscaler configurations for Managed Instance Groups
Scaling policy JSON/YAML for Azure VMSS
CloudWatch or Stackdriver alarm definitions tied to scaling actions

Error Handling

Error	Cause	Solution
`No scaling activity despite high load`	Metric not reaching threshold or cooldown active	Verify metric source in CloudWatch/Stackdriver; check cooldown timer with `describe-scaling-activities`
`Scaling too aggressively (flapping)`	Cooldown too short or threshold too sensitive	Increase cooldown period and widen the gap between scale-out and scale-in thresholds
`Max capacity reached`	Instance/pod limit hit during traffic spike	Raise `max_size` or implement request queuing as a backpressure mechanism
`HPA unable to compute replica count`	Metrics server not deployed or metric unavailable	Install metrics-server and verify `kubectl top pods` returns data
`FailedScaleUp: insufficient capacity`	Cloud provider out of capacity in selected AZ/region	Add multiple AZs to the ASG or use mixed instance types with allocation strategy

Examples

"Configure an AWS ASG with target tracking at 65% CPU, min 2 / max 20 instances, and 5-minute cooldown."
"Create a Kubernetes HPA for a deployment that scales from 3 to 50 pods based on requests-per-second using a custom Prometheus metric."
"Set up scheduled scaling for a GCP MIG: scale to 10 instances at 8am UTC and back to 2 at 10pm."

Resources

AWS Auto Scaling: https://docs.aws.amazon.com/autoscaling/ec2/userguide/
Kubernetes HPA: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
GCP Autoscaler: https://cloud.google.com/compute/docs/autoscaler
Azure VMSS Autoscale: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-autoscale-overview