- Newest
- Most votes
- Most comments
This is most often from the TerminateInstanceInAutoScalingGroup API. Its commonly used by some services (such as EKS, Batch, or CloudFormation), as well as some 3rd party applications which are managing instances in an ASG. As the other replies recommended, go to CloudTrail and search around the start time of one of these activities by either: ReadOnly=False or EventSource=autoscaling.amazonaws.com
You'll want to look at the UserAgent of the call in cloudtrail to see where its coming from
Hello.
If the change was made by a user, I think you could check which IAM user changed the EC2 capacity by checking the CloudTrail event history.
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html
Hii
Check these troubleshoot steps to resolve issue:
- Identify Specific Actions: Look for entries in the Actions Log with "in response to a user request" next to the scaling action (scale-in or scale-out).
- Review User Activity: Check if any users made scaling requests through the autoscaler's user interface or API during the logged times..
Consider Integrations:
- Do you have any integrations with other tools that might trigger scaling actions?
- Investigate if these integrations can initiate scaling and might be misidentified as user requests.
- Check Scheduled Actions: Double-check your scheduled scaling actions to ensure they aren't causing these events
.
Relevant content
- asked 2 years ago
- AWS OFFICIALUpdated 4 months ago

thank you, I have activated cloudtrail now. We found some issues with our load balancer health checks which target this autoscaler group, could it be that the load balancer does these "user requests" to make sure we have healthy instances in the autoscaler?
No, failed ELB healthchecks would have an explicit message in the Activity History. Its possible some other system is noticing the failed ELB healthchecks and sending these termination requests to AutoScaling, but the ELB itself won't do that
You should be able to see 90 days of past CloudTrail events by default, even without a Trail setup to store them externally. You can see these past events on the CloudTrail console, or via the lookup-events API