The document discusses various strategies for optimizing costs and performance when using AWS, focusing on real-world examples from Adobe Systems. It emphasizes the importance of cloud-native architectures for reducing total cost of ownership (TCO) and improving disaster recovery, while offering practical tips for managing resources efficiently. Recommendations include leveraging AWS services, implementing automation, and optimizing application design to maximize performance and minimize costs.

2. Whether you're a startup getting to profitability or an enterprise optimizing spend, it pays to run cost-efficient architectures on AWS. Building on last year's popular foundation of how to reduce waste and fine-tune your AWS spending, this session reviews a wide range of cost planning, monitoring, and optimization strategies, featuring real-world experience from AWS customer Adobe Systems. With the massive growth of subscribers to Adobe's Creative Cloud, Adobe's footprint in AWS continues to expand. We will discuss the techniques used to optimize and manage costs, while maximizing performance and improving resiliency.
When traditional application and operating practices are used in cloud deployments, immediate benefits occur in speed of deployment, automation, and transparency of costs. The next step is a re-architecture of the application to be cloud-native, and significant operating cost reductions can help justify this development work. Cloud-native applications are dynamic and use ephemeral resources that customers are only charged for when the resources are in use.

3. With AWS, you can reduce capital costs, lower your overall bill, and match your expense to your usage. This session describes how to calculate the total cost of ownership (TCO) for deploying solutions on AWS vs. on-premises or at a colocation facility, as well as how to address common pitfalls in building a TCO analysis. The session presents and models customer examples.
This session is a deep dive into techniques used by successful customers who optimized their use of AWS. Learn tricks and hear tips you can implement right away to reduce waste, choose the most efficient instance, and fine-tune your spending; often with improved performance and a better end-customer experience. We showcase innovative approaches and demonstrate easily applicable methods to save you time and money with Amazon EC2, Amazon S3, and a host of other services.

4. In this session, you learn how you can leverage AWS services together with third-party storage appliances and gateways to automate your backup and recovery processes so that they are not only less complex and lightweight, but also easy to manage and maintain. We demonstrate how to manage data flow from on- premises systems to the cloud and how to leverage storage gateways. You also learn best practices for quick implementation, reducing TCO, and automating lifecycle management.
In the event of a disaster, you need to be able to recover lost data quickly to ensure business continuity. For critical applications, keeping your time to recover and data loss to a minimum as well as optimizing your overall capital expense can be challenging. This session presents AWS features and services along with Disaster Recovery architectures that you can leverage when building highly available and disaster resilient applications. We will provide recommendations on how to improve your Disaster Recovery plan and discuss example scenarios showing how to recover from a disaster.

6. •Pay as you go, no up-front investments
•Low ongoing cost
•Flexible capacity
•Speed, agility, and innovation
•Focus on your business
•Go global in minutes

8. Strategy 1: Do nothing

9. Ecosystem
Global Footprint
New Features
New Services
More AWS Usage
More Infrastructure
Lower Infrastructure Costs
Reduced Prices
More Customers
Infrastructure Innovation
45 price reductions since 2006
Economies
of Scale

10. Strategy 2: Do almost nothing

11. aws.amazon.com/premiumsupport/trustedadvisor/
Free with Business or Enterprise Support

12. Strategy 3: Optimize Architecture

14. Cloud-Ready
Cloud-Aware
Cloud-Native
•Run AWS like a virtual colocation (Fork-lift)
•Does not optimize for on-demand (overprovisioned)
•Minor modifications to improve cloud usage
•Automating servers can lower operational burden
•Redesign with AWS in mind
(high effort)
•Embrace scalable services (reduce admin)
•EC2, EBS
•HAProxy on EC2
•MySQL on EC2
•Cassandra, Hadoop on EC2
•ActiveMQ/Redis/KAFKA on EC2
•Chef on EC2
•EC2, EBS, S3, CloudFront
•ELB, Route53(round-robin)
•Multi-AZ RDS + read replica
•ElastiCache Redis
•OpsWorks
•Autoscaling, Self-healing
•Route53(LBR)
•RDS Aurora, RedShift
•DynamoDB, EMR
•SQS, SNS, Kinesis
•CloudFormation, Elastic Beanstalk
Development Cost
Scalability/Availability
Management Cost

