This chapter covers AWS Service Health Dashboard and AWS Personal Health Dashboard, two critical tools for monitoring the health of AWS services and your specific resources. For the SOA-C02 exam, these topics appear in Domain 1: Monitoring and Reporting, Objective 1.2: Use AWS services to monitor and report on performance and health. Expect 5–8% of exam questions to touch on these dashboards, their differences, and how to integrate them with other monitoring services. Understanding when to use each dashboard and how to automate responses to health events is essential for both the exam and real-world operations.
Jump to a section
Imagine you are the facilities manager for a large corporate campus with dozens of buildings. The city's utility company provides a public dashboard showing major outages: a power line down in the north district, a water main break downtown. This is the AWS Service Health Dashboard—it shows regional, city-wide issues affecting many customers. However, you also have a personalized monitoring system for your specific buildings: sensors on your HVAC, fire alarms, and electrical panels that report issues unique to your campus. This is AWS Personal Health Dashboard. When a circuit breaker trips in Building 3, your personal system alerts you immediately, even if the city's grid is fine. Conversely, if the city announces a planned power outage for maintenance, your personal dashboard tells you exactly which of your buildings will be affected and when. The city dashboard is for awareness of broad events; the personal dashboard gives you actionable, resource-specific information. Just as you would not rely on the city dashboard to know if your building's air conditioner failed, you should not rely on the Service Health Dashboard for issues specific to your AWS resources. The Personal Health Dashboard integrates with Amazon CloudWatch Events (now Amazon EventBridge) to trigger automated responses, like sending a maintenance crew or starting a backup generator.
What are the AWS Service Health Dashboard and Personal Health Dashboard?
The AWS Service Health Dashboard (SHD) is a public, read-only web page that displays the current status of all AWS services across every region. It shows service-wide events such as outages, degraded performance, and planned maintenance. The URL is https://health.aws.amazon.com/health/status. Any user, even without an AWS account, can view it. It is the 'canary in the coal mine' for AWS itself—if you suspect a regional issue, you check SHD first.
The AWS Personal Health Dashboard (PHD) is a personalized view of events that affect your specific AWS account and resources. It is accessible only to authenticated AWS users via the AWS Management Console, API, or CLI. PHD shows events like EC2 instance retirements, EBS volume degradation, or scheduled maintenance that directly impacts your resources. It also provides proactive notifications (e.g., 'Your EC2 instance i-12345 will be retired on 2025-06-01').
Why Two Dashboards?
AWS separates these because the scope of events differs. SHD covers global or regional service-level health; PHD covers account-specific events. For example, if us-east-1 experiences an EC2 launch failure, SHD shows 'EC2: Impaired' for us-east-1. However, if a specific EBS volume in your account is at risk of failure, only PHD will tell you, because it is a resource-specific issue. The exam expects you to choose the correct dashboard based on the event scope.
How Do They Work Internally?
Service Health Dashboard (SHD): AWS operations teams monitor service metrics and manually or automatically update the SHD. Events are categorized as: - Service disruption: A service is currently unavailable or degraded. - Informational message: General announcements about features, deprecations, or known issues. - Planned maintenance: Scheduled changes that may cause brief interruptions.
SHD is updated in near real-time but with a latency of several minutes. It does not provide per-account details. The SHD also has an RSS feed and a JSON feed for programmatic consumption. The JSON feed (https://health.aws.amazon.com/health/status) provides structured data for integration.
Personal Health Dashboard (PHD): AWS monitors the health of your resources using internal health checks. When a health event is detected (e.g., an EC2 instance scheduled for retirement), AWS publishes an event to your account's PHD. Events are stored for 90 days and can be retrieved via the AWS Health API, CLI, or SDK. The PHD uses the AWS Health service, which is a regional service. You must enable AWS Health to receive events in all regions or specific ones. Events are categorized as: - Scheduled change: Upcoming maintenance or retirement. - Account notification: Billing alerts, service limit increases, etc. - Issue: Ongoing problem affecting your resources (e.g., degraded EBS performance).
PHD events have a structured JSON payload with fields like eventTypeCode, service, region, startTime, endTime, affectedEntities, and eventDescription. You can filter events by these fields.
Key Components, Values, and Defaults
SHD URL: https://health.aws.amazon.com/health/status (public, no auth required).
PHD Console: Accessible via AWS Management Console > Health > Dashboard (requires sign-in).
PHD API: The AWS Health API is the programmatic interface. Endpoint: health.us-east-1.amazonaws.com (global service, but must specify region).
Event retention: PHD events are retained for 90 days. After that, they are automatically deleted.
Event types: AWS_* prefixes for AWS-generated events (e.g., AWS_EC2_DEGRADED, AWS_RDS_MAINTENANCE).
CloudWatch Events integration: PHD events can be forwarded to Amazon EventBridge (formerly CloudWatch Events) to trigger automated actions. For example, you can create a rule that sends an SNS notification when an AWS_EC2_INSTANCE_RETIREMENT event occurs.
AWS Health Organizations view: If you are using AWS Organizations, you can enable the organizational view of PHD to see health events for all accounts in the organization. This requires enabling the AWS Health service for the organization.
Configuration and Verification Commands
To retrieve PHD events using the AWS CLI:
# List all events for the current account
aws health describe-events
# Filter events by service and region
aws health describe-events --filter "{\"services\":[\"EC2\"],\"regions\":[\"us-east-1\"]}"
# Get detailed event description
event_arn="arn:aws:health:us-east-1::event/EC2/AWS_EC2_INSTANCE_RETIREMENT/abc123"
aws health describe-event-details --event-arns $event_arn
# List affected entities for an event
aws health describe-affected-entities --filter "{\"eventArns\":[\"$event_arn\"]}"To enable AWS Health for an organization:
aws health enable-health-service-access-for-organizationTo verify organizational view:
aws health describe-health-service-status-for-organizationInteraction with Related Technologies
Amazon EventBridge (CloudWatch Events): PHD events are automatically sent to the default event bus in EventBridge. You can create rules to match specific event types and route them to targets like SNS, Lambda, SQS, or Step Functions.
AWS Config: While not directly integrated, you can use Config rules to evaluate resource compliance, but PHD focuses on health events, not configuration.
CloudWatch Metrics: CloudWatch monitors performance metrics; PHD monitors health events. They complement each other.
AWS Trusted Advisor: Provides recommendations based on best practices, while PHD provides events affecting your resources.
Common Misconfigurations and Pitfalls
Assuming SHD shows account-specific issues: SHD is global; it will not show your personal resource problems.
Not enabling AWS Health for organization: Without enabling the organizational view, you must check each account individually.
Ignoring event expiration: PHD events expire after 90 days. If you need long-term audit, export events to S3 or CloudWatch Logs.
Not setting up automated responses: Manually checking PHD is reactive. Use EventBridge to automate remediation.
Exam Tips
Know the difference: SHD = public, service-wide; PHD = authenticated, account-specific.
Remember that PHD integrates with EventBridge for automated actions.
Understand that PHD events have a 90-day retention and can be retrieved via API/CLI.
Be able to identify scenarios where you would use each dashboard.
Access the Service Health Dashboard
Open a web browser and navigate to https://health.aws.amazon.com/health/status. No authentication is required. The page displays a table of all AWS services across all regions with status indicators: green (operational), yellow (degraded), red (disruption). Click on a service to see detailed event descriptions. This step is passive monitoring—you are checking for broad AWS issues. For example, if your application in us-west-2 is slow, you check SHD to see if EC2 or RDS in that region is degraded. The SHD is updated by AWS operations teams; updates may have a latency of several minutes.
Access the Personal Health Dashboard
Sign in to the AWS Management Console, navigate to the Health Dashboard (under 'Services' > 'Management & Governance' > 'Health Dashboard'). Alternatively, you can access it directly via https://console.aws.amazon.com/health/home. The PHD shows events specific to your account, such as scheduled maintenance, resource retirements, or billing alerts. Each event has a severity (e.g., 'High', 'Medium', 'Low') and a status (open, closed, upcoming). You can filter by service, region, and event type. This step requires authentication and is the primary interface for personalized health monitoring.
Retrieve events via AWS CLI
Use the AWS CLI to programmatically list health events. First, configure the CLI with appropriate credentials. Run 'aws health describe-events' to get a list of events. You can filter by service (e.g., EC2), region, or event status. The output includes event ARNs, type codes, and timestamps. This step is useful for automation and integration with other tools. For example, you can write a script that checks for EC2 instance retirements and sends alerts. The CLI returns JSON output, which can be parsed by scripts.
Filter and examine affected entities
After obtaining an event ARN, use 'aws health describe-affected-entities' to see which specific resources are impacted. For example, if an event is 'AWS_EC2_INSTANCE_RETIREMENT', the affected entities will list the instance IDs. This step provides granular details needed for remediation. You can also filter by entity ARN to check if a particular resource is affected. The response includes the entity ARN, status, and last updated time.
Automate response with EventBridge
Create an Amazon EventBridge rule that matches health events from PHD. For example, a rule with event pattern: {"source": ["aws.health"], "detail-type": ["AWS Health Event"], "detail": {"service": ["EC2"], "eventTypeCode": ["AWS_EC2_INSTANCE_RETIREMENT"]}}. Set the target to an SNS topic, Lambda function, or Step Functions state machine. This step enables proactive remediation, such as automatically launching a replacement EC2 instance or notifying the operations team. The rule evaluates events in real-time as they are published.
Enterprise Scenario 1: E-Commerce Platform with Multi-Region Deployment
A large e-commerce company runs its application across three AWS regions (us-east-1, eu-west-1, ap-southeast-1) for high availability. The SysOps team uses the Service Health Dashboard to quickly identify if a regional outage is affecting their application. For example, if users in Europe report slow page loads, the team checks SHD for eu-west-1. If SHD shows 'EC2: Impaired', they know the issue is at the service level and may decide to fail over to another region. However, SHD does not tell them if their specific EC2 instances are affected. For that, they use PHD. They have configured EventBridge rules to send PHD events to a central SNS topic that pages the on-call engineer. When an EC2 instance retirement is scheduled, the rule triggers a Lambda function that automatically launches a replacement instance from an AMI and updates the load balancer target group. This automation reduces downtime from hours to minutes. The team also uses the AWS Health API to pull events into their internal ticketing system. They have learned that PHD events expire after 90 days, so they export events to S3 for long-term audit compliance.
Enterprise Scenario 2: Financial Services with Strict Compliance
A bank uses AWS for its core banking application and must comply with regulatory requirements for incident response. They use PHD to receive proactive notifications about scheduled maintenance and security advisories. The compliance team requires that all health events be logged and retained for at least 7 years. To meet this, they use EventBridge to forward all PHD events to CloudWatch Logs, which then streams to Amazon S3 via export. They also use AWS Organizations and have enabled the organizational view of PHD so that the security team can see health events across all 50 accounts. When a critical vulnerability like 'CVE-2025-1234' is announced, PHD shows an event with the affected services and accounts. The team uses the CLI to filter events by eventTypeCode and service to quickly identify which resources need patching. A common misconfiguration they encountered was forgetting to enable the organizational view, causing each account to only see its own events, which delayed response.
Scenario 3: SaaS Provider with Shared Responsibility
A SaaS company runs its multi-tenant application on AWS. They rely on the Service Health Dashboard to communicate with customers about AWS outages. If SHD shows a disruption, they post a status update on their own status page. However, for issues specific to their infrastructure (e.g., a failed EBS volume), they use PHD to get details and then notify affected customers. They have automated the creation of support cases: when a PHD event of severity 'High' occurs, an EventBridge rule triggers a Lambda function that opens a support case with AWS Support using the AWS Support API. This integration ensures that the support team has all relevant event details. They also discovered that not all AWS services are covered by PHD; for example, some older services may not generate events. They rely on CloudWatch metrics and custom health checks for those.
Exam Focus: AWS Service Health Dashboard and Personal Health Dashboard (Objective 1.2)
The SOA-C02 exam tests your ability to distinguish between the Service Health Dashboard (SHD) and Personal Health Dashboard (PHD) and to know how to integrate PHD with other services for automated response. Expect questions that present a scenario and ask which dashboard to use or how to react to a specific event.
Common Wrong Answers and Why Candidates Choose Them
Using SHD when PHD is needed: A question describes an EC2 instance scheduled for retirement. Candidates often pick 'Check the Service Health Dashboard' because they think all health info is there. Wrong: SHD only shows service-wide issues, not account-specific events. PHD is the correct answer.
Assuming PHD events are real-time: PHD events are published within minutes of detection, but candidates may think they are instantaneous. The exam might ask about latency; the correct answer is 'within a few minutes'.
Confusing retention periods: PHD retains events for 90 days. Candidates may think it's indefinite or 30 days. The exam tests this exact number.
Ignoring EventBridge integration: A question asks how to automate a response to a health event. Candidates might suggest manually checking or using CloudWatch alarms. The correct answer is to create an EventBridge rule matching the health event.
Specific Numbers, Values, and Terms
PHD event retention: 90 days.
SHD URL: https://health.aws.amazon.com/health/status (public).
PHD API endpoint: health.us-east-1.amazonaws.com (global service).
Event type code prefix: AWS_ (e.g., AWS_EC2_INSTANCE_RETIREMENT).
EventBridge source: aws.health.
Organizational view: Must be enabled via enable-health-service-access-for-organization.
Edge Cases and Exceptions
Events not generated for all services: Some older services may not publish health events. The exam may test that you should not rely solely on PHD for those services.
Cross-account events: In an organization, unless organizational view is enabled, events are only visible in the affected account.
Event statuses: 'open', 'closed', 'upcoming'. Know that 'upcoming' means scheduled future event.
How to Eliminate Wrong Answers
If the scenario mentions 'your specific EC2 instance' or 'account-specific', eliminate SHD.
If the question asks for 'real-time' or 'instant', look for options that acknowledge latency.
If automation is required, look for EventBridge (or CloudWatch Events) as the trigger.
If the question mentions 'retention' or 'history', remember 90 days.
Service Health Dashboard is public and shows service-wide status; Personal Health Dashboard is private and shows account-specific events.
Personal Health Dashboard events are retained for 90 days and can be retrieved via the AWS Health API or CLI.
PHD integrates with Amazon EventBridge to automate responses to health events.
To view health events across all accounts in an organization, enable the organizational view of AWS Health.
The AWS Health API endpoint is health.us-east-1.amazonaws.com (global service).
EventBridge rule source for health events is 'aws.health' and detail-type is 'AWS Health Event'.
These come up on the exam all the time. Here's how to tell them apart.
Service Health Dashboard
Publicly accessible without authentication
Shows service-wide events across all customers
URL: https://health.aws.amazon.com/health/status
Does not provide resource-specific details
Updated manually by AWS operations teams
Personal Health Dashboard
Requires AWS authentication (IAM credentials)
Shows events specific to your account and resources
Accessible via Console, CLI, or API
Provides resource ARNs and event descriptions
Events published automatically by AWS Health service
Mistake
The Service Health Dashboard shows events specific to my AWS account.
Correct
The SHD is a public dashboard that shows service-wide events across all customers. It does not show account-specific events like EC2 instance retirements. For account-specific events, use the Personal Health Dashboard.
Mistake
Personal Health Dashboard events are available indefinitely.
Correct
PHD events are retained for only 90 days. After that, they are automatically deleted. To retain events longer, you must export them to S3 or CloudWatch Logs.
Mistake
I can access the Personal Health Dashboard without signing in to AWS.
Correct
The PHD requires authentication via the AWS Management Console, CLI, or API. It is not publicly accessible. Only the Service Health Dashboard is public.
Mistake
All AWS services generate Personal Health Dashboard events.
Correct
Not all services are integrated with AWS Health. Some older or less critical services may not publish health events. You should use CloudWatch metrics and custom monitoring for those services.
Mistake
If I enable AWS Health for my organization, all accounts automatically see events from all other accounts.
Correct
Enabling the organizational view allows a management account to see events for all member accounts, but member accounts still only see their own events unless they also enable the organizational view. The management account must explicitly enable the feature.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Service Health Dashboard (SHD) is a public page showing the status of all AWS services across regions. It is useful for checking if a widespread outage is occurring. The Personal Health Dashboard (PHD) is a private, authenticated dashboard that shows events affecting your specific AWS account and resources, such as EC2 instance retirements or EBS volume degradation. For the exam, remember that SHD = global, PHD = personal.
PHD events are retained for 90 days from the event end time. After 90 days, they are automatically deleted. If you need to keep events longer, you must export them to Amazon S3 or CloudWatch Logs using a script or EventBridge rule.
Yes. PHD events are automatically sent to the default event bus in Amazon EventBridge (formerly CloudWatch Events). You can create EventBridge rules that match specific health events (e.g., EC2 instance retirement) and trigger targets such as AWS Lambda functions, SNS notifications, or Step Functions workflows.
You need to enable the organizational view of AWS Health. As the management account, run: aws health enable-health-service-access-for-organization. Then you can use the AWS Health API with the --organization flag to retrieve events for all member accounts. Note that member accounts cannot see each other's events unless they also enable this feature.
Use: aws health describe-events --filter '{"services":["EC2"],"regions":["us-east-1"]}'. You can also filter by event status (open/closed) and event type code. The response includes event ARNs, which you can then use with describe-affected-entities to see specific resources.
No. Not all services are integrated with the AWS Health service. Services like Amazon S3, EC2, RDS, and Lambda are supported, but some older or less critical services may not publish health events. For unsupported services, rely on CloudWatch metrics and custom health checks.
AWS-generated health events have event type codes that start with 'AWS_' followed by the service abbreviation and event name. For example, 'AWS_EC2_INSTANCE_RETIREMENT', 'AWS_RDS_MAINTENANCE', 'AWS_EBS_VOLUME_DEGRADED'. Custom events (if you publish your own) use 'CUSTOM_' prefix.
You've just covered AWS Service Health Dashboard and Personal Health — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?