Are you well-architected?

Karen: All right. Well, good afternoon, everyone. Welcome, welcome. My name is Karen and thank you for joining me in this session.

So before I get started in here, just a couple of quick questions:

For how many people is this your first re:Invent? Oh wow. Well, it's my first re:Invent too. So I am super excited to be here. It's, it's been a really great week so far.

My next question then - how many folks are actually running workloads in AWS right now? I mean, it was oh, good, good. Ok. That's what I like to see. Lots of hands up.

In this session we're gonna talk about, you know, are you well architected?

Now, this next question don't feel like you have to answer. All right. This is just something for food for thought. But if I was to walk into your organization and come up and say you told me you're running a workload in AWS. Is that workload well architected and maybe for some of you, it's like, yeah, absolutely. 1000%. No doubt about it. Others may be thinking, yeah, maybe kinda. I think so. I think I did all the right things to make sure it's well architected, which leads me to my next question.

What if I was to ask you for anyone who thought about that and said, yeah, I'm well architected. My workload is well architected. And if I was to ask you, how do you know, how can you prove that your architecture in AWS as well? Like adapted? And that might be the question that gives you a little bit more pause.

If we think about a bridge. All right, and I'm, I'm gonna relate to a real life story. I come from Miami, Florida. Right. Any other Floridians? So there's a few of us here. I do know when I got off the plane. My first thought was, oh, it's cold. It was definitely, it was a little chillier than it was when I left home in Miami. And we had a bridge that was built. It was a pedestrian walkway that was built in Miami and it was designed, it was uh for the Florida International University and it was supposed to be a pedestrian walkway to allow the students to go cross over the street rather than crossing on the street. Um because the street they had to cross was a really, really busy crazy street with a lot of traffic.

So they designed this really interesting unique bridge walkway, right? And they built it and they tried, they were trying out a new way of doing the infrastructure and they put the bridge in place and they got it all lined up and things were looking really good. And probably a couple of weeks or so after that walkway, that bridge was built and put in place. And before it was being really used by the students yet, just before rush hour traffic, that bridge collapsed, it came down in a fraction of seconds. And unfortunately, there were some very tragic consequences from that bridge. Eight people lost their lives when that bridge landed on the cars.

So while in AWS, we may not be thinking that something that's not well architected could be quite that dramatic. If you think about the infrastructure that you're running the applications that you're supporting, the data that you're protecting for a lot of companies next to our people. That's one of our most valuable assets. And the last thing we want to have happen is something go on in AWS where we end up with something that does not work properly that collapses and all of a sudden, we're now struggling and fighting to make sure we get that back.

That's a lot of the purpose as to why we are here today. What do we want to talk about? What are we going to look at? So we want to start thinking about the foundation. We want to make sure that our teams have that base knowledge, right? Understand what the pieces are. So we want to enable them to get that knowledge.

We want to make sure folks know what the well-architected framework is and chances are pretty good. You've heard that term? You've, you've probably heard us talk about the well architect, architected framework. I mean, we certainly mentioned a lot in, in my side as a trainer in all the classes that i talk about, but we wanna make sure that we know how to use that well-architected framework.

We wanna be able to adopt the practices in the well-architected framework. So that as we build, we almost get into that stage where we are building well-architected right from the beginning, right?

We want to, of course, for anyone who's not as familiar with, what really is the well-architected framework and the well-architected tool. Well, part of my role here today is to help show you a little bit about it, give you an idea of what's in this well-architected framework and it's more than just a white paper, although it's a very, very good document just to read when you're working and building your infrastructure in AWS.

And of course, we want to help continue to build that expertise. So one of the other things i'm gonna share, of course is what are some next steps in this whole journey for this next hour? Of course, we're gonna start by just making sure we understand and define what the well-architected framework is all about. I'm gonna give you an overview of it, right?

We're gonna talk about doing something called a well architected framework review. Has anybody gone through a well architected framework review at all? Ok. So I do see a couple of hands up and it's a really, really good experience. It's a really good thing to go through. We're gonna talk a little bit more about what that review is all about and what are some of the components and pieces that are in that well architected framework.

So let's get started and kick things off. And this comes back basically to the question that i started with, if you're running an architecture, if you're running infrastructure, if you're running applications, a workload in AWS, the next question becomes, are you well architected? And that's one of our goals, the well architected framework itself is not new. All this has actually been around for quite a long time.

