WEBVTT 1 00:00:00.360 --> 00:00:03.359 Welcome back to the deep dive. We are we're doing 2 00:00:03.399 --> 00:00:04.599 something a little bit different today. 3 00:00:04.639 --> 00:00:06.639 Yeah, definitely a pivot from the usual stuff. 4 00:00:06.719 --> 00:00:09.199 Right, Usually we grab a business book or you know, 5 00:00:09.279 --> 00:00:11.519 a piece of long form journalism and just pull it apart. 6 00:00:11.880 --> 00:00:14.919 But today we are staring straight into the abyss of 7 00:00:15.000 --> 00:00:15.519 the cloud. 8 00:00:15.839 --> 00:00:18.199 The abyss. I like that, it really is. 9 00:00:18.280 --> 00:00:23.839 Right. Specifically, we are unpacking the AWS Certified Cloud Practitioner 10 00:00:24.000 --> 00:00:28.280 CLF COO two cert dyed by Anthony Sakira. 11 00:00:28.120 --> 00:00:31.320 Which I'll be honest, that title sounds a bit dry. 12 00:00:31.519 --> 00:00:32.799 Sounds exactly like homework. 13 00:00:32.840 --> 00:00:35.039 It totally sounds like homework. But here is the hook 14 00:00:35.280 --> 00:00:37.880 and why I wanted to do this today. The cloud 15 00:00:38.320 --> 00:00:41.520 is this term you hear every single day, oh constantly. Right, 16 00:00:41.600 --> 00:00:44.159 It's in the cloud, upload it to the cloud. 17 00:00:44.200 --> 00:00:44.759 It's on our. 18 00:00:44.679 --> 00:00:48.399 Phones, our TVs probably are refrigerators by. 19 00:00:48.399 --> 00:00:49.840 Now, almost certainly your refrigerator. 20 00:00:49.880 --> 00:00:51.119 And if I stop you on the street and ask 21 00:00:51.280 --> 00:00:55.119 what is it physically and how does it actually work? 22 00:00:55.159 --> 00:00:58.439 I mean most people, even really smart people, can't answer that. 23 00:00:58.439 --> 00:01:02.719 That's entirely fair. It's it's become a black box. We 24 00:01:02.799 --> 00:01:05.760 trust it, but we don't understand the mechanics at all, 25 00:01:06.200 --> 00:01:08.640 and frankly, a lot of businesses are writing massive checks 26 00:01:08.640 --> 00:01:11.239 for it without really understanding what they're buying exactly. 27 00:01:11.640 --> 00:01:14.359 So our mission today isn't just to help someone pass 28 00:01:14.400 --> 00:01:16.680 a multiple choice test, though, hey, if you are taking 29 00:01:16.719 --> 00:01:19.920 the CLFCO two, this is going to be gold for you, absolutely, 30 00:01:20.319 --> 00:01:22.799 But the real goal is to look at the blueprints 31 00:01:22.840 --> 00:01:25.280 of the modern Internet. We're going to look at the 32 00:01:25.319 --> 00:01:30.959 actual definitions from NIST, the National Institute of Standards and Technology. 33 00:01:30.400 --> 00:01:32.200 The official rules basically right. 34 00:01:32.239 --> 00:01:34.319 And we're going to break down the economics of why 35 00:01:34.439 --> 00:01:38.159 companies are actively shutting down their own data centers. Plus, 36 00:01:38.239 --> 00:01:39.959 we're going to spend a good chunk of time on 37 00:01:40.000 --> 00:01:41.879 the well architected framework. 38 00:01:41.760 --> 00:01:46.439 Which is essentially Amazon's secret sauce, their philosophy for how 39 00:01:46.439 --> 00:01:50.680 to build systems that don't just instantly crash exactly. And honestly, 40 00:01:51.159 --> 00:01:54.799 that framework is arguably more important than the tech itself. 41 00:01:55.400 --> 00:01:56.959 You know, you can have the best power tools in 42 00:01:57.000 --> 00:01:58.480 the world, but if you don't know how to frame 43 00:01:58.480 --> 00:02:00.519 a house, it's just going to collapse. 44 00:02:00.760 --> 00:02:03.040 That is a great way to put it. So let's 45 00:02:03.040 --> 00:02:07.120 start with the definition. Because the cloud feels, I don't. 46 00:02:06.959 --> 00:02:08.639 Know, fluffy, very fluffy. 47 00:02:08.759 --> 00:02:12.680 It implies it's up in the sky, completely ephemeral. But NIST, 48 00:02:13.039 --> 00:02:16.400 which is the government body that defines standards for measurements 49 00:02:16.400 --> 00:02:20.919 in time, they have a very concrete, very unfluffy definition 50 00:02:21.080 --> 00:02:21.360 they do. 51 00:02:21.439 --> 00:02:24.840 They totally strip away the marketing speak. They define cloud 52 00:02:24.879 --> 00:02:31.319 computing as ubiquitous, convenient, on demand network access to a 53 00:02:31.400 --> 00:02:34.240 shared pool of configurable computing resources. 54 00:02:34.319 --> 00:02:36.719 Okay, shared pool is the phrase that really jumps out 55 00:02:36.719 --> 00:02:36.879 of me. 56 00:02:36.919 --> 00:02:39.159 There it should, it's the core of it. And NIST 57 00:02:39.240 --> 00:02:43.000 actually breaks this down into five essential characteristics. If you 58 00:02:43.039 --> 00:02:45.520 don't have these five, you aren't really doing cloud computing. 59 00:02:45.520 --> 00:02:47.919 You're just doing remote computing. Right. So the first one 60 00:02:47.960 --> 00:02:49.879 is on demand self service. 61 00:02:49.560 --> 00:02:51.919 Which is basically the vending machine model. 62 00:02:52.000 --> 00:02:53.680 Right, that's the best way to think about it. In 63 00:02:53.719 --> 00:02:56.479 the pre cloud era, let's just call it the legacy era, 64 00:02:56.639 --> 00:02:58.879 if you were a developer and you needed a server 65 00:02:59.120 --> 00:03:00.759 to test a new app, what did you do? 66 00:03:01.039 --> 00:03:04.479 You filled out a ticket, you begged the it manager, 67 00:03:04.520 --> 00:03:06.000 you waited what three weeks. 68 00:03:05.719 --> 00:03:08.680 For shipping exactly, and then someone had to physically rack 69 00:03:08.719 --> 00:03:10.919 it and cable it up. It was a completely friction 70 00:03:11.039 --> 00:03:14.680 heavy process. Yeah, but on demand cell service means you 71 00:03:14.719 --> 00:03:18.080 remove that human gatekeeper entirely. You click a button or 72 00:03:18.120 --> 00:03:21.000 run a script, and the server just appears. You don't 73 00:03:21.039 --> 00:03:23.719 need permission to innovate anymore. It changes the speed of 74 00:03:23.759 --> 00:03:26.439 business from weeks to literally minutes. 75 00:03:26.319 --> 00:03:29.800 Which pairs perfectly with the second characteristic broad network access. 76 00:03:29.879 --> 00:03:31.759 I mean I can get to it from my laptop, 77 00:03:31.840 --> 00:03:35.000 my phone, a tablet, it's all standard web product. 78 00:03:35.000 --> 00:03:36.400 Well, it's accessible anywhere. 79 00:03:36.520 --> 00:03:39.719 But the third one is where the engineering gets interesting 80 00:03:39.960 --> 00:03:43.280 and maybe a little scary for some people. Resource pooling. 81 00:03:43.439 --> 00:03:45.199 This is that multi tenant model. 82 00:03:45.319 --> 00:03:48.360 This is probably the most misunderstood part of the cloud. 83 00:03:49.080 --> 00:03:52.000 Think of a massive apartment complex. Everyone has their own key, 84 00:03:52.319 --> 00:03:56.159 their own private space, but behind the walls, you are 85 00:03:56.240 --> 00:03:59.560 all sharing the same plumbing, the same electrical grid, the 86 00:03:59.639 --> 00:04:00.840 exact same foundation. 87 00:04:01.439 --> 00:04:04.400 So just to be completely clear here, my company's data 88 00:04:04.479 --> 00:04:06.960 might be sitting on the exact same physical hard drive 89 00:04:07.000 --> 00:04:08.360 as my competitor's data. 90 00:04:08.439 --> 00:04:13.599 It is very likely through virtualization, AWS basically slices up 91 00:04:13.599 --> 00:04:18.600 that physical hardware into secure, isolated chunks. You are tenants 92 00:04:18.600 --> 00:04:20.279 in the same building. You can't see each other, you 93 00:04:20.319 --> 00:04:23.079 can't hear each other, but you are leveraging the massive 94 00:04:23.079 --> 00:04:25.560 efficiency of sharing that core infrastructure. 95 00:04:25.920 --> 00:04:28.079 I can totally see why banks used to be terrified 96 00:04:28.079 --> 00:04:28.279 of that. 97 00:04:28.399 --> 00:04:31.519 Oh they were, But the security of that isolation layer 98 00:04:31.560 --> 00:04:35.600 the hypervisor is now generally considered way stronger than what 99 00:04:35.639 --> 00:04:38.160 most companies can build in their own private basements. Anyway, 100 00:04:38.319 --> 00:04:43.439 makes sense, and that sharing drives the fourth characteristic rapid elasticity. 101 00:04:43.639 --> 00:04:46.040 This is the one that feels like absolute magic. 102 00:04:46.199 --> 00:04:48.759 It's the rubber band effect. In a traditional data center, 103 00:04:48.839 --> 00:04:51.360 if you buy ten servers, you have ten servers period. 104 00:04:51.639 --> 00:04:53.759 If you have a traffic spike and you suddenly need eleven, 105 00:04:54.079 --> 00:04:55.839 your website crashes. 106 00:04:55.480 --> 00:04:57.519 And if you only need two, you're just burning money 107 00:04:57.519 --> 00:04:59.040 on the other eight exactly. 108 00:04:59.439 --> 00:05:02.759 But with a plasticity, the system breaths, It scales out 109 00:05:02.800 --> 00:05:05.560 when demand creates the need, and this is crucial, it 110 00:05:05.600 --> 00:05:08.639 scales back in when the demand drops to the user, 111 00:05:09.160 --> 00:05:12.720 the resources appear completely unlimited. You never hit a sold outsign. 112 00:05:13.120 --> 00:05:15.120 And that leads right into the fifth one, which is 113 00:05:15.160 --> 00:05:17.879 what makes the CFO happy. Measured service. 114 00:05:17.959 --> 00:05:20.800 The utility bill, you pay for electricity by the kilabot hour. 115 00:05:20.920 --> 00:05:23.879 Right in the cloud, you pay for compute by the 116 00:05:23.920 --> 00:05:25.680 second and storage by the gigabyte. 117 00:05:25.759 --> 00:05:28.160 So it changes it from a fixed cost to a 118 00:05:28.240 --> 00:05:28.959 variable cost. 119 00:05:29.040 --> 00:05:32.160 Precisely, you stop paying for just in case capacity. 120 00:05:32.240 --> 00:05:34.439 Okay, so we know what it is, but we also 121 00:05:34.480 --> 00:05:37.279 need to talk about how it's actually delivered. The guide 122 00:05:37.279 --> 00:05:40.680 breaks this down into those famous as the service acronyms 123 00:05:41.120 --> 00:05:46.120 SaaS pass iss. I feel like these get thrown around 124 00:05:46.120 --> 00:05:48.279 in corporate meetings just to sound smart, But there is 125 00:05:48.319 --> 00:05:49.720 a distinct hierarchy here. 126 00:05:49.839 --> 00:05:52.839 There really is. It's all about control versus convenience. The 127 00:05:52.879 --> 00:05:56.600 shared responsibility model dictates this. As you move down the stack, 128 00:05:56.839 --> 00:05:59.360 you get more control, but you also inherit a lot 129 00:05:59.399 --> 00:05:59.920 more work. 130 00:06:00.240 --> 00:06:03.120 Let's start at the top, the one everyone uses SaaS 131 00:06:03.160 --> 00:06:04.199 software as a service. 132 00:06:04.399 --> 00:06:08.319 This is Gmail, it's Salesforce Zoom. As a user, you 133 00:06:08.360 --> 00:06:11.560 have zero control over the infrastructure. You don't patch the servers, 134 00:06:11.759 --> 00:06:13.920 you don't worry about the code updates. You just log 135 00:06:13.959 --> 00:06:14.680 in and use the tool. 136 00:06:14.839 --> 00:06:16.560 The convenience is high, control is low. 137 00:06:16.800 --> 00:06:21.319 Exactly. Then we step down to pays Platform as a service. 138 00:06:22.199 --> 00:06:25.000 The source guy actually mentions this is the sweet spot 139 00:06:25.040 --> 00:06:25.720 for developers. 140 00:06:26.000 --> 00:06:26.480 Why is that? 141 00:06:27.120 --> 00:06:30.839 Think of PAS as a fully furnished workshop. You bring 142 00:06:30.879 --> 00:06:34.480 your own project, your code, but the workshop owner maintains 143 00:06:34.519 --> 00:06:38.680 all the tools, the operating system, and the runtime environment. 144 00:06:38.480 --> 00:06:40.800 Like Microsoft Azure in the early days. 145 00:06:40.639 --> 00:06:43.040 Right, Microsoft Azure actually started out here. You don't want 146 00:06:43.040 --> 00:06:45.199 to manage Windows updates. You just want your dot net 147 00:06:45.199 --> 00:06:46.160 application to run. 148 00:06:46.279 --> 00:06:49.199 And finally we hit the basement. I as infrastructure as 149 00:06:49.199 --> 00:06:49.720 a service. 150 00:06:49.879 --> 00:06:52.199 This is for the control freaks, and I say that 151 00:06:52.240 --> 00:06:54.319 with love, because sometimes you really need to be a 152 00:06:54.360 --> 00:06:58.600 control freak. This is aws EC two Elastic compute cloud. 153 00:06:58.720 --> 00:07:00.399 You get the virtual barre metal yep. 154 00:07:00.920 --> 00:07:03.800 You are responsible for the operating system, the security patches, 155 00:07:03.839 --> 00:07:06.720 configuring the firewalls. It's the most work, but it gives 156 00:07:06.720 --> 00:07:10.000 you the granular control to configure the system exactly how 157 00:07:10.040 --> 00:07:11.279 your application needs it. 158 00:07:11.600 --> 00:07:14.279 The guide uses the analogy of housing for this, which 159 00:07:14.279 --> 00:07:16.879 I loved. Sauce is like staying in a hotel. Room 160 00:07:16.879 --> 00:07:20.240 made services included paths is renting a house. You mow 161 00:07:20.279 --> 00:07:24.079 the lawn, but the landlord fixes the roof. And is 162 00:07:24.160 --> 00:07:26.759 is buying an empty lot and building the house yourself. 163 00:07:27.000 --> 00:07:29.720 It holds up perfectly, and knowing which one to pick 164 00:07:29.800 --> 00:07:32.920 is really half the battle. In architecture. Don't build a 165 00:07:32.959 --> 00:07:34.920 house from scratch if you just need a place to 166 00:07:34.920 --> 00:07:35.639 sleep for the night. 167 00:07:35.800 --> 00:07:38.959 Good point Now, before we get into the money, because 168 00:07:38.959 --> 00:07:41.319 the economics here are fascinating, we have to touch on 169 00:07:41.360 --> 00:07:46.560 where this stuff lives. The guide discusses deployment models public, private, 170 00:07:46.800 --> 00:07:47.319 and hybrid. 171 00:07:47.560 --> 00:07:51.279 So public is AWS or Azure or Google. Anyone with 172 00:07:51.319 --> 00:07:53.800 a credit card can join. Private is your own data 173 00:07:53.800 --> 00:07:57.240 center or a dedicated cloud just for you. This is 174 00:07:57.240 --> 00:07:59.879 often used by governments or agencies who are paranoid about 175 00:07:59.879 --> 00:08:03.439 that multi tenant thing we discussed earlier, and hybrid is 176 00:08:03.480 --> 00:08:06.519 the messy reality For most big companies, they have legacy 177 00:08:06.560 --> 00:08:09.000 mainframes they just can't get rid of. Maybe they're running 178 00:08:09.040 --> 00:08:12.000 some core banking software from nineteen eighty, which happens a 179 00:08:12.040 --> 00:08:15.560 lot all the time. So they connect that old mainframe 180 00:08:15.839 --> 00:08:19.040 to the modern public cloud. It's binding the old world 181 00:08:19.040 --> 00:08:20.079 and the new world together. 182 00:08:20.240 --> 00:08:23.800 Okay, let's talk cash. The source text really emphasizes this 183 00:08:23.959 --> 00:08:29.279 shift from CAPEX to op X capitaled expenditures versus operating expenditures. 184 00:08:29.920 --> 00:08:31.720 Why is this such a game changer? It sounds like 185 00:08:31.800 --> 00:08:33.120 total accounting boredom. 186 00:08:33.360 --> 00:08:36.279 It does sound boring until you realize it changes entire 187 00:08:36.320 --> 00:08:39.320 business strategies. CAPEX is buying a house. You need a 188 00:08:39.399 --> 00:08:42.840 massive down payment. You are locked in if the market crashes, 189 00:08:43.279 --> 00:08:46.480 you lose big time. Op X is renting. 190 00:08:46.679 --> 00:08:48.759 There is a story in the sorce material that perfectly 191 00:08:48.799 --> 00:08:50.519 illustrates this, and I have to share it. It's about 192 00:08:50.559 --> 00:08:54.279 a university that needed to do some massive AI testing. 193 00:08:54.399 --> 00:08:57.759 Oh yes, the university AI story. This is a classic example. 194 00:08:57.919 --> 00:09:00.360 So they needed this massive compute power. In the old 195 00:09:00.440 --> 00:09:02.840 capex world, they would have had to apply for a grant, 196 00:09:03.480 --> 00:09:06.320 buy millions of dollars of hardware, wait for it to arrive, 197 00:09:06.480 --> 00:09:09.120 install it. I mean the project would take years. 198 00:09:09.320 --> 00:09:11.480 So once the project was finally done, they just have 199 00:09:11.519 --> 00:09:15.320 a basement full of depreciating servers doing absolutely nothing right. 200 00:09:15.639 --> 00:09:18.639 But instead they went to aws. They spun up millions 201 00:09:18.639 --> 00:09:23.200 of CPUs on EC two instances. They basically rented a supercomputer. 202 00:09:23.399 --> 00:09:26.919 They ran their calculation for about forty eight hours and then, 203 00:09:26.960 --> 00:09:28.720 and this is the absolute key, they turn it off. 204 00:09:28.759 --> 00:09:31.080 They deleted the super exactly. 205 00:09:30.720 --> 00:09:34.879 They paid for two days of usage. That is opex. 206 00:09:35.279 --> 00:09:38.879 It completely democratizes power. A college student with a credit 207 00:09:38.879 --> 00:09:41.600 card can access the exact same computing power as a 208 00:09:41.639 --> 00:09:44.080 Fortune five hundred company as long as they can pay 209 00:09:44.080 --> 00:09:44.799 the hourly rate. 210 00:09:45.000 --> 00:09:48.039 That is agility right there, That is the ability to 211 00:09:48.120 --> 00:09:50.639 fail fast because if the experiment didn't work, they were 212 00:09:50.679 --> 00:09:52.879 out a few hundred bucks, not a few million. 213 00:09:53.039 --> 00:09:55.879 And because Amazon is buying these servers by the shipping 214 00:09:55.879 --> 00:09:59.960 container load, they achieve incredible economies of scale. A single 215 00:10:00.120 --> 00:10:02.960 company can never negotiate the hardware prices that Amazon can, 216 00:10:03.279 --> 00:10:05.840 and theoretically those savings get passed down to you in 217 00:10:05.919 --> 00:10:07.039 lower rates over time. 218 00:10:07.200 --> 00:10:10.279 Theoretically, yes, But let's ground this in physical reality for 219 00:10:10.320 --> 00:10:13.399 a second, because despite the name cloud, this data has 220 00:10:13.440 --> 00:10:15.519 to live somewhere. It's not actually floating in the ether. 221 00:10:15.639 --> 00:10:16.879 It's in a building somewhere. 222 00:10:16.960 --> 00:10:21.279 It is very terrestrial. It's dirt, concrete, copper, and fiber optics. 223 00:10:21.720 --> 00:10:24.240 AWS divides the planet up into regions like. 224 00:10:24.360 --> 00:10:27.919 US East and Northern Virginia or the EU region in London. 225 00:10:27.720 --> 00:10:30.320 Right, And choosing a region isn't just about personal preference. 226 00:10:30.559 --> 00:10:33.799 It's about physics. If your customers are in London, you 227 00:10:33.799 --> 00:10:36.279 don't put your servers in Tokyo. The speed of light 228 00:10:36.399 --> 00:10:39.120 is fast, but it is not instant. You want to 229 00:10:39.120 --> 00:10:41.559 minimize latency, you want to reduce that delay. 230 00:10:41.840 --> 00:10:46.159 But inside a region there are availability zones or azs. 231 00:10:46.559 --> 00:10:48.559 The guide makes a really big deal out of the 232 00:10:48.600 --> 00:10:50.480 difference between a region and an AZ. 233 00:10:50.799 --> 00:10:53.120 This is a crucial concept both for the examine for 234 00:10:53.159 --> 00:10:56.360 real life and AZ is not necessarily one building, and 235 00:10:56.440 --> 00:10:59.360 AZ is a cluster of data centers. But and here's 236 00:10:59.360 --> 00:11:01.759 the kicker e Each AZY is physically separated from the 237 00:11:01.799 --> 00:11:03.840 others in that region by miles one miles. 238 00:11:03.840 --> 00:11:06.360 Why don't just put the next door to save on cabling. 239 00:11:06.120 --> 00:11:10.960 Floodplains, power grids, tectonic plates. If a massive hurricane hits AZA, 240 00:11:11.039 --> 00:11:13.320 you want AZB to be on a completely different power 241 00:11:13.360 --> 00:11:15.759 grid and maybe sitting on higher ground. They're connected by 242 00:11:15.840 --> 00:11:18.120 high speed fibers, so they act like one single unit, 243 00:11:18.440 --> 00:11:19.399 but they fail separately. 244 00:11:19.679 --> 00:11:21.000 So if I'm a bank, I don't just put my 245 00:11:21.080 --> 00:11:24.000 data in Virginia. I put it in Virginia AZY one 246 00:11:24.399 --> 00:11:26.480 and Virginia AZY two exactly. 247 00:11:26.879 --> 00:11:30.279 That is called high availability. If one building literally goes dark, 248 00:11:30.720 --> 00:11:33.120 the other takes over instantly. You don't put all your 249 00:11:33.120 --> 00:11:35.279 eggs in one basket, and you definitely don't put all 250 00:11:35.320 --> 00:11:36.919 your servers in one ASY. 251 00:11:37.279 --> 00:11:41.720 We also have edge locations. These are different from regions, right, Yes, there. 252 00:11:41.679 --> 00:11:45.039 Are way more edge locations all over the globe. These 253 00:11:45.080 --> 00:11:48.440 power Amazon cloud Front, which is a content delivery network. 254 00:11:48.679 --> 00:11:50.960 Just think of them as local caches. 255 00:11:50.759 --> 00:11:52.919 Like a seven to eleven versus a supermarket. 256 00:11:53.240 --> 00:11:55.919 That is a very good analogy. If the main Netflix 257 00:11:55.960 --> 00:11:59.399 server is the giant supermarket in California, the edge location 258 00:11:59.559 --> 00:12:02.200 is the seven eleven in your neighborhood. It stocks the 259 00:12:02.240 --> 00:12:04.879 most popular items like the latest hit movie, right down 260 00:12:04.919 --> 00:12:06.279 the street from your house, so you don't have to 261 00:12:06.360 --> 00:12:08.360 drive all the way to California to get it. It 262 00:12:08.440 --> 00:12:09.960 speeds up delivery massively. 263 00:12:10.080 --> 00:12:13.519 Okay, so we have the definition, the money, and the map. 264 00:12:13.759 --> 00:12:17.120 Now we get to the philosophy the well architected framework. 265 00:12:17.360 --> 00:12:19.720 This feels like the most deep dive part of the text. 266 00:12:19.720 --> 00:12:22.039 It's not just here as a tool, it's here is 267 00:12:22.080 --> 00:12:24.120 how you need to think it really is. 268 00:12:24.360 --> 00:12:27.080 AWS realized early on that people were moving to the 269 00:12:27.080 --> 00:12:30.799 cloud and building terrible systems. They were just copying their old, 270 00:12:30.919 --> 00:12:35.120 fragile data center practices and pasting them into AWS. So 271 00:12:35.240 --> 00:12:39.360 Amazon released this framework six pillars to basically say, here 272 00:12:39.480 --> 00:12:41.240 is what the highly successful people do. 273 00:12:41.480 --> 00:12:44.200 Let's run through these pillars because this is the real blueprint. 274 00:12:44.480 --> 00:12:47.840 Pillar one is operational excellence, which. 275 00:12:47.600 --> 00:12:50.960 Sounds like pure management speak, but the core technical concept 276 00:12:51.000 --> 00:12:55.279 here is infrastructure as code or IAC translate that for me. 277 00:12:55.399 --> 00:12:57.799 Don't let humans click buttons in the management console to 278 00:12:57.840 --> 00:13:01.840 build servers. Humans are terrible at competitive tasks. We get tired, 279 00:13:01.879 --> 00:13:06.480 we make typos, we forget crucial security steps. Instead, define 280 00:13:06.519 --> 00:13:09.440 your entire infrastructure in a script, a text file. You 281 00:13:09.519 --> 00:13:12.399 run the script, and AWS builds the environment perfectly. You 282 00:13:12.440 --> 00:13:14.679 want to update a server, you update the script. 283 00:13:14.759 --> 00:13:17.480 So your entire data center exists as code that can 284 00:13:17.480 --> 00:13:20.399 be version controlled, reviewed by peers, and rolled back if 285 00:13:20.440 --> 00:13:21.480 needed exactly. 286 00:13:22.200 --> 00:13:26.639 The framework also heavily preaches small reversible changes. Don't do 287 00:13:26.679 --> 00:13:29.480 the massive big bang release on a Friday night. Do 288 00:13:29.679 --> 00:13:32.879 tiny incremental updates that you can undo instantly if they 289 00:13:32.879 --> 00:13:34.080 happen to break something. 290 00:13:34.039 --> 00:13:39.000 Makes total sense. Pillar two Security. Now, obviously the goal 291 00:13:39.080 --> 00:13:42.240 is don't get hacked, but the framework gets very specific. 292 00:13:42.320 --> 00:13:45.240 It talks a lot about imidentity and access management. 293 00:13:45.600 --> 00:13:48.759 The main principle here is least privilege, and it's shocking 294 00:13:48.759 --> 00:13:51.360 how many companies still fail at this. If you hire 295 00:13:51.360 --> 00:13:53.840 a plumber to fix your sink, you don't give them 296 00:13:53.879 --> 00:13:55.840 the combination to your wall, say, if you give them 297 00:13:55.840 --> 00:13:59.039 access to the kitchen. In AWS, you give a user 298 00:13:59.200 --> 00:14:01.519 or a program to do exactly what they need to 299 00:14:01.559 --> 00:14:03.440 do and absolutely nothing more. 300 00:14:03.519 --> 00:14:05.879 The guide also really leans into traceability. 301 00:14:06.159 --> 00:14:08.759 That's cloud trail. It is a service that logs every 302 00:14:08.799 --> 00:14:11.799 single API call made in your account. If a hacker 303 00:14:12.240 --> 00:14:15.879 or honestly just a clumsy employee deletes a production database, 304 00:14:15.960 --> 00:14:18.480 you know exactly who did it, from what IP address 305 00:14:18.480 --> 00:14:21.000 and at what exact millisecond. It's a flight recorder for 306 00:14:21.039 --> 00:14:21.559 your business. 307 00:14:21.799 --> 00:14:24.759 There's also an interesting distinction here on where you secure 308 00:14:24.799 --> 00:14:27.480 things security groups versus network acls. 309 00:14:27.720 --> 00:14:30.919 This is a classic exam question, but it matters deeply 310 00:14:31.000 --> 00:14:34.960 for real defense. A security group is stateful. It acts 311 00:14:34.960 --> 00:14:37.440 like a bouncer at the club door. If the bouncer 312 00:14:37.519 --> 00:14:40.080 checks your ID and lets you in, he automatically lets 313 00:14:40.120 --> 00:14:44.200 you out. A network ACL, on the other hand, is stateless. 314 00:14:44.639 --> 00:14:46.919 It operates at the subnet level, and it's like a 315 00:14:46.919 --> 00:14:49.559 border guard. Just because you got in doesn't mean you 316 00:14:49.559 --> 00:14:52.279 automatically get out. You get checked both ways. You really 317 00:14:52.360 --> 00:14:55.720 need to understand these layers to build proper defense in depth. 318 00:14:56.320 --> 00:15:00.320 Got it Moving to pillar three reliability. The big quote 319 00:15:00.360 --> 00:15:02.519 here is stop guessing capacity. 320 00:15:03.120 --> 00:15:05.840 We touched on this with elasticity. In the old days, 321 00:15:05.840 --> 00:15:07.320 you had to guess if your website would get one 322 00:15:07.360 --> 00:15:11.039 hundred visitors or ten thousand. Guess wrong on the low side, 323 00:15:11.080 --> 00:15:13.919 and you crash during your biggest sale. In the cloud, 324 00:15:13.960 --> 00:15:17.200 you use auto scaling. The system watches the load. If 325 00:15:17.240 --> 00:15:20.320 CPU usage hits seventy percent, it automatically adds a server. 326 00:15:20.679 --> 00:15:22.960 If it drops to twenty percent at night, it kills 327 00:15:22.960 --> 00:15:24.039 a server to save money. 328 00:15:24.399 --> 00:15:28.279 The guide also emphasizes horizontal versus vertical scaling. I love 329 00:15:28.279 --> 00:15:30.480 the analogy of TETs versus cattle. That gets used here 330 00:15:30.519 --> 00:15:30.799 a lot. 331 00:15:31.000 --> 00:15:33.799 It's a bit morbid if you think about it too much, 332 00:15:34.200 --> 00:15:38.240 but it works perfectly. Vertical scaling is making your one 333 00:15:38.279 --> 00:15:42.279 existing server bigger, adding more RAM, adding a faster CPU. 334 00:15:43.000 --> 00:15:45.840 That server is a pet. You name it, You nurse 335 00:15:45.879 --> 00:15:47.960 it back to health if it gets sick, because it 336 00:15:48.000 --> 00:15:50.720 is unique and incredibly valuable. 337 00:15:50.360 --> 00:15:51.600 And horizontal scaling. 338 00:15:51.879 --> 00:15:55.559 Horizontal scaling is adding more servers alongside it. These are cattle. 339 00:15:55.799 --> 00:15:57.879 You don't name them. If one gets sick, you don't 340 00:15:58.240 --> 00:15:59.960 log in and try to fix it. You just terminate 341 00:16:00.480 --> 00:16:02.080 and spin up a brand new one in second. 342 00:16:02.200 --> 00:16:03.080 You replace the server. 343 00:16:03.200 --> 00:16:06.120 You don't fix it right. Because in the cloud, servers 344 00:16:06.120 --> 00:16:08.919 are meant to be disposable. You want to scale horizontally 345 00:16:09.240 --> 00:16:12.360 add more small servers rather than vertically because it prevents 346 00:16:12.399 --> 00:16:15.159 a single point of failure. If your pet dies, your 347 00:16:15.200 --> 00:16:17.840 whole app is down. If one cow dies, well the 348 00:16:17.919 --> 00:16:18.960 herd just keeps moving. 349 00:16:19.440 --> 00:16:22.639 Pillar four is performance efficiency. This is really about using 350 00:16:22.679 --> 00:16:23.240 the right. 351 00:16:23.120 --> 00:16:26.159 Tool for the job and democratizing advanced technologies. 352 00:16:26.279 --> 00:16:27.240 That isn't mouthful. 353 00:16:27.480 --> 00:16:29.600 It just means you don't need a PhD in advanced 354 00:16:29.639 --> 00:16:32.240 mathematics to run machine learning anymore. You just use an 355 00:16:32.240 --> 00:16:36.080 AWS service like Amazon sage maker. AWS has already done 356 00:16:36.080 --> 00:16:39.080 the hard math. You just bring your company's data. It 357 00:16:39.120 --> 00:16:42.399 makes truly high tech stuff accessible to normal developers. 358 00:16:42.519 --> 00:16:45.240 And this is where serverleist comes in again. Right Services 359 00:16:45.279 --> 00:16:45.799 like Lambda. 360 00:16:46.039 --> 00:16:50.679 Yes, we mentioned undifferentiated heavy lifting earlier. That is Amazon's 361 00:16:50.679 --> 00:16:54.559 favorite phrase. It basically means stop doing work that doesn't 362 00:16:54.559 --> 00:16:58.559 make your specific product unique. Racking servers is heavy lifting, 363 00:16:58.720 --> 00:17:01.480 but it doesn't differentiate you from your competitor at all. 364 00:17:02.039 --> 00:17:05.359 Writing brilliant code for your app does differentiate you. So 365 00:17:05.440 --> 00:17:08.519 use serverless architectures like Lambda. You just upload your code 366 00:17:08.519 --> 00:17:12.079 and AWS runs it. You manage absolutely zero servers. You 367 00:17:12.079 --> 00:17:14.400 focus one hundred percent of your time on business. 368 00:17:14.079 --> 00:17:17.559 Value, which flows nicely into Pillar five cost optimization. 369 00:17:18.240 --> 00:17:21.920 This pillar treats cost as a functional requirement. Think about it. 370 00:17:22.160 --> 00:17:25.000 If your app is incredibly fast and perfectly secure, but 371 00:17:25.039 --> 00:17:26.960 it costs ten thousand dollars a day to run when 372 00:17:27.000 --> 00:17:30.839 it should only cost one hundred, it is not well architected. 373 00:17:30.440 --> 00:17:33.319 And there are tricks here to fix that. Like spot instances, 374 00:17:33.720 --> 00:17:34.079 that is. 375 00:17:34.079 --> 00:17:38.640 A great example. AWS always has massive spare capacity sitting 376 00:17:38.680 --> 00:17:41.920 around doing nothing. They sell that spare compute power at 377 00:17:41.960 --> 00:17:44.759 a massive discount, sometimes up to ninety percent off, but 378 00:17:44.839 --> 00:17:47.319 with a huge catch, they can take it back from 379 00:17:47.400 --> 00:17:49.400 you with just two minutes. Notice if they need it 380 00:17:49.440 --> 00:17:50.279 for a full paying. 381 00:17:50.119 --> 00:17:53.400 Customer, so you obviously wouldn't run your main customer database on. 382 00:17:53.359 --> 00:17:56.519 That never that would be a complete disaster. But for 383 00:17:56.640 --> 00:18:00.519 batch processing crunching a massive backlog of no numbers where 384 00:18:00.519 --> 00:18:02.559 it doesn't matter if the job stops and restarts, it's 385 00:18:02.599 --> 00:18:06.279 an absolute gold mine. Using the right pricing model is 386 00:18:06.319 --> 00:18:08.359 a core part of being a cloud architect. 387 00:18:08.559 --> 00:18:12.359 Finally, we arrive at the newest pillar number six, sustainability. 388 00:18:12.599 --> 00:18:16.039 This one is becoming critical. The cloud consumes a massive 389 00:18:16.079 --> 00:18:20.200 amount of global electricity data centers are hot, power hungry. 390 00:18:19.799 --> 00:18:22.599 Beasts, and there is a totally counterintuitive tip in the 391 00:18:22.640 --> 00:18:26.359 guide here. The expert advice is to maximize utilization. 392 00:18:26.759 --> 00:18:30.160 It sounds odd to traditional IT folks. Usually we think 393 00:18:30.240 --> 00:18:33.599 running a server at one hundred percent CPU is dangerous 394 00:18:33.640 --> 00:18:37.440 it might crash, But for sustainability, running a server at 395 00:18:37.480 --> 00:18:41.359 ten percent is a crime. You are burning electricity and 396 00:18:41.440 --> 00:18:44.240 generating heat to keep the lights on for a machine 397 00:18:44.240 --> 00:18:45.960 that is doing almost nothing. 398 00:18:46.240 --> 00:18:49.519 So right sizing, which is using the smallest possible server 399 00:18:49.599 --> 00:18:52.640 for the job, isn't just cheap, it's actually green exactly. 400 00:18:52.720 --> 00:18:55.640 Every idle resource is just wasted carbon. If you aren't 401 00:18:55.680 --> 00:18:57.200