Trufflow logoTrufflow

Platform Engineering · AWS · Kubernetes

Your observability data and your cost data have never met.

When someone asks why infrastructure costs went up, your answer shouldn't be a spreadsheet and a best guess.

Trufflow gives you the connection between service behaviour and cost impact.

Tell us about your stack
investigate.sh — payments-api
 cost query \
    --service payments-api \
    --window 24h \
    --show cost-per-request

  Connecting to observability pipeline...  ok
  Connecting to AWS billing data...        ok
  Resolving service → cost mapping...

ERROR  No connection between observability data and cost data.
         Cannot attribute cost to service behaviour.
         Trace context exists. Cost context: none.

HINT   Try manual investigation:
         1. Open AWS Cost Explorer
         2. Pull CUR export → query in Athena
         3. Cross-reference Datadog manually
         4. Build spreadsheet approximation
         5. Present with low confidence
         Estimated time: 2–3 days

 _

The data exists. The connection doesn't.

The engineering work that can't be closed
You shipped the optimisation.
Did it actually save anything?
Without cost as a signal in your workflow, you're shipping improvements you can't validate.
Sprint 1
Ticket opened
Data-pipeline is expensive. Refactor batch processing logic to reduce compute per job.
Goal: reduce infrastructure cost
Sprint 2
Shipped
Refactor complete. Latency improved 18%. Memory usage down 22%. Tests passing.
Performance: confirmed better
Sprint 3
Waiting
Billing data is 48 hours delayed. Need to wait for the monthly CUR export to see if costs actually changed.
Cost impact: unknown
Month end
Still unclear
Bill is slightly lower but there were 3 other deploys. Can't attribute the saving to this specific change.
Ticket: never definitively closed
The missing feedback loop

Every engineering discipline has a feedback loop. You deploy, you measure, you know if it worked.

Cost optimisation has been the exception — connecting observability data to billing data has meant spreadsheets, Athena queries, and best guesses.

Why your current stack can't answer the question

Every tool covers its layer.
None cover the gap between them.

The question “what does this service behaviour cost me right now?” sits in the space no existing tool was designed to occupy.

Query
cost_per_request · payments-api · now
Datadognull— no billing data
Cost Explorererror— not a billing primitive
OpenCostpartial— no trace context
Infracostn/a— pre-deploy only
Trufflow$0.0038· deploy v2.5 · −9% vs v2.4

The vision

Cost, where engineers
already look.

Not a new dashboard. Not a report. Cost as a native signal in the observability workflow you already live in — attached to every trace, attributed to every deploy.

Cost on every span

Open any trace in your existing observability tool. No new dashboard to open, no context switch.

Deploy-attributed savings

Every cost delta is attributed to the specific deploy that caused it. Optimization decisions are backed by evidence, not assumptions.

Regressions your alerts miss

Latency and error rates can stay flat while a deploy still drives up cost. Trufflow surfaces what your alerts miss.

No new tools to learn

Trufflow is a hosted service that pulls from your CUR exports and enriches your OTel spans. No additional instrumentation required.

payments-api · POST /api/process143ms
payments-api
143ms
→ auth.validate
17ms
→ batch.process
69ms · 63% cost
→ cache.write
17ms
Trufflow cost attributesenriched
trufflow.cost.total$0.0038
trufflow.cost.vs_baseline−9.5%
trufflow.cost.batch_process$0.0024
trufflow.cost.attributedtrue

batch.process is 63% of this request's cost. Reduced 18% by refactor in v2.5.

How it fits in your stack

No agents. No sidecars.
No traffic interception.

Trufflow is a hosted service that reads from your OTel pipeline and your CUR exports.
Your existing data flow is unchanged. If Trufflow goes down, nothing else does.

Trufflow architecture diagramTrufflow is a hosted service outside the critical path. It reads spans from Datadog or OTel Collector and CUR exports from AWS S3 via cross-account IAM, then returns enriched spans back to Datadog. The existing EKS to Datadog data flow is unchanged.EKS clusterEKS podsOTel SDKOTelCollectorAWS accountCUR exportsS3 · read-only IAMDatadogGrafana / OTel backendTrufflowHosted serviceCost attributionCUR × pod metrics→ span enrichmentenriched spans outenriched spansExisting flow — unchangedEnriched spans returnedTrufflow reads (never writes · never in critical path)
Where we start

Built for EKS on AWS.

GKE and AKS on the roadmap — tell us about your stack and we'll prioritise.
This is built for you if
You run Kubernetes on AWS (EKS)
significant monthly cloud spend
You use Datadog, Grafana, or Prometheus
or any OpenTelemetry-compatible stack
Cost is an active engineering concern
at sprint level or above
You can't trace your bill to a service
the core problem we solve

Trufflow requires read-only access to your CUR exports and your OTel collector pipeline. No write access. No data leaves your AWS account.

Early access

Sign up for early access.

Drop your email. We'll reach out to understand your setup, share what we're building, and give you early access when we ship. No calls you didn't ask for. No updates you didn't want.