Episode 25: Cost Optimization on AWS - Pricing Models, Budgets & Savings | SAA-C03

Hey everyone, Balu here. Welcome back to Tech Talk with Balu, your complete guide to Asing the AWS Solutions Architect Associate Exam. Today, we are tackling episode 25 and we are talking about cost optimization on AWS. Now, here's something you need to understand about the exam. Cost is not confined to one section. It runs through the entire exam. Over and over, you will see questions that describe a working architecture and then ask for the most cost effective way to achieve it. Two answers might both technically work, but only one is the cheapest and that's the one they want to know. So knowing how AWS pricing works and knowing the tools to manage and reduce costs, give you an edge on questions across every single domain. Here's how I want you to think about cost optimization. It has two halves. The first half is choosing the right pricing model for your compute because how you buy your easy to capacity has an enormous impact on your bill. The second half is using the cost management tools to see where your money is going. Forecast it, get alerted when something is wrong and get recommendations to trim waste. So today, we'll start with the easy to purchasing options, which is the heart of compute cost optimization and is heavily tested. That's on demand, reserved instances, saving plans, spot instances and a few specialized options. Then we'll move to cost management toolset, which includes cost explorer, AWS budgets, cost anomaly detection, cost allocation tags and trusted advisor. And we'll finish with some storage cost strategies tying back to our S3 episodes. We're keeping the same interactive format with pulse checks, trap spotlights and memory hooks and we're staying with the shorter puncher length. So let's get started. Let's begin with the easy to purchasing options because this is where the biggest cost decisions get made and it's one of the most tested topics in the whole area. To make these stick, I'm going to use a single running analogy throughout and it's a hotel resort. Imagine you need somewhere to stay. The different ways you can book a room map almost perfectly onto different ways you can buy easy to capacity. Keep that resort in mind as we go. Let's start with on demand instances. This is the default. You pay the full price by the second for exactly what you use with no commitment. In the resort analogy, on demand is showing up and staying whenever you like, paying the full nightly rate. It's the most flexible and the most expensive per hour. On demand is right for short term workloads, unpredictable usage or anything you're just experimenting with where you don't want to commit yet. Now, if you know you'll be running workloads for a long time, you can commit and save a lot. That brings us to reserved instances. With reserved instances, you commit to a one-year or three-year term and in exchange you get a huge discount compared to on demand up to around 72%. You reserve specific instance attributes, meaning the instance type, the region, the tenancy, the operating system, etc. The three-year term saves more than the one-year term and your payment option affects the discount too. You can pay nothing upfront for a smaller discount, partial upfront for more, or all upfront for the biggest discount. In the resort analogy, this is planning ahead and booking a long state to get a good rate. Reserved instances are recommended for steady state always on usage. The classic example is a database that runs 24/7. There's a variant now called the convertible reserved instances. These give us somewhat smaller discount but in exchange you gain flexibility to change the instance type, the instance family, the operating system, the scope and the tenancy during your term. So if you want the commitment savings but you're not certain your instance needs will stay fixed, convertible is the safer bet. Next up and often confused with reserved instances are saving plans. Savings plans also give you up to around 72% off the same ballpark as reserved instances and they also involve a one-year or three-year commitment. But here's a crucial difference. Instead of committing to a specific instance, you commit to a certain amount of usage measured in dollars per hour. For example, you commit to spending ten dollars an hour for one or three years. As long as your usage is at or below that commitment, you get the discounted rate. Any usage beyond your commitment is built at normal on demand prices. Savings plans are logged to a specific instance family and region but within that they're flexible across instance size, operating system and tenancy. In the resort analogy, a savings plan is committing to pay a certain amount per night for a period but you can stay in any room type, a king, a suite, a CV whatever as long as it's in the resort. So the mental model is this. Reserved instances lock you to specific instance attributes for the discount. Sparks plans on the other hand lock you to a dollar amount of usage and give you more flexibility in what you run. Now, for the cheapest option of all sport instances. Sport instances can save you up to 90% compared to on-demand, making them the single most cost effective option in all of AWS. But there's a catch and it's a big one. You can lose a sport instance at any time, so here's how it works. There's a fluctuating sport price based on supply and demand and you define a maximum price you're willing to pay. As long as the current sport price is below your max, you keep your instance. But the moment the sport price rises above your max price, AWS can reclaim your instance giving you just two minute grace period to wrap all of it up. In the resort analogy, sport is when the hotel lets people bid on empty rooms and the highest bidder gets them. But you can be kicked out at any time if someone outbits you. Because of that unpredictability, sport is perfect for workloads that are resilient to failure, things like batch jobs, data analysis, image processing and any distributed workload with flexible start and end times. And it's absolutely not suitable for critical jobs or databases because you can't have those disappearing on two minutes notice. There's a related concept called sport fleets, which is a set of sport instances optionally combined with on-demand instances that automatically works to meet a target capacity across multiple instance types and availability zones at the best price. You can set a location strategies and the recommended one for the most workload is price capacity optimized, which picks the pools with the most available capacity and then the lowest price balancing cost with the risk of interruption. Finally, a couple of specialized options to recognize. There is dedicated host that let you book on an entire physical server for yourself, which matters for certain licensing requirements or compliance. In the resort analogy, that's booking an entire building. Dedicated instances ensure no other customer shares your hardware, but without the full control of a dedicated host. And capacity reservations let you reserve capacity in a specific availability zone for any duration with no commitment and no discount. So your guarantee the capacity is there when you need it, but you pay on demand rates whether you use it or not. So let's do a pulse check here. Here's a scenario. A company runs a nightly batch job that processes large datasets. The job can be safely interrupted and restarted, it doesn't need to finish at any exact time and cost is the top priority here. Which easy to purchasing options should they use? Let's take a moment and think about it. The answer is of course, sport instances. The signals are that workload is interruptible and restartable. It has a flexible completion time and cost is the absolute top priority. Remember, sport gives you up to 90% savings and is designed exactly for a resilient flexible batch workload just like this. If the job had been a critical always on database, sport would completely be wrong and reserved instances or a savings plan would be the answer instant. So here's a trap to watch out for. The exam loves the reserved instances versus savings plan distinction. If a question emphasizes committing to specific instant types, especially for something steady like a database, then lean towards reserved instances. If it emphasizes flexibility across instant sizes and operating systems, while still committing for savings, then lean towards savings plans. And anytime you see a workload described as fault, tolerance, interruptible or batch, with cost as the priority, then that's definitely spot. Steady and always on with commitment is reserved or savings plans. On the other hand, short and unpredictable with no commitment is on demand. For your memory hook, hold on to that result. On demand is paying full price to come and go as you please. Reserved instances is booking a specific room for a long stay at a discount. savings plans is committing to a nightly spent but staying in any room type you like. And sport is bidding on empty rooms cheaply, knowing you could be kicked out at any moment. Now let's move to the tools that help you see, understand and control your spending. The first is AWS Cost Explorer. Cost Explorer lets you visualize, understand and manage your AWS costs and usage over time. It's your window into where the money is actually going. You can look at your data at a high level, seeing total costs and usage across all your accounts, or you can drill down to monthly hourly or even resource level granularity to find exactly what's driving a bill. Cost Explorer does a few specially useful things. It can help you choose an optimal savings plan by analyzing your past usage and Showing you what commitment would save you the most. And it can forecast your usage and spending up to 12 months into the future based on your historical patterns, which is invaluable for budgeting and planning. So when a question mentions visualizing costs over time, unlicing spending trends or forecasting future spend, cost explorer is always your answer. For your memory hook, think of cost explorer as the itemized bank statement and spending trends dashboard for your entire AWS account. It shows you where every dollar went and projects where future dollars will go. Seeing your costs is one thing, but you also want to be alerted before things get out of hand. And that's where AWS budgets come in. AWS budgets let you set custom budgets and receive alerts when your cost or usage exceed or are forecast to exceed the thresholds you define. So you might set a budget of $5,000 a month and configure an alert to notify you when you reach 80% of that. And again, when your forecast to blow past it, the alerts can go out by email or through SNS so you can wire them into notification systems. The key distinction to hold in your head is between cost explorer and budgets. Cost explorer is for analysis and visualization after the fact looking at what happened and forecasting trends. Budget is for proactive alerting, telling you the moment you cross line you care about. If a question is about being notified when spending exceeds a threshold, then that's budgets. For your memory hook, think of AWS budgets as the low balance alert on your bank account. You set the limit and it taps you on the shoulder the moment you're getting close so there are no nasty surprises later on. Now budgets rely on setting thresholds, but what about unexpected spending that you didn't anticipate at all? For that, AWS has cost anomaly detection. Cost anomaly detection continuously monitors your cost and usage using machine learning to detect unusual spending. The clever part is that you don't have to define any thresholds yourself. It learns your unique historical spending patterns and then it flags anomalies whether that's a sudden one time cost spike or a slower continuous cost increase that you might have never noticed. It can monitor by AWS service, by member account, by cost allocation tag or by cost category. When it finds something, it sends you a normally report with a root cost analysis and it can alert you individually or with daily or weekly summaries through SNS. So the distinction here is that budgets requires you to know and set a threshold while cost anomaly detection figures out what's normal for you and catches they unexpected without any threshold setting at all. If a question describes automatically detecting unusual spend with no predefined thresholds using machine learning, then that's definitely cost anomaly detection. For your memory hook, think of cost anomaly detection as your credit cards company's fraud detection. You never told it what a suspicious charge might look like, but it learns your normal habits and calls you the moment something looks off. Let's cover a foundational piece now that makes cost tracking possible in the first place which is called cost location tags. Cost allocation tags let you label your AWS resources with key value tags and then break down your costs by those tags. For example, you might tag every resource with a project name, a department or an environment like production or development. Then in your cost reports, you can see exactly how much marketing department I spend or how much the production environment costs versus the development environment. This is essential for charge backs where you attribute cloud costs back to the teams that incurred them and for simply understanding your spending in business terms rather than just by service. This is also the AWS cost and usage report which is the most comprehensive and granular set of costs and usage data available. It's the detailed raw data that you can load into analytical tools and it works hand-in-hand with cost allocation tags to give you deep breakdowns. This connects back to tag policies we discussed in the multi-account episode where you standardize tags across an organization. Consistent tagging is what makes cost allocation actually work at scale. For your memory hook, think of cost allocation tags as putting labeled expense codes on every purchase so that at the end of the month, you can sort your entire bill by department, project or environment. Finally in the tool section, let's talk about AWS trusted advisor which gives you recommendations across several areas including cost. Trusted advisor is like an automated consultant that inspects your AWS account and gives you recommendations across five categories. Those categories are cost optimization, performance, security, fault tolerance and service limits. On the cost site, trusted advisor will flag things like idle load balancers, underutilized easy-to-instances, unassociated, elastic IP addresses and reserved instance purchase opportunities. In other words, it hunts for waste and for savings you're leaving on the table. It's worth knowing that the full set of trusted advisor checks is available with business and enterprise support plans, while the basic plans get a limited subset. But conceptually, when a question asks about how to get automated recommendations to reduce cost or improve security across your account, trusted advisor is mostly the answer. For your memory hook, think of trusted advisor as a financial and safety advisor who does a full checkup on your account and hands you a list saying here's where you're wasting money. Here's a security gap or here's a resource that you have nearly maxed out. Let's close the content with storage cost strategies now which tie back again to our S3 episodes and it shows up in cost-focused questions all the time. The big one is S3 Intelligent Tearing. Remember that S3 has multiple storage classes at different price points, from standard for frequently access data down through glacier ties for cheap archival. The challenges that you don't always know your access patterns in advance and manually moving objects between classes is a hassle. S3 Intelligent Tearing solves all of this. For small monthly monitoring fee, it automatically moves your objects between access tiers based on how they're actually being used and more crucially there are no retrieval charges. Objects not access for 30 days moved to an infrequent access tier automatically and after 90 days to an archive instant access tier with optional deeper archive tiers you can configure. So when you have unknown or changing access patterns and you want cost optimization to happen automatically without any effort, intelligent Tearing is the answer. Known that, remember S3 lifecycle policies from our storage episodes which let you define explicit rules to transition objects to cheaper classes or expire them after a set time when you do not know your access patterns. Intelligent Tearing is the automatic hands of approach for unknown patterns while lifecycle policies are the manual rule based approach for known patterns. And more broadly, the whole idea of right sizing applies to storage and compute alike. Don't over provision, match your resources to the actual needs, use the cheapest option that meets your requirement and let automation handle the rest where you can. For your memory hook, think of S3 Intelligent Tearing as a self-organizing closet. It watches which clothes you actually wear, quietly moves the rarely worn items to the back and to the attic and brings anything back to the front the moment you reach for it, all without you lifting a finger. Now let's put everything together with exam traps. The first trap is on demand versus the committed options. On demand is for short term unpredictable workloads with no commitment. If a workload is steady and long running, you're leaving money on the table if you don't use reserved instances or savings plans. The second trap is reserved instances versus saving plans. Reserved instances lock you to a specific instance attributes ideal for steady things like databases. Saving plans on the other hand commit you to dollar per hour amount and gives flexibility across instance size, operating system and tenancy within a family and region. The third trap is spot instances. You get up to 90% off but it's intractable with a 2 minute warning. It's perfect for all tolerant batch jobs and data processing but never used that for critical workloads or databases. The fourth trap is cost explorer versus budgets. Cost explorer is for visualizing and forecasting costs after the fact. This is for proactive alerts when you cross a threshold. The fifth trap is cost anomaly detection. This uses machine learning to catch unusual spend with no thresholds required unlike budgets which you need to set a threshold. The sixth trap is cost allocation tax. These let you break down costs by project, department or environment and their foundation for chargebacks. The seventh trap is trusted advisor. Social advisor gives you automated recommendations across cost, performance, security, fault, tolerance and service limits. The full check version needs business or enterprise support. The eighth trap is S3 intelligent tiering versus lifecycle policies. Intelligent tiering is automatic for unknown or changing access patterns with no retrieval charges whereas lifecycle policies are manual rules for known patterns. The ninth trap is capacity reservations. Dedicated guarantee capacity in a specific availability zone but give no discount so you pay on demand rates whether you use them or not. Don't confuse guaranteed capacity with cost savings. And the tenth trap is dedicated hosts versus dedicated instances. Dedicated hosts give you a whole physical server with placement control often for licensing. Dedicated instances on the other hand just guarantee no shared hardware without full control. Alright, let's now do a rapid fire summary to lock everything in. The easy to purchasing options on demand for short and unpredictable with no commitment. Reserved instances for steady? long-running workloads log to specific attributes up to 72% off, saving plans for some savings with flexibility committing to a dollar amount per hour, and sport instances for up to 90% off on intreptable, fault-tolerant workloads never use them for critical jobs, plus dedicated hosts, dedicated instances and capacity reservations for specialized needs. We talked about cost management tools, cost explorer to visualize and focus, budgets to alert you when you cross a threshold, cost anomaly detection to catch unusual spend automatically with machine learning, cost allocation tax to break costs down the project or department, and then trusted advisors for automated recommendations across cost security and more. For storage, S3 intelligent tiering automatically moves objects to cheaper tiers based on usage with no retrieval charges. It's ideal for unknown access patterns while lifecycle policies, on the other hand, handle known patterns with explicit rules. So the decision framework I want you to remember is for steady workload, commit with reserved instances or savings plans. For intreptable batch, go for sport instance. To visualize and focus, to use cost explorer, you want to get alerted at a threshold, then use budgets, catch surprise spend, use cost anomaly detection, you want to break down by team, use cost allocation tags, if you want to get savings recommendations, then that's trusted advisor, and to understand unknown storage access patterns use intelligent tiering. Right, that's for episode 25 on cost optimization. We covered the easy to purchasing options in depth using our resort analogy from on demand through reserved instances, saving plans and sport plus the specialized options. We then covered the cost management toolset with cost explorer for visualization and forecasting and budgets for threshold alerts. We also covered cost anomaly detection, for machine learning surprise detection, cost allocation tags for breaking down spend and trusted advisor for recommendations. And we finally covered storage cost strategies with S3 intelligent tiering and lifecycle policies. So here's the big takeaway. Cost optimization is woven through the entire exam. When two architectures both work, the exam wants the cheaper one. So internalize the pricing models, especially the reserved versus savings plans versus sport decision and know which tool answers which cost question. Match the commitment to the workload, match the tool to the need and cost focus questions across every domain become very straightforward. We have now completed 25 main episodes and we are nearly at the finish line of the core SAAC 03 material. If this episode helped cost optimization click for you, please concert to leave a five star rating on my podcast and share it with anyone who's studying for the AWS exam. It generally helps the channel grow. So until next time keep building, keep optimizing and I will see you in the next episode. This is Balu signing off. Bye.