pull base content,head:MicrosoftDocs:main,into:wwlpublishsync

Author: wwlpublish

learn-pr/advocates/intro-ai-landing-zones/1-introduction-landing-zones.yml

@@ -0,0 +1,13 @@
+### YamlMime:ModuleUnit
+uid: learn.introduction-ai-landing-zones.introduction-landing-zones
+title: Introduction to landing zones
+metadata:
+  title: Introduction to landing zones
+  description: Understand the purpose and elements of Azure landing zones.
+  ms.date: 05/01/2025
+  author: Orin-Thomas
+  ms.author: orthomas
+  ms.topic: unit
+durationInMinutes: 8
+content: |
+  [!include[](includes/1-introduction-landing-zones.md)]

learn-pr/advocates/intro-ai-landing-zones/2-azure-ai-landing-zones.yml

@@ -0,0 +1,13 @@
+### YamlMime:ModuleUnit
+uid: learn.introduction-ai-landing-zones.azure-ai-landing-zones
+title: Azure AI Landing Zones
+metadata:
+  title: Azure AI Landing Zones
+  description: Understand how AI applications can use Azure Landing Zones.
+  ms.date: 05/01/2025
+  author: Orin-Thomas
+  ms.author: orthomas
+  ms.topic: unit
+durationInMinutes: 10
+content: |
+  [!include[](includes/2-azure-ai-landing-zones.md)]

learn-pr/advocates/intro-ai-landing-zones/3-deploy-test-landing-zones.yml

@@ -0,0 +1,13 @@
+### YamlMime:ModuleUnit
+uid: learn.introduction-ai-landing-zones.deploy-test-landing-zones
+title: Deploy and Test Landing Zones
+metadata:
+  title: Deploy and Test Landing Zones
+  description: How to deploy and test landing zones using the Azure CLI and Bicep.
+  ms.date: 05/01/2025
+  author: Orin-Thomas
+  ms.author: orthomas
+  ms.topic: unit
+durationInMinutes: 4
+content: |
+  [!include[](includes/3-deploy-test-landing-zones.md)]

learn-pr/advocates/intro-ai-landing-zones/4-knowledge-check.yml

@@ -0,0 +1,47 @@
+### YamlMime:ModuleUnit
+uid: learn.introduction-ai-landing-zones.knowledge-check
+title: Knowledge Check
+metadata:
+  title: Knowledge Check
+  description: Check your understanding of the module content.
+  ms.date: 05/01/2025
+  author: Orin-Thomas
+  ms.author: orthomas
+  ms.topic: unit
+durationInMinutes: 3
+content: Choose the best response for each question. 
+quiz:
+  questions:
+    - content: "You are in the process of planning management boundaries for an AI application deployment. Which Azure landing zone design area aligns with this goal?"
+      choices:
+        - content: "Network topology and connectivity"
+          isCorrect: false
+          explanation: "This design area addresses appropriately planned network topology and connectivity. This ensures that deployed resources can communicate in a secure, reliable, and cost effective manner."
+        - content: "Resource organization"
+          isCorrect: true
+          explanation: "The resource organization design area determines the appropriate Azure management group and subscription hierarchy. Planning subscription hierarchy impacts governance, operations management, and adoption patterns. When considering this design area, you configure subscriptions as management boundaries that separate the platform and workload teams. This separation is also termed subscription democratization."
+        - content: "Platform automation and DevOps"
+          isCorrect: false
+          explanation: "This design element ensures that your organization uses the right alignment of tools and templates to deploy landing zones and supporting resources."
+    - content: "Which of the following is the responsibility of the workload team in an Azure AI application deployment using landing zones?"
+      choices:
+        - content: "Azure AI Foundry"
+          isCorrect: true
+          explanation: "Azure AI Foundry is the responsibility of the workload team. The workload team is responsible for the configuration, management, and deployment of the workload components, including all AI services that are used in this architecture."
+        - content: "Azure Firewall"
+          isCorrect: false
+          explanation: "Network infrastructure like Azure Firewall is the responsibility of the platform team."
+        - content: "Azure private DNS zones"
+          isCorrect: false
+          explanation: "Network infrastructure like Azure private DNS zones is the responsibility of the platform team."
+    - content: "Which of the following is the responsibility of the platform team in an Azure AI application deployment using landing zones?"
+      choices:
+        - content: "Azure Bastion"
+          isCorrect: true
+          explanation: "Azure Bastion is the responsibility of the platform team in an Azure AI application deployment using landing zones"
+        - content: "Azure Container Registry"
+          isCorrect: false
+          explanation: "Azure Container Registry is the responsibility of the workload team in an Azure AI application deployment using landing zones"
+        - content: "Azure App Service"
+          isCorrect: false
+          explanation: "Azure App Services is the responsibility of the workload team in an Azure AI application deployment using landing zones"

