(upbeat music) >> Okay, we're back covering AWS Storage Day 2022 with Ashish Palekar. Who's the general manager of AWS EBS Snapshot and Edge and Cami Tavares. Who's the head of product at Amazon EBS. Thanks for coming back in theCube guys. Great to see you again. >> Great to see you as well, Dave. >> Great to see you, Dave. Ashish, we've been hearing a lot today about companies all kinds of applications to the cloud and AWS and using their data in new ways. Resiliency is always top of mind for companies when they think about just generally their workloads and specifically the clouds. How should they think about customers think about data resiliency? >> Yeah, when we think about data resiliency it's all about making sure that your application data, the data that your application needs is available when it needs it. It's really the ability for your workload to mitigate disruptions or recover from them. And to build that resilient architecture you really need to understand what kinds of disruptions your applications can experience. How broad the impact of those disruptions is, and then how quickly you need to recover. And a lot of this is a function of what the application does, how critical it is. And the thing that we constantly tell customers is, this works differently in the cloud than it does in a traditional on-premises environment. >> What's different about the cloud versus on-prem? Can you explain how it's different? >> Yeah, let me start with a video on-premises one. And in the on-premises one, building resilient architectures is really the customer's responsibility, and it's very challenging. You'll start thinking about what your single points of failure are. To avoid those, you have to build in redundancy, you might build in replication as an example for storage and doing this now means you have to have provision more hardware. And depending on what your availability requirements are, you may even have to start looking for multiple data centers, some in the same regions, some in different geographical locations. And you have to ensure that you're fully automated, so that your recovery processes can take place. And as you can see that's a lot of owners being placed on the customer. One other thing that we hear about is really elasticity and how elasticity plays into the resiliency for applications. As an example, if you experience a sudden spike in workloads, in a on-premises environment, that can lead to resource saturation. And so really you have two choices. One is to sort of throttle the workload and experience resiliency, or your second option becomes buying additional hardware and securing more capacity and keeping it fair low in case of experiencing such a spike. And so your two propositions that are either experiencing resiliency, challenges or paying really to have infrastructure that's lying around. And both of those are different really when you start thinking about the cloud. >> Yeah, there's a third option too, which is lose data, which is not an option. Go ahead- >> Which is not, yeah, I pretty much as a storage person, that is not an option. The reason about that that we think is reasonable for customers to take. The big contrast in the cloud really comes with how we think about capacity. And fundamentally the the cloud gives you that access to capacity so you are not managing that capacity. The infrastructure complexity and the cost associated with that are also just a function of how infrastructure is built really in the cloud. But all of that really starts with the bedrock of how we design for avoiding single points of failure. The best way to explain this is really to start thinking about our availability zones. Typically these availability zones consist of multiple data centers, located in the same regional area to enable high throughput and low latency for applications. But the availability zones themselves are physically independent. They have independent connections to utility power, standalone backup power resources, independent mechanical services and independent network connectivity. We take availability zone independence extremely seriously, so that when customers are building the availability of their workload, they can architect using these multiple zones. And that is something that when I'm talking to customers or Tami is talking to customers, we highly encourage customers to keep in mind as they're building resiliency for their applications. >> Right, so you can have within an availability zone, you can have, you know, instantaneous, you know when you're doing it right. You've got, you've captured that data and you can asynchronously move to outside of that in case there's, the very low probability, but it does happen, you get some disasters. You're minimizing that RPO. And I don't have to worry about that as a customer and figuring out how to do three site data centers. >> That's right. Like that even further, now imagine if you're expanding globally. All those things that we described about like creating new footprint and creating a new region and finding new data centers. As a customer in an on-premises environment, you take that on yourself. Whereas with AWS, because of our global presence, you can expand to a region and bring those same operational characteristics to those environments. And so again, bringing resiliency as you're thinking about expanding your workload, that's another benefit that you get from using the availability zone region architecture that AWS has. >> And as Charles Phillips, former CEO of Infor said, "Friends, don't let friends build data center," so I don't have to worry about building the data center. Let's bring Cami into the discussion here. Cami, think about elastic block storage, it gives, you know customers, you get persistent block storage for EC2 instances. So it's foundational for any mission critical or business critical application that you're building on AWS. How do you think about data resiliency in EBS specifically? I always ask the question, what happens if something goes wrong? So how should we think about data resiliency in EBS specifically? >> Yeah, you're right Dave, block storage is a really foundational piece. When we talk to customers about building in the cloud or moving an application to the cloud, and data resiliency is something that comes up all the time. And with EBS, you know EBS is a very large distributed system with many components. And we put a lot of thought and effort to build resiliency into EBS. So we design those components to operate and fail independently. So when customers create an EBS volume for example, we'll automatically choose the best storage nodes to address the failure domain and the data protection strategy for each of our different volume types. And part of our resiliency strategy also includes separating what we call a volume life cycle control plane. Which are things like creating a volume, or attaching a volume to an EC2 instance. So we separate that control plane, from the storage data plane, which includes all the components that are responsible for serving IO to your instance, and then persisting it to durable media. So what that means is once a volume is created and attached to the instance, the operations on that volume they're independent from the control point function. So even in the case of an infrastructure event, like a power issue, for example, you can recreate an EBS volume from a snapshot. And speaking of snapshots, that's the other core pillar of resiliency in EBS. Snapshots are point in time copies of EBS volumes that would store in S3. And snapshots are actually a regional service. And that means internally we use multiple of the availability zones that Ashish was talking about to replicate your data so that the snapshots can withstand the failure of an availability zone. And so thanks to that availability zone independence, and then this builtin component independence, customers can use that snapshot and recreate an EBS following another AZO or even in another region if they need to. >> Great so, okay, so you touched on some of the things EBS does to build resiliency into the service. Now thinking about over your right shoulders, you know, Joan Deviva, so what can organizations do to build more resilience into their applications on EBS so they can enjoy life without anxiety? >> (laughs) That is a great question. Also something that we love to talk to customers about. And the core thing to think about here is that we don't believe in a one size fits all approach. And so what we are doing in EBS is we give customers different tools so that they can design a resiliency strategy that is custom tailored for their data. And so to do this, this resiliency assessment, you have to think about the context of this specific workload and ask questions like what other critical services depend on this data and what will break if this data's not available and how long can can those systems withstand that, for example. And so the most important step I'll mention it again, snapshots, that is a very important step in a recovery plan. Make sure you have a backup of your data. And so we actually recommend that customers take the snapshots at least daily. And we have features that make that easier for you. For example, Data Lifecycle Manager which is a feature that is entirely free. It allows you to create backup policies, and then you can automate the process of creating the snapshot, so it's very low effort. And then when you want to use that backup to recreate a volume, we have a feature called Fast Snapshot Restore, that can expedite the creation of the volume. So if you have a more, you know a shorter recovery time objective you can use that feature to expedite the recovery process. So that's backup. And then the other pillar we talked to customers about is data replication. Just another very important step when you're thinking about your resiliency and your recovery plans. So with EBS, you can use replication tools that work at the level of the operating system. So that's something like DRBD for example. Or you can use AWS Elastic Disaster Recovery, and that will replicate your data across availability zones or nearby regions too. So we talked about backup and replication, and then the last topic that we recommend customers think about is having a workload monitoring solution in place. And you can do that in EBS, using cloud watch metrics. So you can monitor the health of your EBS volume using those metrics. We have a lot of tips in our documentation on how to measure that performance. And then you can use those performance metrics as triggers for automated recovery workflows that you can build using tools like auto scaling groups for example. >> Great, thank you for that advice. Just quick follow up. So you mentioned your recommendation, at least daily, what kind of granularity, if I want to compress my RPO can I go at a more granular level? >> Yes, you can go more granular and you can use again the daily lifecycle manager to define those policies. >> Great, thank you. Before we go, I want to just quickly cover what's new with EBS. Ashish, maybe you could talk about, I understand you've got something new today. You've got an announcement, take us through that. >> Yeah, thanks for checking in and I'm so glad you asked. We talked about how snapshots help resilience and are a critical part of building resilient architectures. So customers like the simplicity of backing up their EC2 instances, using multi volume snapshots. And what they're looking for is the ability to back up only to exclude specific volumes from the backup, especially those that don't need backup. So think of applications that have cash data, or applications that have temporary data that really doesn't need backup. So today we are adding a new parameter to the create snapshots API, which creates a crash consistent set of snapshots for volumes attached to an EC2 instance. Where customers can now exclude specific volumes from an instance backup. So customers using data life cycle manager that can be touched on, can automate their backups. And again they also get to exclude these specific volumes. So really the feature is not just about convenience, but it's also to help customers save on cost. As many of these customers are managing tens of thousands of snapshots. And so we want to make sure they can take it at the granularity that they need it. So super happy to bring that into the hands of customers as well. >> Yeah, that's a nice option. Okay, Ashish, Cami thank you so much for coming back in theCube, helping us learn about what's new and what's cool and EBS, appreciate your time. >> Thank you for having us Dave. >> Thank you for having us Dave. >> You're very welcome now, if you want to learn more about EBS resilience, stay right here because coming up, we've got a session which is a deep dive on protecting mission critical workloads with Amazon EBS. Stay right there, you're watching theCube's coverage of AWS Storage Day 2022. (calm music)

