Confirm your impact first
An AWS incident is useful context, but it does not tell you whether your customers are affected. Check your own error rate, latency, synthetic transactions, and support reports. Then compare those signals with AWS Health and the public AWS status page for the services and regions you use.
Record what you know and what remains uncertain. A short statement such as ‘checkout errors increased in eu-west-1; the cause is still under investigation’ is more useful than declaring a broad AWS outage too early.
Narrow the affected path
Identify the customer action that is failing, the AWS services it touches, and the region or availability zone involved. Check adjacent dependencies as well: DNS, identity, queues, databases, content delivery, and third-party APIs can produce similar symptoms.
Use a prepared dependency map if one exists. If it does not, write down the path as you investigate; that record will improve the next response.
Choose mitigation based on tested capability
Failover is not automatically the right answer. A regional or multi-cloud switch can introduce data consistency, capacity, networking, and authentication problems of its own. Use it only when the path has been tested and the expected benefit is greater than the change risk.
Other responses may be safer:
- pause work that can be queued and replayed
- disable a nonessential feature that is causing cascading failures
- serve a limited read-only or static experience
- reduce retries that are adding load
- ask support to use a documented workaround
Communicate what customers can observe
Your status update should name the affected function, when you confirmed it, and what customers should do. Mention AWS when the relationship is supported by evidence, not as a substitute for describing your own impact.
Set the next update time based on the severity and how quickly facts are changing. If there is no material change, say that plainly.
Verify recovery in your system
A provider recovery notice is the start of validation. Re-run customer transactions, watch queues drain, confirm background jobs, and check for stale connections or cached errors. Restore paused features and traffic gradually when the architecture allows it.
Afterward, preserve the timeline and decisions while they are still clear. The review should produce a small set of owned changes: a missing check, an unsafe retry policy, an untested failover path, or a communication gap.