Four questions to ask about new AWS announcements
From new features to price cuts, Amazon Web Services is known for releasing updates and improvements at a fairly steady clip. This is awesome for AWS users—but it can also be tricky to navigate. How can you ensure that your infrastructure is optimized for power and efficiency when you’re faced with an ever-changing service catalog?
Making the most of new AWS updates comes down to understanding how they can impact you. Which is why when Amazon announces something new, we ask ourselves these four questions.
1) Will this benefit me?
Sure, it’s shiny and new. But Amazon tools have a broad variety of applications—and only some of them will suit the needs of a distinct use case. Before spinning up a new (or newly price-reduced) AWS product, make sure you know what you’re signing up for—and whether you actually need it.
AWS products each perform differently according to a set of parameters; namely vCPU, ECU, Memory (GiB), and Instance Storage (GB). When a new product is released, you’ll want to take note of how it performs across these dimensions and compare that against the products you’re currently using to satisfy your own memory, storage, and compute needs. It’s helpful to simply chart out the differences, such as in this table we made when Amazon announced the M4 instance type
Once you’ve determined that a new service outperforms the services you’re currently using across your priority metrics, you’ve jumped the first hurdle—but there are a few more inquiries to address before going all-in.
2) Is it worth the price?
Sure, it’s powerful; but is it cost-efficient? When you’ve determined that a new or improved feature is appropriately powerful to suit your needs, the next step is confirming that it delivers that power at an optimum price-per-performance-unit. It may be twice as powerful as what you’re currently using—but if it costs three times as much, that won’t do.
You can determine the cost-efficiency of a service by comparing its price-per-X, where X is vCPU, ECU, GiB, GB, or any other deliverable. Again, we’ve found it easiest to simply chart out those values against existing offerings, as we did when AWS released the t2.large:
As you can see in this example, the fact that t2.large is the most powerful of these options doesn’t mean that it’s the mostcost-effective for each use case. Depending on whether your priority lies with ECU or GiB and just how much you anticipate you’ll need the t2.large’s burst capacity, you might not find it worth the price over an r3.large or c4.large.
3) Will this fit within my existing infrastructure?
Even if you’re certain that a new or updated AWS service will represent a worthwhile addition to your setup, that doesn’t necessarily mean that you should start using it immediately—you’ll have to time the infrastructure change carefully to avoid unintended (and costly) consequences.
If you’ve purchased Reserved Instances for your existing infrastructure, any change in instance types might render those Reserved Instances inapplicable to your new setup—and could lose you far more money than you’d hoped to save by switching to a more cost-efficient service. You can determine the financial impact of such a change by referencing this formula, where “annualized cost” refers to the hourly rates of your old family’s RIs and of any new family instances, and “old family RI write-off” refers to the portion of the old family RI cost that remains at the time of the family change:
If the resulting “family change % savings/loss” value is negative, changing to the new family will be potentially less cost-effective than sticking with your existing infrastructure until your existing RIs expire or see some more use. If the value is positive, making an immediate change will likely prove your most cost-effective option.
4) Where will I put it?
When budgeting for the implementation of a new AWS service, there’s more to consider than just the cost-per-hour. When you decide to take a new or updated service for a spin, you’ve got to ensure that you have a cost-effective Region and AZ to put it in—or face hefty fees for moving data in or out of it across the rest of your infrastructure.
First, you should take note of the prices to transfer data to and from the service you’ve got your eye on. As a general rule, cross-Regional data transfer will be more costly; so if you’ll regularly be transferring data in and out of this service, you’ll want to ensure that it’s available in the Region or Regions within which you primarily operate. Further minimizing cross-AZ data transfer can potentially reduce these fees further. Your safest bet will almost always be to stick to spinning up new instances within the same Region and AZ as the other aspects of your infrastructure with which they’ll be interacting—so make sure this is doable before spinning up that shiny new instance in the first Region you see.
Stay in the know
AWS announcements can come fast and hard, especially this time of year—but by keeping these questions in mind, you can quickly understand the impact each has on you.
Want to stay up-to-date on all the latest news in AWS? Keep up with all the latest AWS announcements this week and beyond by subscribing to our newsletter.