Serverless daily report surfaces suspended AWS Auto Scaling processes

A forgotten flag that breaks scaling

Amazon EC2 Auto Scaling Groups let engineers suspend individual scaling processes — Launch, Terminate, HealthCheck and AZRebalance among them. According to a post on dev.to, that flexibility is valuable during incidents: freezing capacity for a deployment, stopping instance churn while debugging, or holding a group steady during a migration. The danger arrives afterwards, when nobody remembers to resume the suspended processes.

A group with Launch suspended will not add capacity when traffic spikes, and one with HealthCheck suspended will not replace unhealthy instances. The author notes that no alarm covers this state by default, so teams tend to discover the leftover suspension during the exact incident where they needed scaling to work.

A three-part serverless pipeline

The fix described on dev.to is a daily, near-zero-cost chain:

• Amazon EventBridge supplies a cron-style trigger.
• An AWS Lambda function written in Python with boto3 lists every Auto Scaling Group across the configured regions and keeps only those with suspended processes.
• Amazon SES delivers the findings as a formatted HTML email.

Pagination and the report itself

The scan uses a paginator on describe_auto_scaling_groups, which the author flags as essential: accounts with many groups receive paged responses, so a single unpaginated call would silently skip some of them.

The email lists each affected group with its region, name, the suspended process names and its min, desired and max capacity, so the reader can gauge the impact at a glance rather than parsing raw JSON. A NOTIFY_WHEN_EMPTY setting switches between alert-only mode and a daily all-clear message.

Deployment without a framework

Deployment stays dependency-free: a bash script shells out to the AWS CLI, zips handler.py, and creates the Lambda on Python 3.12 with a 120-second timeout (ap-south-1 in the example). The EventBridge rule and IAM role are either created the same way or once by hand. No framework, no agents, no server to keep alive.

Two bugs worth learning from

The post also records the two failures that had to be fixed before the pipeline ran.

The first invocation died with Runtime.ImportModuleError: the function still pointed at the console default lambda_function.lambda_handler, while the code actually lived in handler.py with a function named handler. The handler string must read file-then-function, so a single update-function-configuration call setting handler.handler resolved it.

The second run got further and then failed with AccessDenied on describe_auto_scaling_groups: the execution role carried a trust policy but none of the permissions the code needed. The fix was a minimal inline policy granting autoscaling:DescribeAutoScalingGroups — which the author notes does not support resource-level restrictions and therefore needs a wildcard resource — plus ses:SendEmail and ses:SendRawEmail, which can be scoped to a verified SES identity for tighter least privilege.

The broader lesson the author draws is that least-privilege IAM will produce AccessDenied errors, and that is a feature: each error names the exact action to grant, one at a time, instead of pushing toward blanket wildcards. Reading the error type also points straight at the fix — import errors are configuration problems, access errors are IAM problems.

Why it matters

Suspended scaling processes are a quiet but real risk for any team that leans on them during incidents, and nothing in default AWS tooling reports on the leftovers. This pattern closes that gap for roughly the cost of one Lambda invocation per day.

It is also broadly reusable: swap the boto3 call and the same EventBridge-Lambda-SES skeleton can report unencrypted volumes, public snapshots, idle load balancers or any other slow-moving drift that CloudWatch alarms do not naturally cover. Small periodic automations of this kind, as the post argues, can head off serious production failures for a few lines of Python.