How to leverage Cloud Storage on AWS (PART ONE)

Jon Spallone of XenTegra and Brian Schoepfle of AWS discuss  Cloud Storage on AWS. This episode part one where we breakdown what is offered in AWS object, file, & block storage, and  how this benefits you in your cloud architecture.

Topics we'll discuss are: 

• AWS storage services
  • Object, file, and block storage
    • Amazon Simple Storage Service (S3)
    • Amazon Elastic File System (EFS)
    • Amazon FSx
    • Amazon Elastic Block Store (EBS)

This episode is PART ONE

Host: Jon Spallone
Co-Host: Brian Schoepfle

Transcript

WEBVTT

1
00:00:04.770 --> 00:00:24.270
Jon Spallone: And welcome everybody to another episode of in the clouds with Aws Brian's here with us again today. We've got a pretty interesting topic. We're going to talk to you about. We're going to cover storage with any of the aws you can see my screen that I've got up here. This is where we're going to focus our conversation kind of

2
00:00:24.280 --> 00:00:35.019
Jon Spallone: and understanding the different types of sword jobs and options that are out there from Aws. How those fit in from a migration standpoint. You know what what is a benefit

3
00:00:35.030 --> 00:00:52.959
Jon Spallone: to infrastructure deployments, and you know, overall some features and functionality that may not be aware of or see a benefit for in your environment. So you know, Brian again, I want to thank you being with us again this week. As we go through this discussion.

4
00:00:53.060 --> 00:00:55.099
Brian Schoepfle: Yes, thanks, John. It's great to be here.

5
00:00:55.180 --> 00:01:02.749
Jon Spallone: It so really. I mean, we've got multiple options. Now you know those of you that are not familiar with the cloud.

6
00:01:02.760 --> 00:01:27.540
Jon Spallone: There are native storage options within cloud providers that allow me to eliminate some services or take different utilization of those storage offerings, as far as it's concerned, within, you know, sharing your vms or doing database, housing or migrations, Drs. Or you know, just putting another drive to a server. So let's get into it.

7
00:01:27.550 --> 00:01:43.219
Jon Spallone: We've got our particular areas of storage, and I figure we'll just kind of step through them right? Um. So you know, for stuff. We got the simple storage, the s three. So I mean, it sounds pretty pretty explanatory. There it's simple storage. It's just what we're providing.

8
00:01:43.230 --> 00:01:56.329
Brian Schoepfle: Yeah, so Amazon s three right? This is the og of of Storage, and I think you know what a lot of people, especially, you know, in

9
00:01:56.340 --> 00:02:15.900
Brian Schoepfle: in the in the middle part of the previous decade, as they were looking at. What are some early cloud use? Cases like cloud storage is one of the first things that that comes to folks, and you know, probably you know, we go through kind of the history of history, and why customers love it so much.

10
00:02:16.010 --> 00:02:37.629
Brian Schoepfle: I I hesitate. I hesitate to like, speak in superlatives or things like that. But I've I've heard people. The third party is much smarter than me. Describe it this way. So so i'll describe it this way as well is. This is basically infinite storage. Right? Is, you know, for for nearly every customer that's out there, or or that somebody that's considering this

11
00:02:37.640 --> 00:03:05.000
Brian Schoepfle: a aws can really add disks to s three faster than anybody can put data into. It. So this is. This is object-based storage, so different from the file and black technologies that we'll get into later. And Um, you know, as I said, was was one of the was one of the original kind of Aws services, and this web available storage is great for so many different things. The classic use cases are,

12
00:03:05.010 --> 00:03:34.689
Brian Schoepfle: you know, static media files to get to get that off of disk attached to a virtual machine. Um! This is, you know, you know, massively redundant. Ah, eleven nines of durability. Um, in that case, so I I think it's like you got a better chance of winning the lottery and getting attacked by a shark and getting struck by lightning at the same time. That, then Aws is going to is going to lose data that's that's been stored in s three.

13
00:03:34.760 --> 00:03:40.370
Brian Schoepfle: So it's it's it's globally accessible,

14
00:03:40.380 --> 00:04:09.609
Brian Schoepfle: and uh and also very secure storage as Well, so that we've We've added a lot of features uh bucket policies object-level policies. Um, we've We've added uh endpoints inside of a virtual private cloud, or the Amazon Vpc: so that, uh data that's stored in, you know, would technically be considered the public space. The public zone of Aws, which is S. Three, can only be accessible from within the Vpc. We put a cloud front as a content delivery network

15
00:04:09.620 --> 00:04:39.179
Brian Schoepfle: platform distribution, and in front of that we can. We can create signed urls, make cloud from a trusted signer, and and there are many customers that use s three for its ability to host static websites as well. So um. And then, you know, speaking to the redundancy of it, the durability of it, The availability of it and security of it is S. Three is where your your logs from aws, your cloud trail logs reside, and when we turn on

16
00:04:39.190 --> 00:04:57.240
Brian Schoepfle: trail, log, file, integrity, validation. We turn on object versioning inside of s three. We've made it so. If anybody's attempting to tamper with our log files. We'll instantly know, because once we change the metadata of the underlying data that's being stored, a new object is being created.

17
00:04:57.250 --> 00:05:04.079
Brian Schoepfle: So this is given customers, lots of great fast, secure, highly available ways to store all different types of data,

18
00:05:04.100 --> 00:05:09.499
Jon Spallone: so as far as integration and i'm taking my approach from the

19
00:05:09.540 --> 00:05:22.659
Jon Spallone: coming from a Microsoft side of the house. We have ad integration. We could do from this like an ntf share, or an nfs share, or a sift share, but using this storage.

20
00:05:22.710 --> 00:05:26.089
Brian Schoepfle: So so those are our file protocols, obviously,

21
00:05:26.100 --> 00:05:45.609
Brian Schoepfle: and as we get into some of the other storage services we'll talk about how we can integrate with with active directory or or other traditional, more on premises, identity systems. But in in many cases, and as we'll get into something like Aws storage Gateway S. Three is being used as a back end for that.

22
00:05:45.620 --> 00:05:50.890
Brian Schoepfle: But authentication and authorization are happening through a different mechanism.

23
00:05:50.900 --> 00:05:56.359
Brian Schoepfle: And then, lastly, about s three one of the things that's made it so cost-effective

24
00:05:56.470 --> 00:06:14.569
Brian Schoepfle: for customers, you know. I think you know it it was two decades ago, really, that we were, you know, an an operational functional, usable tiered storage system in a on-premise environment. It was like the Holy Grail for for a storage manager. And now with.

25
00:06:14.580 --> 00:06:43.929
Brian Schoepfle: We've got, you know, your s three standard. You've got s three for infrequently accessed stuff. That's, you know. Maybe once a month we've got s three for just single a Z. Um. So this is data that you know I I could easily recover or get from somewhere else if it got lost, and I've got. I can now activate intelligent tearing inside of s three to move things from, You know the most performance, but still you know. But i'm paying a premium for that performance.

26
00:06:43.940 --> 00:06:48.669
Brian Schoepfle: The way down into glacier and Glacier Deep Archive

27
00:06:48.680 --> 00:07:16.430
Brian Schoepfle: um is is giving me lots and lots of management capabilities really automated and managed, as from the customer perspective on my behalf by Amazon, so that I don't have to worry about um. You know, provisioning different types of discs, you know. I like John. You probably remember, like we'd have like a small thin layer of of hopefully, like some two hundred gig Ssd. Drives, and then some ten K Sads drives underneath that. Then, if we'd love you, we got some

28
00:07:16.440 --> 00:07:28.060
Brian Schoepfle: seven thousand two hundred Zeta drives beneath that. I don't have to worry about the management of that at all with s three intelligence hearing, and how it integrates with all the different versions of block stores that we have.

