canonical: https://jentic.com/apis/amazonaws.com/autoscaling

# AWS Amazon EC2 Auto Scaling

Amazon EC2 Auto Scaling launches and terminates EC2 instances automatically in response to demand, scheduled actions, and instance health checks. The API lets you create Auto Scaling groups, define launch templates and configurations, attach load balancers and target groups, configure scaling policies driven by CloudWatch alarms, and set lifecycle hooks for graceful instance bring-up and tear-down. It is the control plane for keeping a fleet of EC2 instances at the size your workload requires while replacing failed instances and balancing them across Availability Zones.

## For AI agents

Create and manage EC2 Auto Scaling groups, scaling policies, scheduled actions, and lifecycle hooks so an agent can keep an EC2 fleet sized to demand and replace unhealthy instances automatically.

## Scope

Does not provision EC2 instances directly, manage Kubernetes node pools, or scale ECS services. Use for EC2 Auto Scaling group capacity management only.

## Capabilities

- Create Auto Scaling groups bound to a launch template, with min/max/desired capacity across one or more Availability Zones
- Attach Application Load Balancer target groups and Classic Load Balancers to an Auto Scaling group so new instances receive traffic automatically
- Configure target tracking, step, and simple scaling policies driven by CloudWatch metrics such as CPU utilisation or request count
- Schedule capacity changes ahead of known traffic patterns using PutScheduledUpdateGroupAction
- Set instance lifecycle hooks to drain connections or run bootstrapping work before an instance is launched or terminated
- Mark instances unhealthy with SetInstanceHealth so Auto Scaling replaces them on the next health check
- Enable instance refresh to roll out a new launch template version across the group with a target healthy percentage

## Use cases

### Demand-Based Web Fleet Scaling

Run a stateless web tier that grows and shrinks with traffic. Define an Auto Scaling group bound to a launch template, attach an Application Load Balancer target group, and add a target tracking policy that holds average CPU at 50 percent. EC2 Auto Scaling adds instances when demand rises, removes them when it falls, and replaces any that fail an EC2 or ELB health check. Initial setup takes a few hours including launch template, IAM role, and ALB wiring.

Example prompt: Create an Auto Scaling group named web-prod with min 2, desired 4, max 20 across three AZs, attach target group arn:aws:elasticloadbalancing:..., and add a target tracking policy keeping ASGAverageCPUUtilization at 50.

### Scheduled Capacity for Predictable Traffic

Pre-warm capacity before a known traffic spike, such as Monday 9am, an end-of-month batch run, or a scheduled marketing send, without paying for unused instances overnight. Use PutScheduledUpdateGroupAction to set min, max, and desired capacity at specific times in cron-style schedules. EC2 Auto Scaling adjusts the group at the scheduled time and lets the regular scaling policies take over once load arrives.

Example prompt: Create a scheduled action on Auto Scaling group web-prod that sets min=10, desired=15 every weekday at 08:30 UTC and reverts to min=2, desired=4 at 19:00 UTC.

### Rolling AMI Rollout with Instance Refresh

Deploy a new AMI or launch template version across an Auto Scaling group without manually cycling instances. StartInstanceRefresh replaces instances in batches with a configurable minimum healthy percentage and warm-up period, pausing if health checks fail. Suitable for OS patching, agent upgrades, or rolling out a new application version on long-lived instances.

Example prompt: Update the launch template for web-prod to AMI ami-0abc123, then call StartInstanceRefresh with MinHealthyPercentage=90 and InstanceWarmup=300, polling DescribeInstanceRefreshes until status is Successful.

### Agent-Driven Capacity Operator

Give an AI ops agent the ability to react to sustained load anomalies that fall outside static scaling policies, such as a sudden viral mention, an unusual customer cohort, or an upstream incident draining capacity. The agent calls EC2 Auto Scaling through Jentic to inspect group state, adjust desired capacity within configured bounds, kick off an instance refresh, or temporarily suspend scaling during an incident, all behind Jentic-managed AWS credentials so the human operator never hands a long-lived secret to the agent.

Example prompt: Search Jentic for 'set desired capacity on an auto scaling group', load the SetDesiredCapacity schema, and execute it on web-prod with desired=12 after confirming current CPU > 80 percent for 10 minutes.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /#Action=CreateAutoScalingGroup | Create an Auto Scaling group |
| POST | /#Action=UpdateAutoScalingGroup | Update group capacity, AZs, or launch template |
| POST | /#Action=DescribeAutoScalingGroups | List Auto Scaling groups and their state |
| POST | /#Action=SetDesiredCapacity | Set the desired capacity on a group |
| POST | /#Action=PutScalingPolicy | Create or update a scaling policy |
| POST | /#Action=PutScheduledUpdateGroupAction | Schedule a capacity change |
| POST | /#Action=StartInstanceRefresh | Roll out a new launch template version |
| POST | /#Action=AttachLoadBalancerTargetGroups | Attach ALB/NLB target groups to a group |

