1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Getting Started with an Amazon Web Services Solution: Real World Practices

Cost Management

The course is part of these learning paths

Solutions Architect – Professional Certification Preparation for AWS
course-steps 48 certification 6 lab-steps 19 quiz-steps 4 description 2
Get Started Building Cloud Solutions
course-steps 14 certification 5 lab-steps 1

Contents

keyboard_tab
Course Introduction
1
Introduction
PREVIEW2m 57s
AWS Solutions
2
Pass, Hold, Adopt
PREVIEW12m 25s
3
Security
8m 32s
Course Conclusion
6
play-arrow
Start course
Overview
DifficultyBeginner
Duration38m
Students70
Ratings
4.8/5
star star star star star-half

Description

Getting Started with an Amazon Web Services Solution Real World Practices: In this course, we will untangle the AWS landscape and teach what you need to know to build applications on AWS. This includes understanding what AWS has to offer you if those prepackaged services make sense for your use case, and best practices around scaling, monitoring, security, and cost.

Transcript

Hello and welcome to the Getting Started with an AWS Solution: Real World Practices course from CloudAcademy. My name is Adam Hawkins and I'm your instructor for this lesson. This lesson covers tracking and lowering your AWS cost, specifically we're talking about cost allocation tags, budgeting, reserved capacity and spot instances. The objectives for this lesson are to learn to budget and track your costs and also to minimize your costs. T

his all starts with effectively tracking your various costs. The screenshot shows the AWS Cost Explorer. It allows you to look at various costs at the service level. For example, if you compare you're easy to cost, RDS, or even S3 service charges. However, that's not granular enough for most people, but you can instruct AWS how to divide costs based on your application using cost allocation tags. Cost allocation tags are the best way to understand your actual AWS bill. Cost allocation tags are preselected tags that AWS will track costs based on. This provides you historical data month-to-month, year-to-year, groupings and filterings and other powerful insight features to truly understand the different lines items in your AWS bill. There is one drawback though. You must preselect them. You only have data once they're activated, thus it's in your best interest to decide them up-front and start tagging everything in the beginning.

I recommend you use these tags at a minimum. You should use the environment, this is your production, staging, UAT or test, etc. Your application, such as backend, front end or data and probably your team and organization. This is especially relevant when you have multiple cooks in the kitchen, so to speak. This allows you to track who's actually using all the different ingredients. Adopting these three tags gives you a great start on tracking your costs. Need to breakdown your costs in a different way? Then add a new cost allocation tag. Be sure to apply these to everything, and not just easy to instances. You also need to tag your ELBs or EBS volumes etc. The ideal solution is that your cost allocation reports match your overall spend reports, meaning nothing is unaccounted for. Cost allocation tags tell you how much you're spending, but how do you know if you're meeting your targets? That's where the budget comes in.

AWS supports creating budgets and learning U under chosen conditions. The screenshot shows the UI for creating a budget. We won't get too far into creating a budget, jut know that you can create budgets for different areas with matching reports. Spending alerts are the most useful feature in my opinion. You can configure email alerts when your cost hit a certain value. This is a fantastic way to learn about unexpected costs. Combine that with cost allocation tags, you have a solar approach for investigating what's costing you money. Also remember to continually monitor your provision infrastructure against your current load or traffic. You must be proactive about down scaling or terminating over proficient infrastructure.

We've covered how to track costs, now let's discuss ways to lower them. Reserved capacity is the easiest way to reduce your costs. You pay AWS on-demand by default. This is the highest rate. Reserved capacity inverts the pricing model. You commit to a certain amount upfront and get a better price. The longer you commit, the more you save. Different AWS services have different commitment plans. Easy to offers plans for one year or three years with full or partial payment upfront. Savings range from roughly 20 to 40% over on-demand prices. Debian for example offers one or three year plans only with full upfront. Naturally your acutement depends on your time horizon and certainty around your compute requirements. If you're building something for a few years, then it's best to start with a small amount of reserved capacity and grow out from there. Don't worry about reserved capacity if your time horizon is less than a year.

Remember that it's better to start with something less and buy more as you grow, instead of overestimating in the beginning. Spot instances are another tool in your toolbox. AWS auctions off spot instances. You set your bid price and you'll get the instance if one's available at that price. These are usually significantly cheaper than on-demand prices. However, there are a few drawbacks. Well there's no assurance you'll actually win the bid, and spot instances automatically shut down if the market price exceeds your bid price. They're perfect for short live usage, say for less than an hour or so.

Spot instances are generally targeted at highly elastic workloads, so they may not make sense for your particular use case in the beginning, but be sure and keep them in your back pocket for when the time comes along. Let's conclude this lesson with recommendations to keep your AWS finances in check. First apply cost allocation tags from the start. Also set a budget and create spending alarms. Plan for reserved capacity and purchase it when the time is right. However, this is not mutually exclusive with spot instances. Combine these strategies for the most benefit. Also continually monitor your capacity and scale down where possible. Now we've reached the end of the topic specific lessons. In the next and final lesson, we'll conclude the course and give a grab bag of things that didn't fit into the previous lessons. See you in the next one. Cheers.

About the Author

Adam is backend/service engineer turned deployment and infrastructure engineer. His passion is building rock solid services and equally powerful deployment pipelines. He has been working with Docker for years and leads the SRE team at Saltside. Outside of work he's a traveller, beach bum, and trance addict.