When teams model the cost of observability, they count ingestion and storage and stop there. But there is a third line item that hides in the architecture of every SaaS monitoring platform: data egress cost. Every gigabyte of telemetry that leaves your cloud to reach a third-party observability or SIEM vendor is a gigabyte you pay your cloud provider to move, plus a gigabyte of risk you cannot claw back. This post breaks down observability egress costs, why they scale faster than teams expect, and how to eliminate them entirely.
What data egress actually is
Cloud providers charge for data egress, the traffic that leaves their network. Moving data between regions costs money. Moving data out to the public internet, for example to a hosted observability SaaS, costs more. Ingress is usually free; egress is where the meter runs. That pricing asymmetry is the entire reason egress sneaks up on observability budgets.
Now consider what a typical monitoring pipeline does: agents on your hosts collect logs, metrics, and traces, then ship all of it out of your VPC to the vendor’s cloud for ingestion, indexing, and storage. Every one of those bytes crosses the egress boundary. The louder your systems, the bigger the egress bill, and telemetry is the loudest data most organizations produce.
Why telemetry egress costs scale faster than you think
- Telemetry is high-volume by nature. A single busy service can emit terabytes of logs and traces per day. That is terabytes of egress, every day, forever.
- It grows with your success. More users, more services, and more regions all multiply the outbound telemetry stream.
- It is billed twice. You pay your cloud provider to send the data out, and you pay the observability vendor to ingest it. Egress is the tax you pay before the invoice you already dreaded.
- Cross-region replication compounds it. Multi-region and disaster-recovery setups can move the same telemetry across the egress boundary more than once.
If your monitoring architecture ships raw telemetry out of your cloud, egress is not a rounding error. It is a recurring transfer fee on the single highest-volume data you generate.
Egress is a security and compliance risk, not just a cost
The dollars are only half the story. Every byte of telemetry that egresses to a third party is a byte that now lives outside your security perimeter. Logs and traces routinely contain sensitive material: user identifiers, session tokens, internal hostnames, query parameters, and sometimes regulated data like PII, PHI, or cardholder information that leaked into a log line. Shipping that stream to an external vendor means:
- Expanded attack surface. Your telemetry now sits in someone else’s cloud, subject to their breach exposure, not just yours.
- Data-residency and sovereignty problems. If regulations require data to stay in a region or in your control, egress to a vendor can violate them.
- Audit complexity. Proving who can access your logs is far harder when copies live in a third-party platform.
How to eliminate observability egress: keep the data in your cloud
The clean solution is architectural: stop shipping raw telemetry out. Sasquatch Labs compresses logs, metrics, and traces losslessly at the edge and stores the compressed data in your own cloud, not ours. Nothing leaves your environment, so there is no egress to a vendor and no telemetry sitting in someone else’s account.
Querying works the same way. Our Snowman query engine runs against your cold storage in place and speaks the query languages your teams already use (LogQL, SPL, TraceQL, PromQL). Because queries execute where the data lives and read the compressed chunks directly, there is no re-ingestion and no fresh egress every time an engineer runs a search. You get full-fidelity observability with the egress line item removed.
Model your real observability cost
When you compare observability and SIEM options, put egress on the whiteboard next to ingestion and storage. Ask the vendor a simple question: does my raw telemetry leave my cloud? If the answer is yes, you are paying a transfer fee and accepting a data-exposure risk that a bring-your-own-cloud architecture avoids entirely.
Related reading: BYOC observability and data sovereignty and the math of observability cost reduction. Learn more at sasquatchlabs.io.