S3

[00:00:00]
>> So with that, we've got three green checks. Two of them we already started out with. One of them was we got for free, which is none of our access keys for this user are over a year old, which can confirm, right? Our root user has MFA. We have MFA, three green checks, feels good to be secure in this case.

[00:00:19]
So now we've done the kind of administrative upon unintended pieces of this. We've got the root user, we've got the administrative user, we'll have to create a user to some will be created for us, that's fine as we go through. But for that we're kinda done with the the account setup piece of this.

[00:00:41]
So with that, we're gonna move into talking a little bit about S3. S3 solves the first of a series of problems for us. Which is despite all of our hard work fighting with JavaScript and the DOM and CSS scoping, so on and so forth, the end of the day, our applications are a series of text files that we need to put onto the internet.

[00:01:03]
S3 is a place where you can take things, put them on the cloud, the cloud just being somebody else's computer, get them off of your computer onto somebody else's computer. It's hooked up to the internet. S 3 stands for Simple Storage Service, say that three times fast. And it's basically a way that you can take anything in our case is gonna be our JavaScript asset for images, video so on and so forth.

[00:01:30]
Right and it brings a lot to the table despite its very unassuming name. So, let's just kind of get a conceptual idea around this. We have our S3 account, which is the one that our administrator has right now has a series of buckets. It's a very technical term.

[00:01:48]
In that bucket, you put objects or things. So now you have a bucket full of things. In this case, it's gonna be our client side assets. But like I said, it could be anything and you can figure out, you can put stuff in the bucket. You can take stuff out of the bucket, you can list all the things in the bucket, so on and so forth.

[00:02:07]
We can also host web pages and web applications out of our buckets. So that's really great. Now there's a little bit more to it, it's infinitely scalable yeah sounds good right. I think you can get like there's stuff like the maximum file size you can put in there as I think five terabytes.

[00:02:29]
From doing that from memory, again the joke about JavaScript is going large at some point look at code splitting. If you're looking at five terabytes in the eye it's time to start thinking about that. It's got three nines of availability and we'll talk about how to make that a little bit better later on and it's built for four nines, which means 99.99% of the year it is up.

[00:02:51]
And more impressive is the 11 nines of durability, right? Which means despite how much you might regret some of the code in those applications, S3 will not be the one that loses it. Which is really great especially for some more for assets, like video or something along those lines like they do replicate it across multiple data centers, so on and so forth.

[00:03:14]
As some of the features almost none of which will be using versioning. So if you take a file or a object in your bucket, and you replace it with another one, you can have all the previous versions. Obviously you'll pay for that, right? I mean in money not in consequences.

[00:03:33]
But you can have versions. You can have encryption, security and all those things. For us, we are going to kinda have Git as our kinda versioning tool. And we don't need to encrypt our client side assets cuz the whole goal is to get those JavaScripts to the browsers to be compiled and run.

[00:03:51]
But for different kinds of things that you might have to do, those are kind of available. And there are ways to secure the bucket. There are ways to encrypt things in the bucket, right? And we're gonna kind of go through some of those steps as well. Like I said, we are optimizing for people getting the stuff in our buckets, but you can, every once in a while you hear about somebody who left their bucket unsecured and lost a bunch of sensitive data and stuff along those lines.

[00:04:17]
We are lucky enough that we are trying to get people to read files out of our bucket. We will go out of our way to put those files closer to their computers to optimize their ability to read out of those buckets. But those are things, think about, should you be storing, PDFs of the most recent bill or something along those lines.

[00:04:36]
If you work in the healthcare industry, right, there's obviously additional concerns around S3 that you definitely gonna need to consider. It's effectively a key value store. The key being the file name, the value Bing the file, right? But you can set up directories. It doesn't really have directories but it will let you think you do.

[00:04:57]
Right, so if you call something like Java scripts/script.js, the UI will show you a folder that makes you feel better, right, but it's effectively flat hierarchy. There's also a data consistency model. Just to keep it in mind. I actually literally had an argument is a strong word a lively conversation about the kind of second point here, which is putting stuff in his immediate updating and removing objects is eventually consistent.

[00:05:32]
This is to get you to those 11 nines of durability they don't just put your file on one hard drive one place, they put it many places and it might take a little bit to get all of them off all the different places right. Amazon we'll see this in a little bit when we start setting up the very first thing has this idea of regions right US East 1 US West 2 so on and so forth and in those are availabilities zones, right?

[00:05:58]
One of my co workers literally designed the East Coast ones and US East one and us these two are different power grids for a reason. For us, we are gonna distribute our files everywhere. So where you get a little bit of that kind of reliability from distribution for free, but for back end engineers like if a region goes down below to flip over to a clone of a database somewhere else makes a ton of sense.

[00:06:19]
But anyway, updated removing objects is eventually consistent. You could update an object and get a slightly old one for a second. What we're talking about this is literally, that happens very infrequently if ever. But it is one of those things that just put in your brain. If it does happen to you in some case that is technically what it says on the label that that could happen in this case.

[00:06:43]
What is the cost to uploading S3 is free. You get charged for storage and you get charged for request. So putting things into S3, totally free, keeping them in S3 will cost you. But we saw at the free tier we got five gigabytes of free storage and then we get charged for requests.

[00:07:05]
But we will figure out how to limit the requests to our bucket as much as possible by the end of this using CloudFront. If you're really worried about there's different tiers as well. There is, hey, this is normal stuff I wanna put in a bucket, then there's another tier called infrequently access which is kinda you're gonna put in a bucket that's on a high shelf, right.

[00:07:26]
Cost you less to keep it up there, but might cost more to go get it, right? Then there's all the way down to intelligent tearing which will move it to different places for you. And finally glacier, which is we will put that in the freezer out in the shed, right.

[00:07:40]
And so you can kind of for different use cases. You can also like find cheaper options as well, but for the general size of our client side application since I said that $13 included me never cleaning stuff out of the bucket ever, right ,yeah.
>> As far as the difference between cost of uploading and cost of storage my understanding it right that if you theoretically uploaded files, files that were zero byte size would cost you nothing

[00:08:09]
>> Yeah I mean upload like they will take your data to charge you for storing it later they will happily encourage you to upload as much as you possibly want to them so that you will never think about migrating it to one of their competitors. [LAUGH] It sounds very generous, but it's also purposeful in that case.

[00:08:30]
So with that, one of the occasional limitations is that bucket names need to both be unique. And then for some of the kinda early stages of this if you're gonna use it to host a website then it needs to be the same as the URL. I think with CloudFront, we avoid that eventually but there will be kind of intermediary period, right?

[00:08:56]
So it means you have to go through a fun dance. You need a domain name and you need a bucket, they both have to be unique. Probably figure that out kind of simultaneously. Most of the cases that won't be a big problem because of that, but there's another reason why we're gonna switch gears for a slight moment and we'll go back into S3.

[00:09:17]
So we're gonna switch gears talk a little bit about registering a domain name with route 53. And the reason that we're going to do that now before we get all the way into using S3 is one, we wanna know that the domain name is available. Two it takes a little bit of time to set up.

[00:09:34]
So mostly gonna do it now and then jump back into some of the S3 stuff and get that all set up to buy ourselves some time for the domain to get fully registered everything along those lines. So we're gonna do that now as well. So we will revisit, we are actually using S3 shortly.

[00:09:54]
But first we are going to make sure that we can have both a bucket and a domain name that work together and also give it some time for that to cook