Oliver Berger | Mon, 10 Jul 2017
We wanted to take a quick time out to discuss the new cost allocation functionality for AWS Elastic Block Store (EBS) snapshots and how GorillaStack complements the service in an intelligent fashion.
You’re probably already aware, but here’s a pithy summation for you: Amazon EBS is an Amazon Web Services (AWS) block storage system that’s optimized for persistent data storage, creating available storage volumes tied to Amazon EC2 instances. It enables users to maintain file system data beyond when you shut down an EC2 instance.
While an Amazon EBS volume can only be hooked into a single EC2 instance at any given juncture, snapshots alleviate this restriction.
Let’s say you wish to establish a copy (or multiple copies!) of a volume as a backup. When you take a snapshot, a backup file is automatically created that reflects the exact state of the EBS volume in question at that time. A matching EC2 instance can also be generated, enabling identical content publishing on different servers.
This may be useful, for example, in restoring EC2 instances that have failed or to launch new similar instances if you want to spin up a fleet.
Here’s where things get interesting: Your first snapshot of a specific EBS volume represents a full backup to Amazon S3. However, successive snapshots only save the blocks that have changed since the previous snapshot was created. And once such a snapshot is erased, only the unique blocks within that specific snapshot are deleted.
You can now view cost allocations for EBS snapshots by tag. Of course, you’ll want to have a good tagging policy in the first place if you’re to make the most of this feature. This allows you to track the growth of cost over time and identify where you could be saving, particularly if you choose to export the data and analyse it through a BI tool.
Simon Elisha from AWS breaks down EBS pricing and how it works
Something to bear in mind (and here’s where it gets interesting) is that snapshots are incremental, so deleting 1gb of data may not actually eventuate in that full saving. You’re only actually removing the difference between that snapshot and the previous one (not the full amount), so don’t overestimate!
EBS snapshots are great and all, but with the ease associated with whipping up EC2 instances, matters can still quickly spin out of control. All those volumes and snapshots pile up and are often forgotten over time, and—despite how successive snapshotting operates—the data adds up and storage costs rise.
By leveraging your tags, you can use GorillaStack's AWS Automation Tools to create life cycles for volumes and associated snapshots, ensuring they’re terminated once their usefulness comes to an end. Set rules that define a period after which specifically tagged snapshots and volumes can be deleted.
GorillaStack provides a couple of options: set and forget to automatically schedule removal of EBS snapshots, volumes and AMIs or schedule EBS snapshots automatically. Alternatively you can set rules that notify you via email, SMS, HipChat or our AWS Slack Integration when specific EBS is eligible for deletion and you can choose to act.