Merge branch 'MicrosoftDocs:main' into tozimmergren-caf-modernize-mig…

…ration

docs/_bread/toc.yml

@@ -1,92 +1,3 @@
-items:
 - name: Azure
-  tocHref: /azure
-  topicHref: /azure
-  items:
-  - name: Cloud Adoption Framework
-    tocHref: /azure/cloud-adoption-framework/
-    topicHref: /azure/cloud-adoption-framework
-    items:
-    - name: Strategy
-      tocHref: /azure/cloud-adoption-framework/strategy/
-      topicHref: /azure/cloud-adoption-framework/strategy
-    - name: Plan
-      tocHref: /azure/cloud-adoption-framework/plan/
-      topicHref: /azure/cloud-adoption-framework/plan
-      items:
-      - name: Digital estate
-        tocHref: /azure/cloud-adoption-framework/digital-estate/
-        topicHref: /azure/cloud-adoption-framework/digital-estate
-    - name: Ready
-      tocHref: /azure/cloud-adoption-framework/ready/
-      topicHref: /azure/cloud-adoption-framework/ready
-      items:
-      - name: Best practices
-        tocHref: /azure/cloud-adoption-framework/ready/azure-best-practices/
-        topicHref: /azure/cloud-adoption-framework/ready/azure-best-practices
-      - name: Best practices
-        tocHref: /azure/security/fundamentals/
-        topicHref: /azure/cloud-adoption-framework/ready/azure-best-practices
-    - name: Adopt
-      tocHref: /azure/cloud-adoption-framework/adopt/
-      topicHref: /azure/cloud-adoption-framework/adopt
-      items:
-      - name: Migrate
-        tocHref: /azure/cloud-adoption-framework/migrate/
-        topicHref: /azure/cloud-adoption-framework/migrate
-      - name: Modernize
-        tocHref: /azure/cloud-adoption-framework/modernize/
-        topicHref: /azure/cloud-adoption-framework/modernize
-      - name: Innovate
-        tocHref: /azure/cloud-adoption-framework/innovate/
-        topicHref: /azure/cloud-adoption-framework/innovate
-        items:
-        - name: Azure innovation guide
-          tocHref: /azure/cloud-adoption-framework/innovate/innovation-guide/
-          topicHref: /azure/cloud-adoption-framework/innovate/innovation-guide
-    - name: Operating model
-      tocHref: /azure/cloud-adoption-framework/operating-model/
-      topicHref: /azure/cloud-adoption-framework/operating-model
-      items:
-      - name: Govern
-        tocHref: /azure/cloud-adoption-framework/govern/
-        topicHref: /azure/cloud-adoption-framework/govern
-      - name: Organize
-        tocHref: /azure/cloud-adoption-framework/organize/
-        topicHref: /azure/cloud-adoption-framework/organize
-      - name: Manage
-        tocHref: /azure/cloud-adoption-framework/manage/
-        topicHref: /azure/cloud-adoption-framework/manage
-      - name: Secure
-        tocHref: /azure/cloud-adoption-framework/secure/
-        topicHref: /azure/cloud-adoption-framework/secure
-    - name: Scenarios
-      tocHref: /azure/cloud-adoption-framework/scenarios/
-      topicHref: /azure/cloud-adoption-framework/scenarios/overview
-      items:
-      - name: Data management
-        tocHref: /azure/cloud-adoption-framework/scenarios/data-management
-        topicHref: /azure/cloud-adoption-framework/scenarios/data-management/
-      - name: Hybrid and multicloud
-        tocHref: /azure/cloud-adoption-framework/scenarios/hybrid
-        topicHref: /azure/cloud-adoption-framework/scenarios/hybrid/
-      - name: Modern application platform
-        tocHref: /azure/cloud-adoption-framework/scenarios/app-platform
-        topicHref: /azure/cloud-adoption-framework/scenarios/app-platform/
-      - name: SAP
-        tocHref: /azure/cloud-adoption-framework/scenarios/sap
-        topicHref: /azure/cloud-adoption-framework/scenarios/sap/
-      - name: Desktop virtualization
-        tocHref: /azure/cloud-adoption-framework/scenarios/wvd
-        topicHref: /azure/cloud-adoption-framework/scenarios/wvd/
-      - name: Retail industry
-        tocHref: /azure/cloud-adoption-framework/industry/retail
-        topicHref: /azure/cloud-adoption-framework/industry/retail/
-    - name: Reference
-      tocHref: /azure/cloud-adoption-framework/reference/
-      topicHref: /azure/cloud-adoption-framework/reference
-
-      items:
-      - name: Decision guides
-        tocHref: /azure/cloud-adoption-framework/decision-guides/
-        topicHref: /azure/cloud-adoption-framework/decision-guides
+  tocHref: /azure/
+  topicHref: /azure/index

