 Hi, I'm Amy Collier, Senior Cloud Advocate at Microsoft. And joining with me is Federico Guerrini, a Senior Cloud Solution Architect, covering customer architecture and engineering for AVS. And we're on to phase one, connectivity between AVS private clouds and your on-premises site. So first, we're gonna go over the design approach that connectivity between on-prem and AVS, then some examples, best order for use, the IPsec VPN option, and maybe some other options to the site global region IPsec VPN. Yes, Amy, the guide describes three different implementation options in order of increasing complexity. The recommendation here is that the simplest option should be always considered first. Only when solid technical reasons are identified that they make an option and not viable in a specific scenario, then the next one should be considered. And this approach is summarized in this flowchart that is presented at the beginning of the first section of the guide. Okay, Federico, can you give me an example? Sure, Amy. So the first option covered in the network design guide for connectivity to on-prem sites is ExpressRoute Global Richer. It allows connecting a customer-managed circuits and the AVS-managed circuits. This is supported out of the box in AVS. It can be set up in a few simple steps and it is optimal from a performance standpoint. However, there are a few cases where this option is not viable. For example, when global rich is not available in the country where the customer-managed circuit or the private cloud have been deployed. In these cases, the second option covered in the guide which is used in IPsec VPNs should be considered. All right, so can we talk about that IPsec VPN option? Yeah, sure. This is a topic that the design guide tries to demystify. There are many ways to implement IPsec VPNs for AVS connectivity. You can use a virtual encumber or you can use a normal VNet. As for IPsec devices, you can use Azure VPN gateways, third party VPN concentrators deployed as NDAs and so on and so forth. Instead of attempting to document all the possible combinations, the guide recommends a three steps approach to identifying the IPsec VPN implementation that best fits a specific scenario. The first step is choosing the underlay for the IPsec tunnel. The underlay can be the internet or an extra source circuit. If extra source is chosen, both the Microsoft peering and the private peering can be used. The guide sticks to its philosophy of presenting the simplest option first. If it is not applicable, then the more complex ones should be considered. The second step is about choosing between hosting the VPN device in a customer managed VNet, I mean, the traditional Habesburg model or in a virtual encumber. As far as AVS connectivity is concerned, the two alternatives are equally valid. The guide just presents them both without making a recommendation. In most cases, non-AVS related requirements or other Azure workloads will dictate the best option. And finally, the first step is about choosing the IPsec device itself. The choice is between a native VPN gateways and third party NPAs. Again, as far as AVS connectivity is concerned, the two alternatives are equally valid. The guide just presented both without making a recommendation. In most cases, non-AVS related requirements and other Azure workloads will again dictate what option to select. Okay, so we've discussed global reach connectivity and IPsec VPN. Is there that third option, right? Yeah, definitely. The third option is a routine traffic between a customer managed extra circuits and AVS managed circuits without using global reach. This is not a native capability of the Azure platform. The guide describes two possible implementations. Both requires deploying third party to be capable NPAs. The two approaches offer different trade-offs between implementation complexity and flexibility. The guide again applies the principle of presenting the simplest implementation first. The second one should be considered only when the first one is not applicable. Great. Well, thank you again, Federico, for going over what seems to be one of the most important phases for your design, the connectivity between on-premises into AVS. And I look forward to our next talk on design, please, to connectivity with Azure Virtual Networks. Thanks. Thanks, Ben.