Are you running many EC2 instances on with OnDemand prices? Here are some tips on how to save money and get your running hours cheaper. Please share or tweet if this is of any value to you!

1. Exploring ways to buy EC2
capacity
Antti Siiskonen
CTO, Alma Mediapartners Oy

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. How much can we save with std reservations?

11. 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!)

12. 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

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

14. How much can we save with convertible
reservations?
• for three year reservations
• no upfront 32%
• partial upfront 42%
• all upfront 43%

15. 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

16. 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

17. 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

18. 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

19. 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

20. Pricing history is visible on AWS EC2 console

21. 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 %

22. Sounds too good. What's the catch?
• Spot price and availability may vary .. really

23. Price peaks and it's effects

24. More price peak effects

25. 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

26. 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)

27. 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

28. 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

29. 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

30. 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

31. 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

32. Thank you!
@AnttiSiiskonen
antti.siiskonen@almamedia.fi
https://www.linkedin.com/in/anttisiiskonen