docs/operating-model/define.md

@@ -1,43 +1,43 @@
 ---
 title: Define your cloud operating model
 description: Learn how the Cloud Adoption Framework helps you define your operating model.
-author: martinekuan
-ms.author: martinek
-ms.date: 06/27/2022
+author: Zimmergren
+ms.author: tozimmergren
+ms.date: 10/24/2023
 ms.topic: conceptual
-ms.custom: internal, operating-model, UpdateFrequency2
+ms.custom: operating-model, UpdateFrequency2
 ---
 
 # Define your cloud operating model
 
-Cloud operating models are complex, and it's easy to fall into a series of circular references when defining them. The Cloud Adoption Framework provides a series of complimentary and incremental methodologies that break the large number of decisions into smaller exercises and help you avoid circular references as you define your organization's cloud operating model.
+Cloud operating models are complex, and it's easy to fall into a series of circular references when defining them. The Cloud Adoption Framework provides a series of complimentary and incremental methodologies that break many decisions into smaller exercises and help you avoid circular references as you define your organization's cloud operating model.
 
 ## Cloud Adoption Framework alignment
 
 To help you define the cloud operating model for your business, the Cloud Adoption Framework breaks down each aspect of the operating model into methodologies. Each methodology and its actionable exercises are designed to help you define your future state operations.
 
-![Diagram of different Cloud Adoption Framework methodologies.](../_images/caf-overview-new.png)
+![Diagram of different Cloud Adoption Framework methodologies.](../_images/caf-overview-graphic.png)
 
 ### Support for developing your operating model
 
 The following incremental methodologies are designed to help you develop your operating Cloud Adoption Framework model.
 
 - [Manage](../manage/index.md): Align ongoing processes for operational technology management.
 - [Govern](../govern/index.md): Maintain alignment with governance and compliance requirements and ensure consistency across your adoption efforts.
-- [Security strategy](../strategy/define-security-strategy.md): Define your overall security strategy.
+- [Secure](../secure/index.md): Align your business to the security disciplines and strengthen your security posture.
 - [Organize](../organize/index.md): Outline which functions your business needs and define organizational methods for your business goals and people.
 
 ### Collective operating model output
 
-Your environment should represent the way your business operates. As you define your operating model, make sure your environmental readiness aligns with your operations, governance, security, and organizational requirements.
+Your environment should represent the way your business operates. As you define your operating model, ensure your environmental readiness aligns with your operations, governance, security, and organizational requirements.
 
-- [Ready](../ready/index.md): Use deployment guidance and reference implementations from Azure landing zones to help you build your environmental configuration.
+- [Ready](../ready/index.md): Use deployment guidance and reference implementations from Azure landing zones to help build your environmental configuration.
 
 > [!NOTE]
 > The Ready methodology provides two implementation options for Azure landing zones:
 >
 > - **Start small and expand:** Build your cloud platform as you define each aspect of your operating model.
-> - **Enterprise-scale:** Build an enterprise-ready architecture based on a set of defined operating-model decisions.
+> - **Enterprise-scale:** Build an enterprise-ready architecture based on defined operating-model decisions.
 
 ### Dependencies and inputs for operating model decisions
 
@@ -48,7 +48,7 @@ Consider business strategy and collective cloud adoption plans as you define you
 
 ## Next steps
 
-Before you engage any of the methodologies described in this article, use the following article to compare common cloud operating models. Identify the model that most closely meets your requirements. This closest-match cloud operating model provides you with an actionable starting point and set of exercises to move you towards your desired cloud platform operating model.
+Before you engage any of the methodologies described in this article, use the following article to compare common cloud operating models. Identify the model that most closely meets your requirements. This closest-match cloud operating model provides an actionable starting point and exercises to move you toward your desired cloud platform operating model.
 
 > [!div class="nextstepaction"]
 > [Compare common cloud operating models](./compare.md)

docs/plan/data-warehouse-migration.md

@@ -5,7 +5,7 @@ author: v-hanki
 ms.author: martinek
 ms.date: 06/24/2020
 ms.topic: conceptual
