Multi-Cloud Strategy
Use Microsoft Fabric as a unifying analytics layer across AWS, GCP, SaaS platforms, and on-premises systems without forcing a full migration on day one.
Data Architect Cloud Architect Platform Owner — This page is for teams deciding how Fabric fits into a broader multi-cloud or hybrid estate while preserving existing investments.
Microsoft Fabric works well as a multi-cloud data hub because OneLake gives teams a single logical data estate even when the physical data remains spread across different clouds or data platforms. Instead of treating every external source as a migration project, Fabric lets you standardize governance, analytics, and collaboration around a shared destination while still respecting where the source data lives today.
Two mechanisms make this practical. Shortcuts provide zero-copy virtualization, exposing external data in place so Fabric can read it without ingestion or duplication. Mirroring provides near real-time replication, continuously landing external operational data in OneLake as Delta tables for low-latency analytics. Together they give architects a spectrum between “leave it where it is” and “replicate what matters.”
The core thesis is simple: you do not need to migrate everything into Fabric to get value from Fabric. In many organizations, the best first step is to unify access, governance, and analytics across clouds, then selectively move or replicate the datasets that justify deeper consolidation. For the lower-level mechanics of these options, see Data Integration for the full guidance on shortcuts, mirroring, and pipelines.
🔗 Unify first
Use shortcuts when the data is already well managed in AWS, GCP, or Azure and the main requirement is shared analytics, not storage relocation.
🪞 Replicate selectively
Use mirroring for high-value operational data that needs near real-time access in OneLake for BI, SQL, and Direct Lake scenarios.
🏗️ Modernize incrementally
Keep existing platforms for established workloads while introducing Fabric for cross-domain analytics, governance, and new workloads.
AWS Integration
Connect Fabric to S3-centric estates and position OneLake as the analytics layer without forcing an AWS data lake rewrite.
Amazon S3 shortcuts are the primary AWS integration pattern for Fabric. They let you connect OneLake to S3 buckets and query supported data without copying it into Fabric storage first. This is especially useful when an AWS platform team already operates the lake, but business analysts or downstream consumers want Fabric-native experiences such as lakehouse exploration, notebooks, or Power BI on top of that data.
Setup usually involves configuring an ADLS-compatible credential flow plus the required ARN-based access configuration for the bucket or path being exposed. In practice, teams should align this with central cloud credential policies rather than embedding ad hoc credentials in individual workspaces. Fabric can read common lake formats such as Delta, Parquet, and CSV, with Delta providing the richest behavior for consistent analytics.
The canonical pattern is AWS S3 as the data lake, Fabric as the analytics layer. Raw and curated data can stay in AWS while Fabric provides unified SQL, semantic modeling, reporting, and cross-domain access. For Amazon Redshift, there is no direct mirroring path today, so teams generally use Data Pipeline copy or export via S3 plus a shortcut when the goal is to make Redshift-managed data visible to Fabric.
🪣 S3 shortcuts
Best for lake data already stored in open file formats. Queries read in place, so there is no duplicate storage bill in OneLake.
📦 Redshift handoff
When Redshift is the source of truth, use copy pipelines or unload patterns through S3 because native mirroring is not the current integration model.
💸 Cost awareness
Model cross-cloud egress costs, added network latency, and credential rotation overhead before assuming zero-copy always means lowest total cost.
Shortcuts eliminate Fabric-side copy jobs, but they do not eliminate network and source-system realities. Query patterns that repeatedly scan large S3 datasets can create meaningful egress charges, and interactive workloads may feel slower than locally materialized data. Validate credential lifecycle, latency, and query shape early.
GCP Integration
Use Fabric to analyze Google Cloud data in place or move selected data products when BigQuery or GCS remain core parts of the estate.
Google Cloud Storage shortcuts give Fabric the same zero-copy pattern for GCP that S3 shortcuts provide for AWS. By configuring a service account key and the target bucket path, teams can expose GCS-hosted data into OneLake without relocating the underlying files. Supported file formats mirror the S3 experience, with Delta, Parquet, and CSV being the most common options.
This makes a strong pattern for organizations that already use GCS as a cloud landing zone or archival store but want to centralize analytics in Fabric. Fabric can sit above that storage layer and provide a common experience for lakehouse engineering, semantic modeling, and reporting. It is also a practical way to let Azure-based consumers work with GCP datasets without building a separate ingestion estate first.
For BigQuery, Fabric does not currently offer native mirroring. When data movement is required, use Dataflow Gen2 or Data Pipelines to extract and load the necessary datasets into Fabric-managed storage. That gives more control over scheduling, transformations, and incremental logic, but it is a different design choice than shortcut-based virtualization.
☁️ GCS landing zone
Keep ingestion and raw retention in GCS, then expose trusted zones to Fabric for centralized analytics and reporting.
🔄 BigQuery movement
Use low-code or pipeline-based movement when the requirement is to persist data in OneLake rather than just read it in place.
📏 Same trade-offs
The same cross-cloud realities apply here: egress, latency, and secure credential handling should be part of the architecture review from the start.
Snowflake Integration
Use mirroring for near real-time replication from Snowflake into OneLake while keeping established Snowflake workloads in place.
Snowflake is one of the clearest examples of Fabric’s side-by-side modernization story. Rather than forcing an abrupt warehouse migration, Fabric can mirror selected Snowflake tables into OneLake as Delta tables for downstream analytics, Power BI, and cross-domain data product consumption. The design objective is not necessarily to replace Snowflake immediately, but to make its data easier to operationalize inside a broader Fabric platform.
Mirroring works through Snowflake streams and tasks to support incremental synchronization of selected tables. This is a near real-time replication pattern rather than a one-time export, making it appropriate for operational reporting and shared analytics scenarios where minutes matter but sub-second streaming is not required. Fabric can then treat the replicated data like other Delta-native assets in OneLake.
Shortcuts are not the Snowflake pattern; mirroring is the primary mechanism here. That matters architecturally because you are explicitly choosing managed replication into OneLake rather than direct read-through virtualization. The upside is better alignment with Fabric-native performance and downstream usability. The trade-off is storage for the replicated copy plus the operational design around table selection and sync governance.
Interoperability runs both ways. Snowflake can read from OneLake, and Fabric can mirror from Snowflake, which opens a pragmatic coexistence pattern: preserve Snowflake for existing pipelines or teams while using Fabric for new analytics, BI acceleration, or domain-level data sharing. Per the requested guidance, treat this capability as GA status confirmed at FabCon 2026.
🪞 Primary mechanism
Snowflake integration is a mirroring-first pattern, suitable when selected data needs to become Fabric-native Delta for broader consumption.
🤝 Side-by-side adoption
Keep Snowflake where it already delivers value, and use Fabric for incremental expansion into BI, governance, and shared analytics use cases.
📚 Table-by-table control
Start with the specific Snowflake tables that drive analytics demand instead of replicating an entire estate without a clear consumer need.
Databricks Interoperability
Connect Fabric and Databricks through shared Delta patterns, Unity Catalog integration, and a pragmatic split of engineering versus analytics responsibilities.
Fabric and Databricks are often used together rather than as mutually exclusive choices. A common enterprise pattern is to keep Databricks for advanced engineering, data science, or ML-heavy pipelines while using Fabric for BI, semantic modeling, self-service analytics, and OneLake-centered governance. Because both platforms align around open Delta patterns, interoperability is much stronger than it would be between proprietary storage engines.
Fabric can work with Unity Catalog integration to mirror Delta tables from Databricks, enabling Fabric consumers to use curated engineering outputs without rebuilding the same logic in a second platform. Delta Sharing also matters here because it is an open protocol for sharing Delta data across platform boundaries, reducing the need for brittle bespoke exports.
The relationship is increasingly bidirectional. Per the requested guidance, Databricks can read from OneLake via Unity Catalog, noted as a preview announced at FabCon 2026. That means OneLake can act not just as a Fabric destination, but as part of a broader lake-centric architecture where multiple engines participate. The practical architecture pattern is: Databricks for ML and deep engineering, Fabric for analytics and BI acceleration.
Validate Delta format compatibility, supported table features, and table format version alignment before assuming full portability. Open table formats improve interoperability, but advanced platform-specific features can still create friction if not tested early.
🧠 Best split of labor
Let Databricks own feature engineering, ML pipelines, and complex distributed processing while Fabric owns downstream semantic and BI consumption.
📤 Delta sharing
Use open sharing patterns wherever possible so the integration model remains portable and less dependent on custom copy pipelines.
🔍 Compatibility testing
Test representative tables, not just sample files, especially if your estate uses advanced Delta features, governance policies, or nontrivial schema evolution.
On-Premises & Hybrid
Bridge transactional systems and private networks into Fabric using gateways and selective replication instead of forcing all systems into the cloud first.
Hybrid is still the default reality for many enterprises. Core ERP, operational databases, manufacturing systems, and regulated data stores often remain on-premises even when analytics strategy has moved to the cloud. Fabric fits this model through the on-premises data gateway, which acts as the secure bridge between private sources and Fabric services.
The gateway supports common enterprise sources such as SQL Server, Oracle, SAP, and selected file system access patterns. Organizations should understand the distinction between standard mode, which is shared and centrally managed for enterprise workloads, and personal mode, which is intended for individual self-service scenarios and is not the right choice for governed platform integration.
SQL Server Mirroring is the standout hybrid pattern when near real-time analytics is required. Fabric can replicate on-premises SQL Server databases into OneLake in near real-time, provided CDC is enabled on the source and the gateway is configured correctly. That gives architects a clean coexistence model: keep the transactional system on-premises, but move analytical consumption into Fabric where lakehouse, warehouse, and Power BI tooling can operate at scale.
For Azure resources hidden behind private networks, the VNet Data Gateway provides a cloud-managed gateway option that reduces some of the operational burden of self-hosted connectivity. The broader architecture pattern is straightforward: on-premises sources → gateway → Fabric → analytics. This is often the most practical path for phased modernization because it respects production system boundaries while still centralizing analytics in the cloud.
🏭 Keep transactional local
Do not move a critical transactional system just to satisfy an analytics requirement. Bridge it to Fabric and separate transactional constraints from analytical scale.
🪞 SQL Server mirroring
Use CDC-backed mirroring when near real-time reporting matters and pipeline scheduling is too slow or too brittle.
🔐 Gateway discipline
Treat gateway placement, patching, credential ownership, and HA design as architecture topics, not as last-mile admin details.
Landing Zone Patterns
Place Fabric inside a broader Azure platform design so multi-cloud data access does not bypass governance, identity, and operational standards.
Multi-cloud integration still benefits from a strong Azure foundation. In Cloud Adoption Framework terms, Fabric should live inside a deliberate landing zone strategy rather than as an isolated SaaS purchase with ad hoc governance. This is how platform teams ensure that Fabric connectivity, identities, monitoring, data protection, and environment design remain aligned with the rest of the enterprise estate.
A typical pattern separates a Data Management Landing Zone from the Data Landing Zone itself. The management zone holds central capabilities such as governance, Microsoft Purview, monitoring, policies, and shared security controls. The data zone contains the actual Fabric capacities, workspaces, OneLake-aligned operating constructs, and integration points used by delivery teams. This split gives central teams clear control points without bottlenecking every data product change.
Fabric then becomes the analytics platform inside the wider Azure architecture, not a disconnected exception. For multi-tenant operating models, architects usually choose between shared capacity for lightweight or centrally governed domains and dedicated capacity per business unit where isolation, chargeback, or predictable performance is more important. For deeper CAF guidance, see Frameworks — CAF guidance.
🏛️ Management zone
Centralize policy, governance, identity integration, Purview, and monitoring so multi-cloud access remains visible and enforceable.
🏗️ Data zone
Host Fabric capacities, workspace standards, and domain-level implementation patterns where product teams can deliver safely.
🏢 Tenant model
Pick shared versus dedicated capacity deliberately based on performance isolation, budget ownership, and domain autonomy.
Decision Matrix: Shortcut vs Mirror vs Copy
Choose the lightest-weight integration method that still meets your freshness, performance, and transformation requirements.
Most architecture mistakes happen when teams pick one integration pattern and force every source through it. The better approach is to choose the mechanism that matches the source shape and business need. Shortcuts are best when the source is already lake-friendly. Mirroring is best when operational data needs near real-time analytical availability. Data Pipelines are best when movement and transformation are both required.
| Factor | Shortcut | Mirroring | Data Pipeline (Copy) |
|---|---|---|---|
| Data movement | None (in-place) | Incremental replication | Full/incremental copy |
| Latency | Real-time (read) | Near real-time (minutes) | Batch (scheduled) |
| Data format in OneLake | Source format | Delta | Delta/Parquet |
| Cost | No storage cost | Storage for replica | Storage for copy |
| Supported sources | ADLS, S3, GCS | SQL DB, Cosmos, Snowflake, etc. | 100+ connectors |
| Use case | Analytics on existing lake data | Operational analytics on OLTP | ETL/ELT, full data movement |
| Data freshness | Always current | Minutes lag | Depends on schedule |
| Transformation | None | None (raw replication) | Full transformation support |
If the source is already a well-structured lake, start with a shortcut. If the source is a transactional database that needs fast analytical visibility, start with mirroring. If the source requires reshaping, cleansing, joins, or enrichment before use, use a pipeline.
Best Practices
Adopt multi-cloud and hybrid integration patterns incrementally, with security, cost, and observability built in from the start.
Start with shortcuts
For existing lake data in AWS or GCP, shortcuts usually deliver the fastest proof of value with the least architectural risk because they avoid migration and re-ingestion complexity.
Mirror operational systems selectively
Use mirroring for transactional sources that need near real-time analytics, especially where direct reporting against the source would create risk or performance pressure.
Keep copy pipelines purposeful
Reserve full copy patterns for transformation-heavy ETL or where governance requires a separately managed analytical copy rather than in-place access.
Budget for egress
Cross-cloud reads are never just a connectivity decision. Include data transfer charges, scan behavior, and usage growth in the business case.
Prefer secure connectivity
Use managed private endpoints and approved credential patterns whenever the source or regulatory environment supports them.
Test before standardizing
Validate latency, query performance, refresh behavior, and operational supportability with real workloads before turning a pattern into platform standard guidance.
Document the data map
Maintain a clear inventory of which datasets are virtualized, mirrored, or copied, along with owners, credentials, SLAs, and downstream consumers.
Resources
Official references for shortcuts, mirroring, and pipeline-based data movement in Microsoft Fabric.
Use these references to confirm product details, supported sources, and setup steps as features evolve. For design decisions, combine these technical docs with your organization’s landing zone, security, and cost-management standards.