## Key resources

- **Auto Scaling Groups** — Create, describe, update, and delete groups; set desired capacity; suspend or resume processes.
- **Launch Configurations and Templates** — Manage launch configurations and integrate with EC2 launch templates that define the instance shape.
- **Scaling Policies** — Target tracking, step, and simple scaling policies tied to CloudWatch alarms.
- **Scheduled Actions** — Time-based capacity changes via PutScheduledUpdateGroupAction.
- **Lifecycle Hooks** — Pause instances entering or leaving the group so external work can complete.
- **Instance Refresh** — Roll out new launch template versions across the group with health-aware batching.

## Why Jentic

- **Setup:** Wiring Amazon EC2 Auto Scaling by hand means creating IAM credentials, choosing the right regional host from autoscaling.{region}.amazonaws.com, signing every query request with AWS SigV4, and adding your own retry and pagination handling. Through Jentic you install once, import Amazon EC2 Auto Scaling from the API Directory, store the AWS access key once, and your agent calls it.
- **Permission scoping:** Amazon EC2 Auto Scaling names the Auto Scaling group in the request body rather than the URL path, so limit the agent to the operations it needs, such as CreateAutoScalingGroup, SetDesiredCapacity, or DescribeAutoScalingGroups. You choose the operations it may call, so destructive ones like deleting a group or starting an instance refresh are not included unless you add them.
- **Credential handling:** Your AWS access key for Amazon EC2 Auto Scaling is stored once, encrypted, by your own Jentic One instance and signed with SigV4 at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an auto scaling group' or 'set the desired capacity on a group', and Jentic returns the matching Amazon EC2 Auto Scaling operation with its input schema so the agent calls the right endpoint without browsing the AWS service reference.

## Related APIs

- **Amazon EC2** — Manages the underlying EC2 instances, launch templates, AMIs, and security groups that Auto Scaling launches.
- **Amazon CloudWatch** — Provides the metrics and alarms that drive Auto Scaling target tracking and step scaling policies.
- **Amazon EKS** — Kubernetes-native control plane where the Cluster Autoscaler or Karpenter handles node scaling instead of EC2 Auto Scaling groups.

## FAQ

### What authentication does the Amazon EC2 Auto Scaling API use?

All requests are signed with AWS Signature Version 4 using an AWS access key ID and secret access key, sent in the Authorization header. Through Jentic, those credentials are stored encrypted in the vault and signing happens server-side, so the agent only ever sees a scoped Jentic credential reference.

### Can I attach an Application Load Balancer to an Auto Scaling group with this API?

Yes. Use AttachLoadBalancerTargetGroups for ALB and NLB target groups, or AttachLoadBalancers for Classic Load Balancers. Once attached, instances launched by the group are registered with the target group automatically and removed on termination.

### What are the rate limits for the Amazon EC2 Auto Scaling API?

EC2 Auto Scaling uses standard AWS service quotas, not a published per-second limit. Requests can be throttled with a Throttling error, and DescribeAutoScalingGroups in particular has lower quotas than mutating actions. Jentic respects the documented exponential-backoff guidance from AWS when retrying.

### How do I roll out a new launch template version to an existing Auto Scaling group through Jentic?

Update the group's launch template version with UpdateAutoScalingGroup, then call StartInstanceRefresh with a MinHealthyPercentage and InstanceWarmup that match your tolerance. Through Jentic, search for 'roll out new launch template' and execute the returned operation; Jentic returns the refresh ID so the agent can poll DescribeInstanceRefreshes.

### Does EC2 Auto Scaling work with EC2 Spot instances?

Yes. Mixed instance policies on the Auto Scaling group let you combine On-Demand and Spot capacity with allocation strategies like price-capacity-optimized. Configure this through the group's MixedInstancesPolicy when calling CreateAutoScalingGroup or UpdateAutoScalingGroup.

### How is Amazon EC2 Auto Scaling priced?

EC2 Auto Scaling itself is free to use; you pay only for the EC2 instances, EBS volumes, CloudWatch alarms, and Elastic Load Balancing capacity it manages on your behalf.

### Can I limit what my agent is allowed to do with the Amazon EC2 Auto Scaling API?

Yes. Because you self-host Jentic One, your own rules decide which operations and credentials the agent may use, so you can allow only what it needs, such as DescribeAutoScalingGroups, CreateAutoScalingGroup, or SetDesiredCapacity. Amazon EC2 Auto Scaling names the target group in the request body rather than the URL path, so scoping is done by the set of operations you grant rather than by path patterns. Destructive actions like deleting a group or calling StartInstanceRefresh stay out of the agent's reach unless you explicitly add them, and the AWS access key is signed at execution time so it never reaches the agent.
