AWS, Azure & GCP · Cloud across providers
How do you control cloud costs?
Short answer
Make spend visible with tagging and budgets, eliminate idle resources, right-size, and choose pricing models that match usage. Cost control is an ongoing process with ownership, not a one-time cleanup.
Cloud cost is driven by resource shape, usage duration, data transfer and requests. You cannot optimise what you cannot attribute, so tagging and account structure come first. After that, the biggest wins are usually idle resources, oversized instances and unnecessary data transfer.
A working cost process
- Tag resources by team, environment, service and cost centre, and enforce tags with policy
- Set budgets and anomaly alerts, not just monthly reports
- Right-size compute and storage from observed utilisation
- Use lifecycle policies for logs, backups and old objects
- Buy commitments only for stable baseline usage
- Review unit economics, such as cost per order or per active user
aws ce get-cost-and-usage --time-period Start=2026-10-01,End=2026-10-31 --granularity MONTHLY --metrics UnblendedCost --group-by Type=TAG,Key=teamThe cheapest resource is not always the right one. Cutting redundancy to save money can reduce reliability, and aggressive commitments can lock you into the wrong instance family. Treat cost as one pillar with explicit trade-offs against reliability and performance.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you make cost attributable to teams?
- 2What hidden costs do teams commonly miss?
- 3When is a commitment purchase risky?
- 4How would you reduce cost without hurting reliability?
Say it in the interview
I start by making spend attributable through tags, accounts and budgets, because optimisation without ownership does not stick. Then I remove idle resources, right-size from observed usage, apply storage lifecycle rules and buy commitments only for stable baseline load. I review unit economics and hidden costs like egress and NAT, while keeping reliability trade-offs explicit.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live AWS, Azure & GCP mock interview and get scored feedback on depth, clarity and confidence.