And as you can see is our pretty little map here, you know, draws its lines and shows you the progress we've made, which kind of really started with this back in 2012. And a lot of this came from, of course, as companies were, you know, moving into AWS and moving their workloads into AWS. And as we were working with our customers, uh we wanted to make sure that they were taking into account all the different angles and decisions and thoughts and um making sure they were, you know, building things for resiliency and building things for high availability and you're thinking about how we're gonna deploy and are we gonna go in multiple availability zones?

Do we need to go across regions? Have we thought about the security aspects? And we started to pull this together into some more of a formal white paper, more of a formal document, more of a formal process that we can go through? All right. So we started moving up and you can see that we started adding the pillars questions. We're talking about the well-architected tool and what some of those questions are in just a little bit.

So we started adding those in. We added, we started off with four pillars right back in the day. Does anybody know? Can anybody tell me, just shout it out. How many pillars are currently in the well architected framework? Does anybody know? I'm hearing fives. It is six. We just added our sixth pillar. We added it in 2022. It's our sustainability pillar and the sustainability pillar is looking at options to help reduce our footprint on this wonderful planet we call home and i'm very, very proud to be working for a company that takes that so seriously.

And at AWS and in Amazon, we are so we added that one. That's one of the most recent pillars, our sustainability pillar and part of uh the functionality we have in there, by the way, can also help you look at what you're running and see if there are steps you can take to help reduce your impact on this world too. And that's all part of that.

This year, we added a couple of things because customers were asking for them, right? So we had customers coming up to say, you know, for those that have done these reviews, a lot of times what was happening in these reviews, customers were saying, well, we do these reviews and you've got all these great questions. But for, for some of us, the every workload, every workload we do and every workload that we've reviewed those, the answers to those questions have always been the same answers because it's the way we do things in our organization.

And so our customers were coming back saying, is there a way that we can kinda not have to answer those questions every time we do a review because they're always the same, it's always the same answer. It is the way we do things. And one of the things we came up with this year was the ability to create what we call a review template, which is the ability for some of those key core questions, if you do a well-architected review to be able to save those answers and use those as a starting point for your next review. And so that was one of the big things that uh folks were asking for, our customers were asking for the other.

Uh what i think is uh was really well requested was an ability to generate a consolidated report so how many of you are running more than one workload in AWS? All right. So I'm seeing a few hands and again, from our customers, we were getting, uh, customers saying is there a way i can get a consolidated report? I mean, I've got four or five different workloads. I've done four or five different reviews. It would be really great if i could see a consolidated report from my well-architected reviews and that was also added this year, the barcode there, by the way, should take you to the uh well-architected white paper, right? The well-architected site, it is worth a read. All right. So i said, but uh definitely take a good look at it it or talk about, well, why do we want to use this? Why, why should we really sit down and focus on what's in this well-architected framework?

One of the big benefits of course is hopefully we can build and deploy even faster than we do now. And of course, one of the big benefits to AWS and cloud computing is the ability to build and deploy quickly. I think this is one of the keys. All right, to me, this is one of the key benefits of knowing what's in the well-architected framework, doing the well-architected reviews following the well-architected best practices is to help lower or mitigate risks for our workloads that we're running in AWS.

We want to make good decisions about how we're going to deploy where we're going to deploy what we're going to incorporate as we deploy our workloads. And of course, we want to learn and follow AWS best practices. All right. So in terms of using this, it's all about having a mechanism or a tool that you can use, right, as our customers to basically really make sure that we are building good solid, long lasting infrastructures and workloads in our AWS cloud, right?

So of course, we want to learn, we wanna be able to measure, ok, coming back to that question that i asked. All right. So, you know, for those who are saying, yeah, i think i'm well architected and i came back and said, well, what if i want to, you know what if i ask you, how do you know, how can you measure? How can you tell? And that by the way is what the well architected tool is all about, right, is being able to do that measure and then of course, to use that information to be able to make improvements.

So here's another food for thought question for you. If you were to learn early on in building an application or deploying your workload, that there was a fundamental aspect that you had missed. All right, maybe we forgot to think about doing backups. All right. Now, for most of us probably backups is one of the things we just automatically make sure as part of, of what we're doing. But, you know, what if we realize that we have completely forgotten about making sure that we're doing backups?

