EBS Snapshots Now Support Cost Allocation

Historically, one big item in AWS cost reports that wasn't able to be assigned various costing tags has been EBS snapshots. The reasoning behind this was presumably tied to their differential nature-- it's presumably non-trivial to allocate thousands of very small amounts of data to a cost tag, nor was it a particularly high priority. After all, unless you're doing something strange you're unlikely to be spending significant amounts of money on snapshots.

Of course, AWS is vast enough that many of us are indeed doing something strange! In some cases I've seen snapshot costs rise into the tens of thousands.

As of today, tags propagated to your snapshots now act as cost allocation tags once enabled in your billing dashboard. Combined with a tool (I'm partial to Lambda functions) that propagates  tags to from instances to EBS volumes, and then further to snapshots, you get a more accurate cost picture for various environments, business units, and projects.  

Reduced Redundancy S3 is Dead

Once upon a time, Amazon offered four tiers of object storage:

  • Standard S3 (this is S3 as commonly discussed)
  • Infrequent Access S3 (costs less, but you pay to access it more frequently) 
  • Reduced Redundancy S3 (similar to standard S3, but offers 4 9's of durability instead of Standard S3's 11 9's)
  • Glacier (long term storage that doesn't need to be available instantly)

Officially, Reduced Redundancy S3 still exists. That said, it's apparent that Amazon isn't moving forward with the offering, based upon two datapoints:

First, they no longer talk about it at all in blog posts or other public discussions of S3 storage classes

Second, and more relevant to optimizing costs, S3-RR no longer participates in service discounts that affect the other S3 tiers.

As a direct result, while S3 Reduced Redundancy still exists, you will pay more to store objects there than you will in Standard S3, while achieving worse object durability. 

In conclusion, if you've got any objects living in Reduced Redundancy, it's time to migrate them to standard S3. Your bill and your data durability will both thank you for it.

RI Coverage Reports: AWS Hits You With the Shame Stick

Today Amazon announced Reserved Instance coverage reports in an effort to simultaneously help you control your costs while feeling bad about your infrastructure.

At an implementation level this makes a lot of sense; define a percentage threshold for instance hours you want covered by reservations (a common number for initial baseline reservations is 70%), and highlight the deviation whenever you dip below that threshold. Many of my clients target a RI coverage rate above 90%-- which you can do once you have an accurate forecasting model, and automation that handles RI purchasing.

So far, this sounds great-- so where's the problem?

Stragetically, this continues to position AWS as a cloud computing environment where you need to plan your spending one or more years in advance. 

As they themselves say, one of the best aspects of AWS lies in its elasticity. You can have your baseline usage squared away, run a Super Bowl ad, scale to 1000x your typical volume, and then dial it back down as traffic ebbs, all in near realtime. That model's diametrically opposed to a CapEx centered world wherein you have to plan in advance what your usage is going to look like, and commit to 1 or 3 years at that capacity. (If you can do that accurately enough, the economic benefits of AWS become more unclear.)

As a result, if you don't know what your usage is going to look like in three months, AWS's approach to RIs begins to take on a darker tone, where the unstated message is "you're terrible at forecasting and should feel bad about that." 

Further, it will be interesting to see how many of the cost analysis vendors such as CloudCheckr, Cloudability, CloudDyn, and others respond to this move. I firmly believe that visibility into your AWS bill should be something that AWS provides natively, so moves like this one are definitely in the customer's interest. How this is going to impact areas of Amazon's partner ecosystem remain to be seen. 

If you have questions about this or other AWS billing topics, please email me-- I'm eager to hear your perspective!

Reserved Instance Purchases Now Less Terrifying

Buying Reserved Instances just got a lot easier.

Yesterday evening Amazon announced a change to how reserved instances work. You can now modify your environment on the fly while still taking advantage of RIs. 

For example, you have an m4.xlarge reserved instance. You can now apply that reservation to four m4.medium instances instead-- or vice versa. 

In the inverse (you have an m4.medium reservation and switch to an m4.xlarge) the instance reservation discount will still apply-- you'll get a discount on 1/4 of your usage of that instance, and pay on-demand for the remaining 75%. AWS "does the right thing" here-- but it's going to make unwinding your monthly bill a bit more convoluted!  

Benefits:

  • This applies to existing RIs you've already got, effective for this month's billing cycle. 
  • You can rearchitect your instance size.

Caveats:

  • This only works inside of instance families. You can't use an i4 reservation for a m3.medium. As a result, you still need to determine the general performance profile of your application prior to locking in an RI purchase.
  • This only applies to shared tenancy. If you're using dedicated hardware for your instances (generally used either for security reasons or to qualify your cloud spend as CapEx) this doesn't apply to you.
  •  "Instance Families" only apply to a single generation. When i3 instances came out last month, they offered significant cost savings over the previous generation i2 instances-- but i2 reservations won't work here. As a result, 1 year RIs continue to be my default recommendation unless you really know what you're doing.