(upbeat music) >> Welcome back to theCUBE's continuous coverage of AWS storage day. My name is Dave Vellante and we're here from Seattle. And we're going to look at the really hard workloads, those business and mission critical workloads, the most sensitive data. They're harder to move to the cloud. They're hardened. They have a lot of technical debt. And the blocker in some cases has been storage. Ashish Palekar is here. He's the general manager of EBS snapshots, and he's joined by Cami Tavares who's a senior manager of product management for Amazon EBS. Folks, good to see you. >> Ashish: Good to see you again Dave. >> Dave: Okay, nice to see you again Ashish So first of all, let's start with EBS. People might not be familiar. Everybody knows about S3 is famous, but how are customers using EBS? What do we need to know? >> Yeah, it's super important to get the basics, right? Right, yeah. We have a pretty broad storage portfolio. You talked about S3 and S3 glacier, which are an object and object and archival storage. We have EFS and FSX that cover the file site, and then you have a whole host of data transfer services. Now, when we think about block, we think of a really four things. We think about EBS, which is the system storage for EC2 volumes. When we think about snapshots, which is backups for EBS volumes. Then we think about instant storage, which is really a storage that's directly attached to an instance and manages and then its life cycle is similar to that of an instance. Last but not the least, data services. So things like our elastic volumes capability of fast snapshot restore. So the answer to your question really is EBS is persistent storage for EC2 volumes. So if you've used EC2 instances, you'll likely use EBS volumes. They service boot volumes and they service data volumes, and really cover a wide gamut of workloads from relational databases, no SQL databases, file streaming, media and coding. It really covers the gamut of workloads. >> Dave: So when I heard SAN in the cloud, I laughed out loud. I said, oh, because I could think about a box, a bunch of switches and this complicated network, and then you're turning it into an API. I was like, okay. So you've made some announcements that support SAN in the cloud. What, what can you tell us about? >> Ashish: Yeah, So SANs and for customers and storage, those are storage area networks, really our external arrays that customers buy and connect their performance critical and mission critical workloads. With block storage and with EBS, we got a bunch of customers that came to us and said, I'm thinking about moving those kinds of workloads to the cloud. What do you have? And really what they're looking for and what they were looking for is performance availability and durability characteristics that they would get from their traditional SANs on premises. And so that's what the team embarked on and what we launched at reinvent and then at GEd in July is IO2 block express. And what IO2 block express does is it's a complete ground app, really the invention of our storage product offering and gives customers the same availability, durability, and performance characteristics that can, we'll go into little later about that they're used to in their on premises. The other thing that we realized is that it's not just enough to have a volume. You need an instance that can drive that kind of throughput and IOPS. And so coupled with our trends in EC2 we launched our R5b that now triples the amount of IOPS and throughput that you can get from a single instance to EBS storage. So when you couple the sub millisecond latency, the capacity and the performance that you get from IO2 block express with R5b, what we hear from customers is that gives them enough of the performance availability characteristics and durability characteristics to move their workloads from on premises, into the cloud, for the mission critical and business critical apps. >> Dave: Thank you for that. So Cami when I, if I think about how the prevailing way in which storage works, I drop off a box at the loading dock and then I really don't know what happens. There may be a service organization that's maybe more intimate with the customer, but I don't really see the innovations and the use cases that are applied clouds, different. You know, you live it every day. So you guys always talk about customer inspired innovation. So what are you seeing in terms of how people are using this capability and what innovations they're driving? >> Cami: Yeah, so I think when we look at the EBS portfolio and this, the evolution over the years, you can really see that it was driven by customer need and we have different volume types and they have very specific performance characteristics, and they're built to meet these unique needs of customer workloads. So I'll tell you a little bit about some of our specific volume types to kind of illustrate this evolution over the years. So starting with our general purpose volumes, we have many customers that are using these volumes today. They really are looking for high performance at a low cost, and you have all kinds of transactional workloads and low-latency interactive applications and boot volumes, as Ashish mentioned. And they tell us, the customer is using these general purpose volumes, they tell us that they really like this balanced cost and performance. And customers also told us, listen, I have these more demanding applications that need higher performance. I need more IOPS, more throughput. And so looking at that customer need, we were really talking about these IO intensive applications like SAP HANA and Oracle and databases that require just higher durability. And so we looked at that customer feedback and we launched our provisioned IOPS IO2 volume. And with that volume, you get five nines of durability and four times the IOPS that you would get with general purpose volumes. So it's a really compelling offering. Again, customers came to us and said, this is great. I need more performance, I need more IOPS, more throughput, more storage than I can get with a single IO2 volume. And so these were talking about, you mentioned mission critical applications, SAP HANA, Oracle, and what we saw customers doing often is they were striping together multiple IO2 volumes to get the maximum performance, but very quickly with the most demanding applications, it got to a point where we have more IO2 volumes that you want to manage. And so we took that feedback to heart and we completely reinvented the underlying EBS hardware and the software and networking stacks. And we'll launched block express. With block express, you can get four times the IOPS throughput and storage that you would get with a single io2 volume. So it's a really compelling offering for customers. >> Dave: If I had to go back and ask you, what was the catalyst, what was the sort of business climate that really drove the decision here. Was that people were just sort of fed up with you know, I'll use the phrase, the undifferentiated, heavy lifting around SAN, what was it, was it COVID driven? What was the climate? >> You know, it's important to recognize when we are talking about business climate today, every business is a data business and block storage is really a foundational part of that. And so with SAN in the cloud specifically, we have seen enterprises for several years, buying these traditional hardware arrays for on premises SANs. And it's a very expensive investment. Just this year alone, they're spending over $22 billion on SANs. And with this old model on premises SANs, you would probably spend a lot of time doing this upfront capacity planning, trying to figure out how much storage you might need. And in the end, you'd probably end up overbuying for peak demand because you really don't want to get stuck, not having what you need to scale your business. And so now with block express, you don't have to do that anymore. You pay for what you need today, and then you can increase your storage as your business needs change. So that's cost and cost is a very important factor. But really when we're talking to customers and enterprises that are looking for SAN in the cloud, the number one reason that they want to move to the cloud with their SANs and these mission, critical workloads is agility and speed. And it's really transformational for businesses to be able to change the customer experience for their customers and innovate at a much faster pace. And so with the block express product, you get to do that much faster. You can go from an idea to an implementation orders of magnitude faster. Whereas before if you had these workloads on premises, it would take you several weeks just to get the hardware. And then you have to build all this surrounding infrastructure to get it up and running. Now, you don't have to do that anymore. You get your storage in minutes, and if you change your mind, if your business needs change, if your workloads change, you can modify your EBS volume types without interrupting your workload. >> Dave: Thank you for that. So Cami kind of addressed some of this, but I know store admins say, don't touch my SAN, I'm not moving it. This is a big decision for a lot of people. So kind of a two-part question, you know, why now, what do people need to know? And give us the north star close it out with, with where you see the future. >> Ashish: Yeah, so let's, I'll kick things off and then Cami, do jump in. So first of the volume is one part of the story, right? And with IO2 block express, I think we've given customers an extremely compelling offering to go build their mission critical and business critical applications on. We talked about the instance type R5b in terms of giving that instance level performance, but all this is on the foundation of AWS in terms of availability zones and regions. So you think about the constructs and we talk them in terms of building blocks, but our building blocks are really availability zones and regions. And that gives you that core availability infrastructure that you need to build your mission critical and business critical applications. You then take layer on top of that our regional footprint, right. And now you can spin up those workloads globally, if you need to. And then last but not the least, once you're in AWS, you have access to other services. Be it AI, be it ML, be it our relational database services that you can start to think about undifferentiated, heavy lifting. So really you get the smorgasbord really from the availability footprint to global footprint and all the way up to sort of our service stack that you get access to. >> Dave: So that's really thinking out of the box. We're out of time. Cami we'll give you the last word. >> Cami: I just want to say, if you want to learn more about EBS, there's a deep dive session with our principal engineer, Marc Olson later today. So definitely join that. >> Dave: Folks, thanks so much for coming to theCUBE. (in chorus )Thank you. >> Thank you for watching. Keep it right there for more great content from AWS storage day from Seattle.