Do you think you'd rather learn about that earlier on? Right. And be able to make that adjustment and make that change and make sure you're doing the backup than to figure it out when something went wrong. And all of a sudden you realize that either you didn't have backups or maybe your backups weren't correct or maybe they hadn't been tested.

So in some cases, when we talk about improving, some folks will say, you know what, i, i did a review and they found xy and z that was room for improvement and we found it out during, you know, during this review and maybe we did the review, you know, relatively early on. And so folks will say, well, isn't it a bad thing that we found out that we had missed something that we had some kind of, you know, big flaw?

But you know what, finding that out early is not necessarily a bad thing, probably better to find out early so that you can make the improvements and make the adjustments. I mean, i'd certainly rather find out early and say, oh, ok. Yeah, i can take steps. I can do something. I can address that.

So when we talk about the review a little later, don't think that, you know, if there's a review and there's a finding in the review that's bad. No, if you do a review and there's a finding in that review, that's good, right? Because that means you can now do something about it and that's part of our goal as well.

Hi there!

Now a lot of folks who have heard of the Well-Architected Framework and worked with it are familiar with this idea of pillars, right? Because when it first started, we talked about the four pillars, the five pillars, the six pillars that we now have, which of course is, is you know, think of that, like think of like the front of the White House, right? With all the really nice white pillars, that's how we actually diagram it in our pictures.

So we do have the pillars, that's definitely a big part of it, but we also have something called lenses, lenses, right? And we're adding more and more lenses all the time. So the Well-Architected Framework and the six pillars, right? Are your foundational best practices, right? Different areas to consider. But we're all in different kinds of organizations. And so sometimes if you're in, for example, healthcare versus building cars, they both have a lot of foundational requirements that are the same, there's no doubt, but at the same time, they also probably have differences in what they have to look at, right?

Building cars, maybe you're not quite so worried about HIPAA compliance and the health information protection where if you're in healthcare that's really really fundamental. And so what we're doing is we're adding these lenses and these lenses add additional questions into the tool when you do your reviews, that kind of try to bring that very specific perspective into place.

So it's the the general base, but now this additional kind of focus, let's, you know, take the magnifying glass and focus it in. So we're really kind of spotlighting that particular kind of industry and I'll show you some of the lenses that are in place and being planned.

Each one of our pillars in each one of these areas, we have some what we call general design principles guidelines. There's some overall general ones that we're going to talk about in a minute and then within each pillar, each pillar has very specific principles that you want to adhere to or look at within that pillar.

In the tool itself, the Well Architected tool, when you go to start a review for each one of those pillars and based on the lens that you've selected, we give you a series of questions that you want to look at when you're reviewing a workload and you're gonna pick a specific workload and start your review. We give you this series of questions and they're all yes, no. Are you doing this? Do you have a methodology for doing this? Yes or no.

And what you're gonna do is go through them with the group of team, we're gonna talk a little bit about, I said setting up that well, architected review. But you go through those and then what we do is we take that tool and we take the answers to all those questions and we pull it all together and we analyze it, we organize it and we give you a report and say, here's how you're doing. Here's some of the areas where you're very, very strong. Alright. Well, you've got really good things in place and maybe here's a couple of areas that you might want to look at in order to make improvements to make sure that your workloads are well architected, right? And of course, our best practices that feature into all of us.

So in this section, all right, good. Ok. Break this all down. All right, we did that quick review. All right. So our pillars operational excellence. Are we running things, running them well in our, well, in our architecture, security? All right, we, of course, always security is paramount. Yes, I think everybody's kind of in agreement. Security is definitely a really, really important aspect. All right. So we have a pillar that really just focuses on all of those security aspects.

Reliability. Well, you know what, it'd be really good to know that even if the demand peaks up, our customers can reliably access our applications. All right, that's another big, big area. We wanna make sure that we're getting in the performance efficiency that we're using the right tools that we're getting the best performance and at the best possible price, I mean, you know, not too many of us have like an infinite budget and somewhere in there, you know, we do want to optimize our cost, right?

