Assign costs to a purpose
Group resources by workload and environment. Give every meaningful group an owner. Separate costs that support serving traffic from costs for development, retained data, observability or recovery. An unlabelled line item is a question to investigate, not automatic proof of waste.
Choose a period long enough to include normal scheduled work. Compare the bill with deployments, traffic and data growth during that period. Record known anomalies so an unusual month does not become the assumed baseline.
Review one resource class at a time
For compute, compare capacity with observed demand and required headroom. For storage, examine retention, access needs and recovery requirements. For transfer, understand which systems exchange data and why. The same cost can be necessary in one service and avoidable in another.
If containers are involved, Docker’s resource documentation explains how memory and CPU controls affect workloads. These settings are operational controls, not a guarantee of a lower provider bill. Billing depends on the product and allocation model.
Make a reversible proposal
Write each proposed change as a small experiment: expected saving, expected performance effect, success criteria and rollback. Use actual account prices and measurements rather than a generic percentage from a blog.
After the change, compare both cost and service behaviour over an appropriate period. Include the engineering time required to operate the new design. A cheaper component that creates a fragile workflow may increase the total cost of ownership. Retain the reasoning so future reviewers can understand why apparently idle capacity exists.
Before you finish
- Resource owners identified
- Normal workload period selected
- Savings use actual billing data
- Reliability checked after changes
Technical reference
Docker: resource constraints