Mean Time to Explanation: A New Metric for AWS Cost Investigation

Operations teams have clear metrics for incidents. MTTR (Mean Time to Recovery) measures how long it takes to restore service. MTTI (Mean Time to Innocence) measures how long it takes to prove a component is not the cause.

FinOps has no equivalent metric for cost incidents.

When AWS spend increases unexpectedly, how long does it take to produce a defensible explanation? Not a guess. Not "it's probably that new workload." An explanation backed by evidence, with ownership identified and next steps recommended.

That gap is why I'm introducing a new term.

Why MTTE matters

Most organizations have some form of cost alerting. AWS Budgets, Cost Anomaly Detection, or a FinOps platform sends a notification when spend increases.

What happens next is where things break down.

Someone opens a dashboard. Clicks around. Filters by service, then by account, then by region. Downloads a CSV. Opens a spreadsheet. Cross-references with deployment logs. Sends a Slack message asking who owns that account. Waits. Sends another message. Eventually, maybe, an explanation emerges.

That process can take hours. Sometimes days. Sometimes the question just gets dropped because nobody has time to chase it.

A high MTTE means cost questions go unanswered. Teams lose confidence in their cost data. Finance and engineering produce different numbers. Anomalies become noise. Ownership becomes unclear.

A low MTTE means cost questions get answered while they're still relevant. Teams can act on findings. Ownership is clear. The cost data becomes a useful operational signal instead of a monthly surprise.

What drives MTTE

MTTE is a function of three things:

• Data access: Can you get to the billing data you need without waiting for someone else?
• Evidence collection: Can you gather supporting evidence (resource IDs, usage patterns, ownership signals) without manual clicking?
• Context assembly: Can you connect the cost movement to the technical change that caused it?

Most organizations fail at all three. Billing data is locked in a platform only finance can access. Evidence collection requires manual clicking through the console. Context assembly requires tribal knowledge about who owns what.

Mission FinOps helps reduce MTTE through investigations. Kulshan helps reduce MTTE through tooling.

Kulshan v0.2.x: Built for lower MTTE

Kulshan started as a FinOps baseline tool. Run a scan, get a report, understand your AWS environment's cost and security posture.

With v0.2.x, Kulshan can now query AWS Cost Explorer and CUR data directly. That changes what's possible.

Cost Explorer integration

The kulshan report command now pulls service-level cost data, forecasts, and RI/SP coverage directly from Cost Explorer. The cost pack runs anomaly detection using z-score, IQR, MAD, and week-over-week analysis, and can compare the results with AWS Cost Anomaly Detection findings when available.

$ kulshan report
# Pulls Cost Explorer data, detects anomalies, checks commitment gaps

CUR and Data Export support

Kulshan can now auto-detect your AWS Data Exports and query CUR Parquet files directly. Local files or S3. S3-native queries do not require downloading the full export locally first: DuckDB's httpfs extension handles it.

$ kulshan cur validate --path ./cur/
# Validates Parquet structure, checks schema mapping

$ kulshan investigate cost --s3 s3://your-bucket/cur/ --month 2024-06
# Top movers by service, account, region, usage type

$ kulshan investigate ec2 --cur ./cur/ --month 2024-06
# EC2-specific breakdown: instance family, pricing model, resource-level

Performance improvements

Full 10-pack scans now run substantially faster. Parallel pack execution, parallel region scanning, batched API calls, and quota caching all contribute.

Faster scans mean lower MTTE. You can run a baseline while the cost question is still fresh.

MCP server for AI agents

Kulshan now includes an MCP server. Run kulshan mcp-serve and any MCP-compatible agent (Claude Desktop, Kiro, Cursor) can use Kulshan's tools directly.

Seven tools are exposed:

• kulshan_doctor - Check AWS identity and permissions
• kulshan_report - Run audit packs
• kulshan_quick_security - Fast single-region security scan
• kulshan_list_packs - List available packs
• kulshan_cur_validate - Validate CUR data
• kulshan_investigate_ec2 - EC2 cost analysis
• kulshan_investigate_cost - S3 CUR analysis

This means AI agents can gather evidence and investigate cost questions using the same tools you'd use manually. The agent handles the clicking. You get the explanation.

Evidence Contract

Kulshan doesn't just output a confident answer. Every investigation result includes a structured evidence contract:

• Provenance: Schema version, Kulshan version, generation timestamp, data freshness
• Confidence: Structured assessment of data completeness and ownership confidence, not a numeric score
• Available evidence: What data sources were used, with unique IDs for traceability
• Missing evidence: What couldn't be determined from the available data
• human_review_required: true: Always. Kulshan surfaces evidence. Humans make decisions.

This structure lets AI agents reason over the evidence while making clear what still needs human confirmation. It's the difference between "EC2 costs increased" and "EC2 costs increased $2,400 in us-east-1, linked account 394812, instance family m5, confidence: high for cost data, low for ownership, owner candidate: platform-team (requires confirmation)."

Evidence quality improvements

Raw findings are not explanations. Kulshan v0.2.x includes several quality improvements:

• Deduplication: Similar findings grouped together. "9 subnets without flow logs" instead of 9 separate findings.
• Remediation cost estimates: Estimated monthly cost to fix common findings.
• Severity auto-tuning: Context-based adjustments. An inactive IAM user is lower severity than an active one with console access.

Better findings mean faster understanding. Faster understanding means lower MTTE.

What MTTE looks like in practice

Here's a concrete example. Finance reports that last month's AWS spend increased 18%. They want to know why.

High MTTE process:

• Cloud team opens Cost Explorer, clicks around for 30 minutes
• Identifies EC2 as the primary driver
• Asks Slack who launched new instances
• Waits 4 hours for a response
• Gets a partial answer: "We scaled up for the product launch"
• Still unclear which accounts, which regions, whether it's temporary
• Total time: 6+ hours, incomplete answer

Low MTTE process:

• Run kulshan investigate cost against CUR data
• See top movers: EC2 in us-east-1, linked account 394812...
• Run kulshan investigate ec2 for resource-level breakdown
• See specific instance IDs, launch dates, tags showing "product-launch" workload
• Cross-reference with deployment logs (already have the timestamps and resource IDs)
• Total time: 20 minutes, complete answer with evidence

The difference is not magic. It's having the right data accessible and the right tools to query it.

Measuring MTTE

The clock starts when a cost question is accepted for investigation. It stops when the explanation is documented with supporting evidence, known limitations, ownership, and a recommended next action.

You may eventually want to distinguish:

• Time to first hypothesis: how long until someone has a working theory
• Time to defensible explanation: how long until there's evidence-backed documentation (this is MTTE)
• Time to corrective action: how long until something changes

MTTE is the middle one. It measures explanation quality, not just speed.

Reducing MTTE in your organization

MTTE is a useful metric because it's measurable. Track how long cost questions take to answer. Look at the bottlenecks.

Common bottlenecks:

• Data access: Enable CUR 2.0 if you haven't. Put billing data where engineers can query it.
• Tooling: Use tools that query billing data directly instead of clicking through dashboards.
• Ownership: Tag resources. Map accounts to teams. Make ownership visible in the billing data.
• Process: Define who investigates cost questions and what "answered" means.

Kulshan helps with data access and tooling. Mission FinOps helps with the full picture: data foundations, ownership models, and investigation process.

What's next

MTTE is a useful frame for thinking about cost investigation maturity. Over time, I'll share more about what low MTTE looks like in practice: the data foundations, the tooling, the processes, and the organizational patterns that make cost questions answerable.

If you have cost questions nobody has answered properly, reach out. That's what Mission FinOps does.