We wanna make sure that we are getting the absolute best value and that we are doing our operations and running our applications at the best possible price point. And that doesn't necessarily mean always by the way, the cheapest ones, right? It's I'm getting the best price to make sure I'm getting what I need for my applications and of course, our sustainability pillar. Hm. That we just added, taking a look at how we can help reduce our impact, right? Which again, and as we're probably all aware, that's become a really hot topic lately is what can we do to reduce that impact?

So these are the six pillars. And if you go to the white paper on the Well-Architected Framework, we go into depth and we explain exactly what's in each of these pillars. What do they mean? What's the focus? And occasionally I'll get folks who put up their hand and say is one pillar more important than the other. And the reality is the answer is no right. In any one given review that you do, you might want to focus on one or two pillars more than the others. They're really, they're all interconnected. They're all very, very important.

Now when we start talking about those lenses, you know, so that was what I was talking about, you know, healthcare versus building cars. We have several high performance computing software as a service you can see in here. Uh networking data analytics, excuse me, so sorry. Uh but if you take a look at these different lenses, again, this is all about those different focuses if you will and I do have to mention not all of these lenses are available yet, right?

The one lens, there's a few that are the basic Well-Architected best practices lens is the starting point. Some of these lenses I said they're building, they're adding these are the ones that are currently planned and there will be additional lenses that will be added and built on another new requirement that came in from our customers.

We had customers who came up to us and said, well, you know what, we're kind of unique now, maybe we were kind of that really niche organizations. We have a really unique perspective that we have to look at these reviews. We're not, you know, we're not high performance computing, we're not software as a service. We kind of have this this very unique different perspective.

And one of the things that you can now do and we give you the tools, you can create a custom lens, which means you can and we even give you a template, JSON based template that you can download. You can add your own questions to include in any reviews that you are doing as part of a well architected review.

So if there are things that are very specific to your business, very specific to your industry and they're not in one of the existing lenses, right? You can create that one. And then when you create your review, you say, ok, I want to include that lens. It's gonna include those additional questions into your review across the different pillars and make sure that they are evaluated and ranked with everything else.

And so here's a just a quick screenshot of what it starts to look like. All right, so you can, again, we gave you a template, you can start with it, allowing you saying, ok, so how do I start building a lens? All right. Well, we give you a JSON template follow that, add your questions and it said we got documentation to help you walk through how you rank them and put them into their various categories and various pillars. And now all of a sudden you've incorporated your own company's perspective into your reviews.

All right, you just looking through all these uploads, so upload them again, JSON formatted. And of course, we always like to make sure that you have QR codes. So if you want to get into the documentation on how to build or work with a custom lens, because we have the QR codes to help you with that too.

Now, overall principles, general guidelines, if you will, that you want to look at, from a overall perspective. So we have some general principles. All right. All right. So that we want to follow each pillar has principles that belong to that pillar. And then we talk about improving through game days.

So, if you see improving through game days, does anybody say? Oh, that sounds like a really good day to go out and play soccer? Let's have a game day. We'll all go out and play soccer. Ah, ok. That's not quite what we're talking about. What we're saying is go through tests, go through drills, break something.

Spin up on the infrastructure, spin up a copy of your infrastructure, by the way, please don't go out and start breaking production. Ok. I'm just saying that that's not, that's not what we want you to do with game days. No, but spin up a test infrastructure that replicates what your production infrastructure looks like and then have somebody go in and break something and then make sure that you're able to completely recover and rebuild from whatever happened.

Those are the kinds of things we talk about with game days because you want to be able to do that. And you know, there's a couple of benefits besides you catch anything but one of the biggest benefits by making sure that you've gone through tests and you've tested your recoveries and you've tested when something breaks.

One of the biggest benefits is that when something breaks for real, you can take a big deep breath and you can say I can do this, we can handle this. We've gone through it. We, you know, it may not be identical but we've gone through it and you're gonna feel a lot less stress knowing that you've gone through practices. They said it won't eliminate all the stress. I promise it never does.

Oh, and I started off in IT back in the days of mainframe computers. Does anybody remember mainframe computers? Yeah, a few of us, you know, you know, big things as big as, you know, the house, so to speak. Yeah, that's where I started my career and, yeah, we, we didn't have the ability to practice your game days back then we couldn't spin up a test environment that was identical to our production environment that we could just kinda, ok, let's see what happens if somebody deletes the database.

