Instructor: Carlos Rivas

Overview of the AWS Health Dashboard

The Health Dashboard is divided into 2 main sections:

Events that affect everyone (top left), and
Events that affect your account’s resources, right below that.

Let’s go over each one.

Service Health

First, you have Open and recent issues, this is where you can see current issues happening in the AWS Platform. More often than not, this option will show as disabled if there’s nothing of interest going on.

Service history on the other hand, will show a historic view of issues. This is really helpful if something happened over a weekend or holiday and you want to get details about which services and regions were affected.

Let’s look at an example of a possible outage:

Each one of these tickets will have: A header, showing the latest status , in this case “resolved” and a short description of the issue. In this case, “Increased API Error rates.”

You want to pay close attention to the affected services, in this case it’s a list of 20 services and chances are, that if you were using one of these services when this event happened in the US-EAST-1 regions, your application would have experienced similar problems.

Information like this is useful to shorten troubleshooting times and also to consider multi-region solutions if your business suffers a significant impact by an issue like this, in this particular AWS region.

Your account health

If we switch over to Your account health, this is where the Health Dashboard becomes really useful, because it correlates AWS Global issues with the resources and service that you are currently using. This way, you can see if there’s any impact to your business.

For example, let’s say you are running an EC2 instance and it’s been running nonstop for 12 months…

You may go here under the Scheduled events tab ( or, you may get it in an Email from AWS) and see something like this:

Essentially, this means that the physical hardware running your EC2 server may need to be taken down for repairs, upgrades or simply maintenance. – The solution is simple by he way: simply stop and restart your virtual EC2 instance and it will come online on a different physical computer, therefore allowing AWS to perform maintenance without further interruption to you or any other customers.

Integration with EventBridge

It’s totally understandable if you don’t want to have to manually visit a web page to find out if there’s an outage affecting your AWS infrastructure, for this, there’s a solution: EventBridge.

EventBridge can be used to monitor and react to AWS Health Dashboard events, and take certain actions including:

Sending a notification to the Ops team
Identifying affected resources, and
Executing custom lambda functions to perform pretty much any task, such as creating a Zendesk or JIRA ticket related to an AWS Scheduled maintenance event.

We will be looking at this in more detail, but here’s a pattern to catch Events related to notifications, scheduled changes or issues sent to your account via the Health Dashboard.

{

"detail": {

"eventTypeCategory": [

"issue",

"accountNotification",

"scheduledChange"

"service": [

"AUTOSCALING",

"VPC",

"EC2"

]

"detail-type": [

"AWS Health Event"

"source": [

"aws.health"

]

}

With this pattern in EventBridge you can quickly react to potential issues without human intervention and notify the right folks in order to decide what to do. Also note the Service filter here that includes AUTOSCALING, EC2 and VPC. This is important because if you are not using AWS S3 -for example- you don’t want to send out alerts if this service won’t impact you directly.