29
00:07:28.070 --> 00:07:42.199
Brian Schoepfle: Okay? And then and then just obviously, of course, because it's simple storage. This is an offering that we see both in a commercial cloud at Aws and the dove cloud as well. So it is something that both sides of the house can take care of

30
00:07:42.210 --> 00:07:45.519
Brian Schoepfle: one hundred percent, and by virtue of the fact that

31
00:07:45.580 --> 00:07:53.830
Brian Schoepfle: I would hope that everybody has cloud trail logging turned on inside of their Aws account. I would venture against to say

32
00:07:54.520 --> 00:08:01.420
Brian Schoepfle: the the the percentage of Aws customers who are not using s three in some capacity is is near zero.

33
00:08:02.130 --> 00:08:03.310
Jon Spallone: Catch him,

34
00:08:03.650 --> 00:08:04.290
Jon Spallone: Whoa,

35
00:08:04.300 --> 00:08:30.660
Brian Schoepfle: you know again, like you said, and like it explains It's a simple storage. So this is as plain Jane as we can get, as far as storage is concerned with aws. So we take a step up, and now we go into the elastic file system. Um, efs within aws. So again, this is serverless uh storage that's out there. So you know. Let's get into a little bit more data that we would handle within this type of arena.

36
00:08:30.910 --> 00:08:35.230
Brian Schoepfle: Mm-hmm So efs is great for

37
00:08:35.320 --> 00:08:36.470
Brian Schoepfle: ah

38
00:08:37.280 --> 00:08:56.040
Brian Schoepfle: it professionals really who are needing to manage a a shared file system for Linux hosts. It's it's it's multi a z from from an availability perspective, and

39
00:08:56.050 --> 00:09:10.970
Brian Schoepfle: and it integrates with with services and features like aws backup, so that I can, so that I can protect that data. But this is great for file data that's going to live within my Vpc. That my Linux hosts need to use

40
00:09:11.000 --> 00:09:33.169
Jon Spallone: Gotcha, and for those of you who don't know virtual but private cloud. Um! I just the reason I bring that up is, I have a customer we're talking to, and they're having a hard time with the terminology getting that understanding. So I like to just clear it up so it's. This is more of linux-driven type storage. So this is where we would see things

41
00:09:33.250 --> 00:09:44.290
Brian Schoepfle: from like a red hat, those types of on two types of storage models. Not really again, not really, from a Microsoft standpoint. Right?

42
00:09:44.300 --> 00:10:02.949
Brian Schoepfle: Absolutely, But some of the advantages that i'm getting as a as a customer is, I've got similar durability about eleven over nine on my data, and up to four nines of availability as an sla.

43
00:10:03.240 --> 00:10:07.819
Brian Schoepfle: I'm only paying for the storage that I use,

44
00:10:07.830 --> 00:10:25.419
Brian Schoepfle: and I I do have the ability ah, similar to S. Three to automatically move in frequently accessed files, and you'll hear me keep coming back to that, as I think one of the management headaches from an it. Perspective for a long time has been

45
00:10:25.430 --> 00:10:55.199
Brian Schoepfle: whether it's it's users or somebody else saying, you I can't delete that I can never get rid of it, and you know. And meanwhile it's a it's a forty Meg Powerpoint presentation that hasn't been opened at three years. That's that's sitting on primary storage. So with efs I've got a serverless implementation that allows me to reduce costs up to ninety two percent by automatically removing these these infrequently accessed files. So it's a great way to quickly create and configure shared files

46
00:10:55.210 --> 00:11:00.769
Brian Schoepfle: systems for for aws compute services. You know, I think probably the

47
00:11:00.780 --> 00:11:18.530
Brian Schoepfle: the most commonly our most common way I've seen this use would be on on Amazon, Ec. Two. So our elastic compute cloud Linux virtual machines. But efs can also function as a shared file system for

48
00:11:18.540 --> 00:11:33.630
Brian Schoepfle: our elastic container service Ecs. Our elastic Kubernetes service eks as well as Amazon Fargate, and and the Efs also functions as a shared storage layer for

49
00:11:33.700 --> 00:11:35.890
Brian Schoepfle: uh, many uh lambda functions. So

50
00:11:35.900 --> 00:11:43.990
Brian Schoepfle: when when serverless computing, it needs to go pull files from somewhere. Efs integrates with that greatly Gotcha.

51
00:11:44.000 --> 00:12:01.739
Jon Spallone: Um. So I mean this this again, obviously let's just handle the question. You're right up front. So we're not in it on each one, but as far as all of the storage services that aws provides. There's nothing out there that we can't get on the Gov. Cloud side of the house. Correct

52
00:12:02.880 --> 00:12:05.689
Brian Schoepfle: the best place to check

53
00:12:05.700 --> 00:12:22.589
Brian Schoepfle: on all of these things, and i'll share this with our with our listeners. Here is, There's a great place to go Find the services in scope, and and John i'll, I'll send you that link if you want to pull this page up

54
00:12:22.600 --> 00:12:29.090
Brian Schoepfle: like this is this is the best place for customers in every vertical

55
00:12:29.100 --> 00:12:42.739
Brian Schoepfle: to go check out what services are in scope for various compliance programs, and as this page loads up we'll see just a few lines down fedrant, and we can go ahead and click that

56
00:12:42.920 --> 00:12:46.389
Brian Schoepfle: because that's what we're talking. Uh. Sorry right in the chart in the middle there.

57
00:12:46.400 --> 00:12:47.490
Brian Schoepfle: Oh, I'm:

58
00:12:47.500 --> 00:12:48.939
Jon Spallone: Yeah, there we go,

59
00:12:52.230 --> 00:13:04.360
Brian Schoepfle: and if we scroll down so here's where we can see fed, rant, moderate, So that's our commercial regions in the Us. East and West, and then in the middle there. These are all of our services with a a fed ram,

60
00:13:04.370 --> 00:13:21.389
Brian Schoepfle: a high authorization, and here's where you can see It's been totally approved. It's maybe going through the Joint Authorization Board Review. It may be going through a third party assessor. But this is where you can go. Find whether or not any of these services are available in in the region that you're looking for.

61
00:13:21.400 --> 00:13:24.480
Well, that's great. So that yeah, So we got in our uh

62
00:13:25.000 --> 00:13:36.559
Jon Spallone: storage right in here that we can get to. Now this great, this great site. What i'll do is I'll make sure. I add this into our description as well. Once we get this posted so everybody can take a look for themselves.

63
00:13:37.100 --> 00:13:45.290
Brian Schoepfle: But But yeah, so far, everything that we've discussed s three. And efs yeah definitely available in

64
00:13:45.300 --> 00:14:00.189
Brian Schoepfle: Yeah, cause. And I mean, I know we're talking about storage. But just again from an understanding of when we're talking about these different levels of cloud that are out there offered. You know we obviously have our commercial. Everything comes out commercial. That's That's our leading

65
00:14:00.370 --> 00:14:16.099
Jon Spallone: cutting-edge technologies. Disruptive solutions that are out there and then we see a lag from that, because of the approval process when it goes into that Gov. Cloud just because it's got to go through. You know their checks and balances before that service can be applied. So

66
00:14:16.110 --> 00:14:23.049
Jon Spallone: you see something that's not there. Initially, it's typically on a roadmap when we're talking about cloud providers.

67
00:14:23.240 --> 00:14:31.800
Brian Schoepfle: Yeah, we're working with our sponsoring agencies and our customers to try to get that all done. But I think for many of the things that we're talking about.

68
00:14:31.810 --> 00:14:50.360
Brian Schoepfle: I and I know we're here to talk about storage. But one of the things that I've come across as a common misconception in the public sector is that because I am a government entity, I must use Aws Cup cloud, and that's whether i'm a Federal customer, or State or local. And the fact of the matter is that what we should really be looking at is does.

