 Hi, I'm Amy Collier, senior cloud advocate at Microsoft and with these Federico-Garini senior cloud solution architect And now we're going over phase 4 outbound internet connectivity for AVS So we'll go over the outbound internet connectivity options available and maybe some caveats to consider So this is the last design area Federico What's gonna be covered? Yes, I mean so the network design guide, okay It's designing outbound internet connectivity after inbound internet connectivity as we explained in the previous video And the reason is that if public IPs on the ns60 edge have been selected for inbound connectivity Then they must be used for outbound connectivity too and in this case you have essentially no Choices no design choices to make in this space. Okay. So that's pretty easy You can't do anything more to design in that case Yeah, correct. However, it is important to note that the opposite is not true If you are not using public IPs on the ns60 edge then you may still decide to use them for outbound connectivity only and This is explained or summarized in the flowchart that is available in the last section of the network design guide Okay, can you quickly summarize those options that are available? Yeah, sure sure The options can be seen in the Azure portal and the network design guides Guide includes screenshots for the portal tile that allows users to choose as you can see here At the end of the day Outbound connectivity is about the source nothing connections initiated by AVS virtual machines The easiest option is to let the platform do that on your behalf That's perfect when you do not need to stay in control of which or how many IP addresses are used for source not This is referred to as man as not in the Azure portal The other option is to use public IPs on the ns60 edge as a snap pull This allows you to decide which not to use and to do more advanced things such as using different IPs for snatching different connections. This can be done by means of proper ns60 configuration performed directly in AVS Finally, you can implement snap in Azure to do so a default route must be announced from Azure to AVS and This default route can even be propagated by Azure when a default route is received by Azure from on-prem over an extra circuit Snack can be implemented with Azure firewall if you prefer a first-party solution Alternatively, you can deploy MVAs and configures them to snatching the S connections This option is a common choice especially in brownfield scenarios where customers may want to leverage a pre-existing Azure Edge devices Great, I mean thanks for going over all these design phases throughout the network design guide It seems to really walk you through each step I'm sure many people find this very helpful and creating a proper connection throughout their Azure VMR solution design So thanks again for joining me make sure to watch all the videos that we have included and those Azure landing zones And thank you Federico Thank you, Amy