Should you build your company’s generative AI platform on Azure? After twenty-nine parts pulling this stack apart, here is the short answer. Yes, if Microsoft already runs your identity, your data estate, and your developers. No, if it does not, because most of what makes Azure worth choosing is the gravity of the rest of Microsoft, not the models themselves. This final part pays back that one sentence, names where Azure loses, and tells you what the bill really looks like before you commit.

Where Azure earns its place

The strongest thing about Azure is not any single model. It is that one control plane, Microsoft Foundry (the platform formerly branded Azure AI Foundry), sits over the whole stack, and that plane speaks the same identity language as the rest of your Microsoft tenancy. When a request hits an Azure OpenAI deployment, the caller is a Microsoft Entra identity (Entra is Microsoft’s cloud directory, the service that used to be called Azure Active Directory), the same identity that governs your mailboxes and your SharePoint. That means a data scientist and a finance app authenticate the same way, role assignments carry over, and your security team audits one directory instead of three. On a multi-cloud team I have watched this single fact save weeks, because nobody had to invent a second identity model just for AI.

Model breadth is the second real strength, and it grew a lot by 2026. The catalog now carries OpenAI frontier models including gpt-5.5 with a one million token context window, smaller and cheaper variants like gpt-5.4-mini and gpt-5.4-nano, a coding-tuned gpt-5.3-codex, low-latency speech through gpt-realtime-1.5, and native image generation with gpt-image-2. Alongside those sit DeepSeek, xAI’s Grok, Meta’s Llama, Mistral, and FLUX image models from Black Forest Labs, offered as fully hosted Models-as-a-Service so you pay per token and never manage a GPU. You are not locked to one lab. You can route cheap traffic to a mini model and hard traffic to a frontier one, inside the same project, behind the same key.

Third is the agent story, which finally stopped being a preview. Foundry Agent Service, the managed runtime for building and hosting agents that call tools and other agents, reached general availability in 2026, with hosted agents running in per-session VM-isolated sandboxes, the same hypervisor boundary that separates tenant virtual machines in Azure’s data centers. Microsoft backs it with a 99.9 percent uptime SLA and ties it into Azure Policy and Microsoft Purview for data governance. If you read Part 13 when agents were still rough, the difference now is that the boring enterprise commitments exist. That is what turns a demo into something a bank will run.

How Azure compares to AWS and Google Cloud

Every hyperscaler now sells the same rough shape: a managed model catalog, a serverless per-token tier, a provisioned-throughput tier for steady traffic, a managed agent runtime, a retrieval service, and safety filters. The differences are in emphasis and in the parts you cannot see on a feature grid. Azure leads on identity and on access to OpenAI’s frontier line. AWS Bedrock leads on model neutrality and on rentable custom chips, since Trainium3, its first 3nm training chip, went generally available at re:Invent and you can actually put workloads on it today. Google Cloud leads on silicon maturity, with TPUs in their seventh generation and a decade of tuning behind them, and on Gemini’s long-context and multimodal work.

First-party and third-party model names shift often; confirm current availability in each provider’s catalog before you design around a specific model.

The honest read is that no hyperscaler is clearly ahead on models anymore, because the good models show up on more than one cloud. What separates them is the surrounding estate. If your engineers already carry Entra badges and your compliance team already runs Purview, Azure removes a whole category of integration work. If you are neutral, you will weigh Bedrock’s rentable Trainium against Google’s TPU maturity, and Azure’s identity advantage means less to you. For the vendor-neutral view of these same trade-offs across every provider, the pillar in the Generative AI guide maps them without a house bias, and the AWS verdict gives the mirror of this argument from the Amazon side.

Stack layers, from identity up to the model

One diagram captures how these pieces stack, and the order matters because each layer leans on the one beneath it. Identity sits at the base: every call is a Microsoft Entra principal. Governance wraps that, with Azure Policy and Microsoft Purview watching what data moves and who touched it. Microsoft Foundry is the control plane where you create projects, deployments, and connections. Above it sit the models, Azure OpenAI plus the wider Models-as-a-Service catalog. Foundry Agent Service turns those models into tool-calling agents with managed hosting, and your application rides on top. Read it bottom up, because a gap low in the stack, a missing role assignment or an ungoverned data source, breaks everything above it, while a model swap near the top is cheap. Design from identity upward, not from the model down.

Three weaknesses worth naming before you commit

A verdict that only lists strengths is a brochure. Here are the three things that will actually bite you, in the order I have seen them cause pain. First, silicon you cannot rent. Microsoft’s Maia accelerator is real, and the Maia 200 generation is quoted at around ten petaflops of FP4 compute with 216 gigabytes of HBM3E memory under 900 watts, numbers that on paper aim past Google’s TPU v7 and AWS Trainium3. The catch is that Maia has no instance type, no API, and no migration path for you. It runs Microsoft’s own workloads. When you rent GPU on Azure for training, you are renting NVIDIA, and you pay NVIDIA-class prices. AWS and Google both let you put your own jobs on their custom chips today.

