How a .NET Engineer Actually Runs AI Inside Azure

The next step in learning AI with .NET is taking it beyond your laptop.

Let us take stock of where you are.

You already know software engineering. That was never the gap. The gap was AI, and you have been closing it one step at a time.

Step one: use AI. In Chapter 1, you installed Claude Code and let AI help you write .NET. Why it mattered: you learned the working loop of describing, reviewing, directing, and verifying, before touching anything complicated.

Step two: call AI. In Chapter 2, your own code called a model through an Application Programming Interface (API). Why it mattered: you saw that calling a model is an integration you already know how to build, with one new property, a non-deterministic response.

Step three: understand AI. In Chapter 3, you learned what models, tokens, context, caching, and temperature actually are. Why it mattered: you can now read an AI bill and predict an AI response.

Now step four.

Step four: run AI on Azure, the way real .NET software runs.

That is this chapter.

Why this is step four, and not step one

As a .NET engineer, you will hear "just start with Foundry" or "start with the Microsoft AI stack" before you have ever written a model call.

That is the wrong order.

Before Chapter 2, you had no call to move. Before Chapter 3, you could not judge what you were moving. The platform decisions would have been abstract, and you would have made them by following a product list.

Now they are concrete.

You have an endpoint that calls a model. You know what it costs and why. And the moment that endpoint has to be more than a demo, the questions change.

Where does the credential live?

Who is allowed to call the model?

How does the application prove who it is without a secret?

Where does the usage get billed?

Can access be locked down to only this application?

What happens if the key leaks?

None of these are really AI questions.

They are the same questions you answer for every dependency that goes into production.

And that is where Microsoft Foundry enters the picture.

There is one more reason for the order. Everything that comes next in this series, prompts and structured output, your own data, tool calling, agents, the Model Context Protocol (MCP), and production concerns, needs a model to call. A key in your user secrets is still exactly the right way to learn them. But when you take any of them beyond your laptop, you will want this step already behind you.

So we put the ground under your feet first.

Where Foundry fits in the Microsoft picture

As a .NET engineer, you have probably heard a growing list of Microsoft AI names:

• Microsoft Foundry
• GitHub Copilot
• Microsoft.Extensions.AI
• Microsoft Agent Framework
• Copilot Studio
• Microsoft 365 Copilot

It is easy to look at that list and wonder whether you are supposed to learn all of them before you can build an AI application.

You are not.

Here is the useful way to hold them, in the order you will actually meet them.

GitHub Copilot you have already met, in Chapter 1. It is an AI tool that helps you write software. It is not the model-calling layer of your application.

Microsoft Foundry is today. It is the Azure platform through which supported AI models can be discovered, deployed, and accessed.

Microsoft.Extensions.AI, and its IChatClient interface, comes later. It gives your code a common interface across AI providers.

Microsoft Agent Framework comes later still. It is for building agents, and it only makes sense once you have seen tool calling.

Copilot Studio and Microsoft 365 Copilot are end-user and low-code experiences. They are important Microsoft products, but they are not where a .NET engineer writes model calls, so they are a side branch of this path, not a step on it.

So for now, keep one thing in your head:

Foundry is the Azure layer around the model.

What Foundry actually is

Think about services you already understand.

Azure SQL gives you a managed database.

Azure Storage gives you managed storage.

App Service gives you a managed application platform.

Foundry gives you a managed Azure environment for working with AI models.

A quick note on the name, because it will save you some confusion. Older articles, videos, and tools call it Azure AI Foundry. It is the same platform, now called Microsoft Foundry. If you see either name, you are in the right place.

You pick a model from a catalog, deploy it, and call it. And it comes with the things you already expect from Azure: role-based access control (RBAC), monitoring, networking options, and cost visibility.

Foundry is not limited to Microsoft's own models. It hosts models from several providers, including Anthropic. Claude became generally available in Foundry in June 2026, so that is the model we will use as our example.

One thing to say clearly: almost nothing in this chapter is Claude-specific. Everything here applies to any model you deploy in Foundry.

Two words matter more than any others.

Resource. The Azure-managed container around your model access. It holds your security settings, your billing setup, and your network options, and it gives you the endpoint your application talks to.

Deployment. The particular model configuration your application targets, with a name that you choose.

The second one is the important one.

Your application does not have to say claude-sonnet-.... It can say summarizer. Behind that name, Foundry knows which model and version is running.

You have used this idea before. A connection-string name instead of a database implementation. A configuration key instead of a hard-coded endpoint. An App Service slot instead of a fixed instance.

The principle is familiar:

Your application depends on a stable name. Infrastructure decides what that name currently points to.

