Slides for lightning talks presented by AWS on Right Sizing Best Practices by Frank Fan, Tagging Best Practices by Craig Gunson, and RI Best Practices by Peter Shi
Group URL: https://www.meetup.com/AWS-Cost-Optimisation-Interest-Group/
2. Agenda
• 4:00pm - Setup
• 4:05pm - Kick off: welcome and intro
• 4:15pm - Talk 1 – Katerina Martianova from Realestate.com.au
• 4:45pm - Q&A and/or Break (15 mins)
• 5:00pm - Talk 2 – Right Sizing Best Practices by Frank Fan, TAM from AWS
• 5:10pm - Talk 3 – Tagging Best Practices by Craig Gunson, TAM from AWS
• 5:20pm - Talk 4 – RI Best Practices by Peter Shi, from AWS
• 5:30pm - Q&A and/or Break (15 mins)
• 5:45pm to 7:00pm – Open Discussion Networking
3. TAM (& adopted TAM) Speakers
Reserved
Instances
Right Sizing Tagging
10. Instance Selection Decision Tree
D2 I3
EBS
>20,000 IOPS>500 MB/s
N
P2
F1
G3
Generic Graphic
FPGA
M4
R4
X1
<=4G/vCPU
4G-8G/vCPU
4T/Instance
C4
T2Regular
More
RAM ?
N
N
Y
Requirements
Y
N
Y
14. AWS Right sizing tools
Cost Optimization:
EC2 Right Sizing
https://aws.amazon.com/answers/account-
management/cost-optimization-ec2-right-sizing/
AWS trusted advisor
Comes with Business and Enterprise
support, for identifying idle resources
19. Types of Tags
AWS-Generated
User-Defined
Linked accounts can take up to seven days to appear in the Billing and Cost Management
console. To speed the process up, you can trigger a manual refresh to make them appear
within 24 hours.
key = aws:createdBy
value = account-type:account-ID or access-key:user-name or role session name
Root:1234567890
Root:1234567890:exampleUser
IAMUser:EXAMPLEACCESSKEY:exampleUser
AssumedRole:EXAMPLEACCESSKEY:exampleRole
FederatedUser:1234567890:exampleUser
27. What are Reserved Instances (RIs)?
RIs are like discount coupon booklets
• Each RI gives one coupon per hour per instance being reserved over
the term of the RI (e.g. a 1 year RI provides 24*365 coupons)
• The coupon provides a discount in exchange for commitment
• Each individual coupon expires at the end of each hour
• RIs are a financial construct/layer on top of your AWS infrastructure
RI coupon
28. RIs are best used for Always-On instances
(can still be used to save for non-always on)
Commitment level
1 year (approx. payback 7-9 months)
3 year (approx. payback 10-18 months)
AWS services offering RIs
Amazon EC2 & EC2 Hosts
Amazon RDS
Amazon Redshift
Amazon ElastiCache
Amazon DynamoDB*
Amazon CloudFront*
*Discount for commitment, but not a RI
29. EC2 RI matching properties
• Instance type: m4.xlarge
• Operating System: Linux/UNIX, Windows, Windows with
SQL Server Standard, etc.
• Region: ap-southeast-2 (Sydney)
o or AZ: ap-southeast-2a
• Tenancy: Shared, dedicated
Non-EC2 RIs have similar (but not exactly the same) matching criteria.
30. Understanding the different EC2 RI types
1 year 3 years
Standard Regional
(with Linux/Unix Size Flex)
Regional
AZ-Specific
(with capacity reservation)
AZ-Specific
Convertible Regional (new!) Regional
AZ-Specific (new!) AZ-Specific
Note: can easily switch between Regional and AZ-Specific at no cost
Shaded items affect pricing
31. Understanding Convertible Reserved Instances
With a Convertible Reserved Instance, you can modify
your existing reservation across:
Instance families
Instance sizes
Operating Systems
Tenancy
32. Understanding Convertible Reserved Instances
You are committing to:
3 years (not refreshed on conversion)
Region
EC2 on AWS
Spend (convert to equal or greater $)
33. Examples of conversion
m4.xlarge
$20 upfront
remaining
m4.large
$10 upfront
m4.large
$10 upfront
No Sure-up
required
m4.xlarge
$20 upfront
remaining
m4.2xlarge
$40 upfront
Sure-up $20
Sizing to smaller instance (same family and OS)
Sizing to larger instance (same family and OS)
34. Examples of conversion
m4.xlarge
$20 upfront
remaining
r4.xlarge
$25 upfront
Sure-up $5
Sizing to more expensive instance type
r4.xlarge
$25 upfront
remaining
m4.xlarge
$20 upfront
Sure-up $15
Sizing to cheaper instance type
m4.xlarge
$20 upfront
35. Understanding Instance Size Flexibility
• Effective March 1, your existing Regional RIs are even
more flexible!
• All Regional Linux/UNIX RIs with shared tenancy now
apply to all sizes of instances within an instance family
and AWS region.
• E.g. 1 m4.xlarge RI can apply to:
2 m4.large instances or
½ a m4.2xlarge instance
36. RIs have priority to apply to instances in the
same account as the RI
http://docs.aws.amazon.com/awsaccountbilling/latest/
aboutv2/consolidated-billing.html
RI can live here and this
account will get priority
to use it first
RIs can also live here and this account
will get priority to use the RI.
Be sure to have RI console access to
modify RIs if needed & billing console
access to check RI utilisation
37. Use Cost Explorer to track your RI utilization
(higher utilisation = greater savings realization)
Open discussion will include Networking < use this session to poll the audience for future topics to plan next meet up. Also interest in an open source resource hub.
Open discussion will include Networking < use this session to poll the audience for future topics to plan next meet up. Also interest in an open source resource hub.
SLIDE 1 – Title
Add customer name, customer’s logo, and change the month and year to the reporting period.
Compared with traditional world, right sizing process in Cloud is a lot simpler and agile.
Think out of box, what architecture decision principle should I consider ?
Where should I start to choose a instance in build phase ?
What should I monitor ?
Before you can determine the right instance type/size for your application, it’s best for you to make sure that you are taking advantage of the low-cost, highly available and durable storage, S3 for your assets like audio, video, and images. By offloading your static assets from your web server to S3, you can achieve higher scalability with lower cost. You can then further improve user experience by using Cloudfront, CDN, for edge caching.
Three easy ways to offload:• Use CDN - Amazon CloudFront• Introduce Caching – Amazon ElastiCache
Leverage existing Amazon Web Services
Because with smaller instances, you also have more granular controls when it comes to things like scaling.
Most people guess as to what their needs are. And when you do that you usually end up over provisioning or under provisioning. And thi means you’re spending money on hardware that’s just sitting idle, or you’re giving a bad experience to your end users. One of the most powerful things I think that I think AWS gives you, is the ability to quickly change from one instance size or family to another. And because you pay by the hour, it’s really cheap to actually do the testing to make sure you’re hiring the right server.
What this means for your application is that you can decide how you’re able to chunk up the work in order to best utilize your resources. So like a web server where smaller instances can just as effectively handle a request as the larger ones, more of a smaller instance size may be a better choice. Because with smaller instances, you’re not only able to spread your footprint over more availability zones to get higher availability, but you also have more granular controls when it comes to things like scaling. If you’re adding an 8xlarge instance when your load coming in only request a 1xlarge, then you’ve got a lot of extra compute sitting around idle that you shouldn’t be paying for. So the goal is to find the right instance size for the unit of work you’re trying to match it up to.
So before we start diving into the instances, I wanted to quickly go over how we name them so that we’re all speaking the same language. What you see here, is the c4 large instance. And the first letter you see is the instance family, this usually stands for what it’s best suited for or what sort of resources it has “c for compute” “r for ram”, “I for iops”, etc. The next number you see is the generation. And you can kinda think of this like a version number. So a c4 is a newer instance generation than the c3 instance. And lastly you have the different sizes of the instance. I heard them called T-Shirt sizes, so you have small, medium, large, and extra large and that’s actually a good way to think about them.
because newer systems often require less power and less cooling, which means they’re less expensive for us to operate which means we can pass those saving back to you.
Background - 3 tier web app
E/Measure/Understand/Simulate/Benchmark - CPU/RAM/Network
Monitor
Review/Work on - Change instance type
Once you’ve done a little bit of testing you generally know what you’re going to be constrained by, and from there it’s pretty easy to start picking the right instance family. If you know you’ll need a lot of memory, you should probably start with an R4 instance, if you need raw CPU performance you should go with the C4. If your application is actually well rounded, start with the general purpose m4 & t2 instances. By approaching EC2 in this way, you can quickly narrow down to the right instance family, and from there just do a little bit of testing to find the right size within that family.
when choosing an instance] there is no substitute for measuring the performance of your full application.”
So instead of installing a synthetic benchmark tool to count the number of flops you can get, I tell people to just install their application and start sending some realistic load to it. If it’s a mobile app, simulate a real user navigating it, if it’s an HPC application, run some of your common models, if it’s a data warehouse, run your typicall BI queries. You can even do things like the spot market so that you can run your tests on larger and realistically sized instances and the testing will only cost you pennies an hour.
Understand your unit of work
Web request
Database / Table
Batch Process
What is that unit’s requirements?
CPU threads
Memory Constraints
Disk & Network
What are it’s availability requirements?
*unless you have specific storage requirements, upgrade from M3 to m4 – not only will you benefit from enhanced networking, m4 would have a better price point than m3.large (and higher). Thus giving you already at least $10 per month savings.
Lowest cost EC2 instance at $0.0065 per hour
Burstable performance
Fixed allocation enforced with CPU credits
Change instance size up or down based upon monitoring
Run multiple instances in multiple Availability Zones
How efficiently are resources being used
Low utilization can indicate over-provisioning
Tools
Use CloudWatch standard and custom metrics
Right Sizing tool
EC2 usage and utilization
Trusted Advisor