AWS cost optimisation for non-production environments: where to start

Build a cost and ownership baseline

Export cost by account, service, tag and environment. Find spend with no owner and resources whose environment or lifecycle is unclear. Cost optimisation stalls when nobody can approve a change.

Combine billing data with utilisation and application schedules. A low average does not prove a resource can be reduced if short peaks matter.

Prioritise reversible actions

Non-production schedules, unattached resources, old snapshots and consistent over-provisioning can produce early savings. Apply safeguards and opt-outs for teams that run tests or support across time zones.

• Tag owner, environment and service
• Schedule eligible development and test compute
• Review unattached storage and stale snapshots
• Rightsize from CPU, memory and request evidence
• Review commitment discounts only after the baseline is stable

Automate without hiding control

A Lambda-based scheduler can start and stop eligible resources from tags or a controlled inventory. Log every action, expose an override and alert on failures. Keep stateful dependencies and recovery time in scope.

Treat cost automation like a production change. Test it in a limited account or resource group and confirm the next billing period.

Experience from telecom cloud optimisation

During a telecom AWS migration, Saikat designed Lambda-based EC2 cost automation. The supplied CV reports savings of approximately EUR 10,000 per month in that environment.

This is an employment-history example, not a savings promise for a future client. Actual opportunity depends on baseline spend, workload schedules and current commitments.

Add guardrails before scheduling cloud resources

Eligibility should be explicit. Use account, environment, owner and schedule tags or a controlled inventory, and require an application owner to confirm that stopping the resource will not affect integration tests, batch work, support across time zones or stateful dependencies. Start with a small non-production group.

The automation identity needs only the actions and resources required. Log planned and completed state changes, failed actions and overrides. Provide a documented way to keep an eligible resource running temporarily, with an owner and expiry, so engineers do not disable the scheduler or remove tags under pressure.

Test start as well as stop. An instance may return before its application, registration, dependency connection or scheduled work is ready. Monitor the full service state and alert when the expected environment is not available by the agreed time.

• Owner-approved eligibility and default schedule
• Least-privilege automation role and resource boundary
• Action logging, failure alerting and time-bound override
• Application-level start verification, not instance state alone
• Rollback method and support owner for the automation

Create a monthly cost review that leads to engineering decisions

Review cost by account, service, environment and owner, then explain material movement. Separate business growth, price or commitment changes and one-off usage from optimisation. Pair billing with utilisation and delivery context so a low average is not mistaken for safe downsizing.

Maintain an action register with expected saving, implementation effort, reliability risk, owner and validation date. Reversible waste removal can move early; architectural changes need a stronger case. Commitment discounts should follow a stable usage baseline because they reduce flexibility as well as price.

Verify each action after implementation using a comparable billing period and service evidence. Record developer or operational impact. A saving that repeatedly blocks test environments or creates manual recovery may cost more than it removes.

Frequently asked questions