 Hi everybody, this is Dave Vellante with theCUBE and welcome to Boston. We're covering storage here at Amazon Storage Day and we're looking at all the innovations and the expansion of Amazon's pretty vast storage portfolio. Duncan Lennox is here, he's the Director of Product Management for Amazon EFS. Duncan, good to see you. It's great to be here. So EFS stands for Elastic File System. What is Amazon EFS? That's right, EFS is our NFS based file system service designed to make it super easy for customers to get up and running with the file system in the cloud. So should we think of this as kind of on-prem file services just stuck into the cloud or is it more than that? It's more than that, but it's definitely designed to enable that. We wanted to make it really easy for customers to take the on-prem applications that they have today that depend on a file system and move those into the cloud. When you look at the macro trends, particularly as it relates to file services, what are customers telling you? Well, the first thing that we see is that it's still very early in the move to the cloud. The vast majority of workloads are still running on-prem and customers need easy ways to move those thousands of applications they might have into the cloud without having to necessarily rewrite them to take advantage of cloud native services. And that's a key thing that we built EFS for to make it easy to just pick up the application and drop it into the cloud without the application even needing to know that it's now running in the cloud. Okay, so that's transparent to the application and the workload. It absolutely is. We built it deliberately using NFS so that the application wouldn't even need to know that it's now running in the cloud. And we also built it to be elastic and simple for the same reason. So customers don't have to worry about provisioning the storage they need. It just works. NFS is hard. Making NFS simple and elastic is not a trivial engineering task, is it? It hadn't been done until we did it. A lot of people said it couldn't be done. How could you make something that truly was elastic in the cloud but still support the NFS? But we've been able to do that for tens of thousands of customers successfully. And what's the real challenge there? Is it to maintain that performance and the recoverability from a technical standpoint and engineering standpoint? Yeah, it's all of the above. People expect a certain level of performance, whether that's latency, throughput and IOPS that their application is dependent on. But they also want to be able to take advantage of that pay as you go cloud model that AWS created back with S3 13 years ago. So that elasticity that we offer to customers means they don't have to worry about CAPEX. They don't have to plan for exactly how much storage they need to provision. The file system grows and shrinks as they add and remove data. They pay only for what they're using and we handle all the heavy lifting for them to make that happen. This opens up a huge new set of workloads for your customers, doesn't it? It absolutely does. And a big part of what we see is customers wanting to go on that journey through the cloud. So initially they're starting with lifting and shifting those applications as we talked about it. But as they mature, they want to be able to take advantage of newer technologies like containerization and ultimately even serverless. All right, let's talk about EFS IA. Infrequently accessed files is really what it's designed for. Tell us more about it. Right, so one of the things that we heard a lot from our customers of course is can you make it cheaper? We love it, but we'd like to use more of it. And what we discovered is that we could develop this infrequent access storage class. And how it works is you turn on a capability we call life cycle management and it's completely automated after that. So we know from industry analysts and from talking to customers that the majority of data, perhaps as much as 80%, goes pretty cold after about a month and it's rarely touched again. So we develop the infrequent access storage class to take advantage of that. So once you enable it, which is a single click in the console or one API call, you pick a policy, 14 days, 30 days. And we monitor the read-write IO to every file individually. And once a file hasn't been read from or written to in that policy period, say 30 days, we automatically and transparently move it to the infrequent access storage class, which is 92% cheaper than our standard storage class. It's only two and a half cents in our US East One region as opposed to 30 cents for our standard storage class. Two and a half cents per gigabyte per month? Per gigabyte month. Things we've done for customers that we're particularly excited about is that it remains active file system data. So we move your file to the infrequent access storage class, but it does not appear to move in the file system. So for your applications and your users, it's the same file in the same directory. So they don't even need to be aware of the fact that it's now on the infrequent access storage class. You just get a bill that's 92% cheaper for storage for that file. I was like that. Okay, and it's simple to set up. You said it's one click and then I set my policy and I can go back and change my policy. That's exactly right. We have multiple policies available. You can change it later. You can turn off lifecycle management if you decide you no longer need it later. So how do you see customers taking advantage of this? What do you expect the adoption to be like and what are you hearing from them? Well, what we heard from customers was that they'd like to keep larger workloads in their file systems, but because the data tends to go cold and isn't frequently accessed, it didn't make economic sense to say to keep large amounts of data in our standard storage class, but there's advantages to them in their businesses. For example, we've got customers who are doing genomic sequencing and for them to have a larger set of data always available to their applications, but not costing them as much as it was, allows them to get more results faster as one example. You obviously see that. Yeah, what we're trying to do all the time is help our customers be able to focus less on the infrastructure and the heavy lifting and more on being able to innovate faster for their customer. So Duncan, some of the sort of fundamental capabilities of EFS include high availability and durability. Tell us more about that. Yeah, when we were developing EFS, we heard a lot from customers that they really wanted higher levels of durability and availability than they'd typically been able to have on-prem. It's super expensive and complex to build high availability and high durability solutions. So we've baked that in as a standard part of EFS. So when a file is written to an EFS file system and that acknowledgement is received back by the client, at that point the data is already spread across three availability zones for both availability and durability. What that means is not only are you extremely unlikely to ever lose any data, if one of those AZs goes down or becomes unavailable for some reason to your application, you continue to have full read-write access to your file system from the other two availability zones. So traditionally, this would be a very expensive proposition to do sort of on-prem and multiple data centers. Maybe talk about how it's different in the cloud. Yeah, it's complex to build. There's a lot of moving parts involved in it because in our case with three availability zones, you're talking about three physically distinct data centers, high-speed networking between those and actually moving the data so that it's written not just to one, but to all three. And we handle that all transparently under the hood in EFS. It's all included in our standard storage tier cost as well. So it's not something that customers have to worry about for either a complexity or a cost point of view. So very, I guess low RPO and RTO, am I understanding that? Essentially zero, if you will, between the three availability zones because once your client gets that acknowledgement back, it's already durably written to the three availability zones. All right, we'll give you last word just in the world of file services. What should we be paying attention to? What kinds of things are you really trying to achieve? I think it's helping people do more for less faster. So there's always more we can do and helping them take advantage of all the services AWS has to offer. Spoken like a true Amazonian. Duncan, thanks so much for coming on theCUBE. Thank you. I appreciate it. All right, and thank you for watching. Everybody will be back from Storage Day in Boston. You're watching theCUBE.