Observability is a growing cost centre for most engineering teams. The more you scale, the more logs you generate. And while storage has gotten cheaper, most observability tools haven’t kept up. 

To save money, many teams send logs to cold storage like S3 after a few days. It’s cheap, sure, but not exactly usable. The moment you need to investigate an old issue or audit past behaviour, you’re stuck digging through frozen data that’s hard to search and even harder to make sense of. S3 is built for storage, not search, correlation, or real-time debugging.

This post is about CtrlB’s approach: how we help teams search logs sitting in S3 directly, without rehydration or building complex pipelines, and how that changes the way you think about storing and accessing your data.

The Common Tradeoff: Retention vs Cost

The typical setup works like: 

• Logs are ingested, processed, and indexed in real time
• You keep them “hot” for a week or two, because it’s expensive
• Everything older gets pushed to S3 or Glacier as archived data
• That data is no longer part of your regular searches

If you do need to query old logs, you either:

• Don’t bother because it’s too much of a pain
• Spin up a batch job to pull and process the logs (like ETL)
• Hope someone already saved a copy somewhere
  

But none of these options is ideal. They’re slow, clunky, and usually require writing custom glue code or one-off scripts. You either wait hours for someone to run SQL through an external query engine, write a custom script, or, worse, you give up and guess.

Why Cold Storage Usually Means Cold Insight

It’s easy to store logs in S3. It’s cheap and scales forever. But once your data is there, it’s usually out of reach. That’s because most platforms charge a premium for fast, searchable storage, so teams only keep a few days or weeks of logs “hot". After that, the data is pushed to cold storage, where it’s hard to access or query. You either wait hours for a response or just give up and move on.

This makes it really hard to spot patterns over time. If something breaks today, and it looks familiar, you might not be able to pull up the logs from the last time it happened. Say you want to compare Black Friday traffic this year to last year, the data’s there in S3, but it’s buried. And without that context, you’re left guessing. With CtrlB, you don’t have to make those tradeoffs. You can keep all your data in S3 for as long as you want and still get answers instantly when you need them.

What CtrlB Does Differently

CtrlB flips this setup. Unlike traditional observability tools that charge for ingestion, CtrlB separates storage from compute. Your data stays in S3. CtrlB provides the compute layer on top, when you need to search, explore, or debug. That means you can keep logs forever, without paying for the things you’ll never look at. And when you run a query later, whether it’s a few hours or a few months after the logs were written, CtrlB’s query engine kicks in and gives you the results on demand.

Logs, Traces, and Services In One View

CtrlB doesn’t stop at search. Once you find the log line or trace of interest, CtrlB correlates it with the related service, upstream calls, and downstream effects. You get full system context in a single interface, built for devs and SREs.

There’s no bouncing between tools or stitching JSON in your head. Everything you need to debug is in one place, even if the data is stored in a million folders on S3.

Case Study: Scaling Logs Without Scaling Costs

One of our early users was dealing with 7– 8TB of logs weekly across their Kubernetes infrastructure. They were only keeping a few days' worth of hot data, mostly because of the high costs associated with ingestion and indexing charges.

They tried traditional cold storage workflows, sending logs to S3, then using Athena or writing Spark jobs to search later, but it just wasn’t practical, as the RCA (root cause analysis) took hours. Often, they skipped it altogether unless the issue was critical.

With CtrlB, they moved to a simpler model:

• Logs are written directly to S3
• The data is kept for as long as you need
• Everything else is accessed through CtrlB when needed
  

It helped them cut observability costs by more than 70% while improving their ability to look back in time and correlate across services.

Why This Matters

There’s a quiet trap a lot of teams fall into: you either keep all your logs (and pay dearly for it), or you throw them away (and lose visibility). CtrlB gives you another path - Keep everything. Search when it matters. Pay only when you query. Especially for:

• Debugging issues weeks after they occur
• Scaling without re-architecting pipelines
• Teams that are tired of paying to index everything upfront
  

S3 Isn’t the Problem. It’s the Opportunity.

S3 is a great place to store observability data. The problem is getting answers out of it. CtrlB turns S3 into an active part of your debugging workflow. You don’t need new formats or new pipelines. Just your logs, your questions, and a search bar.

If this sounds interesting, we’d love to hear from you- drop us a line at support@ctrlb.ai