learn-pr/advocates/intro-ai-landing-zones/5-summary.yml

@@ -0,0 +1,13 @@
+### YamlMime:ModuleUnit
+uid: learn.introduction-ai-landing-zones.summary
+title: Summary
+metadata:
+  title: Summary
+  description: Summary of module content.
+  ms.date: 05/01/2025
+  author: Orin-Thomas
+  ms.author: orthomas
+  ms.topic: unit
+durationInMinutes: 3
+content: |
+  [!include[](includes/5-summary.md)]

learn-pr/advocates/intro-ai-landing-zones/includes/1-introduction-landing-zones.md

@@ -0,0 +1,37 @@
+An Azure landing zone is a preconfigured, scalable environment within Microsoft Azure that serves as the foundation for deploying cloud workloads. Landing zones implement best practices for governance, security, and infrastructure. Landing zones provide standardized subscription designs, identity and access management controls, policy configurations, network topology, and shared services. 
+
+Azure landing zones use subscriptions to isolate and scale application resources and platform resources. Azure landing zone architectures are scalable and modular. The repeatable infrastructure allows you to apply configurations and controls to every subscription consistently. You can deploy landing zones using the Azure portal, Bicep modules, or Terraform. 
+
+You should use landing zone conceptual architectures as a starting point and tailor the architecture to meet your needs for your organization's AI workloads.
+
+## Landing zone design areas
+
+An Azure landing zone is an environment that follows key design principles across eight design areas. Azure landing zone design areas describe what to consider before you deploy a landing zone. Design areas help you establish a process in exploring the subjects relevant to making critical decisions about your environment. You should evaluate each design area to help you understand any changes that you might need to make to the implementation options for Azure landing zones and the AI related workloads that those zones might host.
+
+Evaluating each design area sequentially provides you with a process that simplifies the design of any complex environment. Once you've already addressed each design area to your satisfaction, move on to the next area.
+
+These Azure landing zone design areas are as follows:
+
+- **Azure billing and Microsoft Entra tenant.** Ensures that the tenants in the landing zone are properly created, enrolled, and that billing is appropriately configured.
+- **Identity and access management.** Identity functions as the primary security boundary in the public cloud. This landing zone design area ensures that identity and access management is implemented to serve as the foundation for a secure and fully compliant architecture.
+- **Network topology and connectivity.** Appropriately planned network topology and connectivity ensure that deployed resources can communicate in a secure, reliable, and cost effective manner. 
+- **Resource organization.** Determines the appropriate Azure management group and subscription hierarchy. Planning subscription hierarchy impacts governance, operations management, and adoption patterns. Configure subscriptions as management boundaries that separate the platform and workload teams. This separation is also termed subscription democratization. 
+- **Security.** The security design area involves designing and implementing the appropriate controls and processes to secure all elements of the cloud environment. An example of this design area is ensuring use of managed identities rather than API keys for authentication and authorization.
+- **Management.** The management design area includes developing management baselines that provide appropriate and secure visibility into resources and also ensuring that operations practices meet compliance requirements.
+- **Governance.** This design area addresses ensuring that governance policies and auditing are enforced and automated. An example would be notifications and alerts being generated when an element of the deployment's configuration drifts out of compliance due to configuration changes.
+- **Platform automation and DevOps.** This design element ensures that your organization leverages the right alignment of tools and templates to deploy landing zones and supporting resources.
+
+![Diagram showing the eight different Azure landing zone design areas.](../media/landing-zone-decision-areas.png)
+
+As a general rule, be prepared to balance requirements and functionality. Your journey to the most effective architecture for your organization's AI workloads will evolve over time as requirements change and you learn from your implementation.
+
+All Azure landing zone architectures are designed with a separation of ownership between the platform team and the workload team. This subscription democratization allows application architects, data scientists, and DevOps teams to understand what's under their direct influence or control and what isn't.
+
+## Application and platform landing zones
+
+Subscription democratization leads to two categories of landing zone that are relevant to AI adoption: application landing zones and platform landing zones. The differences between them are as follows: 
+
+- An application landing zone is an Azure subscription in which a workload runs. An application landing zone is connected to the organization's shared platform resources. Through that connection, the landing zone has access to the infrastructure that supports the workload, such as networking, identity access management, policies, and monitoring. These landing zones and subscriptions are the responsibility of the workload team.
+- A platform landing zone is a subscription that provides shared services (identity, connectivity, management) to applications in application landing zones. A platform landing zone is a collection of various subscriptions that multiple platform teams can manage. Each subscription has a specific function. For example, a connectivity subscription provides centralized Domain Name System (DNS) resolution, cross-premises connectivity, and network virtual appliances (NVAs) that are available for platform teams to use. These landing zones and subscriptions are the responsibility of the platform team.
+
+Determine which infrastructure elements need to be present for the workloads in the application landing zones and deploy them in the platform landing zones. Ensure that the infrastructure present in the platform landing zones adheres to the principles laid out in the security, management, governance, network, and identity and access design areas. Once the infrastructure to support the workloads is in place, you can use the design principles, including those in the platform automation and DevOps design area, to deploy, update and maintain the application workloads.

