 Hi, my name is Amy Collier, Senior Cloud Advocate with Microsoft. And joined with me today is Federico Garini, Senior Cloud Solution Architect for Customer Architecture and Engineering for ADS. Thanks for joining me, Federico. Hello, I mean, thank you for having me. This will be great to go over, but before we go into your network design guide, I wanted to go over the agenda, we're going to go explain the whole design guide, the approaches used, and the best order for use. We also have these accelerator landing zones for reference architecture and reference implementation. So as you can see, the Azure VMware Solution Planning Zone Accelerator has different design guidelines for you to go through. There's different design areas for network topology, connectivity, so we definitely recommend you check that out. The second link that we also have is the GitHub repository. You might even find this network guide there right now, but we have our accelerated landing zones and different options for greenfield and brownfield deployments. So let's start with the network design guide to go over all of this stuff. Yeah, sure. So the network design guide is an additional piece of content that we recently published in our enterprise scale for ADS repo. It is documentation that describes the recommended approach to designing network connectivity for ADS. This recommended approach aligns with the Azure Landing Zone's reference architecture. ADS connectivity is a very broad topic. Yeah, and in ADS kind of cloud, it may require connectivity to multiple different things, connectivity to Azure native resources, connectivity to on-prem data centers, connectivity to the Internet. ADS customers have complex and often conflicting requirements. These guides suggests a divide and conquer approach to tackle them. Okay. So can you tell us more about the approach used and advocated by the network design guide? Yeah, sure. The guide identifies four main design areas which are summarized and presented at the very beginning of the guide as you can see here. The first design area is connectivity to on-prem sites, then we have connectivity to Azure Virtual Networks, then inbound Internet connectivity, and finally outbound Internet connectivity. It is important to note that these four design areas are not completely independent on each other. Design decisions made in one area may limit the options available to you in other areas. The network design guide recommends the order in which the four design areas should be tackled to minimize such dependencies and to avoid entering loops whereby every new element added to a design requires going back and reconsider the design decisions already made. Okay. So then what would be the best order recommended by this design guide? Well, the most critical design area is connectivity between ADS private Clouds and on-prem sites, especially data centers with complex network. So it is critical that this is addressed first, so that the full spectrum of options can be considered without any constraints set by design decisions made for other design areas. Next, it makes sense to finalize the design decision for connectivity between AVS and native Azure Virtual Networks because that decision is almost entirely driven by the connectivity option chosen for connectivity with on-prem sites. Finally, Internet connectivity should be designed. Inbound and outbound Internet connectivity are two different things from a routing perspective. Therefore, the guide considers them as two different design areas. The recommendation here is that inbound Internet connectivity should be addressed first, because some decisions made for inbound Internet connectivity may limit the options available for outbound connectivity. Okay. So do you have any final thoughts on everything? Yeah, definitely. While the network design guide provides for each design area a pretty comprehensive set of options, real-world implementation may need to address very specific constraints or requirements. The ability to adapt the options presented in the network design guide to specific scenarios does require the solid understanding of the basics of AVS networking. This is why the guide contains an introductory section that summarizes the key concepts. It is not meant to be a replacement for the AVS official docker because that stays the automated authoritative source of tools for anything related to AVS. However, it provides a cohesive view of AVS networking with links to the relevant documentation articles in the official docker. This introductory section is presented immediately after the design areas and can be found by clicking the link here. As you can see, it is a collection of topics that are important to understand before starting to design complex AVS network solutions. Great. It's great to have all this at hand to help us decide what to do first and since everything builds up on another, like a building block to make that right decision in the beginning is really important. So thank you, Federico, for covering what the network design guide is. And I believe our next video will be covering that design phase one connected to the AVS to your on-premises data center. That's right. Thank you, Amy.