As organizations modernize their applications in Azure, secure and resilient outbound connectivity has become just as critical as inbound security. Workloads need reliable access to external APIs, SaaS services, operating system updates, and partner endpoints, while still meeting strong security controls, predictable egress IPs, and high availability.  

Achieving all of this consistently requires using the right networking services together. 

To make this easier, we’ve updated the Azure Firewall create experience in the Azure portal to include StandardV2 NAT Gateway directly in the deployment flow. This new experience makes it quick and seamless to adopt a secure, scalable, and zone‑resilient outbound architecture from day one by using Azure Firewall and Azure NAT Gateway together. 

In this post, we’ll cover: 

• Why pairing Azure Firewall with StandardV2 NAT Gateway is a recommended design 

• How this combination simplifies secure and resilient outbound connectivity 

• What’s new in the Azure Firewall portal experience and how to get started 

Why Azure Firewall and StandardV2 NAT Gateway?

Azure Firewall and Azure NAT Gateway are designed to complement each other, each focusing on what they do best: 

• Azure Firewall provides centralized traffic inspection and policy enforcement, including IP address and FQDN filtering, threat intelligence, and logging. 

• StandardV2 NAT Gateway delivers high‑scale outbound SNAT, static egress IPs, and built‑in zone redundancy.  

StandardV2 NAT Gateway is zone‑redundant by default, automatically spanning availability zones within a region. This means outbound connectivity remains available even during a zonal failure without requiring multiple zonal NAT gateways or additional routing configurations. 

Together, this pairing cleanly separates: 

• Security policy and inspection handled by Azure Firewall 

• Outbound scale, resiliency, and IP predictability handled by NAT Gateway 

This separation is key for modern, large‑scale cloud workloads. 

A recommended outbound architecture

In a typical hub‑and‑spoke design: 

1. Workloads in spoke virtual networks route outbound traffic to Azure Firewall in the hub 
2. Firewall policies inspect and allow the traffic 
3. StandardV2 NAT Gateway is attached to the AzureFirewallSubnet in the Hub 
4. Approved traffic flows through StandardV2 NAT Gateway for SNAT 
5. Traffic exits Azure using static, predictable public IPs 

This approach provides several important benefits: 

• Scalable SNAT capacity for high‑connection workloads 

• Static outbound IPs for partner allow‑listing and compliance 

• Zone‑resilient outbound connectivity by default

For step-by-step architectural guidance, see Integrate NAT gateway with Azure Firewall in a hub and spoke architecture. 

Built for secure and resilient Azure environments

As customers increasingly adopt availability zones, large‑scale VMSS or AKS deployments, and zero‑trust network models, outbound connectivity must be secure, predictable, and resilient. 

By pairing Azure Firewall with StandardV2 NAT Gateway—and now surfacing this pairing directly in the portal create experience—customers can start with a production‑ready outbound architecture that scales with their environment. 

What's new in the Azure Firewall create experience in the portal

When creating a new Azure Firewall in the portal, customers can now: 

• Select and associate a StandardV2 NAT Gateway during firewall deployment. 

• Reduce post‑deployment configuration and manual touches. 

• Start with a recommended zone-resilient outbound architecture by default. 

By bringing NAT Gateway directly into the Firewall create flow, the portal helps guide customers toward a more secure and scalable outbound setup—without requiring them to stitch services together after the fact. 

Get started

You can try the updated experience today by creating a new Azure Firewall in the Azure portal and selecting StandardV2 NAT Gateway during deployment. 

With just a couple clicks of a button: 

1. In the Basics tab, configure your Firewall settings (ex., SKU, policy, virtual network). 
2. In the *new* Advanced tab, create a new or add an existing StandardV2 NAT gateway and associate StandardV2 public IP addresses or prefixes. The StandardV2 NAT gateway is automatically attached to the Firewall subnet—no additional routing or configuration required. 
3. Review and Create. 

Note: StandardV2 NAT Gateway is not yet available in all regions. If your selected region does not support StandardV2 NAT Gateway, the option to enable StandardV2 NAT gateway will not appear during Firewall creation. Refer to StandardV2 NAT Gateway limitations for more information. 

For more details, see: 

• Integrate StandardV2 NAT Gateway with Azure Firewall
• Integrate NAT Gateway with Azure Firewall in a hub‑and‑spoke network 
• Azure NAT Gateway SKUs 

In May, I published a runnable sample that put Azure API Management in front of an AI agent on Azure App Service. APIM handled token limits, semantic caching, token metrics, and access to the model. The point was simple: keep the agent framework interchangeable and put the production controls at the gateway.

