the well architected framework

en flag
it flag

All right, let’s talk about the well architected framework. These are the five pillars that AWS has learned over time. Dr. Success in AWS really success anywhere in I T. You need to consider all five of these pillars when you design your architectures to make sure you get the most out of your organization and the most out of your I T. Let’s take a look at each one of these pillars one by one, starting at the beginning with security insecurity. The idea is to protect your information and to make sure that you mitigate any possible damage by taking care of how are you planning for disaster recoveries? Basic strategies such as traceability, ensuring that identities are known at all times. There’s no shared credentials needed. A W s every operator, whether it’s a human or a machine, is known individually, and they’re granted permissions specifically, This goes to security at all layers. We don’t assume that just because you’re a trusted operator that you should be trusted to do all admin privileges. In fact, you might Onley be authorized to do extreme specific number of one or two tasks, especially if you’re a robot. There’s no reason to give your robots the permission to create new users unless they’re part of a user management application. We talk about security at the operator level at the network level at the application level. At this storage level, every piece of AWS has ways to lock it down, and best practices is to use all of those layers. But as we mentioned, risk assessment. Even with all of the protections in place, it is still incumbent upon you to make sure you plan for ultimate disasters, and you plan for ways to mitigate them. Are you protecting your data from an unfortunate attack? Uh, what if someone grabbed admin credentials for an account and suddenly encrypted everything and demanded Bitcoin ransom? How would you manage that scenario? These are things that could easily be mitigated if your critical data happened to be replicated in a different account with a different set of permissions. So no single admin access would be able to encrypt every copy of the data. So in that case, you can simply destroy the data that’s encrypted and replace it with clean, unencrypted content. Move forward. The next pillar is reliability, in this case, making sure that your system is up, that you can quickly recover from system failures. Now AWS is designed to be highly resistant, but one of the phrases you hear all the time and I’ve seen posters of it around the building is, is in I t. Everything fails all the time. Now you might have heard that phrase, but it’s important to know that phrase by itself. You gotta finish the paragraph. Everything fails all the time, so plan for failure and nothing fails. That’s the entire quote and AWS that’s critical for us. We expect things to happen, perhaps. Ah, hard drive fails. Maybe your mother board dies. Maybe Windows crashes. Not that Windows ever crashes, but pretend with me. Who knows? It’s your job to mitigate for to mitigate these possible disruptions by having baked in redundancies copies of elements backups of your database, making sure that you’ve got network options, even hybrid network options that allow you to have different options to connect to your on premises Data centers as you build hybrid modalities. Optimizing for cost. Just because AWS is engineered to be incredibly cost efficient doesn’t mean you’re automatically cost efficient just because you’re running in aws Let me go back to when I was designing on premises systems for my customers. If I were to use the exact same methodologies which I can do and run my system now on AWS, guess what? It’s not gonna be cheap because I’m still gonna be planning for a 7% utilization, which means a lot of overhead. And I’m gonna have a lot of other elements in there that you don’t need to use because of how AWS is architected, you need to plan to run in the cloud using cloud optimized technologies. If you simply replicate the same thing as an on premises system, you’re not gonna find from a cost efficiency manner and possibly even application efficiency that you’re getting the best out of AWS. We’ll cover a lot of that is this course goes on. Operating on AWS takes on a whole new meaning my on premises world. In that case, a lot of it was set it and forget it. Once you’ve got the hardware racked and stacked, there’s not a lot you can dio now as I’m running inside aws when operations point of view, I can change things constantly to continually optimize what I’m doing. We haven’t covered it yet, but think about different E. C. Two instance types being able to experiment and change with regular M class instances to maybe a compute optimized. Maybe I experiment with some graphics cards and G class instances, and each one of those can produce different types of metrics. That is an operation staff we can look at, determine what’s better, maybe change. Maybe stay with the old method. But more importantly, AWS is constantly releasing new services, new hardware, new methods By staying on top of those and by deploying them where it makes sense, you’re able to add some operational improvements without re architect ing the application itself. Two totally different way of thinking That’s not possible on premises. Performance efficiency is a continuation of this idea of operational efficiency, but in this case you’re trying to make sure that not only are you optimized, but you’re actually looking at new technologies. A W S just doesn’t release new instance types constantly. We’re releasing entire new technologies, which goes to the concept of mechanical sympathy, and in this case, the idea is to actually use the technology that best solves the problem, which means you need to be aware of the different problems you’re trying to solve and the different technology options that are out there so that you become one with the entire process. This idea performance efficiency is really how we talk about moving from just a lift and shift and semi optimized environment to truly being cloud native, not just in your operations but in your design, in your development in the architecture itself