AWS prescriptive-guidance documentation change
Summary
Updated operational guidance to emphasize customer perspective monitoring with CloudWatch Synthetics, simplified alerting strategies, actionable runbooks, and lean incident management processes. Removed technical implementation details about Service Quotas and visual monitoring blueprints.
Security assessment
The changes focus on operational excellence and monitoring best practices rather than addressing security vulnerabilities. While improved monitoring can help detect operational issues, there's no mention of security controls, vulnerability remediation, or explicit security mechanisms. The guidance about canaries and alerts relates to general availability rather than security protection.
Diff
diff --git a/prescriptive-guidance/latest/startup-resiliency-baseline/stage-4.md b/prescriptive-guidance/latest/startup-resiliency-baseline/stage-4.md index 0023a1c53..f2a8f00e9 100644 --- a//prescriptive-guidance/latest/startup-resiliency-baseline/stage-4.md +++ b//prescriptive-guidance/latest/startup-resiliency-baseline/stage-4.md @@ -3,3 +3 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Startup Resiliency Baseline (AWS SRB)](introduction.html) - -ObservabilityContinuous resilience +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Startup Resiliency Baseline](introduction.html) @@ -9 +7 @@ ObservabilityContinuous resilience -This stage focuses on the operational practices your system uses to maintain and improve resilience. Building a culture of operational excellence helps establish standards and consistency for these practices. +You've built a resilient application and tested it. Now the daily reality is keeping it running. But in a startup, you can't watch all operations, and you shouldn't try to. The key is to stay alert to what matters without providing too many metrics or overburdening your team. @@ -11 +9 @@ This stage focuses on the operational practices your system uses to maintain and -## Observability +Start with the customer perspective. [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) canaries act as automated customers. They continuously test critical user journeys. Have them log in, simulate purchases using test accounts, or access key features, especially during your busiest hours. This helps you understand the customer experience and helps you catch issues before real users do. When a canary fails, you know immediately that something's wrong from a customer's perspective. @@ -13 +11 @@ This stage focuses on the operational practices your system uses to maintain and -To effectively measure resiliency, monitor your applications from both the server side and the client side. +Build on this foundation with focused monitoring of the supporting infrastructure. What signals tell you there's trouble? [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) helps you build dashboards that track these signs. Don't just monitor technical metrics; tie them to business impact. For example, high CPU usage matters, but that's because it might degrade the customer experience that you're tracking with canaries. @@ -15 +13 @@ To effectively measure resiliency, monitor your applications from both the serve -For server-side monitoring, use your preferred infrastructure monitoring tools. With these tools, set up dashboards, alarms, and notifications for any breaches to key performance indicators (KPIs) for infrastructure or applications. If you are using [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html), configure [dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) and [alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) to provide alerts about any infrastructure or application failures. +As a practical approach, map your monitoring to your customer journeys. If you're running a software as a service (SaaS) platform, you likely care about API response times, authentication success rates, and core feature availability. Set up alerts that tell you when these metrics drift. However, be selective. Every alert should demand action. If your team starts ignoring alerts because "it's probably nothing," you've set too many or are tracking the wrong metrics. @@ -17 +15 @@ For server-side monitoring, use your preferred infrastructure monitoring tools. -Use [Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html), an AWS service that helps you manage your [quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) for many AWS services. This helps prevent service quota issues when scaling your production workloads on AWS. You can also create CloudWatch alarms that alert you when you approach the threshold for critical services in your workload. +Route these alerts through tools that your team already uses. If your engineers live in a particular messaging application, send alerts there. The goal is quick awareness without creating a new process. When an alert fires, your team should know exactly what it means and what to do about it. @@ -19 +17 @@ Use [Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/ -For client-side monitoring, set up synthetic monitoring by creating scripts or canaries that monitor your application for metrics, such as availability, page load times, or broken links. _Synthetic monitoring_ continually verifies your customers' experience by following the same routes and actions as customers. You can use [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) canaries to visually monitor your applications. The [visual monitoring blueprint](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Blueprints.html#CloudWatch_Synthetics_Canaries_Blueprints_VisualTesting) helps you quickly create or update canaries that compare screenshots of your running application against baseline screenshot. You can also use [CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) to perform real user monitoring to collect and view client-side data about your web application performance from actual user sessions in near real time. You can visualize and analyze data, such as page load times, client-side errors, and user behavior. +Keep your operational documentation lean and practical. Store runbooks with your code in version control, but remember that they're not novels. When something breaks, your team needs clear, actionable steps. Each alert should link to a corresponding runbook, and each runbook should answer three questions: @@ -21 +19 @@ For client-side monitoring, set up synthetic monitoring by creating scripts or c -**Additional resources:** + * What broke? @@ -23 +21 @@ For client-side monitoring, set up synthetic monitoring by creating scripts or c - * [Monitor all components for the workload](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html) + * Why does it matter? @@ -25 +23 @@ For client-side monitoring, set up synthetic monitoring by creating scripts or c - * [Send notifications (Real-time processing and alarming)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html) + * How do I fix it? @@ -27 +24,0 @@ For client-side monitoring, set up synthetic monitoring by creating scripts or c - * [Visual monitoring of applications with Amazon CloudWatch Synthetics](https://aws.amazon.com/blogs/mt/visual-monitoring-of-applications-with-amazon-cloudwatch-synthetics/) (AWS blog post) @@ -30,0 +28 @@ For client-side monitoring, set up synthetic monitoring by creating scripts or c +Implement a simple incident management process. You don't need complex frameworks, just clear definitions of what constitutes an incident and who to call when things escalate. Keep incident logs because they help you improve your application's resilience. @@ -32 +30 @@ For client-side monitoring, set up synthetic monitoring by creating scripts or c -## Continuous resilience +The key is finding the sweet spot between vigilance and overhead. Use AWS tools to automate what you can, focus on monitoring metrics that impact customers, and keep your processes light enough to evolve as you grow. @@ -34 +32 @@ For client-side monitoring, set up synthetic monitoring by creating scripts or c -Periodically review the resilience posture of your mission critical workloads by using the AWS Well-Architected Tool. Also consider running a [game day](https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/) to simulate a known event against which you have established resilience mechanisms. For example, you might simulate an Availability Zone impairment and run a multi-AZ failover. Although implementing these activities might require a significant level of effort, both practices build confidence that your workload is resilient against the failure modes that you've designed it to withstand. +The next chapter explores how to foster a resilience mindset without sacrificing the speed and innovation that make startups special. At the end of the day, resilience is as much about people as it is about technology.