WEBVTT 00:00:00.000 --> 00:00:02.779 Welcome back to the deep dive. Our mission, as 00:00:02.779 --> 00:00:05.200 always, is pretty simple. We take a whole stack 00:00:05.200 --> 00:00:08.099 of complex sources, pull out the really critical 00:00:08.099 --> 00:00:10.320 stuff, and basically give you the shortcut to 00:00:10.320 --> 00:00:13.060 understanding it all. Today, we're diving into 00:00:13.060 --> 00:00:14.640 something that trips up a lot of people, even 00:00:14.640 --> 00:00:17.859 tech pros. It's cloud economics. Specifically, 00:00:18.280 --> 00:00:20.679 AWS economics and billing. I mean, you can be 00:00:20.679 --> 00:00:23.620 a wizard with APIs, right? Build amazing architecture. 00:00:24.160 --> 00:00:26.699 But if you don't get the dollars and cents, Well, 00:00:26.920 --> 00:00:29.500 your whole cloud strategy could fall apart. OK, 00:00:29.500 --> 00:00:31.239 let's really unpack this. This isn't just about 00:00:31.239 --> 00:00:33.539 passing an exam. It's about true financial literacy 00:00:33.539 --> 00:00:36.399 for the cloud age. That's the bedrock for actually 00:00:36.399 --> 00:00:38.399 driving business value. That's absolutely right. 00:00:38.420 --> 00:00:41.000 And it's crucial because AWS gives you this incredibly 00:00:41.000 --> 00:00:44.299 flexible consumption -based model. I think utility 00:00:44.299 --> 00:00:46.600 is amazing for scaling up or down. But like you 00:00:46.600 --> 00:00:48.219 said, that flexibility, it's a bit of a double 00:00:48.219 --> 00:00:50.579 -edged sword. If you don't really grasp how the 00:00:50.579 --> 00:00:53.140 billing works, what actually drives the costs 00:00:53.140 --> 00:00:55.820 and what levers you have to pull those costs. 00:00:55.719 --> 00:00:58.640 can just spiral completely, and suddenly all 00:00:58.640 --> 00:01:01.159 the reasons you moved off -prem are gone. So 00:01:01.159 --> 00:01:03.479 yeah, our focus today is really on mastering 00:01:03.479 --> 00:01:06.319 the strategies to, well, harness those costs 00:01:06.319 --> 00:01:08.819 effectively. Okay, so let's start right at the 00:01:08.819 --> 00:01:12.680 top. Cloud economics. It sounds a bit academic, 00:01:12.739 --> 00:01:15.359 maybe, but it's really the heart of making good 00:01:15.359 --> 00:01:17.459 decisions, isn't it? It really is. You can think 00:01:17.459 --> 00:01:21.019 of it as the study of financial impact. How does 00:01:21.019 --> 00:01:23.060 using cloud services actually affect your bottom 00:01:23.060 --> 00:01:25.500 line? It's the analysis you use to compare, say, 00:01:25.819 --> 00:01:28.019 running workloads in AWS versus your own data 00:01:28.019 --> 00:01:30.079 center. That's the whole total cost of ownership 00:01:30.079 --> 00:01:32.920 piece we'll get into. Right. TCO. Exactly. But 00:01:32.920 --> 00:01:36.700 it's also about... forecasting what you're likely 00:01:36.700 --> 00:01:39.340 to spend next month, next quarter, and then constantly 00:01:39.340 --> 00:01:41.980 looking for ways to optimize that spending. You 00:01:41.980 --> 00:01:44.480 want every dollar you spend on IT to really align 00:01:44.480 --> 00:01:46.180 with what the organization is trying to achieve. 00:01:46.620 --> 00:01:48.540 And the core idea, as you mentioned, is modeled 00:01:48.540 --> 00:01:51.519 after utilities. That pays you go thinking. You 00:01:51.519 --> 00:01:53.780 only pay for what you actually use, right? Unless 00:01:53.780 --> 00:01:56.799 you specifically choose to commit upfront for 00:01:56.799 --> 00:01:59.709 a discount. Precisely. Pay only for what you 00:01:59.709 --> 00:02:02.569 consume second by second, or hour by hour, or 00:02:02.569 --> 00:02:04.549 gigabyte by gigabyte. So if we boil it all down, 00:02:04.810 --> 00:02:07.129 what are the absolute main things, like three 00:02:07.129 --> 00:02:09.490 big variables that you, the listener, really 00:02:09.490 --> 00:02:11.770 need to track? Okay, the three fundamental cost 00:02:11.770 --> 00:02:14.889 drivers are compute, storage, and data transfer. 00:02:15.490 --> 00:02:17.729 Compute is pretty straightforward. You're paying 00:02:17.729 --> 00:02:19.770 per hour, or sometimes per second, depending 00:02:19.770 --> 00:02:22.009 on the specific virtual machine, the instance 00:02:22.009 --> 00:02:24.849 type. Okay. Storage is typically charged per 00:02:24.849 --> 00:02:27.639 gigabyte per month. How much data are you storing, 00:02:27.979 --> 00:02:31.060 and for how long? And data transfer. This one 00:02:31.060 --> 00:02:33.000 seems to catch people out sometimes. It can, 00:02:33.060 --> 00:02:35.960 yeah. The key distinction is direction. Data 00:02:35.960 --> 00:02:39.340 going out of AWS, like to the internet, or back 00:02:39.340 --> 00:02:41.919 to your own data center, that's generally charged 00:02:41.919 --> 00:02:46.500 per gigabyte. But data coming in to AWS, often 00:02:46.500 --> 00:02:49.280 free. And data moving between services within 00:02:49.280 --> 00:02:52.710 the same AWS region. also often free, understanding 00:02:52.710 --> 00:02:55.250 that in versus outflow is really critical for 00:02:55.250 --> 00:02:57.050 accurate budgeting. You don't want surprises 00:02:57.050 --> 00:02:59.770 there. No kidding. OK, so if those are the drivers, 00:03:00.169 --> 00:03:03.849 how do you actually pay? Because obviously, companies 00:03:03.849 --> 00:03:05.849 have all sorts of different needs, right? Predictable 00:03:05.849 --> 00:03:07.830 stuff, totally unpredictable stuff. Exactly. 00:03:08.090 --> 00:03:10.750 And that's why AWS doesn't just have one price. 00:03:10.849 --> 00:03:13.789 They offer four main pricing models. Think of 00:03:13.789 --> 00:03:16.509 them as different strategies or financial levers 00:03:16.509 --> 00:03:18.449 you can pull depending on the workload. All right, 00:03:18.449 --> 00:03:20.180 let's start with the default, the baseline. On 00:03:20.180 --> 00:03:22.500 -demand. On -demand is exactly what it sounds 00:03:22.500 --> 00:03:24.659 like. No commitment needed. You just pay the 00:03:24.659 --> 00:03:27.219 standard rate by the second or hour for whatever 00:03:27.219 --> 00:03:31.360 you use. It's perfect for spiky, unpredictable 00:03:31.360 --> 00:03:33.219 workloads. Maybe you're testing a brand new app. 00:03:33.400 --> 00:03:35.740 Or like a short marketing campaign website. Perfect 00:03:35.740 --> 00:03:38.479 example. Or some quick data analysis. It offers 00:03:38.479 --> 00:03:40.719 the most flexibility, zero strings attached. 00:03:41.099 --> 00:03:43.139 But it also comes at the highest price point 00:03:43.139 --> 00:03:45.759 per unit. OK, so maximum flexibility, maximum 00:03:45.759 --> 00:03:49.229 price. But what happens when that test app becomes 00:03:49.229 --> 00:03:52.889 the main company website? Running that on demand 00:03:52.889 --> 00:03:55.930 forever would get expensive fast. Right. And 00:03:55.930 --> 00:03:57.909 that's where the strategy comes in. Once you 00:03:57.909 --> 00:04:01.050 have a workload that's stable, predictable, something 00:04:01.050 --> 00:04:03.729 you know you'll be running constantly, that's 00:04:03.729 --> 00:04:06.550 when you look at reserved instances, or RIs. 00:04:06.849 --> 00:04:09.689 RIs. The commitment model. Exactly. You're telling 00:04:09.689 --> 00:04:12.590 AWS, hey, I'm going to run this specific type 00:04:12.590 --> 00:04:15.990 of instance in this region. for one year, or 00:04:15.990 --> 00:04:18.089 maybe even three years, and because you're giving 00:04:18.089 --> 00:04:20.050 them that predictable revenue, they give you 00:04:20.050 --> 00:04:22.269 a really significant discount. How significant 00:04:22.269 --> 00:04:25.089 are we talking? It can be huge. Up to 72 % off 00:04:25.089 --> 00:04:27.410 the on -demand price. Think about that for your 00:04:27.410 --> 00:04:29.470 main web servers, your core databases, the things 00:04:29.470 --> 00:04:32.470 that are always on. That's serious savings. 72%, 00:04:32.470 --> 00:04:35.050 wow. OK, and I remember there are different ways 00:04:35.050 --> 00:04:36.910 to pay for that commitment too. Yeah. Right, 00:04:36.990 --> 00:04:38.889 it's not just one option. Correct. You've got 00:04:38.889 --> 00:04:41.310 flexibility even within the commitment. There 00:04:41.310 --> 00:04:44.470 are three payment options. You can pay all upfront, 00:04:44.810 --> 00:04:46.810 basically pay for the whole year or three years 00:04:46.810 --> 00:04:49.129 at the start. That gets you the absolute biggest 00:04:49.129 --> 00:04:52.810 discount. OK. Or you can do partial upfront. 00:04:53.290 --> 00:04:56.230 Pay some now and the rest monthly. Gets you a 00:04:56.230 --> 00:04:58.389 good discount, maybe not quite as deep as all 00:04:58.389 --> 00:05:00.550 upfront. Right, balances cash flow a bit. Mm 00:05:00.550 --> 00:05:03.420 -hmm. And then there's no upfront. You still 00:05:03.420 --> 00:05:05.199 make the one or three -year commitment, but you 00:05:05.199 --> 00:05:07.779 pay for it purely on a monthly basis. The discount 00:05:07.779 --> 00:05:09.579 is smaller than the other two, but you don't 00:05:09.579 --> 00:05:11.939 have that initial cash outlay. It really depends 00:05:11.939 --> 00:05:13.839 on your organization's financial preferences. 00:05:14.420 --> 00:05:17.560 That makes sense. So, orias were king for a long 00:05:17.560 --> 00:05:20.290 time for predictable workloads. But things have 00:05:20.290 --> 00:05:21.910 evolved, haven't they? There's something newer, 00:05:21.910 --> 00:05:24.910 more flexible. Yes, absolutely. And this is where 00:05:24.910 --> 00:05:27.569 savings plans, or SPs, come in. They're kind 00:05:27.569 --> 00:05:30.069 of the modern, more flexible evolution of RISE 00:05:30.069 --> 00:05:32.050 in many ways. How so? What's the core difference? 00:05:32.310 --> 00:05:36.069 Instead of committing to, say, running a specific 00:05:36.069 --> 00:05:38.910 instance type, like an M5 .large in the US East 00:05:38.910 --> 00:05:41.629 1 region. Which is what you do with an RI. Exactly. 00:05:41.670 --> 00:05:44.009 With a savings plan, you commit to spending a 00:05:44.009 --> 00:05:46.850 certain amount of money per hour on compute usage. 00:05:47.430 --> 00:05:50.000 For example, you might say, I commit to spending 00:05:50.000 --> 00:05:53.819 at least $20 per hour on compute services. Ah. 00:05:53.920 --> 00:05:55.959 OK, so it's a dollar commitment, not an instance 00:05:55.959 --> 00:05:58.420 commitment. Precisely. And that commitment automatically 00:05:58.420 --> 00:06:01.259 applies to eligible compute usage across different 00:06:01.259 --> 00:06:03.899 instance families, different sizes, even different 00:06:03.899 --> 00:06:06.639 AWS regions, and sometimes even across services 00:06:06.639 --> 00:06:09.459 like Fargate or Lambda, depending on the type 00:06:09.459 --> 00:06:11.339 of savings plan. OK, so there are different types 00:06:11.339 --> 00:06:13.779 of savings plans too. Yes, two main types. Compute 00:06:13.779 --> 00:06:16.519 savings plans are the most flexible. That 20 00:06:16.519 --> 00:06:18.509 -hour commitment we just talked about It could 00:06:18.509 --> 00:06:21.370 apply to an M5 instance today, a C6 instance 00:06:21.370 --> 00:06:23.389 tomorrow, maybe running an Oregon one week and 00:06:23.389 --> 00:06:26.529 Ohio the next. It even covers Fargate and Lambda, 00:06:26.990 --> 00:06:29.230 super flexible. So if you change instance types 00:06:29.230 --> 00:06:31.470 or regions, you keep the discount. You keep the 00:06:31.470 --> 00:06:33.370 discount as long as you're meeting that hourly 00:06:33.370 --> 00:06:36.470 dollar commitment. The other type is an EC2 instance 00:06:36.470 --> 00:06:39.230 savings plan. This one is a bit more like an 00:06:39.230 --> 00:06:42.389 RI you commit to using a specific instance family, 00:06:42.610 --> 00:06:46.310 like M5, within a specific region, like US East 00:06:46.310 --> 00:06:49.759 1. Less flexible than the compute SP. Less flexible, 00:06:49.939 --> 00:06:52.959 yes. But in return, it generally offers a slightly 00:06:52.959 --> 00:06:55.180 deeper discount than the compute savings plan 00:06:55.180 --> 00:06:57.639 for that specific family and region. So it's 00:06:57.639 --> 00:07:00.259 a trade -off. Maximum flexibility with compute 00:07:00.259 --> 00:07:02.860 SPs. Or potentially slightly better savings, 00:07:02.920 --> 00:07:06.660 but less flexibility with EC2 instance SPS. Got 00:07:06.660 --> 00:07:09.220 it. That flexibility seems really powerful, especially 00:07:09.220 --> 00:07:13.959 as architectures evolve. OK, one more major model. 00:07:14.439 --> 00:07:17.069 The one with the steepest discount. but also 00:07:17.069 --> 00:07:20.610 the biggest catch, spot instances. Spot instances. 00:07:21.089 --> 00:07:24.230 Yes, the potential savings here are, well, staggering. 00:07:24.589 --> 00:07:27.670 Up to 90 % off the on -demand price. 90%, how 00:07:27.670 --> 00:07:30.209 is that even possible? It's because you're essentially 00:07:30.209 --> 00:07:33.269 bidding on spare unused compute capacity that 00:07:33.269 --> 00:07:34.949 AWS happens to have at that moment. You say, 00:07:35.050 --> 00:07:36.930 I'm willing to pay up to this price for this 00:07:36.930 --> 00:07:39.370 instance type, and if your bid is above the current 00:07:39.370 --> 00:07:41.209 spot price and there's capacity, you get the 00:07:41.209 --> 00:07:42.930 instance. Okay, sounds great. What's the catch 00:07:42.930 --> 00:07:46.050 you mentioned? The catch is huge. Because it's 00:07:46.050 --> 00:07:48.649 spare capacity, AWS can reclaim it whenever they 00:07:48.649 --> 00:07:50.990 need it back for on -demand or reserved instance 00:07:50.990 --> 00:07:53.750 customers. And they only give you a very short 00:07:53.750 --> 00:07:56.269 warning, typically just two minutes. Two minutes. 00:07:56.310 --> 00:08:00.129 So your instance could just vanish. Oof. Gone. 00:08:00.589 --> 00:08:03.350 Terminated. Which means Spot instances are absolutely 00:08:03.350 --> 00:08:05.589 not suitable for workloads that can't handle 00:08:05.589 --> 00:08:07.889 interruption. Forget running your main database 00:08:07.889 --> 00:08:10.170 on Spot. Right. So what are they good for? They're 00:08:10.170 --> 00:08:12.410 fantastic for things that are fault tolerant 00:08:12.410 --> 00:08:15.769 and flexible. Think large -scale batch processing 00:08:15.769 --> 00:08:19.250 jobs, maybe big data analysis, scientific computing, 00:08:19.870 --> 00:08:22.790 rendering farms, tasks where if one instance 00:08:22.790 --> 00:08:25.009 gets terminated, the overall job can either restart 00:08:25.009 --> 00:08:27.089 that piece of work elsewhere or just carry on 00:08:27.089 --> 00:08:28.970 without it. You have to design your applications 00:08:28.970 --> 00:08:30.730 specifically for that potential interruption. 00:08:30.930 --> 00:08:33.470 Makes sense. High risk, high reward, but only 00:08:33.470 --> 00:08:35.929 if your workload fits. OK, and before we move 00:08:35.929 --> 00:08:37.750 off pricing, we should probably mention the AWS 00:08:37.750 --> 00:08:39.629 free tier, should we? Especially for listeners 00:08:39.629 --> 00:08:41.850 just starting out. Oh, absolutely essential. 00:08:42.080 --> 00:08:44.820 The free tier is how most people get their hands 00:08:44.820 --> 00:08:47.480 dirty with AWS without spending money initially. 00:08:48.120 --> 00:08:49.740 There are really two parts to it. Right. There's 00:08:49.740 --> 00:08:52.340 the 12 month one. Yes, the 12 -month free tier. 00:08:52.700 --> 00:08:54.980 When you first sign up for an AWS account, you 00:08:54.980 --> 00:08:57.580 get free usage allowances for a whole range of 00:08:57.580 --> 00:08:59.720 popular services for your first year. Things 00:08:59.720 --> 00:09:04.220 like 750 hours per month of a small EC2 instance. 00:09:04.440 --> 00:09:06.460 Enough to run a small website, basically. Exactly. 00:09:06.700 --> 00:09:09.399 And five gigabytes of S3 standard storage, a 00:09:09.399 --> 00:09:11.240 certain amount of database usage, and so on. 00:09:11.279 --> 00:09:13.519 It's quite generous for learning in small projects. 00:09:13.700 --> 00:09:16.389 But it expires after a year. It does. But then 00:09:16.389 --> 00:09:18.149 there's the always free tier. These are services 00:09:18.149 --> 00:09:20.769 that have a free usage allowance that never expires, 00:09:21.009 --> 00:09:23.809 even after your first year. Things like AWS Lambda, 00:09:24.070 --> 00:09:26.470 a million free requests per month, DynamoDB, 00:09:26.909 --> 00:09:29.049 a certain amount of storage and throughput, SNS 00:09:29.049 --> 00:09:31.450 notifications. So even experienced users can 00:09:31.450 --> 00:09:34.320 leverage those always free services. Absolutely. 00:09:34.519 --> 00:09:36.440 But the key thing, especially when you're in 00:09:36.440 --> 00:09:39.679 that first 12 -month period, is to monitor your 00:09:39.679 --> 00:09:42.360 usage. It's easy to accidentally go over those 00:09:42.360 --> 00:09:44.200 free tier limits, and that's often how people 00:09:44.200 --> 00:09:47.460 get their first unexpected AWS bill. So keeping 00:09:47.460 --> 00:09:49.240 an eye on those limits is kind of your first 00:09:49.240 --> 00:09:52.240 lesson in AWS cost management. Good point. So 00:09:52.240 --> 00:09:54.259 we've got the cost drivers, the pricing models. 00:09:55.519 --> 00:09:58.100 Let's shift gears a bit. How do organizations 00:09:58.100 --> 00:10:01.019 make the big strategic decisions, like deciding 00:10:01.019 --> 00:10:02.940 to move to AWS in the first place? You mentioned 00:10:02.940 --> 00:10:05.240 TCO earlier. Right. Total cost of ownership, 00:10:05.580 --> 00:10:08.139 TCO. This is the big financial framework used 00:10:08.139 --> 00:10:10.960 to justify moving from an on -premises data center 00:10:10.960 --> 00:10:14.919 to the cloud. It's all about making a fair comparison. 00:10:15.360 --> 00:10:17.340 What goes into that comparison? It's not just 00:10:17.340 --> 00:10:19.200 the cost of the servers, right? Not at all. That's 00:10:19.200 --> 00:10:21.840 a common mistake. A proper TCO analysis includes 00:10:21.840 --> 00:10:25.080 the obvious server hardware costs, yes, and software 00:10:25.080 --> 00:10:27.940 licenses. But crucially, it also has to include 00:10:27.940 --> 00:10:31.059 facilities costs, like the electricity to power 00:10:31.059 --> 00:10:33.179 those servers, the industrial air conditioning 00:10:33.179 --> 00:10:36.019 to cool them, the physical security for the building, 00:10:36.080 --> 00:10:38.679 the actual square footage costs of the data center 00:10:38.679 --> 00:10:41.340 space. OK, the hidden infrastructure costs. Exactly. 00:10:41.500 --> 00:10:43.200 And then there's storage costs, not just the 00:10:43.200 --> 00:10:46.019 disks, but backup system. tape libraries, et 00:10:46.019 --> 00:10:49.500 cetera, and maybe the biggest often underestimated 00:10:49.500 --> 00:10:52.580 cost? Labor. The people cost. The people cost. 00:10:52.860 --> 00:10:55.139 How much time do your IT staff spend racking 00:10:55.139 --> 00:10:57.860 servers, replacing failed drives, patching operating 00:10:57.860 --> 00:11:00.259 systems, managing network gear, doing backups, 00:11:00.580 --> 00:11:04.100 all that operational toil? The argument for AWS 00:11:04.100 --> 00:11:06.440 is that by shifting that burden to them, your 00:11:06.440 --> 00:11:09.730 team can focus on higher value work. And AWS 00:11:09.730 --> 00:11:12.649 has tools to help with this. They do. The AWS 00:11:12.649 --> 00:11:14.909 TCO Calculator is a web -based tool where you 00:11:14.909 --> 00:11:17.309 can input details about your current on -premise 00:11:17.309 --> 00:11:19.590 environment, and it helps generate a comparison 00:11:19.590 --> 00:11:21.950 report showing the potential savings with AWS. 00:11:22.450 --> 00:11:24.690 It's a key tool for building that initial business 00:11:24.690 --> 00:11:27.070 case. Makes sense. Okay, another organizational 00:11:27.070 --> 00:11:29.090 thing. What about large companies with lots of 00:11:29.090 --> 00:11:31.529 different departments or projects all using AWS? 00:11:31.970 --> 00:11:33.970 How do they manage that financially? That's where 00:11:33.970 --> 00:11:36.710 AWS organizations and consolidated billing come 00:11:36.710 --> 00:11:40.519 in. This is a really powerful feature. AWS Organizations 00:11:40.519 --> 00:11:44.120 lets you group multiple AWS accounts. Maybe one 00:11:44.120 --> 00:11:46.779 for marketing, one for engineering, one for finance 00:11:46.779 --> 00:11:49.759 under a single central management account. Okay, 00:11:49.840 --> 00:11:51.580 so brings them all together administratively. 00:11:51.919 --> 00:11:54.179 What's the financial benefit? Two main ones. 00:11:54.399 --> 00:11:58.419 First, volume discounts. Many AWS services, like 00:11:58.419 --> 00:12:01.240 S3 storage or data transfer, have tiered pricing. 00:12:01.759 --> 00:12:04.279 The more you use, the cheaper the per unit cost 00:12:04.279 --> 00:12:07.759 gets. With consolidated billing, AWS pools the 00:12:07.759 --> 00:12:10.179 usage across all the accounts in your organization. 00:12:10.440 --> 00:12:12.840 Ah, so even if individual accounts don't use 00:12:12.840 --> 00:12:15.299 much, the combined usage might push the whole 00:12:15.299 --> 00:12:18.080 organization into a cheaper pricing tier. Precisely. 00:12:18.259 --> 00:12:20.460 Everyone benefits from the aggregated volume. 00:12:21.120 --> 00:12:23.340 The second big benefit is simplified cost tracking 00:12:23.340 --> 00:12:25.740 and governance. The management account gets one 00:12:25.740 --> 00:12:27.740 single bill covering all the linked accounts. 00:12:28.059 --> 00:12:30.000 And you can easily use things like tags, which 00:12:30.000 --> 00:12:31.840 we'll talk about, or just the structure of the 00:12:31.840 --> 00:12:33.799 linked accounts themselves to see exactly how 00:12:33.799 --> 00:12:35.879 much each department or project is spending. 00:12:36.159 --> 00:12:38.779 It makes chargeback or showback much easier for 00:12:38.779 --> 00:12:41.460 the finance teams. Right, visibility and potentially 00:12:41.460 --> 00:12:44.019 lower costs through volume. Okay, we've got the 00:12:44.019 --> 00:12:46.700 strategies, the frameworks, but how do you actually 00:12:46.700 --> 00:12:48.580 track this stuff day to day? I mean, you mentioned 00:12:48.580 --> 00:12:50.320 that first bill shock, everyone wants to avoid 00:12:50.320 --> 00:12:52.700 that. What are the tools? Yeah, knowing the theory 00:12:52.700 --> 00:12:56.000 is one thing. Actually managing it requires using 00:12:56.000 --> 00:12:58.460 the right tools. The starting point is usually 00:12:58.460 --> 00:13:01.179 the billing dashboard in the AWS console. What 00:13:01.179 --> 00:13:03.179 do you get there? It's your main overview. You'll 00:13:03.179 --> 00:13:05.740 see your current month to date spend, your forecast 00:13:05.740 --> 00:13:08.519 for the month, a breakdown of spending by service, 00:13:08.779 --> 00:13:12.120 your payment history, access to your actual invoices. 00:13:12.519 --> 00:13:15.240 It's the central hub. OK, the high level view. 00:13:15.779 --> 00:13:17.879 But what if you see a spike and need to figure 00:13:17.879 --> 00:13:21.659 out why? That's when you dive into AWS Cost Explorer. 00:13:22.000 --> 00:13:24.700 This is a much more powerful visualization tool. 00:13:24.980 --> 00:13:27.899 You can graph your costs over time, daily, monthly. 00:13:28.299 --> 00:13:31.019 You can filter that data in countless ways. Show 00:13:31.019 --> 00:13:33.519 me just EC2 costs, just costs for the production 00:13:33.519 --> 00:13:36.299 account, just costs associated with a specific 00:13:36.299 --> 00:13:38.759 Project X tag. So you can really slice and dice 00:13:38.759 --> 00:13:41.330 the data to find the source of spending. Exactly. 00:13:41.789 --> 00:13:45.129 And a really key feature is its forecasting capability. 00:13:45.669 --> 00:13:48.169 Based on your recent usage patterns, Cost Explorer 00:13:48.169 --> 00:13:50.289 can project your spending for the next few months, 00:13:50.610 --> 00:13:52.929 helping you anticipate future bills and adjust 00:13:52.929 --> 00:13:56.090 if needed. OK, so Cost Explorer is for analyzing 00:13:56.090 --> 00:13:58.830 past and future spending. What about preventing 00:13:58.830 --> 00:14:01.470 overspending before it happens? That's the job 00:14:01.470 --> 00:14:05.190 of AWS Budgets. This tool lets you set specific 00:14:05.190 --> 00:14:08.049 thresholds for either cost or usage. You could 00:14:08.049 --> 00:14:10.980 say, alert me if my toll monthly spend exceeds 00:14:10.980 --> 00:14:14.659 $1 ,000 or alert me if my S3 storage goes over 00:14:14.659 --> 00:14:16.639 five terabytes. And it just sends you an email 00:14:16.639 --> 00:14:18.799 or something? Yep. You configure notifications, 00:14:19.000 --> 00:14:21.360 email, SNS topics so that the moment a budget 00:14:21.360 --> 00:14:23.539 threshold is breached or even just forecasted 00:14:23.539 --> 00:14:25.860 to be breached, you get an alert. It's your early 00:14:25.860 --> 00:14:28.299 warning system. Super important for avoiding 00:14:28.299 --> 00:14:30.700 those nasty surprises. Definitely sounds useful. 00:14:30.919 --> 00:14:33.240 Now I've heard about something called CUR files, 00:14:33.519 --> 00:14:36.820 cost and usage reports. What are those? Ah, the 00:14:36.820 --> 00:14:40.610 cost and usage reports or CUR. Okay, these are 00:14:40.610 --> 00:14:42.990 the most detailed billing data you can possibly 00:14:42.990 --> 00:14:46.669 get from AWS. We're talking incredibly granular 00:14:46.669 --> 00:14:49.690 information about every single resource usage, 00:14:50.110 --> 00:14:52.990 down to the hour, with pricing details, tags, 00:14:53.309 --> 00:14:55.710 everything. And intense. It is. They're delivered 00:14:55.710 --> 00:14:58.850 as large, complex CSV files to an S3 bucket, 00:14:58.929 --> 00:15:01.269 you specify. These are not really meant for casual 00:15:01.269 --> 00:15:03.950 browsing in Excel. CUR files are designed for 00:15:03.950 --> 00:15:06.389 organizations that want to feed this raw data 00:15:06.389 --> 00:15:09.129 into their own sophisticated business intelligence, 00:15:09.409 --> 00:15:12.629 BI tools, data warehouses, or third -party cost 00:15:12.629 --> 00:15:15.440 management platforms for real - really deep customized 00:15:15.440 --> 00:15:17.980 analysis and automation. So power user level 00:15:17.980 --> 00:15:20.159 stuff for deep integration. Definitely. For most 00:15:20.159 --> 00:15:22.100 day to day tracking, cost exploring budgets are 00:15:22.100 --> 00:15:23.980 where you'll spend your time. Got it. And one 00:15:23.980 --> 00:15:26.019 more tool maybe for the planning stage. before 00:15:26.019 --> 00:15:28.440 you've even deployed anything. Right. The Simple 00:15:28.440 --> 00:15:31.200 Monthly Calculator, or now often referred to 00:15:31.200 --> 00:15:34.580 as the AWS Pricing Calculator, this is a web 00:15:34.580 --> 00:15:36.960 tool you use before you build. You can model 00:15:36.960 --> 00:15:39.440 out a potential architecture, say two web servers 00:15:39.440 --> 00:15:42.200 of this size, a database of that size, estimate 00:15:42.200 --> 00:15:44.259 your data transfer, and it gives you an estimated 00:15:44.259 --> 00:15:47.059 monthly cost. Crucial for planning and getting 00:15:47.059 --> 00:15:49.399 budget approval before you start incurring charges. 00:15:49.820 --> 00:15:53.039 Okay. Great overview of the tools. So using these 00:15:53.039 --> 00:15:55.840 tools, understanding the models, it all leads 00:15:55.840 --> 00:15:58.120 towards optimization, right? Keeping that bill 00:15:58.120 --> 00:16:01.080 under control. What are the key best practices 00:16:01.080 --> 00:16:03.500 here? Absolutely. Optimization is an ongoing 00:16:03.500 --> 00:16:06.039 process, not a one -time fix. There are probably 00:16:06.039 --> 00:16:08.799 six core best practices that every organization 00:16:08.799 --> 00:16:11.100 serious about cloud costs follows. Let's hear 00:16:11.100 --> 00:16:13.440 them. Number one. Number one is almost always 00:16:13.440 --> 00:16:16.059 right sizing. This means constantly evaluating 00:16:16.059 --> 00:16:17.840 if the resources you're running are actually 00:16:17.840 --> 00:16:20.220 the appropriate size for the workload. Are you 00:16:20.220 --> 00:16:23.100 paying for a huge, powerful EC2 instance when 00:16:23.100 --> 00:16:25.679 its CPU utilization is only hovering around 10 00:16:25.679 --> 00:16:27.480 %? Right. Paying for capacity you don't need. 00:16:27.820 --> 00:16:30.720 Exactly. So monitor your utilization metrics. 00:16:30.730 --> 00:16:33.590 using CloudWatch, for instance, and downsize 00:16:33.590 --> 00:16:36.370 instances that are over -provisioned. Conversely, 00:16:36.730 --> 00:16:39.070 make sure instances aren't under -provisioned 00:16:39.070 --> 00:16:41.909 and struggling. And using autoscaling is part 00:16:41.909 --> 00:16:44.450 of this automatically adding or removing instances 00:16:44.450 --> 00:16:46.929 based on demand, so you're only paying for what 00:16:46.929 --> 00:16:50.090 you need at any given time. Makes sense. OK, 00:16:50.269 --> 00:16:52.009 number two and three probably relate back to 00:16:52.009 --> 00:16:54.360 our pricing discussion. You got it. Number two 00:16:54.360 --> 00:16:57.779 is using reserved instances or savings plans. 00:16:58.179 --> 00:17:00.659 For any workload that has predictable steady 00:17:00.659 --> 00:17:03.299 state usage, you should absolutely be leveraging 00:17:03.299 --> 00:17:05.900 these commitment based discounts. Leaving predictable 00:17:05.900 --> 00:17:08.519 workloads running on demand is just leaving money 00:17:08.519 --> 00:17:11.000 on the table. And number three. Leveraging spot 00:17:11.000 --> 00:17:13.119 instances. For those workloads that are fault 00:17:13.119 --> 00:17:15.960 tolerant and flexible, using spot can drastically 00:17:15.960 --> 00:17:18.700 cut costs. It requires careful architecture, 00:17:18.700 --> 00:17:21.839 but the savings can be enormous. Okay, so match 00:17:21.839 --> 00:17:23.880 the pricing model to the workload characteristics. 00:17:24.000 --> 00:17:26.279 What's number four? Diligent monitoring. You 00:17:26.279 --> 00:17:28.920 can't optimize what you can't see. This means 00:17:28.920 --> 00:17:31.599 regularly checking Cost Explorer, setting up 00:17:31.599 --> 00:17:34.140 AWS budgets for alerts, and generally keeping 00:17:34.140 --> 00:17:36.900 an eye on your spending trends. Catching anomalies 00:17:36.900 --> 00:17:39.519 early is key. That test environment someone forgot 00:17:39.519 --> 00:17:42.019 to shut down over the weekend. Monitoring catches 00:17:42.019 --> 00:17:44.420 that. Good point. Number five. This one's crucial 00:17:44.420 --> 00:17:46.880 for visibility, especially in larger organizations. 00:17:47.299 --> 00:17:51.059 Tag resources. AWS allows you to apply metadata 00:17:51.059 --> 00:17:54.440 tags, key value pairs like project .phoenix or 00:17:54.440 --> 00:17:57.180 department .marketing, to almost all your resources. 00:17:57.460 --> 00:18:00.519 And Cost Explorer can filter by these tags. Exactly. 00:18:00.660 --> 00:18:02.960 If you consistently tag your resources, you can 00:18:02.960 --> 00:18:05.759 then use Cost Explorer or CUR reports to see 00:18:05.759 --> 00:18:08.099 exactly how much Project Phoenix cost last month, 00:18:08.400 --> 00:18:10.660 or which department is responsible for that spike 00:18:10.660 --> 00:18:13.640 in S3 spending. Without tags, it just becomes 00:18:13.640 --> 00:18:16.759 one big undifferentiated bill. Tags are essential 00:18:16.759 --> 00:18:19.319 for accountability and cost allocation. Got it. 00:18:19.380 --> 00:18:21.859 Seems like good hygiene. And the last one, number 00:18:21.859 --> 00:18:24.460 six. It sounds simple, but it's often overlooked. 00:18:24.660 --> 00:18:27.359 Turning off idle resources. If developers spin 00:18:27.359 --> 00:18:29.759 up test environments and forget about them, or 00:18:29.759 --> 00:18:32.019 if you have resources running overnight or on 00:18:32.019 --> 00:18:34.259 weekends that aren't actually being used, shut 00:18:34.259 --> 00:18:37.970 them down. Stop the instance. Delete the unused 00:18:37.970 --> 00:18:40.930 EBS volume. Remember, you pay for things while 00:18:40.930 --> 00:18:43.430 they're running, so don't pay for resources that 00:18:43.430 --> 00:18:45.450 are just sitting idle. Shut down what you're 00:18:45.450 --> 00:18:48.049 not using. Makes perfect sense. Okay, so those 00:18:48.049 --> 00:18:50.289 are great optimization practices. What about 00:18:50.289 --> 00:18:52.609 getting help from AWS when things go wrong, or 00:18:52.609 --> 00:18:54.609 even just for advice? Let's talk about support 00:18:54.609 --> 00:18:58.130 plans. Right. AWS offers different tiers of paid 00:18:58.130 --> 00:19:00.470 support on top of the basic help everyone gets. 00:19:00.809 --> 00:19:02.869 There are four main levels. Okay. What's the 00:19:02.869 --> 00:19:05.210 baseline? Basic support. This comes free with 00:19:05.210 --> 00:19:08.690 every AWS account. It gives you access to documentation, 00:19:09.089 --> 00:19:11.569 white papers, support forums, and importantly, 00:19:11.730 --> 00:19:13.750 you can open support cases for billing questions 00:19:13.750 --> 00:19:16.569 or account issues, but no technical support for 00:19:16.569 --> 00:19:18.990 your actual running services. Okay. Free, but 00:19:18.990 --> 00:19:20.910 limited to billing and docs. What's the first 00:19:20.910 --> 00:19:23.779 paid tier? That's developer support. It starts 00:19:23.779 --> 00:19:26.680 at around $29 per month plus a percentage of 00:19:26.680 --> 00:19:29.400 usage. This gets you technical support via email, 00:19:29.500 --> 00:19:31.740 but generally only during business hours with 00:19:31.740 --> 00:19:34.259 response time goals measured in hours. It's aimed 00:19:34.259 --> 00:19:36.640 at individual developers or small teams doing 00:19:36.640 --> 00:19:39.059 testing. Okay, email support during business 00:19:39.059 --> 00:19:41.339 hours. What's the next step up? Business support. 00:19:41.519 --> 00:19:43.920 This is probably the most common paid tier for 00:19:43.920 --> 00:19:46.420 organizations running production workloads. It 00:19:46.420 --> 00:19:48.720 starts at around $100 per month, plus a percentage 00:19:48.720 --> 00:19:52.859 of usage. The big step up here is 247 access 00:19:52.859 --> 00:19:55.400 to technical support via email, chat, and phone 00:19:55.400 --> 00:19:58.400 with much faster response time goals, often under 00:19:58.400 --> 00:20:01.299 an hour for critical issues. 247 phone support. 00:20:01.380 --> 00:20:03.690 That sounds important for production. Anything 00:20:03.690 --> 00:20:06.329 else with business? Yes. A really valuable benefit 00:20:06.329 --> 00:20:09.329 is full access to AWS Trusted Advisor checks. 00:20:09.730 --> 00:20:11.589 Trusted Advisor automatically scans your AWS 00:20:11.589 --> 00:20:13.549 environment and provides recommendations across 00:20:13.549 --> 00:20:15.690 several categories, including cost optimization, 00:20:16.029 --> 00:20:18.369 security, performance, and fault tolerance. Business 00:20:18.369 --> 00:20:21.109 support unlocks all the checks. So proactive 00:20:21.109 --> 00:20:23.509 advice, not just reactive support. OK. And the 00:20:23.509 --> 00:20:26.009 top tier? The top tier is enterprise support. 00:20:26.299 --> 00:20:28.160 This is for large organizations with mission 00:20:28.160 --> 00:20:30.680 -critical workloads and significant AWS spend. 00:20:31.200 --> 00:20:35.180 Pricing starts at $15 ,000 per month. $15 ,000. 00:20:35.180 --> 00:20:37.660 Wow. What do you get for that? You get everything 00:20:37.660 --> 00:20:40.240 in business support, plus even faster response 00:20:40.240 --> 00:20:43.099 times, like 15 minutes for critical issues. But 00:20:43.099 --> 00:20:45.480 the real differentiator is you get assigned a 00:20:45.480 --> 00:20:49.000 dedicated technical account manager. or TAM. 00:20:49.200 --> 00:20:51.920 A TAM? What do they do? A TAM is basically your 00:20:51.920 --> 00:20:54.599 dedicated advocate and strategic advisor within 00:20:54.599 --> 00:20:56.960 AWS. They get to know your architecture, your 00:20:56.960 --> 00:20:58.839 business goals, they help with infrastructure 00:20:58.839 --> 00:21:01.579 planning, operational reviews, coordinating AWS 00:21:01.579 --> 00:21:04.079 resources during major events or issues. It's 00:21:04.079 --> 00:21:07.059 a very high touch proactive partnership. White 00:21:07.059 --> 00:21:09.339 glove service, essentially. Okay, so a dedicated 00:21:09.339 --> 00:21:12.680 guide inside AWS. That makes sense for huge deployments. 00:21:13.099 --> 00:21:15.160 All right, we've covered a ton. Models, tools, 00:21:15.519 --> 00:21:17.279 optimization, support. Let's try to tie it all 00:21:17.279 --> 00:21:18.859 together. Can we walk through a hypothetical 00:21:18.859 --> 00:21:22.519 example? KV. University cloud lab environment. 00:21:22.660 --> 00:21:24.519 How would all these concepts play out there? 00:21:24.859 --> 00:21:26.720 Oh, a university is a perfect example because 00:21:26.720 --> 00:21:28.880 you have such diverse users and needs. It's like 00:21:28.880 --> 00:21:31.339 a mini enterprise. OK, so where would we start? 00:21:31.920 --> 00:21:34.400 Students. Right. Your students who are just learning 00:21:34.400 --> 00:21:37.480 AWS doing coursework. They'd primarily be using 00:21:37.480 --> 00:21:40.440 the free tier, setting up small EC2 instances 00:21:40.440 --> 00:21:44.019 using S3 for projects. The university benefits 00:21:44.019 --> 00:21:46.839 because the students learn valuable skills at 00:21:46.839 --> 00:21:49.359 basically zero cost, assuming they stay within 00:21:49.359 --> 00:21:51.940 the limits. It also teaches them cost awareness 00:21:51.940 --> 00:21:54.730 early on. Makes sense. What about faculty doing 00:21:54.730 --> 00:21:56.970 research, maybe needing a burst of compute for 00:21:56.970 --> 00:21:59.269 a few weeks for a specific project? For those 00:21:59.269 --> 00:22:01.630 kinds of short -term, potentially unpredictable 00:22:01.630 --> 00:22:04.130 research projects, faculty might rely heavily 00:22:04.130 --> 00:22:07.210 on on -demand instances. They need the flexibility 00:22:07.210 --> 00:22:10.029 to spin up resources quickly for a specific experiment 00:22:10.029 --> 00:22:12.309 and then shut them down. The higher on -demand 00:22:12.309 --> 00:22:15.109 cost is acceptable because the usage is temporary 00:22:15.109 --> 00:22:18.299 and specific. OK. Now, what about the core university 00:22:18.299 --> 00:22:21.079 systems, like the student registration portal 00:22:21.079 --> 00:22:22.900 or the learning management system like Moodle 00:22:22.900 --> 00:22:25.299 or Blackboard? Those need to be always on, right? 00:22:25.420 --> 00:22:28.740 Exactly. For those critical steady -state administrative 00:22:28.740 --> 00:22:32.599 systems that run 24 -7, the university IT department 00:22:32.599 --> 00:22:36.460 would absolutely use reserved instances, or more 00:22:36.460 --> 00:22:39.559 likely now, savings plans. They know these systems 00:22:39.559 --> 00:22:41.680 will be running constantly, so committing for 00:22:41.680 --> 00:22:43.980 one or three years gives them those deep discounts 00:22:43.980 --> 00:22:46.660 we talked about, saving significant money compared 00:22:46.660 --> 00:22:48.660 to on -demand. All right, so different pricing 00:22:48.660 --> 00:22:50.700 models for different user groups and workloads. 00:22:51.119 --> 00:22:53.460 How would they manage the budgets across, say, 00:22:53.500 --> 00:22:55.430 the physics department versus the Arts Department. 00:22:55.680 --> 00:22:58.720 They definitely use AWS organizations to group 00:22:58.720 --> 00:23:00.859 all the departmental accounts under a central 00:23:00.859 --> 00:23:03.460 university IT management account. This gives 00:23:03.460 --> 00:23:05.960 them that consolidated billing benefit pooling 00:23:05.960 --> 00:23:10.039 usage for volume discounts. And then within organizations, 00:23:10.099 --> 00:23:12.420 they'd set up AWS budgets for each department 00:23:12.420 --> 00:23:15.140 or maybe even major research grants. The physics 00:23:15.140 --> 00:23:17.440 department might get a $5 ,000 monthly budget. 00:23:17.619 --> 00:23:20.700 Arts gets $500. If a department starts to exceed 00:23:20.700 --> 00:23:22.759 its budget, alerts go out to the department head 00:23:22.759 --> 00:23:25.500 in central IT. It enforces accountability. And 00:23:25.500 --> 00:23:27.700 tracking usage patterns, maybe seeing when things 00:23:27.700 --> 00:23:30.220 get busy. That's where Cost Explorer comes in. 00:23:30.519 --> 00:23:32.980 Central IT would use it to monitor overall trends. 00:23:33.500 --> 00:23:36.339 They'd probably see huge usage spikes around 00:23:36.339 --> 00:23:38.539 final exam periods, right? When everyone's hitting 00:23:38.539 --> 00:23:40.839 the learning system or running simulations. Yeah, 00:23:41.000 --> 00:23:43.079 definitely. Seeing that pattern in Cost Explorer 00:23:43.079 --> 00:23:45.660 helps them plan capacity for the next exam period. 00:23:46.039 --> 00:23:48.480 They might even use tags to see if one specific 00:23:48.480 --> 00:23:50.839 course or research project is driving a lot of 00:23:50.839 --> 00:23:53.829 cost. And finally, support. What level would 00:23:53.829 --> 00:23:56.910 a university likely choose? Given the criticality 00:23:56.910 --> 00:23:58.890 of systems like the Learning Platform, especially 00:23:58.890 --> 00:24:01.730 during exams, they'd almost certainly need more 00:24:01.730 --> 00:24:04.289 than basic support. They'd likely opt for the 00:24:04.289 --> 00:24:07.690 Business Support Plan. That 247 phone access 00:24:07.690 --> 00:24:10.170 and the quicker response times for critical issues 00:24:10.170 --> 00:24:12.730 would be essential to ensure uptime for students 00:24:12.730 --> 00:24:15.230 and faculty when it matters most. Okay, that 00:24:15.230 --> 00:24:18.109 paints a really clear picture of how all these 00:24:18.109 --> 00:24:20.509 different pieces, pricing, tools, structure, 00:24:20.809 --> 00:24:23.529 support, come together in a real -world scenario. 00:24:24.490 --> 00:24:27.390 So, wrapping things up, what we've really established 00:24:27.390 --> 00:24:30.579 today is that Understanding AWS economics isn't 00:24:30.579 --> 00:24:33.440 just an add -on skill. It's fundamental. It's 00:24:33.440 --> 00:24:35.200 about shifting your mindset from just buying 00:24:35.200 --> 00:24:38.140 server capacity to actively managing resource 00:24:38.140 --> 00:24:41.190 consumption. Exactly. Being able to explain these 00:24:41.190 --> 00:24:43.130 different pricing strategies, knowing how to 00:24:43.130 --> 00:24:45.289 use the billing tools effectively, and critically, 00:24:45.490 --> 00:24:47.829 being able to align cloud spending with the actual 00:24:47.829 --> 00:24:50.170 financial goals of your organization, that's 00:24:50.170 --> 00:24:52.390 what defines a truly skilled cloud practitioner 00:24:52.390 --> 00:24:54.470 today. It's about understanding the trade -offs. 00:24:54.710 --> 00:24:56.609 The flexibility of on -demand versus the savings 00:24:56.609 --> 00:24:59.210 of commitment with RIs and SPIs, knowing when 00:24:59.210 --> 00:25:01.190 to use Spot, that's where the real value lies. 00:25:01.529 --> 00:25:03.349 You have to see the cloud as this constantly 00:25:03.349 --> 00:25:07.000 running financial ledger, basically. Okay, so 00:25:07.000 --> 00:25:08.940 here is a final thought for you our listener 00:25:08.940 --> 00:25:11.619 to chew on building on what we discussed about 00:25:11.619 --> 00:25:14.779 AWS organizations Given how powerful consolidated 00:25:14.779 --> 00:25:17.240 billing is and the volume discounts it enables 00:25:17.240 --> 00:25:19.299 which really push companies towards putting everything 00:25:19.299 --> 00:25:22.559 under that one financial umbrella How might the 00:25:22.559 --> 00:25:25.339 purely financial incentives baked into AWS organizations 00:25:25.339 --> 00:25:27.680 actually start to change the internal operational 00:25:27.680 --> 00:25:29.440 structure, maybe even the internal politics, 00:25:29.900 --> 00:25:32.039 of a company compared to the old world of separate 00:25:32.039 --> 00:25:34.759 siloed IT budgets for each department? That's 00:25:34.759 --> 00:25:36.099 the strategic governance question we'll leave 00:25:36.099 --> 00:25:36.440 you with.