- [Raf] There are multiple storage options you can use in the AWS Cloud. In this video, I will compare block-storage options like EBS volumes; file-storage options, like EFS; and object storage, like Amazon S3-- as well as provide comments on their access patterns, durability, and performance. It is very common to hear the term, use the right tool for the job when talking about storage. And that's why access pattern should be the first aspect you should consider when choosing what storage offering to use. As I said, Amazon S3 offers you object storage, while Amazon EBS and EFS offers you block- and file-storage capabilities. And each of those services is designed to satisfy a different access pattern. When you are provided with storage coming from EBS volumes, the operating system can perform block-storage operations, like editing blocks in the file system, that will reflect changes in files. For example, if you load a 5-MB text file into a file system, and it wants to change one character in that text file, the file system will do a precise change of only the blocks that represents that character. And it does that because it has access to the blocks, since they are provided by a block storage service, like Amazon EBS. The same happens with image files, video files, binary information used by database engines, and actually everything that needs to be edited on the block level in order to work. On the other hand, if you load that same file into an object-storage service, like Amazon S3, you need to do an API call to download it to a block-storage device, change it, and do another API call to upload it back to Amazon S3. Actually, these API call names are get-object and put-object. That may lead you to think that block storage is better because it allows file editing. And that's why I say that it really depends on the access pattern. If you don't need to edit the files, object storage, like Amazon S3, can provide a higher data durability and a lower cost when compared to Amazon EBS or EFS. That's why S3 is instrumental for things like storing log files, storing large objects, or serving as a data lake. In fact, lots of managed AWS services, like Elastic Load Balancer or CloudFront, use Amazon S3 for storing their logs. Access logs is not something you would like to edit. So, the access pattern is mostly read-only. So, as the access-pattern topic is better understood, let me double-click on Amazon EBS and Amazon EFS. Amazon Elastic Block Store, or Amazon EBS, is a block-storage service designed for EC2 instances. That means you can only attach EBS volumes to EC2 instances-- and more precisely, only on EC2 instances living in the same Availability Zone as the EBS volume. Save that Availability Zone information for now, because it will help you to tell the difference between EBS and EFS. Notice that I used the word attach when referring to the relationship between an EC2 instance and an EBS volume. That's because attach-volume is the name of the API call to attach EBS volumes to EC2 instances. When creating EBS volumes, you can primarily choose between hard disks or solid state drives, which will impact in cost and performance. There is an entire page at aws.amazon.com/ebs/volume-types/, which provides details for every single EBS volume. I suggest you take a look at this page after watching this video. What you need to know for understanding that page is that the performance of EBS volumes is measured in IOPS, or I/Os per second, and throughput, or how fast data can be transferred between an EC2 instance and the volume. Among the EBS volume types, there are options where you can buy a fixed amounts of IOPS for a consistent and predicted performance. These are called Provisioned IOPS. There is also an option called General Purpose, where AWS does some calculation of I/O credits for better matching performance and cost. If you're not sure which one to choose, I recommend starting with GP2 or GP3 volumes, which are General Purpose, and take a look at their CloudWatch metrics to see if you need more IOPS to justify using a Provisioned IOPS volume. Remember that a big advantage of the cloud is the ability to match the technology to your workloads, and not the other way around. We will talk about Amazon CloudWatch in a further video. Now, remember when I said that EBS volumes needs to be used by EC2 instances residing in the same Availability Zone? That's where Amazon EFS, or Elastic File System, comes in as a great help. If you need EC2 instances using the same file system for data storage, and your access pattern does not require you to edit files in parallel, Amazon EFS can be a good choice. When compared to Amazon EBS, EFS provides a higher durability because data is replicated across multiple Availability Zones. But guess what? Although the baseline performance is fast enough for most workloads, it does not provide the low latency per I/O found in Amazon EBS. Amazon EFS uses NFSv4 under the hood, or Network File System version 4. When you create a file system, the service orchestrates all the creation and configuration of NFS endpoints in each subnet of your choice. It also gives you a unique DNS name, which you can use in your EC2 instances to connect with the NFS client. That's it. I hope this gave you a better background on understanding the differences between some of the major AWS storage options, like Amazon S3, Amazon EBS, and Amazon EFS.
