Cost overruns in the cloud are rarely caused by expensive services. They are caused by architectures that make an expensive pattern the default — chatty cross-zone traffic, over-provisioned always-on capacity, or logs retained indefinitely because nobody set a policy.
Know which axis you scale on
Before choosing infrastructure, identify what actually grows: concurrent users, stored data, background processing, or egress. A platform whose cost is dominated by storage should not be optimised for compute elasticity, and vice versa.
Egress and cross-zone traffic are the quiet ones
Compute and storage line items get scrutiny; data transfer rarely does until it is significant. Keep chatty services in the same zone, put a CDN in front of anything static, and be deliberate about where large payloads cross a boundary.
- Set log and metric retention explicitly — the default is usually longer than you need
- Right-size after measuring real usage, not from the initial estimate
- Scale non-production environments to zero outside working hours
- Tag every resource by project and environment so cost is attributable
- Put a budget alert in place on day one, not after the first surprising invoice
Kubernetes when the workload justifies it
Kubernetes is the right answer for a portfolio of services with genuinely varied scaling profiles. For a single application with predictable load it adds operational cost — cluster upgrades, node management, and the expertise to debug it at three in the morning — without a corresponding benefit. Choose it deliberately.