The specific situation: a team has already committed to Kinesis Firehose or S3 Transfer Acceleration, the pipelines are live, and they have no way to know when a single high-volume event stream is about to blow past the monthly budget. AWS Cost Explorer exists but it reports at the service level — it tells you that Kinesis cost $3,200 this month, not which stream caused it or which destination leg is the expensive one. By the time you see the bill, you've already spent it.
This gap is structural inside AWS. The Cost Explorer team is building a general-purpose billing tool for every AWS service across every customer. They have no reason to build Kinesis-specific pipeline-level attribution with per-stream budget alerts — it would serve a small fraction of their customer base and compete with their own incentive to let usage run. The data engineers who would want this have no way to request it loudly enough because they don't own the AWS account budget conversation.
The complaints are specific: Kinesis is called out for being 'expensive if ingesting large volumes or using multiple destinations' and for a 1MB/second write limit that forces teams to either batch awkwardly or pay for multiple streams. Neither problem is visible until it's a billing problem. Right now, teams set CloudWatch alarms on invocation counts, not on cost-per-stream — a mismatch that leaves budget exposure invisible until month-end.
This recurs every billing cycle. Every new stream added is another line of cost exposure with no owner. Every traffic spike is a potential overrun with no early warning. The concrete cost of not having this is discovered invoices and reactive architecture changes — which cost engineering time that's far more expensive than a monitoring subscription.
What to build
Build an AWS-connected dashboard that reads CloudWatch metrics and Cost Allocation Tags to attribute Kinesis Firehose and S3 Transfer Acceleration spend to individual streams and destinations, then lets a team set per-stream monthly budget thresholds with Slack or email alerts before the threshold is breached — not after.
Where to start
Target FinOps practitioners first — they already have budget authority and are actively looking for service-level cost visibility gaps inside AWS; winning one FinOps lead at a mid-size company gives you an internal champion who can justify the spend without needing an engineering sponsor.
The hard part
Getting accurate per-stream cost attribution requires interpreting AWS Cost and Usage Reports plus CloudWatch metrics in combination, and the mapping between the two isn't clean — early customers will find edge cases where attribution is wrong, which is exactly the kind of bug that destroys trust in a cost-focused product.
How it makes money
Monthly flat fee per AWS account connected, tiered by number of active streams monitored — starting at $99/month for up to 25 streams, scaling to $399/month for enterprise accounts with multiple AWS accounts under one organization.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in ETL Tools.
More ideas in ETL Tools