69
00:14:50.370 --> 00:15:07.740
Brian Schoepfle: Uh, do I have some requirement to meet fed ram high uh baselines, which you know means a lot of things. But one of the things that differentiates bed ramp high from everything else is that it's all us persons that are going to be supporting your environment, you know,

70
00:15:07.750 --> 00:15:17.399
Brian Schoepfle: doing maintenance inside of the data center, whether that's physically inside of it or we're remotely. It's all us persons. And what I found is that, like

71
00:15:17.410 --> 00:15:42.610
Brian Schoepfle: I've had schools tell me that they think they need fed ram. You know. They think they need to be in Golf cloud because they're technically the public sector agency, and that's that's not the case. That's not what God proud is for. And conversely, if you are a if you're a commercial entity, but you require um, you know I tar compliance, or you believe that it's easier to manage your hipaa Compliance with with fed ramp high baselines That aws God can be the place for you.

72
00:15:42.620 --> 00:15:44.630
Jon Spallone: Yeah, that's and it is. It's a good

73
00:15:44.640 --> 00:15:57.769
Jon Spallone: it cross-match between commercial companies and companies. Organizations that really you've got to define, and that's where my role comes into play when i'm working with my customers is really defining

74
00:15:57.780 --> 00:16:17.029
Brian Schoepfle: what it is, and where they need to fit into it. But get off our soapbox here for a little bit for the cub cloud when we get back to storage. So the one that I i'm interested in talking about is the Fsx storage offering that's out there. So this is. This is where we get into the Microsoft world. Right?

75
00:16:17.040 --> 00:16:33.579
Brian Schoepfle: Yeah. Yeah. So Fsx comes in in several different flavors. There's Fsx for luster, which I know a lot of data scientists seem to like. There's There's fss for for open Zfs, which is a really highly performance system.

76
00:16:33.590 --> 00:16:49.749
Brian Schoepfle: Uh for again Linux host, but Amazon Fsx. For windows, file, server opens up so many things that we can talk about that are just driving incredible value for customers. So

77
00:16:49.760 --> 00:17:16.970
Brian Schoepfle: uh that by sex, you know I five times, and it's vanilla flavor it's vanilla format. We talk about it as being when, as a Linux, host. Right? So this is a cifs Nfs and i'm not i'm not really doing a lot of like active directory integration or anything like that. But um, as i'm getting into this is a great hybrid cloud. Use case as well. I have a need for a managed windows File server

78
00:17:16.980 --> 00:17:28.920
Brian Schoepfle: that resides within the cloud, and it's going to start to give me some of the benefits that i'm that i'm looking for when i'm using when i'm using windows to manage my infrastructure. So

79
00:17:29.490 --> 00:17:41.119
Brian Schoepfle: we've got highly available storage for windows applications with full smb support because we've got data, d duplication and compression built into it customers are lowering their cost by nearly sixty percent.

80
00:17:41.130 --> 00:18:11.119
Brian Schoepfle: We can strengthen data protection with encryption. We've got file access auditing and we've got automatic backups inside of it. So we're presenting a a front end windows, native file system integrated right with your X Directory submissions and everything are all going to flow through. I can set up as many windows, file shares as I would need on my system, and I can establish access permissions from there, and then I can connect to my file shares, whether i'm using whether i'm connecting perhaps over a Vpn. Into my aws virtual private cloud from a remoter branch off,

81
00:18:11.130 --> 00:18:19.640
Brian Schoepfle: whether i'm accessing these file shares from window servers because the servers need them. Or maybe i'm using

82
00:18:19.650 --> 00:18:42.410
Brian Schoepfle: Ah, Amazon workspaces for remote desktop or or upstream for streaming applications. I have. I have a a managed windows file system behind me that's giving me That's It's completely native integration. There's no application that you're using, or no no server that you're running, that it's not going to look at this and think it's anything other than a windows file system.

83
00:18:42.420 --> 00:19:10.239
Jon Spallone: Yeah. So that I mean that really gets us into more of a content collaboration from a Microsoft side of the house, being able to provide these shares out there, but to be able to access it. Now. The other thing, too, is I know this is coming back to some of the stuff within my wheelhouse. This is one of the high recommendations from Aws, as well as some of the other Euc partners. Out there. We're utilizing Fs logics, which is

84
00:19:10.250 --> 00:19:27.429
Jon Spallone: to be confused. His profile management persona management for users persona. So we're decoupling that from the Os. And we're putting that into shares. So this is that type of storage that we would do because from a windows perspective we don't need to have that windows front end.

85
00:19:27.440 --> 00:19:35.920
Jon Spallone: We don't have to have that file server compute sitting in our Vpc. That we've got up there, and then we also don't need to

86
00:19:36.320 --> 00:19:43.389
Jon Spallone: really do more than just provide that share, and the actual drives themselves. It's a high performance side of the house. Correct?

87
00:19:44.100 --> 00:20:09.190
Brian Schoepfle: Yeah. So I've got. I've got consistent sub millisecond latencies from within the cluster capable of of consistently delivering multiple gigabytes per second of throughput and hundreds of thousands of I apps than a file system, and I can provide storage with with fmsx to to all of my users and systems with file systems up to sixty, four terabytes for a file system.

88
00:20:09.200 --> 00:20:16.390
Brian Schoepfle: And then, if I do need to expand beyond that, I can use Dfs namespaces to create a common namespace that would span multiple clusters that I could be creating.

89
00:20:16.900 --> 00:20:25.330
Brian Schoepfle: And then I can expand this across multiple zones within aws correct for absolutely. I made for some resiliency and high availability of it.

90
00:20:25.340 --> 00:20:26.680
Brian Schoepfle: Ah, yeah, So

91
00:20:26.690 --> 00:20:39.130
Brian Schoepfle: it's going to automatically replicate your data within an availability zone to protect it from component failure, but it offers multiasy deployment options as well. So that's going to give me

92
00:20:40.130 --> 00:20:41.790
to my data.

93
00:20:41.800 --> 00:20:52.179
Jon Spallone: So now, when we say we're eliminating that that windows file serve that tradition traditional virtual machine that we would have. That would be our front end for translation.

94
00:20:52.310 --> 00:20:55.310
We we do that

95
00:20:55.560 --> 00:20:58.789
Brian Schoepfle: eighty permission set at the

96
00:20:58.950 --> 00:21:00.800
Jon Spallone: Fs. X.

97
00:21:01.440 --> 00:21:20.790
Brian Schoepfle: That dashboard panel within our tenant when we're making up these shares, and everything is that correct? Is that that's where we're doing some connectivity to our active Directory, to be able to pull those permissions that we need to do or set those permissions that we need to on these different shares that we're providing correct.

98
00:21:20.800 --> 00:21:30.759
Brian Schoepfle: That's right from within the console or the Cli or the Sdk, I'll get all of the information that I need to join this cluster to my domain. But you know,

99
00:21:30.770 --> 00:21:59.479
Brian Schoepfle: as a managed windows file server. It's it's, I guess, a shorthand way of putting is You can do everything with it that you could with a normal windows file server, except for get into a server manager and um and work within the Os because we're managing the Os. We're patching it. We're making sure it's available. We're providing that that maintenance and that ongoing management for it, so that you just have

100
00:21:59.490 --> 00:22:08.020
Brian Schoepfle: windows file server cluster that you can connect to right is that I think most customers is not within. You know

101
00:22:08.260 --> 00:22:25.890
Brian Schoepfle: it's not within their core operating model, like their their own and customers don't derive value from how they manage their own windows file system. So this is another way of just shifting this undifferentiated management task. Stuff off to somebody who can do it. A tremendous scale like Aws

102
00:22:25.900 --> 00:22:28.079
Jon Spallone: well, and and to