A recent Apps on Azure post, From AI Adoption to AI Governance, arrived at the same architectural conclusion from a platform-governance angle. It uses APIM to turn model identity and token consumption into a per-model chargeback signal for Microsoft Foundry workloads.

That is useful validation, but the more interesting update is in the product itself: Microsoft Foundry can now create or associate an APIM-based AI Gateway directly from its Admin console. The data path is still APIM. What changed is who can configure and govern it.

This post explains what that means for an App Service-hosted agent, what Foundry now manages, what still belongs in APIM, and what I would change in the sample we built earlier.

Update (August 2026): Azure API Management now offers a dedicated AI Gateway tier in public preview. This article describes Foundry’s integration with APIM-based gateways. The new tier adds an AI-focused portal and resource experience for models and MCP tools and is expected to integrate with Foundry separately. See the announcement.

The short version: same gateway, new control plane

The architecture is still familiar:

Client -> App Service agent -> APIM AI Gateway -> Foundry model

APIM remains the traffic gateway. It authenticates callers, applies policies, forwards requests, and emits telemetry. App Service remains the application runtime for the agent and its APIs.

The new piece is the Foundry control plane. From Operate > Admin console > AI Gateway, a platform team can now:

• Create a new APIM instance or associate a supported existing instance.
• Enable the gateway for individual Foundry projects.
• Apply independent token limits to projects sharing the gateway.
• Verify gateway traffic and inspect logs.

Once the gateway is enabled, separate Foundry experiences can also register custom agents and govern supported MCP tools. Those actions do not happen in the AI Gateway tab itself, but the gateway provides their governed traffic path.

That is a meaningful shift. In the original sample, the infrastructure owner created APIM, imported the model API, deployed policy XML, and wired the agent to the gateway. Foundry does not remove APIM or replace those advanced capabilities. It gives Foundry administrators a first-party path into the same architecture.

What Foundry now owns

Project onboarding

An AI Gateway is associated with a Foundry resource, then enabled for projects inside it. New projects can inherit the gateway automatically. Existing projects must be added explicitly.

This creates a useful governance boundary: multiple teams can share the same APIM instance without sharing one undifferentiated token pool. Each project can receive its own token ceiling. If a project exceeds its configured limit, the gateway returns 429 Too Many Requests while other projects continue using their allocations.

Foundry-level limits

Our earlier sample used an APIM token-limit policy keyed by an APIM subscription. That is still a valid pattern, especially when the consumer boundary is an application, business unit, or external customer.

The Foundry integration adds another natural counter key: the Foundry project. For organizations already organizing models and agents by project, limits can now follow that structure instead of being recreated independently in every client application.

Inventory for agents and tools

The AI Gateway experience is expanding beyond model endpoints in two distinct ways. Foundry can register custom agents running outside Foundry, including agents that use A2A as their communication protocol. Separately, AI Gateway can govern supported MCP tools. The current tools-governance preview is scoped to MCP; it does not cover every Foundry or OpenAPI tool type.

That matters for App Service because the runtime does not need to move. An agent can continue running on App Service while participating in Foundry's inventory, and its supported MCP traffic can flow through the gateway.

These experiences are still preview features, so I would treat them as a control-plane integration to evaluate, not a reason to redesign a working production agent.

What still belongs in APIM

Foundry makes the common path easier. It does not make the full APIM surface unnecessary.

I would still use APIM directly for:

• Custom policy expressions and organization-specific headers or claims.
• Semantic caching backed by Azure Managed Redis.
• Backend pools, priority routing, and circuit breakers.
• Private networking, multi-region gateways, and advanced topology decisions.
• Custom metrics and dimensions needed for internal chargeback.

The clean mental model is: Foundry manages the AI assets and common project guardrails; APIM manages the traffic contract and advanced gateway behavior.

Applying this to the App Service sample

The existing framework-agnostic AI Gateway sample hosts a Microsoft Agent Framework agent and an MCP server on one Linux App Service. The agent reaches its model through APIM, which applies token limits, semantic caching, token metrics, and managed-identity authentication.

Most of that architecture should stay exactly as it is.

1. Keep the App Service application unchanged

The agent should continue calling a stable gateway endpoint. It should not need to understand whether APIM was provisioned by Bicep, associated in Foundry, or managed by a central platform team. That separation was the reason to introduce the gateway in the first place.

2. Choose the APIM ownership model deliberately

Update (August 2026): Foundry can now associate eligible API Management instances on classic (v1) SKUs as AI Gateways, in addition to v2 instances. If you already operate a classic-tier gateway, check Use existing APIM before planning a migration. Association does not change that tier’s SLA, scaling, networking, or feature limitations.

