- [Alana] All right. So we figured out block storage for our application. Now we need to figure out where to store our employee photos. A natural question is why can't we just store these photos in Amazon EBS? Well, there's a few reasons. Number one, most EBS volumes can only be connected to one EC2 instance at a time. Eventually as my app scales, I'll need to figure out how to access those photos from all of my instances. That's an issue. The second consideration is that an EBS volume has size limitations. That means that eventually there will be a limit to how many HD 4K photos I store of my employees in one drive. Ideally, I'd store these photos in a more scalable solution. So EBS probably isn't the right choice. Fortunately, AWS has a service called Amazon Simple Storage Service or Amazon S3 that was designed to be a standalone storage solution that isn't tied to compute, meaning you don't mount this type of storage onto your EC2 instances. Instead, you can access your data through URLs from anywhere on the web, which gives this service its nickname, storage for the internet. S3 also allows you to store as many objects as you'd like with an individual object size limit of five terabytes. This makes it ideal for our employee photos. Now let's talk about how we store things in S3. The underlying storage type for S3 is object storage. That means that all of the same characteristics of object storage are also characteristics of S3. So S3 uses a flat structure. It uses unique identifiers to look up objects when requested. You get the idea. S3 is also considered distributed storage meaning that we store your data across multiple different facilities within one AWS region. This is what makes S3 designed for 99.99% availability and gives it 11 nines of durability. All right, let's learn about some S3 concepts. The first concept is a bucket. In S3 you store your objects in buckets. You can't upload any object, not even a single photo to S3 without creating a bucket first. You then place your objects inside these buckets. And if you want to organize and arrange those objects you can also have folders inside of the buckets. Let's create a bucket in the console. When you log in you'll type in S3 in the service search bar. Once you click on it, you'll see the S3 dashboard showing you all the available buckets for every region. I'll then select create bucket. And what I want to point out here is that buckets are region specific. So what that means is we can choose where we want to place our bucket. In this case, we want to place our bucket close to our infrastructure for our application which is in the Oregon region. So we'll go ahead and leave it as Oregon. Next, we have the name of our bucket. Even though our bucket is specific to one region our bucket name has to be globally unique across all AWS accounts and must be DNS compliant. Once you create your bucket AWS will construct a URL using this name, so it has to be something that can be reachable over HTTP or HTTPS, meaning there can be no special characters, no spaces, et cetera. So for this bucket's name, let's choose employee-photo-bucket-al-001, employee-photo-bucket-al-001, which is DNS-compliant. Now we can leave the rest as defaults. Scroll down and click create. To work with this bucket, I'll need to find it in the list and click on its name. Here we can start uploading our objects. To do this I'll click upload and then click add files, find the file I want to upload and click open. Then scroll down and click upload. So as you can see, the object upload was successful. If I click on the name of my object I get to see quite a bit of detail here. I can see the owner, region, and size. But most importantly we can see the URL of my object. The first part of this URL is simply just the bucket URL that AWS created using my bucket name. Then AWS appended the name of my object, also referred to as the object key, to the bucket URL. Now what happens if I click on this URL? Hmm, access denied. That's weird, right? Well, not really. That access denied message leads us to a bigger question that most people have when they start out on AWS, and that's who can access my data? Earlier I mentioned that you can retrieve your data from anywhere on the web. And people often think that means that anyone can retrieve that data, but by default it's actually the opposite. Everything in S3 is private by default. This means that all S3 resources, such as buckets, folders and objects can only be viewed by the user or AWS account that created that resource. That's why I get that access denied message because I was acting as an anonymous user on the internet trying to access an S3 object that's private. Now that's not to say that no object or bucket can be open to the world. They absolutely can be if you explicitly choose that option. And it's actually kind of a process to make something public. The reason it's difficult to make your objects public is to prevent accidental exposure of data. Let's try it. Okay, so if we want to make the object we created public we need to do a few things. First thing is from the objects detail page, we'll want to click on the actions dropdown and then select make public. Then click it again. Now, once we do that a message will pop up saying that our setting is blocked. So to ensure that we allow public access to our objects we'll click on this link in the message. From here we'll go ahead and click edit block public access settings, uncheck the top box, and then click save changes. Type in confirm and confirm it. Now we'll go ahead and go back to our object by clicking on objects, clicking on the object's name, click object actions, and make public again. And then we can go ahead and click on our object name again and then click on the object URL. Now we can view our photo. That's how you make an object public. That being said, most of the time you don't want your permissions to be all or nothing to where either nobody can see it or everybody can see it. Typically you want to be more granular about the way you provide access to resources. As far as access control, you can use IAM policies attached to users, groups and roles to access your S3 content. And you can also use a feature called S3 bucket policies. S3 bucket policies are similar to IAM policies in that they are both defined using the same policy language in a JSON format. The difference is IAM policies are attached to users, groups, and roles whereas S3 bucket policies are only attached to buckets. S3 bucket policies specify what actions are allowed or denied on the bucket. For example, you might want to attach an S3 bucket policy to it that allows another AWS account to put objects in that bucket. Or you might want to create a bucket policy that allows read-only permissions to anonymous viewers. S3 bucket policies can only be placed on buckets and cannot be used for folders or objects. However, the policy that is placed on the buckets can apply to object in that bucket. All right, to recap S3 uses containers called buckets to store your objects and you have several options to control access to those objects through the use of IAM policies and bucket policies.