I mean, we just, we just didn't have that functionality but in AWS you certainly can, you can spin up a test environment. Right. Pretty much clone production. Run some of these tests, shut it all down when you're done. And it's really not a whole lot of out of pocket expense to do that. Is it, you know, run something for a few days, test it out, you know, light a fire under it, see what goes wrong. I said when you're done, shut it down again, just don't use production to do that.

But we couldn't do that back in the day when I started in IT. That was unheard of. And the other one, of course, along with testing for game days is also, of course, make sure we're focusing on potential security events. I mean, how often do we hear about some security breach that's happened someplace, you know, and, and usually that's just considered not good news and we don't even hear about most of them. Yeah. Oops, go back one. Here we go.

All right. So general design principles. This is just overall guidelines from Well Architected. These are not pillar specific.

Stop guessing what you think your capacity is going to need. One of the benefits to AWS is our ability to scale out, scale in scale up, scale down. All right, we don't need to do that guessing. We no longer need to try to order a server on day one of a project and we haven't written a line of code yet and cross our fingers and hope that we've ordered a big enough powerful enough server to do what we want. Ok. I've gone through that as well. Ok. We don't need to do that anymore.

Test on production scale. I was just talking about doing that. Automate.

Ok. Automate, automate, automate right? Automate building your infrastructure. That's always a given, right? Consider the new things, new services. New functionality, new types of instances, you know, can I take something that I've maybe been running on EC2 and it's been running really well. But AWS has introduced a new feature or a new service that might be able to do that for me, consider it at least evaluate it. Right. Of course, I said, you know, make sure we're data driven. Ok. And we've already talked about the importance of game days now in the question section, right? I'm gonna go through in here, right? This is part of our documentation. When you go to do a review, you're going to get questions on each one of the pillars and in each of those questions, we don't just kind of put a question out there and leave you hanging.

So you look at the question that says, you know, uh how do you protect your data at rest? And that's all we say. Oh no, we're gonna go in and say, ok, do you use encryption to protect your data at rest? Uh hopefully the answer is, you know, we should, we should, ought to be doing that. But what we'll do is we'll give you additional information. All right. So we'll give you that perspective. We'll give you the best practices, right? Make sure we're managing our encryption keys. Who can tell me what happens if you encrypt data and you lose your encryption key.

Yeah, it's kind of gone, right? Like, like don't send a trouble ticket cause if you've lost your encryption key. Uh sorry. Uh yeah, you're just in really, really big trouble you. So when we start thinking about protecting data at raft, it's not just encryption, it's how are we managing the encryption keys? How are we limiting access to that data? That's part of protecting it? Right. So we give you all that additional information to help guide you.

Wait, I get through all my build up here. Ah right. So let's say you've decided now that you know a little bit about the well-architected framework and you've heard me talking about this well-architected review. All right. And a few of you have said that you've actually gone through a couple of well architected reviews. So let's just think about doing a well-architected review and I'll show you a couple of screenshots coming up. But the idea of a well-architected review is to pick a workflow, right? And analyze that workflow using the best uh well architected framework, these pillars, these questions, these lenses.

So if you want to do one of these reviews and i highly highly recommend them, we have some recommendations to make sure that those reviews are going to be successful. And the first and foremost is to make sure you've got the right people in the room doing the review that you wanna have folks that can answer questions on security. You wanna have folks that can answer questions about operational procedures you wanna have of course, folks that can make the big decision about. Ok. Are we going to implement a change? What kind of change? But you need to have the right people involved in doing the review. So that's going to be one of the first things you wanna do, right? You have to have some business sponsorship. Folks are saying yes, this is a good idea, right? And then we want to collaborate, right? Gather data and most importantly for everybody who's going to be part of a review, make sure that they take some time to go through the well-architected framework white paper so that they come in knowing kind of the angle and the questions and the pillars that we're going to be looking at because it's really gonna help them, help you do the review and get some really good results from it when we think about a well-architected review.

First and foremost, this is not an information systems audit. Have any of you gone through like a formal information systems audit on your systems? So some of you have gone through that well, in one point in my previous life or maybe several previous lives ago, uh i used to be a certified information systems auditor. That was one of the roles that i had and my role was to come in and do information systems audits. And you know, for some strange reason, most departments when they got that notice in the internal mail that said your application has been selected to be audited this year. They weren't always real happy to see me. You know, for some strange reason, i did not instill this, this feeling of happiness and joy in them. You know, i was always like, oh, how did we get picked?

