Skip to content

Design Checklist

Use this checklist when designing an AI workload landing zone, before approving a deployment, and when reviewing a significant change. For each applicable row, record your decision, owner and verification evidence. These are design recommendations, not a list of features automatically enabled by a template. Check the selected implementation and deployment parameters before assuming a control is present.

Compute and cost

ID Design consideration Recommended decision or check References
C-R1 Where will models, agents and application components run? Choose compute for each component's scaling, network and operational needs. Standardize where useful, but do not assume model hosting and application hosting have identical requirements. Compute decision guide
CO-R1 What is the workload's monthly cost and usage model? Estimate the selected resources, model tokens, indexing and observability before deployment. Include optional services and separate shared-platform costs. Cost guide, Foundry cost planning
CO-R2 Is model traffic predictable enough for provisioned throughput? Compare measured utilization and commitment costs with pay-as-you-go. If using spillover, explicitly design gateway routing and test quota exhaustion. Provisioned capacity is not automatically cheaper. Provisioned throughput, Multi-backend gateway
CO-R3 Which model deployment type meets residency, latency and cost requirements? Compare regional, data-zone and global options for the chosen model. Verify processing-location requirements before choosing a lower advertised token price. Deployment types
CO-R4 Which nonproduction resources can stop outside working hours? Schedule shutdown only for supported resources that can tolerate downtime. Check disks, networking and other charges that continue while compute is stopped. VM auto-shutdown

Data

ID Design consideration Recommended decision or check References
D-R1 Where are agent state, uploaded files and application data stored? Identify the selected Agent Service setup and its backing resources. Record retention, access, backup and deletion requirements separately for each data store. Standard agent setup
D-R2 Which resources may be shared across projects? Review supported resource-sharing constraints and choose explicit isolation boundaries. Separate application storage from Agent Service backing storage where required. Capability hosts and backing resources
D-R3 Does the workload need data from Microsoft Fabric? Evaluate the Fabric data agent's supported access model, permissions and regional availability before selecting it as an agent tool. Fabric data agent tool

Governance

ID Design consideration Recommended decision or check References
G-R1 Which policies apply to the deployed services? Assign relevant built-in or custom policies at the appropriate scope. Review audit results and exemptions before enforcing deny effects. AI services policies, Search policies
G-R2 Which regulatory and organizational obligations apply? Map risks and applicable controls to evidence. A policy initiative or checklist does not establish compliance by itself. NIST AI RMF, Regulatory compliance initiatives
G-R3 How will responsible AI risks be evaluated? Define evaluation datasets, human review, acceptance thresholds and escalation for the actual agent tasks. Do not assume a machine-learning dashboard supports every generative AI workflow. Generative AI evaluation
G-R4 What content safety controls are needed? Select supported filters and Content Safety APIs for the model and modalities in use. Test prompts, outputs and failure handling. Content filtering does not replace authorization. Content Safety overview
G-R5 Which models may teams deploy? Review the applicable model-deployment policies. Start in audit mode, assess impact, then enforce approved restrictions and remediate existing noncompliant deployments separately. Model deployment policies

Identity and access

ID Design consideration Recommended decision or check References
I-R1 How do services authenticate to one another? Prefer managed identity where supported, with narrowly scoped roles for each runtime principal. Keep deployment, project and runtime identities distinct. Managed identities
I-R2 How is privileged human access controlled? Require MFA and use just-in-time privileged access where available. Use a private administrative path when resources are isolated. MFA, Privileged Identity Management
I-R3 Can clients use Microsoft Entra ID rather than static keys? Use identity-based authentication where supported. Where a key is necessary, store it securely, limit distribution and define rotation and recovery. AI services authentication
I-R4 Which sign-in conditions should be enforced? Evaluate risk, device and location policies for human access. Test workload identities separately; interactive Conditional Access is not a replacement for service authorization. Conditional Access
I-R5 What can each user and service read or modify? Grant minimal control-plane and data-plane permissions at the smallest supported scope. Verify document allow/deny behavior, not just successful authentication. Foundry RBAC
I-R6 Can local key authentication be disabled? Confirm every dependent client supports Entra ID, then disable local authentication where supported. Plan a tested migration rather than breaking existing clients. Azure OpenAI managed identity authentication

Monitoring

