The situation
What needs investigation
A production AWS environment accumulates cost as services grow, traffic patterns change, storage increases, and temporary resources become permanent. The objective is not simply to reduce the bill; it is to identify spend that does not contribute to required capacity, reliability, or recovery.
Signals we look for
Compute
- consistently low utilisation
- oversized instances or tasks
- idle non-production capacity
- purchase model fit
Containers
- CPU / memory imbalance
- task sizing
- weak scaling signals
- unused warm capacity
Storage
- unattached volumes
- snapshot growth
- storage class selection
- retention and lifecycle gaps
Network & data
- NAT Gateway processing
- cross-AZ traffic
- data-transfer patterns
- database class and I/O behaviour
How we investigate
Each step is validated against the workload before the next change.
- 01
Inventory
Group resources by owner, environment, workload, and service dependency.
- 02
Baseline utilisation
Compare spend with utilisation, traffic, latency, backup, and recovery requirements.
- 03
Identify cost drivers
Identify idle, oversized, duplicated, or poorly retained resources before changing architecture.
- 04
Validate workload requirements
Confirm the capacity and recovery expectations each workload actually needs.
- 05
Model changes
Review rightsizing, lifecycle, scaling, and purchase options with performance controls.
- 06
Measure
Verify spend and production signals after each controlled change.
Architecture / decision path
Example engineering decision
Illustrative workload signal — not customer data
Compute patternCPU below 15% for most of the week
Memory patternsteady at about 60%
Traffic patternweekday peaks only
Engineering interpretation
A smaller instance might lower cost, but it must first be checked against peak memory use, failover capacity, and the time needed to add capacity during a traffic increase.
Possible next investigation
- Review peak and percentile utilisation, not averages alone.
- Check autoscaling and health-check timing.
- Confirm backup and recovery capacity is excluded from a simple rightsizing decision.
- Test a smaller class in a controlled environment where possible.
Trade-offs we consider
Cost
A lower baseline can reduce spend but may reduce headroom.
Reliability
Backup, failover, and recovery capacity may be intentional.
Performance
Rightsizing must be checked against peaks and I/O behaviour.
Operations
A low-cost design that is difficult to operate can create a different cost.
What the engagement can produce
Typical outputs for this type of work
Scope depends on the environment and the problem being investigated.
- resource and ownership inventory
- utilisation baseline
- prioritized cost-driver findings
- architecture and lifecycle recommendations
- implementation plan
- monitoring and rollback notes