Seeking advice on hosting Teams Media Bots: Production requirements vs. Azure Bandwidth costs

Question

Hi everyone,

I’ve been working with the Microsoft Graph Communications SDK and have successfully built an application-hosted media bot that handles real-time video/audio. It’s currently running perfectly on a Windows Server outside of Azure for my dev testing.

I’m looking to move this to production, but I’ve run into a bit of a blocker regarding the official documentation which states that production media bots must be deployed on Azure.

The challenge is that for a video-heavy bot, the Azure egress/bandwidth costs are looking to be extremely high (often much higher than the compute itself). If I host externally there are dramatically more cost-effective bandwidth options (factor of 10).

A few questions for the community or anyone from the MS team:

Strictness of Azure Requirement: If a bot is hosted on-premises or in another cloud but meets all the technical requirements (Public IP, SSL, specific UDP ports), does Microsoft actively block these in production? Or is the "Azure only" rule mainly for supportability and latency reasons?

Cost Mitigation: For those running high-volume media bots in Azure, are there specific "best practices" or certain Azure networking SKUs (like Internet Routing Preference) that you've used to keep bandwidth bills from spiralling? Based on what I can see there are just no options that would give significantly lower egress costs.

Hybrid Approaches: Has anyone tried a hybrid setup—perhaps keeping the signaling/SDK portion in Azure but routing the heavy media processing to a private data centre via ExpressRoute to save on public egress? Although that probably doesn't actually save that much and is undesirable in terms of latency.

I'd love to hear how others are managing the commercial side of running application hosted media bots at higher volumes. Any tips or experiences would be hugely appreciated!

Answer 1

Hi @Alex Darlington
I have reviewed the official documentation along with related community discussions, and I would like to share the insights gathered so far in response to your questions. 

Strictness of Azure Requirement:  

If an application‑hosted media bot is deployed on‑premises or in another cloud and meets all documented technical prerequisites such as a public IP address, valid SSL certificates, and required UDP port availability, Microsoft does not publicly document any explicit technical blocking mechanism for production bots hosted outside Azure. 

That said, Microsoft documentation https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/requirements-cons…  is very clear that production application‑hosted media bots are supported only when deployed on a Windows Server guest operating system in Azure. The documentation does not frame this requirement as optional or advisory. Instead, Azure is presented as the expected and supported production environment, while non‑Azure hosting is mentioned exclusively in the context of development or testing. 

Because enforcement behavior is not described, the most accurate interpretation is that the “Azure only” requirement is primarily driven by supportability, reliability, and latency guarantees, rather than a publicly documented hard block. 

Cost Mitigation: 

At present, Azure offers limited mechanisms to meaningfully reduce these costs for real‑time media workloads. 

One commonly referenced option is Internet Routing Preference, which allows outbound traffic to use ISP routing rather than Microsoft’s premium global network. Azure positions this as a cost‑optimized routing path. 

Beyond configuring Internet Routing Preference and exploring Enterprise Agreement pricing, I have not found any Azure networking SKUs that are specifically designed to reduce real‑time media egress costs to a level comparable with dedicated hosting providers. 

Hybrid Approaches: 

Hybrid setups for application-hosted media are hard to justify because Microsoft documents that real-time media calls are pinned to the VM instance that accepted/started the call (media flows to that VM and media sent back must originate from it). If the “hybrid” idea depends on ExpressRoute for Microsoft 365 traffic, Microsoft explicitly says ExpressRoute is not recommended for Microsoft 365 in most circumstances and requires Microsoft authorization to use. If you don’t strictly need live raw media, Microsoft provides post‑meeting options to fetch transcripts/recordings via Graph after the meeting or call ends.

For deeper insights and perspectives from other community members, I recommend engaging with community · Discussions · GitHub. Many experienced developers and subject matter experts actively participate there and can often share practical, real‑world observations beyond the official documentation. 

I hope this provides additional context and is helpful. 

References: 

• https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/requirements-cons… 
• https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/routing-preference-overview 
• https://azure.microsoft.com/en-us/pricing/details/bandwidth/ 
• https://learn.microsoft.com/en-us/microsoft-365/enterprise/azure-expressroute 
• https://learn.microsoft.com/en-us/graph/api/resources/calltranscript 

---

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.