learn-pr/advocates/intro-ai-landing-zones/includes/2-azure-ai-landing-zones.md

@@ -0,0 +1,66 @@
+The Azure OpenAI chat baseline application published in the Azure Architecture Center on the Microsoft website illustrates an example of how you can use Azure Landing Zones with AI workloads. 
+
+![Diagram of all elements of a complex AI application deployment.](../media/ai-landing-zone-network-diagram.png)
+
+In the AI chatbot landing zone implementation, the workload team is mostly responsible for the configuration, management, and deployment of the workload components, including all AI services that are used in this architecture.
+
+For this architecture, the workload team and platform team need to collaborate on a few topics: management group assignment (including the associated Azure Policy governance) and networking setup.
+
+## Workload team managed resources
+
+In the AI chatbot landing zone implementation, the workload team is responsible for the following resources:
+
+- **Azure AI Foundry.** The platform used to build, test, and deploy AI solutions. AI Foundry is used in this architecture to build, test, and deploy the prompt flow orchestration logic for the chat application. In this architecture, Azure AI Foundry provides the managed virtual network for network security.
+- **Managed online endpoints.** These are used as a platform as a service (PaaS) endpoint for the chat UI application, which invokes the prompt flows hosted by Azure AI Foundry.
+- **Azure App Service**. Used to host the web application for the chat UI. In this architecture, App Service has three instances, each in a different Azure zone.
+- **AI Search**. Service that's used in the flows behind chat applications. You can use AI Search to retrieve indexed data that's relevant for user queries.
+- **Azure Storage.** Used to persist the prompt flow source files for prompt flow development.
+- **Azure Container Registry.** Used to store flows that are packaged as container images.
+- **Azure Application Gateway.** Used as the reverse proxy to route user requests to the chat UI that's hosted in App Service. In this architecture, Azure Application Gateway is also used to host an Azure web application firewall to protect the front-end application from potentially malicious traffic.
+- **Key Vault.** Used to store application secrets and certificates.
+- **Azure Monitor, Azure Monitor Logs, and Application Insights.** Used to collect, store, and visualize observability data.
+- **Azure Policy.** Used to apply policies that are specific to the workload to help govern, secure, and apply controls at scale.
+
+![Diagram of the part of the AI workload that is the responsibility of the workload team.](../media/workload-resources.png)
+
+In this architecture the workload team is also responsible for maintaining the following resources:
+
+- Spoke virtual network subnets and the network security groups (NSGs) that are placed on those subnets to maintain segmentation and control traffic flow.
+- Private endpoints to secure connectivity to PaaS solutions.
+
+## Platform team managed resources
+
+In this architecture the platform team owns and maintains the following centralized resources which should be pre-provisioned before the deployment of the resources managed by the workload team:
+
+- **Azure Firewall.** Deployed in the hub network is used to route, inspect, and restrict egress traffic. Workload egress traffic goes to the internet, cross-premises destinations, or to other application landing zones.
+- **Azure Bastion.** Deployed in the hub network and provides secure operational access to workload components and also allows secure access to Azure AI Foundry components.
+- **Spoke virtual network.** This network hosts the AI application.
+- **User-defined routes (UDRs).** Used to force tunnel network traffic to the hub network.
+- **Azure Policy-based governance constraints and DeployIfNotExists (DINE) policies.** You can apply these policies at the platform team-owned management group level or apply them to the workload's subscription directly.
+- **Azure private DNS zones.** Host the A records for private endpoints. 
+- **DNS resolution service for spoke virtual networks and cross-premises workstations.** That service usually takes the form of Azure Firewall as a DNS proxy or Azure DNS Private Resolver. In this architecture, this service resolves private endpoint DNS records for all DNS requests that originate in the spoke.
+- **Azure DDoS Protection.** Used to protect public IP addresses against distributed attacks.
+
+![Diagram of the part of the AI workload that is the responsibility of the platform team.](../media/platform-resources.png)
+
+## Critical dependencies
+
+All functionality that the workload performs in the platform and application landing zones are dependencies. Incident response plans require that the workload team is aware of the point and method of contact information for these dependencies, and the workload team should be included in the change management process for these dependencies. Also include these dependencies in the workload's failure mode analysis (FMA).
+
+Important dependencies to take into account:
+
+- Egress firewall. The centralized egress firewall, shared by multiple workloads, undergoes may undergo changes unrelated to the AI workload.
+- **DNS resolution.** This architecture uses DNS provided by the platform team instead of directly interfacing with Azure DNS. This means that timely updates to DNS records for private endpoints and availability of DNS services are new dependencies.
+- **DINE policies.** Deploy If Not Exists (DINE) policies for Azure DNS private DNS zones, or any other platform-provided dependency, are best effort, with no SLA when you apply them. For example, a delay in DNS configuration for this architecture's private endpoints can cause delays in the readiness of the chat UI to handle traffic or prompt flow from completing queries.
+- **Management group policies.** Consistent policies among environments are key for reliability. Ensure that preproduction environments are similar to production environments to provide accurate testing and to prevent environment-specific deviations that can block a deployment or scale.
+
+## Security considerations
+
+The following security considerations should be addressed when implementing this type of AI workload.
+
+- **Ingress traffic control.** Isolate your workload from other workload spokes within your organization by using NSGs on your subnets and the nontransitive nature or controls in the regional hub. Construct comprehensive NSGs that only permit the inbound network requirements of your application and its infrastructure.
+- **Egress traffic control.** Apply NSG rules that express the required outbound connectivity requirements of your solution and deny everything else. Don't rely only on the hub network controls. As a workload operator, block undesired egress traffic as close to the source as practicable.
+- **DDoS Protection.** Determine who should apply the DDoS Protection plan that covers all of your solution's public IP addresses. The platform team might use IP address protection plans, or use Azure Policy to enforce virtual network protection plans. This architecture should have coverage because it involves a public IP address for ingress from the internet.
+- **Identity and access management.** Unless otherwise required by your platform team's governance automation, there are no expectations of extra authorization requirements on this architecture because of the platform team's involvement. Azure role-based access control (RBAC) should continue to fulfill the principle of least privilege, which grants limited access only to those who need it and only when needed.
+- **Certificates and encryption.** The workload team typically procures the TLS certificate for the public IP address on Application Gateway in this architecture.
+- **Correlate data from multiple sinks.** The workload's logs and metrics and its infrastructure components are stored in the workload's Azure Monitor Logs workspace. However, logs and metrics from centralized services, such as Azure Firewall, DNS Private Resolver, and Azure Bastion, are often stored in a central Azure Monitor Logs workspace. Correlating data from multiple sinks can be a complex task.