Azure News - 2026-08-19

We're excited to announce the public preview of Traffic Manager linked records, a new Azure DNS capability that enables customers to directly associate Azure Public DNS record sets with Azure Traffic Manager profiles without using a CNAME to trafficmanager.net.

With this capability, customers can use Traffic Manager's DNS-based load balancing capabilities without exposing the intermediate trafficmanager.net domain in DNS responses. Azure DNS and Traffic Manager now work together to provide a more seamless, integrated DNS experience for applications running across Azure, hybrid, and multi-cloud environments.

Simplifying DNS-based traffic routing

Traditionally, customers using Azure DNS with Traffic Manager relied on CNAME records that returned a Traffic Manager hostname. DNS clients would then perform an additional lookup to resolve that hostname before reaching the application endpoint.

Traffic Manager linked records simplifies this process by allowing Azure DNS to resolve Traffic Manager routing decisions internally and return the appropriate endpoint information directly to clients.

The result is a cleaner DNS resolution path while preserving all of Traffic Manager's existing routing methods, health monitoring, and failover capabilities.

Key benefits

Better integration between Azure DNS and Azure Traffic Manager

Traffic Manager linked records allow Azure DNS record sets to directly reference Traffic Manager profiles, including nested profile configurations.

This enables sophisticated traffic routing architectures without relying on intermediate CNAME records, making complex global deployments easier to build and manage.

Improved security and DNS hygiene

Because DNS responses no longer expose the intermediate trafficmanager.net domain, organizations can simplify firewall rules and reduce reliance on intermediate DNS names.

Traffic Manager linked records also help eliminate a common source of dangling subdomains caused by orphaned or misconfigured trafficmanager.net records, strengthening overall DNS hygiene and reducing operational risk.

DNSSEC for Traffic Manager

Traffic Manager routing decisions are now resolved within Azure DNS, If the DNS zone is a DNSSEC signed zone the answers supplied by linked Traffic Manager profiles are automatically signed as well. This enables customer to use Traffic Manager profiles with DNSSEC, unlike a CNAME to trafficmanager.net which would break the DNSSEC end to end validation chain as trafficmanager.net is not a signed zone.

Zone apex load balancing

Traffic Manager Linked Records enable DNS-based load balancing directly at the zone apex (for example, contoso.com), where traditional CNAME records are prohibited by DNS standards. Customers can now bring Traffic Manager routing to root domains without complex workarounds. This is similar to ALIAS records but with much better integration and scale.

Cleaner & faster DNS responses

Clients now receive the final endpoint directly from Azure DNS instead of first resolving a trafficmanager.net hostname. By removing an extra DNS lookup, applications can experience lower DNS resolution latency while benefiting from Traffic Manager's intelligent routing decisions.

Built-in operational safeguards with strictly typed profiles

Traffic Manager Linked Records integrate with strictly typed profiles in Azure Traffic Manager, providing validation that helps ensure DNS record types remain compatible with their associated Traffic Manager profiles. In simpler words this features ensures that type of response served by the traffic manager profile matches the type of DNS records it is linked to.

The feature also prevents accidental deletion of Traffic Manager profiles that are still referenced by Azure DNS records, reducing the risk of configuration errors and improving operational safety.

Getting started

Traffic Manager linked records are available today in public preview.

Following record types can be used with Traffic Manager Linked Records

• A
• AAAA
• CNAME

Traffic Manager linked records are designed to make DNS-based load balancing simpler, faster, and more secure while preserving the flexibility and reliability customers expect from Azure Traffic Manager.

To learn more and start using Traffic Manager linked records today, see the DNS Traffic Management documentation.

In May, I published a runnable sample that put Azure API Management in front of an AI agent on Azure App Service. The agent framework was replaceable; the gateway was the contribution. APIM handled model access, token limits, semantic caching, token metrics, and the MCP traffic contract.

I followed that with a look at Foundry's new AI Gateway control plane. The data path was still APIM, but Foundry gave model and platform owners a first-party way to associate gateways, onboard projects, and allocate capacity.

Now API Management has a dedicated AI Gateway tier in public preview. That raises a different question for App Service users: does the application runtime change, or does the boundary around models and tools change?

The short answer is that App Service still owns the web application, agent orchestration, streaming experience, deployment lifecycle, scaling, managed identity, and application telemetry. The dedicated tier gives the model-and-tool boundary an AI-focused resource, portal, and runtime experience. To make that distinction concrete, I built a new runnable sample in which a Python agent on App Service can reach both its model and its MCP tools only through the dedicated AI Gateway.

Get the sample: Deploy and explore the complete App Service + AI Gateway sample on GitHub.

Preview notice: The dedicated AI Gateway tier is in public preview. It has no SLA, is currently available only in East US 2 and Sweden Central, and does not yet have an announced pricing or business model. APIs, limits, regions, policy behavior, and portal experiences may change. The sample is designed for learning and validation, not as a production-ready reference architecture.

The short version: App Service is the runtime; AI Gateway is the governed boundary

The architecture separates application concerns from AI access concerns:

