Back to Blog

Query every cloud at once, without moving a byte of data

04 May 2026
10
 words
5
 min

TL;DR

  • Vega’s federated analytics engine and in-place reverse indexing now span every major cloud (AWS, Azure, GCP) and every major legacy SIEM, returning normalized results from a single query.
  • Indexes live where the data lives. Telemetry never crosses cloud or regional boundaries, which keeps GDPR posture intact and audit trails clean.
  • Source-level RBAC is preserved end-to-end, so the unified surface never loosens the access model of any underlying system.
  • Eliminating cross-cloud movement and offloading high-volume logs from legacy SIEM indexes meaningfully lowers the SIEM tax without sacrificing query speed.
  • AI agents get the same broad, governed evidence access as human analysts, making agentic workflows practical in regulated environments.

Why does multi-cloud security force a tradeoff between cost, coverage, and compliance?

Security teams don't get to choose where their data lives. One acquisition brings AWS telemetry. A cloud-first product team runs on GCP. A compliance mandate keeps a business unit on Azure. The result: fragmented coverage, fragmented tooling, and an analyst who has to stitch together results from three different systems before they can even start investigating.

Most of this telemetry already exists somewhere cheap:S3, Azure Blob, GCS. The problem isn't storage. It's that data sitting in low-cost object storage isn't searchable. So teams are forced to re-ingest it into expensive legacy SIEM indexes just to make it queryable, paying a significant cost premium on data that may never generate a single alert. The economics are backwards: store it cheap, then pay again to make it useful.

The standard answers make it worse. Centralize everything into a data lake and you inherit egress bills, re-authorization headaches, and a new set of data residency risks. Build per-cloud pipelines and you're maintaining three versions of every detection, three query surfaces, and three audit trails. Neither path gives you unified visibility. They just move the complexity around.

For regulated organizations, the stakes are higher still. Cross-border data transfers create legal exposure. Demonstrating consistent coverage to auditors means reconciling outputs from systems that were never designed to talk to each other. And every time a new cloud footprint appears, the whole problem starts over.

We built multi-cloud federated analytics because the tradeoff between compliance, cost, and coverage shouldn't exist. Security teams should be able to run one query and get the full picture - without compromising on where data lives, who controls it, or what it costs to keep it searchable.

What does a multi-cloud federated query look like in practice?

The clearest way to see what changes is to walk through a single investigation. In a centralized model, this kind of scenario kicks off three or four parallel data engineering tasks before anyone gets close to an answer. With multi-cloud federated analytics, it's one query.

Persona: A security engineer at a regulated enterprise running workloads across AWS, Azure, and GCP.

Context: The environment spans three clouds and two legacy SIEMs. Each SIEM ingests a mix of telemetry: EDR events from endpoints running across cloud boundaries, network events from traffic flowing between them. No single SIEM has the full picture: one holds EDR telemetry from AWS and Azure workloads alongside east-west network traffic; the other holds EDR telemetry from GCP endpoints and network logs from the perimeter. The signals that matter are rarely contained within one system:an attacker moving laterally will leave traces in endpoint telemetry on one cloud and network events on another. But correlating across two SIEMs and three clouds manually isn't an investigation, it's a data engineering project.

The user action:

  1. The analyst runs a single federated query from Vega's unified surface, spanning both SIEMs, all three clouds, and every telemetry type in scope.
  2. The engine normalizes the query across EDR and network event schemas, translates it into each system's native dialect, and fans it out simultaneously across every source.
  3. Each source executes locally against Vega's in-place indexes. No data moves between clouds or SIEMs.
  4. Results come back normalized to a common schema, correlating EDR and network events across cloud boundaries in a single view.

The outcome: The analyst sees what no individual system could surface:endpoint activity on one cloud correlated against network events on another, across two SIEMs, in one query. The full attack path becomes visible without moving data, without manual joins, and without gaps.

This same pattern applies to threat hunts, detection engineering, compliance reporting, and AI agent workflows that need broad evidence access without bypassing access controls.

What changes in this scenario isn't the analyst's skill or the toolset's complexity. It's that cross-cloud, cross-SIEM scope stops being a special case at all. The architecture below is what lets it stay that way.

How does Vega query across clouds without moving data?

Three components work together to make federated multi-cloud analytics possible without data movement.

Architecture summary: Vega builds reverse search indexes directly inside your existing cloud storage, S3, Azure Blob, or GCS,  in the same region as your telemetry. A federated analytics engine translates and distributes queries across all three, executes them locally, and returns unified results. RBAC policies from each source travel with the query end-to-end, so the unified surface never bypasses the access model of any underlying system.

In-place indexing means the index lives where the data lives. No copies, no re-authorization, no egress triggered by making data searchable.

Permissions-preserving execution means RBAC policies from each source are enforced through least-privilege connectors. A unified query surface doesn't mean a flattened access model - each system's controls remain intact.

That tight coupling is what makes the architecture distinctive. Federation, regional fidelity, and source-level RBAC behave as a single coherent platform rather than three bolt-ons.

Key Takeaways

  • Full-coverage analytics without data movement: Vega indexes telemetry in-place inside S3, Azure Blob, and GCS - queries execute locally, data never crosses cloud or regional boundaries.
  • One query, three clouds: Analysts and AI agents run a single query and get normalized, unified results from every cloud and federated source - no manual reconciliation.
  • Compliance by design: Regional fidelity is maintained end-to-end, simplifying GDPR posture and making it straightforward to demonstrate consistent coverage to auditors.
  • Lower egress and SIEM costs: Indexing in-place eliminates cross-cloud egress entirely - there's no data movement to bill, and fast in-place analytics means teams can stop routing high-volume logs into expensive SIEM indexes - customers in beta reduced SIEM indexing costs by more than 70%.
  • Governed AI access: AI agents get broad access to the full evidence set across every cloud without bypassing the RBAC controls that regulated environments depend on.

What's Next

Multi-cloud federated analytics is available now. Schedule a demo to see it running across your environment.

Text Link
What can SAM do for you
Find out
What can SAM do for you
Find out
What can SAM do for you
Find out
What can SAM do for you
Find out
What can SAM do for you