Now, granted, we actually had a few departments that would request a review. They actually wanted that certification, they wanted that review. So, so we actually did get folks who would send us in a thing saying, could you please include this new application and do an audit for us? But most of them not so much the idea of a review though, this isn't an audit, this isn't about finding fault and reporting it up the chain because that's what we used to have to do with audits, right? They used to, we had a formal chain of command, they had to go all the way up to the executive levels. No, this isn't gonna go anywhere that that's not what this is about. This is about pulling the right people together to take a look at the workload, to do an evaluation, to say, how can we make sure it is good? And if it is not, how can we make improvements? We want to protect this workload, we wanna protect this data, we wanna protect our applications. So again, it's a very different perspective. All right.

Right. It's not theory. Ok, we've done a lot of these kinds of reviews when we put together the well architected framework and that came from an awful lot of work that we did us and our partners and our customers. Right. So the information, the recommendations they are proven they, they work, right. And it's also not necessarily a one and done. This is something you may want to come back and evaluate again down the road, but they're not meant to be a one and done.

Great. All right. So when you come withdrew a review, of course, uh you know, the earlier you can do this review and make adjustments probably the better. Ok. We do recommend this early on in the process. That doesn't mean to say that if you have a workload that's been running for a while, then you kind of say, oh, well, this one's been running and we're not early in the process. So maybe we should just ignore it and, and not worry. No, no, no, no, no, no, that's not what we're saying either, but we're certainly saying this is something you want to think about as early on as you can, right?

There is no such thing as a bad decision when it comes to these reviews. Nor is there a bad decision typical legal when you look at the questions that we're going to ask and we ask a question and you're kind of saying, um hmm sweetie didn't do that or maybe we did and it's not a bad decision. You know what the biggest problem is. The biggest problem is not that you made a decision and it was wrong and we're not gonna be able to change it half of the time. The biggest problem is that we didn't even think about it. We don't make a decision. I gotta come back to my backups. We don't make a decision not to do backups. Right. Or at least not likely. Right. Yeah, we're, we're probably gonna say, yeah, we probably should do backups. It's more like nobody even has thought about doing the backups.

I got another quick little story. I'll tell you, uh, and this is on testing recoveries, not so much testing backups, but there was an organization and they were running, uh, way up in northern canada. Uh, now i, i grew up in central canada and so if anybody's saying, gee, she sounds like she has a canadian accent. Apparently i do, i didn't think canadians had an accent, but apparently we do and apparently i do. And, ok, i just kind of go with it and say if you, if you think i have an accent, but there was a company and this was years ago, um, and they had a system and they had tunnels between these two buildings and they had their application running in one and they built a vault in the other building because they were taking ta tape backups on a daily basis.

So then i can tell this is old because it's like tape backups and, you know, i don't so much see that now. And what they did is they would take a daily backup and they had enough tapes that they didn't have to reuse tapes. They just got a new tape every single day. And so they would take their backups and they would, you know, take their tape and they would walk it through the tunnels because it was really cold outside and they put it in the safe vault in the other building. And then all of a sudden one day, somebody said, maybe we should try a test restore and it wasn't that they weren't taking backups or they hadn't, you know, they made a decision not to ever do or restore. They just never did one.

And so they went and did a restore. They did a quick test restore. So they went and grabbed what they did is they grabbed the very first tape. They said, oh, let's go back to the very beginning. Let's grab the very first tape, took that tape back, took it over to the building, went to try to restore it on their system and the tape was blank completely to me. Blank. Gone, just gone. And they said, oh, wow, that's really weird. And they figured, well, maybe it's because it was old. It was like 18 months old or something like that at this time.

So they grabbed one from about six months ago and it was blank and they kind of went, oh, now, thankfully they had never had a problem. They had never had to do a report. They went and got the tape from the day before and that one was blank and they thought, oh, wow. Ok. They've been really lucky. So, they took a new backup, they checked the backup, they took the tape, put it across in the vault, went and got it. The next day, came back, it was blank and what it was and they figured it out is when they were walking the tapes through the tunnels, all the electrical wires were running through the tunnels for both buildings and generating just enough electrical force that it was erasing their tapes every day. How say it again. They had just never, i mean, it wasn't that they didn't make a decision to do it. They just never thought about it. That's usually the bigger problem.