A small piece of advice that will save you later: name the deployment after its job, not its model. Call it summarizer, not claude-sonnet-..., because the job is stable and the model is not. And choose carefully, because the name cannot be changed after the deployment is created.

Where to find everything, so you do not get lost

Before the exercises, here is a short map of the places you will actually open. Keep it handy.

The Foundry portal is at ai.azure.com. This is where you create a Foundry resource, browse the model catalog, and deploy a model. The portal has a "New Foundry" toggle. If your screen looks different from the one in a tutorial, check that toggle first, because the classic layout arranges things differently.

The Claude model catalog is at ai.azure.com/catalog/publishers/anthropic. It lists the Claude models you can deploy.

The Azure portal is at portal.azure.com. This is where you manage the resource itself, including who has access to it.

The endpoint is the address your application calls. For Claude in Foundry, it has this shape, with your own resource name in the middle:

https://{your-resource}.services.ai.azure.com/anthropic/

You do not have to build it by hand. After you deploy a model, the deployment's details page shows it, labelled Target URI (Uniform Resource Identifier, which is simply the address), next to a key.

The documentation is worth bookmarking. Microsoft's guide is Deploy and use Claude models in Microsoft Foundry. Anthropic's guide is Claude in Microsoft Foundry. And for cost, use the Foundry section of Anthropic's pricing page.

One honest note. Portals and page names change often. If a screen does not match what you read here, trust the current documentation over any tutorial, including this one.

What actually changes for you

Here is the question you have probably been holding since the start of this chapter. If I move my call into Foundry, how much of my code changes?

Very little.

Three things.

The client. Anthropic ships its Foundry support as a separate NuGet package next to the one you used in Chapter 2. It is still marked as a preview package in Microsoft's documentation at the time of writing, so check the current status before you build on it.

The credential. Instead of an API key, the client is given an Azure identity and the name of your Foundry resource.

The model value. Where Chapter 2 hard-coded a model, you now pass the deployment name, ideally read from configuration.

Everything else stays where it was.

The system prompt. The messages. The token limit. The response handling. The interface. The endpoint.

Anthropic's Foundry documentation confirms that Claude deployments use the same Messages API, with the deployment name supplied as the model value.

So the call did not change.

Everything around the call did.

And remember ITextInsightService, the interface we put in front of the Claude client in Chapter 2? This is where that small decision pays for itself. The Foundry change lives at the edge of your application. Your endpoints and your tests never notice.

From a secret to an identity

This is the change that matters most.

Foundry supports two ways to authenticate: an API key, or a token from Microsoft Entra ID. Microsoft Entra ID is the service formerly called Azure Active Directory.

An API key is fine for a quick first test. But if you use one, you have moved the model behind Azure and you are still carrying a secret. A secret can be committed to a repository by mistake, pasted into a chat, or left in a forgotten configuration file. Every developer has heard that story.

With Microsoft Entra ID, your application does not prove itself with a secret string. It proves itself with an Azure identity, and Azure already knows who that is.

You stop saying:

"Here is a secret that proves I can use Claude."

You start saying:

"Here is my Azure identity. Azure already knows who I am."

.NET application
       │
       │ Azure identity
       ▼
Microsoft Entra ID
       │
       │ access token
       ▼
Microsoft Foundry
       │
       │ deployment
       ▼
     Claude

No Anthropic API key needs to sit in your application configuration.

The access decision becomes an Azure RBAC decision, the same kind you make for every other Azure service. On your machine, the identity is you. In Azure, it should normally be the application's managed identity.

And access becomes a role you grant and revoke. There is no long-lived key to rotate, and no long-lived key to leak.

This is not an AI concept.

It is an Azure identity concept.

Which is exactly why it should feel familiar.

Two more things that move inside Azure

Billing. Claude usage through Foundry is billed through the Azure Marketplace and appears on your Azure invoice. There is no separate vendor invoice to manage. I am deliberately not quoting prices, because they change, so check the current pricing before you start experimenting.

Network and monitoring. The resource can be placed on a private network, and its usage, latency, and errors can sit next to everything else you already watch in Azure.

That is the whole point of this step. AI stops being a separate island with its own credential, its own invoice, and its own blind spots. It becomes another dependency on the platform you already know how to run.

The model becomes a configuration decision

Suppose your deployment is named summarizer.

Later, you decide the task is simple enough for a smaller model. You create a second deployment, called summarizer-fast, and change one configuration value.

The application code does not change.

The interface does not change.

The caller does not change.

That is the benefit of the deployment boundary.

But there is an important distinction.

No code change does not mean no engineering change.