• App Service hosts the FastAPI application, browser UI, Microsoft Agent Framework agent, server-sent event stream, retry behavior, and a small read-only MCP server.
• AI Gateway exposes the OpenAI-compatible model endpoint and MCP ToolServer endpoint used by the application. It owns the runtime access key, model registration, structured token policy, backend tool credential, and gateway telemetry exporter.
• Microsoft Foundry / Azure AI Services supplies the backing model. AI Gateway reaches it with managed identity.
• Key Vault stores the gateway runtime key and a separate MCP backend secret. App Service resolves both through managed identity-backed Key Vault references.
• Application Insights receives application OpenTelemetry and the preview gateway token-usage export.

First, which AI Gateway are we talking about?

The dedicated tier is not simply a renamed regular APIM instance. Its portal and resource model center on providers, models, ToolServers, runtime keys, telemetry exporters, and AI policies instead of asking an application team to begin with a general-purpose API surface.

What the sample actually does

The sample deploys a Python 3.12 FastAPI application to Linux App Service. The browser presents a small chat interface, but the useful part is behind it:

• Microsoft Agent Framework configured with an OpenAIChatCompletionClient whose base URL is the gateway OpenAI v1 route.
• An MCPStreamableHTTPTool configured with the gateway ToolServer route and a fixed allow-list of two read-only tools.
• Server-sent event streaming from App Service to the browser.
• A stable gateway model name, appservice-chat, initially mapped to a gpt-5-mini deployment.
• A separate MCP endpoint on App Service that rejects direct callers unless AI Gateway injects the expected backend secret.
• Bounded handling for 401, 404, 429, and transient 5xx responses.
• Application Insights and OpenTelemetry with correlation IDs and a strict telemetry attribute allow-list.
• Complete azd and Bicep infrastructure using the published preview resource contracts.

The model path

1. The browser posts a message to /api/chat/stream on App Service.
2. FastAPI creates or accepts a correlation ID and returns a server-sent event stream.
3. The Agent Framework client sends an OpenAI-compatible request to /default/models/openai/v1/ on AI Gateway with the gateway runtime access key.
4. AI Gateway resolves the stable catalog name appservice-chat, applies its structured token policy, and calls the backing Foundry deployment with the gateway system-assigned managed identity.
5. Text fragments return through AI Gateway and App Service as delta events. The browser renders them as they arrive.
6. Application spans and gateway token usage are correlated in Application Insights without capturing prompts, responses, keys, or backend secrets as custom attributes.

This is the first practical benefit for an App Service user: application code targets one governed OpenAI-compatible boundary. The app does not contain a Foundry endpoint, a Foundry key, or a direct-provider fallback.

The tool path

The sample deliberately hosts its MCP server on the same App Service application so the complete tool path is visible:

1. For the two documented operational prompts, the application sets Agent Framework tool_choice to the matching read-only tool. Other prompts retain automatic tool selection.
2. Agent Framework invokes the appservice-ops MCP ToolServer through AI Gateway using the same runtime access key.
3. AI Gateway validates the caller and injects a different x-appservice-mcp-secret header only on the backend hop.
4. The ToolServer calls /mcp on App Service.
5. App Service compares the backend secret and executes one of two fixed, read-only tools.
6. The tool result travels back through AI Gateway to the agent, which uses it in the streamed answer.

This explicit choice matters in a demonstration. Strong instructions make tool use more likely, but they do not make a model decision deterministic. The application therefore recognizes the exact status and deployment-context prompts shown below and requires the matching function. The backend publishes raw names such as get_service_status; the AI Gateway ToolServer advertises them to the client as appservice-ops_get_service_status and appservice-ops_get_deployment_context. Agent Framework must allow the gateway-advertised names without adding a second prefix.

The two tools are intentionally small:

Try it yourself

Proving the gateway is actually in the path

A successful chat response alone is not sufficient evidence. The sample includes several tests that make the gateway boundary observable.

1. Confirm the application has no provider fallback

The application accepts only gateway-shaped model and MCP URLs. Configuration validation rejects other endpoint shapes, and there is no provider endpoint or provider credential setting. If the gateway is unavailable or misconfigured, the application fails visibly rather than silently bypassing policy.

2. Test runtime-key enforcement

Call the gateway model route with a deliberately invalid key. The expected result is HTTP 401. The application treats this as a deployment or configuration failure and does not retry it.

3. Test model catalog routing

Request an unknown model name through the OpenAI-compatible route. The expected result is HTTP 404. A normal application request uses the stable name appservice-chat, showing that the gateway catalog—not a provider-specific name embedded in application source—controls resolution.

4. Test the structured token policy

The model registration includes a JSON-backed token-limit policy. In a disposable test environment, temporarily lower the limit, send enough requests to exceed it, and capture HTTP 429. Restore the normal value immediately afterward. During preview validation, the gateway returned 429 without a Retry-After header, so the sample honors the header when present and otherwise uses bounded fallback backoff.

5. Prove direct MCP access is denied

