When organizations work with Microsoft Fabric, one of the most attractive features is the ability to create shortcuts to external storage systems such as AWS S3.
A shortcut gives you the convenience of accessing external data as if it were already part of OneLake, without the need to copy or duplicate files.
But here’s the catch: while shortcuts simplify connectivity, they don’t eliminate one of the biggest hidden costs in cloud analytics — data transfer fees.
How Shortcuts Work
A Fabric shortcut is essentially a pointer to the data. When you query parquet files in S3 through Fabric, the compute engine (running in Azure) must fetch the bytes from AWS. This means the data is leaving AWS, and every gigabyte transferred counts as egress traffic.
So even though the files aren’t duplicated inside Fabric storage, AWS still charges you for every read that crosses into Azure.
The Cost of Reading 200 GB Daily
Let’s consider a realistic example:
Your S3 bucket contains about 200 GB of parquet files.
These files are refreshed daily, and your Fabric semantic model needs a daily refresh.
That means 200 GB per day × 30 days = ~6 TB per month.
Based on typical AWS S3 data transfer rates (around $0.09 per GB for the first 10 TB), you’re looking at:
6,000 GB × $0.09 ≈ $540 per month in AWS egress charges.
That’s before considering Fabric compute costs.
Why Shortcuts Don’t Reduce Egress Fees
It’s important to understand that shortcuts don’t magically reduce data transfer charges. They prevent duplication of storage, but the actual bytes must still move from AWS to Azure every time you run a query or refresh your model.
So, if you’re reading the full 200 GB daily, you’ll pay egress fees as if you were downloading the data each day.
Strategies to Optimize Costs
The good news is that you don’t have to accept those fees at face value. There are practical ways to bring them down:
Initial Full Copy + Incremental Loads
Do one large migration of your dataset into OneLake (or Azure Data Lake). After that, only copy the new or updated files each day. This reduces daily transfers to just the delta, which is usually far smaller than the entire dataset.
Partitioning and Predicate Pushdown
Structure your parquet files by date or partition keys. Ensure your queries are selective so that Fabric only reads what’s necessary instead of scanning all 200 GB.
Push Changes from AWS
Instead of letting Fabric pull data every day, configure S3 event triggers (with Lambda or DataSync) to push only the new files into Azure as they arrive.
Compression and Column Pruning
Since parquet is columnar, make sure your reports only pull the columns that are actually needed. This reduces the amount of data read — and the egress bill.
Evaluate Long-Term Data Residency
If your workload is permanent and heavy, it may be more cost-effective to migrate the dataset fully into Azure and avoid continuous cross-cloud transfers.
Fabric shortcuts offer a great way to connect to S3 without moving data right away, but they don’t avoid AWS data transfer charges. If you access large volumes of S3 data every day, costs can add up quickly.
The most effective approach is usually to copy once, then refresh incrementally, while designing your data to minimize unnecessary reads. That way, you get the best of both worlds: the convenience of Fabric integration and a controlled cloud bill.
on:
🚀 From 60 Minutes to 30 Minutes: Optimizing Spark...
nestorreveron
on:
4 Ways Copilot in Microsoft Fabric Accelerates Dat...
on:
Build apps with Fabric API for GraphQL with code g...
on:
Ownership of Fabric Items
on:
A Cost-Effective Fabric Solution Driven by Azure A...
on:
Working with Data in Microsoft Fabric