103
00:22:28.440 --> 00:22:42.910
Jon Spallone: little ah shameless plug here. But our previous episode, where we discussed about being able to. Once we get migrated into the cloud, being able to eliminate some of that compute as we move along to grow, that

104
00:22:42.920 --> 00:23:12.510
Brian Schoepfle: Roi and our cloud services. This is a This is a perfect one that pretty much you could start right off the back, I mean you you can. This can be planned in your migration and eliminate You know those, the licensing requirements you need from a Microsoft that whole tax, the compute that you would have to. I mean that that is pulled off of the shoulders of your it department. So this is a good thing for people to take a look at um, and I know again coming back to the Uc. World. This is what was highly recommended is

105
00:23:12.520 --> 00:23:23.279
Jon Spallone: as deployments when we're talking about that Fs logics store for our user persona. So I just want to make sure people are aware of This is not just your typical,

106
00:23:23.300 --> 00:23:40.679
Jon Spallone: You know this is the Hr share, And this is where we're putting all of our, you know Pdf: tax ones. This is everything across the board. And oh, by the way, we have additional functionality to handle that high demand storage that we need in the environment for other things.

107
00:23:40.710 --> 00:23:41.890
Brian Schoepfle: So, Ada,

108
00:23:41.900 --> 00:24:08.200
Brian Schoepfle: you know, go through that typical like, what are some things that I can do to reduce my storage cost type stuff, and and Fsx is really putting the bill for a lot of things I can use. Magnetic disk, or I can do solid state drives. Don't. Let me optimize my costs based on the performance that I need. I'm only paying for the resources that I use. I don't have minimum commitments. There's no licensing costs for these. I'm really just being filled by the hour for the file system, and then the storage capacity and the fruit of capacity that I envision.

109
00:24:08.210 --> 00:24:23.449
Brian Schoepfle: And we mentioned the data to duplication. So thirty to fifty percent savings for user documents, seventy to eighty percent for software development data sets and then at the management level as an administrator, I'm: able to offer user photos like a monitor and control user level user level Storage Consumption,

110
00:24:23.460 --> 00:24:28.289
of course, is great in in a remote desktop world and just a file share world as well.

111
00:24:28.300 --> 00:24:52.230
Jon Spallone: And again, this is where you can start to monetize your it Department, because now, with those quotas you give the bill backs, you can do charges on that. So that again helps the technology department to be able to. This is where that cloud shifts that you know. I'm: just supporting with this is from a technology standpoint. I'm a fireman responding by a person responding to you know, whatever the event is. Now. Now, I can actually say,

112
00:24:52.240 --> 00:25:04.240
Brian Schoepfle: You know these services are monetized, and you're paying back for us as you expand it. So this really helps an organization to look differently at the cloud. So yeah, I mean, that's a very good thing.

113
00:25:04.250 --> 00:25:22.430
Brian Schoepfle: So there's one other aspect of that that we haven't really talked about. And you know, last time we were talking about migrations we were talking about when we're doing assessments correctly, and we're understanding how many cores we're actually going to need, we can see a real significant reduction

114
00:25:22.440 --> 00:25:34.099
Brian Schoepfle: um in our licensing costs and and many customers out there that are running. Microsoft, Sql. Workloads are are faced with the choice of

115
00:25:34.110 --> 00:25:47.540
Brian Schoepfle: having a failover cluster, which, from a licensing perspective, is much more advantageous or or having these always on availability groups the the failover cluster within. Let's say,

116
00:25:47.550 --> 00:26:08.260
Brian Schoepfle: take to the on- we're in a single data center is a typically a little bit easier to manage because it's difficult for shared file systems to span across multiple data centers. So where I might like to use that failover cluster to get that that licensing advantage I end up using sql server enterprise.

117
00:26:08.270 --> 00:26:25.200
Brian Schoepfle: Ah! And and having these always on availability groups so that I can have continuous availability. Ah, for my ah! For sql server! But with ah with fsx for windows, file, server as the shared storage layer for

118
00:26:25.210 --> 00:26:39.589
Brian Schoepfle: Sql. Server Instances running on Ec. Two. I'm. Now creating a multi A. Z shared storage layer which allows me to put my failover cluster in a different availability zone.

119
00:26:39.600 --> 00:26:56.279
Brian Schoepfle: And and I'm, seeing, you know, potentially a fifty percent reduction in my Sql Server licensing costs while getting the same very similar level of availability as sql server enterprise, and because of

120
00:26:56.290 --> 00:27:11.389
Brian Schoepfle: because of the native integration, with windows with windows file, Ah, Server, and and with with sql and window server in General, you know Microsoft is an absolutely first-class citizen on aws. This is really simplifying data database migrations into aws.

121
00:27:11.400 --> 00:27:22.580
Jon Spallone: That's great. I mean again, that cost savings there, and I do. You know, we work with sequel a lot. So yeah, there's always trying to plan, and customers are always trying to evaluate

122
00:27:22.590 --> 00:27:44.389
Jon Spallone: from a licensing perspective, you know. Do I go to the always Availability group? Do I go to um, you know, just doing a mirror or a cluster, and it comes down to cost. So this is something that definitely is is a cost savings. But you're still getting the advantages of that replication on the back end that you need for high availability.

123
00:27:44.400 --> 00:27:59.160
Brian Schoepfle: Yeah, Because because fsx for windows, file server supports continuously available file shares, I can provide highly available shared file storage to clusters across multiple availability zone, which is something that would be very, very difficult to manage in an on-prem. World.

124
00:27:59.170 --> 00:28:10.409
Brian Schoepfle: Yeah, now, that's that's great. So I want to go back here as well. Is it? Was there anything else in particular on the window side that you see that we

125
00:28:10.420 --> 00:28:17.689
Brian Schoepfle: um not for the windows side. But I definitely don't want to move on from Fsx just because we haven't talked about Fsx for Netflix.

126
00:28:17.700 --> 00:28:21.510
Brian Schoepfle: Yes, yes, I'm very familiar with that one as well.

127
00:28:21.810 --> 00:28:27.960
Yeah. So how are I? I'm: curious to know. How are you seeing Fsx for ontat being here?

128
00:28:27.970 --> 00:28:56.039
Jon Spallone: Um. So we have a project where that we work with one of our customers, and we did the on-tap setup from their data center that they have we have the replication going across to their tenant where we've put workloads to be able to expand across both that environment. It's worked so well for the customer that we're now putting in a direct connect. We're now expanding more certain footprints into the environment, and they're now taking a look at that second phase of

129
00:28:56.050 --> 00:29:02.510
Jon Spallone: how do I increase that Roi, by eliminating the front end on the Microsoft boxes.

130
00:29:02.520 --> 00:29:20.280
Jon Spallone: So they have their Vmware clusters sitting in a data center. That's where we're doing our connections here on tap, and we're we're doing a replication across the board from their on-prem into the cloud to where they're eventually going to move that transition to full

131
00:29:20.620 --> 00:29:24.219
Jon Spallone: operations within their aws. Tenant.

132
00:29:24.960 --> 00:29:36.009
Brian Schoepfle: That's that's That's absolutely a great use case. So we launched Fsx for netf on tab about a year ago. It recently became generally available.

133
00:29:36.670 --> 00:29:38.699
Brian Schoepfle: Ah, but you know, with

134
00:29:39.300 --> 00:29:56.240
Brian Schoepfle: you know, we can talk about like how much it scales up, to which I, you know, which is in this case file systems up to one hundred and seventy six petabytes, which is probably probably more than your average bear is going to need. But you know,

135
00:29:56.250 --> 00:30:17.330
Brian Schoepfle: with with Fsx for windows. I'm getting smb, and with fsx for on tab I have full native support for Smb. Six and nfs. So I've got this multi protocol storage where i'm getting all of the things that I would love about net app in a on premises Environment?

