FinOps — financial operations for cloud infrastructure — was developed by and for large enterprises with dedicated finance and engineering teams managing cloud budgets in the millions. The principles, stripped of enterprise ceremony, are directly applicable to small businesses paying monthly cloud bills between $2,000 and $20,000.
The problem is identical at all scales: cloud spending is variable and grows without intervention. The solution is identical: visibility, accountability, and active management. The implementation is simpler at smaller scale.
The Foundation: You Need to Know Where the Money Goes
Cloud billing is designed to be comprehensive, not readable. AWS, GCP, and Azure all offer billing dashboards that show you the total bill broken down by service — but not the breakdown by team, by project, or by workload that would tell you whether you’re spending appropriately.
The first FinOps step for any organization: enforce tagging. Every cloud resource should be tagged with at minimum:
Environment: production, staging, developmentTeamorOwner: the team or person responsibleProjectorService: the workload or application
With consistent tagging, Cost Explorer (AWS) or the equivalent on other providers can show you cloud spend by environment, by team, and by project. Without tagging, all you can see is that you spent $8,400 last month on EC2 — not which workloads or teams drove that spend.
Enforce tagging at the infrastructure provisioning layer. If your infrastructure is defined in Terraform, enforce the tag in the module definition. If it’s provisioned via the console, implement an AWS Config rule that flags untagged resources. A manual policy that nobody enforces is not a tagging policy.
Setting and Monitoring Budgets
Cloud providers offer budget alerting tools that most organizations don’t configure. AWS Budgets lets you set a monthly cost budget and send email or SNS alerts at specified thresholds (e.g., alert at 80% of budget, alert at 100%, alert if forecasted spend will exceed budget before month end).
A small business cloud budget configuration:
- Set a monthly budget based on expected spend (use the last 3 months average as baseline)
- Configure alerts at 75%, 90%, and 100% of the monthly budget
- Route alerts to the person who owns the cloud bill and the engineering lead
The forecast alert is particularly useful — it fires mid-month when AWS predicts you’ll exceed the budget by month end, giving you time to investigate and act before the bill is finalized.
Tag-based budgets let you set budgets per team, per environment, or per project. This is the mechanism that makes teams accountable for their cloud spending — each team’s AWS usage shows up against their budget, not anonymized into the total organizational bill.
The Monthly Review Ritual
Large FinOps programs have dedicated engineers running continuous optimization. Small businesses need a monthly 30-minute review:
What changed month-over-month? The Cost Explorer comparison view shows this directly. A 20% increase in EC2 costs — what drove it? New instances? Higher instance sizes? More hours on existing instances?
Which workloads grew the most? Broken out by tag (if tagging is in place), which projects or teams drove the largest cost increase? Is that increase expected and justified?
Are there any anomalies? Unexpected spikes in data transfer, unexpected storage growth, services you don’t recognize — these surface in the monthly review.
What’s the Reserved Instance / Savings Plan coverage? The Coverage report in AWS Cost Explorer shows what percentage of instance hours are covered by reserved pricing vs. on-demand. Any EC2 that’s been running continuously for the past month that’s on on-demand pricing is a candidate for commitment.
The monthly review doesn’t require deep technical expertise — it requires reading charts and asking “does this make sense?” The anomalies usually surface clearly. Acting on them requires more investigation, which is when engineering time is warranted.
The Quick Wins That Pay for the Time Investment
Three changes that consistently produce immediate savings with minimal effort:
Turn off development and staging environments outside business hours. Most development and staging workloads don’t need to run nights and weekends. AWS Instance Scheduler or simple Lambda functions triggered by CloudWatch Events can stop and start instances on a schedule. Stopping instances nights (8 PM - 8 AM) and weekends reduces runtime from 720 hours/month to approximately 260 hours/month — a 64% reduction in hours, and a proportional reduction in cost for those environments.
Implementation time: 2-4 hours. Expected savings: 50-60% of development/staging compute costs.
Purchase Savings Plans for baseline production compute. Review the last 30 days of on-demand EC2 and Fargate spend. Purchase Compute Savings Plans for 70-80% of that baseline (leaving headroom for variable usage). The discount is 25-30% on the covered hours.
Implementation time: 30 minutes. Expected savings: 25-30% of covered compute.
Delete unattached EBS volumes. Run the CloudShell query to list all unattached EBS volumes, review the list (verify each is actually unused — some are used by stopped instances), and delete confirmed orphans.
Implementation time: 1 hour. Expected savings: depends on accumulated orphans; typically $50-500/month for organizations that haven’t done this audit.
Showback and Chargeback for Multi-Team Organizations
For businesses with multiple teams or product lines sharing cloud infrastructure, showback (showing each team their cloud costs without charging them back) and chargeback (actually allocating costs to the team’s budget) drive accountability.
The psychological effect is real: teams that see their cloud spend attributed specifically to their work make different architectural decisions than teams that see a shared infrastructure line on the company P&L. “We could run this job every 5 minutes, but that costs $80/month more than running it every 15 minutes” is a calculation that teams make when it’s their budget.
Showback requires tagging (to attribute costs) and a reporting tool (Cost Explorer with tag filters, or a more sophisticated tool like CloudHealth or Apptio). Start with showback — show teams their costs without the financial accountability of chargeback — and move to chargeback when the organization is ready to manage cloud costs at the team level.
When to Get External Help
A structured cloud cost audit by an external party with FinOps experience is worthwhile when:
- Cloud spend has grown significantly without a clear explanation
- You don’t know where the majority of your cloud bill is coming from
- A recent migration or new workload created unexpected costs
- You suspect there’s waste but internal reviews haven’t surfaced it
External auditors bring familiarity with the specific patterns of cloud waste that don’t appear in general billing views — Reserved Instance portfolio optimization, Data Transfer analysis, storage tier review — and with the tooling to surface them quickly.
The typical engagement: 1-2 weeks of analysis, a prioritized savings opportunity report, implementation guidance for each finding. The savings from implementing the findings commonly exceed the cost of the engagement within the first 2-3 months.
Our cloud migration and cost optimization practice runs exactly this type of engagement. Related: the tagging and budget infrastructure that enables ongoing FinOps is directly connected to DevOps and automation — infrastructure provisioning pipelines that enforce tagging policies prevent the accumulated debt that makes cost management hard.