Foundry hub
A Foundry hub is a hub-style Microsoft Foundry resource used in selected scenarios to group AI projects with shared security, connections, data access, and governance settings. Teams use it to organize related AI projects that need common connections, managed identities, network controls, storage, security review, and platform governance across teams or application portfolios. It is not a whole Azure tenant, a model deployment by itself, a replacement for project-level permissions, or the required resource shape for every modern Foundry scenario.
Source: Microsoft Learn - Hubs and hub-based project overview Reviewed 2026-05-14
- Exam trap
- Treating Foundry hub as a label instead of checking the exact resource scope, live configuration, owner, and dependencies.
- Production check
- Verify resource scope, enabled state, identity, network path, diagnostics, owner tags, and linked resources before changing production behavior.
Article details and learning context
- Aliases
- Azure AI Foundry hub, Foundry hub resource, hub-based project, AI hub
- Difficulty
- intermediate
- CLI mappings
- 6
- Last verified
- 2026-05-14
Understand the concept
Why it matters
Foundry hub matters because it is the shared governance boundary for hub-based AI work, especially where multiple projects inherit platform connections and security posture. Without clear vocabulary, teams may confuse hubs with projects, grant broad shared access, attach sensitive connections to the wrong boundary, or keep classic hub resources without lifecycle ownership. It also affects security, reliability, operations, cost, and performance because one configuration choice can change who can act, what fails, how quickly work completes, what evidence exists, and how much the platform costs. Good glossary discipline helps teams ask who owns it, what depends on it, which metric proves health, and what rollback path exists before a release.
Official wording and source
A Foundry hub is a hub-style Microsoft Foundry resource used in selected scenarios to group AI projects with shared security, connections, data access, and governance settings.
Technical context
Technically, the Foundry hub is configured or observed through Foundry hub resources, hub-based projects, Azure AI Foundry classic portal, project connections, managed identities, storage accounts, Key Vault, container registry, network isolation, role assignments, and linked Azure Machine Learning assets. It depends on resource provider support, project model, identity assignments, shared connection policy, network isolation, storage and Key Vault configuration, role scope, regional availability, compliance requirements, and lifecycle migration plans. Operators inspect it through the Azure portal, ARM or Bicep, Azure CLI, SDK or REST calls, Azure Monitor, diagnostic logs, and application telemetry.
Exam context
Compare with
Where it is used
Where you see it
- An AI platform inventory shows a hub resource with multiple projects, shared connections, storage, Key Vault, managed identity, and private networking settings. Review scope, owners, metrics, and rollback evidence.
- Security reviews discuss inherited project access, shared connection scope, hub administrators, private endpoint configuration, or whether a hub-based model is still required. Review scope, owners, metrics, and rollback evidence.
- Cost reports show model, storage, networking, or evaluation spend grouped under a hub or dependent resources used by several AI projects. Review scope, owners, metrics, and rollback evidence.
Common situations
- Review hub-based AI project governance before adding shared connections, identities, network isolation, or dependent resources.
- Map a classic Foundry hub to projects, Key Vault, storage, role assignments, and private endpoints during a security review.
- Plan cleanup or migration when hub-based resources no longer match current Microsoft Foundry project patterns.
- Support incident response by correlating Azure configuration, diagnostic logs, metrics, deployment history, and application traces.
Illustrative Azure scenarios
These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.
Scenario 01 Foundry hub in action for financial services Scenario, objectives, solution, measured impact, and takeaway.
FinCore Advisory, a financial services organization, needed to solve a production challenge: three AI teams created separate connections to the same regulated data sources, creating inconsistent access reviews. The architecture team used Foundry hub to make the design measurable, governable, and easier to support.
- Centralize shared AI connections
- Reduce duplicate secrets
- Separate project permissions
- Keep audit evidence clear
Platform architects organized hub-based projects under a Foundry hub with shared Key Vault-backed connections, private endpoint access, and scoped project roles. Each project still had separate model deployment and evaluation evidence. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.
- Duplicate secret stores were retired
- Access reviews used one shared connection inventory
- Project teams kept separate workspaces
- Audit findings from inconsistent connections closed
A Foundry hub is useful when shared governance must be explicit instead of recreated by each project.
Scenario 02 Foundry hub in action for public sector Scenario, objectives, solution, measured impact, and takeaway.
CityLabs Innovation, a public sector organization, needed to solve a production challenge: an AI pilot portfolio needed a controlled place for experiments without giving every team subscription-wide permissions. The architecture team used Foundry hub to make the design measurable, governable, and easier to support.
- Provide governed project creation
- Limit shared resource administration
- Track pilot ownership
- Avoid public network exposure
The cloud team created a hub-style Foundry boundary with private networking, managed identities, and project-level roles. Pilot owners received project access while hub administration stayed with the platform team. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.
- Five pilots launched without subscription owner rights
- Private network controls were inherited
- Ownership tags improved chargeback
- Hub admin changes stayed in platform hands
Foundry hubs help separate platform administration from project experimentation.
Scenario 03 Foundry hub in action for life sciences Scenario, objectives, solution, measured impact, and takeaway.
BluePeak Pharma, a life sciences organization, needed to solve a production challenge: legacy hub-based AI assets needed review before a move to newer Foundry project patterns. The architecture team used Foundry hub to make the design measurable, governable, and easier to support.
- Inventory hub dependencies
- Protect active model workflows
- Identify unused projects
- Plan staged migration
Engineers mapped hub projects, shared connections, storage, model deployments, and role assignments. They removed unused projects, kept active workflows stable, and documented which workloads would migrate first. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.
- Unused project spend fell by 24 percent
- No active workflow was interrupted
- Migration order was approved by owners
- Connection risk was visible before redesign
Hub review turns AI platform modernization into controlled dependency management.
Azure CLI
Azure CLI helps validate Foundry hub because it captures reproducible evidence for scope, configuration, permissions, runtime state, diagnostics, and related resources before a production change.
Useful for
- List or show Azure resources and related configuration for Foundry hub.
- Capture read-only evidence before changing identity, networking, triggers, capacity, policy, deployment, or automation settings.
- Compare Azure metrics, logs, run history, deployment operations, and application evidence during production incidents.
Before you run a command
- Confirm the tenant, subscription, resource group, resource names, environment, and time window are the intended scope.
- Run read-only list, show, metrics, operation, or query commands before any create, update, delete, start, stop, policy, or deployment change.
- Get approval for mutating commands because configuration changes can expose data, break workflows, increase cost, or alter compliance evidence.
What the output tells you
- Resource IDs, enabled state, configuration values, identity settings, network posture, and ownership metadata show the current design.
- Metrics, logs, run history, or deployment operations show whether the platform behaved as expected during the reviewed time window.
- Application and downstream evidence shows whether the issue is Azure configuration, permissions, client behavior, data readiness, or business processing.
Mapped commands
Some evidence is visible only in service logs, SDK behavior, deployment output, SQL metadata, portal configuration, or application telemetry; Azure CLI still validates surrounding resources and operational scope.
Architecture context
A Foundry hub is a shared project foundation used in hub-based Microsoft Foundry scenarios, especially where several AI projects need common security, connections, storage, networking, and governance. I treat it like a platform landing zone for AI teams rather than a folder for experiments. The architecture decision covers hub region, managed identity, project membership, Key Vault, storage, container registry, private networking, role assignments, and which teams can create project connections. Hub design becomes important when production agents, model deployments, evaluations, and data connections need consistent controls. I also separate experimentation from production hubs where possible, because a shared hub can quietly centralize blast radius if permissions or network paths are too broad.
- Security
- Security for the Foundry hub starts with knowing who can administer the hub, create projects, manage shared connections, assign identities, read secrets, configure network isolation, deploy models, and access data through inherited project permissions. Review hub resource ID, projects, shared connections, identities, storage, Key Vault, network mode, private endpoints, role assignments, owner, project lifecycle, and whether the scenario still requires hub-based design before approving production changes. Prefer managed identity and Microsoft Entra ID where the service supports it, keep secrets in approved vaults, scope roles narrowly, and protect diagnostics that may reveal sensitive names, payloads, or operational patterns. During audits, capture Activity Log entries, role assignments, network settings, diagnostic settings, and owner approvals so teams can prove access and behavior were intentional.
- Cost
- Cost for the Foundry hub is driven by dependent storage, Key Vault, networking, model deployments, compute, evaluations, duplicate hubs, unused projects, diagnostics, and administrative effort maintaining shared resources across teams. The expensive mistake is not only Azure consumption; it is also duplicate processing, failed retries, audit cleanup, manual investigations, and unnecessary capacity caused by weak design evidence. Review whether the workload truly needs the selected tier, frequency, retention, diagnostics, network path, and automation pattern. Use tags, budgets, alerts, and recurring reviews so teams can explain why the current design exists and remove stale resources safely. This keeps Foundry hub review specific across architecture, security, operations, and incident response.
- Reliability
- Reliability for the Foundry hub depends on healthy dependent storage, Key Vault, identity, network configuration, project creation flow, connection availability, regional support, quota, and documented procedures for project migration or hub-level configuration changes. A healthy Azure resource can still fail the business workflow if downstream services, identities, triggers, clients, or data contracts are wrong. Test retries, failover assumptions, disabled states, stale configuration, private DNS problems, timeout behavior, and duplicate processing before relying on the design. Keep runbooks for first-response checks, known limits, owner escalation, and rollback so support teams can recover without guessing. This keeps Foundry hub review specific across architecture, security, operations, and incident response.
- Performance
- Performance for the Foundry hub depends on model deployment placement, project connection latency, private network routing, shared storage access, key vault calls, quota, evaluation workload, and how many projects depend on hub-level services. Measure platform-side metrics and application-side completion metrics because fast service response does not always mean the business task finished. Use realistic data sizes, concurrency, filter patterns, region placement, authentication paths, and downstream limits in tests. When performance regresses, compare configuration changes, resource limits, client logs, diagnostic data, and workload timing before adding capacity or blaming one Azure service. This keeps Foundry hub review specific across architecture, security, operations, and incident response.
- Operations
- Operations for the Foundry hub require named owners, documented resource IDs, expected behavior, diagnostic settings, and first-response checks. Before a change, capture read-only CLI output, portal screenshots when useful, deployment history, and relevant application configuration. During incidents, avoid changing several settings at once. Compare service metrics, logs, run history, identity evidence, network state, and downstream health in the same time window. Keep release notes clear enough for support teams to verify current behavior quickly. This keeps Foundry hub review specific across architecture, security, operations, and incident response. This keeps Foundry hub review specific across architecture, security, operations, and incident response.
Common mistakes
- Treating Foundry hub as a label instead of checking the exact resource scope, live configuration, owner, and dependencies.
- Changing several settings at once without saving read-only evidence, rollback instructions, and the expected metric change.
- Assuming the Azure resource succeeded means the end-to-end business workflow completed correctly and safely.