Azure Bot Service

What it does

Azure Bot Service is the channel-management and hosting layer for conversational bots built with the Bot Framework SDK. It decouples the bot logic (your code) from the channels it communicates through:

• Channel connectivity — a single registered bot connects to Teams, Web Chat, Slack, Facebook Messenger, Twilio SMS, email, and more through the Bot Service channel configuration.

• Bot registration — provides the identity (App ID, endpoint) that channels use to authenticate and route messages to your bot.

• Direct Line channel — a secure REST API channel for embedding a bot into a custom web or mobile app.

• Teams integration — deep integration with Microsoft Teams for tabs, messaging extensions, and proactive messaging.

• Activity handler model — the Bot Framework SDK (C# or Node.js) provides a structured programming model for handling messages, events, card interactions, and dialogs.

• Adaptive Cards — rich, platform-agnostic card rendering for structured interactive messages in any channel.

Azure Bot Service does not provide the AI or NLP capabilities — it is purely the plumbing. Intelligence comes from services the bot calls: Azure OpenAI, Azure AI Language (CLU/QnA), LUIS, or any other API.

When you'd use it

• You need full programmatic control over bot logic that Copilot Studio's low-code canvas cannot express.

• You are building complex, stateful, multi-turn dialog flows with branching logic, custom authentication, or deep integrations.

• You need to publish a bot across multiple channels (Teams + Web Chat + Slack) from a single codebase.

• You want to avoid the message-based billing model of Copilot Studio for high-volume scenarios.

• You are integrating a chatbot into a custom mobile or web application via Direct Line.

Sample use case

A telecoms provider builds a customer service bot that handles account queries, plan upgrades, and fault reports. The bot logic runs as an Azure App Service, connecting to CRM APIs for account data, Azure AI Language for intent recognition, and Azure OpenAI for generative fallback responses. The bot is published to both the company's website (via Direct Line) and Microsoft Teams for internal support staff. The development team owns the full codebase and can iterate on dialog flows without any platform constraints.

Example reference architecture

Pricing & How Costs Work

Azure Bot Service itself is structured around two components: the Bot registration (control plane) and the channels (communication routing). The cost model is deliberately simple — the Service is mostly free, with costs concentrated in the compute hosting the bot and the AI services it calls.

Bot Service channel charges

Where bot costs actually come from

The Bot Service channel layer is free; all meaningful cost is in the resources the bot uses:

Key pricing mechanics:

• App Service hosting: If the bot runs on an App Service plan (S1, S2, etc.), it bills continuously regardless of message volume — this is an always-on cost. Scaling up (larger SKU) or out (more instances) multiplies this cost.

• Azure Functions (Consumption plan): Bot logic hosted on serverless Functions bills only per execution + memory consumption — well-suited to low- or medium-volume bots with variable traffic.

• Container Apps: A modern hosting option that scales to zero; suits bots with intermittent traffic and removes the always-on App Service cost.

• Cosmos DB state storage: Multi-turn conversations require storing state (dialog stack, user data) between turns. Each read/write consumes Request Units (RUs). High-volume bots with complex dialog state can generate significant Cosmos DB costs.

What Drives Costs

Cost optimisation levers:

• Use Azure Functions or Container Apps instead of App Service for variable-traffic bots to eliminate always-on compute cost.

• Right-size the App Service plan based on actual CPU/memory usage, not anticipated peak — many bots run comfortably on S1 or even B2.

• Use GPT-4o mini or AI Language CLU for intent recognition instead of GPT-4o — CLU is significantly cheaper per call for structured intent matching.

• Implement response caching for FAQ-style intents — cache common answers rather than calling AI services on every identical input.

• Minimise Cosmos DB state size — store only essential dialog state, not full conversation history, to reduce RU consumption.

• Set Application Insights sampling to reduce log ingestion volume for high-traffic bots; full telemetry is rarely needed for every message in production.

• Use free standard channels rather than building custom Direct Line integrations where Teams or Web Chat meets the requirement.

Azure Cost Data — Meters & Meter Subcategories

Azure Bot Service channel costs appear under the Bot Service service family in Cost Management. Resource type: Microsoft.BotService/botServices.

The Bot Service resource itself generates almost no billable meters. The cost picture for a bot is assembled from multiple other services:

Key notes for cost attribution:

• Because Bot Service itself is free, there is no single resource in Cost Management that represents the "total bot cost." A resource group per bot (containing the App Service, Cosmos DB, AI services, and the Bot registration) is the most effective way to see a complete cost picture in Cost Management's resource group view.

• Tagging the resource group (e.g. bot=customer-service, env=prod) ensures that all resources within it inherit the tags and can be filtered consistently in cost exports.

• For bots with shared AI service resources (e.g. one Azure OpenAI account used by multiple bots), the bot-level cost attribution requires Azure Monitor Metrics or custom logging — billing data alone cannot distinguish which bot's calls generated which token charges.

Common Developer Mistakes That Drive Up Costs

• Hosting the bot on an App Service Plan when it could run on Consumption Functions. App Service plans bill 24×7 regardless of traffic. A bot with low or intermittent traffic running on an S1 App Service plan pays for idle compute around the clock. Azure Functions on the Consumption plan only bills per execution — significantly cheaper for bots that handle fewer than a few hundred thousand messages per month.

• Using GPT-4o for all bot responses regardless of intent complexity. Bots that route every user message — including simple navigation or FAQ responses — through GPT-4o accumulate token costs for queries that CLU (Azure AI Language) or a simple rule-based match would have handled at a fraction of the cost.

• Storing full conversation history in the state store. Bot Framework's built-in state management allows storing arbitrary data per conversation. Teams often store the full message transcript in Cosmos DB state, driving up RU consumption per turn. Only the dialog stack and essential user context should be stored in state.

• Not implementing response caching for frequently repeated queries. Many bots handle the same 20–30 questions repeatedly. Without caching, each instance generates a new AI service call, even for questions answered identically every time.

• Scaling App Service instances for headroom that never materialises. Teams provision multiple App Service instances for anticipated peak load that never arrives, paying for unused capacity indefinitely.

• Not disposing of unused bot registrations. While the Bot Service registration itself is free, the attached App Service, Cosmos DB, and AI service resources continue to bill after a bot is decommissioned if they are not deleted.

What Could Make Your Bill Go Up or Down Next Month

Could go UP:

• A bot is promoted from internal to external use, significantly increasing conversation volume and therefore App Service CPU, AI service call counts, and Cosmos DB RU consumption.

• A new intent handler is added that calls GPT-4o for every response, replacing a previously rule-based topic that made no AI service calls.

• App Service plan is scaled up (e.g. S1 → S2) to handle a load test and not scaled back down afterwards.

• Cosmos DB RU consumption increases because a new feature stores richer state per conversation turn.

• Application Insights sampling is disabled for debugging and not re-enabled, causing full telemetry ingestion at high volume.

• A Direct Line Speech channel is added, introducing per-audio-hour charges from Azure AI Speech.

Could go DOWN:

• Bot is migrated from App Service plan to Azure Functions Consumption plan as traffic analysis shows it is well within serverless limits.

• CLU is adopted for intent classification on common intents, replacing GPT-4o calls for those paths.

• A response cache is implemented for the top 20 FAQ intents, eliminating AI service calls for those queries.

• Cosmos DB state storage is pruned — only the dialog stack is retained rather than full conversation history.

• App Service is scaled from 2 instances to 1 after load profiling shows 1 instance handles peak load comfortably.

• Application Insights sampling is configured at 10% for high-volume, low-value telemetry events.

Most Common Optimisation Techniques