aws meetup - exploring ways to buy ec2 capacity

Exploring ways to buy EC2 capacity

Antti Siiskonen

CTO, Alma Mediapartners Oy

Agenda

• Introduction

• Costs of computing on EC2, running hours

• OnDemand instances

• Reserved instances, standard & convertible, regional benefit, marketplace, consolidated billing

• Spot capacity

• A guide to control spot risk

• Takeaways

Who's this guy?

• Antti Siiskonen, Tampere University of Technology 1996-2006, MSc Software Engineering, Networks and Protocols

• Plenware Oy 1999-2002

• Atostek Oy & Staselog Oy 2002-2008

• Alma Media Interactive Oy & Alma Mediapartners Oy 2008-

• I live in Tampere, 39, married, three children

• CTO, infrastructure design, problem solving, helping people

• AWS stuff since late 2011, using EC2, VPC, S3, CloudFront, CloudFormation, Elastic Beanstalk, RDS, etc

Alma Mediapartners Oy

• part of Alma Markets

• etuovi.com, etuovi sisustus, autotalli.com, vuokraovi.com, gofinland.fi

• kivi, nettikoti, websales, autosofta, urakkamaailma, autojerry ..

• 2015 turnover 13.7M€, profit 2.7M€

• some 100 people, maybe 40 of which are in IT

• software development is done mostly in-house with assistance from subcontractors

Costs of computing on EC2

• generally pay only for what you use• running hours of virtual machines

• storage

• network traffic

• http requests

• etc

• most of Mediapartners' AWS costs from EC2 running hours

Why so many running hours ..?

• the cloud way of doing things follows a single responsibility principle• translates to one responsibility or one application per EC2 instance

• should lead to resilient solutions where instances are mostly expendable

• unfortunately also leads to wasting cpu cycles and therefore money

• a lot of applications are mostly idle waiting for something to do

• serverless computing would be a brilliant solution to this dilemma but we (our company and many others) are not quite there yet

Ok, many hours, how to get them cheap?

• there are multiple options when buying the EC2 capacity• OnDemand instances

• Standard Reserved instances

• Convertible Reserved instances

• Scheduled Reserved instances

• Spot instances

• Dedicated hosts

OnDemand instances

• this is the usual entry point to EC2

• easy and relatively cheap to get started when trying out something

• AWS does it's best to keep the instance running

• a static instance does not cease to exist if it is stopped, only "ephemeral storage" is erased

• stop-start cycle triggers migration to different hardware

• no upfront fee

• high hourly cost but we can stop or start an instance at any time

Standard Reserved instances

• we make a commitment for one year or for three years

• in return we get a capacity reservation and a discount

• we are charged for every hour whether we use capacity matching the reservation or not (careful!)

• it's a billing trick really, a reservation is not attached to any specific EC2 instance

• we may pay some or all of the costs upfront and the sooner AWS gets their money, the lower the total price will be

• standard reservation is rigid

How much can we save with std reservations?

How much can we save with std reservations?

• for one year reservations• no upfront 24%• partial upfront 35%• all upfront 37%

• for three year reservations • partial upfront 54%• all upfront 57%

• not a huge difference between partial upfront & all upfront• three years is a very long time in computing (careful!)

Convertible Reserved instances

• make a commitment for three years (the only option!)

• in return we get a discount

• this reservation is convertible over instance types, but also over instance families, operating system, tenancy and payment options

• increased flexibility but lower discount than with Standard Reserved instances

How much can we save with convertible reservations? m4.large

How much can we save with convertible reservations?

• for three year reservations• no upfront 32%• partial upfront 42%• all upfront 43%

Regional benefit for Reserved instances

• AWS customer can choose to waive the capacity reservation• in return the "reservation" and discount are no longer restricted to a

single AZ and may be applied to matching instances on any AZ• region constraint remains – only AZ constraint is relaxed• can be applied to standard and convertible reservations• handy when using auto scaling and spanning multiple availability

zones• figure out your average or median level of EC2 consumption and buy

matching amount of reservations with regional benefit enabled

Unused reservations can be bought and sold

