Hi, I am currently working around to ingest data from S3 into Snowflake, I use Pipeline in Fabric to do it. There are 2 options that I found:- First is create a shortcuts from S3 into Fabric Onelake, then I will process one Onelake into Snowflake.- Second is create a pipeline with source is S3 and sink the data directly into Snowflake. Could you recommend me which approach is better (for Fabric, it would acting as orchestrator, since all transformation will be done later in Snowflake). Also if i use shortcuts, will it cost more than using S3 connector in pipeline item ?

Hello bao_phan Both the options you mentioned will work technically, however, given your specific use case, and yuor consideration on cost, there's one that fits better. Option 1: Shortcut via OneLake (S3 > OneLake > Snowflake)When you use OneLake shortcuts, Fabric gives you a logical view over S3 rather than copying the data. Every time the pipeline reads the shortcut, Fabric is effectively streaming data out of S3 and into your process. This works well when Fabric engines also need to analyse the same data, but less so when Fabric is only acting as a coordinator. The main upside here is architectural flexibility. You get a shared, cloud‑agnostic data layer that Spark, SQL and Power BI can all reuse without duplication. It also provides a clean abstraction if you expect Fabric to become a consumer later on. The downside is cost and indirection. You incur AWS S3 egress on reads, Fabric capacity consumption for OneLake access, and then Snowflake load compute on top. Even with shortcut caching, this tends to be more expensive for batch ingestion, because each run still has to materialise data through Fabric. Option 2: Direct pipeline (S3 > Snowflake)With a direct pipeline, Fabric stays firmly in the orchestration role. Data flows straight from S3 into Snowflake, and Fabric simply triggers and monitors the COPY operation. There’s no intermediate lake layer and no additional data hop. This approach is simpler to reason about operationally. You only pay unavoidable AWS egress and Snowflake warehouse compute, while Fabric consumption stays minimal because it’s not reading or materialising the data itself. Cost attribution and performance tuning remain Snowflake‑centric. The trade‑off is that you’re not building a shared lake for Fabric users. If, later on, Fabric workloads need to query the raw data, you’d need to reintroduce OneLake or point Fabric directly at Snowflake instead. For ingestion‑only scenarios, though, this is usually acceptable. Recommended approachGiven that you’re using Fabric purely as an orchestrator and all transformations happen downstream, the direct S3 > Snowflake pipeline is the better fit. It avoids unnecessary Fabric compute, removes an extra data hop, and keeps the cost model clean and predictable. OneLake shortcuts simply don’t add enough value in this scenario to justify the overhead.

Ingest data from S3 into Snowflake | Microsoft Fabric Community

Forum Discussion

Related content

Data Ingestion Troubles

Least Privilege for Pipeline item to ingest data from SQL Server to Snowflake

Snowflake AI

API Data ingestion Orchestration

Moving data from S3 to Snowflake