wellarchitected-framework.pdf

Framework AWS Well-Architected Framework Copyright © 2024 Amazon Web Services, Inc. and/or its aﬃliates. All rights reserved. AWS Well-Architected Framework Framework AWS Well-Architected Framework: Framework Copyright © 2024 Amazon Web Services, Inc. and/or its aﬃliates. All rights reserved. Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon. AWS Well-Architected Framework Framework Table of Contents Abstract and introduction............................................................................................................... 1 Introduction................................................................................................................................................... 1 Deﬁnitions...................................................................................................................................................... 2 On architecture............................................................................................................................................. 4 General design principles............................................................................................................................ 6 The pillars of the framework......................................................................................................... 8 Operational excellence................................................................................................................................ 8 Design principles..................................................................................................................................... 9 Deﬁnition................................................................................................................................................ 10 Best practices......................................................................................................................................... 11 Resources................................................................................................................................................ 20 Security......................................................................................................................................................... 20 Design principles................................................................................................................................... 21 Deﬁnition................................................................................................................................................ 21 Best practices......................................................................................................................................... 22 Resources................................................................................................................................................ 31 Reliability...................................................................................................................................................... 32 Design principles................................................................................................................................... 32 Deﬁnition................................................................................................................................................ 33 Best practices......................................................................................................................................... 34 Resources................................................................................................................................................ 39 Performance eﬃciency.............................................................................................................................. 39 Design principles................................................................................................................................... 40 Deﬁnition................................................................................................................................................ 40 Best practices......................................................................................................................................... 41 Resources................................................................................................................................................ 46 Cost optimization....................................................................................................................................... 46 Design principles................................................................................................................................... 47 Deﬁnition................................................................................................................................................ 48 Best practices......................................................................................................................................... 48 Resources................................................................................................................................................ 54 Sustainability............................................................................................................................................... 55 Design principles................................................................................................................................... 55 Deﬁnition................................................................................................................................................ 56 iii AWS Well-Architected Framework Framework Best practices......................................................................................................................................... 57 Resources................................................................................................................................................ 63 The review process........................................................................................................................ 64 Conclusion...................................................................................................................................... 66 Contributors................................................................................................................................... 67 Further reading.............................................................................................................................. 68 Document revisions....................................................................................................................... 69 Appendix: Questions and best practices...................................................................................... 72 Operational excellence............................................................................................................................ 72 Organization......................................................................................................................................... 72 Prepare................................................................................................................................................ 129 Operate............................................................................................................................................... 196 Evolve.................................................................................................................................................. 238 Security...................................................................................................................................................... 257 Security foundations.......................................................................................................................... 257 Identity and access management................................................................................................... 282 Detection.............................................................................................................................................. 336 Infrastructure protection................................................................................................................... 350 Data protection................................................................................................................................... 376 Incident response............................................................................................................................... 408 Application security............................................................................................................................ 431 Reliability................................................................................................................................................... 449 Foundations......................................................................................................................................... 450 Workload architecture....................................................................................................................... 488 Change management......................................................................................................................... 533 Failure management.......................................................................................................................... 573 Performance eﬃciency........................................................................................................................... 669 Architecture selection........................................................................................................................ 669 Compute and hardware.................................................................................................................... 684 Data management.............................................................................................................................. 702 Networking and content delivery................................................................................................... 726 Process and culture............................................................................................................................ 755 Cost optimization..................................................................................................................................... 772 Practice Cloud Financial Management........................................................................................... 772 Expenditure and usage awareness.................................................................................................. 795 Cost-eﬀective resources.................................................................................................................... 837 iv AWS Well-Architected Framework Framework Manage demand and supply resources......................................................................................... 878 Optimize over time............................................................................................................................ 890 Sustainability............................................................................................................................................. 898 Region selection.................................................................................................................................. 899 Alignment to demand....................................................................................................................... 901 Software and architecture................................................................................................................ 915 Data....................................................................................................................................................... 927 Hardware and services...................................................................................................................... 945 Process and culture............................................................................................................................ 955 Notices.......................................................................................................................................... 964 AWS Glossary............................................................................................................................... 965 v AWS Well-Architected Framework Framework AWS Well-Architected Framework Publication date: June 27, 2024 (Document revisions) The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while building systems on AWS. By using the Framework you will learn architectural best practices for designing and operating reliable, secure, eﬃcient, cost-eﬀective, and sustainable systems in the cloud. Introduction The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while building systems on AWS. Using the Framework helps you learn architectural best practices for designing and operating secure, reliable, eﬃcient, cost-eﬀective, and sustainable workloads in the AWS Cloud. It provides a way for you to consistently measure your architectures against best practices and identify areas for improvement. The process for reviewing an architecture is a constructive conversation about architectural decisions, and is not an audit mechanism. We believe that having well-architected systems greatly increases the likelihood of business success. AWS Solutions Architects have years of experience architecting solutions across a wide variety of business verticals and use cases. We have helped design and review thousands of customers’ architectures on AWS. From this experience, we have identiﬁed best practices and core strategies for architecting systems in the cloud. The AWS Well-Architected Framework documents a set of foundational questions that help you to understand if a speciﬁc architecture aligns well with cloud best practices. The framework provides a consistent approach to evaluating systems against the qualities you expect from modern cloud- based systems, and the remediation that would be required to achieve those qualities. As AWS continues to evolve, and we continue to learn more from working with our customers, we will continue to reﬁne the deﬁnition of well-architected. This framework is intended for those in technology roles, such as chief technology oﬃcers (CTOs), architects, developers, and operations team members. It describes AWS best practices and strategies to use when designing and operating a cloud workload, and provides links to further implementation details and architectural patterns. For more information, see the AWS Well- Architected homepage. Introduction 1 AWS Well-Architected Framework Framework AWS also provides a service for reviewing your workloads at no charge. The AWS Well-Architected Tool (AWS WA Tool) is a service in the cloud that provides a consistent process for you to review and measure your architecture using the AWS Well-Architected Framework. The AWS WA Tool provides recommendations for making your workloads more reliable, secure, eﬃcient, and cost- eﬀective. To help you apply best practices, we have created AWS Well-Architected Labs, which provides you with a repository of code and documentation to give you hands-on experience implementing best practices. We also have teamed up with select AWS Partner Network (APN) Partners, who are members of the AWS Well-Architected Partner program. These AWS Partners have deep AWS knowledge, and can help you review and improve your workloads. Deﬁnitions Every day, experts at AWS assist customers in architecting systems to take advantage of best practices in the cloud. We work with you on making architectural trade-oﬀs as your designs evolve. As you deploy these systems into live environments, we learn how well these systems perform and the consequences of those trade-oﬀs. Based on what we have learned, we have created the AWS Well-Architected Framework, which provides a consistent set of best practices for customers and partners to evaluate architectures, and provides a set of questions you can use to evaluate how well an architecture is aligned to AWS best practices. The AWS Well-Architected Framework is based on six pillars — operational excellence, security, reliability, performance eﬃciency, cost optimization, and sustainability. Table 1. The pillars of the AWS Well-Architected Framework Name Description Operational excellence The ability to support development and run workloads eﬀectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value. Security The security pillar describes how to take advantage of cloud technologies to protect Deﬁnitions 2 AWS Well-Architected Framework Framework Name Description data, systems, and assets in a way that can improve your security posture. Reliability The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle. This paper provides in-depth, best practice guidance for implementing reliable workloads on AWS. Performance eﬃciency The ability to use computing resources eﬃciently to meet system requirements, and to maintain that eﬃciency as demand changes and technologies evolve. Cost optimization The ability to run systems to deliver business value at the lowest price point. Sustainability The ability to continually improve sustainab ility impacts by reducing energy consumption and increasing eﬃciency across all component s of a workload by maximizing the beneﬁts from the provisioned resources and minimizin g the total resources required. In the AWS Well-Architected Framework, we use these terms: A component is the code, conﬁguration, and AWS Resources that together deliver against a requirement. A component is often the unit of technical ownership, and is decoupled from other components. The term workload is used to identify a set of components that together deliver business value. A workload is usually the level of detail that business and technology leaders communicate about. Deﬁnitions 3 AWS Well-Architected Framework Framework We think about architecture as being how components work together in a workload. How components communicate and interact is often the focus of architecture diagrams. Milestones mark key changes in your architecture as it evolves throughout the product lifecycle (design, implementation, testing, go live, and in production). Within an organization the technology portfolio is the collection of workloads that are required for the business to operate. The level of eﬀort is categorizing the amount of time, eﬀort, and complexity a task requires for implementation. Each organization needs to consider the size and expertise of the team and the complexity of the workload for additional context to properly categorize the level of eﬀort for the organization. High: The work might take multiple weeks or multiple months. This could be broken out into multiple stories, releases, and tasks. Medium: The work might take multiple days or multiple weeks. This could be broken out into multiple releases and tasks. Low: The work might take multiple hours or multiple days. This could be broken out into multiple tasks. When architecting workloads, you make trade-oﬀs between pillars based on your business context. These business decisions can drive your engineering priorities. You might optimize to improve sustainability impact and reduce cost at the expense of reliability in development environments, or, for mission-critical solutions, you might optimize reliability with increased costs and sustainability impact. In ecommerce solutions, performance can aﬀect revenue and customer propensity to buy. Security and operational excellence are generally not traded-oﬀ against the other pillars. On architecture In on-premises environments, customers often have a central team for technology architecture that acts as an overlay to other product or feature teams to verify they are following best practice. Technology architecture teams typically include a set of roles such as: Technical Architect (infrastructure), Solutions Architect (software), Data Architect, Networking Architect, and Security Architect. Often these teams use TOGAF or the Zachman Framework as part of an enterprise architecture capability. At AWS, we prefer to distribute capabilities into teams rather than having a centralized team with that capability. There are risks when you choose to distribute decision making authority, for On architecture 4 AWS Well-Architected Framework Framework example, verifying that teams are meeting internal standards. We mitigate these risks in two ways. First, we have practices (ways of doing things, process, standards, and accepted norms) that focus on allowing each team to have that capability, and we put in place experts who verify that teams raise the bar on the standards they need to meet. Second, we implement mechanisms that carry out automated checks to verify standards are being met. “Good intentions never work, you need good mechanisms to make anything happen” — Jeﬀ Bezos. This means replacing a human's best eﬀorts with mechanisms (often automated) that check for compliance with rules or process. This distributed approach is supported by the Amazon leadership principles, and establishes a culture across all roles that works back from the customer. Working backward is a fundamental part of our innovation process. We start with the customer and what they want, and let that deﬁne and guide our eﬀorts. Customer-obsessed teams build products in response to a customer need. For architecture, this means that we expect every team to have the capability to create architectures and to follow best practices. To help new teams gain these capabilities or existing teams to raise their bar, we activate access to a virtual community of principal engineers who can review their designs and help them understand what AWS best practices are. The principal engineering community works to make best practices visible and accessible. One way they do this, for example, is through lunchtime talks that focus on applying best practices to real examples. These talks are recorded and can be used as part of onboarding materials for new team members. AWS best practices emerge from our experience running thousands of systems at internet scale. We prefer to use data to deﬁne best practice, but we also use subject matter experts, like principal engineers, to set them. As principal engineers see new best practices emerge, they work as a community to verify that teams follow them. In time, these best practices are formalized into our internal review processes, and also into mechanisms that enforce compliance. The Well-Architected Framework is the customer-facing implementation of our internal review process, where we have codiﬁed our principal engineering thinking across ﬁeld roles, like Solutions Architecture and internal engineering teams. The Well-Architected Framework is a scalable mechanism that lets you take advantage of these learnings. By following the approach of a principal engineering community with distributed ownership of architecture, we believe that a Well-Architected enterprise architecture can emerge that is driven On architecture 5 AWS Well-Architected Framework Framework by customer need. Technology leaders (such as a CTOs or development managers), carrying out Well-Architected reviews across all your workloads will permit you to better understand the risks in your technology portfolio. Using this approach, you can identify themes across teams that your organization could address by mechanisms, training, or lunchtime talks where your principal engineers can share their thinking on speciﬁc areas with multiple teams. General design principles The Well-Architected Framework identiﬁes a set of general design principles to facilitate good design in the cloud: Stop guessing your capacity needs: If you make a poor capacity decision when deploying a workload, you might end up sitting on expensive idle resources or dealing with the performance implications of limited capacity. With cloud computing, these problems can go away. You can use as much or as little capacity as you need, and scale in and out automatically. Test systems at production scale: In the cloud, you can create a production-scale test environment on demand, complete your testing, and then decommission the resources. Because you only pay for the test environment when it's running, you can simulate your live environment for a fraction of the cost of testing on premises. Automate with architectural experimentation in mind: Automation permits you to create and replicate your workloads at low cost and avoid the expense of manual eﬀort. You can track changes to your automation, audit the impact, and revert to previous parameters when necessary. Consider evolutionary architectures: In a traditional environment, architectural decisions are often implemented as static, onetime events, with a few major versions of a system during its lifetime. As a business and its context continue to evolve, these initial decisions might hinder the system's ability to deliver changing business requirements. In the cloud, the capability to automate and test on demand lowers the risk of impact from design changes. This permits systems to evolve over time so that businesses can take advantage of innovations as a standard practice. Drive architectures using data: In the cloud, you can collect data on how your architectural choices aﬀect the behavior of your workload. This lets you make fact-based decisions on how to improve your workload. Your cloud infrastructure is code, so you can use that data to inform your architecture choices and improvements over time. Improve through game days: Test how your architecture and processes perform by regularly scheduling game days to simulate events in production. This will help you understand where General design principles 6 AWS Well-Architected Framework Framework improvements can be made and can help develop organizational experience in dealing with events. General design principles 7 AWS Well-Architected Framework Framework The pillars of the framework Creating a software system is a lot like constructing a building. If the foundation is not solid, structural problems can undermine the integrity and function of the building. When architecting technology solutions, if you neglect the six pillars of operational excellence, security, reliability, performance eﬃciency, cost optimization, and sustainability, it can become challenging to build a system that delivers on your expectations and requirements. Incorporating these pillars into your architecture will help you produce stable and eﬃcient systems. This will allow you to focus on the other aspects of design, such as functional requirements. Pillars Operational excellence Security Reliability Performance eﬃciency Cost optimization Sustainability Operational excellence The Operational Excellence pillar includes the ability to support development and run workloads eﬀectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value. The operational excellence pillar provides an overview of design principles, best practices, and questions. You can ﬁnd prescriptive guidance on implementation in the Operational Excellence Pillar whitepaper. Topics Design principles Deﬁnition Best practices Resources Operational excellence 8 AWS Well-Architected Framework Framework Design principles The following are design principles for operational excellence in the cloud: Organize teams around business outcomes: The ability of a team to achieve business outcomes comes from leadership vision, eﬀective operations, and a business-aligned operating model. Leadership should be fully invested and committed to a CloudOps transformation with a suitable cloud operating model that incentivizes teams to operate in the most eﬃcient way and meet business outcomes. The right operating model uses people, process, and technology capabilities to scale, optimize for productivity, and diﬀerentiate through agility, responsiveness, and adaptation. The organization's long-term vision is translated into goals that are communicated across the enterprise to stakeholders and consumers of your cloud services. Goals and operational KPIs are aligned at all levels. This practice sustains the long-term value derived from implementing the following design principles. Implement observability for actionable insights: Gain a comprehensive understanding of workload behavior, performance, reliability, cost, and health. Establish key performance indicators (KPIs) and leverage observability telemetry to make informed decisions and take prompt action when business outcomes are at risk. Proactively improve performance, reliability, and cost based on actionable observability data. Safely automate where possible: In the cloud, you can apply the same engineering discipline that you use for application code to your entire environment. You can deﬁne your entire workload and its operations (applications, infrastructure, conﬁguration, and procedures) as code, and update it. You can then automate your workload’s operations by initiating them in response to events. In the cloud, you can employ automation safety by conﬁguring guardrails, including rate control, error thresholds, and approvals. Through eﬀective automation, you can achieve consistent responses to events, limit human error, and reduce operator toil. Make frequent, small, reversible changes: Design workloads that are scalable and loosely coupled to permit components to be updated regularly. Automated deployment techniques together with smaller, incremental changes reduces the blast radius and allows for faster reversal when failures occur. This increases conﬁdence to deliver beneﬁcial changes to your workload while maintaining quality and adapting quickly to changes in market conditions. Reﬁne operations procedures frequently: As you evolve your workloads, evolve your operations appropriately. As you use operations procedures, look for opportunities to improve them. Hold regular reviews and validate that all procedures are eﬀective and that teams are familiar with them. Where gaps are identiﬁed, update procedures accordingly. Communicate procedural Design principles 9 AWS Well-Architected Framework Framework updates to all stakeholders and teams. Gamify your operations to share best practices and educate teams. Anticipate failure: Maximize operational success by driving failure scenarios to understand the workload’s risk proﬁle and its impact on your business outcomes. Test the eﬀectiveness of your procedures and your team’s response against these simulated failures. Make informed decisions to manage open risks that are identiﬁed by your testing. Learn from all operational events and metrics: Drive improvement through lessons learned from all operational events and failures. Share what is learned across teams and through the entire organization. Learnings should highlight data and anecdotes on how operations contribute to business outcomes. Use managed services: Reduce operational burden by using AWS managed services where possible. Build operational procedures around interactions with those services. Deﬁnition There are four best practice areas for operational excellence in the cloud: Organization Prepare Operate Evolve Your organization’s leadership deﬁnes business objectives. Your organization must understand requirements and priorities and use these to organize and conduct work to support the achievement of business outcomes. Your workload must emit the information necessary to support it. Implementing services to achieve integration, deployment, and delivery of your workload will create an increased ﬂow of beneﬁcial changes into production by automating repetitive processes. There may be risks inherent in the operation of your workload. Understand those risks and make an informed decision to enter production. Your teams must be able to support your workload. Business and operational metrics derived from desired business outcomes will permit you to understand the health of your workload, your operations activities, and respond to incidents. Your priorities will change as your business needs and business environment changes. Use these as a feedback loop to continually drive improvement for your organization and the operation of your workload. Deﬁnition 10 AWS Well-Architected Framework Framework Best practices Note All operational excellence questions have the OPS preﬁx as a shorthand for the pillar. Topics Organization Prepare Operate Evolve Organization Your teams must have a shared understanding of your entire workload, their role in it, and shared business goals to set the priorities that will achieve business success. Well-deﬁned priorities will maximize the beneﬁts of your eﬀorts. Evaluate internal and external customer needs involving key stakeholders, including business, development, and operations teams, to determine where to focus eﬀorts. Evaluating customer needs will verify that you have a thorough understanding of the support that is required to achieve business outcomes. Verify that you are aware of guidelines or obligations deﬁned by your organizational governance and external factors, such as regulatory compliance requirements and industry standards that may mandate or emphasize speciﬁc focus. Validate that you have mechanisms to identify changes to internal governance and external compliance requirements. If no requirements are identiﬁed, validate that you have applied due diligence to this determination. Review your priorities regularly so that they can be updated as needs change. Evaluate threats to the business (for example, business risk and liabilities, and information security threats) and maintain this information in a risk registry. Evaluate the impact of risks, and tradeoﬀs between competing interests or alternative approaches. For example, accelerating speed to market for new features may be emphasized over cost optimization, or you may choose a relational database for non-relational data to simplify the eﬀort to migrate a system without refactoring. Manage beneﬁts and risks to make informed decisions when determining where to focus eﬀorts. Some risks or choices may be acceptable for a time, it may be possible to mitigate associated risks, Best practices 11 AWS Well-Architected Framework Framework or it may become unacceptable to permit a risk to remain, in which case you will take action to address the risk. Your teams must understand their part in achieving business outcomes. Teams must understand their roles in the success of other teams, the role of other teams in their success, and have shared goals. Understanding responsibility, ownership, how decisions are made, and who has authority to make decisions will help focus eﬀorts and maximize the beneﬁts from your teams. The needs of a team will be shaped by the customer they support, their organization, the makeup of the team, and the characteristics of their workload. It's unreasonable to expect a single operating model to be able to support all teams and their workloads in your organization. Verify that there are identiﬁed owners for each application, workload, platform, and infrastructure component, and that each process and procedure has an identiﬁed owner responsible for its deﬁnition, and owners responsible for their performance. Having understanding of the business value of each component, process, and procedure, of why those resources are in place or activities are performed, and why that ownership exists will inform the actions of your team members. Clearly deﬁne the responsibilities of team members so that they may act appropriately and have mechanisms to identify responsibility and ownership. Have mechanisms to request additions, changes, and exceptions so that you do not constrain innovation. Deﬁne agreements between teams describing how they work together to support each other and your business outcomes. Provide support for your team members so that they can be more eﬀective in taking action and supporting your business outcomes. Engaged senior leadership should set expectations and measure success. Senior leadership should be the sponsor, advocate, and driver for the adoption of best practices and evolution of the organization. Let team members take action when outcomes are at risk to minimize impact and encourage them to escalate to decision makers and stakeholders when they believe there is a risk so that it can be addressed and incidents avoided. Provide timely, clear, and actionable communications of known risks and planned events so that team members can take timely and appropriate action. Encourage experimentation to accelerate learning and keep team members interested and engaged. Teams must grow their skill sets to adopt new technologies, and to support changes in demand and responsibilities. Support and encourage this by providing dedicated structured time for learning. Verify that your team members have the resources, both tools and team members, to be successful and scale to support your business outcomes. Leverage cross-organizational diversity to seek multiple unique perspectives. Use this perspective to increase innovation, challenge your Best practices 12 AWS Well-Architected Framework Framework assumptions, and reduce the risk of conﬁrmation bias. Grow inclusion, diversity, and accessibility within your teams to gain beneﬁcial perspectives. If there are external regulatory or compliance requirements that apply to your organization, you should use the resources provided by AWS Cloud Compliance to help educate your teams so that they can determine the impact on your priorities. The Well-Architected Framework emphasizes learning, measuring, and improving. It provides a consistent approach for you to evaluate architectures, and implement designs that will scale over time. AWS provides the AWS Well-Architected Tool to help you review your approach before development, the state of your workloads before production, and the state of your workloads in production. You can compare workloads to the latest AWS architectural best practices, monitor their overall status, and gain insight into potential risks. AWS Trusted Advisor is a tool that provides access to a core set of checks that recommend optimizations that may help shape your priorities. Business and Enterprise Support customers receive access to additional checks focusing on security, reliability, performance, cost-optimization, and sustainability that can further help shape their priorities. AWS can help you educate your teams about AWS and its services to increase their understanding of how their choices can have an impact on your workload. Use the resources provided by AWS Support (AWS Knowledge Center, AWS Discussion Forums, and AWS Support Center) and AWS Documentation to educate your teams. Reach out to AWS Support through AWS Support Center for help with your AWS questions. AWS also shares best practices and patterns that we have learned through the operation of AWS in The Amazon Builders' Library. A wide variety of other useful information is available through the AWS Blog and The Oﬃcial AWS Podcast. AWS Training and Certiﬁcation provides some training through self-paced digital courses on AWS fundamentals. You can also register for instructor-led training to further support the development of your teams’ AWS skills. Use tools or services that permit you to centrally govern your environments across accounts, such as AWS Organizations, to help manage your operating models. Services like AWS Control Tower expand this management capability by allowing you to deﬁne blueprints (supporting your operating models) for the setup of accounts, apply ongoing governance using AWS Organizations, and automate provisioning of new accounts. Managed Services providers such as AWS Managed Services, AWS Managed Services Partners, or Managed Services Providers in the AWS Partner Network, provide expertise implementing cloud environments, and support your security and compliance requirements and business goals. Adding Managed Services to your operating model can save you time and resources, and lets you keep your internal teams lean and focused on strategic outcomes that will diﬀerentiate your business, rather than developing new skills and capabilities. Best practices 13 AWS Well-Architected Framework Framework The following questions focus on these considerations for operational excellence. (For a list of operational excellence questions and best practices, see the Appendix.) OPS 1: How do you determine what your priorities are? Everyone must understand their part in achieving business success. Have shared goals in order to set priorities for resources. This will maximize the beneﬁts of your eﬀorts. OPS 2: How do you structure your organization to support your business outcomes? Your teams must understand their part in achieving business outcomes. Teams must understan d their roles in the success of other teams, the role of other teams in their success, and have shared goals. Understanding responsibility, ownership, how decisions are made, and who has authority to make decisions will help focus eﬀorts and maximize the beneﬁts from your teams. OPS 3: How does your organizational culture support your business outcomes? Provide support for your team members so that they can be more eﬀective in taking action and supporting your business outcome. You might ﬁnd that you want to emphasize a small subset of your priorities at some point in time. Use a balanced approach over the long term to verify the development of needed capabilities and management of risk. Review your priorities regularly and update them as needs change. When responsibility and ownership are undeﬁned or unknown, you are at risk of both not performing necessary action in a timely fashion and of redundant and potentially conﬂicting eﬀorts emerging to address those needs. Organizational culture has a direct impact on team member job satisfaction and retention. Activate the engagement and capabilities of your team members to achieve the success of your business. Experimentation is required for innovation to happen and turn ideas into outcomes. Recognize that an undesired result is a successful experiment that has identiﬁed a path that will not lead to success. Best practices 14 AWS Well-Architected Framework Framework Prepare To prepare for operational excellence, you have to understand your workloads and their expected behaviors. You will then be able to design them to provide insight to their status and build the procedures to support them. Design your workload so that it provides the information necessary for you to understand its internal state (for example, metrics, logs, events, and traces) across all components in support of observability and investigating issues. Observability goes beyond simple monitoring, providing a comprehensive understanding of a system's internal workings based on its external outputs. Rooted in metrics, logs, and traces, observability oﬀers profound insights into system behavior and dynamics. With eﬀective observability, teams can discern patterns, anomalies, and trends, allowing them to proactively address potential issues and maintain optimal system health. Identifying key performance indicators (KPIs) is pivotal to ensure alignment between monitoring activities and business objectives. This alignment ensures that teams are making data-driven decisions using metrics that genuinely matter, optimizing both system performance and business outcomes. Furthermore, observability empowers businesses to be proactive rather than reactive. Teams can understand the cause-and-eﬀect relationships within their systems, predicting and preventing issues rather than just reacting to them. As workloads evolve, it's essential to revisit and reﬁne the observability strategy, ensuring it remains relevant and eﬀective. Adopt approaches that improve the ﬂow of changes into production and that achieves refactoring, fast feedback on quality, and bug ﬁxing. These accelerate beneﬁcial changes entering production, limit issues deployed, and activate rapid identiﬁcation and remediation of issues introduced through deployment activities or discovered in your environments. Adopt approaches that provide fast feedback on quality and achieves rapid recovery from changes that do not have desired outcomes. Using these practices mitigates the impact of issues introduced through the deployment of changes. Plan for unsuccessful changes so that you are able to respond faster if necessary and test and validate the changes you make. Be aware of planned activities in your environments so that you can manage the risk of changes impacting planned activities. Emphasize frequent, small, reversible changes to limit the scope of change. This results in faster troubleshooting and remediation with the option to roll back a change. It also means you are able to get the beneﬁt of valuable changes more frequently. Evaluate the operational readiness of your workload, processes, procedures, and personnel to understand the operational risks related to your workload. Use a consistent process (including manual or automated checklists) to know when you are ready to go live with your workload or Best practices 15 AWS Well-Architected Framework Framework a change. This will also help you to ﬁnd any areas that you must make plans to address. Have runbooks that document your routine activities and playbooks that guide your processes for issue resolution. Understand the beneﬁts and risks to make informed decisions to permit changes to enter production. AWS allows you to view your entire workload (applications, infrastructure, policy, governance, and operations) as code. This means you can apply the same engineering discipline that you use for application code to every element of your stack and share these across teams or organizations to magnify the beneﬁts of development eﬀorts. Use operations as code in the cloud and the ability to safely experiment to develop your workload, your operations procedures, and practice failure. Using AWS CloudFormation allows you to have consistent, templated, sandbox development, test, and production environments with increasing levels of operations control. The following questions focus on these considerations for operational excellence. OPS 4: How do you implement observability in your workload? Implement observability in your workload so that you can understand its state and make data- driven decisions based on business requirements. OPS 5: How do you reduce defects, ease remediation, and improve ﬂow into production? Adopt approaches that improve ﬂow of changes into production that achieve refactoring fast feedback on quality, and bug ﬁxing. These accelerate beneﬁcial changes entering productio n, limit issues deployed, and achieve rapid identiﬁcation and remediation of issues introduced through deployment activities. OPS 6: How do you mitigate deployment risks? Adopt approaches that provide fast feedback on quality and achieve rapid recovery from changes that do not have desired outcomes. Using these practices mitigates the impact of issues introduced through the deployment of changes. Best practices 16 AWS Well-Architected Framework Framework OPS 7: How do you know that you are ready to support a workload? Evaluate the operational readiness of your workload, processes and procedures, and personnel to understand the operational risks related to your workload. Invest in implementing operations activities as code to maximize the productivity of operations personnel, minimize error rates, and achieve automated responses. Use “pre-mortems” to anticipate failure and create procedures where appropriate. Apply metadata using Resource Tags and AWS Resource Groups following a consistent tagging strategy to achieve identiﬁcation of your resources. Tag your resources for organization, cost accounting, access controls, and targeting the running of automated operations activities. Adopt deployment practices that take advantage of the elasticity of the cloud to facilitate development activities, and pre-deployment of systems for faster implementations. When you make changes to the checklists you use to evaluate your workloads, plan what you will do with live systems that no longer comply. Operate Observability allows you to focus on meaningful data and understand your workload's interactions and output. By concentrating on essential insights and eliminating unnecessary data, you maintain a straightforward approach to understanding workload performance. It's essential not only to collect data but also to interpret it correctly. Deﬁne clear baselines, set appropriate alert thresholds, and actively monitor for any deviations. A shift in a key metric, especially when correlated with other data, can pinpoint speciﬁc problem areas. With observability, you're better equipped to foresee and address potential challenges, ensuring that your workload operates smoothly and meets business needs. Successful operation of a workload is measured by the achievement of business and customer outcomes. Deﬁne expected outcomes, determine how success will be measured, and identify metrics that will be used in those calculations to determine if your workload and operations are successful. Operational health includes both the health of the workload and the health and success of the operations activities performed in support of the workload (for example, deployment and incident response). Establish metrics baselines for improvement, investigation, and intervention, collect and analyze your metrics, and then validate your understanding of operations success and how it changes over time. Use collected metrics to determine if you are satisfying customer and business needs, and identify areas for improvement. Best practices 17 AWS Well-Architected Framework Framework Eﬃcient and eﬀective management of operational events is required to achieve operational excellence. This applies to both planned and unplanned operational events. Use established runbooks for well-understood events, and use playbooks to aid in investigation and resolution of issues. Prioritize responses to events based on their business and customer impact. Verify that if an alert is raised in response to an event, there is an associated process to run with a speciﬁcally identiﬁed owner. Deﬁne in advance the personnel required to resolve an event and include escalation processes to engage additional personnel, as it becomes necessary, based on urgency and impact. Identify and engage individuals with the authority to make a decision on courses of action where there will be a business impact from an event response not previously addressed. Communicate the operational status of workloads through dashboards and notiﬁcations that are tailored to the target audience (for example, customer, business, developers, operations) so that they may take appropriate action, so that their expectations are managed, and so that they are informed when normal operations resume. In AWS, you can generate dashboard views of your metrics collected from workloads and natively from AWS. You can leverage CloudWatch or third-party applications to aggregate and present business, workload, and operations level views of operations activities. AWS provides workload insights through logging capabilities including AWS X-Ray, CloudWatch, CloudTrail, and VPC Flow Logs to identify workload issues in support of root cause analysis and remediation. The following questions focus on these considerations for operational excellence. OPS 8: How do you utilize workload observability in your organization? Ensure optimal workload health by leveraging observability. Utilize relevant metrics, logs, and traces to gain a comprehensive view of your workload's performance and address issues eﬃcient ly. OPS 9: How do you understand the health of your operations? Deﬁne, capture, and analyze operations metrics to gain visibility to operations events so that you can take appropriate action. Best practices 18 AWS Well-Architected Framework Framework OPS 10: How do you manage workload and operations events? Prepare and validate procedures for responding to events to minimize their disruption to your workload. All of the metrics you collect should be aligned to a business need and the outcomes they support. Develop scripted responses to well-understood events and automate their performance in response to recognizing the event. Evolve Learn, share, and continuously improve to sustain operational excellence. Dedicate work cycles to making nearly continuous incremental improvements. Perform post-incident analysis of all customer impacting events. Identify the contributing factors and preventative action to limit or prevent recurrence. Communicate contributing factors with aﬀected communities as appropriate. Regularly evaluate and prioritize opportunities for improvement (for example, feature requests, issue remediation, and compliance requirements), including both the workload and operations procedures. Include feedback loops within your procedures to rapidly identify areas for improvement and capture learnings from running operations. Share lessons learned across teams to share the beneﬁts of those lessons. Analyze trends within lessons learned and perform cross-team retrospective analysis of operations metrics to identify opportunities and methods for improvement. Implement changes intended to bring about improvement and evaluate the results to determine success. On AWS, you can export your log data to Amazon S3 or send logs directly to Amazon S3 for long- term storage. Using AWS Glue, you can discover and prepare your log data in Amazon S3 for analytics, and store associated metadata in the AWS Glue Data Catalog. Amazon Athena, through its native integration with AWS Glue, can then be used to analyze your log data, querying it using standard SQL. Using a business intelligence tool like Amazon QuickSight, you can visualize, explore, and analyze your data. Discovering trends and events of interest that may drive improvement. The following question focuses on these considerations for operational excellence. Best practices 19 AWS Well-Architected Framework Framework OPS 11: How do you evolve operations? Dedicate time and resources for nearly continuous incremental improvement to evolve the eﬀectiveness and eﬃciency of your operations. Successful evolution of operations is founded in: frequent small improvements; providing safe environments and time to experiment, develop, and test improvements; and environments in which learning from failures is encouraged. Operations support for sandbox, development, test, and production environments, with increasing level of operational controls, facilitates development and increases the predictability of successful results from changes deployed into production. Resources Refer to the following resources to learn more about our best practices for Operational Excellence. Documentation DevOps and AWS Whitepaper Operational Excellence Pillar Video DevOps at Amazon Security The Security pillar encompasses the ability to protect data, systems, and assets to take advantage of cloud technologies to improve your security. The security pillar provides an overview of design principles, best practices, and questions. You can ﬁnd prescriptive guidance on implementation in the Security Pillar whitepaper. Topics Design principles Resources 20 AWS Well-Architected Framework Framework Deﬁnition Best practices Resources Design principles In the cloud, there are a number of principles that can help you strengthen your workload security: Implement a strong identity foundation: Implement the principle of least privilege and enforce separation of duties with appropriate authorization for each interaction with your AWS resources. Centralize identity management, and aim to eliminate reliance on long-term static credentials. Maintain traceability: Monitor, alert, and audit actions and changes to your environment in real time. Integrate log and metric collection with systems to automatically investigate and take action. Apply security at all layers: Apply a defense in depth approach with multiple security controls. Apply to all layers (for example, edge of network, VPC, load balancing, every instance and compute service, operating system, application, and code). Automate security best practices: Automated software-based security mechanisms improve your ability to securely scale more rapidly and cost-eﬀectively. Create secure architectures, including the implementation of controls that are deﬁned and managed as code in version- controlled templates. Protect data in transit and at rest: Classify your data into sensitivity levels and use mechanisms, such as encryption, tokenization, and access control where appropriate. Keep people away from data: Use mechanisms and tools to reduce or eliminate the need for direct access or manual processing of data. This reduces the risk of mishandling or modiﬁcation and human error when handling sensitive data. Prepare for security events: Prepare for an incident by having incident management and investigation policy and processes that align to your organizational requirements. Run incident response simulations and use tools with automation to increase your speed for detection, investigation, and recovery. Deﬁnition There are seven best practice areas for security in the cloud: Design principles 21 AWS Well-Architected Framework Framework Security foundations Identity and access management Detection Infrastructure protection Data protection Incident response Application security Before you architect any workload, you need to put in place practices that inﬂuence security. You will want to control who can do what. In addition, you want to be able to identify security incidents, protect your systems and services, and maintain the conﬁdentiality and integrity of data through data protection. You should have a well-deﬁned and practiced process for responding to security incidents. These tools and techniques are important because they support objectives such as preventing ﬁnancial loss or complying with regulatory obligations. The AWS Shared Responsibility Model helps organizations that adopt the cloud to achieve their security and compliance goals. Because AWS physically secures the infrastructure that supports our cloud services, as an AWS customer you can focus on using services to accomplish your goals. The AWS Cloud also provides greater access to security data and an automated approach to responding to security events. Best practices Topics Security Identity and access management Detection Infrastructure protection Data protection Incident response Application security Best practices 22 AWS Well-Architected Framework Framework Security The following question focuses on these considerations for security. (For a list of security questions and best practices, see the Appendix.). SEC 1: How do you securely operate your workload? To operate your workload securely, you must apply overarching best practices to every area of security. Take requirements and processes that you have deﬁned in operational excellence at an organizational and workload level, and apply them to all areas. Staying up to date with recommendations from AWS, industry sources, and threat intellige nce helps you evolve your threat model and control objectives. Automating security processes, testing, and validation allow you to scale your security operations. In AWS, segregating diﬀerent workloads by account, based on their function and compliance or data sensitivity requirements, is a recommended approach. Identity and access management Identity and access management are key parts of an information security program, ensuring that only authorized and authenticated users and components are able to access your resources, and only in a manner that you intend. For example, you should deﬁne principals (that is, accounts, users, roles, and services that can perform actions in your account), build out policies aligned with these principals, and implement strong credential management. These privilege-management elements form the core of authentication and authorization. In AWS, privilege management is primarily supported by the AWS Identity and Access Management (IAM) service, which allows you to control user and programmatic access to AWS services and resources. You should apply granular policies, which assign permissions to a user, group, role, or resource. You also have the ability to require strong password practices, such as complexity level, avoiding re-use, and enforcing multi-factor authentication (MFA). You can use federation with your existing directory service. For workloads that require systems to have access to AWS, IAM allows for secure access through roles, instance proﬁles, identity federation, and temporary credentials. The following questions focus on these considerations for security. Best practices 23 AWS Well-Architected Framework Framework SEC 2: How do you manage identities for people and machines? There are two types of identities you need to manage when approaching operating secure AWS workloads. Understanding the type of identity you need to manage and grant access helps you verify the right identities have access to the right resources under the right conditions. Human Identities: Your administrators, developers, operators, and end users require an identity to access your AWS environments and applications. These are members of your organization, or external users with whom you collaborate, and who interact with your AWS resources via a web browser, client application, or interactive command line tools. Machine Identities: Your service applications, operational tools, and workloads require an identity to make requests to AWS services, for example, to read data. These identities include machines running in your AWS environment such as Amazon EC2 instances or AWS Lambda functions. You may also manage machine identities for external parties who need access. Additionally, you may also have machines outside of AWS that need access to your AWS environment. SEC 3: How do you manage permissions for people and machines? Manage permissions to control access to people and machine identities that require access to AWS and your workload. Permissions control who can access what, and under what conditions. Credentials must not be shared between any user or system. User access should be granted using a least-privilege approach with best practices including password requirements and MFA enforced. Programmatic access, including API calls to AWS services, should be performed using temporary and limited-privilege credentials, such as those issued by the AWS Security Token Service. Users need programmatic access if they want to interact with AWS outside of the AWS Management Console. The way to grant programmatic access depends on the type of user that's accessing AWS. To grant users programmatic access, choose one of the following options. Best practices 24 AWS Well-Architected Framework Framework Which user needs To By programmatic access? Workforce identity Use temporary credentials to Following the instructions for sign programmatic requests the interface that you want to (Users managed in IAM to the AWS CLI, AWS SDKs, or use. Identity Center) AWS APIs. For the AWS CLI, see Conﬁguring the AWS CLI to use AWS IAM Identity Center in the AWS Command Line Interface User Guide. For AWS SDKs, tools, and AWS APIs, see IAM Identity Center authentication in the AWS SDKs and Tools Reference Guide. IAM Use temporary credentials to Following the instructions in sign programmatic requests Using temporary credentia to the AWS CLI, AWS SDKs, or ls with AWS resources in the AWS APIs. IAM User Guide. IAM (Not recommended) Following the instructions for Use long-term credentials to the interface that you want to sign programmatic requests use. to the AWS CLI, AWS SDKs, or For the AWS CLI, see AWS APIs. Authenticating using IAM user credentials in the AWS Command Line Interface User Guide. For AWS SDKs and tools, see Authenticate using long-term credentials in Best practices 25 AWS Well-Architected Framework Framework Which user needs To By programmatic access? the AWS SDKs and Tools Reference Guide. For AWS APIs, see Managing access keys for IAM users in the IAM User Guide. AWS provides resources that can help you with identity and access management. To help learn best practices, explore our hands-on labs on managing credentials & authentication, controlling human access, and controlling programmatic access. Detection You can use detective controls to identify a potential security threat or incident. They are an essential part of governance frameworks and can be used to support a quality process, a legal or compliance obligation, and for threat identiﬁcation and response eﬀorts. There are diﬀerent types of detective controls. For example, conducting an inventory of assets and their detailed attributes promotes more eﬀective decision making (and lifecycle controls) to help establish operational baselines. You can also use internal auditing, an examination of controls related to information systems, to verify that practices meet policies and requirements and that you have set the correct automated alerting notiﬁcations based on deﬁned conditions. These controls are important reactive factors that can help your organization identify and understand the scope of anomalous activity. In AWS, you can implement detective controls by processing logs, events, and monitoring that allows for auditing, automated analysis, and alarming. CloudTrail logs, AWS API calls, and CloudWatch provide monitoring of metrics with alarming, and AWS Conﬁg provides conﬁguration history. Amazon GuardDuty is a managed threat detection service that continuously monitors for malicious or unauthorized behavior to help you protect your AWS accounts and workloads. Service- level logs are also available, for example, you can use Amazon Simple Storage Service (Amazon S3) to log access requests. The following question focuses on these considerations for security. Best practices 26 AWS Well-Architected Framework Framework SEC 4: How do you detect and investigate security events? Capture and analyze events from logs and metrics to gain visibility. Take action on security events and potential threats to help secure your workload. Log management is important to a Well-Architected workload for reasons ranging from security or forensics to regulatory or legal requirements. It is critical that you analyze logs and respond to them so that you can identify potential security incidents. AWS provides functionality that makes log management easier to implement by giving you the ability to deﬁne a data-retention lifecycle or deﬁne where data will be preserved, archived, or eventually deleted. This makes predictable and reliable data handling simpler and more cost eﬀective. Infrastructure protection Infrastructure protection encompasses control methodologies, such as defense in depth, necessary to meet best practices and organizational or regulatory obligations. Use of these methodologies is critical for successful, ongoing operations in either the cloud or on-premises. In AWS, you can implement stateful and stateless packet inspection, either by using AWS-native technologies or by using partner products and services available through the AWS Marketplace. You should use Amazon Virtual Private Cloud (Amazon VPC) to create a private, secured, and scalable environment in which you can deﬁne your topology—including gateways, routing tables, and public and private subnets. The following questions focus on these considerations for security. SEC 5: How do you protect your network resources? Any workload that has some form of network connectivity, whether it’s the internet or a private network, requires multiple layers of defense to help protect from external and internal network- based threats. Best practices 27 AWS Well-Architected Framework Framework SEC 6: How do you protect your compute resources? Compute resources in your workload require multiple layers of defense to help protect from external and internal threats. Compute resources include EC2 instances, containers, AWS Lambda functions, database services, IoT devices, and more. Multiple layers of defense are advisable in any type of environment. In the case of infrastructure protection, many of the concepts and methods are valid across cloud and on-premises models. Enforcing boundary protection, monitoring points of ingress and egress, and comprehensive logging, monitoring, and alerting are all essential to an eﬀective information security plan. AWS customers are able to tailor, or harden, the conﬁguration of an Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS) container, or AWS Elastic Beanstalk instance, and persist this conﬁguration to an immutable Amazon Machine Image (AMI). Then, whether launched by Auto Scaling or launched manually, all new virtual servers (instances) launched with this AMI receive the hardened conﬁguration. Data protection Before architecting any system, foundational practices that inﬂuence security should be in place. For example, data classiﬁcation provides a way to categorize organizational data based on levels of sensitivity, and encryption protects data by way of rendering it unintelligible to unauthorized access. These tools and techniques are important because they support objectives such as preventing ﬁnancial loss or complying with regulatory obligations. In AWS, the following practices facilitate protection of data: As an AWS customer you maintain full control over your data. AWS makes it easier for you to encrypt your data and manage keys, including regular key rotation, which can be easily automated by AWS or maintained by you. Detailed logging that contains important content, such as ﬁle access and changes, is available. AWS has designed storage systems for exceptional resiliency. For example, Amazon S3 Standard, S3 Standard–IA, S3 One Zone-IA, and Amazon Glacier are all designed to provide 99.999999999% durability of objects over a given year. This durability level corresponds to an average annual expected loss of 0.000000001% of objects. Versioning, which can be part of a larger data lifecycle management process, can protect against accidental overwrites, deletes, and similar harm. Best practices 28 AWS Well-Architected Framework Framework AWS never initiates the movement of data between Regions. Content placed in a Region will remain in that Region unless you explicitly use a feature or leverage a service that provides that functionality. The following questions focus on these considerations for security. SEC 7: How do you classify your data? Classiﬁcation provides a way to categorize data, based on criticality and sensitivity in order to help you determine appropriate protection and retention controls. SEC 8: How do you protect your data at rest? Protect your data at rest by implementing multiple controls, to reduce the risk of unauthorized access or mishandling. SEC 9: How do you protect your data in transit? Protect your data in transit by implementing multiple controls to reduce the risk of unauthori zed access or loss. AWS provides multiple means for encrypting data at rest and in transit. We build features into our services that make it easier to encrypt your data. For example, we have implemented server-side encryption (SSE) for Amazon S3 to make it easier for you to store your data in an encrypted form. You can also arrange for the entire HTTPS encryption and decryption process (generally known as SSL termination) to be handled by Elastic Load Balancing (ELB). Incident response Even with extremely mature preventive and detective controls, your organization should still put processes in place to respond to and mitigate the potential impact of security incidents. The architecture of your workload strongly aﬀects the ability of your teams to operate eﬀectively during an incident, to isolate or contain systems, and to restore operations to a known good state. Putting in place the tools and access ahead of a security incident, then routinely practicing incident Best practices 29 AWS Well-Architected Framework Framework response through game days, will help you verify that your architecture can accommodate timely investigation and recovery. In AWS, the following practices facilitate eﬀective incident response: Detailed logging is available that contains important content, such as ﬁle access and changes. Events can be automatically processed and launch tools that automate responses through the use of AWS APIs. You can pre-provision tooling and a “clean room” using AWS CloudFormation. This allows you to carry out forensics in a safe, isolated environment. The following question focuses on these considerations for security. SEC 10: How do you anticipate, respond to, and recover from incidents? Preparation is critical to timely and eﬀective investigation, response to, and recovery from security incidents to help minimize disruption to your organization. Verify that you have a way to quickly grant access for your security team, and automate the isolation of instances as well as the capturing of data and state for forensics. Application security Application security (AppSec) describes the overall process of how you design, build, and test the security properties of the workloads you develop. You should have appropriately trained people in your organization, understand the security properties of your build and release infrastructure, and use automation to identify security issues. Adopting application security testing as a regular part of your software development lifecycle (SDLC) and post release processes help validate that you have a structured mechanism to identify, ﬁx, and prevent application security issues entering your production environment. Your application development methodology should include security controls as you design, build, deploy, and operate your workloads. While doing so, align the process for continuous defect reduction and minimizing technical debt. For example, using threat modeling in the design phase helps you uncover design ﬂaws early, which makes them easier and less costly to ﬁx as opposed to waiting and mitigating them later. Best practices 30 AWS Well-Architected Framework Framework The cost and complexity to resolve defects is typically lower the earlier you are in the SDLC. The easiest way to resolve issues is to not have them in the ﬁrst place, which is why starting with a threat model helps you focus on the right outcomes from the design phase. As your AppSec program matures, you can increase the amount of testing that is performed using automation, improve the ﬁdelity of feedback to builders, and reduce the time needed for security reviews. All of these actions improve the quality of the software you build, and increase the speed of delivering features into production. These implementation guidelines focus on four areas: organization and culture, security of the pipeline, security in the pipeline, and dependency management. Each area provides a set of principles that you can implement and provides an end-to-end view of how you design, develop, build, deploy, and operate workloads. In AWS, there are a number of approaches you can use when addressing your application security program. Some of these approaches rely on technology while others focus on the people and organizational aspects of your application security program. The following question focuses on these considerations for application security. SEC 11: How do you incorporate and validate the security properties of applications throughout the design, development, and deployment lifecycle? Training people, testing using automation, understanding dependencies, and validating the security properties of tools and applications help to reduce the likelihood of security issues in production workloads. Resources Refer to the following resources to learn more about our best practices for Security. Documentation AWS Cloud Security AWS Compliance AWS Security Blog AWS Security Maturity Model Resources 31 AWS Well-Architected Framework Framework Whitepaper Security Pillar AWS Security Overview AWS Risk and Compliance Video AWS Security State of the Union Shared Responsibility Overview Reliability The Reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle. This paper provides in-depth, best practice guidance for implementing reliable workloads on AWS. The reliability pillar provides an overview of design principles, best practices, and questions. You can ﬁnd prescriptive guidance on implementation in the Reliability Pillar whitepaper. Topics Design principles Deﬁnition Best practices Resources Design principles There are ﬁve design principles for reliability in the cloud: Automatically recover from failure: By monitoring a workload for key performance indicators (KPIs), you can start automation when a threshold is breached. These KPIs should be a measure of business value, not of the technical aspects of the operation of the service. This provides for automatic notiﬁcation and tracking of failures, and for automated recovery processes that work Reliability 32 AWS Well-Architected Framework Framework around or repair the failure. With more sophisticated automation, it’s possible to anticipate and remediate failures before they occur. Test recovery procedures: In an on-premises environment, testing is often conducted to prove that the workload works in a particular scenario. Testing is not typically used to validate recovery strategies. In the cloud, you can test how your workload fails, and you can validate your recovery procedures. You can use automation to simulate diﬀerent failures or to recreate scenarios that led to failures before. This approach exposes failure pathways that you can test and ﬁx before a real failure scenario occurs, thus reducing risk. Scale horizontally to increase aggregate workload availability: Replace one large resource with multiple small resources to reduce the impact of a single failure on the overall workload. Distribute requests across multiple, smaller resources to verify that they don’t share a common point of failure. Stop guessing capacity: A common cause of failure in on-premises workloads is resource saturation, when the demands placed on a workload exceed the capacity of that workload (this is often the objective of denial of service attacks). In the cloud, you can monitor demand and workload utilization, and automate the addition or removal of resources to maintain the more eﬃcient level to satisfy demand without over- or under-provisioning. There are still limits, but some quotas can be controlled and others can be managed (see Manage Service Quotas and Constraints). Manage change through automation: Changes to your infrastructure should be made using automation. The changes that must be managed include changes to the automation, which then can be tracked and reviewed. Deﬁnition There are four best practice areas for reliability in the cloud: Foundations Workload architecture Change management Failure management To achieve reliability, you must start with the foundations — an environment where Service Quotas and network topology accommodate the workload. The workload architecture of the distributed Deﬁnition 33 AWS Well-Architected Framework Framework system must be designed to prevent and mitigate failures. The workload must handle changes in demand or requirements, and it must be designed to detect failure and automatically heal itself. Best practices Topics Foundations Workload architecture Change management Failure management Foundations Foundational requirements are those whose scope extends beyond a single workload or project. Before architecting any system, foundational requirements that inﬂuence reliability should be in place. For example, you must have suﬃcient network bandwidth to your data center. With AWS, most of these foundational requirements are already incorporated or can be addressed as needed. The cloud is designed to be nearly limitless, so it’s the responsibility of AWS to satisfy the requirement for suﬃcient networking and compute capacity, permitting you to change resource size and allocations on demand. The following questions focus on these considerations for reliability. (For a list of reliability questions and best practices, see the Appendix.). REL 1: How do you manage Service Quotas and constraints? For cloud-based workload architectures, there are Service Quotas (which are also referred to as service limits). These quotas exist to prevent accidentally provisioning more resources than you need and to limit request rates on API operations so as to protect services from abuse. There are also resource constraints, for example, the rate that you can push bits down a ﬁber-optic cable, or the amount of storage on a physical disk. Best practices 34 AWS Well-Architected Framework Framework REL 2: How do you plan your network topology? Workloads often exist in multiple environments. These include multiple cloud environments (both publicly accessible and private) and possibly your existing data center infrastructure. Plans must include network considerations such as intra- and inter-system connectivity, public IP address management, private IP address management, and domain name resolution. Workload architecture A reliable workload starts with upfront design decisions for both software and infrastructure. Your architecture choices will impact your workload behavior across all of the Well-Architected pillars. For reliability, there are speciﬁc patterns you must follow. With AWS, workload developers have their choice of languages and technologies to use. AWS SDKs take the complexity out of coding by providing language-speciﬁc APIs for AWS services. These SDKs, plus the choice of languages, permits developers to implement the reliability best practices listed here. Developers can also read about and learn from how Amazon builds and operates software in The Amazon Builders' Library. The following questions focus on these considerations for reliability. REL 3: How do you design your workload service architecture? Build highly scalable and reliable workloads using a service-oriented architecture (SOA) or a microservices architecture. Service-oriented architecture (SOA) is the practice of making software components reusable via service interfaces. Microservices architecture goes further to make components smaller and simpler. REL 4: How do you design interactions in a distributed system to prevent failures? Distributed systems rely on communications networks to interconnect components, such as servers or services. Your workload must operate reliably despite data loss or latency in these networks. Components of the distributed system must operate in a way that does not negativel y impact other components or the workload. These best practices prevent failures and improve mean time between failures (MTBF). Best practices 35 AWS Well-Architected Framework Framework REL 5: How do you design interactions in a distributed system to mitigate or withstand failures? Distributed systems rely on communications networks to interconnect components (such as servers or services). Your workload must operate reliably despite data loss or latency over these networks. Components of the distributed system must operate in a way that does not negatively impact other components or the workload. These best practices permit workloads to withstand stresses or failures, more quickly recover from them, and mitigate the impact of such impairmen ts. The result is improved mean time to recovery (MTTR). Change management Changes to your workload or its environment must be anticipated and accommodated to achieve reliable operation of the workload. Changes include those imposed on your workload, such as spikes in demand, and also those from within, such as feature deployments and security patches. Using AWS, you can monitor the behavior of a workload and automate the response to KPIs. For example, your workload can add additional servers as a workload gains more users. You can control who has permission to make workload changes and audit the history of these changes. The following questions focus on these considerations for reliability. REL 6: How do you monitor workload resources? Logs and metrics are powerful tools to gain insight into the health of your workload. You can conﬁgure your workload to monitor logs and metrics and send notiﬁcations when thresholds are crossed or signiﬁcant events occur. Monitoring allows your workload to recognize when low- performance thresholds are crossed or failures occur, so it can recover automatically in response. REL 7: How do you design your workload to adapt to changes in demand? A scalable workload provides elasticity to add or remove resources automatically so that they closely match the current demand at any given point in time. Best practices 36 AWS Well-Architected Framework Framework REL 8: How do you implement change? Controlled changes are necessary to deploy new functionality, and to verify that the workloads and the operating environment are running known software and can be patched or replaced in a predictable manner. If these changes are uncontrolled, then it makes it diﬃcult to predict the eﬀect of these changes, or to address issues that arise because of them. When you architect a workload to automatically add and remove resources in response to changes in demand, this not only increases reliability but also validates that business success doesn't become a burden. With monitoring in place, your team will be automatically alerted when KPIs deviate from expected norms. Automatic logging of changes to your environment permits you to audit and quickly identify actions that might have impacted reliability. Controls on change management certify that you can enforce the rules that deliver the reliability you need. Failure management In any system of reasonable complexity, it is expected that failures will occur. Reliability requires that your workload be aware of failures as they occur and take action to avoid impact on availability. Workloads must be able to both withstand failures and automatically

wellarchitected-framework.pdf

Document Details

Related

Full Transcript

Upgrade to continue