Connecting Microsoft Fabric to Amazon RDS for Oracle - A Practical Guide

Plenty of Australian businesses live in two clouds whether they planned to or not. The core line-of-business system runs on Oracle, and at some point someone stood that Oracle database up on Amazon RDS because that was where the infrastructure team was comfortable. Meanwhile the analytics and AI ambitions are pointed at Microsoft Fabric, because that is where the Power BI reporting lives and where the leadership team wants the data strategy to go. Now you have production data in AWS and the place you want to analyse it in Azure, and something has to bridge the gap.

The Amazon RDS for Oracle connector in Microsoft Fabric Data Factory is that bridge. It lets Fabric reach into an Oracle database running on Amazon RDS and pull the data across into your Fabric environment, where you can shape it, model it, and put it in front of people. It is a genuinely useful connector, and it also has some sharp edges that are worth understanding before you commit to a design, because moving data between two clouds is never quite as simple as the connector diagram makes it look.

Why this connector exists at all

Multi-cloud is the normal state of things now, not the exception. I rarely meet a mid-sized or large Australian organisation that is cleanly all-in on one cloud. There is nearly always an Oracle system somewhere, often because it predates the current cloud strategy by a decade, and often running on AWS because that decision got made by a different team at a different time. Ripping it out and moving it is expensive, risky, and usually not worth it.

So rather than fight that reality, the practical move is to leave the Oracle database where it works fine and bring its data to where you want to analyse it. That is exactly what this connector is for. It treats Amazon RDS for Oracle as a first-class source, so you are not stuck writing custom extract scripts or standing up some brittle intermediate hop just to get Oracle data into Fabric. You point Fabric at the RDS instance, authenticate, and pull.

This matters because the alternative, hand-rolled extraction, is where data pipelines go to die. Someone writes a script, it works, they leave, the script breaks when Oracle changes, and nobody understands it. A supported connector inside Fabric Data Factory is a far more maintainable foundation, and it slots into the same orchestration, monitoring, and scheduling as the rest of your Fabric pipelines.

How it fits into a Fabric pipeline

In practice you use this connector as the source step in a Data Factory pipeline or a dataflow. You define the connection to your Amazon RDS for Oracle instance, and from there you can copy data into Fabric, typically landing it in a Lakehouse or Warehouse where the rest of your transformation and modelling happens.

The usual shape we build is a copy activity that lands the raw Oracle tables into a Lakehouse, then transformation logic on top of that to clean, join, and model the data into something analytics-ready, and finally Power BI reporting sitting over the modelled layer. The Oracle connector is the first link in that chain, and getting it solid matters because everything downstream depends on the data arriving reliably.

You have choices about how much you pull. A full load every run is simplest but gets expensive and slow as tables grow, and it hammers both the source and your egress bill. Incremental loading, where you only pull rows that changed since last time, is more work to set up but far kinder to everything involved. For anything beyond a modest table, incremental is the right call, and it is worth designing for from the start rather than retrofitting once the full loads start timing out. This is exactly the sort of architecture decision we work through on our Microsoft Fabric consulting engagements, because the choice you make early shapes how well the whole thing scales.

The cross-cloud realities to plan for

Here is where honesty helps more than enthusiasm. Moving data from AWS to Azure is not free, and it is not always fast, and the connector does not make those facts go away.

The first thing is egress cost. When you pull data out of Amazon RDS across to Fabric in Azure, AWS charges you for the data leaving its network. For a small daily incremental load, that is noise. For a large full load running frequently, it adds up in a way that surprises people when the AWS bill lands. This is the single strongest argument for incremental loading and for being thoughtful about how often you refresh. Pull only what changed, only as often as you actually need it, and the egress cost stays sensible.

The second is latency and throughput. Data crossing between two clouds travels further and through more hops than data moving within one. That means large transfers take longer than the equivalent within-Azure copy, and it means you should size your refresh windows with that in mind. If you are moving serious volume, this is where incremental loading stops being a nice-to-have and becomes the only sane approach.

The third, and the one people underestimate, is networking and security. Your Oracle database on RDS is presumably not open to the whole internet, and it should not be. So Fabric needs a secure, authenticated path to reach it, which means thinking about network configuration, firewall and security group rules on the AWS side, credential management, and how the connection is authenticated. This is fiddly, it crosses two clouds' worth of networking models, and it is where cross-cloud projects most often stall. Get your networking and security people involved early rather than discovering at integration time that the path you assumed exists does not.

What works well and what is still rough

The good news first. When it is set up properly, this connector does its job well and quietly, which is exactly what you want from a data connector. It slots into Fabric's orchestration, so your Oracle data lands on schedule alongside everything else, monitored the same way, and you are not maintaining some bespoke bridge off to the side. For getting Oracle data on RDS into a modern analytics platform, it is a solid, supported path, and that alone is worth a lot.

The rougher edges are the ones you would expect from any cross-cloud data movement. Performance tuning for large volumes takes real thought, and the naive full-load-every-night approach will bite you as data grows. The networking setup between AWS and Azure is genuinely more involved than a single-cloud connection, and it is the most common place we see projects lose a week. And Oracle itself brings its own quirks around data types, precision, and how certain values map into the Fabric world, so you want to validate carefully that what lands matches what left, rather than assuming a clean copy.

None of that is a reason to avoid the connector. It is a reason to plan the pipeline properly rather than wiring it up in an afternoon and hoping. The teams that get burned are the ones who treat cross-cloud data movement as a formality. The teams that do well treat it as the real engineering problem it is.

Where we come in

We do a fair amount of this exact work: helping Australian businesses that have data stranded in one cloud get it working usefully in another. The Amazon RDS for Oracle connector is one specific instance of a broader pattern, which is meeting organisations where they actually are, with their real, messy, multi-cloud estates, rather than pretending everything lives neatly in one place.

The engineering that makes these pipelines reliable, cost-aware, and secure is core to what our team does day to day. If you want a sense of the range, our Microsoft data and Data Factory work covers the pipeline side, and it usually connects into a wider business AI and data strategy rather than sitting on its own, because getting Oracle data into Fabric is only worth doing if it feeds something the business actually uses.

The bottom line

The Amazon RDS for Oracle connector in Microsoft Fabric Data Factory solves a very real problem for the many Australian organisations running Oracle on AWS while pointing their analytics at Fabric. It gives you a supported, maintainable way to bring that data across, which beats hand-rolled scripts every time.

Just go in with your eyes open. Cross-cloud data movement carries egress costs, latency, and networking complexity that single-cloud pipelines do not, so design for incremental loading, size your refresh windows realistically, and get the networking and security sorted early. Do that, and you end up with Oracle data flowing reliably into Fabric and a reporting layer people can trust.

If you have got Oracle data sitting in AWS and analytics ambitions pointed at Fabric, and the gap between the two is where things keep going wrong, that is a problem we enjoy solving. Take a look at our Microsoft Fabric consulting, or get in touch and we will help you design a pipeline that works and keeps working.