Episode 8: EBS vs EFS vs S3: The Complete Storage Decision Guide | AWS Solutions Architect Prep

Hey everyone, Ballu here, welcome back to Tech Talk with Ballu, your complete guide to Async the AWS Solutions Architect Exam. We are now on episode 8 and today we are doing something different. Instead of diving deep into one service, we are comparing three different storage services side by side, which is EBS, EFS and S3. This is all about designing storage architectures and making the right storage choice for your use case. Here is why this matters. On the exam, you will constantly be asked which storage service should you use for the scenario, should you use block storage, file storage or object storage, EBS, EFS or S3. The answer often depends on the specific requirements. You might think, can't I just use S3 for everything? No, each storage type solves different problems. Using the wrong one leads to terrible performance, high costs or outright failure. So today, we are comparing EBS, elastic block store, that's your virtual hard drives, EFS, the elastic file system that's your shared network file systems and S3, which is your simple storage service and object storage we covered earlier in episode 7. We will cover what each one is when to use it, performance characteristics, cost implications and their real world architecture patterns. By the end of this episode, you will know exactly which storage service to choose for any scenario on the exam or in the real world. So let's dive straight in. Before we compare EBS, EFS and S3, let's understand the three fundamental types of storage. So what is block storage? Think of block storage as a virtual hard drive attached to your computer. This raw storage divided into blocks, you formatted with a file system like EXD4 or NTFS, then mounted to your instance. Just like a hard drive on your laptop, you can install an operating system on it, run databases, store application files, anything that you do with a local disk. On AWS, this is EBS, elastic block store. Now, what about file storage? First storage is a network file system, multiple computers can mount the same file system simultaneously and share files. Think of a shared drive at your office. Multiple people access the same folders and files over the network. One person uploads a document, everyone else can see it immediately. On AWS, this is called EFS or elastic file system. And what is object storage finally? Object storage is fundamentally different. You don't mount it like a drive. You access it via APIs, that's HTTP calls. You upload files, called objects and retrieve them using a unique key. It's designed for massive scale, store billions of objects perfect for media files, backups, data lakes, anything where you would be storing and retrieving complete files. On AWS, this is called the S3 or the simple storage services which we covered extensively in our last episode. So what are their core differences? So let me put this simply, block storage, I need a disk attached to my EC2 instance to run a database. For file storage, I need multiple EC2 instances to share the same files for object storage. I need to store millions of images that users upload and retrieve them via API. Different problems have these different solutions. So for the exam, here's the key decision tree. Need to attach storage to one EC2 instance for a database or application. Then you want to go with EBS. Need multiple EC2 instances to access the same file simultaneously. You want to think EFS. Need to store objects, accessible via HTTP API. Don't need to mount as a drive them think S3. Now let's dive into each one of them. Let's start with EBS. So what is EBS? EBS is a network attached block storage volume that you can attach to EC2 instances. The profit like a network USB drive is not physically inside your EC2 instance. It connects over the network, but it just acts like a physical disk. Now what are the key characteristics of EBS? First, it's a network drive that is important. It's not physically attached to your instance. It uses the network to communicate, which means there's a tiny bit of latency. Not much milliseconds, but it still exists. Because as a network drive, you can detach it from one instance and attach it to another instance fairly quickly. Your instance dies, then detach the EBS volume and attach it to a new instance, your data survives. Second, it's locked to an availability zone. This is critical for the exam we discussed earlier. An EBS volume in U.S. East 1A can only attach to instances in U.S. East 1A. It cannot attach to an instance in U.S. East 1B. If you need to move it to a different AZ, what you have to do is to create a snapshot, then restore that snapshot in the target AZ. We'll cover this shortly. Third, your provision capacity. When you create an EBS volume, you specify the size in GBs and the IOPs, which is the input/output operations per second. You'll build for all the provisioned capacity whether you use it or not. If you provision 100 GB volume but only use 20 GB, you're still paying for the 100 GB. What's the good news? You can increase capacity over time without downtime. Now let's talk about EBS volume types. Know these for the exam. EBS comes in six types. Each optimized for different workloads. Let me start with type 1, that is GP3 general purpose SSD. This is the modern option, this is the newest general purpose SSD. It replaced GP2. Baseline is about 3000 IOPs and 125 megabits per second throughput just for information. You can increase IOPs up to 16,000 and throughput up to 1000 MBPS independently of the volume size. It's cost effective, it's balance performance, that is the default choice for most of the workloads. Use cases are boot volumes, virtual desktops, development environments, low latency applications and so on and so forth. The size is typically 1 GB to 16 GB. Type 2 is GB2 which is general purpose SSD. This is the legacy option, this is the older general purpose SSD but it's still available but GB3 is far better. With GB2, IOPs scales with volume size. Three IOPs per GB so 100 GB volume gives you 300 IOPs. The max IOPs is 16,000 which you hit at about 5000 GB. All volumes can burst up to 3000 IOPs temporarily. If you're designing new systems, please use GB3 and not GB2. Then you have type 3 which is IO2 block express. This is the provisioned IOPs SSD for extreme performance. This is for mission critical applications that need sustained high performance. It offers sub millisecond latency about 256,000, that's the maximum IOPs. This is the most expensive IBS type, you provision exact IOPs you need. Use cases are large databases like Oracle, SQL Server, MongoDB, high performance workloads where latency truly matters. Critical feature. It supports IBS multi-attach. One volume can attach up to 16 EC2 instances simultaneously in the same ASI. It's used for cluster databases. Type 4 is IO1 which is provisioned IOPs SSD, the legacy version. This is the older version of IO2. Maxim IOPs is 64,000. If you're starting new, use IO2 block express. Type 5 SD1, throughput optimized HDD. This is a hard disk drive, not SSD, that's lower cost but it cannot be a boot volume. We covered this earlier in our episodes. It's optimized for high throughput but not for IOPs. Even throughput is about only 500 MBBS. Use cases are big data, data warehouses, log processing, basically sequential read-write workloads where you're streaming large amounts of data. And finally we have Type 6 which is EC1, called HDD. This is the lowest cost IBS option. Also it cannot be a boot volume. It's used for infrequently access data where you just need cheap storage. Maximum throughput is about 250 MBBS. These cases are infrequently access data where cost is more important than performance. So here's the decision tree for EBS types. You need a boot volume, then go for GP3 or IO2. Remember only SSD types can boot. Running a high performance database, then go for IO2 block express. Do you need cost effective balance performance, then you think about GP3? If you need for big data with sequential access patterns, then think SD1 which is HDD. If it's for infrequently access data where you need the cheapest option, then think as C1 which is also HDD. Now let's talk about EBS snapshots, your backups. You can take snapshots on EBS volumes. A snapshot is a backup at a point in time. Snapshots are stored in S3 but you don't see them in your S3 pockets. AWS manages them all behind the scenes. You don't need to detach the volume to snapshot it, but it's recommended for consistency. You can copy snapshots across AZs or regions. This is how you move an EBS volume to a different AZ. Here's the process to move EBS to a different AZ. Number one, take snapshot of the world. volume in US East 1A. Number two, create new volume from the snapshot in US East 1B. And number three, attach new volume to the instance in US East 1B. What about the snapshot features? Snapshot archive. Move all snapshots to an archive tier that's 75% cheaper. Takes 24 to 72 hours to restore. And there's recycled bin, that's to recover accidentally deleted snapshot. Set retention from one day to a year. Fast snapshot restore. Three warmer snapshots. So the first read has no latency. This costs extra. OK, now let's talk about EBS encryption. When you encrypt an EBS volume, everything is encrypted. Data addressed on the volume. Data in flight between instance and volume. All snapshots created from the volume. All volumes created from encrypted snapshots. Encryption uses AWS KMS with AES256. There's minimal performance impact. Encryption and decryption happen transparently. To encrypt an unencrypted volume. Number one, create snapshot of the unencrypted volume. Number two, copy snapshot and enable encryption during copy. Number three, create new volume from the encrypted snapshot. And finally, number four, attach encrypted volume to the instance. What about delete on termination? By default, when you terminate an EC2 instance, the root EBS volume is deleted. But additional volumes are preserved. You can change this behavior, by the way. You might want to preserve the root volume to recover day after instance termination. For the exam, remember these key points. EBS is easy locked. It cannot attach across AES's unique snapshots to move. Simply GP3, GP2, IO1, and IO2 can be boot volumes. IO2 block express supports multi-attach that's up to 16 instances in the same AZ, HDD volumes that's SD1 and SC1 cannot boot volumes. Now let's talk about EFS, elastic file system. EFS is completely different from EBS. EFS is a managed network file system that can be mounted on hundreds or thousands of EC2 instances simultaneously. Think of it like a shared drive that multiple computers can access at the same time. So what does EFS exactly? EFS is a managed NFS, or the network file system. It uses NFS version 4.1 protocol, which is a standard Linux file sharing protocol. The key difference from EBS is that EFS works across multiple availability zones. You can have instances in U.S. East 1A, U.S. East 1B, and U.S. East 1C all mounting the same EFS file system. This is huge for high availability and shared data scenarios. Now what are its key characteristics? Firstly, it's highly available and scalable. EFS automatically replicates your data across multiple AZs. That is if one AZ fails, your data is safe in the other AZs. Secondly, it's expensive. EFS costs about three times more than GP2, EBS volumes. You pay for what you use, not the provisioned capacity. Number three, it's Linux only. EFS works with Linux-based AMIs. Windows instances cannot use EFS. This is a common exam question, so please do remember that. And number four, it uses security groups for access control. That's you can attach a security group to the EFS mount targets, just like you would do with the EC2 instances. Number five, it scales automatically. You don't provision capacity, as you add more files, EFS then just grows. As you delete files, you're billless. There's no capacity planning needed. Number six, it supports encryption address using KMS. Now let's talk about EFS performance modes. When you create an EFS file system, you choose a performance mode. This cannot be changed later. There is the general purpose mode. This is the default. That's the lowest latency. That's for latency-sensitive workloads like web servers, content management systems, or development environments. Then there is the max IO mode, that's for higher latency, but much higher throughput and parallelism. So that's for big data, media processing, workloads with hundreds, or thousands of instances accessing EFS. You also choose a throughput mode. Then there is the bursting mode. Thruput scales with the file system size here. So one TB of storage gives you 50 MBBS baseline plus bursting up to 100 MBBS. Then there is the provision mode. You set throughput independent of the storage size. Example, one GPS, throughput even if you only had 100 GB of data. Then there is the elastic mode. This is recommended. It automatically scales throughput up and down based on the workload. Up to three GPS for reads and one GBBS for writes is what you get. That's perfect for unpredictable workloads. Now what about EFS storage classes? EFS has storage tiers like S3, similar. EFS standard is the first one. That's for frequently access files, it's got standard pricing. There is EFS in frequent access, or as they call EFS hyphen IA. These are for files not access often, slower storage cost, but you pay for retrieval fee. You can save up to 92% on storage costs compared to standard. Then there is the EFS archive. This is for rarely access data. That's file accessed a few times per year. It's 50% cheaper than EFS IA. What about lifecycle management? You could use this to set policies to automatically move files between tiers. An example is move files not access for 30 days to EFS IA. Move files not access for 90 days to EFS archive and so on. This is automatic cost optimization just like S3 lifecycle policies. Let's discuss EFS availability and durability. Standard or multi-AZ? Data is replicated across multiple AZs. It's great for production and provides high availability. There is one zone that is data is stored in a single AZ, it's cheaper. That's over 90% cost savings when compared to standard. It's great for demo test environments or backups where multi-AZs isn't really needed. If that AZ fails, you lose the data, but it's cheap. How can combine one zone with infrequent access for maximum savings? That is EFS one zone IA. So when we do use EFS and what are its use cases? Number one, content management system. So for example WordPress, Drupal, there's multiple web servers that need to access the same content files. Web serving that's shared web content across multiple web servers, data sharing that's multiple applications or instances that need to access the same data sets. Some directory that's user home directories accessible from any instance, here's a real world example. Let's go through. A company runs a WordPress website with 10 web servers behind a load balancer. Now without EFS, each web server has its own copy of WordPress files. Someone uploads an image, it only goes to one server. Other servers don't have it, it's a nightmare there. Now with EFS, all the 10 web servers mount to the same EFS file system so someone uploads an image and there you go, all servers see it immediately, it's perfect. For the exam, so remember, EFS works across multiple A's, that's unlike EBS, which is logged to one A's, EFS is Linux only, Windows cannot use EFS, EFS is more expensive than EBS about three times, use EFS when multiple instances need simultaneous access to the same files, EFS standard is multi-A's, EFS one zone is single-A's and cheaper. Now let's go on to the next section where we compare EBS, EFS and S3, let's put them side by side and understand when to use each one. Let's start with the attachment model, EBS, attached to one EC2 instance at a time, except IO2 multi-attach, which then allows up to 16, EFS mounted by hundreds or thousands of EC2 instances simultaneously, S3 not attached or mounted, accessed via HTTP API calls normally. How about availability zone scope? EBS is logged to a specific AZ, volume in US East 1A cannot attach to the instance in US East 1BV, talked about this multiple times, EFS works across multiple A's, instances in any A's can mount the same file system, S3 is regional service with multi-A's replication that's done automatically. Now let's look at use case patterns, EBS is used for database storage, application root volumes, anything needing block level access, EFS on the other hand for shared content media files that needs to be accessed by multiple servers and then shared application data. S3 you would use that for object storage, backup files, media files for websites, data lakes and archive files. What about the performance? EBS is high performance, IO2 block express can do 256K IOPS and sub millisecond latency, EFS is good in performance too, but higher latency than EBS because it's a network file system. The maximum performance you would get is about 3GPPS. S3 is optimized for HTTP get or put that's about 3,500 put and 5,500 get per second per prefix. Now let's compare the course. EBS is moderate cost because you pay for the provision capacity, GP3 cost about $0.08 per GB per month. EFS on the other hand is expensive, it's pay for what you use. EFS standard costs about $0.30 per GB per month, that is 3 times more than EBS. EFS 1 zone IO can be asked low at $0.016. per GB per month. S3's cheap, S3's standard is 0.023 dollar per GB per month. Glacier Deep Archive is as low as 0.00099 dollar per GB per month as well. What about data persistence? EBS, data persists independently of EC2 instance life. That's the volume survives instance termination unless delete on termination is enabled. For EFS, data persists independently that's independent of any instances. For S3, data also persists independently. There is 11 9s of durability they provide. Want to how do they scale? EBS is manual, you provision capacity, you can increase size but it's a manual operation. For EFS, it's completely automatic. File system grows and shrinks automatically as you add or remove your files. For S3's infinite, no limits on the number of objects or total storage. For our backups now, EBS snapshots to S3, manual or automated via AWS backup or data lifecycle manager. EFS uses the AWS backup service. It can also sync to S3 with AWS data sync. For S3, use versioning, replication, lifecycle policies are built in. What protocols do they use? For EBS, block level storage protocols use. There is no other specific protocol. It's a virtual disk after all. For EFS, remember, it's the NFS version 4.1. That's a Linux network file system protocol. For S3, it would be the HTTP or the HTTPS rest APIs. SDKs are available for all languages. What operating systems do they support? EBS works with any OS. Could be Linux, Windows or Mac. EFS works with Linux only. Windows cannot mount EFS. S3 is OS, independent or diagnostic, accessed via APIs from any OS. Now, let me give you a comparison table summary. For attachment, EBS attaches to one instance. EFS to many instances. S3 is API access. For easy scope, EBS is single, easy, EFS is multi-easy, and S3 is regional. For cost, EBS is medium, EFS is high, S3 is low. For scaling, EBS is manual, EFS and S3 are automatic. For OS support, EBS works with any. EFS is Linux only. S3 is API, so it can work with any. For use cases, EBS is for databases, EFS for shared files, and S3 for objects and media. Now let me give you a decision matrix for the exam. Choose EBS when the question mentions one of these different things. It mentions attach to easy to instance or database storage, which is my SQL, Postgres SQL, Oracle, or it is to be used as boot volume for easy to instance or there is a low latency requirement or there is a high I/OPS requirement where you want to use I/O2, by the way, or there is a single instance needs storage kind of requirement. Use EFS when the question mentions one of these things. That's multiple instances accessing the same files, content management system, WordPress or shared web content, Linux based file sharing, need multi-az file system, automatic scaling needed, so and so forth. And you choose S3 when the question mentions static web hosting, backup and archival, data lakes, media storage, images, videos, need HTTP or HTTPS access, infinite scalability needed or cross-region access needed. Right, so here are some common exam scenarios. Having a MySQL database on EC2, what storage do you want to use? EBS, I/O2 for production, GP3 for dev or test. 10 web servers need to share uploaded images. What do you want to use? You want to use EFS, multiple instances, and handles shared files. Store user profile pictures for a mobile based app. You want to use S3, which supports object storage and HTTP access. Boot volume for easy to instance. EBS, that's the only option that can boot. Share files between window instances. Neither EBS nor EFS window files share use fsx for windows. WordPerside with 5 web service. EFS for shared content. EBS for each service, OS. Archive 100 TB of all data that's rarely accessed. Yeah, I think S3 glacier, deep archive. OK, onto our next section, let's walk through some real world architecture patterns, combining these storage types. Pattern 1, standard web application. The scenario is that you have an e-commerce website with web service, application service, and a database. Now let's break down the architecture into web tier, application tier, and database tier, and what you would use in each of these tiers. So for the web tier, you would want multiple easy to instances. EBS GP3 for OS and application code on each instance. EFS for shared product images and media files. S3 for user uploaded images. That's product photos from sellers and so forth. For the application tier, you want multiple easy to instances as well. You'll want EBS, GP3 for OS and application. Similarly, for database tier, you want RDS, MySQL, EBS, I/O2 for database storage that's managed by RDS. Now why does all of this work? Each instance has its own OS on EBS that's fast and there's low latency. Product images are shared via EFS, all web servers see exactly the same files. User upload goes to S3, which is scalable and delivered via CloudFront CDN. Database gets high performance I/O2 storage. Now onto pattern number two. We're looking at a content management system like, let's say, WordPress. So scenario is WordPress site with auto scaling web service. Let's look at the architecture. You want to use application load balancer, auto scaling group with up to 3 to 20 web service. EFS would be mounted on all web servers for WordPress content. That would be the WP content folder. EBS GP3 would be used for each servers root volume for OS and the WordPress code. RDS, MySQL would be used as the database with EBS I/O2 storage system. S3 plus CloudFront for offload static assets like CSS and JavaScript. Why this works now? WordPress writes uploaded media to EFS. All web servers immediately see the new uploads. Auto scaling can add or remove service, they all mount the same EFS and RDS handles database with high performance storage. Onto next pattern, machine learn training. The scenarios you want to train ML models on large data sets. The architecture. You want to use EC2 GP instances P3 or G4. You want to use S3 to store training data sets that could be terabytes in size. You want to use EBS I/O2 that's attached to instances for fast read during training and then finally S3 for storing the trained models. The process would be store data sets in S3. When training starts copy data to the EBS I/O2 volume, train from EBS that's low latency and often high I/OPS and then save the train model back to S3. Why this works is S3 is cheap for long term data storage. EBS I/O2 for fast training models can train faster with low latency storage and you're able to share the models across a team with S3 for model storage. Next pattern hybrid application. The scenario is application with different storage needs. EC2 instances you want to use is EBS GP3 that's for operating system and application binaries. You want to use EFS that shared configuration files accessed by all instances. You want to use an instance stored to temporarily cache it's the fastest but it's ephemeral and then you want to use S3 to store the application logs and backups. Why does all of this work? EBS for OS is fast and persistent. EFS for config that's all instances get the same configs it's very easy to update then. Instance store for cache that's ultra fast temporary storage and S3 for logs is cheap long term log storage onto our next pattern. Development and production environments. The scenarios you want to separate dev and prod and minimize dev costs. For development you want to use EFS one so that shared dev files is 90% cheaper than standard. EBS GP3 that's for dev instance root volumes. For dev backups you want to use S3 standard I/A that's cheaper than standard. For prod for sharing production files and high availability you want to use EFS standard multi-az. You want to use EBS I/O2 for production database it's high performance. You want to use S3 standard for production backups and media that's fast access and S3 glacier to archive old data. Now why this works is because the dev uses cheaper storage options that's one zone or standard I/A while the prod uses high availability options that's multi-az and high performance options and there's a write balance of cost versus the reliability. For the exam know these patterns question often describe a scenario and ask what storage architecture should you use. Look for the keywords multi-instances plus shared files point you to EFS database point you to EBS I/O2 media or images think S3 boot volume you know it's EBS GP3 big data would be S3 plus EBS ST1 for archive you know it's S3 glacier. Now for the interesting section let's cover the common exam traps for storage. Trapped number one EBS is easy locked question an EBS volume in US East 1A needs to attach an instance in US East 1B. how people think just attach it. And it's wrong. EBS volumes are easy locked. So the answer is to create a snapshot of the volume, then create a new volume from that snapshot into us East 1b. This comes up constantly and we've discussed this multiple times. Top number two, EFS is Linux only question. Windows instances need to share files. Use EFS? No, you can't. EFS only works with Linux. For Windows use FSX for Windows file server. Top number three, S3 is not a file system. Question, can we mount S3 as a drive on EC2 instance? The answer is you cannot mount S3 as a traditional file system. S3 is object storage, access to via an API. There are third party tools like S3FS that can mount S3, but this is not native AWS functionality and has serious performance limitations. Top number four, instance store versus EBS. The question is, you need highest IO performance for temporary data, do you want to use EBS or instance store? The answer is instance store. It's physically attached to the host, so it's definitely got better performance than EBS. But remember, it's ephemeral, that is data is lost if the instance stops. Use instance stores for temporary cache, scratch data, or buffers. Use EBS for persistent data that must survive instance stop or start. Next drop, HDD volumes cannot boot. The question is, can you use ST1 HDD for EC2 boot volume to save costs? The answer is no. Only SSD volumes that is GP2, GP3, IO1, IO2 can be boot volumes. Top six, EBS multi-attach limitations. Question is, can you share an EBS volume across 20 instances in different Asis? The answer is no. EBS multi-attach can only be used for IO1 and IO2 volumes. There's a maximum of 16 instances. All instances must be in the same Asis. It requires cluster-aware file system. So for cross-Asis file sharing, you want to use EFS. Trap 7, EFS cost. Is EFS a cost-effective shared storage for dev environment? People think EFS is always expensive. But if you use EFS one zone IA for dev, it's 90% plus cheaper than EFS standard multi-AZ. Remember that. Trap 8, S3 storage class choice. The question is, can you store database backups that might be needed for disaster recovery using S3? People might choose glacier deep archive because that is the cheapest. The better answer is to use S3 standard IA or glacier instant retrieval. Deep archive takes 12 to 48 hours to retrieve in a disaster you probably need faster access. Trap 9, Snapshots and Performance. Can you take EBS snapshots during peak traffic? It's a bad idea, you know. Snapshots use IO. During high traffic, snapshot operations can slow down your application itself. So what you want to do is take snapshots during off-peak hours or use fast snapshot restore FSR if you need snapshots during peak. Trap number 10, Delete on Termination. Question, instance-isterminated root EBS volume is gone. Why? Remember by default, root EBS volumes have delete on termination enabled. They're automatically deleted when the instance terminates. Additional volumes do not have this enabled by default. They survive termination. So if you need to preserve the root volume, disable delete on termination. Trap 11, EFS performance mode is permanent. Question, if you had an EFS with general purpose mode and you need max IO now, can you change it? The answer is you cannot change performance mode after EFS has been created. You had to create a new EFS with max IO mode and then migrate the data. So it's important to choose carefully at creation time. And finally Trap 12, S3 versus EBS for static websites. The question is, you want the whole static website? Do you want to use EBS or S3? Well, you recommend S3. S3 has static website hosting built in its design for this. EBS would require you to run a web server on EC2 which is absolutely unnecessary overhead and cost. Now onto the next section, exam quick tips. It's rapid fire exam tips for storage. Tip 1, keywords matter. Attach to instance, think EBS. Multiple instances plus shared, think EFS, HTTP access or objects. Think S3. Tip 2, performance hierarchy. The fastest of the lot is instant store, but remember it's ephemeral. Then you have the very fast which is the EBS IO2 block express. Then you have the fast which is EBS GP3. The good is the EFS and then you know S3 is API based. Tip 3, cost hierarchy. The most expensive is the EFS standard multi-AZ. The medium expensive is the EBS and the least expensive is S3 especially glacier. Exception is EFS one zone IA that can be cheaper than EBS. Tip 4, durability. All the three are highly durable. For EBS data is replicated within AZ. For EFS data is replicated across multiple AZs and for S3 remember there's 119s of durability they offer. Tip 5, scalability. EBS provides manual scaling. EFS provides automatic scaling and S3 provides infinite scaling. Tip 6, multi-AZ support. EBS, no it's AZ locked EFS. Yes, it works across AZs and S3. Yes, it's regional but automatically it supports multi-AZ. Tip 7, backup strategy. For EBS you want snapshots to be stolen to S3. For EFS, AWS backup or data sync to S3. For S3, versioning replication or use lifecycle policies. Tip 8, boot volume. Only EBS can be a boot volume must be SSD though, GB2, GB3, IO1 or IO2. Tip 9, database storage. For production database, you want to use EBS IO2. For dev or test database, you want to use EBS GP3. Never use EFS for databases that's too slow. And for tip 10, media files decision. For static media, serve to users use S3 plus cloud front. For media shared between application service, use EFS and for media for video editing workstation and so forth, use EBS IO2. Alright everyone, that's episode 8 on design storage architectures and their comparison. We covered a lot today. We compared three fundamental storage types, block, file and object. We dove deep into EBS that's your virtual hard drives attached to easy to instances. It's got six types, it's easy locked, it's great for databases and boot volumes. We then explored EFS, which is a shared network file system that works across multiple easy, it's perfect for when multiple instances need to access the same files. It's Linux only, it's more expensive than EBS, but it's automatically scalable. Then we reviewed S3, which is object storage for billions of files. We covered this deeply in our last episode, but today we saw how it fits into a broader storage architecture. We compared them side by side when to use each one, performance, characteristics, costs and their limitations. We walked through six real world architecture patterns showing how to combine these storage types effectively and we covered 12 exam traps that trip people up on the test day. So the key takeaway, each storage type solves different problems. EBS for single instance block storage, EFS for multi-instance file sharing, S3 for scalable object storage, so choose based on your specific requirements. In our next episode, episode nine, we're diving into AWS databases, RDS, Aurora and Elastie Cash, then to use relational databases, how multi-AZ works, read replicas for scaling and Aurora's unique architecture. Now, if this episode helped you understand storage architectures, please do leave a five-star rating on Spotify and share with anyone studying for the AWS exam. So until next time, keep studying, keep practicing and I will see you in the next episode. This is Baloo signing off. Bye.