Storage
Mobility
Protection
Analysis and control
TOPICShare
Subscribe to our blog
Thanks for subscribing to the blog.
January 12, 2015
Topics: AWS3 minute read
Amazon Storage Types
Of the most common questions that I get asked, defining the difference between S3 (Simple Storage Service) and EBS (Elastic Block Storage) is pretty high on the list. The key characteristics that make up the differences are vital to understand. Everything from design to architecture to replication is dependent on these storage services.
There are two major types of storage in Amazon thought you generally also hear about a third type. We break each of these into a quick description:
- Elastic Block Storage (EBS) – Default storage used by EC2 instances as virtual hard disks. Performance typically tied to device size or Provisioned IOPS (more on this later). Backups are created by using AWS Snapshots
- Simple Storage Service (S3) – Object based storage accessible via HTTP/HTTPS protocol. Single objects cannot exceed 5TB in size. S3 objects are automatically replicated to multiple devices and locations within the same region.
- Glacier – Designed for longer-term archives of objects rarely read. Slow recovery times but very cheap per GB to store. Works nicely with S3 lifecycle policies to archive data.
Ok, now that we have an idea of the storage services, we should start talking about how they can be used. Hopefully, we all understand that our computers (tablet, mobile, Cardiff Electric Giant [I can’t be the only Halt and Catch Fire fan]) have internal storage devices. These hard disks are used to store our OS, applications, and files. Let’s examine how AWS handles this.
Elastic Block Storage (EBS)
Amazon defines EBS as persistent block level storage for use with EC2 instances. The important thing to note is that EBS is just like your hard disk with a bunch of great capabilities. One of the most interesting features is that AWS will automatically replicate your EBS volumes within the same Availability Zone. This means that you get added protection for physical failure in the Availability Zone.
Another feature of this storage is that you control exactly how much of a volume you need. When you provision a new volume, you can assign the storage size. When choosing General Purpose SSD devices, you get 3 IOPS per GB provisioned up to a sustained amount of 3,000 IOPS. For applications that need high IO, you can purchase Provisioned IOPS for your EBS Volume. For a complete breakdown on the types and performance see theAWS EBS Guide. As of November 2014, AWS announced coming support for 16TB EBS volumes. This was a huge jump from the maximum of 1TB previously.
AWS provides EBS based snapshots to create full back ups of your volumes. Creating new instances from EBS snapshots is simple and fairly quick. Another nice feature is that you only pay for the storage that you are using. If you backup 50GB of data in your first snapshot and then add 5GB of changes before your second snapshot, the cost is only for the 5GB of added blocks.
Encryption has always been of high importance to some customers out there. AWS now has EBS encryption and now you can even use your own encryption keys. This is huge as there has always been a nagging concern about storing unencrypted data in the cloud.
One big downside to EBS is the inability to share the disks between EC2 instances. A single EBS Volume can only be attached to a single EC2 instance at any given time. This translates to some interesting changes to how we traditionally handled application high availability. Your application must be able to replicate at the App Level to multiple EC2 instances and cannot rely on traditional shared-disk clustering.
But what about data that needs to be shared with many sources or data that is static and rarely changed? In our next section, we will investigate Object Storage and S3. We will learn more about how to build applications or even bootstrap an entire build using S3.
Other articles in this series
