Know when an AWS event affects your resources — AWS Health

Your goal

Plan how your team notices and responds to relevant AWS service events.

Why this matters

A planned service event may affect resources your app uses. You will find the relevant notice, identify who owns the affected resources, and keep checking the app’s own health.

Words you will use

A health event reports a service issue or planned change. Affected resources are the resources linked to the notice. A runbook describes the steps a team should follow.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Find relevant service events

Your team wants information about AWS service events that may affect its environment, including account-specific notices when available.

What should it consult?

AWS Health and the relevant event details.

AWS Health provides service event information and relevant account context where available. Review the event’s scope and current details. An event notice should be connected to the resources and services your app actually uses.

The team has an authoritative event to investigate.

Service event → scope and affected-resource details

2. Give the notice an owner

A planned change affects several resources, but no team is responsible for checking them. The notice could be read and still lead to no action.

What should the response process identify?

Affected resource owners, required actions, and relevant timing.

Route relevant notices to people who can act and use a runbook for the needed checks or changes. Confirm completion rather than assuming delivery of a notification means the work was done.

The event has an owner and a clear response plan.

Affected resources → owners → timed action and verification

3. Keep observing the app

There is no AWS Health event for the Region, but customers report failures. A missing provider notice does not prove the application is healthy.

What should the team do?

Check application metrics, logs, dependencies, and user-facing behavior.

Provider health and application health are different views. Your own configuration, code, or dependencies can fail without a broad service event. Keep application monitoring and investigation active alongside AWS Health.

The team uses both provider notices and application evidence.

AWS Health context + app telemetry → informed investigation

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.