• there is a reservation "marketplace" on AWS console• unused reservations can be put for sale mid-term• US bank account is required for receiving money

What is consolidated billing?

• a single AWS account with a billing agreement ("buyer" or "master")

• other accounts that are linked to the billing agreement ("linked")

• two levels of hierarchy at most (afaik)

X

A B C D

Buyer account

Linked accounts

Why consolidated billing?

• simplifies payment procedure – no more credit cards, no need for multiple billing agreements

• isolate resources

• allocate costs per account

• get volume discounts accumulated over all linked accounts

• makes it easier to monitor cost accumulation from a single place when operating multiple AWS accounts

• reservation discounts are applied to the whole "tree" of accounts, exact details are a bit unclear

Spot Instances

• spot is a market for otherwise unsold EC2 capacity

• "no-one seems to pay OnDemand or Reserved price for this capacity, can we sell it at a lower price to get some money from it?"

• spot price is continuously calculated by AWS based on availability and demand

• we set an upper limit as to what we are willing to pay at most ("bid")

• if the current spot price rises above our bid our instances may be terminated and the capacity sold to someone who's willing to pay more

Pricing history is visible on AWS EC2 console

So how much can we save by using spot ..?

instance type az hourly price savings

ondemand spot

m4.large $0,1320

eu-west-1a $0,0248 81,2 %

eu-west-1b $0,0154 88,3 %

eu-west-1c $0,0179 86,4 %

m4.xlarge $0,2640

eu-west-1a $0,0363 86,3 %

eu-west-1b 0,0325 87,7 %

eu-west-1c $0,0483 81,7 %

Sounds too good. What's the catch?

• Spot price and availability may vary .. really

Price peaks and it's effects

More price peak effects

Ok, anything else I need to know about Spot?

• no way to run static EC2 Spot instances with CloudFormation

• no (supported) way to use Spot capacity with Elastic Beanstalk

• best used as inexpensive extra muscle when doing EC2 auto scaling

• there are strategies to control the risk involved

Controlling Spot risk: initial step

• isolate workloads that suffer least if the spot risk hits them

• use for QA and test environments that don't require 100% availability

• use for background jobs, batch jobs, map-reduce stuff etc

• use for jobs that may be interrupted and later resumed

• (this mostly applies to all auto scaled work loads)

Controlling Spot risk: first iteration

• augment your OnDemand capacity with Spot capacity

• set up two Auto Scaling Groups behind a single load balancer

• one ASG is for OnDemand, other is for Spot capacity

• build scaling rules so that spot ASG scales up before OnDemand if capacity is available and scales down after OnDemand does

Controlling Spot risk: second iteration

• why stop there? to further control the Spot risk we can setup more than two ASGs behind the same load balancer and spread Spot ASGs over multiple instance types

• with equal scaling rules 1/N chance of scaling with OnDemands

• with properly planned scaling rules the probability of scaling with OnDemands may fall very low -> nearly always scale with Spot

Controlling Spot risk: third iteration

• why stop there? now that we got going let's see how deep this goes!

• if we seem to run fine with the multi ASG Spot setup – should we just get rid of the OnDemands altogether ..?

• take on some more risk in exchange for more savings

Should we use Spot capacity?

• will we get in real trouble if it goes down ..? does it cease working or just slow down ..? if the effects are acceptable then absolutely!

• if we get in trouble how soon can we recover? instance type switch takes minutes, starting up new capacity may take something like 5 to 15 minutes .. is this ok? if it is, then absolutely!

• using cloud capacity the right way requires special planning and construction – if you're doing everything in a smart way, you should be pretty much ready to take on some Spot risk

Takeaways in short

• if you are a long term AWS user and pay tens of thousands of dollars monthly for your OnDemand capacity it is really worth it to use reservations or spot

• plan carefully before you do any reservations

• use spot whenever it is suitable for your application, have recovery plans ready and tested

• optimize your costs, but don't overdo it as it soon leads to insanity

Thank you!

@AnttiSiiskonen

antti.siiskonen@almamedia.fi

https://www.linkedin.com/in/anttisiiskonen