ID Design consideration Recommended decision or check References
M-R1 What signals establish workload health? Define service-level objectives for availability, latency, task outcomes and data freshness. Monitor models, resources and data against those objectives. AI workload management
M-R2 Which failures require an alert? Enable applicable baseline alerts and route them to an owner. Tune thresholds and test delivery rather than enabling alerts without a response plan. Azure Monitor Baseline Alerts
M-R3 Can one failed request be traced across dependencies? Correlate application, model and retrieval calls. Protect prompts, documents and user data; content capture must be a deliberate privacy decision. Foundry tracing
M-R4 Which resource logs must be retained? Configure supported diagnostic categories and retention for key services. Confirm that logs reach the intended destination and restrict access to them. Diagnostic settings
M-R5 How will quality changes be detected? Re-evaluate representative tasks after model, prompt, tool and data changes. Investigate regressions before deciding whether to change data, prompts or models. Evaluation metrics
M-R6 Can private connectivity failures be diagnosed? Test DNS, routes, TLS and service authorization separately from the affected network. Use network diagnostics supported by the resource. Network Watcher

Reliability and resource organization

ID Design consideration Recommended decision or check References
R-R1 What are the recovery time and recovery point objectives? Plan backup, restore and regional recovery for each stateful dependency. Test recovery and application routing. A second region alone does not guarantee continuity. Azure OpenAI continuity, Storage disaster recovery, Cosmos DB backup
RO-R1 Are the required services and models available in the selected regions? Check current service, model, deployment-type and feature availability. Do not rely on a fixed region list copied into a design document. Products by region, Model availability
RO-R2 Is there enough quota for every resource to be created? Count all selected service instances, including separate Agent Service backing resources. Validate regional model capacity and request increases before deployment. Azure limits and quotas
RO-R3 How will growth affect subscription and regional limits? Record capacity headroom, ownership and the process for requesting quota. A passing preflight is not a guarantee of service capacity at deployment time. Quota overview
RO-R4 What are the account, project and billing boundaries? Align Foundry accounts and projects with access, network and operational boundaries. Verify supported isolation instead of assuming a project is a complete security boundary. Foundry architecture

Security

ID Design consideration Recommended decision or check References
S-R1 Which deployed AI risks can be monitored? Evaluate Defender for Cloud's supported AI posture and threat-protection features, coverage, prerequisites and cost for this workload. AI security posture
S-R2 Which service security controls are required? Map applicable Azure security baselines and Well-Architected guidance to the services actually deployed. Security baselines, Service guides
S-R3 How is sensitive data discovered and protected? Assess data classification, oversharing and insider-risk requirements. Evaluate Purview coverage and licensing without assuming it enforces retrieval permissions. Purview Insider Risk Management
S-R4 Which AI-specific attack paths need testing? Threat-model tools, model calls, retrieved content and data access. Use established AI risk frameworks to define tests and mitigations. MITRE ATLAS, OWASP generative AI risks
S-R5 How will prompt injection be handled? Evaluate Prompt Shields for supported inputs and test failures. Keep tool permissions and document authorization enforced independently of model output. Prompt Shields

Networking

ID Design consideration Recommended decision or check References
N-R1 Does public ingress need DDoS protection? Assess coverage for the actual public IP resources. Reuse platform protection where appropriate; VNet DDoS protection does not cover every PaaS endpoint. DDoS Protection overview
N-R2 How will operators reach private resources? Use an approved VPN, connected runner or jumpbox. Reuse central Bastion and administrative access when available rather than adding unnecessary public VM access. Azure Bastion
N-R3 Which services require private endpoints? Design private ingress and service-managed outbound links separately. Verify DNS and disable public access only after the intended path works. Foundry account/project networking is not interchangeable with hub-based managed networking. Foundry private networking
N-R4 Where should NSGs enforce traffic policy? Apply supported NSG rules to subnets or network interfaces, not to a VNet itself. Preserve service-specific subnet and platform connectivity requirements. Network security groups
N-R5 Is a regional or global web application firewall needed? Select Application Gateway or Front Door according to ingress requirements. Verify routing, authentication and backend access as well as WAF rules. Azure WAF
N-R6 Does the workload need an AI gateway? Evaluate API Management for routing, token controls and authentication. Confirm tier support and configure policies explicitly. Avoid logging raw prompts or responses by default. AI gateway capabilities
N-R7 Which outbound traffic must traverse a firewall? Reuse a platform firewall where appropriate. Verify routes, supported service paths and required destinations before enforcing egress restrictions. Azure Firewall
N-R8 How will private service names resolve from every client network? Plan zone links, conditional forwarding and connected-network resolution. Private DNS provides name resolution, not traffic routing or authorization. Private endpoint DNS integration
N-R9 What outbound destinations are allowed? Restrict egress to verified service and build dependencies where supported. Review exceptions and test recovery without opening unrestricted internet access as a troubleshooting shortcut. AI services data-loss prevention
© 2026 Azure AI Landing Zones