16. •Developer, test, training instances
•Use simple instance start and stop
•Or tear down and build up all together
•Instances are disposable
•Automate, automate, automate:
–AWS CloudFormation
–Weekend/off-hours scripts
–Use tags

17. Monday
Friday
End of Vacation Season
35% saved

18. Automatic resizing of compute clusters
based on demand
Trigger autoscaling
policy
Feature Details
Control Define minimum and maximum instance pool
sizes and when scaling and cool down occurs.
Integrated to Amazon
CloudWatch
Use metrics gathered by CloudWatch to drive
scaling.
Instance types Run Auto Scaling for On-Demand and Spot
Instances. Compatible with VPC.
AWS autoscaling create-autoscaling-group
— Auto Scaling-group-name MyGroup
— Launch-configuration-name MyConfig
— Min size 4
— Max size 200
— Availability Zones us-west-2c
Amazon
CloudWatch

19. Cloud capacity
used is maybe
half average DC capacity

20. Mad scramble to add more DC capacity during launch phase outages

21. Capacity wasted
on failed launch
magnifies the
losses

22. Start
Choose an instance that best meets your basic requirements
Start with memory & then choose closest virtual cores
Look for peak IOPS storage requirements
Tune
Change instance size up or down based upon monitoring
Use CloudWatch & Trusted Advisor to assess
Roll-Out
Run multiple instances in multiple Availability Zones

23. 1, 1.7, $0.060 1, 3.75, $0.113 2, 3.75, $0.145 2, 7.5, $0.225 2, 17.1, $0.410 4, 7, $0.300 4, 15, $0.450 4, 34.2, $0.820 8, 15, $0.600 8, 30, $0.900 8, 68.4, $1.640 4, 30.5, $0.853 8, 61, 1.705 16, 30, $1.200 32, 60, $2.400 32, 244, $3.500 16, 122, $3.410 16, 117, $4.600 32, 244, $6.820 0 50 100 150 200 250 300 0 5 10 15 20 25 30 On Demand Prices shown (N.Virginia region), only latest generation instances (M3,C3) shown where applicable, GPU and Micro instances not shown above Memory-Optimized Instances Compute-Optimized Instances General Purpose Instances Storage-Optimized Instances vCPU RAM

24. More small instances vs. Less large instances
29 m3.xlarge
= 29 x $0.280/hour
= $8.12/hour
69 m3.medium
= 69 x $0.070/hour
= $4.83/hour
40% Savings

25. 1
5
9
13
17
21
25
29
33
37
41
45
49
Web Servers
Week
50% Savings
Weekly CPU Load

26. Scale up/down by 70%+
Move to Load-Based Scaling
50% Savings

27. Auto Scaling in the Amazon Cloud
http://techblog.netflix.com/2012/01/auto-scaling-in-amazon-cloud.html
Reactive Auto Scaling saves around 50%
Requests
Servers
50% Savings

28. Predictive Auto Scaling saves around 70%
Load prediction
Autoscaling Plan
Scryer: Netflix’s Predictive Auto Scaling Engine
http://goo.gl/iFefxJ
70% Savings

29. 1y RI
Break even
3y RI
Break even

30. •No Upfront
You pay nothing upfront but commit to pay for the Reserved Instance over the course of the Reserved Instance term, with discounts (typically about 30%) when compared to On-Demand. This option is offered with a one year term
•Partial Upfront
You pay for a portion of the Reserved Instance upfront, and then pay for the remainder over the course of the one or three year term. This option balances the RI payments between upfront and hourly.
•All Upfront
You pay for the entire Reserved Instance term (one or three years) with one upfront payment and get the best effective hourly price when compared to On-Demand.

31. 62% Savings
77% Savings

32. 47% Savings
65% Savings

33. 39% Savings
63% Savings

34. •Can be moved between AZs
•Can be moved between
EC2-Classic and EC2-VPC platforms
•Size can be modified within the
same instance family

35. •Price based on supply/demand
•You choose your maximum price/hour
•Your instance is started if the Spot price is lower
•Your instance is terminated if the Spot price is higher
•But: You did plan for fault tolerance, didn’t you?

36. On-Demand:
$0.24
$0.028 (11.7%)
$0.026 (10.8%)
90% Savings

37. •Very dynamic pricing
•Opportunity to save 80-90% cost
–But there are risks
•Different prices per AZ
•Leverage Auto Scaling!
–One group with Spot Instances
–One group with On-Demand
–Get the best of both worlds
•Coming soon: 2-minute Spot interruption warnings

