At the end of August 2012, Amazon Web Services released their latest service offering – a long-term archive service called Glacier. As a complement to their existing active data access service S3, Glacier provides long term storage for “cold” data – information that has to be retained for a long time but doesn’t require frequent access.
What Exactly is Glacier?
Many organisations need to retain data in archive format for extended periods of time. This is for regulatory or compliance purposes or may simply be part of their normal business process. Good examples are medical, healthcare, financial or media (video and audio) data. Typically for many IT departments, backup has provided a lazy way of archiving information. Access to backups retained for up to 10 years provides a cheap and rudimentary archive service. However backup isn’t archive (see my recent article on the subject) as an archive provides additional features around data management and security. Glacier enables AWS customers to store their long-term retention data within Amazon’s existing data centres at a very low cost, starting at $0.01/GB per month. The low cost is tempered with rather leisurely access times of between 3-5 hours for data retrieval.
Within Glacier, data is stored in vaults. Up to 1000 vaults may be created per AWS region, with each vault providing individual security credentials via Amazon’s IAM (Identity and Access Management) service. Within a vault, data is stored in an archive, which consists of one or more files. Obviously if multiple files need to be stored together for consistency purposes then they can be stored as a single archive. An unlimited number of archive files can be created, with a limit of 40TB on any single archive file itself.
Data uploaded to Glacier is stored using AES-256 encryption, managed by AWS. Customers requiring their own encryption are advised to pre-encrypt their data before upload.
Amazon are claiming a data “durability” level of 99.999999999% per archive although I’m not really sure how they define the term “durability” and exactly what that means in terms of data loss.
As mentioned earlier, data retrieval is between 3-5 hours per archive. Retrieval requests (or jobs as they are known in Glacier) are queued asynchronously and can be notified once complete via AWS SNS (Simple Notification Service). Once data is retrieved, it is available for access to the customer for 24 hours. The long retrieval time implies that the majority of Glacier data is stored on tape, with retrieval resulting in a copy to disk for general access. Based on the costs, this also makes sense.
The Charging Model
Charging for Glacier is more complex than the other AWS offerings and includes the following components:
- $0.01/GB/month for storage of data
- Data upload – no charge for data volume
- Upload and retrieval requests – $0.05 per 1000 requests
- Archive query commands (list vault contents, get job status, delete objects) – no charge
- Data retrieval – 5% of archive per month for free, $0.011/GB upwards after that
- Data out (moving data outside an AWS region) – $0.12 – $0.05/GB dependent on volume
- Moving data to EC2 – no charge
- Deletion of data less than 90 days old – $0.033/GB
It’s interesting that there is a charge for deleting new data, presumably to encourage users to use the service for the purpose it was intended. In addition, only 5% of the archive can be retrieved per month without incurring costs (although data out incurs a cost), however there are no costs for transferring data to EC2. This creates an ecosystem that encourages data to be kept in Glacier, using EC2 as the indexing and search or refresh mechanism.
What’s Not Included
Glacier itself is simply a large storage vault for data. All objects are stored using 138-byte character keys. Data access is managed via REST-based APIs that can also be developed using pre-coded Java and .NET SDKs. This means there are no facilities within Glacier for providing some of the most fundamental parts of an archive – notably metadata and indexing capabilities. These need to be developed by the user themselves and as yet I haven’t found anyone offering services that use Glacier as their storage platform. There are a few little quirks to bear in mind too. For instance, vaults are inventoried on a daily basis, so could be inconsistent with any external index the user creates.
The Architect’s View
Amazon have provided a framework and storage repository that could be used by many organisations to store their data over the long term. This does not mean that tape is dead – far from it – Glacier itself is certainly using tape technology. What Amazon are providing is a data store against which 3rd party developers can create their own archive solutions in a similar way to that being used for S3 (think Nasuni or Jungledisk). There are already many other cloud archiving solutions available today (see the same recent article) and on its own Glacier doesn’t represent direct competition, but rather provides another storage platform in which data can be stored. However there are a few things to consider when using a Glacier-based service;
- The indexing of data is purely based on any 3rd party vendor’s indexing system or needs to be managed by the end user
- Taking data out of the archive to move elsewhere will incur a cost
- Refreshing data within the archive will incur a cost
Glacier and the supporting services could therefore represent a significant and unexpected lock-in for customers.
Overall, Glacier does provide a framework against which developers can create new services for archive and that’s a good thing. Cost will be a significant factor for many and the marketing-set price of $0.01/GB/month certainly sounds attractive. Like the other AWS offerings, I’m sure Glacier will be very successful.
- Amazon Glacier service puts tape in a very different place (Ovum)
- Amazon cloud storage options enhanced with Glacier (Datacenter Journal)
- Is Amazon’s Glacier Cloud Storage a Good Deal? (Network Computing)
- Netapp: The Inflexibility of Flexvols (10,222)
- Windows Server 2012 (Windows Server “8″) – Storage Spaces (9,679)
- Enterprise Computing: Why Thin Provisioning Is Not The Holy Grail for Utilisation (8,064)
- Comparing iSCSI Targets – Microsoft, StarWind, iSCSI Cake and Kernsafe – Part I (6,031)
- Review: Compellent Storage Center – Part II (5,679)
- Data ONTAP 8.0 – Part III (5,170)
- Why Does Microsoft Hyper-V Not Support NFS? (5,087)
- Windows Server 2012 (Windows Server “8″) – Virtual Fibre Channel (4,546)
- How To: Enable iSNS Server in Windows 2008 (4,546)
- Back to Blogging (4,455)
- Windows Server 2012 (Windows Server “8″) – Storage Spaces (10)
- ViPR – Frankenstorage Revisited (8)
- 3PAR Continues to be HP Storage Cornerstone (8)
- Managing Microcode Upgrades (6)
- Netapp: The Inflexibility of Flexvols (6)
- HP Discover – Las Vegas 11-13 June 2013 and Software Defined Storage (5)
- Data ONTAP 8.0 – Part III (5)
- Choosing Between Monolithic and Modular Architectures – Part II (4)
- Choosing Between Monolithic and Modular Architectures – Part I (3)
- EMC Releases VNX and “Breaks Records” (3)