136
00:30:17.340 --> 00:30:19.239
Brian Schoepfle: Um, you know. As

137
00:30:20.060 --> 00:30:24.990
Brian Schoepfle: you know, it's it's rare. I think that somebody would just set up a database and just never ever do anything with it

138
00:30:25.000 --> 00:30:44.389
Brian Schoepfle: Right? So um i'm, i'm storing some data. I'm probably going to want to do some things with it, and one of the one of the great features of that um or the fsx for edit on tap and and on tap in general is this point in time cloning with flex clone. So I can clone my production storage

139
00:30:44.400 --> 00:30:59.880
Brian Schoepfle: and it. The data is actually shared at the block level. So as long as that data Hasn't changed. I haven't duplicated my storage. But when I make changes I get that additional storage. So why would I want to do that? Well, maybe I've got some sequel

140
00:30:59.890 --> 00:31:29.789
Brian Schoepfle: queries that I want to run, and I want to make sure that it's it's not going to my data sets or do something. I don't want it to do so. I can create this flex clone. Run my queries against that. Make sure that it's working, and then and then turn that back down. And in terms of my additional storage costs is almost nothing, because as long as i'm not changing data at the block level that day is going to be stored, and with with in line data, compression, d duplication,

141
00:31:29.800 --> 00:31:45.470
Brian Schoepfle: the compassion, thin, provisioning, and replication with Snap mirror. I'm saving a lot of money, And the other thing about snap the full support for Snapmere is, while it's really making migrations much, much easier. So I just we're seeing This is like,

142
00:31:45.820 --> 00:32:02.550
Brian Schoepfle: have to be careful about saying the most or the fastest, or the whatever, but I can say safely, this is this is one of the most, if not the most fastest, growing, most popular services since.

143
00:32:03.000 --> 00:32:17.689
Brian Schoepfle: Uh, since we launched Aurora um, which is, which is our our our managed Rds. Um. So customers are loving this, and and i'm i'm, i'm. So so glad that that aws has this partnership with that.

144
00:32:17.700 --> 00:32:33.069
Jon Spallone: Yeah, no. I mean it is a great integration there, and it's it gives you the feel from Let's say a Vmware administrator within an organization. You get that same feel. So it's not that different from what

145
00:32:33.130 --> 00:32:49.600
Jon Spallone: some of the things that you're handling on, friend. But yeah, there is some huge benefits that we go within this, and you know there's the advantages from that Vmware side of the house to do this integrated migration. I mean, I know when we did our project. That was a complete

146
00:32:49.610 --> 00:33:09.260
Jon Spallone: handshake between the Aws team and the Vmware team that we worked together with. To get this product or this solution deployed for our customer and get it up and running for them. So it was a really good transition for the customer to where they now see that value going forward, and again

147
00:33:09.270 --> 00:33:27.510
Brian Schoepfle: allowing them to focus on getting that roi. Where can I trim the fact on that infrastructure that I don't need anymore. But I had my data certified. I can replace with other means in the cloud and the and these are in the marketplace, of course, and these are different tiers. The Fs.

148
00:33:27.520 --> 00:33:32.700
Jon Spallone: That the Fs. X side of the house, because you know, we're more

149
00:33:32.710 --> 00:33:57.809
Jon Spallone: ah focus geared into this from the the net outside of the house, and then also from the Microsoft side of the house. So it's a little bit different than what we're seeing from. You know our basic block level type storage stuff. So you know, that's something that that you need to be aware of. Yeah, you may see a cost from this, but once you work out those breakdowns for somebody like us as a partner can help you.

150
00:33:57.820 --> 00:34:00.410
Jon Spallone: You can understand the cost savings over time.

151
00:34:00.420 --> 00:34:00.990
Brian Schoepfle: He's

152
00:34:01.000 --> 00:34:25.689
Brian Schoepfle: that I can't stress enough just how critical taking in total cost of ownership due to that is, you know, because I think that some people look at like the the Aws Price calculators. They're doing some sort of cost, estimation, and what they what they kind of have Perhaps a blind spot to is how how much of your time, person, hours per month. They're being devoted towards business.

153
00:34:25.699 --> 00:34:28.340
Brian Schoepfle: Yeah, back up definitely hatching

154
00:34:28.350 --> 00:34:58.290
Brian Schoepfle: um all these things, whereas with that plusx for that app on tap, and especially like in the Sql environment. I continue to get the benefits of this continuously available file system. I can use failover clusters instead of instead of a G's and the Mpio failover policy that's going to be on my my windows. Instances just looks at two different elastic network interfaces that we put on this shared storage layer, and that's how I like from that App on. Tap um, and and make that an ice cuzzy target

155
00:34:58.300 --> 00:35:04.869
Brian Schoepfle: it. And now I've got a preferred and a stand by path to a shared storage layer that stretches across availability zones

156
00:35:04.880 --> 00:35:34.560
Brian Schoepfle: the word I don't have to worry about. I don't have to worry about setting things up to replicate the data on my own. I don't have to worry about setting things to configure back up. So yeah, all of the stuff is natively integrated, and just the time savings. I think you know it's It's been known for quite some time that the longer customers are on aws, the more money they save, and it's they. They begin to realize, like these things that i'm doing manually are are built in as as automatic management features. Then that I you know I can set policies for that. I revisit on a regular basis.

157
00:35:34.570 --> 00:35:46.849
Brian Schoepfle: But then I don't have to be there, making clicks and and and getting out of click-ups, I think, is one of the that should be a primary goal for every customer is getting into this space.

158
00:35:46.860 --> 00:35:56.049
Jon Spallone: And then, just to clarify. You know my use case where I was discussing the migration from on-prem to cloud that necessarily it's, not what it

159
00:35:56.060 --> 00:36:11.630
Jon Spallone: you have to do, as far as the fsx, for on tap it's really that on-tap methodology that we have offered from that App on Prem is now living in your cloud. I mean, I just want to make sure that everybody's clear in that way.

160
00:36:11.960 --> 00:36:15.289
Believe it or not. We've got one more thing to talk about with that has

161
00:36:15.300 --> 00:36:16.250
Jon Spallone: sure,

162
00:36:16.260 --> 00:36:24.690
Brian Schoepfle: and I hopefully, folks I have at least have heard of before. The The Aws storage gateway

163
00:36:24.800 --> 00:36:53.730
Brian Schoepfle: Aws storage gateway is either Ah is ordered to. It can be ordered through the console as a physical alliance. But it's more commonly deployed as a virtual machine, and we make the images available, you know, for Ah, for hyper, B for Kbm. For vmware, obviously, and of course you can even run it as an Ec. Two instance. So we can talk about those use cases. But this is a great for low latency access from remote office branch office, wherever you are to the most commonly accessed files and data,

164
00:36:53.750 --> 00:37:23.100
Brian Schoepfle: with with backups and cold data being automatically tiered into S. Three. So this is an an area where I was talking about where we've got a front end the data that ultimately lives in in S three. So the storage gateway can be can be configured as a file server can be configured as as just basically an ice cuzzy target, and what we call both block and volume gateways, which are moving snapshots and things like that into S three. And then for for those of us who are still looking at.

165
00:37:23.110 --> 00:37:53.049
Brian Schoepfle: We're getting tape replacements for upgrading our Btl libraries as a tape library. The storage gateway functions can can function as a target, for you know Chronus and Beam and everything else. And then i'm taking my my tapes and and moving them directly. Equation which is just a phenomenal costing. But now I can put Amazon fsx for windows, file, server on the storage gateway service. So now, instead of creating it as that file server that I then put a window server.

166
00:37:53.060 --> 00:38:15.379
Brian Schoepfle: I've got all of that managed data fleet. Um, Ah! Inside of the appliance and inside of aws. So my Smb. Clients are safely connecting to file systems that live within my Vpc. Or our cache locally on my storage gateway device, and all of that data is replicated and protected inside of of Awss three,