And then of course, again, almost every workload can be improved. All right. All right. So again, what are we looking at best practices, picking the right technology, managing our portfolios, right. All of this kind of falls into play as to why we might want to do these at the heart of doing a review is what exactly is a workload? A workload is a combination of components and services that you're using, that deliver business benefit for you, whatever that business benefit happens to be.

So, one of the things when you're doing a review that you want to do is you want to pick a very specific workload. Don't go in and say i'm gonna evaluate my entire aws infrastructure. Uh no, that, that's, that's typically not what you want to be doing. You want to find a very specific workload, you wanna get the right people, the right teams together.

You want to very clearly identify all of the services and components that are supporting that particular workload. And then you wanna go through do the review and based on those findings, you want to define the plan and procedures and direction, you're gonna go from there when you're talking about the people. And I've said a couple of times you gotta have the right people in the room.

First thing you have to do is define which workload or workloads you want to do a review on and there's several different approaches you can use to do that. You can say I'm going to focus on our mission critical. Maybe you're gonna focus on a smaller one the first couple of times or smaller workloads the first couple of times you go through this review until you become a little more comfortable with the whole review process.

As again to find your workload, identify an overall sponsor for the evaluation and then sponsors in each of those key pillar areas. We have three different phases. The first of course, get the pillar or get the the sponsors for your pillars, scope it out, prep the customer keeping in mind, the customer could very well be internal.

All right, when we're talking about customer, that's the group that's doing the review that owns the application. So in many, many cases, customer is an internal entity, not an external entity. Make sure that they have the white paper that they've taken the time to review it, they know kind of what's coming.

Then you do the review, you record it, publish the reports out of it and then you take a look at your findings and prioritize the steps that you want to take to make those improvements based on that. Go back, review it afterwards, right? They said come up with your treatment plan, review the findings, review the results as a team, right? And then make the right decisions and the best decisions on ways to approach that.

So our overall workflow, all right is we're going to identify risks and opportunities. That's one of the things we want to get out of the results. We want to make sure we understand what those risks really are, right? Take some time to go through them, decide how we're going to resolve them, prioritize those improvements, implement and track and then come back and take a look and make sure that we got everything that we wanted out of that well-architected review.

I've been talking all the way through about all these different pieces that make up the well-architected framework, right? And these well-architected tools and the well-architected review. And so again, everything comes together, we've got the content, we've got the white papers, we've got the, you know, well, architected pillars, we've got the actual review that we do the well-architected tool that comes in here.

All right, we've got the workload, of course, and all the metadata and all the results of all those questions that we're asking, right? We've got our improvement plans that come out of here and all of this comes together, right? In terms of what makes up well architected at the core of doing the review is something we call the well architected tool.

Ok? This is available to any of our customers, right? You can log into your account type in well architected. All right, go into the search bar right in the console type in well-architected. They'll take you into the well architected tool. You can use this to define your workloads. You can use this to create your custom lenses. You can use this to review your reports. You can start and stop a review by the way.

So let's say you do a review you've planned for an afternoon, you get into some rather interesting discussions during that review with all the various players that are involved. You get halfway through, you get through three of the six pillars and you say you know what it's seven o'clock, it's time to go for supper. Ok, save it, come back, finish it off the next day, right? There's nothing that says you have to do it all in one sitting, right? You can absolutely save it. It'll it'll be there on your current results.

Of course, all the findings are gonna be available to you in here. I'd notice the pricing. Ok, guess how much we charge you to use the well architected tool. Alright, that is free doing these reviews. The well architect, this is all there's no, there's no cost for any of this.

And then here this is sort of what it starts to look like. There is the question, right? The main area cost, you know, how do you, you know, get the most out of what you want and there's all those yes, no questions that you're going to see and i mean it it's actually very easy but you do need somebody who's running it and you do need a separate recorder or scribe to take notes.

So you can add that in uh you know, two people is probably a really good idea, right? So we've got the question, right? The principles that come in here, of course, about the best practice overview. So get all the documentation. We don't just throw a question at you and leave you hanging, right? We give you all the supporting information.