38. •Reduced redundancy storage class
–99.99% durability vs. 99.999999999%
–Up to 20% savings
–Everything that is easy to reproduce
–Use Amazon SNS lost object notifications
•Amazon Glacier storage class
–Same 99.999999999% durability
–3 to 5 hours restore time
–Up to 64% savings
–Archiving, long-term backups, and old data
•Use life-cycle rules
64% Savings
20% Savings

39. •Read/write capacity units (CUs) determine most of DynamoDB cost
•By optimizing CUs, you can save a lot of money
•But:
–Need to provision enough capacity to not run into capacity errors
–Need to prepare for peaks
–Need to constantly monitor/adjust

40. •Use caching to save read capacity units
–Local RAM caches at app server instances
–Check out Amazon ElastiCache
•Think of strategies for optimizing CU use
–Use multiple tables to support varied access patterns
–Understand access patterns for time series data
–Compress large attribute values
•Use Amazon SQS to buffer over-capacity writes

41. EC2
1.
2.
3.
4.

43. Caching/Optimization: 80% saved
Cache flush
Dynamic DynamoDB:
20% saved
Growth + new features
80% Savings
20% Savings

44. •The more you can offload, the less infrastructure you need to maintain, scale, and pay for
•Three easy ways to offload:
–Use Amazon CloudFront
–Introduce caching
–Leverage existing Amazon web services

46. •Amazon RDS, Amazon DynamoDB or Amazon ElastiCache for Redis, Amazon Redshift
–Instead of running your own database
•Amazon CloudSearch
–Instead of running your own search engine
•Amazon Elastic Transcoder
•Amazon Elastic MapReduce
•Amazon Cognito, Amazon SQS, Amazon SNS, Amazon Simple Workflow Service, Amazon SES, Amazon Kinesis, and more …

47. November 14, 2014 | Las Vegas
Adrian Cockcroft @adrianco, Battery Ventures

48. @adrianco
Bill
Now
Next Month
Ages
Ago
Lease
Building
Install
AC etc.
Rack and
Stack
Private Cloud SW
Run
My Stuff
Data Center Up-Front Costs

49. 0
25
50
75
100
125
1
2
3
4
5
6
7
8
9
10
11
12
1
2
3
4
5
6
7
8
9
10
11
12
1
2
3
4
5
6
7
8
9
10
11
12
Three Years Halving Every 18mo = maybe 40% overall savings
Data shown is purely illustrative

50. Older m1/m2 families
•Slower CPUs
•Higher response times
•Smaller caches (6MB)
•Oldest m1.xlarge
–15G/8.5ECU/35c 23ECU/$
•Old m2.xlarge
– 17G/6.5ECU/25c 26ECU/$
New m3 family
•Faster CPUs
•Lower response times
•Larger caches (20MB)
•Java perf ratio > ECU
•New m3.xlarge
–15G/13ECU/28c 46ECU/$
•77% better ECU/$
•Deploy fewer instances

53. Combinations

54. 100
70
70
70
30
30
25
0
25
50
75
100
125
Base Price
Rightsized
Seasonal
Daily Scaling
Reserved
Tech Refresh
Price Cuts
Traditional
application
using AWS
heavy-use
reservations
Base price is for capacity bought up-front

55. 100
70
50
35
25
20
15
0
25
50
75
100
125
Base Price
Rightsized
Seasonal
Daily Scaling
Reserved
Tech Refresh
Price Cuts
Cloud-native
application
partially optimized
light use reservations

56. 100
50
25
12
8
6
4
0
25
50
75
100
125
Base Price
Rightsized
Seasonal
Daily Scaling
Reserved
Tech Refresh
Price Cuts
Cloud-native application
fully optimized autoscaling
mixed reservation use
costs 4% of base price
over three years!

57. •Business logic isolation in stateless micro-services
•Immutable code with instant rollback
•Autoscaled capacity and deployment updates
•Distributed across availability zones and regions
•De-normalized single function NoSQL data stores
•See over 40 NetflixOSS projects at netflix.github.com
•Get “technical indigestion” trying to keep up with techblog.netflix.com