167
00:38:15.390 --> 00:38:21.820
Brian Schoepfle: where you can turn on all those things like versioning and and delete protection and automatic tearing and all that stuff

168
00:38:21.830 --> 00:38:37.730
Brian Schoepfle: so, and and that, and as a virtual appliance, I mean, i'm sure that has a minimal footprint as far as requirements in me, which type of instance would be needed to run that as an appliance. So yeah, I mean, that's that's for now that it's

169
00:38:37.740 --> 00:38:45.240
Jon Spallone: again. This is you're looking at those cost savings, but also giving the high availability. Now, when we're talking, when you brought up the latency,

170
00:38:45.500 --> 00:38:54.580
Brian Schoepfle: these branches coming into these types of shares, are we looking at a caching or something along for that? Or is it just

171
00:38:54.610 --> 00:38:58.689
Brian Schoepfle: throttling its access to the shares?

172
00:38:58.700 --> 00:39:13.179
Brian Schoepfle: Oh, good question. Yeah. So with with with Fsx for File gateway, I'm. Seamlessly accessing windows Native Smb. Capabilities of Fsx for windows, file, server, and that's giving me ntfs and active directory integration and all that great stuff,

173
00:39:13.190 --> 00:39:43.179
Brian Schoepfle: and I configure it as a file gateway, and as the administrator, I can either pin something locally or allow the logic of the application to to make this determination. But, generally speaking, what's happening is recently written files that commonly access files are cached locally on the appliance, whereas data that has not been accessed for a while, or has crossed a certain threshold in terms of my capacity, is moved off into S three. Now as as the end. User whether that's Dave, and accounts receivable, or Linda and marketing, or whoever that may be.

174
00:39:43.230 --> 00:40:06.029
Brian Schoepfle: They're just, you know they're accessing their files, probably through windows, file explorer on their Pc. The same way they always would. And this is the it Managers dream is no disruption to user workflows right? No questions about who moved my buttons, or anything like that. I'm i'm opening up my files the same way I normally would, and the only difference between

175
00:40:06.220 --> 00:40:27.890
Brian Schoepfle: opening a file that's cached locally on the appliance versus opening a file that's in in Aws is maybe a few seconds of load time, as i'm bringing something up. And you know typically people, Aren't opening Csvs with with five million records inside of them. So I think your standard excel file has been a little bit defined to ten seconds, and that's that's typically, you know, not something that a user would complain about.

176
00:40:27.900 --> 00:40:35.149
Jon Spallone: No, no, definitely. I mean again, with my background, it's it's all about user productivity and user performance experience, You

177
00:40:35.160 --> 00:40:54.690
Brian Schoepfle: So yeah, that's definitely something that we would want to see, especially when there's when you're dealing with those remote offices, those ones, and we've got a lot of those where they're out in the back woods, and you know it's a very slow connection. So, having that ability to to help enhance that user that's phenomenal, that that is, that is really

178
00:40:54.700 --> 00:40:59.790
Jon Spallone: right. Now, as far as that gateway that's handling everything from the Fs.

179
00:40:59.800 --> 00:41:00.390
A

180
00:41:00.400 --> 00:41:08.459
Brian Schoepfle: fsx side of the house for the storage, correct, or we able to use that gateway across all storage platforms.

181
00:41:08.470 --> 00:41:33.049
Brian Schoepfle: So I um I would I would have my gateway in like any any school, any branch office, anything like that. And I I have centralized storage inside of aws. Um, i'm, you know. Maybe as like a Dmware administrator. I'm. I'm doing some work on that Esx host, but primarily I'm. I'm. Accessing and managing this through window server manager

182
00:41:33.090 --> 00:41:44.389
Brian Schoepfle: nine ten out of ten, so it's I'm. I I wouldn't expect even any disruption to something that helped us, or you know, level one administrator in a facility would be doing.

183
00:41:44.400 --> 00:42:00.639
Brian Schoepfle: That's great, that's great. So let's hit real quickly on top of the luster and the open Cfs side of the house, just for those who are listening. That would be interested in something along these lines. These you said the luster. We're focused on the Linux side. Correct?

184
00:42:00.650 --> 00:42:17.009
Brian Schoepfle: Yeah, uh, this is where I have to be careful, because I don't want to get out of my depth, for both cfx and luster. Luster is cloud file storage. It's integrated directly with s three. Um, you know, I typically I would say, like

185
00:42:17.020 --> 00:42:24.780
Brian Schoepfle: folks who are using luster know that they need it kind of thing. It's. But I what I this is great for

186
00:42:24.790 --> 00:42:54.730
Brian Schoepfle: high-performance, computing it's great for big data analytics. It's great for machine learning, and machine learning, training models and for folks that are doing a lot of work with large media files, so visual effects and rendering and transcoding they will have it's. It's a model that allows me to scale my storage with my compute and integrate with machine learning and artificial intelligence services from aws like sage makes

187
00:42:54.740 --> 00:43:24.370
Brian Schoepfle: and work on media stuff with services like nimble studio from aws, and we've got customers like the Toyota Research Institute, Max are netflix and gradient that are using this. Um, I I would say that I've not run into a lot of K. Twelve schools or or organizations with with five hundred users that are really getting into this. But um, you know, data, as we know, is getting bigger all the time, and eventually everybody's going to be doing something with machine learning. Maybe not. Everybody will be doing something with

188
00:43:24.380 --> 00:43:30.380
Brian Schoepfle: compute or media rendering. But this is really high-performance, really high performance for luster file systems.

189
00:43:30.390 --> 00:43:39.370
Jon Spallone: Yeah, And like you said, If you know, you know, typically when when we're working with somebody, if they come in and say this, they have the demand for it.

190
00:43:39.380 --> 00:43:53.390
Brian Schoepfle: If they're not asking for it, that's where we're evaluating other storages because that demand it's not going to fit that user user base. And then from the open Zfs side of the house. I know you said earlier, that was more of a higher performance. Is that correct?

191
00:43:53.400 --> 00:44:07.139
Brian Schoepfle: So it is high performance. It's definitely Linux native Open Zfs is is an open source project of a native port of Zfs, the Zfs file system to Linux and it

192
00:44:07.150 --> 00:44:26.189
Brian Schoepfle: Zfs. As A. As a standard includes functionality of both traditional file systems and a volume manager. Um. So for folks that are are deep into ah Linux development, and the statement goes all the way back to full to maybe what the dust off this term. Folks who are familiar with Solaris system

193
00:44:26.200 --> 00:44:35.050
Brian Schoepfle: eventually fell in love with Zfs and and Zfs was the open Zfs is the port of that to

194
00:44:35.060 --> 00:45:02.480
Brian Schoepfle: to Linux And so for workloads and machines that need posix workloads and Fsv Four. It allows me to do access controller. So there's a lot of security thing I I get. I, for folks like are working with like really large files, especially here, because it does support a natively a maximum file size of like sixteen exabytes.

195
00:45:02.490 --> 00:45:18.990
Brian Schoepfle: Um! So ah big, big big stuff! Um, Ah! And ah! I think similar to luster like. But folks that for folks that have maximum mile size of sixteen exabytes appeals to them. They'll They'll definitely want to take a look at this.

196
00:45:19.000 --> 00:45:38.369
Jon Spallone: Yeah, you brought up a solaris that that brings me nightmares from back in the day we used to use a work with a staff space organization where we provide services. We were heavy on the slayers back in. So I knew we we used the Fs. We had the Microsoft integration up front end. So yeah, I mean the other thing, too.

197
00:45:38.380 --> 00:46:01.100
Jon Spallone: Again. I ramble so much, but bear with me when we're talking about some of these things, of looking at cost savings later on down the road. I've seen a lot of organizations take a look at the Linux side of the house to replace services that Microsoft has done for them before to be able to do cost savings, because I can run a a Linux base

