Why architecture comes first
Most AI projects fail not at the model layer but at the architecture layer. A pilot that worked beautifully on one team's data becomes unmanageable when three more teams want it, when finance asks who is paying for the tokens, and when security asks where the data went. These are architectural questions, and they are far cheaper to answer before the build than after it.
This unit gives you a vocabulary and a small set of repeatable patterns for deploying Microsoft AI workloads. The patterns are not Microsoft-specific inventions — they are the organisational shapes that AI deployments naturally take. Your job as an architect is to recognise which shape fits your situation, and to express it in the resources Azure AI Foundry gives you: hubs, projects, connections, and deployments.
By the end of this unit- Describe the hub-and-spoke, federated, and embedded AI deployment patterns and the trade-offs of each.
- Explain how the Azure AI Foundry hub and project resources map onto those patterns.
- Select an appropriate pattern for a given organisational scenario and justify the choice.
What an architecture pattern actually decides
- Who owns the security configuration, the network boundary, and the data connections
- Where responsible-AI policy and content filters are applied — centrally or per team
- How a new use case is reviewed and approved before it reaches production
- Whether consumption is pooled into shared capacity or attributed to each team
- How quota and rate limits are allocated and protected from noisy-neighbour effects
- Whether you can answer "what did this use case cost us last month" cleanly
- How quickly a new team can start building without re-solving foundational concerns
- Whether teams are blocked on a central platform group, or self-serve within guard-rails
- How much duplicated plumbing each new project has to build for itself
The three core patterns
Almost every Microsoft AI deployment resolves into one of three shapes, or a combination of them. Learn to recognise them and you can place most real-world situations quickly.
1. Hub-and-spoke (centralised platform)
A central platform team owns shared infrastructure — networking, security, model deployments, content safety policy — and exposes it to delivery teams who build their applications against it. In Azure AI Foundry this maps cleanly to one shared hub with multiple projects. Governance is consistent because it is applied once, centrally. The risk is that the central team becomes a bottleneck if it also has to approve every change.
Best when: the organisation values consistency and control, has a capable platform team, and is running many similar use cases.
2. Federated (autonomous teams within guard-rails)
Each business unit or product team owns its own hub and projects, deployed from a shared landing-zone template and policy baseline. Teams move at their own pace; central governance is expressed through Azure Policy, naming standards, and a reference architecture rather than through manual gatekeeping. The trade-off is some duplication and a harder job aggregating cost and posture across the estate.
Best when: business units differ materially in their needs, data residency, or compliance regime, and central approval would create unacceptable delay.
3. Embedded (AI inside an existing application)
The AI capability is a feature of a product that already exists — a search box that now answers in natural language, a support tool that now drafts replies. There is no standalone "AI platform"; an Azure OpenAI or Azure AI Foundry deployment is consumed directly by the application as one dependency among many. The architecture concern shrinks to a single integration: endpoint, key/identity, quota, and fallback behaviour.
Best when: AI is a feature of one product rather than a capability offered across the organisation.
These patterns are not mutually exclusive. A large organisation often runs a hub-and-spoke platform for general-purpose use cases while a flagship product team operates federated with its own hub, and several legacy applications consume AI in the embedded style. The skill is in mapping the estate, not forcing a single answer.
Azure AI Foundry hub and project model
Azure AI Foundry expresses these patterns through two resource types. Understanding the boundary between them is the single most useful piece of platform knowledge for a Microsoft AI architect.
Hub versus project
The hub holds shared, security-sensitive configuration
Projects are the working units that inherit from the hub
Connections decouple "what" from "where"
Mapping resources to patterns
Think about an AI use case in your own organisation. If you had to draw it in Foundry resources right now, how many hubs would you create, and how many projects under each? If you cannot answer cleanly, the underlying ownership and governance question is probably unresolved — and that is the thing to settle first.
Choosing a pattern
The decision is rarely about technology. It is about who needs to own what, how fast teams need to move, and how strict the consistency requirement is. Work through three questions in order.
1. Is AI a product feature or an organisational capability?
If it is a feature of one application, choose embedded and stop. You do not need a platform. If it is a capability you intend to offer to many teams, continue.
2. How different are the consuming teams?
If teams share a regulatory regime, data-residency requirement, and risk appetite, a single hub (hub-and-spoke) keeps governance simple. If they differ materially — separate compliance regimes, separate regions, genuinely independent risk decisions — a federated model with one hub per boundary avoids forcing the highest common denominator on everyone.
3. Where is the bottleneck risk?
Centralisation concentrates control but risks a delivery bottleneck. Federation removes the bottleneck but risks drift and duplicated effort. Whichever you choose, mitigate the named risk: for hub-and-spoke, separate platform operations from use-case approval so the platform team is not the gate on every change; for federated, invest in a shared landing zone and Azure Policy baseline so autonomy does not become anarchy.
Build on these patterns with the official Azure AI Foundry learning paths:
Get started with Azure AI Foundry ↗
Build AI apps and agents with Azure AI Foundry ↗
Responsible AI principles in practice ↗
End of Unit 1
You should now be able to:
- Name and contrast the hub-and-spoke, federated, and embedded deployment patterns.
- Map each pattern onto Azure AI Foundry hubs, projects, and connections.
- Choose a pattern for a scenario and name the risk you must mitigate as a result.
Unit review
In Azure AI Foundry, which resource carries the shared security configuration and connections that multiple use cases inherit?
A single platform team owns one hub, and five delivery teams each build in their own project under it. Which pattern is this?
Two business units have different data-residency obligations and genuinely independent risk decisions. Which pattern best respects that?
You choose the hub-and-spoke pattern. What is the principal risk you must actively mitigate?
End of module
You have completed Course 01: Microsoft AI Architecture Patterns. Next: Designing for Scale — the architecture decisions that carry an AI workload from pilot to production.