 Hey everybody, how's it going? My name is Mike Preston and today I'm gonna walk you through just how easy it is to deploy Rubrik's cloud data management software into your AWS environment through the AWS Marketplace. So with that, let's just dive right in. All right, before we jump right into the deployment, let me first give you a brief overview of what Rubrik is and why a modern solution like Rubrik is a right fit. To do that, let's go back in time and take a look at legacy data management. If you look at the backup and recovery space, not much has changed in the last 20 to 30 years. You have large levels of complexity across multiple components from backup software to server infrastructure. We have infrastructure providing backup services, replication services, indexing, cataloging, archiving. When we look at digital transformation, there's really three main imperatives that come up in conversations with our customers. The ability to leverage cloud, the ability to automate, and the ability to secure this data no matter where it lives. Unfortunately, all this legacy technology acts as a blocker to these initiatives. It was built 20 years ago and centered around proprietary old school storage. As you migrate to the cloud, this architecture breaks down. So what we do is we take everything you see and converge it into a single software fabric that's built for cloud. It's easy to use, easy to scale, easy to automate, and secure by design. As a result, we help our customers save on costs with increased productivity and reduced downtime and native integrations with AWS for very efficient operations. So how do we do it? Well, number one, everything about Rubrik is centered around ease of use and simplicity at enterprise scale. You can get started in under 20 minutes. Rubrik automates the way you do backups with intelligent SLA-based policy engines that dramatically reduce the hours you used to have to spend handholding your backups. Set up your policies and leave it to Rubrik to do the rest. We also provide instant recoverability through an easy search interface. This allows you to rapidly locate specific items you'd like to recover and to restore within minutes for near zero recovery times. Second, we're built for the cloud. In fact, our very first version of the product was natively integrated with AWS for hybrid cloud protection. We've built a ton of innovations in the cloud with archival, instantiation, and protection. And we've built in automation into every aspect of our solution. Not only can you automate the SLA policy creation, we have robust APIs and SDKs that allow you to integrate Rubrik into your other tools and workflows. Lastly, everything on Rubrik is encrypted and secure. With Rubrik, once data is written, it can never be changed. This makes the data secure and immutable to ransomware attacks. So speaking about cloud, our customers use Rubrik to fast track cloud usage and to facilitate their cloud journey at their own pace. We have three ways we provide this. The first is cloud out. We typically see our customers utilizing Rubrik's feature called cloud out to apply a cloud first strategy in terms of long term data retention. They send and store data cost effectively in the cloud with the ability to search data on premises. The second is cloud on. Once that data is in the cloud, customers can utilize that to instantiate a cloud environment through the automated conversion of VMDKs into AMIs. And lastly, once you're up and running in AWS, we provide native protection as a service for AWS. For hybrid cloud enterprises, Rubrik abstracts away the complexity of managing data protection for on-prem and cloud environments through setup ease, the use of only one console, and a high performance system for backup and recovery operations. We've designed our solutions so that data is owned and always under your control. So speaking of cloud native protection, this is provided by a SaaS offering from us called Rubrik Polaris. No additional infrastructure is needed. Customers simply sign up for a Polaris account, add their AWS accounts, and they can begin orchestrating and replicating snapshots of their EC2 and RBS instances. So if Polaris is SaaS, why do we even need to deploy a cloud cluster in AWS? Well, for native EC2 and RBS protection, you don't. However, there's many reasons we see our customers choose to deploy and run Rubrik software directly from within their AWS environments. First, it supports native backups for those databases that you may be running within AWS like SQL, Oracle, or SAP HANA. Secondly, cloud cluster enables backups of native cloud NAS services such as EFS. And if you're running VMC on AWS, then cloud cluster is the recommended best practice to protect those VMs. Cloud cluster can also act as a replication target for another Rubrik cluster that may be located elsewhere. Also, cloud cluster together with the Rubrik backup service can enable a more granular level of backup of your EC2 instances, say only a subset of files need to be processed. And finally, cloud cluster can act as another disaster recovery point located within AWS for your organization. So with that, let's jump into a demo of how to actually deploy a Rubrik cloud cluster. All right, so here we are on the AWS marketplace. So let's just go ahead and perform a quick search for Rubrik. As we can see, we have a couple of options. One being our bring your own license model if you already have entitlements to Rubrik. As well, we have the option to purchase a completely new Rubrik cluster. I already have entitlements. So I'm going to go ahead and choose this bring your own license option. So we get a brief overview here of what the Rubrik cloud cluster is, what it can do for you, and things like customer reviews. Let's go ahead and keep the ball rolling and I'll click continue to subscribe. After taking a look at the terms and conditions, we can kick off the deployment process by selecting continue to configuration. Okay, so now we need to make a couple of decisions. First, there's only one delivery method. So we're good with the AMI deployment selected. Then we need to select what version of Rubrik CDM we want. As you can select anywhere from the 5.2.2 version right up to the latest release. I want all those new bells and whistles. So I'll select the latest 5.3.1 release listed here. We then need to specify what region we want this cluster deployed into. Let's go ahead and leave this at US East 1 and we'll click continue to launch. Now we get a few more options here. We could launch one node directly from the marketplace website here. And this is great for doing things like scaling up existing cloud clusters when the time comes. But for our initial deployment, we're going to need a minimum of four nodes. So in this case, let me just select to launch through EC2 as I know I can specify the number of desired nodes during that config. So on the EC2 launch config here, the first thing we need to do is specify our instance type. Currently Rubrik supports the M5x large, which we refer to as standard, and the M5 for X large, which we refer to as a dense configuration. For reference, our standard config, the M5 XL supports between two to 24 raw terabyte clusters, whereas the dense config, the M5 for XL supports 24 to 96 terabytes of raw capacity. In this case, I'll just leave it at the M5x large and move on. Now since this is our initial cloud cluster deployment, we'll want to get our cluster up to the minimum of four nodes. So let's first change the number of instances to four. And then we can go ahead and select our desired VPC, and it's associated subnet that we want to deploy into. Everything else here, we can simply just leave at the default configuration for the time being. So as far as storage goes, there's a number of requirements based upon the different types of deployments that we have. Now this is all covered within the user guide, but let me dive in quickly here. The number of data disks that are needed and their associated size will really be determined by the raw capacity that's being allocated for the cloud cluster. If standard nodes are being deployed using the M5x large instance type, the capacity per node can be between 1.5 terabytes and 6 terabytes. If we're using dense nodes, then the capacity per node can be between 6 and 24 terabytes. A minimum of three disks per node are required, with a maximum of up to six disks. The individual capacities can be 512 gigabytes, 1 terabyte, 2 terabytes, or 4 terabytes. For all cluster configurations, the ST1 disk type is used. Except when we're going with the dense node deployments with 24 terabytes of disks, those nodes can use either the ST1 disks or the SC1 volume type. It's also recommended to enable encryption for both the data disk and the cloud cluster root disk in order to ensure that encryption at rest is applied holistically. Today we are deploying the dense configuration, so let's just add a few disks here. Let's say three 1 terabyte disks, and I'll go ahead and I'll set these to be throughput optimized. Now we'll go ahead and we'll select to have these disks removed upon termination as well. That way, if we ever do get rid of this Rubik cloud cluster, we won't have those EBS volumes laying around. And we'll specify what KMS key that we want to utilize for our AWS native encryption. Next, if we wanted to tag these instances so they adhere to any AWS tagging policies that we may have established, we can do so. I'm okay here, so I'll just move on. Now we need to either create or use an existing security group. I already have one created here that I know will work. So I'll just go ahead and select that. And then finally, we do a quick review and select launch. Lastly, we select our key pair here that we can use in order to gain SSH access into our newly deployed Rubik nodes. And we'll simply select to launch our instances. So through the magic of video, you can see that we're all up and running with our newly deployed for Rubik instances. The next step, which I've already done in this case, is to bootstrap the cluster. This involves establishing a connection into one of the deployed nodes and running the cluster bootstrap command. There, you'll simply provide things like the default administrator password, DNS and NTP settings, as well as the IP information for the four nodes you wish to have participating in that cluster. Rubik will then go through a process to get that initial cluster up and running, ensuring the services on each node are running and that communication between the nodes is established. Since this is already done, we can go ahead and connect to our cluster. This is done by opening up a browser window to any one of the node's IP addresses. So I'll grab one here and let's connect. All right, we'll open up a new tab here, accept the certificate, and then we can simply log in as admin. And we'll use that default administrator password that we set during that bootstrap process. Once we're in, we simply need to accept the EULA. And then we need to ensure that our cluster is registered. This is as easy as entering in our Rubik support credentials and clicking register. And there we have it, Rubik software running within AWS, fully registered and ready to go. Thanks for watching and remember, don't back up, go forward.