198
00:46:01.110 --> 00:46:13.269
Jon Spallone: instance and still provide Microsoft level services to my desktops, to my other servers in the environment, you know. Bring off some of those services to, you know, an open

199
00:46:13.280 --> 00:46:21.779
Jon Spallone: operating system, and you don't have that cost. So that is something to you know, be aware of, because Zfs can help you out

200
00:46:22.330 --> 00:46:29.929
Jon Spallone: with some heavy lifting and some trickery to be able to do and replace a Microsoft side of the house, but do the same thing

201
00:46:29.940 --> 00:46:30.689
Brian Schoepfle: from a

202
00:46:30.700 --> 00:46:53.389
Brian Schoepfle: Yeah. So I think maybe in a in a future conversation we should talk about some of the things that Amazon is doing to help customers modernize workloads and and produce their costs and and certainly open Zfs is is one of those areas, because I I don't know if we talked last time about graviton processors, but that the aws specific chip that we make,

203
00:46:53.400 --> 00:46:59.890
Brian Schoepfle: which which is is, which is for Linux workloads is great for organizations that are pursuing sustainability

204
00:46:59.900 --> 00:47:29.079
Brian Schoepfle: because it's power. Consumption is so much lower than traditional. X. Eighty six architecture, and because of the performance of the graviton processors. I can get an open Cfs cluster that scales up to one million. I apps with latencies of just a few hundred milliseconds for really high performance workloads. So if you, looking to migrate your on-premise data that's stored in a zfs, or all their Linux based file server to aws, this is great. So it's giving me the same data management capabilities. And I don't have to

205
00:47:29.090 --> 00:47:57.070
Brian Schoepfle: state or modify existing code, or how i'm managing that data. And I've got these rich, rich capabilities within the cluster that make it easier for me to test and develop and run these cloud data applications. So we're seeing customers that are doing front and electronic design automation, genomic research and media processing. But it's great for code and artifact repositories, devops, solutions, and of course big data and analytics. So open Zfs does support a wide range of Linux windows in Mac Os workload.

206
00:47:57.080 --> 00:48:04.190
Brian Schoepfle: But I think I again, this is the case of if if you're using Zfs, and you know that you need it. This is a great place to look, and

207
00:48:04.200 --> 00:48:20.890
Brian Schoepfle: you know, if you're managing traditional windows, file shares and and and that's working well for you, and you're not doing a wholesale, you know migration of everything that you're doing around windows into Linux or or something open source There, there's no reason that we need to be investing in in making those changes.

208
00:48:20.900 --> 00:48:21.390
Jon Spallone: Yeah,

209
00:48:21.400 --> 00:48:25.330
Brian Schoepfle: this is not a not a place to store word and excel

210
00:48:25.340 --> 00:48:48.520
Brian Schoepfle: Exactly. Exactly, and and I made a note here that we'll we'll. We'll cover that as a topic in the future, and maybe we can get some more resources involved to one year side of the house and have a deeper discussion around that so definitely that'll be something that we'll we'll line up later on in the future. Um! So now we're shifting from the Fsx side of the house. Let's go back to our work.

211
00:48:48.800 --> 00:48:50.259
Jon Spallone: Oh, come on, John.

212
00:48:50.270 --> 00:48:51.480
Jon Spallone: There we go,

213
00:48:51.490 --> 00:49:13.389
Brian Schoepfle: um! And now we and again the understanding. We're broken down into different sections here. So this is our our object. File, rock, storage, type stuff. So once we go from the Fsx, now we're looking at this elastic box storage the ebs um, so give us a quick run down to that one. It's. Again. It's a high performance. But um, you know what what kind of use cases are we seeing?

214
00:49:13.400 --> 00:49:28.779
Brian Schoepfle: Yeah. So although I can do things like store structure data in Csvs or K files, or something like that in s three. And query that with Athena that allows me to run sequel queries against

215
00:49:28.790 --> 00:49:56.059
Brian Schoepfle: files, even compressed files that are being stored in S three. That's typically not going to give me the kind of sub millisecond latency performance that I really need in in a database, and it's not the kind of place that we would store. You know. We wouldn't have an operating system to s three. We may. So when we snapshot a volume which is an ebs volume that gets stored in S. Three. But we're not running the block based storage for

216
00:49:56.070 --> 00:50:03.720
Brian Schoepfle: for a virtual machine inside of s three. We want those disks attached directly to the

217
00:50:03.730 --> 00:50:22.950
Brian Schoepfle: um to the host, whether that's, windows, or Linux so, so the elastic block. The elastic block store is are our volumes that we're going to attach to our virtual machines, And it's typically not a great idea to store data That, you know is

218
00:50:23.080 --> 00:50:38.059
Brian Schoepfle: that, you know, non-recoverable data in in the instant store of the machine You know, because that's one of the things to remember there is that's really ephemeral. So if the instance is, you know, it needs to be terminated, or something like that, i'm going to lose that data.

219
00:50:38.070 --> 00:51:01.930
Brian Schoepfle: But elastic block storage is persistent, and that allows me to do things like. Detach a volume from an instance, launch it with a new image, and reattach my data volumes to it, so I can use ebs for my root volumes. I use ebs for my data volumes, and with the somewhat recently announced Amazon Gp: three

220
00:51:01.940 --> 00:51:10.549
Brian Schoepfle: I can. I can scale my. I apps to like to sixteen thousand. I apps, and up to one thousand megabytes of throughput.

221
00:51:10.560 --> 00:51:16.730
Jon Spallone: So this is something we would look for when we're doing a high computational type of

222
00:51:16.860 --> 00:51:19.459
Jon Spallone: dig through data or pull through data.

223
00:51:19.470 --> 00:51:47.710
Brian Schoepfle: Yeah. Ah, you know, when I kind of go through my flow chart of of where should stuff live like for a database? For example, I I try to. I would want to say, I want that in Amazon, Spanish relational database service. One of that's for my sequel. Postpres Ql. Maria, Db. Oracle, Db. Or Sql. A. Hem of mothers, cause I I um um i'm going to the cloud, not just for the the infrastructure management, but also for, like some of that undifferentiated heavy listing that we're talking about.

224
00:51:47.720 --> 00:52:13.020
Brian Schoepfle: But if for some reason I've got workbooks that can't go into a a managed database service that i'm going to be running. My database is on Ec. Two instances. And so the the data that store that the database is solved is is going to be stored on Ebs volume pretty much every virtual machine that's running, whether it's a database or not is going to have some level of of ebs stored, because I may have,

225
00:52:13.030 --> 00:52:41.809
Brian Schoepfle: I may have some of the latency requirements where I do want to keep that data. Um. Ah! Attached directly to the volume. But I may not always need sixteen thousand, I ops and one thousand megabytes of per second of of throughput so ebs. Volumes come in a bunch of different flavors. You know there are three different types of ssd volumes and a and a couple of different types of of of magnetic disks. Htd. Volumes so depending on the kind of performance that I need.

226
00:52:41.820 --> 00:52:44.610
Brian Schoepfle: Um, I um.

227
00:52:44.890 --> 00:53:14.689
Brian Schoepfle: I can attach that to the volume now from a cost savings perspective. One thing to keep in mind, and and where I encourage it. Administrators and and folks making these kind of kind of decisions of Where is my data actually going to live? Important for customers to keep in mind that if I provision a five hundred gigabyte Bs volume I'm. Paying for all five hundred gigabytes, whether or not i'm. Consuming that capacity, whereas with s three and efs and fsx i'm not really provisioning anything in advance on

