Are You Well-Architected? - AWS Virtual Workshop

hello and thank you all very much for taking the time to join me today I really appreciate it so in this session where we talked about ru well architected I'm going to be covering a lot of information about the while architected framework and the content and resources that are available to help you determine are you well architected so my name is John steel I'm a cloud operations specialist but as part of the AWS Enterprise Support Team so what I'm going to talk about today is well architected and an introductory level so you can understand what is the well architected framework what are the resources that come along with that and what's the real value proposition what are we trying to do for our customers with this framework we're also going to walk through an actual presentation the virtual workshop section where we explain how to use the tool and some best practices around getting the most value from tool after that we're also going to dive a little deeper into the other content resources besides just the recently released well architected tool that can help you to better utilize the whole well architected framework so we're going get started here first thing that I want you to do is take a moment and think about the well architected framework is designed really to help customers understand what's different when it comes to the cloud so take a moment and think are you in the cloud right now are you using AWS are you using cloud are you using a hybrid cloud environment and if you're doing that do you know whether or not you're well architected so that's really what we're trying to help customers answer so if you take a moment think about it we were really hope that most customers when we asked that question would be able to say sure I'm well architected and really when they're diving in to start their journey in the cloud they probably want to be well architected to begin with so thinking about it for a second if you're well architected many people would say yes sure I am the challenge is then we start thinking about well architected we like to dive a little bit deeper so as you start to dive deeper in this session we're really going to talk about more than just the general question are you well architected but we're actually going to talk about already well architected around these five pillars so we have concepts around operational excellence security reliability performance efficiency and cost optimization and when we see with a lot of customers is we may ask are you well architected and initially the top-level you say yes but when we begin to dive deeper into these areas often the answer is not quite the same and some of these areas you may know there's things that we're not doing as well as we should we may not have opportunities to improve so let's move on and think a little bit more about what you can do with the well architected framework to better answer that question are you well architected so we think across those five pillars what is it that those pillars are really helping us to do so take a look at those five pillars and think for a moment if you had to take every workload that you have so when we think about a workload we're thinking about a set of systems or services that are used to provide business value so if you think about all of the things that you have in your business that you use a software or technology to provide business value do you know on a regular basis if you're well architected across those five different concepts so if you think about those different concepts the reason we have well architected is to really help customers apply this more consistently so we want you to be able to have a process that allows you to review and understand those workloads on a consistent basis and to do it throughout your entire technology portfolio so that's really why we're here today this is the reason that AWS created the well architected framework so you can see here while architected encompasses a lot of different resources and a lot of different content to help our customers answer the question of whether or not they're well architected so as you're beginning to build systems before we start talking about while architected what would probably help is a little bit of history where did well architected come from so here's the history of well architected it really started back in 2012 so solutions architects began with the idea of just going to customers and asking them are you well architected and over time that developed into a common set of questions that solutions architects were using to ask customers are you well architected do you know what AWS as best practices are for architecting in the cloud so in 2013 there was a lot of different questions were being asked by solutions architects but over time it was sort of recognized that we needed to be more can assistant in that and create a consistent set of best practices for customers to ask themselves about so that's really in 2014 where we came to the questions being brought based across those four pillars originally of security reliability cost optimization and performance efficiency now over the course of time we continue to expand that framework and the thing that we want you to see is really well architected is a continuously evolving thing based on the best practices we've learned from working with customers so in 2015 we recognized not all customers have access to a Solutions Architect we actually published the well architected framework as a white paper that sort of incorporates all the best practices we'd learned from doing thousands of these reviews with our customers over the course of time then we were able to add the operational excellence pillar back in 2016 and then in 2017 we made it so that our AWS partner network partners could become trained to deliver the same level of value that essays were delivering 14 for customers using the well architected framework to then last year at reinvent we were able to launch the self-service while architected tool which is in fact what we're going to be covering today in our virtual workshop and along with that tool we recognize that customers didn't just want to know what are a double us as best practices and what should I be doing but if they were able to recognize risks in their environment by using that tool how should they be addressing or mitigating those risks so that's where we ended up with self-service put that self-service tool and improvement plans embedded in that tool and we'll talk a little bit more about that today the important thing to recognize though is that while architected is based upon AWS as long history of working with customers to help understand what they were doing what was working the key is these best practices are based upon our work with customers because that's how we have developed these best practices so I now want to jump in and actually talk about what is the well architected framework so the well architected framework covers a lot of different content so first thing we're gonna do is talk about why we would want to use the law protected framework what is the point of this what are we trying to do for customers so really add as root the most important thing is we're trying to make it so that customers can build and deploy and the way that works is that we want them to reduce their tactical firefighting efforts and be able to think about things like capacity management and automation and security and some of the things that are different in the cloud in a way that will make them able to experiment and release more often because we don't want customers to focus on just fixing things rather we want them to be able to focus on delivering business value and doing that more quickly now one of the ways that happens is by helping customers to identify risks and then to reduce or mitigate those risks so when customers understand what the tested in true true best practices are for operating and designing in the cloud they're able to reduce risk before they go into production something else is really important is when you understand what risks are it allows you to make informed decisions so we recognize in modern complex systems it's impossible to completely prevent or remove all risk from an environment so the goal is to help customers understand what their risks are and under make an informed decision using data around those risks before they move things into production and while they're operating and supporting their workloads then the last thing is customers have been coming to us for a long time asking how does AWS recommend I do this what does AWS is best practice for this so the goal of the well architected framework is to try and collect and aggregate all those best practices around design decisions for cloud-based workloads and determine what are they and expose them to customer so that you can learn those best practices on your own so that's why we created the well architected framework now what really does the well architected framework do for you so we we see it as a central part as a mechanism for your cloud journey so what do we mean as a mechanism so if you if you actually take a look at several talks that have been done by Jeff Bezos the CEO of Amazon he talks about mechanisms as a very important alternative to best intentions we all have good intentions we all want to do the right thing the problem is that sometimes good intentions are not enough so the idea behind having a mechanism is a mechanism is a repeatable process that allows you to improve it over time so we see well architected is a way to make those improvements through repeatable process over time we'll let you learn the strategies and best practices for architecting and operating workloads in the cloud and more importantly it doesn't just help you learn those best practices it creates a consistent way for you to actually measure against the best practices and determine if you have any risks once those risks have been identified because you've been able to measure against them consistently you should then be able to make improvements over time so you'll see consistent improvement in your operational excellence and the design of your workloads so what goes into the well architected framework so in the well architected framework it really consists of three things pillars those five pillars we discussed as well as design principles now there's two kinds of design principles and we'll talk about them more a little bit later but we have general design principles which are overarching principles we see should be used across all of the design as well as design principles that are specific to each one of those five pillars then we have questions and really those questions are designed to help you look at the design principles and best practices and those pillars and determine are you aligned do you know what they are are you following them and if you're not what risks do they present and what should you do to try and reduce or mitigate that risk so the pillars are well architected here we really want you to think about them by way of analogy think of it like a building so I just happened to be here in Seattle today in Seattle if you have ever been here you'll see that we're constantly building new buildings here in downtown Seattle and if you look at a lot of the buildings we see that it seems like the construction of the building over half of the time is spent before the building even starts to rise up into the sky a huge portion of the time is spent building a really strong solid foundation for those buildings so we want you to really think about well architect it in that same way if you want to have all of the technologies that you use to provide business value be stable be strong the things that design are designed to give the business value they want them to give the best way to do that is by building a good foundation so those five pillars and while architected are designed to help you build a strong foundation for all of your workload and to identify any issues through that consistent measurement and help to reduce or mitigate those so that you can have that strong foundation in your technology portfolio so as I mentioned before there are three major components within the well architected framework so our first one here is the general design principles and the pillar specific design principles so if we take a look at some general principles for example one of the general design principles is automate responses to security events and we think about this as something that's different in the cloud that it may have been in on-premise environments you know in a traditional IT environment you may have the one person that responds to that alarm that goes off and that one security engineer is going to jump in it's going to do as necessary and respond to and perceive security incidents and help to mitigate that risk there are some problems with that though because having that one person when they're woken up at 2:00 a.m. it puts a lot of stress and load on them it also means they're responding at 2:00 a.m. and may not be the clearest and almost because it's an a person doing the response sometimes manual effort means that humans are prone to err especially at 2:00 a.m. and there's a potential that they're not going to have the best response where the responses will vary across your environment so we think about the design principle of automating responses it means you will have a consistent and automated response that helps to ease a lot of those burdens that's one of the benefits you can get from the cloud so there are other design principles and we can talk about them later they're also available in the framework so we highly encourage you to take a look at those good overarching principles there are also those individual design principles that are part of each one of the pillars so each of the five pillars also begins with design principles that are overarching for that concept that we think you should take advantage of so let's then talk about the next component within the well architected framework and it's the questions so it's mentioned the beginning this is all about asking the question are you well architected so in order to do that it all Beit is based on this question framework so the questions here we have one of the questions from the reliability pillar and if we look at the general structure of the question it starts with the area that it comes from so all of the pillars are broken up into areas this particular question is from the failure management area of the reliability pillar and we begin with a question so the question is how is your system designed to withstand component failures now below that question then we have some context the context is designed to give you a brief understanding of how does that relate to you and how would you think about that in your environment and against your workloads now underneath that we then have the list of all of the best practices that we have seen other customers be successful with so these are some examples that we highly encourage you to consider implementing in your environments as mentioned before these are the best practices that we have found from working with customers over the tens of thousands of reviews that we have actually done with customers since 2012 when we started the well architected framework now if you're using all of these it's going to actually help you look at looking at each of these questions to learn what our best practices are as you see listed here the best practices to measure yourself against those best practices and then to make improvements in your architecture by addressing or mitigating the risks that are identified here over time so what all else is available within the well architected framework well really the while architected framework is basically broken down into three major areas and those are content the well architected tool and then the data that is derived from those and we'll talk about how each of those can be used as a different use case for the well architected framework so if you look at the content this is really where it began so the content includes things like the framework with the design principles the individual pillar frameworks that have different design principles for each pillar as well as all the questions and best practices even if you decide not to use well architected tool you should note that the framework is where it started and all of the questions and best practices are actually available in the well architected framework white papers that are available online you will also see there's a lot of other helpful resources including we have the entire well architected tool content is also available on an external website so you can see all the material that's in the tool externally if you would like and then we do have the tool as well so the tool is designed to allow you to have a self-service or guided by AWS to support walking you through the well architected tool questions so that tool and the content combined are really designed to give you data that's kind of the end goal we're trying to get here so that data allows you to get documentation about your workloads to see your entire technology portfolio to understand things like the description the regions which of those five pillars is the highest priority for a particular workload and then allow you to do reviews and aggregate things around what risks have been identified for those workloads so there's a lot of resources that become available since 2012 now and the well architected framework we're gonna talk through some of those and how you could use them so before we go any further we're gonna jump over here and do a quick poll so we'll bring up the poll for you as the poll comes up we'll just talk through the options here so my question before I actually jump into the demo and walk you through the well architected tool is have you ever used it before so if you've used it at a is no you have never used it before B is yes but you haven't actually completed an entire review all 46 questions across those five different pillars yes you have completed one review or yes and you completed more than five reviews which is great so we're looking to have that poll fill in about how much longer should we wait for that the poll okay all right and as everyone is filling out that poll I'll tell you what we have coming up next in a second here I am going to switch over and actually give you the virtual workshop portion of today's session we're going to do a walk-through of the tool using a lab that's actually available externally so I'll get you all set up for that give you a few more seconds here to answer the poll question all right so I'm going to jump out of my presentation now and we will be switching over to show you the well architected tool so what I have here actually is the well architected labs we're going to talk a little bit more about the other lab content that's available but I'm gonna begin by starting with the level 100 walkthrough the well architected tool so this lab that I'm showing you here is what we're going to cover in today's workshop content so if you would like in the sessions there should be a shortened link that you can click on that will take you to this lab you can also just go to well architected labs comm and this will give you access to this lab these labs all are open sourced so there are labs actually for all five of the pillars we'll talk about in a little bit but for today's workshop we're gonna walk through this lab together so if you'd like to follow along you're more than welcome to go here so what I'm doing is to do the lab we're actually going to do this in the console together so I'll give everyone a moment if you didn't see this give you a few seconds here if you have an AWS account please log into the AWS account you need to have an account that has permissions to use the well architected tool and we're gonna walk through using well architected so I'll give everyone about 15 20 seconds here to do that as well if you vlogging in the console and you want to follow the law along in the lab you're welcome to do that too alright so I'm here in the AWS management console there are a lot of different ways to get to the resources in the console so I'll show you some of them you will note because I have been to the well architected tool in the past in this console it shows at the top you also are able to just type in well architected you'll see the tool shows up there as well if you want in all services the while architected tool is a part of the management and governance group on the website so if you want to scroll to management and governance you can get to well architected tool through here so I'm going to click to take me to the well architected tool a couple of key things about the tool is begin walking through it first off you'll see that the well architected tool is available in several regions the reason that we do this is if there is information that you believe to be sensitive that you want to store in the notes for the tool you have the ability to store it in regions that are compliant with whatever your compliance needs are so these are the different regions that are currently offered and will continue to expand in this case as I mentioned before I'm in Seattle so I'm going to choose my closest region uswest - which is Oregon and I'm going to go to the well architected tool page and actually define a workload so let's start with defining a workload I'd mentioned before what a workload is so a workload is something that we allow you as the customer to elect the definition of that but we want you to start from thinking about a group of systems and services that you use together to provide business value so for some customers it may be a small micro service within a larger architecture for some customers it may be multiple services put together that perform that whatever is necessary to produce a particular product for some it may be a set of products that all work together to provide a particular set of features or services we leave it up to you as the customer to decide how you would like to do that but to start with into finding a workload I have to give it a name so I'm going to call this the virtual workshop workload we do want you to give it a good description in this case I think my description is fairly self-explanatory as we'll talk about later we highly recommend that you use the well architected tool throughout the lifecycle including doing it as early as possible so I'm gonna say that I'm in a pre-production environment you will also notice that the way that the well architected tool is set up it is designed around best practices that really are not just specific to AWS so you can if you would like for documentation purposes choose the regions Orion so I may choose US West Oregon you can see that Oregon has now been selected but if you want you also have the ability to run the tool against environments that are not in AWS so you can look at architectures that span AWS even other cloud providers or your on-premise environment lastly you do have the option to put in an account ID now the sections here at the bottom these are optional as well if you want to classify because you have maybe multiple workloads you'll be aggregating you do have the ability to choose an industry and Industry type if you would like those are optional but not required but they do allow you to group and categorize when it comes to searching especially if you have your entire technology portfolio those can be very useful so I'm not gonna choose to find workload you can see now I have my workload to find now once the workload is defined we have a lot of options here we'll walk through what each of these screens does for you but I'm actually just gonna jump in and start my review now my screen is kind of zoomed in here so I'll zoom out to show you what I have over here on the left hand side you can see that it shows me my five pillars and the number of questions that I have answered from each one of the pillars for those of you that are following on the lab guide you will see that Rodney who is the reliability lead for a while architected in the lab goes through the reliability pillar I'm actually going to go through operational excellence because I am from the cloud operations team I'm also one of the people that helped to author the operational excellence pillar but you're welcome to follow along in the lab if you would like to do the reliability pillar so as i zoom in a little bit more let's talk through the components that we see here on the screen so on the screen as we mentioned before we have the question how do you determine what your priorities are I have the ability to get some more information on it also at the bottom I have the overall context that helps you to understand what do we mean by this question you will note then underneath that you can select which of the best this is apply to the workload that you are doing a review against for each one of those best practices you'll note there's an info link that info link actually takes you over here to the sidebar we have additional resources so for evaluate external customer needs as an example you can see that this gives me more detail about what do we mean when we say evaluating external customer needs and more importantly as I mentioned all of the content for well architected is available in an external website as well so part of that includes a bunch of definitions for terminology so in this case definitions for what operations means these links will actually take you to the external site so if you want to dive in more and understand what we mean with certain words you may not be familiar with you can click on them in order to see that so for each one of these best practices around the question you would select whether or not you believe you're following those best practices you will notice we have an option at the very bottom that is a none of these options so you may note looking at this you know either I myself I'm not able to answer those because I need another team to give me the answer or alternatively it may be you just recognize those are all weaknesses or areas that you would like to do improvement so you can mark none of these it will automatically deselect all of them alternatively if you're not sure you cannot use none of these and instead not check any of them so that you know you need to come back to that question to answer it in the future as well at the top for some of the questions you may determine for a specific workload certain things don't really apply to that workload so if you don't want to be see risks come up associated to that workload because you know that is not something that matters so perhaps you have questions when we get further down into well architected about how you are using Direct Connect or monitoring VPN connections maybe that's not applicable because you're not using those you have the option to say that that question does not apply to your workload and you won't see any risks associated with the workload show up around that question so lastly what we believe really is the most important part of what architected beyond those best practices is your ability to document where you're at so you have this note section at the bottom while it is optional we highly recommend we're going to talk more about best practices around well architected but we highly recommend that you consider taking really good thorough notes this is an opportunity to really document you workload and how you are performing against the well architected best practices for that workload so if I check these checkboxes we'll give you an example of what this will look like so I'll check a couple of checkboxes and I choose next takes me to the next question the same thing again I can check the checkboxes for what I'm doing choose next again we recommend you not make this a checkbox exercise but much more focus on driving discussion but I'm gonna check some of these just so you can get an idea of what our output looks like so I'll maybe pick one where I say it doesn't apply because perhaps I don't have the answers to this when it comes to deployment medication there's a different team that manages that and they'll be reviewing it so I'm gonna going that far to save and exit so this takes me back out to the actual workload review that I've started for my virtual workshop now you see that until advanced all 46 questions I have the option to continue the review but let's talk through a few of the other really important components that are available here so you can see that so far I have answered four of the 46 questions you will note that I don't currently have any high risk items but I do have some media's medium risk items I want to demonstrate what happens say for example that I out here let's say that I go down here to understanding the health of my workload and understanding the health of my workload I say that you know I'm really only identifying KPIs and have workload metrics but across the board and everything else I'm not doing as well as I know I should be so if I choose save and exit at that point go back to the review you'll now see that I have an area where I'm not doing very well and has identified that as a high risk so now with the questions that are answered five out of the 46 one of them is a high risk and three of them are medium risk so what do I do with this information and how does that help me so you can see here that I'm gonna get a list of what the risks are that I should be addressing in order you'll see at the bottom I can see the questions that are answered and the risks per pillar but if we go up here to the top to the improvement plan the improvement plan allows us to see what we should do to actually start working on this now you know I can track the status of my improvement so if I want to be able to see for my entire technology portfolio all of the reviews that I'm doing I can set the status on each of those reviews and whether or not I've started working on them is it not started in progress complete or have I just acknowledged I know there's a risk there but it's not something I can put into my backlog of work to mitigate right now now you also notice that you have this Improvement Plan configuration currently for this review security reliability operational excellence performance and cost is my order of priority by pillar if you choose though you can go into edit and either using the arrows to move up and down or in this case as I mentioned I'm doing this around operational excellence so to me that's the most important I can move that to the highest priority and I save that and now in my improvement plan I put operational excellence as the highest priority for me on this workload you notice you also can go through the improvement items and you can filter them by risk or by pillar so if there are areas of improvement needed you'll see in my improvement plan when I said how do you understand how your workload I didn't select the necessary things to really move me out of this being a high-risk area so you'll see in the improvement plan it gives me a list of links that can take me to more materials and resources that I can use to make Mitte to do either reduction of risk or risk mitigation against those findings so that's how the improvement plan works and you'll see for every one of the items where there is either a high or medium risk identified you'll have an improvement plan that incorporates a lot of information that you can use to start making progress on reducing or mitigating that risk so we'll also see that something that's very important as I mentioned we do not think that you should use well architected it's just a point in time rather it's designed to help you make improvements over time so to make improvements over time one important way to do that is the functionality that we have here called milestones so with milestones if I know that this is my initial review I can save this as a milestone so I'm going to choose save milestone and I'm gonna call this my initial review so the market is initial review and I choose save so what did I actually do by saving that milestone well now when I go to my milestones tab you'll see I have a milestone list it says that I've answered five of 46 I have one high risk and one medium risk issue if I go and do an effort to reduce or mitigate those risks by following the improvement plan that's established and well architected or by working with a my solutions architect or account team or working with a partner and I've reduced those risks I can then over time come back to the review and I can continue it so when I jump back into the review what if I know on that particular question about understand my workload health I've actually done things that are necessary and now I collect and analyze workload metrics I have my metrics baselines I have the ability to look at patterns of activity and I have alert setup for both when my outcomes are at risk and also for when I have detected anomalies so I've established a lot of good monitoring practices around understanding my workload health and I could say that I have implemented better monitoring so I now choose save and exit I'm gonna make this as another milestone so I've made changes so this milestone is better monitoring so I saved that milestone now I go back to my milestones tab you'll see that in milestones I have two milestones so for this one notice I no longer have any high-risk this actually marked it as no high-risk and only for medium risks where as initial review add one high risk and three medium risk by using milestones we have the ability to see overtime improvements that are being made on our workloads so it allows you to see if you're making improvements and in fact allows you to go back so for example if I pick my initial review I can choose to view that milestone by clicking on it or choosing the view milestone button and now I see that snapshot of before I'd made the changes or improvements in fact I can go in and I can view the review and when I view the review it'll actually let me see you'll note that I can't make changes because it's a milestone so the milestone is now set as a point in time but I can see where I was and I can go back to understanding the health of my workload I've made changes and I made additions and notes so that's the way that we can actually use the milestones capability to actually track and see improvements that we're making over time alright so back in my milestones I can also jump into the current milestone and I'm able to generate a report from that so you can generate a report from any milestone or generate a report from the current state of any of the well architected reviews so when I choose to generate report what generate report is doing is taking this content and putting it into a PDF and it's gonna allow me to take that and export it and send it to other people or to archive it and track it over time if I would like so we'll take all of the content as well as the links to the different things that we recommend that you do in terms of improvement so those the improvement plans that have been established those are all be generated and put into that report so that should cover all of the basic information about using the well architected tool just to give you a quick review of the well architected tool this is a lot of us to set up a new workload get the details of what it looks like when we performed a workload to see risks that we should address get an overview of what content we've answered allows us to see improvement plans for questions that we've answered so far we've been able to create milestones and track those improvements over time using the milestones and then if I go back to my workloads page you'll also see I can see a list of all the workflows for a particular region aggregated together and if I use the dashboard if I had multiple workloads I would actually be able to see each one of the workloads listed here together and see what while milestones or risks have been done by selecting it you can see gives me a high-level overview of what milestones I have for any workloads that's in that master list all right so that concludes the overview of the well architected tool that we had for today so there is your virtual workshop on well architected tool what we're going to do now is we're going to switch back to the presentation and give you a little bit more information on what else is available in the well architected framework to help you so we're going to start by actually talking about how to apply well architected so now we have a tool you know that you can use the tool you've gotten a good basic overview of the tool but let's actually figure out what are some ways that well architect it can help you know that they have a tool and you know where the resources and content are how can you use that to make some improvements so the first thing that's most important as I mentioned before I want to dive into this little deeper so what is the purpose or the intent of doing a review there's a couple key things to think about most importantly we don't want reviews to be thought of as an so this is not something where it's exhaustive and we want you to get a pass or fail fail mark on this rather reviews are very much designed to be discussion driven approach to dive into your architectures and understand what your risks are so the important thing to think about is when you're doing this it should be a blame free conversation this is not about pointing out what's being done wrong and it's definitely not about getting a red yellow or green score it's about understanding what the best practices are learning from them and being able to measure whether or not you're aligned to those best practices now once you've done that thinking about those best practices we really want you to think about those best practices as being very pragmatic and proven advice so imagine here it's not architecture astronauts what I mean is this is not theoretical so we're not giving you a list of theoretical best practices that are some perfect future state that no one can attain rather remember these best practices have been learned from our customers so if you know much about well the AWS approach to when it comes to designing our services we design 90 to 95% of our features based on what the customer is asked for what our customers want so the same thing is very much true when it comes to well architected those best practices are what we have gotten from learning from our customers our customers have driven us to understand what's actually working for them so when you see those best practices they are proven based upon we've seen customers actually doing another thing that's really important to think about when it comes to using well architected is it shouldn't be a point in time or a one-time-only check set it forget it and you're done rather we want you to think about using the well architected tool and the well architected framework as something that you do throughout the lifecycle of your applications and your technology portfolio so you should do this not only before you while you're designing a workload or something that you do before it goes into production but you should also continuously do that because as we've learned while AWS is continuously improving launching new features new services and new capabilities for our customers it also means customers and AWS are finding new best practices for operating in the cloud all the time we're going to continue to add those so there's something you should consider not just as your workloads change but also as there's new things available in AWS how could running while architected again benefit you so that's another thing to think about when it comes to the intent of the you so we know that choice is very important so how can you actually do a review well there's really three different choices that you have for doing a review now the first is since we last year reinvent we're able to launch the well architected tool in the console for you you do have the ability now to do review self-service and if you did that with your team we highly suggest that you have both your technical leads as well as the business leadership because we really want to make sure that there's an alignment between what the business needs are of your workloads and the teams that are supporting that so as a technical team your business needs you can sit down with the well architected tool and do the review on your own as a self service exercise using your console also you can do it with a partner so we have the APN network a lot of 80 of us partners and in that partner network you can find partners that are trained to use well architected and can sit down and do the engagement with you again most often doing it in the console where you walk through with the the partner in your own console and have discussions about the questions and best practices and well architected then lastly we also have the opportunity to do this with solutions architects so if you have an account team and you have a Solutions Architect that you can get engaged with you can have your solutions architect or if you have our enterprise support you have a Technical Account Manager your tam can also help you out with doing these well architected reviews so you can't have AWS come in and do it now thinking about those reviewed choices the next important question is all right which one should I use and what's the benefit of each so let's have a brief discussion about the benefits so the benefits of doing it self-service is that you really have full control you can choose how often you're going to do it when you're gonna do it how much content you're gonna cover we have recognized there are 46 questions there can be a lot of depth of discussion sometimes you may only want to do a few questions or maybe one pillar at a time by doing self-service and lets you choose how and when the best time is in order to do the review more importantly if you're going to do the review across a really wide array of workloads maybe you want to cover your entire technology portfolio it's really important that you have the control to do that so that you can choose when those different products are going to go through the review process and you don't have to work with a partner or a Solutions Architect every time you do it there's a lot of benefit from that and we'd highly recommend you consider it becoming a regular part of your team's approach now the benefit to having a partner do it is that often once you've gone through the review you may recognize that you don't necessarily have the skills expertise or time necessary to apply the necessary remediations to either reduce or mitigate the risks that are identified so if you need assistance where you can actually have someone come in that has skilled resources that can help to solve for those risks that have been identified you can bring in a partner and they can really help you with addressing those risks now lastly we have the AWS solutions architects or anyone else in your account team that has been trained to deliver these now there's a lot of benefit to having the skilled resources of an AWS solutions architect as the Solutions Architect team has done tens of thousands of these since 2012 however as is recognized many of you may not have direct access to a Solutions Architect or it may be difficult to have an SI go through all of the workloads that you want to do because you have such a wide array of things in your technology portfolio so for that reason we highly recommend that you consider when you're going to do it with an SI or with your account team think about doing it against your most critical workloads another way a lot of customers tend to approach this is when they're doing their first review they're gonna bring in a Solutions Architect to help them understand how to do it treated essentially as a well connected workshop train-the-trainer so to speak we're gonna teach you how to use the tool effectively so that the people on your teams can then go out and do that again with all of their own individual workloads the other thing is by having someone that has a lot of experience with well architected like solutions architects do it's going to have really good guided advice on how to implement that improvement plan and how to prioritize the improvements that you need to make so let's talk about the partner - well architected reviews and what you get out of having the partner well architect that reviews done so engaging with a well architected partner is great because it you for most of our partners actually and allows you to get a free review from them so the well architected partners are able to give you a review for free now what comes out of that review is usually a statement of work about how to address any of the risks are identified are they gonna help you make improvements so usually what the partners gonna do is the review for free and then come back to tell you how they can help you make the implementation of the risk you know regressing risk through implementing new features new capabilities reducing or mitigating risks that have been identified now we recognize though that for a lot of you having a partner come in and do that means there is a cost involved in that so one of the things that AWS does because we really want to see you succeed in reducing or mitigating those risks is if you have one of the partners come in and do the review and have an approved statement of work if you begin to work on that approve statement of work within 30 days of the review being done will actually give you a $5,000 credit toward your AWS usage in order to help defray some of the costs involved in reducing or mitigating those risks so that's again one of the benefits of having a partner while architected review done and that's what it looks like now there are a wide range of partners that are available to assist you you can see I have it here on the screen as well if you just go to the well architected page on the while architected page you can see a list of the partners that are available we have many partners in several different regions so if you like you can reach out to one of these partners and they can help you to get set up to guide you through a review as well as I mentioned we really think about well architected as something we want to continuously improve and adapt based on what best practices are as they develop over time so we want to constantly be able to offer you up-to-date best practices around cloud architecture and cloud operations so that said what have we learned since 2012 in this launched you've seen there's a lot of new things that have come out of the well architected framework but what have we learned since we launched so the first thing is we've recognized that really it's not about just doing it before launch now we do see something that's very important launching going in and using well architected as a review tool before you do a launch so we consider it an operational readiness review is a really good thing but the reality is the earlier in the design phase that you can do architected the more benefit that are going to see so really earlier is better that's the biggest thing that we've seen now when we say earlier is better that may mean doing it during the design phase so when you're sitting down you have the first designs for a new workload or a new feature you go in and use well architected this you're following best practices it may also mean that it's something that you're going to do as a part of the operational readiness review before you launch into production and it may be that you're actually going to use well architected as a regular or repeat process done on a annual or more frequent basis against existing workloads to determine if those workloads continue to use best practices something else is really important we've learned is that it's usually not identifying where people have made bad decisions so we're saying is it's not really about making bad decisions rather in very complex systems with most modern systems tend to be these days in complex systems is often really about the decision that wasn't made so for example most people don't choose I don't want to back up so I'm not going to have a back-up plan what really tends to happen is in the complexity of an environment and getting it up and running it's because someone didn't think about oh yeah I need to figure out backups for my environment so it's usually the decision is made because of a lack of awareness of what should be done so the benefit of using well architect and thing we've learned is for customers you really shouldn't think about the well architected is just being a list of all of the things that you have done wrong rather think about all the things you should be thinking about when it comes to a workload and that really then comes down to this final learning is findings we really do not think of findings as mistakes are things that are people are doing wrong at findings should not be considered something that's bad because the reality is the findings are actually exposing something that you may not have been aware of so findings should be treated as opportunities for improvement the findings the reality is looking at the thousands of reviews we've done it is very very rare that any workload is going to have zero improvement opportunities there's almost always an area our opportunity to improve workload so what we've really learned is you should think about the findings and well architected is how you can focus and prioritize improvements and expose risks you may not have been aware of so that's really the way to think about it now what are some of the use cases that we've seen around well architected so let's talk through some really common use cases so the first thing is most customers are using well architected to learn about cloud best practices that in fact why we release the well architected framework as a public available dock why we built the well architected tool so that customers could see it and in fact why the well architected tool is backed up by a wealth of information in the external website for well architected so when it comes to learning best practices for the cloud by architects is a great way to do that also we see customers are using it for technology governance so the governance being a way to tell am i doing the right things and are people following best practices and then lastly we're also seeing customers now adopt a method to actually manage their portfolio and understand risk across their technology portfolio so let's talk about how each of these use cases works and how well architected can help you with them so when it comes to learning cloud best practices these are some of the questions that we tend to hear that really mean you could use while architected as a way to learn about cloud best practices if you're asking well how do I architect or how do I operate in the cloud or what's different about the cloud if you are you know thinking that maybe some of your design is really it's being constrained based upon principles of an on-premise environment or an older IT solution and you wanna have some that's really designed to be cloud native many times there's so many resources and the question is just where do I start how do I know what this what what best practices or architecture should look like or if you're worried am i doing this right what are my wrists have I done something wrong on my architecture those are the kinds of questions that usually mean you want to learn about what the best practices are for architecting and operating in the cloud so if you want to learn those best practices gonna learn those best practices one second apologize for it so if you want to learn about those best practices some some things to think about is how are you gonna transition to being an older on Prem infrastructure to being cloud native and cloud native means how are you gonna take advantage of the automation and the infrastructure is code or even operations is code that are available in the cloud or more importantly how are you going to take advantage of things that are different in the cloud for example cost in an on-prem IT environment cost is very much something that tends to be done around capital expenditures or as you move the cloud it's more like a utility and something that we're you're paying for it on-demand is use it are you making sure that you're thinking in a cloud native way about that also we provide for you is some sign posting and resources so it's not just hey here's what you should do but if you need to do it here's some resources they're going to help you learn what's available to help you do that now obviously we do start with a lot of the AWS services and capabilities that are available to do that we also talk about other solutions that we've seen customers develop so it'll help you understand what AWS services and capabilities are useful in trying to reduce or mitigate or make improvements that have been identified so when it comes to identifying those improvements then the other thing that we want to customers to get is the ability to inform future architectures so we want you to learn over time and as you're building your next generation of architecture you should be able to learn the best practices and apply those as you continue to implement new new workloads or resources in the cloud now moving on what about technology governance so what are some of the questions that we see driving the use of well architected to help with technology governments so first thing is operational readiness one of the best reasons to do an operational readiness review is if you identify risks or you're aware of the risks and can make an informed decision before you put a new product or new feature into production it's very useful at reducing the amount of downtime or impact or cost you may not be aware of so a lot of times when customers want to say hey you know how do I check to make sure that I'm really ready for production on a workload that's a really great example of how well architected can be used for technology governance also a lot of times leadership wants to know are the teams that I work with are they following best practices and if they are following them how do I know are they measuring whether or not they're doing that consistently another thing to think about is how are they ensuring that they're going to be able to I did take those risks that have been identified and actually burn them down are we addressing them are we allocating time to make the necessary improvements to reduce the risks we've identified in order to make our workloads better over time so when it comes to technology governance if you really think about those five five different pillars of well architected this is the way that well architected can help solve for some of your technology governance needs so across those five different pillars the five different categories it's going give you a mechanism to consistently review your all the workloads in your technology portfolio to understand do they meet the best practices and do I understand the risks it's gonna make sure that it's done consistently across those five pillars and also it's going to make sure that you have a mechanism to do this across everything in your technology portfolio so let's move on then to talk about how customers are using well architected for portfolio management now we know that quite often especially in really large organizations your technology portfolio may be really vast there may be a lot of different things in that technology portfolio so if there's so many different things in that portfolio it's very rare that you have an inventory of all of the workloads and all of the resources that are in that portfolio so we've seen customers starting to use well architected and the tool as a mechanism to really manage our portfolio if they don't know what the inventory of their workloads is if they're not sure how those workloads are set up or what decisions around risks and going to production were made if they don't know if those risks have changed over time if they don't know where to invest resources and trying to make improvements and to solve for challenges that are helping or maybe preventing them from achieving the kind of business value that they want and are there trends that need to be addressed holistically there's another really big value and having all of the well architected work those put together often you can find something where you know it seems like consistently we have this same risk that's coming up over and over again maybe it means I need better training maybe I need to create a reusable pattern that all of the technologies that I'm using can learn from so that we don't have that same risk continue to happen that really is an example that if that last thing is there a way to build a mechanism so that I can do this have a continuous repeatable process that's consistent so that's the way we see a lot of customers actually using the well architected tool and the framework to do portfolio management so if you really think about it we've kind of change the picture here so if you need to manage that technology portfolio this allows you to take every work that you have and document across all five of those pillars how are the workloads established what risks have been identified how often have they been reviewed what's the remediation of those what's the improvement that's been made to those over time so that's really how the architected and framework can be useful to helping you do portfolio management alright so with all of that said we're gonna take a quick break here now and we're gonna jump over to a poll again so the poll should be coming up for all of you I'll read through the poll questions here and then give you a 30 or 45 seconds to answer it but now that you've learned about this so we talked through the well architected framework and the well architected tool giving you a good virtual workshop demo of it so now that you've seen all this and you've seen what some of the use cases are from customers how likely are you to use the well architected tool so answer a if you're already using it which is great love to hear that if now that you've gotten this you think you're actually likely to use this out on some of your workloads or see if you really don't think that it fits your needs or use cases you're unlikely to use or D you're just not really sure at this point in time so you need to spend more time digging into it so give you a few seconds more to answer that [Music] all right give everybody about 15 more seconds here okay so what we're gonna do now is move on to our last section so we're now in the final piece of the presentation for today so after walking you through what the well architected framework is and the tool and how to use it think it's really important to point out a lot of the other resources that are available to help you when it comes to well architected so we're gonna start with some of the tips so we have tips to share honestly this is things that a lot of customers may just not have been aware of and I want to talk those through with you so within the well architected website I'm gonna see links to a lot of other resources not just the basics of the well architected tool or the white papers that are there but let's talk through those white papers one important thing is the white papers are available to download as PDF but they're also available as free Kindle books so there is a while architected framework white paper that covers the entire framework and the general design principles across all five pillars there's also an individual white paper for each one of the pillars so you can get a white paper across operational excellence the reliability security performance efficiency and cost optimization there are also lens white paper so I'll explain lenses here in a moment but we do now have lens white papers for service hyper Moore's compute and the Internet of Things workloads so we're looking for guidance that are specific to architecture on those workloads that's available as well we do also have training so the training is not just on the materials in the framework and the different pillars but also how to use how to perform the review process using things like we're doing today as well as using the best practices for using the well architected tool across your technology portfolio then lastly it's very important the well architected website is an externally available website it actually has all of the content and more in for all the things that you see in the well architected tool so it includes the glossary of terms we mentioned before so the links in while architected tool will take you up to that glossary of terms and help you understand what do we mean when we talk about things like operations or run books or play books so there's a lot of definitions in there as well as resources that help you to better understand how you could use those glossary terms we do also have the videos so as you saw in the well architected tool there's a short video snippet for each one of the questions to give you a brief introduction those videos are also available on the well architected website and more importantly we have a map of the current version of the well architect framework so the map is actually an interactive map that allow you to see all five of the pillars the different areas as I mentioned before there's a focus area that each of the pillars is broken into multiple focus areas and then within those focus areas I will allow you to see what the individual questions are inside of those and have links that take you to those questions within the website so as I mentioned we do have this framework the important thing to recognize about the framework is all of the questions and the best practices are available in the well architected framework white paper as well as in there each of the questions for each pillar are available in the well architected pillar framework white papers so I highly encourage you either by going to the website and pulling down those white papers or if you'd like you can get the free Kindles as well give me the opportunity to see a lot more information and we kind of expound on some of the ways that we've seen patterns that work really well so this is gonna allow you to see some patterns that are very useful when it comes to implementing these best practices so to give you some examples of what are the different services and capabilities that can help you to implement the best practices that we've referenced each one of those questions now each pillar white paper also has a lot more detail about the pillar so it'll dive into not only the different areas but within each one of the focus areas of the pillar it does include all the questions and the appendix at the end but will also tell you for each one of those areas how should you be thinking about that what is the what is the common way of thinking that maybe where some of the problems come from around that particular question or concept and then what are some of the ways you can think about implementing that best practice and what's a pattern that looks like now we also have all the lenses so each lens is a weave record again we've recognized that there are sometimes very specific architectural decisions need to be made depending on a specific type of technology use so in this case we do have them for service for HPC and for IOT so those three lens framework white papers actually cover not just the best practices but they all actually include some reference architectures that you can use to get an idea of what that best practice looks like when applied in an architectural ermand so definitely consider looking at those lenses if you are deciding to build a workload that is going to use serverless high performance compute or IOT now the other thing i mentioned before is there is a lot of free training material that's available so if you look at the AWS training site you will see that there is training around the actual well architected framework itself there's training for each one of the pillars and there is also training about how to do a well architected review and how to use the well architected tool then one more thing here to think about this is just a high-level overview of the well architected content website so the well architected content website includes a lot of different information included it definitely has all the information that you're gonna find in the well architected tools so if you don't want to just go into the tool you want to have a bigger review of all the content you can get that here mostly it helps you to start with a map so this is the map that I was referencing so there's a map that shows you each one of the five pillars and within those pillars each of the focus areas and then when each of those areas what are the questions that we ask and the map is interactive so you can use it to click and link your way through to things that you think are really of interest for you when it comes to understanding how to design architect and operate your workloads and then lastly as I mentioned there's also a lot of other additional resources available in that external site so it does have all the videos they give you the brief overview of the things that you should think about and what you should know and then within each of those you will see links to reference material includes you know blogs other white papers a whole lot of different content that you can use both to understand why those particular best practices matter and more importantly what is the next thing you should consider if you want to implement those best practices in your environment then as I mentioned and as I showed you a little bit earlier there is also the well architected labs so while architected labs are a bunch of open source lab material they are designed to allow you to understand some of these concepts and a much more hands-on way so beyond just the walkthrough of the tool that I walk did for you today what you're gonna see actually for you know this is our first part of a six part series so over the course of the next five series that we do you're going to be able to see information that's available in those labs done in a hands-on workshop format for you but those are also available for you if you have an account and you would like to spin up resources and test that out we have those open source labs available for you so you can see we've got the link popped up for you here so if you want to try some of this all hands-on and see what it looks like in a sample environment and have some basic patterns for how to implement these best practices that's why while architected Labs is there and will continue to build new labs and be publishing new lab material in there regularly so definitely take advantage of those free labs so the last thing that I'd like to do today is dive in a little bit deeper on the design principles so we're gonna do here in our last few minutes is I'm going to walk through at a high level what are the overarching general design principles behind the well architected framework and then we'll talk briefly about the design principles in that are specific to each one of the pillars or what's inside the individual pillars alright so first off the general design principles so these are our general design principles that we think apply to all of well architected so now that you're in if you're running workloads in the cloud things have changed the capacity is very different the cloud has virtually infinite capacities the ability to expand on demand as you need so you should stop guessing at your capacity needs you should really think about designing environments so that your capacity is something that either you understand or it can change on demand as it needs to so really the cloud gives the ability to change your capacity on demand start taking advantage of that the other thing about the cloud is because resources in the cloud are paid for an on demand basis you should be able to spin up systems that where you can test your production at scale so a lot of times we have a testing environment and you know a traditional on-prem it's very difficult or expensive to really test the full-scale environment when you have constrained resources with AWS because you can spend resources up and take them down very quickly if you want to be able to test your production environments at scale you can do that much more easily we also talked about automating and making your architectural experimentation easier so we talked about automation there's a lot of different ways to automate an AWS that includes thinking about infrastructure as code but we also think about things like doing your documentation as code or your operations is code the idea of doing things where and even the responses to events being automated so because everything can be treated as code it allows you to have things that are triggered or happen automatically rather than having to wake up an engineer at 2:00 in the morning when necessary and by doing that means you can experiment a lot more easily so another thing to think about is make sure your architectures are designed so their evolutionary what we mean by that is AWS is constantly evolving or consecrating new features new capabilities new services you should design your workload so that the architecture allows you to do that as well so there's a lot of different things that are better than that but consider making it so that you have the ability to change things out as new features services and capabilities become available well to allow you to reduce overhead and maybe get things to market a lot more quickly or to make it so you can provide a better business value and then the last thing is we talked about this idea of improving through game days so the idea behind a game day is that we want you to actually be able you can test production systems of scale you should also be able to test the environments and the people and processes that you use to manage those environments on a regular basis so if it's very easy to use code to rapidly deploy your environments and make them consistent with your production environment game days allow you to test that and determine if not only is the architecture and the system's working but are the people and processes themselves also capable of handling what your production environment needs are going to be so there's our general design principles so here's the design principles for the operational excellence pillar so the first as I mentioned is designing operations as code what we mean by that is there's a lot of activities that you do when an operation in an operating environment is up and running so the vast majority of your workload lifecycle is probably spent in operations not necessarily in design and architecture so if you're going to do things on an environment when it's up and running the best way to prevent human error is to put things in code so they can be executed and tested consistently so things like run books and play books down as code or even documentation as code make that much easier to do the next design principle then annotating your documentation that means consider treating your documentation as code and I don't mean necessarily self-documenting code but something as simple as putting information in your code about what version the documentation should be and making sure that you check against environment when changes are made to ensure the documentation is up-to-date one example of how code annotation can help you ensure that people operate in the environment have the necessary and correct information to operate effectively we also talked about the idea of making frequent small reversible change now this is not always easy this is probably one of the most difficult design principles this is a good example of why thinking about these things early as useful but a frequent small reversible change means that it's much easier to deploy more quickly if it's frequent small means that if there's a problem it's much easier to roll back the problem that happens during a deployment because you can easily identify what actually was the problem and the reversible is very important that we recognize that sometimes reversible is not always possible but if you have the ability to reverse a change easily that can make it so that it's easier to prevent downtime the other thing is things happen in operations all the time if you're making changes to your application or your code or your environment you should make sure that the operations procedures things like run books and play books that your operating personnel uses are kept up-to-date as that happens it will also talk about this anticipate failure now anticipate failure doesn't mean just think that everything's going to break all the time so the idea of anticipating failure isn't necessarily just expecting that things will break but rather knowing where the areas are that could break and what the impact would be and having plans and mitigation having the mitigations in place beforehand the last thing is yes sometimes things break when they do the worst thing that can happen is and if you're if you're out there in the audience who might sheepishly raise your hand to yourself have you ever had the same problem occur multiple times if the same problem keeps occurring it probably means something you need to learn from and keep from happening again so it's a very very important idea to learn from those failures and to find ways to improve over time to prevent them so best practices our design principles are overarching for security make sure you have a strong identity foundation so the most of the things that happen when it comes to security involve not having well-thought-out credentials and identity management there's a lot of identity management tools in AWS make sure that you think about those ahead of time traceability is important meaning being able to see every action that occurs and understand why and how that action was implemented and to verify whether or not it was supposed to occur curate all lairs there's another very important security concept in really modern complex systems it's not just about having encryption it's not just about having good I am it's about every layer of your architecture considering from the application through the infrastructure that supports it all of the people and processes that we working on that and all of the systems that are supporting that workload have you implemented good security best practices at all of those layers not just at your edge automation is a really important thing you'll see it cross well architected that's definitely a good design principle for security we don't want to have the 2:00 a.m. call where the engineers being your your security expert engineers being woken up to respond to a security incident automate all of those security best practices where possible definitely think about things like encryption encryption so protecting your data both wallets in transit and at rest as much as possible keep people away from the data now we mean by that is not at the best network as a network with no users rather what we mean is only give people access to the systems that present that with the data set that we need you don't want your your users or the people that are operating your environments to be directly acting on the data they should rather be working with systems that help them control the access they have appropriate access to that data the last thing is we talked before the general design principles of game days preparing for security incidents our security events is very definitely a good thing to do and it kind of follows that same idea as game days you should have game days where you test and you know if you have the people the processes and the technology in place to respond to security events so in reliability so reliability most importantly test recovery procedures so the greatest example of this is many of you would say sure I have a back-up plan and then the next question would be have you tested that backup plan if you haven't test that backup plan I'm sorry the answer is you don't actually have a back-up plan so most common the most common cause of failure when it comes to recovery is that they didn't test the recovery first again because you can do things at scale make sure and you can also automate consider having those recovery procedures tested and as much as possible also think about automation when it comes to recovering from failure if you know what your failure points are means you should also be able to build scripted responses to those so that your systems are able to recover automatically there's a lot of best practices that fall inside of that the other thing to think about is scaling horizontally so when it comes to reliability one of the best ways to do that and what AWS has a lot of services to help you do that or features and capabilities think about scaling out not necessarily scaling up so sometimes up is the only way that things work but out is usually a lot better so continuing to add more resources across your workload will help you to respond when there's potential reliability issues as mentioned going from that general design principles same thing here don't guess at capacity use use a lot of the service we have like auto scaling and others to make sure that your environments are able to scale in and out on demand as necessary and then again change is a requirement the only constant is change so in our environments especially as new services capabilities and features are released and also you want to provide new features new capabilities for your customers on a regular basis the only way that that happens consistently is through change so if you're going to do change automate and the changes makes it much easier both to make sure the changes are tested and working correctly but it also makes them easier to rollback and respond to so performance efficiency our best practices are democratize the advanced technologies what we mean by that is make it so that you have everybody has access to the best things so the problem is that you need to make sure the technology people are using is the right technology for the job so the old adage that when the only tool you have is a hammer everything starts looking like a nail we want to avoid that make sure that you're giving your your team's access to the right resources for the right job sign to remote to pair for help she's so chatty today mini apologies so the other thing is go global so you can go global in minutes when it comes to performance efficiency design your workload so they can scale out as much as necessary and if necessary scale out globally consider using service architectures the benefit of service architectures it really reduces the amount of work that you have to spend and then the other thing to think about when it comes to performance efficiency is you need to experiment much more often so experimenting offer often is really really important and the last thing is we talked about this idea of mechanical simple and sympathy so we tend to really force technologies to do what we need and then we hope they get the performance what we need we don't want to think about it that way rather think about using the right technology for the right thing instead of trying to bend the technology to your will alright and then across cost optimization our design principles definitely think about adopting a consumption model in other words think about the way you use AWS as being the utility how do you consume a utility think about the way that the AWS environment works and have a model for what your expectation see so there is the mantra that you can't manage what you don't measure so you definitely want to measure am I using my resources effectively and if you are then you have the ability to continue to improve that if you're not you can find the areas where you can make the biggest impact definitely stops and spending money on data center operations so there's a lot of benefits to the cloud don't treat the cloud as just another data center that's we're really trying to think about the cloud native capabilities always make sure that you're analyzing and attributing expenditures so know what things are costing and what is actually being used to get those costs am i delivering business value with those cost that's the thing to think about when it comes to analyzing and being able to know what's costing you and why and then the other thing is consider using manage services to reduce the cost of ownership so it's great if everything is you know designed so that you're running and managing all of it but a lot of times that management overhead it means that it's going to cost you a lot more to do it and a lot of our the services that are managed for you I mean it takes the operational overhead away and that's a lot of times a cost that's not thought about so what do you need to do now let's finish off with this how do we get started so in order to get started definitely go to the well architected site on the well architected site I've mentioned a whole lot of resources please consider spending the time to read through some of those online resources also if you have an account team or if you need help finding a partner reach out to a partner talk to your account team see if you can get assistance and the best way to start really is to just do a review jump into the console get a team together pick a workload and actually start doing a review of your first workload so that is everything that I have today thank you very much I believe what we're going to do now is actually jump over to the questions and answers so I'm now for a few more minutes to answer questions we have any questions all right so I'm looking through some of the questions that are there I will see if I can get access to all of them there is a questions being asked about the poll are the results from the poll available can those be shared yes okay so they will share the poll results I think another question that's come up a couple times is so what about things like trusted advisor or other third-party tools that are capable of doing some automated things so let's talk a little bit about well we're well architected actually fits along with those other resources like the electron supervisor and other other third-party tools you can put in an environment so we very much see that trusted advisor is a great tool for going and looking at again a pillar based approach and automatically identifying some of the best practices and how those best practices have been implemented or if they need to be implemented we see that while architect that actually very much works in concert or as a complement to the trusted advisor tool where well architected was very much designed to be a conversation driven approach so you'll also see if we start to look through while architected there's a lot of questions and I'll speak specifically to things like the operational excellence pillar we talk about things like how do you know you have enough trained keep personnel to meet the capabilities or requirements for a workload problem with that is very difficult to have an API call for that so if you think about a lot of the things that we end up doing with well architected we're trying to drive discussion above and beyond just the things that we've got now got these great automated tools to pull out of an environment all right so let's see all right okay fortunately I'm unable to see is anybody able to share what our poll results were I think they're being shared up on the screen all right let's see what other questions do we have many people I do apologize for Alexis chattiness today she definitely wanted to join in the conversation all right let's see am i as anyway are there any other questions not seeing any come up here I'll do that all right [Music] so someone did ask how I get here the last page this the all of this content will be available and published online so we'll make sure that you have access to it again that last page before thank you was about the well architected website so if you just go to aws.amazon.com and do a search for wall architected or AWS Amazon com /wel well architected it will bring up all the while architected content for you and everything we've talked about today is available through that so let's see try and dig through some more of the questions here so I see a question here was asked so how do you do documentation this code so to answer that we don't think about documentation as code necessarily as you know the magic of self-documenting code rather and we talk about documentation as code the idea would be embed the documentation about what is required to run or operate your workloads into the actual code base itself consider treating the documentation with the same level of discipline and rigor that you would code so you can check it into shared repos you can do code reviews on it annotating your documentation allows you to actually check and see does the documentation version that I have match in my code and in the documentation via things like run books and play books that my teams need to operate or support my workload and application so when we say documentation is code that's where really what we mean is put your documentation into the same format and same codebase as you do for your application code for your infrastructure as code maybe even for things like your operations this code run books and play books that answers that let's see so does the tool provide guidance for specific languages I believe that the website itself is regionalised so there are several languages available I'll have to check in and see what languages are available there but the website actually has a lot of different region is regionalised so it's going to be available in different languages I'm wondering if one of our logger tickets needs could share the status on that because I'm not actually sure so can we have an account with only access to the log detected tools that's actually thank you for asking that question the well architected tool does have two iam permissions that can be used or assigned to it those permissions are to give you read or write access so basically it's view or full access so that well architected view allows you to see the results of any well architected review in the account that you're referencing and the full gives you the ability to go in and make changes those the two that are available so if you did want to make this something where you had an account that you store these all in and people could only use it for a while architected you are capable of using I am rolls to do that right continue read through alright so there's a question that's asked so how does the wall architect the framework help with compliance thing frameworks like ISO 27001 so the there is actually I want everyone to be aware of this there is a compliant site that's available for AWS that lists the different features and services for compliance when we think about well architected when it comes to compliance really how it helps is that it's a tool that allows you to consistently review your workloads so if you think about like the operational excellence pillar there is a question where we specifically asked do you actually consider compliance requirements now that question to be clear isn't just about compliance around frameworks like you know ISO standards or around things like PCI compliance or whatever regional governance and compliance might need we're also thinking about compliance do you have internal security or governance teams that have standards you have to adhere to so thinking about compliance in the big picture the benefit of the well architected tool is that while architected is a central place where you can document whether or not you're following standards and using that open-ended text you would be able to for any workload or everything in your technology portfolio document and make it searchable or discoverable as to whether or not you're following a particular compliance framework in that workload all right continue to read great okay so there's question asked for those that are not working in a production environment just working on their own beginner level okay what is some thoughts on how to go about familiarizing yourself with the wall contracted tool apart from the reading so a couple things to consider one the well architected tool this is an important thing I want to mention well architected is available at no additional cost in the console so you don't incur any charges for using the well architected tool and create as many reviews as you want honestly one of the best ways to really learn about the tool besides the reading itself is to actually just go in and start using the tool the tool is a great way to kind of get a summary overview of the kind of questions that we think about so if you don't want to just do reading you want more of a hands-on exercise do you definitely consider doing that also if you look inside of the well architected framework whitepapers even though I apologize it is a lot of reading the well architected framework white papers do contain some sample examples of how you might implement these now if you don't want to be reading at all you're looking just to kind of test and learn the other really good resource to consider is that I mentioned before those well architected labs so the well architected labs will allow you to go into if you have a test AWS environment so you can sign up for a free to your account and if you go into that environment using the well architected labs it'll actually allow you to do hands-on exercises that walk you through what it would look like in a real-world environment inside of an AWS account to establish some of those best practices and to utilize them so you'll be able to see actually over the course of the next five weeks the next five sessions here what that actually looks like through the labs that will be demonstrated in those virtual workshops so the question asks how limited is the W a tool against other cloud providers so the reality is that the well architected tool has all of our aggregate AWS best practices but it doesn't actually reference any specific AWS service or feature in those questions it's actually designed around best practices in general so this is something that you there is no limit you can use it against and other cloud providers or even your on-prem environments if you want to it's really talking about what we've learned from AWS customers as best practices for cloud a lot of the remediation plans and things that are follow on the UI interview are we going to be very specific to AWS the tool itself is not just for AWS you can actually use it anywhere that you think would be worthwhile so is the W a tool is supposed to be used for design and assessment you can absolutely use it for doing design and for operational readiness reviews so we've seen customers do that as I mentioned earlier you use it the better so if you move it as far as you can into the design phase tend to get more value because it helps you to prevent or mitigate risk before you go to production it's definitely great as an operational readiness review tool to ensure that your can you know meeting the standards have been established we also recommend running it against current workloads to see maybe you have workloads that have been running for a while and they might need updates or changes made to them to implement new best practices that have been recognized so something that we think is good for design it's good for operational readiness review and it's also good to be run on current production workloads on a regular basis so there's a question I'm wondering about implications of using the tool to evaluate a workload in a region that doesn't have the tool available or the where there's geographical constraints on data for compliance reasons so things to consider again the way the tool works because it's not using API calls it's not it's designed to be discussion driven it doesn't have to be something where you're running it just against the resources in the region or the account that you're doing it so you can do that anywhere the key thing is think about the information that you're putting in about the workload if there are compliance requirements or restrictions or regulatory compliance restrictions if possible use a region that meets those compliance requirements or ensure that the content that you're putting in is something that is not going to require you to comply with those standards so so so keep in mind what kind of information you're putting in what you're doing that all right it looks like we are running down to the end of time here actually so with that we're going to be and in the episode thank you very much what are we going to do as far as a quick question as far as the rest of questions that are here is there another place for people to go to get questions answered any feedback okay so that you can continue to ask questions in the chat and we'll continue answer for them there but thank you all again very much for your time today so John steel-cut Operations Specialist and thank you very much for joining are you well architected [Music] you

Channel: AWS Online Tech Talks

Views: 16,926

Keywords: Well-Architected Tool, Architecture Best Practices, Well-Architected, AWS, Webinar, Cloud Computing, Amazon Web Services

Id: yb9CH3UbMbw

Length: 85min 31sec (5131 seconds)

Published: Mon Oct 14 2019