WEBVTT 00:00:00.000 --> 00:00:01.960 Welcome to the deep dive. If you're building 00:00:01.960 --> 00:00:04.179 anything serious, well, really anything in tech 00:00:04.179 --> 00:00:05.980 today, you're probably working in the cloud. 00:00:06.059 --> 00:00:08.259 And if you're in the cloud, you absolutely need 00:00:08.259 --> 00:00:10.759 a solid blueprint. So today we're diving deep 00:00:10.759 --> 00:00:13.439 into what's arguably the foundational concept 00:00:13.439 --> 00:00:16.120 for building well on AWS, the well architected 00:00:16.120 --> 00:00:18.879 framework, the WA framework. Yeah. And our sources 00:00:18.879 --> 00:00:20.800 are really clear on this. This isn't some academic 00:00:20.800 --> 00:00:24.440 paper. It's like, Distilled wisdom from AWS working 00:00:24.440 --> 00:00:26.379 with literally millions of customers over the 00:00:26.379 --> 00:00:29.079 years It's the playbook really for avoiding those 00:00:29.079 --> 00:00:31.339 costly mistakes and building things that you 00:00:31.339 --> 00:00:34.140 know actually work and last That's exactly right 00:00:34.140 --> 00:00:36.179 and our mission today for you listening is to 00:00:36.179 --> 00:00:38.539 give you that cohesive understanding Think of 00:00:38.539 --> 00:00:41.439 the WA framework as your blueprint for excellence 00:00:41.439 --> 00:00:44.399 in the cloud It helps you build workloads that 00:00:44.399 --> 00:00:47.719 are well secure high -performing resilient efficient 00:00:47.719 --> 00:00:51.359 and increasingly important sustainable, too It's 00:00:51.359 --> 00:00:53.820 a structure approach we're talking about. A consistent 00:00:53.820 --> 00:00:56.439 way to look at your designs, evaluate them, and 00:00:56.439 --> 00:00:58.759 implement scalable solutions. It's all built 00:00:58.759 --> 00:01:01.759 around these foundational principles and six 00:01:01.759 --> 00:01:04.079 core pillars. If you miss this structure, you're 00:01:04.079 --> 00:01:06.019 kind of just winning it. Honestly, getting this 00:01:06.019 --> 00:01:08.079 framework is fundamental. It's how you go from 00:01:08.079 --> 00:01:11.420 just using AWS to really mastering it, building 00:01:11.420 --> 00:01:14.359 well, as they say. OK, Blueprint. I like that. 00:01:14.620 --> 00:01:16.459 Let's unpack it then. You mentioned six pillars 00:01:16.459 --> 00:01:18.340 holding this whole thing up. To really get it, 00:01:18.340 --> 00:01:20.140 we need to know what each one focuses on and 00:01:20.140 --> 00:01:22.480 maybe more important. what core question it answers 00:01:22.480 --> 00:01:24.640 for us, right? Let's start with the operations 00:01:24.640 --> 00:01:28.739 side. Operational excellence or OPEX. What's 00:01:28.739 --> 00:01:31.400 that really demand from us day to day? Operational 00:01:31.400 --> 00:01:33.340 excellence. Yeah, you could argue this is where 00:01:33.340 --> 00:01:37.719 a lot of the daily grind focus. lands. It's about 00:01:37.719 --> 00:01:39.780 running and monitoring your systems effectively. 00:01:40.319 --> 00:01:42.400 But maybe even more critically, it's about continually 00:01:42.400 --> 00:01:44.640 improving your processes. It's shifting from 00:01:44.640 --> 00:01:46.900 seeing architecture as static to something that 00:01:46.900 --> 00:01:49.700 evolves. Right. So moving away from manual fixes 00:01:49.700 --> 00:01:53.390 and firefighting during outages. What are the 00:01:53.390 --> 00:01:55.829 key concepts here? What tools help us get that 00:01:55.829 --> 00:01:59.170 smooth automated operation? Consistency and automation 00:01:59.170 --> 00:02:01.510 are central. You absolutely need to be using 00:02:01.510 --> 00:02:03.909 infrastructure as code ISC for managing changes 00:02:03.909 --> 00:02:06.590 programmatically. Automating deployments, making 00:02:06.590 --> 00:02:08.689 sure changes are frequent, small, reversible, 00:02:08.969 --> 00:02:11.530 that's key. If something breaks, you roll it 00:02:11.530 --> 00:02:14.330 back instantly. Ah. much less painful than figuring 00:02:14.330 --> 00:02:16.229 out what went wrong in some massive quarterly 00:02:16.229 --> 00:02:19.169 update. Minimizes human error too, I guess. Exactly. 00:02:19.330 --> 00:02:22.229 And a huge part of OPEX is observability. You 00:02:22.229 --> 00:02:25.030 need detailed logging, monitoring, think services 00:02:25.030 --> 00:02:28.009 like Amazon CloudWatch, AWS CloudTrail, and you 00:02:28.009 --> 00:02:30.610 need to clearly define what healthy means for 00:02:30.610 --> 00:02:33.650 your workload using KPIs, key performance indicators. 00:02:34.409 --> 00:02:37.150 The driving question here really is, how do we 00:02:37.150 --> 00:02:39.750 run and monitor our systems effectively to deliver 00:02:39.750 --> 00:02:43.020 business value smoothly? Okay, operation smooth. 00:02:43.479 --> 00:02:46.240 Then we hit the big one. Security. Everyone says 00:02:46.240 --> 00:02:48.560 it's job zero, the non -negotiable foundation, 00:02:49.099 --> 00:02:50.759 because you can't just bolt on security later, 00:02:50.879 --> 00:02:53.180 right? The focus is protecting info, systems, 00:02:53.379 --> 00:02:55.800 confidentiality, integrity, availability, the 00:02:55.800 --> 00:02:58.099 whole triad. Security is definitely paramount. 00:02:58.120 --> 00:03:00.939 And it's where you immediately bump into the 00:03:00.939 --> 00:03:04.000 famous shared responsibility model. It is so 00:03:04.000 --> 00:03:05.979 critical that you as the customer know exactly 00:03:05.979 --> 00:03:08.219 what you're responsible for versus what AWS handles. 00:03:08.479 --> 00:03:10.580 AWS secures the cloud of the cloud, the physical 00:03:10.580 --> 00:03:14.099 infrastructure, the core services. But you, you're 00:03:14.099 --> 00:03:15.219 responsible. responsible for security in the 00:03:15.219 --> 00:03:17.819 cloud, your data, your configurations, your OS 00:03:17.819 --> 00:03:20.180 patches. Getting that split wrong sounds like 00:03:20.180 --> 00:03:22.960 an instant disaster. It can be. Yeah. So give 00:03:22.960 --> 00:03:25.120 us the must -nos. What are the key defenses we 00:03:25.120 --> 00:03:27.180 need to think about? Well, identity and access 00:03:27.180 --> 00:03:30.020 management, IAM, is absolutely fundamental, controlling 00:03:30.020 --> 00:03:32.860 who can do what, when, and why. And closely tied 00:03:32.860 --> 00:03:34.800 to that is the principle of least privilege. 00:03:35.360 --> 00:03:37.639 Only grant the minimum permissions needed for 00:03:37.639 --> 00:03:41.159 a task, nothing more. ever, then layer on encryption. 00:03:41.699 --> 00:03:44.120 Data needs to be encrypted both in transit, moving 00:03:44.120 --> 00:03:46.860 across networks, and at rest when it's stored. 00:03:47.599 --> 00:03:49.939 Mandatory. And we need ways to detect problems, 00:03:50.199 --> 00:03:52.080 too, right? Not just prevention. Oh, absolutely. 00:03:52.300 --> 00:03:54.439 Detective controls are essential. Things like 00:03:54.439 --> 00:03:56.439 Amazon GuardDuty, which monitors for malicious 00:03:56.439 --> 00:04:00.120 activity, or AWS Config to track configuration 00:04:00.120 --> 00:04:02.539 changes that might introduce risk. And, of course, 00:04:02.659 --> 00:04:04.680 protecting the network edge with tools like AWS 00:04:04.680 --> 00:04:07.520 Weft, the web application Firewall, and AWS Shield 00:04:07.520 --> 00:04:11.139 for D2S protection. So the security pillar asks 00:04:11.139 --> 00:04:13.659 a very direct question. How do we protect our 00:04:13.659 --> 00:04:16.000 data, accounts, and systems? Simple question, 00:04:16.199 --> 00:04:18.689 complex answer. All right, pillar three, reliability. 00:04:19.670 --> 00:04:21.790 We've automated operations with OpEx, locked 00:04:21.790 --> 00:04:24.250 things down with security. But none of that helps 00:04:24.250 --> 00:04:27.649 if the app keeps falling over. Exactly. Reliability 00:04:27.649 --> 00:04:30.050 is all about resilience. It's ensuring your workload 00:04:30.050 --> 00:04:32.649 functions consistently and crucially can recover 00:04:32.649 --> 00:04:35.209 quickly from any failure. And the big mental 00:04:35.209 --> 00:04:36.990 shift here is that you have to explain that lead 00:04:36.990 --> 00:04:39.389 design for failure. Don't pretend it won't happen. 00:04:39.740 --> 00:04:43.199 Assume hardware fails, networks get flaky, dependencies 00:04:43.199 --> 00:04:45.699 hiccup. OK, but how do we actually do that in 00:04:45.699 --> 00:04:47.879 the cloud without breaking the bank? Designing 00:04:47.879 --> 00:04:50.189 for failure sounds expensive. It doesn't have 00:04:50.189 --> 00:04:51.730 to be. That's the beauty of the cloud model. 00:04:51.850 --> 00:04:53.689 It starts with designing for high availability, 00:04:53.829 --> 00:04:56.610 having robust disaster recovery plans, or DR. 00:04:56.930 --> 00:04:59.829 We aim for auto recovery from failures. Systems 00:04:59.829 --> 00:05:01.930 should ideally fix themselves without needing 00:05:01.930 --> 00:05:04.810 a human to intervene, which ties right back to 00:05:04.810 --> 00:05:07.649 that automation and OPEX. The core mechanism 00:05:07.649 --> 00:05:10.709 is usually scaling horizontally, adding more 00:05:10.709 --> 00:05:13.149 small instances rather than one giant one, and 00:05:13.149 --> 00:05:15.389 distributing everything across multiple availability 00:05:15.389 --> 00:05:18.189 zones, or AZEs. For maximum resilience, you might 00:05:18.189 --> 00:05:21.569 even go across multiple AWS regions. Ah, so if 00:05:21.569 --> 00:05:23.949 one data center or even a whole geographic area 00:05:23.949 --> 00:05:26.730 has issues, your application keeps running. Business 00:05:26.730 --> 00:05:29.870 continuity. Precisely. So the reliability question 00:05:29.870 --> 00:05:32.529 is, how do we make sure our application stays 00:05:32.529 --> 00:05:35.589 up, meets its recovery goals, and can heal itself 00:05:35.589 --> 00:05:38.069 when things inevitably go wrong? Okay, this is 00:05:38.069 --> 00:05:39.689 where, as you said, things start getting really 00:05:39.689 --> 00:05:42.670 intertwined. Yeah. The next three pillars, performance 00:05:42.670 --> 00:05:45.790 efficiency, cost optimization, sustainability, 00:05:46.430 --> 00:05:49.529 They seem to overlap a lot. This requires some 00:05:49.529 --> 00:05:51.790 careful balancing acts, I imagine. Let's tackle 00:05:51.790 --> 00:05:53.850 performance efficiency first. Yeah, performance 00:05:53.850 --> 00:05:56.410 efficiency. This one's about using IT and computing 00:05:56.410 --> 00:05:58.889 resources efficiently. It's about precision. 00:05:59.410 --> 00:06:01.189 You want to make sure you have the right resources 00:06:01.189 --> 00:06:03.350 allocated to meet performance needs, but without 00:06:03.350 --> 00:06:06.399 being wasteful. or constrained. And what are 00:06:06.399 --> 00:06:08.339 the modern ways to get that efficiency? Is it 00:06:08.339 --> 00:06:11.100 just about picking a bigger EC2 instance? No, 00:06:11.139 --> 00:06:13.079 not at all, actually. Often it's the opposite. 00:06:13.300 --> 00:06:16.180 We talk a lot about using advanced tech. Serverless, 00:06:16.360 --> 00:06:18.800 like AWS Lambda, is often great for performance 00:06:18.800 --> 00:06:21.639 efficiency. It scales instantly, handles infrastructure 00:06:21.639 --> 00:06:24.180 for you. We also focus on efficient scaling using 00:06:24.180 --> 00:06:26.660 things like auto -scaling groups. And the really 00:06:26.660 --> 00:06:29.259 critical practice of right -sizing. Right -sizing. 00:06:29.279 --> 00:06:31.480 Yeah. Matching the resource type and size to 00:06:31.480 --> 00:06:34.399 the actual need. Exactly. Don't use an extra 00:06:34.399 --> 00:06:36.519 large instance if a medium would do the job perfectly 00:06:36.519 --> 00:06:40.000 well. Also, using global services like Amazon 00:06:40.000 --> 00:06:42.759 CloudFront to cache content closer to users improves 00:06:42.759 --> 00:06:46.439 performance dramatically, reduces latency. So 00:06:46.439 --> 00:06:49.120 the performance question boils down to, are we 00:06:49.120 --> 00:06:51.100 using the right amount and type of resources 00:06:51.100 --> 00:06:53.699 to meet our performance needs efficiently? Now 00:06:53.699 --> 00:06:55.860 let's shift to the bottom line, cost optimization. 00:06:56.540 --> 00:06:58.660 You hinted that performance and cost are like 00:06:58.660 --> 00:07:01.420 two sides of the same coin. This pillar is all 00:07:01.420 --> 00:07:03.879 about avoiding unnecessary spend and getting 00:07:03.879 --> 00:07:05.879 the real financial benefits the cloud promises, 00:07:06.079 --> 00:07:08.439 right? Absolutely. Cost optimization is critical 00:07:08.439 --> 00:07:10.939 because, let's face it, wasted cloud spend can 00:07:10.939 --> 00:07:13.759 kill any project or migration benefit. It hinges 00:07:13.759 --> 00:07:16.019 on understanding that pay -as -you -go consumption 00:07:16.019 --> 00:07:19.759 model. But also, for predictable workloads, leveraging 00:07:19.759 --> 00:07:22.279 different pricing models. Reserved instances, 00:07:22.519 --> 00:07:25.160 or RIs, and savings plans can dramatically cut 00:07:25.160 --> 00:07:27.180 costs compared to on -demand pricing. And this 00:07:27.180 --> 00:07:29.180 must be where having good visibility becomes 00:07:29.180 --> 00:07:32.579 crucial, using the tools AWS provides. Oh, definitely. 00:07:33.019 --> 00:07:35.730 You can't optimize what you can't see. Tools 00:07:35.730 --> 00:07:39.170 like AWS Cost Explorer and setting up AWS budgets 00:07:39.170 --> 00:07:41.930 are absolutely central. It requires constant 00:07:41.930 --> 00:07:45.050 monitoring and, frankly, a mindset shift. Every 00:07:45.050 --> 00:07:47.509 resource deployed has a direct dollar cost. The 00:07:47.509 --> 00:07:49.829 goal is maximizing value for the lowest possible 00:07:49.829 --> 00:07:53.529 spend. So cost optimization asks, are we spending 00:07:53.529 --> 00:07:56.430 money efficiently, maximizing our ROI, and using 00:07:56.430 --> 00:07:58.569 the most cost -effective resources for the job? 00:07:58.769 --> 00:08:01.850 And finally, the newest pillar added more recently, 00:08:02.529 --> 00:08:05.399 sustainability. This focuses specifically on 00:08:05.399 --> 00:08:07.420 minimizing the environmental impact of our cloud 00:08:07.420 --> 00:08:09.660 workloads. Yes. And this one requires a very 00:08:09.660 --> 00:08:11.399 clear understanding of responsibility, similar 00:08:11.399 --> 00:08:14.279 to security. AWS is responsible for sustainability 00:08:14.279 --> 00:08:16.480 of the cloud. That means the efficiency of their 00:08:16.480 --> 00:08:18.480 data centers, renewable energy usage, efficient 00:08:18.480 --> 00:08:20.459 hardware design, water usage, all that physical 00:08:20.459 --> 00:08:22.879 infrastructure stuff. But the customer, you are 00:08:22.879 --> 00:08:24.540 responsible for sustainability in the cloud. 00:08:24.839 --> 00:08:26.920 Okay. What does sustainability in the cloud mean 00:08:26.920 --> 00:08:29.620 practically for, say, an architect or developer? 00:08:29.720 --> 00:08:33.120 What do we do? It means maximizing resource utilization. 00:08:33.779 --> 00:08:35.779 Making sure the servers you are using are working 00:08:35.779 --> 00:08:39.039 hard, not sitting idle. This means less overall 00:08:39.039 --> 00:08:41.259 hardware is needed, reducing energy consumption 00:08:41.259 --> 00:08:44.679 per task. It means thinking about data, reducing 00:08:44.679 --> 00:08:47.210 the amount you store unnecessarily. Do you really 00:08:47.210 --> 00:08:49.389 need seven years of backups for that test environment? 00:08:49.669 --> 00:08:52.669 Probably not. It also means adopting newer, more 00:08:52.669 --> 00:08:55.789 efficient hardware when appropriate, like AWS's 00:08:55.789 --> 00:08:58.190 Graviton processors, which offer better performance 00:08:58.190 --> 00:09:01.289 per watt. And leveraging managed services often 00:09:01.289 --> 00:09:04.149 helps because AWS can achieve economies of scale 00:09:04.149 --> 00:09:06.269 and utilization that are hard for individual 00:09:06.269 --> 00:09:08.850 customers to match. So the architect needs to 00:09:08.850 --> 00:09:11.610 ask, how can we minimize our environmental footprint 00:09:11.610 --> 00:09:14.230 by maximizing utilization and choosing efficient 00:09:14.230 --> 00:09:16.870 options? Okay, connecting all this, it feels 00:09:16.870 --> 00:09:18.870 like the real skill isn't just memorizing the 00:09:18.870 --> 00:09:21.029 definitions of the six pillars. It's understanding 00:09:21.029 --> 00:09:23.250 the why behind an action, especially where they 00:09:23.250 --> 00:09:25.929 blur. That's exactly it. The intention test is 00:09:25.929 --> 00:09:29.090 key. So, for example, if you implement strict 00:09:29.090 --> 00:09:31.690 IAM policies, your primary intention is protecting 00:09:31.690 --> 00:09:34.629 resources. That's clearly security. If you buy 00:09:34.629 --> 00:09:36.809 a three -year reserved instance for a database, 00:09:37.330 --> 00:09:40.070 your intention is purely financial saving. That's 00:09:40.070 --> 00:09:42.889 cost optimization. But let's hit that big overlap 00:09:42.889 --> 00:09:45.169 you mentioned. Performance efficiency and cost 00:09:45.169 --> 00:09:48.070 optimization. What if I right size an instance? 00:09:48.429 --> 00:09:50.769 Say I downgrade it because it was way too big. 00:09:51.049 --> 00:09:53.629 Which pillar is that? Ah, see, that's a perfect 00:09:53.629 --> 00:09:56.669 example of synergy. Right sizing by reducing 00:09:56.669 --> 00:09:59.049 an oversize instance is probably the number one 00:09:59.049 --> 00:10:01.610 way people save money. So it's absolutely crucial 00:10:01.610 --> 00:10:04.529 for cost optimization. Huge impact there. But 00:10:04.529 --> 00:10:06.669 let's say you had a database bottlenecked by 00:10:06.669 --> 00:10:09.450 slow disk IO. Upgrading the storage volume to 00:10:09.450 --> 00:10:11.710 a faster type is also a form of right sizing. 00:10:11.809 --> 00:10:13.919 And that action directs improves application 00:10:13.919 --> 00:10:15.740 speed, fulfilling the performance efficiency 00:10:15.740 --> 00:10:18.159 pillar. So the same action -changing resource 00:10:18.159 --> 00:10:20.759 size type can serve both pillars, depending on 00:10:20.759 --> 00:10:22.980 the specific problem you're solving. The intent 00:10:22.980 --> 00:10:25.789 matters. Precisely. The action might be identical, 00:10:26.009 --> 00:10:27.669 but the reason you're doing it often targets 00:10:27.669 --> 00:10:29.950 one pillar more directly, even if it benefits 00:10:29.950 --> 00:10:31.970 others. And we see other tight connections too, 00:10:32.070 --> 00:10:34.769 right? Like OPEX and reliability. You mentioned 00:10:34.769 --> 00:10:37.629 automation is core to OPEX. But you can't achieve 00:10:37.629 --> 00:10:40.529 fast, reliable recovery, the heart of reliability, 00:10:40.710 --> 00:10:43.009 without that automation. They feed each other. 00:10:43.250 --> 00:10:45.690 And security underpins everything. You can't 00:10:45.690 --> 00:10:48.590 be reliable or efficient if you've been compromised. 00:10:48.889 --> 00:10:51.269 It's completely foundational. They all work together. 00:10:51.330 --> 00:10:54.190 It's a holistic view. Beyond the pillars themselves, 00:10:54.370 --> 00:10:56.730 the framework also talks about these high -level 00:10:56.730 --> 00:10:59.850 design principles, kind of the guiding philosophies 00:10:59.850 --> 00:11:02.570 that force us away from old -school data center 00:11:02.570 --> 00:11:05.230 thinking. They really do. Take the first one. 00:11:05.690 --> 00:11:08.750 Stop guessing your capacity needs. Remember how 00:11:08.750 --> 00:11:10.990 we used to buy servers for peak load three years 00:11:10.990 --> 00:11:14.090 out? Huge waste. In the cloud, this principle 00:11:14.090 --> 00:11:17.289 says use auto -scaling, use serverless, match 00:11:17.289 --> 00:11:20.470 capacity to demand dynamically. That hits cost 00:11:20.470 --> 00:11:22.950 optimization and performance efficiency immediately. 00:11:23.250 --> 00:11:25.409 And another big one, design for failure. You 00:11:25.409 --> 00:11:27.049 mentioned this with reliability. It's not about 00:11:27.049 --> 00:11:29.309 building stronger things. It's about building 00:11:29.309 --> 00:11:32.129 systems that expect failure and handle it gracefully. 00:11:32.690 --> 00:11:35.710 Multiple AZs, multiple regions, loose coupling, 00:11:36.429 --> 00:11:38.929 ensuring no single component failure takes down 00:11:38.929 --> 00:11:40.750 the whole show. Which sounds like it connects 00:11:40.750 --> 00:11:43.080 to another principle. decouple your components. 00:11:43.779 --> 00:11:47.039 Exactly. Use services like message queues, SQS, 00:11:47.179 --> 00:11:50.100 SNS to break monolithic applications into smaller 00:11:50.100 --> 00:11:52.620 independent services. If the order processing 00:11:52.620 --> 00:11:55.120 part fails, it shouldn't crash the user login 00:11:55.120 --> 00:11:58.200 part. That's classic reliability achieved through 00:11:58.200 --> 00:12:00.059 architectural decoupling. And there's one about 00:12:00.059 --> 00:12:02.860 automation making experimentation easier. Right. 00:12:03.049 --> 00:12:04.970 automate to make architectural experimentation 00:12:04.970 --> 00:12:07.929 easier. We use infrastructure as code, not just 00:12:07.929 --> 00:12:11.009 for stable deployments, OpEx, but so we can spin 00:12:11.009 --> 00:12:13.429 up a whole new environment, test an idea, maybe 00:12:13.429 --> 00:12:16.470 a new database type, run some tests, and then 00:12:16.470 --> 00:12:18.690 tear it all down an hour later. Super cheap, 00:12:18.809 --> 00:12:21.389 super fast. That accelerates innovation safely. 00:12:21.789 --> 00:12:24.009 These principles really force a different mindset, 00:12:24.129 --> 00:12:26.490 don't they? Elasticity, distribution, automation. 00:12:27.269 --> 00:12:29.389 It's a world away from racking physical servers. 00:12:29.470 --> 00:12:32.539 It's a massive conceptual leap. Absolutely. So 00:12:32.539 --> 00:12:34.320 we have the pillars, we have the principles. 00:12:35.080 --> 00:12:36.980 How does this translate into practice? How do 00:12:36.980 --> 00:12:39.720 we actually, you know, use this framework to 00:12:39.720 --> 00:12:42.669 check our own work? Ah, that's where the AWS 00:12:42.669 --> 00:12:45.429 Well -Architected tool comes in, the WA tool. 00:12:46.210 --> 00:12:49.070 It's a free service right there in the AWS Management 00:12:49.070 --> 00:12:52.110 Console. Its whole purpose is to give you a consistent, 00:12:52.370 --> 00:12:55.009 structured way to review a specific workload, 00:12:55.470 --> 00:12:58.009 which is basically the set of components delivering 00:12:58.009 --> 00:13:00.809 some business value against all these best practices 00:13:00.809 --> 00:13:02.950 we've been talking about. OK, so it's not just 00:13:02.950 --> 00:13:05.309 reading the white paper. It's an interactive 00:13:05.309 --> 00:13:08.200 tool, less like an audit. Maybe more like a guided 00:13:08.200 --> 00:13:09.879 self -assessment. That's a good way to put it. 00:13:09.879 --> 00:13:11.940 It guides you, the customer, through a series 00:13:11.940 --> 00:13:14.379 of questions for each of the six pillars. It 00:13:14.379 --> 00:13:16.840 forces you to think critically about your specific 00:13:16.840 --> 00:13:19.279 configurations, your scaling strategies, your 00:13:19.279 --> 00:13:22.279 cost controls, your security postures. And the 00:13:22.279 --> 00:13:24.480 output is really actionable. You get a report 00:13:24.480 --> 00:13:26.980 highlighting potential risks, high risk issues, 00:13:27.120 --> 00:13:30.620 HRIs, and medium risk issues, MRIs. These are 00:13:30.620 --> 00:13:33.080 specific areas where your workload deviates from 00:13:33.080 --> 00:13:35.740 best practices. And crucially, it provides recommended 00:13:35.740 --> 00:13:39.039 improvement plans. So if I, say, have an S3 bucket 00:13:39.039 --> 00:13:41.580 that's accidentally public, the tool would flag 00:13:41.580 --> 00:13:43.480 that as a high -risk security issue. Exactly. 00:13:43.559 --> 00:13:46.320 And it would point you towards the steps to remediate 00:13:46.320 --> 00:13:48.139 it, like changing the bucket policy or using 00:13:48.139 --> 00:13:50.860 blocked public access settings. Got it. So the 00:13:50.860 --> 00:13:53.639 goal isn't just the report itself, but actually 00:13:53.639 --> 00:13:56.879 doing something about it, encouraging that ongoing 00:13:56.879 --> 00:14:00.080 review and improvement cycle. the Well -Architected 00:14:00.080 --> 00:14:02.159 Framework Review, or WAREFOR. That's precisely 00:14:02.159 --> 00:14:04.879 the goal. It turns the framework from abstract 00:14:04.879 --> 00:14:07.840 concepts into a tangible, measurable, and iterative 00:14:07.840 --> 00:14:10.960 process for improvement. It makes good architecture 00:14:10.960 --> 00:14:13.259 something you can actively work on. Fantastic. 00:14:13.379 --> 00:14:15.039 That really clarifies how it all fits together. 00:14:15.659 --> 00:14:18.340 OK. That was a really thorough deep dive. Let's 00:14:18.340 --> 00:14:19.899 quickly recap the key takeaways for everyone 00:14:19.899 --> 00:14:22.419 listening, just to lock in the core idea of each 00:14:22.419 --> 00:14:25.840 pillar. So operational excellence. Think automation, 00:14:26.259 --> 00:14:28.100 monitoring, managing change effectively, keeping 00:14:28.100 --> 00:14:32.480 things consistent. Security. All about IAM, encryption 00:14:32.480 --> 00:14:34.820 everywhere, detective controls, and really understanding 00:14:34.820 --> 00:14:37.539 that shared responsibility model. Reliability. 00:14:37.929 --> 00:14:40.250 Focus on recovery, fault tolerance. Designed 00:14:40.250 --> 00:14:42.870 for failure using multiple AZs, maybe even regions. 00:14:43.529 --> 00:14:45.429 Performance efficiency. Right sizing is key. 00:14:45.529 --> 00:14:47.769 Using smart tech like serverless, selecting the 00:14:47.769 --> 00:14:50.129 best resource for the job. Cost optimization. 00:14:50.570 --> 00:14:52.750 Control your spending. Keep right sizing. Use 00:14:52.750 --> 00:14:55.629 RIs or savings plans where sensible. Visibility 00:14:55.629 --> 00:14:58.620 is crucial. And sustainability. Maximize utilization 00:14:58.620 --> 00:15:01.179 of the resources you do use, reduce waste, choose 00:15:01.179 --> 00:15:03.059 efficient options to minimize that environmental 00:15:03.059 --> 00:15:05.759 footprint in the cloud. Nicely summarized. And 00:15:05.759 --> 00:15:08.480 maybe one final thought to leave you with. Well, 00:15:08.539 --> 00:15:10.299 we talk about the framework in terms of building 00:15:10.299 --> 00:15:13.279 better technical architectures. Think about how 00:15:13.279 --> 00:15:16.039 its principles designing for failure, decoupling, 00:15:16.179 --> 00:15:18.980 constant improvement through OPEX are fundamentally 00:15:18.980 --> 00:15:21.860 about reducing business risk. Consider how these 00:15:21.860 --> 00:15:24.179 areas, especially that tight link between performance 00:15:24.179 --> 00:15:26.919 efficiency and cost optimization, kind of force 00:15:26.919 --> 00:15:29.340 engineers and architects to look at technology 00:15:29.340 --> 00:15:31.759 choices through a financial lens too. How does 00:15:31.759 --> 00:15:34.600 that constant pressure to optimize, to be efficient, 00:15:34.720 --> 00:15:37.419 to justify cost, how does that ultimately change 00:15:37.419 --> 00:15:39.480 the way a large organization approaches innovation 00:15:39.480 --> 00:15:42.539 and investment? It really ties in decisions directly 00:15:42.539 --> 00:15:44.539 back to business outcomes, doesn't it? Something 00:15:44.539 --> 00:15:45.200 to think about.