228
00:53:14.700 --> 00:53:41.970
Brian Schoepfle: paying for what I use. So as as we look to to, you know, modernize and drive cost savings, I think over time. We'll see only that data that needs to live on an ebs volume there, and and and try to leverage something like the advantages that I get from something, for example, like Fsx, for on tap, or I can suddenly provision things and not have to pay for zeros that i'm writing across a disk, i'm not using.

229
00:53:41.980 --> 00:53:47.900
Jon Spallone: Yeah, I mean, that's a good point, because that's another thing. A lot of customers I find don't

230
00:53:48.310 --> 00:53:53.009
Brian Schoepfle: quite understand. And obviously even some, you know,

231
00:53:53.600 --> 00:54:00.990
Jon Spallone: fellow technologists, Don't understand. Is that that? Yes, you're gonna have that cost savings on the cloud side of the house. You

232
00:54:01.000 --> 00:54:16.920
Brian Schoepfle: you'll be able to handle the compute a little bit better. But when it comes to storage typically we're always going to have that storage cost. So, from an abs standpoint, whatever I'm provisioning out there. I'm always paying for it, whether i'm using it or not. So I need to be aware of that.

233
00:54:16.930 --> 00:54:21.979
Brian Schoepfle: Yeah, for for the data that resides on those volumes, the the rule of Thumb. There is like It's really kind of like

234
00:54:22.590 --> 00:54:27.090
Brian Schoepfle: it's the the data that that server, and only that server is going to need. So

235
00:54:27.100 --> 00:54:51.239
Brian Schoepfle: if if if I if I have the ability, if I have the need or the ability to have multiple clients connect to something that needs to be shared storage something like Efx or or fsx, which is, which is built on top of the if it's just isn't that native Linux file system. It's it's the other flavors that we talked about. But the the the the managed shared storage system is going to reduce my operational cost, and give me much better

236
00:54:51.250 --> 00:55:14.990
Brian Schoepfle: that i'm not just provisioning a server for the sole purpose of making something shared when their services built for shared storage that are a better fit, and that's a rule that applies across everything that we do at aws. Whether that's the type of database that we're using, whether database languages, database applications. It's it's It's all about the right tool for the right job

237
00:55:15.000 --> 00:55:21.759
Jon Spallone: mm-hmm that definitely. Now I know we're going to be coming up on time here, so I don't know. Maybe we follow up

238
00:55:21.770 --> 00:55:36.800
Jon Spallone: with a part two to cover some of this other stuff, because I think there's value in talking about the data, migration, hybrid storage. I um manage file, transfer, and but list keeps going, everybody. But I I think

239
00:55:36.840 --> 00:55:38.399
Jon Spallone: we're good good

240
00:55:38.780 --> 00:55:54.499
Jon Spallone: breaking in here on this we'll we'll call this part one. We'll follow up with a part two in our next recording where we'll go into a little bit deeper, but I think this is good for people to understand how the storage breakdown happens for them. Now,

241
00:55:54.510 --> 00:56:08.119
Brian Schoepfle: another question is, as far as when i'm deploying an instance of, let's say, a windows box virtual machine up in my cloud in aws. What level of storage am I using for that?

242
00:56:08.620 --> 00:56:10.359
Brian Schoepfle: So I

243
00:56:10.370 --> 00:56:36.689
Brian Schoepfle: just so. You like the the typical um, you know, in the console I'm going to provision a server with probably a relatively small root Volume eight gigabytes, twenty gigabytes kind of thing That's where my actual like Os is is going to be installed. And um I may have some ephemeral storage attached to the instance, and that's I mean, that's really suitable from a windows perspective that's suitable for page, file, cis, and nothing else.

244
00:56:36.700 --> 00:56:50.829
Brian Schoepfle: Yeah. And then, if I do need additional data volumes, either at the time of provisioning that instance, or at some point in the future, I can create and attach additional volumes, and just mount them from within the windows file system.

245
00:56:50.840 --> 00:56:52.589
Brian Schoepfle: So within windows, server manager,

246
00:56:52.600 --> 00:57:07.279
Jon Spallone: so the operating self, the operating system itself. It's, it's living within the instance. But the the type of storage level or the the storage that's being provided in the back end of the house. That that's all just provision. When I deploy the virtual machine correct.

247
00:57:07.290 --> 00:57:13.089
Brian Schoepfle: Yeah, that's a that's a virtual disc that's attached directly to the to the instance.

248
00:57:13.100 --> 00:57:37.030
Jon Spallone: Yeah, I bring that up because there are other cloud solutions out there where I need to provision my storage first, and then put my machine in that storage. So that's why i'm just trying to make sure that you know everybody understands when i'm at aws and i'm pulling out that instance, it's carved out for me. The storage now comes into play in those peripheral connections, I do. And again, this is from a Microsoft side of the house. Just let everybody know.

249
00:57:37.060 --> 00:57:57.679
Jon Spallone: Ah, typically we We have a lot of Microsoft people, and we can get them converted as we go along, but just wanted people to understand that i'm provisioning the machine, and then i'm applying the storage, and I have the options here of my block level storage, and I can add into that machine, but separate entities from each other,

250
00:57:57.690 --> 00:58:07.790
Brian Schoepfle: and that's that's giving customers a lot of agility, right? Whether that's, you know, creating an instance for the sole purpose of making it a template.

251
00:58:07.800 --> 00:58:36.970
Brian Schoepfle: Vm. What we would call an Amazon machine image inside of aws, so I can create an instance Image it, you know, snapshot and image it. Convert it into a machine image that i'm going to use for like my auto scaling groups, or or just you know I'm creating some some organization-wide standards of Hey, when we do a window server. This is what this is, what it's supposed to be pre-configured to to look like, and that's going to reduce my deployment size and help me enforce better governance standards across the organization.

252
00:58:36.980 --> 00:58:54.170
Brian Schoepfle: But yeah, having having having the having, the the Vm. And the block storage itself suffered, is giving me a lot of agility, because I know that data persists as long as I want it to. Whether or not I actually even have the Vm. Provision and running, or anything like that.

253
00:58:54.180 --> 00:59:20.899
Jon Spallone: That's great, I mean again, it just wanted to make sure people understood that because it is a different approach than some other providers that are out there. So to me. I think that's a huge advantage. But you know we'll we'll let that rest with the listener's decision on their own end. So again, Brian, I appreciate it. You know this is the great Ah, we'll definitely call this part one. I do want to follow up so we can cover some more of this because I do think there's some value. Add in these other storage

254
00:59:20.910 --> 00:59:26.090
Jon Spallone: provisions that we can use within Aws to provide to the customers. So again, thanks, man.

255
00:59:26.100 --> 00:59:50.720
Brian Schoepfle: Yeah, yeah, We We covered the basics, you know. We covered a block or a file. We spent a lot of time on file, but you know There's probably more time that we could spend on on efs. But and and so we've covered a black recover pile with an object um as we get into data Sync and the Snow family and some of these other like managed storage services. Or you know, there's a lot that we can talk about with this from a snow family perspective of, you know, moving data into aws and terror

256
00:59:50.730 --> 01:00:18.720
Brian Schoepfle: by scale, or a petabyte scale. You know, you know there's compute built inside of these actual boxes that we send out that you know, can help with um encryption and compression. And then on the Aws side that we rehydrating, encrypting that data for getting it up into aws. I'd love to share with you a story about how we put a snow cone on the International Space station. That's our small little ruggedized edge, computing appliance, or so many things that we can talk about to play.

257
01:00:18.730 --> 01:00:30.589
Brian Schoepfle: It's It's all ties together right? Because that all ties into what we talked about a couple of weeks ago with migration. So lots to look forward to as far as what we're going to discuss, and these are always so much fun. So I appreciate you having me

258
01:00:30.600 --> 01:00:41.979
Jon Spallone: sure thing, and yet great T. So again conclusion of part, one part, two to come, so look forward to it, and thanks for listening with us today. We'll look forward for you to be with us on our next episode.