Second, quota and region friction. Frontier models do not land in every region at once, and provisioned capacity is something you request and wait for, not something you toggle on. I have had a launch slip because the model we validated in one region was not yet approved in the region the customer’s data residency required. Plan model-to-region mapping early, and treat quota as a lead-time item, the way you would treat a hardware order. This is covered in depth in Part 8, and it is the single operational surprise that catches new teams most often.

Third, product churn. Microsoft renames and reshapes fast. Azure AI Studio became Azure AI Foundry became, in places, just Microsoft Foundry. Prompt Flow, which many early teams built their evaluation pipelines on, is on a retirement path, and greenfield work should start on the Foundry SDK instead. None of this is fatal, but it means documentation drifts, and a tutorial from eighteen months ago may reference a portal that no longer exists. Budget time for the naming to move under you.

What does an Azure GenAI bill actually look like?

Cost is where verdicts get real. Azure gives you two main ways to pay for a chat model: pay-as-you-go per token, and provisioned throughput units, or PTUs, where you reserve a block of dedicated capacity for a flat monthly fee and get predictable latency in return. The whole decision is a break-even. Below a certain volume, per-token billing is cheaper and you should not reserve anything. Above it, a PTU block wins on both price and latency. The trap is buying PTUs too early, on a hunch about future traffic, and paying for idle capacity for months.

You can compute your own crossover in a few lines. Plug in the rate your account actually pays, not the list price, because negotiated discounts move the break-even a lot.

# azure_ptu_breakeven.py
payg_per_million = 12.0   # blended USD per 1M tokens
ptu_month = 2448.0        # one PTU block, USD/month

def cheaper(tokens_m):
    payg = payg_per_million * tokens_m
    pick = 'PTU' if ptu_month < payg else 'PAYG'
    return payg, ptu_month, pick

for m in (100, 204, 300):
    payg, ptu, pick = cheaper(m)
    print(f'{m}M/mo -> PAYG ${payg:,.0f}, PTU ${ptu:,.0f}, cheaper: {pick}')

print(f'break-even at {ptu_month / payg_per_million:.0f}M tokens/month')

Expected output: 100M/mo -> PAYG $1,200, PTU $2,448, cheaper: PAYG // 204M/mo -> PAYG $2,448, PTU $2,448, cheaper: PAYG // 300M/mo -> PAYG $3,600, PTU $2,448, cheaper: PTU // break-even at 204M tokens/month.

Failure mode: PTUs sell in minimum increments, so you cannot buy a fractional block, and a frontier model often needs more than one block to serve at all. If you feed list prices instead of your negotiated rate, or ignore the block minimum, the real crossover sits higher than the script says.

Who should build on Azure, and who should not

Build on Azure if Microsoft is your center of gravity. If your workforce signs in with Entra, your documents live in SharePoint and OneDrive, your compliance runs through Purview, and your developers already ship to Azure, then Foundry is the shortest route to a governed generative AI platform, and the identity integration alone is worth the price. Build on Azure if you specifically want OpenAI’s frontier models under an enterprise agreement with data residency and a private network path, which is a combination Azure sells better than anyone. Build on Azure if regulated governance is a hard requirement, because Purview and Azure Policy reach into the AI stack in a way the others match only in pieces.

Think twice if you are cloud-neutral and optimizing purely for model cost, because the good models are on every cloud and Azure’s identity advantage means little to you. Think twice if your plan depends on training large models on custom silicon you rent, because that is Trainium and TPU territory today, not Maia. Think twice if you cannot tolerate frequent renaming and portal churn, because Azure moves fast and your runbooks will need edits. And if you are a two-person startup that just wants the cheapest capable API this week, a single-model provider or a neutral gateway will get you there with less ceremony. None of these are Azure being bad. They are Azure being aimed at the enterprise, and you knowing whether that aim includes you.

Build on Azure when Microsoft is already your center of gravity

If I had to compress thirty parts into one instruction, it would be this. Let your existing estate pick your cloud, then let the model catalog and the break-even math pick your deployment. Azure’s real product is not gpt-5.5. It is the fact that one identity, one governance plane, and one billing account already cover your whole company, and the AI slots into that instead of standing beside it. When that is your situation, Azure is the calm choice, and you will spend your energy on the application rather than on plumbing. When it is not, be honest that you are paying an enterprise tax for benefits you will not use, and look hard at AWS and Google Cloud first.

That closes the series. Thirty parts, from the shape of the stack to this verdict. Go back to the guide, pick the one part that matches whatever you are building this quarter, and ship something. That is the only real test of any of this.

References

• Microsoft Learn, Foundry Models sold by Azure
• Microsoft Azure, Foundry Models pricing
• Microsoft Foundry blog, Agent Service general availability

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts