Cloud cost engineering across the stack
Reducing cloud waste through Kubernetes rightsizing, observability changes and safe service retirement.
Preserve required data and service behavior; measure each initiative against its own billing baseline.
Contribution at a glance
- My responsibility
- Rightsizing, ingestion-path changes and safe retirement of legacy infrastructure.
- Scope
- Separate initiatives across Kubernetes, monitoring and legacy services in 2025–2026.
- Collaboration & boundaries
- I coordinated infrastructure changes with data-retention and service requirements; savings are attributed to each scoped initiative.
- Outcome
- Annualized equivalents: ~US$30.1K legacy retirement, £26.5K Kubernetes rightsizing and £14K monitoring ingestion. Different currencies and baselines.
The opportunity
Cloud savings came from a sequence of engineering decisions: reduce idle capacity, change expensive ingestion paths, match storage to access patterns and retire services whose business role had ended. I worked across those layers rather than treating the cloud bill as a single optimization.
Retire the service, preserve the data
I coordinated the retirement of a legacy service across Kubernetes and MongoDB Atlas. Before removing resources, I exported and verified the retained data, then removed the database clusters, dedicated compute and temporary backup infrastructure.
The first post-retirement Atlas billing cycle, April 2026, fell from US$2,424.31 to US$131.30 for that service: US$2,293.01 less per month, a 94.6% reduction. The remaining amount included partial runtime and backup retention. It was not a zero bill.
The closeout combined that observed database reduction with approximately US$218/month of removed GKE infrastructure, giving about US$2,511/month, or US$30,132/year annualized. The GKE component is an infrastructure estimate; the Atlas component is a billing comparison. I did not attribute the entire organization-wide bill change to this service.
Right-size Kubernetes before buying more capacity
A January 2025 fleet snapshot recorded a reduction from 69 to 55 nodes across four environments. The recorded monthly reduction was £2,208.33, equivalent to £26,499.96/year annualized.
A later sandbox change reduced the application minimum from two pods to one, enabling four more machines to be removed. That task recorded US$1,009.74/month, or US$12,116.88/year annualized. It represents a separate optimization step, with a different baseline and currency; I keep it separate from the earlier fleet snapshot.
Change the monitoring ingestion path
I replaced a paid managed Prometheus ingestion path with a standard Prometheus stack. The recorded ingestion line fell by £1,165.80/month, equivalent to £13,989.60/year annualized. Validation covered existing scrape targets, dashboards and alerts.
Self-managed monitoring still needs compute, storage and maintenance. This result describes the removed ingestion line. Read the monitoring migration and its trade-offs.
Keep optimizing across the stack
The wider work included storage lifecycle changes, bucket storage-class and region changes, shared compute for AI workers, non-production scheduling, registry cleanup and removal of unused VMs and databases. Those changes demonstrate the breadth of the work; I do not assign them invented financial totals.
For storage, the January 2025 configuration record shows Nearline after 30 days and Archive after 365 days. That configuration alone does not establish the historical storage savings amount. Commitment-discount pricing analyses also stay separate from measured incremental reductions.
How to read the financial results
Each annualized equivalent is twelve times its documented monthly reduction. These are historical initiatives with different measurement periods, not twelve months of realized savings or a forecast of the current bill. GBP and USD remain in their original currencies, and the initiatives are not combined into one headline total.
The engineering principle
Follow the billable resource all the way to an operational decision. Verify dependencies and retention before removing it, validate the resulting service behavior, then return to billing to check the impact.
Decisions and next steps
A retrospective view of the approach and its limits. The next improvement is a proposal, not a delivered result.
Alternative and rationale
Right-size an active service or retire an unused one: the business dependency and retention requirements determine which change is justified.
Trade-off
Reducing a managed billing line can add self-managed operations. Annualized monthly reductions are not twelve months of realized savings.
What I would improve next
Next improvement: reconcile overlapping periods and maintenance costs before reporting a consolidated net saving.