So as you're doing the review, if somebody says, well, what do you really mean by question x hey, let's pull up the documentation, let's read through it. Let's make sure we understand sort of what's aws really trying to ask so we can answer it properly. I here's the main website.

All right, if you go in and go into our well-architected website, gives you access to the white papers. All the documentation, right? All that supporting information is in there, right? Our white paper again that i, even if you're not gonna do a well architected review, you really should take some time to take a look at the well architected white paper and follow those recommendations and foundational guidance for building your workloads.

I we also have labs that you can do if you want to just get started with the whale architected tool. We actually have a lab that you can do that will show you how to create a workload in aws and it'll show you how to get in there and start the review and answer some questions and go through one of the pillars. It takes you through one of the pillars and then said, so it actually shows you a little bit how to work with that tool.

So we have the well-architected labs for you. We have a solutions library, right? That is available to you. And of course, we have partners as well as the aws uh proserve team that can help you with these. All right. So here's a list of some of our partners that can actually help you walk through, doing well-architected reviews. This is not a comprehensive list, but if you go to the website that will actually give you a list of all the partners who are certified to help you do well, architected reviews.

And i said at the beginning that we had four things to go through. Ok, bonus time, i got a little bit extra for you. We have a section five and we've got about 10 minutes. All right, at least of my official time. So what are the next steps that you want to go through? Well, of course, if the first things decide to go ahead and do a review, i mean, even if you pick just a small workload and say, you know, i'm gonna go through this one just because i wanna see what this process really looks like. Go ahead do that.

You know, i said identify sponsored, define it, get a timeline. All right, get your business context, schedule the review, go and do one of these. Now, if you go through the review and you say, ok, i'm never, we're never doing this ourselves again. Uh uh we're gonna bring somebody in the next time. We wanna do this, we're gonna talk to one of those partners. That's ok.

On the other hand, you might go in and say, hey, we can do this. We've designed this tool so that you can do reviews within your organization. You don't have to bring in anybody else? We've designed this to be a self-service tool. So you can say, you know what we're gonna do this internally.

Hi, of course. How do you want to find out more? Right. We have classes. We have training. Ok. I'm a technical trainer. So, you know, somewhere in there when i'm a technical trainer, i'm gonna talk about training because, hey, that's what i do. So, we do have some really great self paced training. We also have two really good classroom in-person classes.

We have one that's called the aws. Uh well, architected best practices. It's a one day class. And what you do is you go in based on all six pillars, right? We, we do a review of what all six pillars are in depth and for each one of them except sustainability right now, we have a hands on lab where you take a look at a workload that is not adhering to that particular pillar that has not got all the best practices for that pillar in and you address it in the lab.

So in that one day class, you actually get um i said several labs, we have five labs in that class where you can go in and actually see what kind of steps you could take and why these steps would be really important.

We also have another one, it's called the advanced aws well-architected framework. And that one takes you through doing a mock well-architected review. All right. So, those are the 221 day classes. Right. And the second one there, of course, we've got ramp up guides as well to help you out with that. Right.

We have skill molder, right. Which gives you access to all sorts of self-paced training and labs. So, we have skill builder. And you've probably heard about skill builder once or twice or three or four times as you've been here and reinvented. I, i'm sure that that's a word that you've heard a couple of times.

And then of course, we have our certifications, right. So, you know, if you're anybody who's interested in going for that solutions, architect, associate solutions, architect, professional, one of our other certifications, of course, we always have the certifications available for you.

So, what do we want to do here? Of course, build brilliantly, take a look at the labs. We still have our self-paced labs rooms available. All right. So if you wanna get some additional hands on go and uh, find out they are still up and running. They would love to see you at those uh, the self-paced labs. All right.

Build real skills. Well, we're getting toward the end of re invent now. All right, we're kind of on the second last day, but there's still sessions going on. There's still labs available, there's still spotlight labs available. Take advantage of them while you're still here. Right.

We also have for skill builder, you'll be able to activate a seven day free trial into skill builder. All right. So that you can go in and see what's in there and see the content that we have in skill builder. Um i said we have content for the well-architected framework in, in skill builder. So you can take advantage of that.

Does anybody have any questions at all that i can answer?