AWS Storage Services
This course will introduce you to the foundations of AWS storage, plus the Amazon Elastic Block Store, known as EBS and Amazon EC2 Instance storage.
If you have any feedback, queries, or comments relating to this course, feel free to reach out to us at email@example.com.
This course has been designed to introduce you to some of the AWS storage services that you need to be familiar with when taking the AWS Solutions Architect - Associate exam
Once you have completed this course, you will understand what EBS and EC2 Instance storage is and when you might use each within your environment
This course has been designed for:
- Storage and operations engineers responsible for maintaining and storing data within the enterprise
- AWS Architects who are designing new solutions requiring data storage capabilities
- Those who are looking to begin their certification journey with either the AWS Cloud Practitioner or one of the three Associate-level certifications
This is a beginner's level course to AWS storage and, therefore, you do not need any prior knowledge of these services
Hello, and welcome to this lecture covering EC2 Instance Level Storage. Which is referred to as an instance store volume. The first point to make about EC2 instance store volumes, is that the volumes physically reside on the same host that provides your EC2 instance itself, acting as local disc drives, allowing you to store data locally to that instance. Up until now within this course we have discussed persistent storage options. But instance store volumes provide ephemeral storage for you EC2 instances.
Ephemeral storage means that the block level storage that it provides offers no means of persistency. Any data stored on these volumes is considered temporary. With this in mind, it is not recommended to store critical or valuable data on these ephemeral instance store volumes, as it could be lost, should an event occur. By an event, let me explain under what conditions that your data would be lost, should it be stored on one of these volumes.
If your instance is either stopped or terminated, then any data that you have stored on that instance store volume associated with this instance will be deleted without any means of data recovery. However, if your instance was simply rebooted, your data would remain intact. Although, you can control when your instances are stopped or terminated, giving you the opportunity to either back-up the data or move it to another persistent volume store, such as the elastic block store service. Sometimes this control is not always possible. Let's consider you had critical data stored on an ephemeral instance store volume and then the underlying host that provided your EC2 instance and storage failed. You had no warning that this failure was going to occur, and as a result of this failure, the instance was stopped or terminated. Now all of your data on these volumes is lost. When a stop and start, or termination occurs, all the blocks on the storage volume are reset, essentially wiping data. So, you might be thinking, why use these volumes? What use do they have if there is a chance that you are going to lose data? They do, in fact, have a number of benefits.
From a cost perspective, the storage used is included in the price of the EC2 instance. So, you don't have an additional spend on storage cost. The I/O speed on these volumes can far exceed those provided by the alternative instance block storage, EBS for example. When using store optimized instance families, such as the I3 Family, it's potentially possible to reach 3.3 million random read IOPS, and 1.4 million write IOPS. With speeds like this, it makes it ideal to handle the high demands of no SQL databases. However, any persistent data required would need to be replicate or copied to a persistent data store in this scenario. Instance store volumes are generally used for data that is frequently changing; that doesn't need to be retained, as such, they are great to be used as a cache or buffer. They are also commonly used for service within a load balancing group, where data is replicated across the fleet such as a web server pool.
Not all instance types support instance store volumes. So, if you do have a need where these instance store volumes would work for your use case, then be sure to check the latest AWS documentation to ascertain if the instance type you're looking to use supports the volume. The size of your volumes, however, will increase as you increase the EC2 instance size.
From a security stance, instance store volumes don't offer any additional security features. As to be honest, they are not separate service like the previous storage options I have already explained. They are simply storage volumes attached to the same host on the EC2 instance, and they are provided as a part of the EC2 service. So, they effectively have the same security mechanisms provided by EC2. This can be IIM policies dictating which instances can and can't be launched, and what action you can perform on the EC2 instance, itself. If you have data that needs to remain persistent, or that needs to be accessed and shared by others, then EC2 instance store volumes are not recommended. If you need to use block level storage and want a quick and easy method to maintain persistency, then there is another block level service that is recommended. This being the elastic block store service.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 90+ courses relating to Cloud reaching over 140,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.