Most enterprise organizations are not single-cloud. They may have landed on AWS as their primary platform but use Azure for Microsoft 365 integration and GCP for Google Workspace analytics. Or they may have inherited a multi-cloud footprint through acquisitions. Whatever the cause, data that is fragmented across cloud providers creates analytical blind spots. An AI agent querying only the AWS data cannot see the Azure operational data needed for a complete picture. The Multi-Cloud Lakehouse is the architectural pattern that resolves this fragmentation.
The Federated Query Approach
The most practical implementation of a Multi-Cloud Lakehouse does not require moving data between clouds. Instead, a federated query engine connects to Iceberg catalogs in each cloud simultaneously. When an AI agent submits a SQL query that requires data from both an S3-hosted Iceberg table (AWS) and an ADLS-hosted Iceberg table (Azure), the engine decomposes the query, routes each sub-query to the appropriate cloud storage endpoint, collects the partial results, and merges them into a single result set that the agent receives as if all the data came from one place.
Dremio is particularly well suited to this pattern. Its source connector architecture treats each cloud storage location as a distinct source, and its distributed query planning layer handles the cross-cloud join logic transparently.
The Cross-Cloud Catalog Challenge
Federated querying handles the data retrieval problem. Catalog federation handles the discovery problem. For an AI agent to know that an Iceberg table exists in Azure ADLS, there must be a catalog entry for it. Apache Polaris supports multi-location catalog configurations, allowing tables hosted in different cloud storage locations to be registered in a single catalog namespace. An AI agent querying the Polaris catalog sees a unified table hierarchy regardless of which cloud provider hosts the underlying files.
Egress Cost Management
Multi-cloud data access carries a significant operational cost risk: cloud egress fees. When the query engine moves data between cloud providers to perform a JOIN, each gigabyte transferred incurs fees from the source cloud provider. Effective Multi-Cloud Lakehouse architecture minimizes cross-cloud data movement by keeping JOIN operations co-located with the larger table. If a small reference table lives in Azure and a 10 TB fact table lives in AWS, the engine should broadcast the reference table to the AWS compute cluster rather than streaming 10 TB of fact data to Azure. Query planners in engines like Dremio implement cost-based optimizer rules specifically for this cross-cloud join ordering problem.
