I'm so excited to be able to talk about our recent announcements with Neta, VMware, and AWS around supplemental data store support with VMware Cloud on AWS. I'm going to be doing a demo with our TCO calculator, and I think you're going to be impressed by the benefits that you get with Amazon FSX for NetApp on. This new supplemental data store offering combines VMware Cloud on AWS with Amazon FSX for NetApp on saving customers money. This offering is attractive to both NetApp and non-Netapp customers alike. If you're on VMware Cloud on AWS today, I'm going to be talking about ways we can save you money as you grow. And if you're not using it today, I'm going to give you reasons to give it another look. With all this discussion about lowering cloud costs, I felt I needed to level set. When we're talking about HCI environments using VSAN, we pull our compute, memory, and storage as we add new nodes. There really isn't a way to scale independently. This is why storage heavy workloads can cause imbalance in your environment. Meaning I have to buy more expensive compute nodes than I really need because I need to have more storage. As we take a closer look at VMware cloud on AWS in regards to storage, historically our only option was to use VSAN from a data store perspective. When we deploy VMC, we get a management data store based on VSAN and subsequent workloads are deployed on data stores as well. This new offering with supplemental data stores allows us to deploy new workloads on NFS data stores in a fully supported and certified manner. Completely integrated with VMware cloud, we can independently scale our resources in the cloud, allowing us to rightsize our environment with an ONAP based firstparty service within AWS. And remember, this firstparty service provides popular ontap benefits including snapshots, snap mirror, flex clone, and data compression and dduplication. So now here we are in our TCO calculator and the first thing I want to point out is the web address. This tool is located on cloud.netup.com and you can access it today. As we move down to our sizer inputs, I want to point out you can do a manual sizing or you can input using an RV tools file. RV tools helps you assess your current environment, allowing you to make decisions when considering new deployments based on your workloads. But we're going to do a standard sizing exercise. Here we see our VM count at 400 and our storage per VM at about a terabyte. There are other details you can enter including IO parameters and storage parameters including your region. Uh but we've prep-populated the tool with some defaults to make it easier. You can also enter details for a disaster recovery profile and transit gateway attachments which I'll cover later in the demo. For now, let's go ahead and hit submit. And you'll see we get a very simple output from our tool. We can easily see the number of hosts that you need to satisfy the workload requirement if you're only using VMC with VSAN data stores for instance. And we can see what would be required if you were using VSAN complemented by a supplemental data store with FSXN. The net TCO savings here in this example is 60%. Now you may ask where we got these sizing considerations. And if we scroll down a little bit more, you will see our sources which you can actually go and check out for yourself. The first is the performance documentation for Amazon FSX for NetUP on tap. Next is the pricing calculator details and finally our quota details for this service. These are all things that you can easily get familiar with yourself and we leverage this information straight from Amazon and VMware to come up with our sizing details. So obviously 60% looks great. Let's run through another sizing exercise. Let's take our number of VMs. We'll reduce it by half and we will reduce our storage per VM by half as well. Now since I've emphasized that storage heavy workloads benefit the most from supplemental data store support, we would expect our TCO savings to be less. Let's hit submit and we will see that our TCO savings has gone down but we're still saving uh about 27%. Now you may be wondering about a sizing exercise that wouldn't look as great. Let's go back and we'll run the tool again and this time I will be reducing the VM count to 100 VMs and the storage needed per VM to 200 gig. We run our sizing exercise again and there right away the tool will tell you that there is no TCO benefit. Now finally I want to show a very heavy storage workload. I will double our VMs required from our original exercise and I'll double our size needed per VM. And let's run our report again. And we'd expect our TCO savings to increase given this is a very storage heavy workload. And after running a tool, we see that our savings are up to 72%. Now I mentioned disaster recovery profile earlier and you can see that here and all these variables that you can modify based on your needs. And as far as transit gateway attachments go, you can modify those here and they are reflected in the cost calculations and you can modify the amount of data transferred per transit gateway attachment as well. This wraps up a brief demo of our TCO calculator and is pretty clear how Amazon FSX for NetUP onap can drive your cost lower both from a compute perspective because you need less host but also because you're using FSX for NetUP on you're getting the storage efficiencies with ONAP that our customers love today. So, thank you very much for watching and feel free to check out this link for more information.