>>This is Dave Violante. We're here at a W s with the Keep talking About Storage palate cars. Here is the director of product management for E B s Elastic block storage. Welcome. Good to see again. >>Nice to see it. If >>so, let's talk about E b s. You know, it all started with us. Three and course customers demand Maur. What do we need to know about E b s? Like, what are the options that you provide? Give us the late low down. >>Yeah. So the way to think about block storage in the AWS eight abreast constructors. Really two kinds of offerings. One is around instant storage, which is a form of block strategy. And then you have a block started service, which is E. B s Andi. Sort of. The key thing they're from customer standpoint of different shit between the two is if you warn your storage like cycle to be coincident with your instance like cycle, then you use instant surgeon. That's why we see a lot of our customers using since storage, because they won't want that experience if you want. On the other hand, it's storage life cycle that's different from your instance life cycle. So the ability to change instances, the ability to grow size is the ability to to take back ups. Then you want to choose the obvious experience. And there we have a series of volume types that customers can consume. Be a GP two we have, I want. We have our stream volumes, which are a C one and C one. >>So she's when you talk to customers of block stores. What did they tell you that they most care about? >>Yeah, uh, it is. It is a Lord around performance. It is a lot around. Availability is a lot on your ability. He's a fuse. Those of the core characteristics that that customers care about earlier this year as an example, one of the things that we launched for customers was the ability to encrypt their volumes by default on you. Say, Well, why is that important? So security becomes a big concern for customers a day as they think about their environment and with encryption by default. We just made it simple. With a single setting, you can now, at an account level, ensure that all your PBS volumes created from that point on our fully encrypted. >>Okay, let's talk about snapshots. So how o r r. Snapshots in the cloud? Different. And how are your customers using stamps? >>Yeah, that's great. Great. Great. Cigarette in tow. Common conversation. Customers who are coming from on premises environment are used to snapshots is being sort of this copy on right type attack volumes. The way to think about aws snapshot. Devious snapshots in particular are really to think of them as backup. And so that is the one sort of key thing that I always tell customers is to think of what we call snapshots, really as backups. Especially if you're coming from a non premises environment. >>Okay, um, how about things you're doing to really improve? Uh, EBS snapshots. I mean, is it more performance? Is it making simple Are expanding use cases. Yeah. >>Yeah. Let's talk about the use case scenario Is that that snapshots get use, and snapshots are really the underlying storage for water called Amazon machine images. Our aim eyes. That is how snaps that is, how our instances boot. That is also the way that customers create CBS Williams from, so you can create an obvious volume from a snapshot. So on that on that particular use case, one of the things that we're we're now launching is a capability via calling far snapshot restored. So you can now take a knee, be a snapshot and then within an availability is soon. Make it such that you can. You can now launch volumes from it without encountering any Leighton sing and back on DDE. That we think is a tremendously powerful capability for customs. Because if you can, it takes away all the undifferentiated heavy lifting that they had to do in order to lure the data from the snapshot into the volume completely out of the picture and allows them to focus on getting their data to their applications. That's right. >>All right, we'll give you the last word. Final thoughts on the innovations that you had. Congratulations on all the hard work. >>No, actually, this is the team has done a tremendous amount of work in art launches. Couldn't be happier to see this in the hands of customers. We look forward to seeing what they build from from the things that we provided them so excited to see that happen. >>That's actually quite amazing. It started all very simple with us three. And now we've seen service is just become more granular. Higher performance. Really meeting customer demands. She's thanks so much. Thank you so much. All right. Thanks for watching. Your body will be back right after this short break.