Most FinOps consulting services deliver a report. A 40-page PDF with charts, AWS Well-Architected findings, and recommendations sorted by category. Then it sits in a shared drive.
Our FinOps audit delivers a prioritized action list with implementation instructions, risk ratings, and estimated savings for each item. It runs two weeks. Engineers can start executing changes in week three.
What FinOps Actually Is (and Isn't)
FinOps is not "cut the AWS bill." It's the practice of making cloud cost a shared responsibility — engineering, finance, and operations aligned on what cloud spend buys and whether it's worth it.
The FinOps Foundation defines three phases: Inform (understand what's running and what it costs), Optimize (remove waste and improve unit economics), and Operate (build governance so optimization sticks). Most companies have spent years in Inform without moving to Optimize.
Our engagements focus on Optimize — with enough Operate to ensure savings hold.
The 2-Week Audit Structure
Week 1: Full Cost Attribution
Day 1–2: Access and tooling setup.
We need: - Cost Explorer read access (IAM role or user) - Cost and Usage Report (CUR) in S3 — if not set up, we create it (data available in 24–48 hours) - AWS Organizations read access if multi-account - Compute Optimizer activation
We run a tagging audit in parallel: what percentage of resources are tagged by environment, team, and application? Untagged resources are uninvestigable waste. We report tagging coverage and flag the gaps.
Day 3–5: Cost attribution by dimension.
We segment spend across:
- Service: EC2, RDS, S3, CloudFront, NAT Gateway, Lambda, Data Transfer — where is the money going?
- Environment: prod vs. dev/test vs. staging — are dev environments running 24/7 unnecessarily?
- Region: is spend distributed across regions rationally, or are there orphan resources in regions nobody uses?
- Account: in multi-account orgs, which accounts have cost anomalies?
We use Cost Explorer custom views, Athena queries against CUR for granular analysis, and Compute Optimizer reports for instance-level data.
By end of week 1, we have a complete cost map: every significant spend category, trend direction, and preliminary waste indicators.
Week 2: Optimization Analysis and Prioritization
Day 6–8: Opportunity identification.
We work through each cost category systematically:
| Category | Analysis Method | Typical Finding |
|---|---|---|
| EC2 | Compute Optimizer + CloudWatch CPU/network | 15–35% oversized |
| RDS | Performance Insights + Multi-AZ review | 10–30% oversized; dev DBs running 24/7 |
| EBS | Volume attachment status + type audit | $500–$5K/mo in unattached or wrong-type volumes |
| S3 | Storage class distribution + access patterns | Missing lifecycle policies on old buckets |
| Data Transfer | Cost Explorer transfer breakdown | NAT Gateway, cross-AZ, internet egress waste |
| Savings Plans/RIs | On-Demand vs. committed spend ratio | 20–40% of stable compute on On-Demand |
| Lambda | Invocation count, memory sizing, timeout analysis | Oversized memory, unnecessary invocations |
Day 9–10: Prioritized action list.
We produce a single deliverable: an action list ranked by (estimated monthly savings × implementation ease ÷ risk). Each item includes:
- Specific resource (instance ID, bucket name, account)
- Estimated monthly savings
- Implementation steps (copy-paste where possible)
- Risk level (Low / Medium / High) with explanation
- Prerequisite dependencies
Example entries:
1. Purchase Compute Savings Plan — $3,200/mo savings
Risk: Low | Commitment: 1-year no-upfront
Action: In Cost Explorer → Savings Plans → Purchase → Compute Plan
Covers: 73% of stable EC2 baseline identified in accounts 123/456
2. Rightsize RDS: prod-db-01 from db.r6g.2xlarge → db.r6g.xlarge — $840/mo savings
Risk: Low (CPU avg 12%, memory avg 31% over 90 days)
Action: Modify instance class during next maintenance window
Validation: Monitor Performance Insights for 7 days post-change
3. Delete unattached EBS volumes (list attached) — $1,240/mo savings
Risk: None (volumes confirmed unattached, no snapshot dependency)
Action: ec2 delete-volume commands in attached runbook
No filler. No generic recommendations. Every item is specific, actionable, and scoped.
Governance Outputs
Cost optimization without governance reverts. We deliver:
Tagging policy: AWS Config rules that flag new untagged resources. Mandatory tags: Environment, Team, Application. Non-compliant resources trigger SNS alerts.
Cost Anomaly Detection: AWS Cost Anomaly Detection configured with thresholds per service. Alerts to email/Slack when spend spikes anomalously.
Monthly review cadence: A one-page monthly cost review template that your team runs independently — top spend categories, trend vs. prior month, any new Compute Optimizer recommendations.
Savings tracking: A spreadsheet (or dashboard if preferred) showing implemented savings vs. target, with actual vs. projected cost by month.
What Makes FinOps Consulting Work (and What Doesn't)
Works: Clear scope, access to real cost data, engineering team engaged and able to execute changes.
Doesn't work: Consulting engagement without engineering execution. The action list only saves money when someone runs the commands. We can execute changes if your team lacks bandwidth.
Works: Starting with quick wins. The first 20% of actions typically deliver 60% of the savings. Momentum matters.
Doesn't work: Trying to fix architecture to save costs without understanding the application. Some "optimization" recommendations break production. We risk-rate everything.
For deeper context on the infrastructure we're optimizing, see our AWS Cloud Infrastructure capability and the tactics in How We Cut an AWS Bill 40% in 6 Weeks. The FinOps Foundation's open-source framework is the industry standard we align to.
Frequently Asked Questions
How is a FinOps audit different from an AWS Well-Architected Review?
A Well-Architected Review evaluates your architecture against AWS best practices across all five pillars — cost is one of them. It's broader and produces a prioritized improvement plan across security, reliability, performance, and cost. A FinOps audit goes much deeper on cost specifically: granular resource-level analysis, specific dollar figures, implementation-ready action items. Both have value; they're different tools.
Do you need production access to our AWS environment?
We need read-only access to Cost Explorer, CUR data in S3, Compute Optimizer, and AWS Organizations. We use an IAM role with minimal permissions and no write access. For implementation phases, we work alongside your engineers or take write access for specific, approved changes.
What if our tagging is poor and we can't attribute costs?
Tagging gaps are common and expected. We work with what's available — resource type, region, creation time, account — to reconstruct attribution. We also prioritize tagging remediation as an early action item since it's a prerequisite for sustained governance.
Can you work with multi-account AWS Organizations?
Yes. Multi-account orgs are our standard operating environment. We analyze management account CUR (which aggregates all member accounts), cross-account Compute Optimizer data, and account-level Cost Explorer views to identify which accounts have the highest waste concentration.
How do we maintain savings after the engagement ends?
Savings hold through governance: tagging enforcement via Config, anomaly detection alerts, and a monthly review cadence. We document all of this and hand it off with your team trained on the process. For teams without dedicated FinOps capacity, we offer ongoing periodic reviews.
Get a free AWS cost review → rutagon.com/contact