For a new proof of concept, Foundry can create a Basic v2 APIM instance. For production, Microsoft recommends evaluating Standard v2 or Premium v2 based on throughput and networking requirements.

For an existing enterprise gateway, use the Foundry option to associate an APIM instance only after confirming that it meets the eligibility requirements: it must be in the same Microsoft Entra tenant and Azure subscription as the Foundry resource, you need the API Management Service Contributor role (or Owner), and the instance must use a currently supported APIM tier.

3. Add existing projects explicitly

Creating or associating the gateway at the Foundry resource level does not automatically enable every existing project. Add each existing project to the gateway, then verify its status is Enabled.

4. Decide where each limit belongs

Avoid layering limits without a clear ownership model. A Foundry project limit, an APIM subscription limit, and a model deployment TPM limit answer different questions:

Use all three when the boundaries are intentional. Otherwise, operators end up debugging a 429 without knowing which layer produced it.

5. Verify the data path

After enabling a project, make a model request and confirm that the APIM request metric increments. Microsoft also recommends checking the GatewayLogs table for a successful response and an API name matching the AI Gateway.

Then test the failure path. Set a deliberately small project limit, exceed it, and confirm that the gateway returns 429. A governance feature is not finished until the team has observed both the allowed and denied behavior.

Which path should you choose?

The architecture was right; the experience caught up

The most important takeaway is not that everyone should rebuild an AI Gateway in a new portal. It is that the composable architecture now has a more accessible control plane.

App Service still runs the agent. APIM still governs the traffic. Foundry now gives model and platform owners a direct way to connect projects, allocate capacity, and bring agents and tools into the same governance view.

If you already built the earlier sample, the application boundary does not need to change. Evaluate the Foundry integration, decide whether its project model matches your organization, and check the APIM tier before planning any migration. The gateway remains the contribution; Foundry now makes it easier to operate.

Resources

• You can build a framework-agnostic AI Gateway on Azure App Service
• From AI Adoption to AI Governance
• Configure AI Gateway in your Foundry resources
• AI Gateway capabilities in Azure API Management
• App Service AI Gateway sample

Azure Functions Agents - the markdown-first runtime that turns a folder of *.agent.md files into a serverless Azure Functions app - now ships with OpenTelemetry tracing built into the runtime itself. Every agent run becomes a real, structured trace in Application Insights: the model used, the session, and every tool call or sub-agent hand-off along the way. None of it requires writing a line of telemetry code in your app.

Click here to create and run a Serverless Agent using Azure Functions

Full visibility, zero code

Bootstrapping an agent app is still two lines:

Turning on export is two settings, no code:

In requirements.txt - 

From there, every run shows up automatically in Application Insights' Agents view, tagged with a consistent set of attributes the runtime adds for you: which agent ran, which model answered, which tools it called, and how the run finished. You don't pick and choose what to instrument - you get the whole run, every time, the same way, regardless of what the agent is doing underneath.

That consistency is what makes the tracing useful for more than debugging. It's also the simplest way to see something that would otherwise happen invisibly inside a single API call.

Example: watching a model decision happen in real time

One good illustration is Model Router - a model you deploy yourself in your Foundry resource, like any other model deployment. Point an agent's model setting at that deployment, and Model Router picks a different underlying LLM per prompt: a smaller model for simple requests, a larger one once a prompt actually needs it.

Normally that choice is invisible - it happens inside one API call. But because Azure Functions Agents traces every run the same way no matter which model is behind it, the decision shows up for free. Same chat session, two prompts:

Both requests show gen_ai.request.model = model-router, that's the deployment the agent called. What changes per message is the response attribute, which names whichever model Router actually picked.

Trace for the easy prompt (response model gpt-5-mini)

Full session in the Agents pane of Application Insights

Nothing here was instrumented specifically for Model Router - this is just what a trace looks like now, for any agent, on any model.

Try it yourself

1. Add the two settings above to an existing agent app - no code changes needed.
2. Send a request or two, then open Application Insights' Agents view (or Transaction Search).
3. Look at what's already there: model, session, tool calls, and timing, all correlated under one trace.

Wrapping up

The point isn't any single scenario - it's that whatever you build next on Azure Functions Agents, from a simple single-model agent to something as dynamic as router-based model selection, you'll be able to see exactly what happened without adding anything yourself. Try it against your own agent and see what's already there.

Resources

• Azure Functions Agents runtime on GitHub
• Model router for Microsoft Foundry