Snowflake AWS → Azure → Microsoft Fabric — Gotchas, Part 4
I wanted to see whether scheduled Snowflake replication could give us more control than continuous mirroring. The source changed only a few times a day, so it felt reasonable to try matching replication to those updates.
Initially, things looked good. The data reached Azure, Fabric queries worked, and the row counts we compared matched.
The trouble started when we connected the workspaces that people actually used. The shared lakehouse could read a table, but a downstream workspace was looking for files it could not find.
In Part 2, I said I would try the Azure replication route. This post covers what worked, where we got stuck, and why I wasn't ready to call it a replacement for mirroring.
Architecture labels are anonymized. This is an engineering investigation, not a controlled benchmark.
Why I wanted to try this
Our source updated approximately three times daily. With continuous mirroring, we had seen higher Snowflake cloud-services usage, but there was no configurable mirroring window to line up with those updates.
I wanted to try this flow:
Snowflake on AWS → scheduled replication to Azure → Fabric access to the replicated Iceberg files.
Snowflake supports cross-cloud replication. We scheduled three refreshes daily, and the initial load and the scheduled refreshes we checked completed successfully. Snowflake replication overview
We checked schemas, ran SQL queries and compared row counts for selected tables. Those checks passed. The next step was to connect the existing downstream workspaces.
I was hoping this would help with cost too, but we hadn't measured enough to say it was cheaper.
The shared lakehouse worked. The downstream one didn't.
Our setup had a shared Fabric lakehouse, with other workspaces accessing its tables through shortcuts. A shortcut points to data elsewhere, so each workspace doesn't need its own copy.
We changed selected shortcuts in the shared lakehouse to point to the replicated source. We kept the table names, and the downstream shortcuts continued pointing to the same shared lakehouse.
The animation shows the routes we tested. Replication copies data from AWS to Azure; the shortcut links provide access to it.
That is where we started seeing SQL I/O errors and Spark missing-file errors downstream, even though reads in the shared layer worked. Some conversion logs also showed success during the investigation.
There is an extra step here that is easy to overlook. Iceberg metadata describes which files belong to a table. Fabric creates virtual Delta metadata so its engines can read that Iceberg table. Completing the Snowflake refresh doesn't verify the rest of that path. OneLake Iceberg virtualization
I had checked the shared layer. I needed to go one workspace farther and check the queries people would actually run.
We tried refreshing metadata, then rolled back
We refreshed SQL endpoint metadata for the affected tables. Some reads recovered; others still failed after the refresh reported success.
We also checked Spark separately. In Part 2, disabling the vectorized reader had helped with a decimal compatibility issue. It didn't fix these missing-file errors, so we couldn't treat this as the same problem.
For affected workloads, we pointed the shared shortcuts back to their original mirrored sources. Even that didn't immediately recover every table. Some shortcut objects needed to be recreated, followed by scoped metadata refreshes.
After that, the SQL and Spark sample reads we checked passed through both layers. We hadn't deleted the underlying source data. We had recovered those reads, but we still hadn't made the replica-backed route reliable enough to replace mirroring.
Then we found the regional restriction
Our Azure replica and the consuming Fabric workspace were in different regions. During troubleshooting, we found a restriction in Microsoft's documentation: for Iceberg virtualization through a shortcut pointing to a OneLake location, the target must be in the same region as the shortcut. Microsoft's platform limitations
We created a fresh same-region test pointing directly to the same replica folders. Its initial conversions and all-column SQL sample reads passed. The older cross-region setup still had mixed conversion results.
That was useful progress, but I wouldn't say it explained every earlier failure. The new setup had only passed its initial checks, and the older setup had worked initially too. We still needed support to explain the downstream file-reference failures.
One thing I would check much earlier next time is the region of every OneLake target. Adding another shortcut doesn't move the data into a different region.
A query passing still wasn't the full answer
Later, we also saw SQL samples working while the latest conversion logs showed failures. These were generic conversion errors, separate from the earlier missing-file errors and Part 3's clone-metadata issue.
Microsoft documents that failed conversion can leave the last successfully converted version available. So a working query alone couldn't tell us whether the latest source change had reached Fabric. Conversion behavior
I now keep these checks separate:
| What I want to know | What I check |
|---|---|
| Did replication finish? | The replica refresh result. |
| Can downstream users read it? | SQL and Spark through their actual access path. |
| Is the expected change there? | A known source change checked at the final consumer. |
The row counts and previews were useful. They just weren't enough to approve the switch.
Where we are now
Snowflake replication worked in this trial. The full Fabric consumption path still had issues, and we hadn't established a cost advantage.
We are now separately testing an AWS replica with direct S3 access from Fabric. I will cover that in another post once we have a clearer result, including what happens across repeated refreshes and how the costs compare.
For now, my advice is simple: before changing the source behind a shared shortcut, check the downstream workspace too. Keeping the same table name doesn't mean the queries behind it will keep working.
Top comments (0)