Changing the model can change response quality, response length, latency, supported parameters, token consumption, cost, and how closely the model follows your formatting instructions. You already saw one example in Chapter 2, when Claude Sonnet 5 stopped accepting temperature, top_p, and top_k.

So treat a deployment change like any other important runtime dependency.

Test it.

Measure it.

Then promote it.

And be honest about the limit. Changing from one Claude deployment to another can be a configuration change. Changing to another vendor's model may change the request shape entirely, because providers expose different APIs and capabilities. That is what your own interface is for, and it is why Foundry does not replace good architecture in your own code. You need both.

What Foundry does not do for you

There is no free abstraction.

Foundry does not automatically give you every capability of every vendor's direct API.

Claude in Foundry comes in two hosting options, Hosted on Azure and Hosted on Anthropic. With Hosted on Azure, your prompts and completions stay within Azure. With Hosted on Anthropic, the model runs on Anthropic's own infrastructure, even though Microsoft still provides the Foundry experience and the billing.

The two options also support different features. For example, some capabilities available in the direct API are not available on Azure-hosted deployments, and those lists keep changing.

So do not begin with:

"Foundry supports Claude, therefore every Claude feature is available."

Begin with:

"Which model, hosting option, and capability does my application actually need?"

That is the better engineering question.

One more boundary, so expectations are clear. Foundry gives you the platform controls around a model. It does not, by itself, answer the wider questions of responsible AI, safety, and governing AI use at scale. Those run much deeper than this chapter, and they deserve their own space later in the series.

Try it yourself

This chapter has no code to write. The best way to make it real is to do it once, yourself, in the portal. Each exercise takes about fifteen minutes.

You will need an Azure subscription with a valid payment method, because Claude in Foundry is billed through the Azure Marketplace. Your billing account also needs to be in a country or region where Anthropic offers the models for purchase, so check availability before you start. If you cannot do the exercises, the chapter still works as a read. The idea matters more than the clicks. Claude is billed by usage, so a few test calls cost very little, but check the current pricing first, and delete anything you no longer need when you finish.

1. Create your first deployment

Sign in to the Foundry portal at ai.azure.com, create a Foundry resource, open the model catalog, and deploy a Claude model.

Give the deployment a name that describes a job, such as summarizer, not the model. Remember that you cannot change it later.

When it finishes, open the deployment's details and look at three things: the endpoint your application would call (the Target URI), the hosting option, and the deployment type.

Write down what each one tells you. You have just done what Step 1 of every Foundry project looks like.

2. Find where identity lives

Open your resource in the Azure portal at portal.azure.com, go to its access control page, and look at the role assignments.

Find your own role. Find the role that lets an identity call the model, currently named Foundry User, previously Azure AI User. Then think through the question this chapter opened with: if a key leaked, what would you do? And if this were a role instead, what would you do?

You do not have to change anything. Understanding the difference is the exercise.

3. See the seam

Deploy a second, smaller model and name it summarizer-fast.

Now compare the two deployments side by side: the model version, the hosting option, the endpoint. Notice what would have to change in an application that calls them.

The answer is one name.

Then write down what you would want to re-test before switching a real application from one to the other. That list is your first model-change checklist.

Where this leaves you

Step back for a moment.

You have now done four things, in order.

• Chapter 1: You used AI to generate .NET code.
• Chapter 2: You called a large language model from your own .NET application.
• Chapter 3: You understood the key concepts behind every model call: tokens, context, caching, and temperature.
• Chapter 4: You saw how to call that same model through .NET and the Microsoft ecosystem, using Microsoft Foundry and your Azure identity.

Each step built on the one before it, and none of them asked you to give up what you already know as a .NET engineer.

You did not replace your .NET architecture. You did not learn a completely new programming model. You applied things you already know, identity, configuration, dependency boundaries, deployment, and cost, to a new kind of dependency.

That is the pattern for this whole series.

AI engineering does not begin by throwing away what you know about software engineering. It begins by applying that knowledge, step by step, in the right order.

If you remember only a few things from this chapter, remember these:

• This is step four because you needed a call to move and an understanding of what you were moving, before the platform decisions made sense.
• Microsoft Foundry is the Azure layer around the model, and almost everything in it applies to any model you deploy.
• A resource is the Azure boundary around your model access. A deployment is a stable name that decides which model answers.
• The biggest change is from a secret to an identity, with Microsoft Entra ID and managed identity.
• Your code changes very little, but changing the model still deserves testing, and changing vendors can still change your code.
• Hosting options and features differ, so check what your application actually needs before you design around it.

The interesting part was never the API call.

It was everything around it.

Now you have somewhere safe to build the rest.

That's Chapter 4 of AI for .NET Engineers done.

If you want future chapters the moment they're out, subscribe to the series.

Subscribe here