Make spend visible first
A single undifferentiated bill cannot be acted on. Tag resources by team, environment, and service so cost can be attributed to something a person is responsible for.
Attribution alone frequently reduces spend before any technical change, because teams that can see their own costs start managing them.
Delete what nobody uses
Unattached storage volumes, idle load balancers, old snapshots, orphaned IP addresses, and environments created for a project that finished two years ago. This is pure waste and removing it carries essentially no risk.
It is also the least glamorous step, which is why it is usually skipped in favour of architectural changes that cost more and save less.
Turn off non-production overnight
Development, test, and staging environments typically run continuously while being used during working hours only. Scheduled shutdown outside those hours removes roughly two thirds of their cost.
Make restart fast and automatic, or people will simply disable the schedule.
Right-size against real usage
Instances are usually sized by an initial guess and never revisited. Look at actual CPU and memory over several weeks, then resize with headroom for genuine peaks rather than for the original estimate.
Do this after a migration rather than during one, when real usage patterns in the new environment are finally visible.
Attack storage and transfer
Storage grows monotonically because deleting feels risky. Lifecycle rules that move old data to cheaper tiers and expire what genuinely has no value are set once and save continuously.
Data transfer is the cost people most often miss. Traffic between regions and out to the internet is charged, and a chatty cross-region architecture can cost more in transfer than in compute.
Commit only to your certain baseline
Reserved capacity and savings plans offer real discounts in exchange for commitment. Commit only to the floor you are confident of, and leave the variable portion on demand.
Over-committing converts a discount into a penalty, and it is remarkably easy to do during a period of growth that then does not continue.
Put a guardrail in place
Budget alerts, anomaly detection, and a cost check in the deployment pipeline stop the next surprise before it accumulates for a month.
Without a guardrail, the same optimisation work has to be repeated annually.