A cost-optimized, serverless automation framework for faster environment lifecycle management
How Creyente designed a serverless, Step Functions-based framework that safely decommissions expired ad-hoc environments — orchestrating SQL cleanup, EBS volume operations, EC2 state management and duplicate protection.
A customer operating multiple ad-hoc development and testing environments on AWS needed a reliable way to quickly provision and decommission temporary environments on demand — used for short-term validation, testing, support activities and engineering troubleshooting.
While flexible, these environments introduced operational challenges when not decommissioned on time. Each included Auto Scaling Group resources, SQL Server databases, attached EBS volumes and supporting EC2 infrastructure — and manual cleanup risked delays, missed resources and unnecessary cost.
Objective: a quick, on-demand ad-hoc environment lifecycle framework that reduces manual effort, improves reliability and optimizes cost.
A serverless, Step Functions-based framework orchestrating SQL cleanup, EBS detach/delete, EC2 state management and environment-level duplicate protection.
When environments reached expiry, cleanup was mostly manual and time-consuming — starting stopped Windows database servers, waiting for SQL Server and SSM connectivity, removing databases, then detaching and deleting EBS volumes. Critically, AWS Lambda's 15-minute timeout made it unsuitable for this long-running workflow.
Manual decommissioning consumed engineering time
Expired environments kept running longer than required
SQL databases and EBS volumes could remain orphaned
Cleanup spanned EC2, SQL Server, SSM, EBS and ASG metadata
A single Lambda was unreliable for long-running workflows
Duplicate triggers could process the same environment twice
We designed a single AWS Step Functions Standard Workflow that works across all ad-hoc environments. Standard Workflows suit long-running, durable, auditable orchestration and can run for up to one year — a far better fit than Lambda for this process.
One reusable Step Functions workflow for all environments (dev01, dev02, ...), deriving DB name, volume prefix, DB server and instance dynamically from input.
A PrepareDecommissionPlan Lambda extracts the environment from the ASG name, ensuring consistent naming across database and storage cleanup.
A DynamoDB lock table (e.g. LOCK#dev01) prevents duplicate cleanup while allowing different environments to run in parallel.
Starts the DB server only if stopped, waits for Windows & SQL to stabilize, and stops it again afterwards to protect cost.
A controlled PowerShell script via SSM Run Command drops the target database — and blocks system databases (master, model, msdb, tempdb).
Identifies volumes by environment prefix (e.g. MntVol-Remote-DEV03), detaches, waits for availability, then deletes — avoiding orphaned storage.
The framework runs in dry-run mode by default. Destructive actions require explicit confirmation flags, preventing accidental database or storage deletion.
Default (safe)
Destructive (explicit)
Expired environments cleaned up without manual intervention, enabling faster recycling for new needs.
Removes unused SQL databases and environment-specific EBS volumes after expiry.
A consistent, repeatable process: validate → lock → prepare → execute → verify → cleanup → release.
Per-environment locking lets dev01, dev02 and dev03 run independently while blocking duplicates.
A clear execution trail for every cleanup — what ran, what was targeted, and the outcome.
Fully managed serverless services — no dedicated automation servers to maintain.
A fully serverless stack keeps operational overhead low.
Speak to Creyente about serverless automation, cost optimization and AWS operational tooling.
Talk to our team
Write a comment