60. AdRoll, an online advertising platform, serves 50 billion impressions a day worldwide with its global retargeting platforms.
We spend more on snacks than we do on Amazon DynamoDB.
•Needed high-performance, flexible platform to swiftly sync data for worldwide audience
•Processes 50 TB of data a day
•Serves 50 billion impressions a day
•Stores 1.5 PB of data
•Worldwide deployment minimizes latency
Valentino Volonghi
CTO, Adroll
”
“
Adroll Uses AWS to Grow by More Than 15,000% in a Year

61. •Handle 150TB/day
•Low <5ms response time
•1,000,000+ global requests/second
•100B items

62. •Memcache
aOpen source
aMature
aBlazingly fast
rNo strong guarantees
•Redis
aOpen source
rStorage scale
rNot really distributed
rOperationally intense.
•Hbase (we still use this)
aOpen source
aMaturing quickly
aGreat scale
rReally hard to operate
a
a
a
r

63. •Revisiting 1 million writes per second (Netflix) http://techblog.netflix.com/2014/07/revisiting-1-million-writes-per-second.html
•Mix is 10% writes/90% reads, 1M ops/sec is total capacity.
Cassandra
DynamoDB
Delta
10/90 mix, $/month
$287,064
$131,040
219%
50/50 mix, $/month
$287,064
$280,800
~0%
10/90, 3-yr reserved
$27,075.6
($904k upfront)
$15,736
($504k upfront)
180%
•10 people Cassandra ops team: $150k/month (fully loaded)
•0 DynamoDB ops team: $0

64. Data Collection = Batch Layer
Bidding = Speed Layer
Data Collection
Data Storage
Global
Distribution
Bid Storage
Bidding

65. US East region
Availability Zone
Availability Zone
Elastic Load Balancing
instances
instances
Auto Scaling group
Amazon S3
Amazon Kinesis

66. US East region
Availability Zone Availability Zone
Elastic Load
Balancing
instances instances
Auto Scaling group
Amazon S3
Amazon
Kinesis
Apache
Storm DynamoDB
US West region
EU West region
DynamoDB
DynamoDB

67. Data Collection Bidding
US East region
Availability Zone Availability Zone
Elastic Load Balancing
instance
s
instance
s
Auto Scaling group
Amazon
S3
Amazon
Kinesis
Apache
Storm
DynamoD
B
Availability Zone Availability Zone
Auto Scaling group
Elastic Load Balancing

68. Data Collection
Bidding
Ad Network 1 Ad Network 2
Auto Scaling Group Auto Scaling Group Auto Scaling Group Auto Scaling Group Auto Scaling Group Auto Scaling Group
Auto Scaling Group Auto Scaling Group Auto Scaling Group
Apache Storm
v1 v2 V3 V3 v1 v2 V3 V3
V1 V2 V3 V3
Auto Scaling Group
V3 V4
Elastic Load Balancing Elastic Load Balancing Elastic Load Balancing Elastic Load Balancing
DynamoDB
Write
Read Read Read Read
Read Read
Write
Writes
Write
Write
Read
V3
`
DynamoDB
Data Collection
Bidding
DynamoDB
Write
Read
Read
Write
Write
Write
Amazon S3
Amazon
Kinesis
Data
Collection
• Amazon EC2, Elastic Load
Balancing, Auto Scaling
Store
• Amazon S3 + Amazon
Kinesis
Global
Distribution
• Apache Storm on Amazon
EC2
Bid Store
• DynamoDB
Bidding
• Amazon EC2, Elastic Load
Balancing, Auto Scaling

70. Cloud-Ready
Cloud-Aware
Cloud-Native
•Run AWS like a virtual colocation (Fork-lift)
•Does not optimize for on-demand (overprovisioned)
•Minor modifications to improve cloud usage
•Automating servers can lower operational burden
•Redesign with AWS in mind
(high effort)
•Embrace scalable services (reduce admin)
•EC2, EBS
•HAProxy on EC2
•MySQL on EC2
•Cassandra, Hadoop on EC2
•ActiveMQ/Redis/KAFKA on EC2
•Chef on EC2
•EC2, EBS, S3, CloudFront
•ELB, Route53(round-robin)
•Multi-AZ RDS + read replica
•ElastiCache Redis
•OpsWorks
•Autoscaling, Self-healing
•Route53(LBR)
•RDS Aurora, RedShift
•DynamoDB, EMR
•SQS, SNS, Kinesis
•CloudFormation, Elastic Beanstalk
Development Cost
Scalability/Availability
Management Cost