Name: Rubrik Workshop: Protecting Mission-critical AWS Cloud Applications with Rubrik
Uploaded: 2026-02-19T20:30:25.902Z
Duration: 40 min 36 s
Description: Rubrik Workshop: Protecting Mission-critical AWS Cloud Applications with Rubrik

Transcript for "Rubrik Workshop: Protecting Mission-critical AWS Cloud Applications with Rubrik": Okay. Awesome. Alright. Looks like we're live. Welcome, everybody. Thank you for joining us today. If you're here to talk all things AWS, you're in the right place. So excited for the content that we have lined up for the next forty five minutes to an hour, depending on how things shake out. I'm gonna give it just a minute or two as people join. Maybe I'll go through this twice. But, basically, in in short, the themes for today are engagement and interaction. So the more you guys can engage with us via the chat and q and a, don't worry. No one's asking you to go on camera. We're not crazy. But engaging in terms of, you know, your thoughts, your questions, that's what really will make today valuable, hopefully, for everyone. Awesome. Cool. If you're just joining us, thank you so much for hopping on. We're gonna get started in just a minute. Awesome. Alright. Well, we can just jump into things, and then as people join although, miss is my very exciting introduction here. But welcome. Really excited. Hi, everybody here. We have some awesome content. If this is your first, like, rubric workshop, I'm really excited for you because it's a pretty awesome experience. We're gonna get deep into the tech. We're also gonna give you the opportunity to walk through kind of, like, a guided lab, guided demo portion towards the end of the session today. So, hopefully, you came with your questions and are excited to to learn a little bit more. Like I was saying before, the chat and the q and a are both open, I believe, and we would just love your engagement. The more questions you have or thoughts that you can share via again, no video. No one's asking you to do that. Via the text would just be would be great. It really helps both Mike and and myself and other people just learn from each other and just have kind of a a more valuable session. So navigate to the right hand of the screen. You'll see the chat and the q and a both are open. The q and a helps us keep track of it a bit more because then we can, like, mark something as answered. But all good if we end up using the chat as well. Okay. I guess with that being said, I'll hand it over to you, Mike, to just do it in a little introduction and then maybe, like, a walk through of what they're gonna see for the next forty five minutes to an hour. But don't worry, folks. I'll be back. But, yeah, over to you, Mike. Awesome. Awesome. Thanks, Hannah. And, yeah, I just wanna reiterate that. As we go through things, if you have any questions or comments or, I don't know, you just wanna see your name pop up, feel free to to use that chat in q and a. I really like to sort of tailor these to what everyone wants to hear about, and we can completely completely derail conversations. That's okay with these things. That's how you know, there's no real, like, script to how these should go. But, anyways, over the next little bit, I'm gonna talk to you guys a little bit about Rubrik and AWS and who I am. I'm Mike Preston. I've been here at Rubrik for almost eight years now. So I'm this is I'm going on my eighth year. So I've seen Rubrik evolve from, like, just backing up VMware and archiving that to AWS into the entire platform that we have now in terms of providing cloud data protection for, you know, the big three clouds for AWS, Azure, and GCP to providing SaaS based data protection, like m three sixty five, Salesforce, Jira, and, of course, all the familiar, like, prem workloads and things like that, and seeing us now start to move into the AI space with Rubrik agent cloud and start to monitor and remediate actions that your AI AI agents are taking. So it's really cool to see how the company's evolved with sort of the the industry. What I do here at Rubrik, I sort of lead tech marketing in terms of cloud as well as APIs and automation. Those two things kinda go hand in hand. So, certainly, if you have any questions or wanna dive further into any of that stuff, feel free to to bring them up. How things are gonna go today? We just had inter introductions. We had some housekeeping options. I'm gonna dive into sort of Rubrik and AWS, talk about, you know, why we need, protection in terms of of cloud and AWS specifically, and then we'll give you the guided lab link. It's somewhat of a new lab. We we revamped it last time. So it's it's more of a use case slash scenario driven lab. So it's gonna be like you're gonna be put into the seat as being hired as a cloud architect for a fictitious company and actually have to, you know, go through a simulated attack and and restore the actual pieces, for that company. So it's a little bit more exciting than this is this is how we onboard AWS to Rubrik. This is how we back our things up. This is how we recover. You can actually go through some real world examples, and we'll wrap up and and close. So with that, to kinda level the playing field, I don't like to put, you know, too many marketing type slides into this, but I do like to promote our Rubrik ZeroLabs. And I usually like to do this first. So if you head to 0labs.rubrik.com, this is sort of an arm within Rubrik, sort of a research arm that that does surveys against different CIOs, CTOs, different organizations, customers, prospects, basically, the industry and starts to pull in some data and glean some insights from that data. And, you know, one on the left here, we talk about data growth. This should come as no surprise to anyone. This has been, you know, happening since the seventies and eighties. We've been, you know, doubling and tripling the amount of data that we're we're growing, but the sensitive data itself is is kind of following in line linear. Right? So there's a lot more sensitive data out there. Identifying where that sensitive data is is quite a challenge. Cloud doesn't help in that case because it's so easy just to spin up services and spin up infrastructure in the cloud that, you know, it's just easily to duplicate, different production infrastructures that we have and things like that. So we end up with more and more data, more and more sensitive data. And we look at some of the facts in terms of threats. 94% of the, organizations that we talked to were actually targeted with some sort of threat. Now this might might not be like a full fledged attack, but it could be, you know, just they could see in the logs if someone's trying to get in or something like that. So that's pretty much everybody, and sixty two percent of them were actually compromised in some way or another. And five days is what they saw for sort of the medium dwell time for an event, which is actually pretty low in terms of what we see out there for the industry average. Normally, we see this extending into weeks and months. But just some interesting stats that you could sort of glean to to sort of understand why we need to protect data in the cloud and why Rubrik's even even here talking about this stuff. If we look at this image here, it's it's gonna be pretty, recognizable to almost any organization. Right? We have data everywhere. We have colos. We have on prem data centers. We have SaaS applications. We have the cloud providing infrastructure as a service and platforms as service, all those databases, object storage, big giant NAS system sitting on prem. Basically, we have data all over the place now. And it's all interconnected, and there's a ton of different teams that sorta manage that data. So one person that's responsible for a certain piece of data might not be responsible for another piece of data. So, really, reining all this in and taking a a look at this holistically holistically is super important. Because what we see here, you know, as being an IT nerd or or an IT practitioner, we see complexity. Right? Although we know how to set all this stuff up and and make everything talk to each other, it's definitely complex. But what an attacker or a bad actor or a threat actor might see is opportunity. Right? Because we see how everything's interconnected. So if you imagine we compromise, say, the security ops team or the cloud dev account there, you know, we can quickly traverse from it up into a PaaS solution, up into our cloud accounts, back down to on prem, things like that. And that's essentially what happens during an attack. Right? A threat actor gains access usually by compromising one of the the bottom accounts here, And then they just sit within your environment performing discovery. You know, I think the latest stats say that's around thirty to sixty days, looking to move laterally, elevate permissions to different things, elevate permissions to even get access, look for look for backup data. So if your backup data is actually in here as well, they're gonna target they're gonna target that because they do not want you to recover. Right? That increases their chance once they sort of begin to expand their footprint, exfiltrate that data, and then finally destroy or encrypt the actual data. In the cloud, we often see it being deleted more than we see it being encrypted. That that sort of ransomware seems to be the encryption seems to happen more so on prem, but we, you know, we we see both. So that's essentially where we're at. A couple different examples of some attacks as of late, and they should they should be fresh from the the mind. Right? So this isn't really an attack itself. This was sort of a systematic failure of the the cloud provider, and I'm not sure how many people heard this one. It was about, I wanna say, six months ago, if even that long. My I'm not I'm not quite sure when it happened. It's very recent, though. A multibillion dollar pension fund had their infrastructure all up in the cloud, and I think it was like a serverless cloud function or something. Something was missing a parameter, and things kinda went awry, and their cloud account ended up being purged. So if you can imagine one one minute, you're kinda plugging along there fine, running along, and then all of a sudden, you start to hear all of all these widespread outages and things like that over a missing parameter in in, one of their serverless functions. And next thing you know, their cloud account's been staged for deletion and deleted. So that's their entire account that went missing in this in that point. Now like many people, they had, you know, multiple different cloud accounts to host multiple different services, so they weren't completely down. And they did pretty good in terms of of this response. We can see fourteen days to to be fully recovered, actually have their minimum viable company or their minimum viable services up in day eight. That's that's not bad. That's that's better than, I think, the average for people to to actually recover their data in terms of of suffering some sort of drastic loss loss of infrastructure and data within the cloud. A second one is gonna be CodeFinger. We've probably all heard of this one. We're talking about this one was AWS specific, And it was really about, you know, attackers using sort of existing cloud tools or the the cloud's own encryption tools to sort of lock customers out of their own data. Right? So gaining access. Again, it was usually achieved through some sort of compromised credentials or, you know, they could buy AWS keys off the dark web or find them, you know, during an on prem attack or anything like that. But the idea was they they use those compromised credentials to come in and actually encrypt s three data using the native server side encryption and then basically toss the the key from there. So in that case, everything was rendered rendered basically unusable. Right? You had to contact these guys, to get those keys, to decrypt all the data, or you had to actually ensure that you had maybe air air gap backups available, and you could actually recover probably to another account and another identity domain, which would be, which would be ideal in this case. But the idea is it's not all just, you know, doom and gloom in terms of, like, somebody hacking into your environment. It could be as simple as a serverless function, you know, missing a parameter somehow queuing your your entire account up to be for deletion or seeing, you know, native cloud tools being used basically against you. And in the case of CodeFinger, they actually, you know, did some some interesting things in terms of the object life cycle management APIs. So they manipulated that schedule to ensure that your data is scheduled for deletion within a short time frame. Right? So changing that changing those values so your retention policy is basically redeemed useless in this case. So it's no wonder, you know, when when clouds get breached, when our data is breached, you know, we're down for a long time. And I and I always ask people, like, how long do you think you would be down? Do you think it would take a day to recover? Would it take two days, four days? Are we talking weeks? You know, some some organizations were into the the months, which is is not good. Right? That's days, weeks, months of downtime, days, weeks, months of lost revenue and, you know, reputational damage and and things like that. And the answer I usually get from, different organizations is we're cool. Right? We got we got snapshots. We're using either AWS's native tools or or AWS backup to create those local snapshots or, you know, we're scripting it out ourselves. We're alright. We have snap we have local snapshots within our cloud account. And while these do service purpose, I always say that's good. I'm glad you're using some sort of native functionality to take snapshots because that's super important. Right? And, I'm gonna just go ahead and build these two out. But the problem is cloud snapshots, while they're great for things like operational recovery so I've deleted a file. I need to go and restore that file or, you know, I'd like to restore this e c two instance to whatever it looked like last week, or I need to, you know, make a copy of the s s three bucket and, you know, place it over over here in this account. So with that operational type stuff, cloud snapshots, native snapshots, they work great. But really where they fail is when we get to the point where we actually need to perform what we call a cyber recovery. Because when we are recovering from some sort of an attack, that's really, really different than our sort of traditional Doctor type scenarios. Excuse me. I have a bit of a cold here, so I'm try try not to lose my voice. But, yeah, it's really different than than our traditional Doctor because there's a number of questions that need to be answered. There's a number of things that we need to do. We can't just simply restore to last night's backup. And the first two reasons are here. Like, when we think about zero day attacks, we're finding and quarantining malware. Now like I mentioned, those bad actors are in your environment for thirty, sixty days. They're planting little seeds, dropping their attacker tools, dropping dormant malware on different workloads and and in different locations. And as a backup vendor, whether it's native tools or whether it's Rubrik, we're gonna go ahead and we're gonna back that up. Right? Because that's our job, is to create a an exact point in time copy of your data. So if there's malware there, we're gonna back that malware up. Right? But, you know, when you go to restore that, you need to you need to ensure we're not actually restoring that malware or that we've gone ahead and identified and plugged those or patched those zero day attacks before that goes back into production because, otherwise, we could again into this big Groundhog Day scenario where all of a sudden, our environment is reinfected again. Right? And we need to do this across all of our backups Because if we aren't, if we cannot find and quarantine malware, we can't identify those zero days within all the backups, we'll get to a point where we, you know, maybe take a guess, restore the last night's backup. Did that work? No. We're reinfected. Okay. Let's try two nights ago. Right? So you get into this point, and a lot of people will throw that into a clean room to be scanned and different things like that, and all of that takes precious, precious time. Like, that's why we're down for weeks or or months. The next thing is sensitive data impact. So if an attack happens on your production AWS account, quite often, that account's gonna be quarantined. Nobody's gonna be allowed in. Nobody's gonna be allowed out. And then your legal teams and your boardrooms are gonna come and say, okay. So we know something's happened. Was any sensitive data at all impacted? Was any customer data impacted? And you need to be able to answer those questions because if you answer that yes or no, that inherently changes everything about the threat. Right? So if if you're regulated by some industry, you need to notify customers if their data's been impacted. That's usually one of the first questions you need answered because the time starts ticking at that point in terms of how long you have to do that. So we need to be able to ensure that we could determine if anything sensitive was affected by the attack even without being having access to any sort of production resources within that account. And then finally, you know, this all sort of leads into calculating what that clean recovery point is. Right? So when do we know how do we know where we can restore to? Is it last week? Is it last month? You know, do we have to restore something from two months ago and then sort of surgically build on top of that with with known good sort of files and folders and things like that? Really being able to identify that clean recovery point is key in that that cyber recovery process. And when I say clean recovery point, I mean it's free from malware, it's free from attacker tools, and it's actually free from, like, anomalies. Right? It doesn't contain, the encrypted files or the encrypted data itself. And all of this sort of takes a long time traditionally, to get at. Like I mentioned, a lot of times what what's involved in this is we take a snapshot, we mount that into a clean room or into a different account or into some sort of isolated environment. We have our security teams come in, SecOps comes in, they scan this using all their tools. They ensure whether or not it's clean. Is it clean? Yes or no? No. It's not. So then the next one comes into the clean room, and the same thing happens over and over and over again. And, again, takes a lot of time and affects what we call the cyber RTO or the the restore time objective on recovering from a cyber attack. So it's no wonder, you know, if we're manually scanning and manually doing all of this when our cloud's breached, we're actually down for for weeks. It's not a thing of of days. We're not, you know, jumping in and just restoring the last night's backup. There's a lot more that needs to be done, a lot of questions that need to be answered before we can even begin the recovery process. So this is really what Rubrik has strived to do with Rubrik Security Cloud by taking sort of the backup and recovery processes, those traditional sort of Doctor type scenarios, right, being able to take really, really quick and efficient backups, being able to, you know, restore those really fast, and then merging that with different cybersecurity sort of overlays to help us with things like dealing with zero day attacks, with identifying sensitive data, with really giving you that clean recovery point right off the hop. And this is really all done with what we call our preemptive recovery engine. And that's like, I always like that that naming, that we had, but it's kind of a weird thing to say as preemptive recovery. But that's exactly really what it is. What it is is it's really answering questions for you before you even ask the questions themselves. So what I mean by this is we're just gonna go ahead and we're gonna take backups of your cloud environment. So whether that's your e c two instances, DynamoDB, RDS, s three, things like that. Right? We're gonna take those backups, but we don't end at just, you know, taking a backup, storing it, making it immutable so it can't be changed or can't be affected by the attack, air gapping that outside of your account, so the attackers don't actually see the backup data at all. You know, it's sort of logically air gapped and and tucked away. We don't stop there. We continue to glean some insights on that data. And that and when I'm talking about this stuff too, I wanna say this isn't just for cloud data because, you know, the way everything's interconnected, if we go back to that that main graphic with everything sort of flowing all over the place, we can't just use a point solution to, you know, protect, recover, and scan our clouds without doing the same thing on prem because attackers are moving all over the place. They're traversing laterally through our environments. So this is going to apply to all of our data no matter where it is, whether it's in the cloud, whether it's on prem, whether it's SaaS based data like, you know, m three sixty five's OneDrive or something like that. So the idea is we're gonna go ahead and we're gonna take a backup. We're gonna make that backup immutable. But what we do with that backup is start to generate some really enriched metadata around different security aspects and apply that to the backup. So what I mean by this is the first thing we're gonna do is we're going to sort of prescan all of your backup images. So as that back as that backup's ingested, we're indexing all the files in that. Right? Every backup vendor does that to provide things like file level recovery and, fast search, things like that. But we're also taking a file hash of everything and sort of saving that into a database, and actually, you know, putting that through what we call our threat monitoring and threat hunting capabilities. So what these are is threat monitoring. As those backups are ingested, Rubrik's gonna use a feed that we get from Mandiant. So you we've probably all heard of Mandiant. They're, you know, one of the leading incident response providers. So we get this threat intelligence feed from them. We pass that along to you as well as ZeroLabs has some different threat intelligence that they add to that, and you can add your own. Or if you already subscribed to another threat intelligence feed, you could do that as well. And we're gonna go ahead and we're gonna scan all of that backup data against that threat intelligence feed. Contains something like 5,000 known malware families, 600 plus attacker tools, things like that. Or you can add your own sort of, you know, file hash if you want to or Yara rule if you're searching for something specific. And we're gonna scan, and we're gonna point out whether there's any matches. So already, you know, after the backup, is there dormant malware lying in this backup? And then you have the ability to actually quarantine that so it can't be used for recovery. Now this is handy, one, to ensure we don't reinfect our environment. Right? And, two, so we ensure that, you know, someone else doesn't log in to Rubrik at some point in time to maybe make a copy of a an e c two instance for some sort of dev test related, things and actually accidentally restore an older instance that has that malware in it. So the whole idea around threat hunting, threat monitoring is the ability to to scan your backups as they're ingested for those known sort of threats out there and allow you to quarantine that data so it can't be used for recovery. Now threat hunting threat monitoring happens automatically. Threat hunting, that's more of our on demand. That's really what we're gonna use for zero day attacks that might not be in that threat feed. Maybe you grab a file hash, you're looking for a certain thing, and you can scan across all your backups very, very quickly. We actually call this turbo threat hunting, because I think the latest sort of stats we have is something like scanning 60,000 restore points in in, like, five minutes or something like that. It's something crazy. It's it's because of all that indexing and prehashing that we do during the backup job that allows us to scan, you know, so quickly because it gets stored in a database. And from that point, it's just a relational database query. And this is very important because if you're looking for a threat, you can't just look at last night's backups. You can't look at the last week's worth of backups. To guarantee that that those backups are clean, you have to look at them all. That's every restore point from every workload across time. So if you've had Rubrik, you know, for five years and you're taking daily backups and keeping daily backups, that's that's a lot of restore points. I don't know. 1,800 restore points or something like that, for one workload. Next is gonna be prediscovering that sensitive data. So like I said, your legal teams, your boardrooms, this is this is the stuff they wanna know right off the bat. Was any sensitive data affected? And we'll classify that sensitive data again as it's ingested with with the backups. And this is done by, you know, classifying your data against a number of predefined data types that we have. So things like PCI, credit card data, personally identifiable information, passport numbers. I don't know. There's there's there's a lot of them within the product that are that are prebuilt out for you. But if you have something that you wanna search for that's specific to your organization, you can easily add that using some sort of regex pattern or dictionary item. And we can actually classify your data, against your your custom sort of data types as well. One really kinda unique one I've seen in here is the ability to scan for AWS access access keys. Almost every attack we hear usually starts with some sort of on premises. You know, they they get through into maybe a VMware environment, and then they find access keys laying around in plain text in some sort of text file or some script that somebody wrote. And next thing you know, they have access to the cloud environment. So you'll be able to actually scan all of your data for those AWS access keys or secret keys, and sort of proactively go out there and, you know, tidy that up, and get rid of them if need be. And then finally is precalculating that clean recovery point. Right? This is what it all comes down to. We wanna get the latest non anomalous, non quarantine snapshot, and that's exactly what our preemptive recovery engine does. It when you go through and perform, basically, what we call a cyber recovery with Rubrik, it's gonna already have that recovery point picked out for you as soon as you log in. So maybe, you know, things start going down the night before, you come in maybe early the next morning. It's already gonna have those recovery points selected for you in the recovery plans, and you can, you know, safely say, hey. We need to restore back to last week. You want me to click go, things like that. So with that, that's how we provide up to, what they say, a 100 times faster sort of cyber recovery. Right? There's no need for a clean room anymore to do sort of all the scanning, looking for malware, looking for threats, looking for zero days, scanning for sensitive data, determining in the determining anomalies. Right? So we also look through your snapshots as they're ingested, comparing them to the snapshot before to determine how many files have been deleted, modified, changed. Do we see signs of encryption? We can predict the type of ransomware. We can point out if we you have a ransom notes within your environment. All this stuff is done upfront from you for you before you even begin the actual recovery process. So to sort of sum up, this is kinda what it it all looks like when we put it all together. So I do wanna say underpinning the entire solution here, we have automation and APIs. We're an API first company. This is something that's near and dear to my heart. I worked in IT operations for twenty years before joining Rubrik, and I automated as much as I could. And I can say, like, having a vendor come in that actually puts dollars and resources behind actually providing APIs and SDKs and, you know, documentation around those APIs and use cases and things like that is very, very key. This is huge in the cloud world, because quite honestly, we have some some organizations that that use Rubrik to back up their cloud, but they don't ever go into our UI at all. Right? It's all driven through the console, through SDKs, through different scripts that they write. They can integrate Rubrik into your infrastructure as code plan. So if you want to onboard Rubrik, using Terraform, protect workloads while you create them with Terraform, that's all possible. Above that is that preemptive recovery engine. That's where we spent most of our time today talking about things like data security posture management, which is sort of discovering and classifying all of your data, the data threat analytics, so discovering those anomalies, searching through for those threats, looking for those zero days, and then finally, cyber recovery being able to actually contain all those threats, and set up recovery plans so you can recover easily. So this this involves things like maybe you have a handful of e c two instances that make up an application and you want one to come up first and then sort of pause and then a group of another three to come up. This is all possible through, sort of our orchestrated recovery solutions. And it all is underpinned by data protection. Right? So this is where we started. This is where we were eight years ago when I when I first joined was just data protection and APIs. So it's really all about getting the access and protecting your entire infrastructure no matter where. So whether it's enterprise, cloud, SaaS, once we have all of that data, we can start to take a look at the time series history of that. You know, we have the unique advantage of being a a data protection vendor is we're probably the only vendor in your environment that has access to all of this data and can see how it's changed over time and can start to glean insights, on top of that. Now all of this, again, is extensible. So if you have a security team, because, you know, quite often, like, this is handled sort of by your IT teams, your your your sort of operations teams, but then we start to get into a little bit of SecOps here. So some of this functionality, you know, we've had security teams ask saying they want this functionality, but they don't wanna go into rubrics. So being able to access it with things like Palo Alto Networks XSOAR, Zscaler, CrowdStrike. You know, we have in a prebuilt integrations into sort of all these different applications that your security teams are comfortable with so they can start to get sort of some of these insights that Rubrik's automatically gathering and push them out into those SIEM and SOAR tools that they're they're comfortable using. In terms of what we support with cloud, you can see AWS is, you know, far in the lead right now with with Azure coming in, you know, with a pretty close second. So it's the most standard sort of services that you see out there, like e c two, EBS, RDS, Aurora s three, EFS, EKS, things like that. Same with Azure. Again, a lot of those sort of similar services. Google Cloud, we're actually have a big push on it this year, so you'll see that little Google Cloud bubble sort of get a little bit bigger and then Oracle coming in there for, which we just announced support for, late last year. So with that, I am going to sort of welcome everyone to the actual lab now. I'm actually gonna check if there's any questions. It doesn't doesn't look like it at the moment. So like I said, the labs are gonna be a little bit different. Instead of just showing you how to onboard AWS and how to, you know, do all this stuff, We're gonna actually give you sort of a scenario. The scenario is congratulations. You've been hired at Zapper Fashion Groups as, you know, their leading cloud architect now. So you're a new hire. You've been brought in specifically because you have rubric knowledge, and you're going to help bring sort of that cyber resilience to to Zapra's infrastructure. So what you're gonna do is you're gonna walk through actually deploying and onboarding rubric into an existing AWS environment that has, workloads running in it, and then protect sort of their flagship online storefront, which is built with e c two and EKS, RDS, s three, and Dynamo. So five main services there that we're gonna need to protect. And then we'll actually, you know, simulate some sort of an attack and go through, sort of the recovery, the end to end recovery from that. So you'll see a couple of different scenarios like operational type restores, maybe a rogue script, you know, deleted some files. We'll have to restore, and then we'll walk through the actual, detection and recovery from a full fledged cyber threat, and have to restore that, that storefront, from scratch. Now just because you know? So we're gonna keep it technical here. This is kind of what the, what the application looks like. So we could see a front end's gonna, store all of the HTML files, things like that. That's basically where the website's being served up from. From there, it's going through an engine server in the back end to gather data from a Postgres database. This is what's storing all of the product information for the storefront, the product names, prices, stuff like that. Any reviews is stored in DynamoDB. Product images and branding and stuff for the site's all sitting in s three, as well as there's an EKS cluster, which does, those sort of recommendation type things such as, like, you know, if you buy this product, you might be interested in this product, things like that. So that's all handled, through an EKS cluster, and then all the different settings and stuff are in a SSM parameter store. So that's kinda what the application looks like. Without Rubrik, bringing Rubrik into the mix, you know, things change a little bit. We'll use what we call Rubrik exo compute. So when we onboard Rubrik into an AWS environment, we do get a small EKS instance that pops up. That's what does things like all the different scanning for anomaly detection and threat monitoring and all of that stuff. It's all handled by exocompute pods. A cross count role as well, that's how authentication is actually brought into the mix. We also have cloud cluster. So this is actually running some Rubrik software in your cloud environment. This is required for EKS on this case, but you don't have to really worry about that for this lab because we're not actually doing any teardown or or rebuild of EKS. But just to to let you know, to protect things like Kubernetes, we do need Rubrik nodes actually running in. Everything else is done through cloud native APIs like EC two, RDS, and stuff using exocompute. The lab itself is gonna kinda look like this. There is a little tour here if you wanna skip two different parts. And there is, you know, you can just you can you can click the actual click throughs what they want, but there is you can use your keyboard arrows as well. And just to let you know, there is, you know, a few videos, so you might want to turn your volume up. Maybe you wanna listen to me talk about sort of what the task is gonna be, and things like that. Some of them, you'll have different options. So you can see here, do you wanna onboard using the Rubrik UI, or would you like to onboard with Terraform? So there is a little bit of a a choose your own adventure, for some of these. I know, you know, I talked to lots of cloud folks that strictly sit in the UI, but then there's lots of cloud folks on, like, platform engineering teams that really wanna see our APIs and our SDKs and and things like that. So you'll have options to sort of choose your own adventure, if you will. So with that, I think I'm gonna pass it back to Hannah, and good luck. Awesome. Thanks, Mike. And that was perfect. That was right around, like, the forty minute mark. So if you guys have any questions or comments or anything, now's the time, or else we'll probably call it a little bit early. But the GuidedLab link is in the chat, so I pinned it. So it should be at the top of your box there. Please, like Mike was saying, leverage that and give us your feedback there. We'd love to see kind of what everybody's experience is. And, hopefully, you know, it's something that you guys can learn from. In terms of next steps, I think there's a couple of resources here. Mike's giving out his email. So you guys are very special for the fact that he's doing that. You guys can reach out to him. But I would also just say get in touch with our team. We'll point you in the right direction if you're interested in learning more. There'll be a follow-up email with these resources. So now it's not now or never. You're gonna get a little response from us, and then everything will be documented out for you. The session's also recorded and will be available on demand. So not your last chance to to see this either. But okay. With that being said, we'd love your feedback in the survey, and just let us know how we can improve. You know? We we live to serve. Right, Mike? That's right. Yep. That's alright. always. iterating. How long will the lab be available? Oh, that's a good question. I think it's a few days. Or is am I wrong, Mike? Yeah. As far as I know, I. I don't foresee anything removing, access to it. forever. So Oh, Oh, it needs emergency here. I think I know it's a couple days typically for. our lab, so it's not like you have to do it tonight. I would give yourself, you know, at least maybe to early next week to to complete and go through it. So not too time sensitive there. Anything else before we call it, folks? Thank you, Hector. Alright. Well, I guess that's it. Appreciate everybody, and until next time.