Call the App Service /mcp endpoint without the backend header. The expected response is HTTP 401. Then ask the agent for live service status and confirm the same tool succeeds through the AI Gateway ToolServer. The contrast proves that the gateway is adding backend authentication rather than exposing an anonymous tool endpoint.

6. Verify telemetry on both sides of the boundary

Use the correlation ID returned by the chat stream to locate the App Service request and agent span in Application Insights. For a tool prompt, confirm the safe application mcp_tool_called trace and the AI Gateway tools/call dependency with its gen_ai.tool.name attribute. Separately confirm token-usage telemetry for the model request. These views prove different parts of the path: the application executed the backend tool, the gateway mediated the ToolServer call, and the model route emitted usage telemetry.

Operating the boundary

Who authenticates to whom

The post-provision hook retrieves the generated gateway runtime key through the documented management action, writes it and a newly generated MCP backend secret to Key Vault without printing them, and completes the ToolServer credential configuration. No runtime key is committed to source control or written to the azd environment.

Changing the model without rewriting the application

The application always requests appservice-chat. Both the Foundry deployment and gateway model registration use that stable client-facing alias, while model name and version remain deployment parameters. This lets the platform team evaluate a backing model update at the gateway and infrastructure layer without changing the FastAPI or Agent Framework source.

The gateway governs; the application still has to be resilient

• 401 and 404 are not retried.
• 429 and transient 5xx responses use a maximum of three attempts by default, bounded exponential backoff, and jitter.
• Retry-After is honored when the gateway supplies it.
• HTTP status and retry metadata are recovered from Agent Framework exception wrappers before classification.
• Retries occur only before the first streamed token.
• A partially emitted stream is never replayed.
• Prompts, model responses, secrets, and upstream response bodies are excluded from application error messages and custom telemetry.

This is another important division of responsibility: the gateway governs access and policy; the application remains responsible for trustworthy interaction behavior.

What azd deploys

The boundary is the product

This is the through line across all three posts. The first sample showed that the agent framework can change while APIM remains the traffic boundary. The Foundry post showed that the same boundary can gain a model- and project-focused control plane. This sample shows what changes when the gateway itself becomes an AI-focused tier.

App Service still runs the agent. AI Gateway still does not replace application logic, deployment, or resilience. The better-together story is that App Service gives the agent a managed application runtime while AI Gateway gives that runtime a governed, observable, and replaceable boundary for models and tools.

One final preview boundary: This sample demonstrates a governed model and tool path, separated identities, model indirection, policy enforcement, and telemetry. It does not establish production readiness, scale limits, final pricing, or live multi-provider routing; the deployment uses one Foundry provider.

Resources

• You Can Build a Framework-Agnostic AI Gateway on Azure App Service—Here's How
• Microsoft Foundry Now Has an AI Gateway Control Plane—What Changes for App Service
• AI Gateway tier of API Management now in public preview
• Azure API Management AI Gateway overview
• Quickstart: Create an AI Gateway
• Runnable App Service sample
• Azure AI Gateway samples catalog

Why Markdown for Agents?

Web pages often contain scripts, styles, and HTML markup that are useful to browsers but add noise when the content is sent to an AI model. Markdown for Agents removes that extra markup and returns a smaller, text-focused response that is easier for agents to process and can reduce token usage.

In internal testing across more than 637,000 pages, converted Markdown responses were 97 percent smaller at the median than the source HTML, with a median conversion time of 2 milliseconds. Results vary based on the page and its content.

Public preview availability

Markdown for Agents is available in public preview for Windows apps on Azure App Service in all public regions. The app must use an App Service plan in the Basic tier or higher.

No additional authentication setup is required for Markdown conversion. Your app's existing authentication, authorization, and network access controls continue to apply.

This feature is only supported on Windows App Service at this time. Support for Linux apps will come later this year.

Enable Markdown for Agents

During the public preview, you can enable the feature through the REST API, ARM/Bicep template, or the Azure CLI using az rest. Dedicated Azure CLI commands and portal support are planned for a future update.

Azure CLI with az rest

Replace the placeholders with your subscription ID, resource group, and app name:

Verify the setting:

To disable the feature, send the same PATCH request with enabled set to false.

ARM template

Add the following property to your Microsoft.Web/sites resource using API version 2026-03-15:

Bicep

Request a Markdown response

After enabling the feature, request an HTML page from your app with the Accept: text/markdown header:

A successfully converted response includes these headers:

Content-Type: text/markdown; charset=utf-8
x-markdown-source: easy-markdown

The response body contains Markdown generated from the page's HTML. Common content such as headings, paragraphs, links, lists, images, emphasis, and code is preserved, while script and style content is removed.

Pages that cannot be safely converted may return their original HTML. Clients should check the Content-Type and x-markdown-source response headers before processing the response as Markdown.

What's next

Linux support is planned before the feature reaches general availability. We also plan to add dedicated Azure CLI commands and a portal experience in future updates.

Share your feedback

Try Markdown for Agents with your Windows App Service apps and let us know how it works for your agent scenarios. Share feedback, questions, and feature requests in the comments below.