Back to Blog

Power BI and Azure Egress Charges - Why Your Tenant Region Matters

November 11, 2026•8 min read•Michael Ridland

Last year we reviewed an Azure bill for a mid-sized Australian business that had a line item nobody could explain. It was under "Bandwidth", it was a few hundred dollars a month, and it had been creeping up for a year. Their Azure SQL data warehouse was in Australia East. Their Power BI tenant, it turned out, was in Southeast Asia, because years earlier somebody had picked Singapore as the country when signing up for a trial of what was then Office 365.

Every scheduled refresh was hauling data out of Sydney and across to Singapore. Every DirectQuery visual was making the same round trip. They were paying for the privilege and getting slower reports as a bonus.

Microsoft has a documentation page on this called Power BI and Azure egress. It is about 200 words long, which makes it one of the shortest pages in the Power BI docs. The idea in it is simple, but the consequences are bigger than the word count suggests, so I want to fill in the gaps.

What egress is

Azure does not charge you for data coming into a data centre. It does charge for data leaving one, whether that is going out to the internet or across to another Azure region. That outbound traffic is called egress, and it is billed per gigabyte under bandwidth.

The per-gigabyte rate is small. For a lot of workloads it rounds to nothing. But Power BI can move a surprising amount of data, and it does it on a schedule, forever, without anyone watching.

The rule Microsoft gives you

The documentation boils down to one sentence: if your Power BI tenant is in the same Azure region as your Azure data sources, you do not incur egress charges for scheduled refresh and DirectQuery.

Those are the two cases that matter:

Scheduled refresh (Import mode). The Power BI service connects to your source, runs the queries, and pulls the results into the semantic model. If the source is in a different region, all of those rows are egress from the source region.

DirectQuery. Nothing is imported. Every time a user opens a report page, changes a slicer or clicks a bar, Power BI sends queries to the source and the results come back. Each response is egress if the regions differ.

Same region, no charge. Different region, you pay on every gigabyte that leaves.

Where does your Power BI tenant live?

This is the bit that catches people. Your Power BI home region was decided when your Microsoft 365 or Power BI tenant was first created, based on the country selected at sign-up. Whoever did that was probably not thinking about data architecture. It may have been a decade ago.

To check, open the Power BI service, click the question mark icon in the top right, and choose About Power BI. You'll see a line reading "Your data is stored in" followed by a region. Microsoft documents the steps in Find the default region for your organisation.

For most Australian organisations the answer is Australia East or Australia Southeast, and if your Azure resources are in the same one, you can stop reading and get on with your day. The exceptions we run into are:

  • Subsidiaries of overseas companies, where the tenant was created by head office in the US or Europe
  • Businesses that signed up from an overseas address, or with the wrong country selected
  • Organisations that merged, and inherited a tenant from the other side
  • Australian tenants in Australia Southeast (Melbourne) with all the Azure data in Australia East (Sydney), which is the sneaky one because both look "local"

That last case deserves a note. Two Australian regions are still two regions. Traffic between them is inter-region transfer, even though the data never leaves the country.

Is the cost a big deal?

Honestly, often not. I don't want to oversell this. For a typical setup with a handful of semantic models refreshing a few gigabytes a day, cross-region bandwidth is going to be tens of dollars a month, not thousands. Inter-region rates within a continent are a couple of US cents per gigabyte, and intercontinental is higher but still measured in cents. Check the Azure bandwidth pricing page for current figures, because they change.

Where it adds up:

  • Large Import models on frequent refresh. A 50 GB fact table doing a full refresh eight times a day is 400 GB of movement daily. Remember that the data travels uncompressed-ish over the wire, so it is bigger than the model size you see in the service.
  • Models without incremental refresh, which reload years of history each time to pick up one day of change.
  • Heavy DirectQuery reports with hundreds of users. Each query result is small. Millions of them are not.

So the money alone is rarely the reason to act. The real reasons are the two things that ride along with it.

The costs that don't show up under Bandwidth

Latency. A DirectQuery report with the service in one region and the database in another pays a network round trip on every visual. A page with twelve visuals fires at least twelve queries. Adding 100 or 200 milliseconds to each makes a report feel sluggish, and users will blame Power BI or the database when the cause is geography. Refreshes run longer too.

Data residency. If your Power BI tenant is offshore, then imported data is stored offshore. For Australian organisations in government, health and financial services, that can be a compliance issue that dwarfs any bandwidth charge. More than once we have started an engagement looking at performance and ended up in a conversation with the client's risk team.

If I had to rank them: residency first, latency second, egress dollars a distant third. The egress charge is useful mostly as a symptom. It is the line on the bill that tells you your architecture is split across regions.

What to do if the regions don't match

You have a few options, and none of them is perfect.

Move the data to where Power BI is. If you are early in a build, deploying your Azure SQL, Synapse or storage in the same region as your Power BI tenant is the cheapest fix. It only works if that region is acceptable for the data in the first place.

Use Multi-Geo. This is the fix Microsoft's documentation points to. With Power BI Premium or a Fabric capacity, you can create a capacity in a region other than your tenant's home region and assign workspaces to it. The semantic models in those workspaces then live in that region, next to your data. For an overseas-headquartered company with an Australian business unit, this is usually the right answer: a capacity in Australia East for the Australian workspaces.

There is a limitation the docs call out specifically. Premium Per User does not support Multi-Geo. If you are on PPU or Pro licensing only, your content sits in the home region and that is that. This is a real gap for smaller organisations, since the fix requires buying a capacity, and that changes the cost conversation completely.

Reduce what moves. If you cannot change regions, shrink the traffic. Set up incremental refresh so each run only pulls recent partitions. Remove columns nobody uses. Push aggregation back into the source with views so you import summarised rows instead of raw transactions. This is good practice anyway, and it cuts refresh time along with egress.

Migrate the tenant. It is possible to have a Power BI tenant moved to another region through Microsoft support. It is not self-service and it is disruptive, so treat it as a project with planning and downtime, not a ticket. We only recommend it when the tenant is in the wrong place for the whole organisation, not just one workload.

A couple of things the docs leave out

The Microsoft page talks about Azure data sources only. In practice you should think about every hop.

If you use an on-premises data gateway running on an Azure VM, that VM's region is part of the picture. Data goes from the source to the gateway and then to the Power BI service. We have seen gateways deployed in whatever region the infrastructure team happened to have a spare subnet, with the source and the Power BI tenant both somewhere else. Put the gateway close to the source and, ideally, in the Power BI region too.

The same thinking applies across Microsoft Fabric. Capacities have a region, OneLake data lives with the capacity, and pipelines that copy across regions are slower and pay for bandwidth. If you are planning a Fabric rollout, settle the region question on day one. It is very cheap to get right at the start and annoying to fix later.

The five minute check

Here is what I'd do this week if you have never looked at this:

  1. Open Power BI, go to About Power BI, and note where your data is stored.
  2. List the regions of the Azure data sources your semantic models connect to.
  3. Look at Cost Management in the Azure portal and filter to bandwidth to see what you are paying now.
  4. If the regions differ, decide whether it is a cost issue, a performance issue, a residency issue, or all three.

For most Australian businesses the check comes back clean. For the ones where it doesn't, it is far better to find out now than during an audit.

If you'd like a hand reviewing your setup, our Power BI consultants do this as part of architecture reviews, and our Microsoft Fabric team can help if you are weighing up a capacity for Multi-Geo. Get in touch and we can go through it with you.