-ms.custom: think-tank, UpdateFrequency2
+ms.custom: think-tank, UpdateFrequency2, build-2023, build-2023-dataai
 ---
 
 # Plan a data warehouse migration

docs/ready/azure-best-practices/private-link-and-dns-integration-at-scale.md

@@ -2,10 +2,10 @@
 title: Private Link and DNS integration at scale
 description: Private Link and DNS integration at scale
 author: JefferyMitchell
-ms.author: martinek
-ms.date: 09/30/2022
+ms.author: tozimmergren
+ms.date: 10/25/2023
 ms.topic: conceptual
-ms.custom: think-tank
+ms.custom: think-tank, UpdateFrequency2
 ---
 
 # Private Link and DNS integration at scale
@@ -51,13 +51,25 @@ From the previous diagram, it's important to highlight that:
 - All Azure VNets use the DNS servers hosted in the hub VNet (`10.100.2.4` and `10.100.2.5`) as the primary and secondary DNS servers.
 - If the DNS servers `10.100.2.4` and `10.100.2.5` aren't authoritative for customer's corporate domains (for example, Active Directory domain names), they should have conditional forwarders for the customer's corporate domains, pointing to the on-premises DNS Servers (`172.16.1.10` and `172.16.1.11`) or DNS servers deployed in Azure that are authoritative for such zones.
 
-While the previous diagram depicts a single hub and spoke architecture, this guidance also applies to scenarios where multiple hub and spoke networks exist across multiple Azure regions. In that case, link the hub VNets in all regions to the same Azure Private DNS zones.
+While the previous diagram depicts a single hub and spoke architecture, customers might need to extend their Azure footprint across multiple regions to address resiliency, proximity or data residency requirements, several scenarios have emerged where the same Private-Link-enabled PaaS instance must be accessed through multiple Private Endpoints (PE’s).
+
+:::image type="content" source="./media/private-link-example-central-dns-multi-regions.png" alt-text="A diagram of a high-level architecture with central DNS resolution and name resolution for Private Link resources in multi region." lightbox="./media/private-link-example-central-dns-multi-regions.png":::
+
+The following diagram shows a typical high-level architecture for enterprise environments with central DNS resolution deployed in the hub (one per region) where name resolution for Private Link resources is done via Azure Private DNS.
+
+It is recommended to deploy multiple regional private endpoints associated to the PaaS instance, one in each region where clients exist, enable per-region Private Link and Private DNS Zones. When working with PaaS services with built-in DR capabilities (geo-redundant storage accounts, SQL DB failover groups, etc.), multiple region Private Endpoints are mandatory.
+
+This scenario requires manual maintenance/updates of the Private Link DNS record set in every region as there is currently no automated lifecycle management for these.
+
+For other use cases, a single global Private Endpoint can be deployed, making accessible to all clients by adding routing from the relevant regions to the single Private Endpoint in a single region. 
+
+To enable resolution, and therefore connectivity, from on premise networks to the `privatelink` private DNS zone and private endpoints, the appropriate DNS configuration (conditional forwarders etc.) need to be provisioned in the DNS infrastructure.
 
 There are two conditions that must be true for application teams to create any required Azure PaaS resources in their subscription:
 
 - Central networking and/or central platform team must ensure that application teams can only deploy and access Azure PaaS services by way of private endpoints.
 - Central networking and/or central platform teams must ensure that when they create private endpoints, they set up how to handle the corresponding records. Set up the corresponding records such that they're automatically created in the centralized private DNS zone that matches the service being created.
-  - DNS record must follow the lifecycle of the private endpoint, in that, it's automatically removed when the private endpoint is deleted.
+- DNS records must follow the lifecycle of the private endpoint, in that, it's automatically removed when the private endpoint is deleted.
 
 > [!NOTE]
 > if [FQDNs in network rules based on DNS resolution is needed to be used in Azure Firewall and Firewall policy](/azure/firewall/fqdn-filtering-network-rules) (This capability allows you to filter outbound traffic with any TCP/UDP protocol -including NTP, SSH, RDP, and more-). You must enable Azure Firewall DNS Proxy to use FQDNs in your network rules, then those spoke VNets are forced to change their DNS setting from custom DNS server to Azure Firewall DNS Proxy. Changing the DNS settings of a spoke VNet requires reboot of all VMs inside that VNet.