- Newest
- Most votes
- Most comments
You can leverage AWS Health API. The AWS Health API provides access to the AWS Health information that appears in the AWS Health Dashboard. You can use the API operations to get information about events that might affect your AWS services and resources.
References:
Hope this helps.
Comment here if you have additional questions, happy to help.
Abhishek
You have personal health dashboard for service.
However, have you considered using event bridge to alert on aws health events and then react to them? I know you mention them in your question.
Then this can trigger your lambda function or step function to perform and action such as a fail over.
It's a great example, and yes, there are a number of reliable methods available here depending on how much real-time accuracy you require.
The AWS Health API is in fact more in line with your needs than you may realize; particularly the DescribeEvents and DescribeAffectedEntities functions are able to display active problems affecting services in specific regions. The drawback is that access to account-level health data requires a Business or Enterprise Support plan; if you have a lower tier plan then you'll only be able to see public events, which brings us to the following alternative.
AWS Service Health Dashboard (SHD) exposes a public RSS feed for each service and region. For example:
https://status.aws.amazon.com/rss/lambda-us-east-1.rsshttps://status.aws.amazon.com/rss/dynamodb-us-east-1.rss
You can programatically poll these feeds, parse the entries and check for any active incidents. Although it isn't a clean REST JSON endpoint, it is publicly accessible without the need for authentication and works satisfactorily for your routing logic.
For your specific /health endpoint strategy, I'd suggest combining both:
- It is reasonable to check the SHD RSS feed for your target services and regions every 60 seconds.
- Store the result internally in order that the /health check doesn't make an outgoing call with each incoming request.
- When an incident is detected for Lambda or DynamoDB in the us-east-1 region, switch the flag that your load balancer reads so as to direct traffic to us-east-2
This avoids the latency of a live outbound call sitting in your critical path while still keeping your routing decision reasonably fresh.
Relevant docs worth checking:
Hope that helps point you in the right direction.
answered 3 months ago
Relevant content
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
Thanks Abhishek. I've tried reading a little about the AWS Health APi, but havent been able to make sense of it yet for the purpose of me doing on-demand health checks on a given AWS resource. I can try looking into it more, but let me ask this 1 question about it. When you say it provides API operations to "get information about events", does that mean you can only use it to view active "events" or "incidents" happening, or can you use it to just check in on a service like SQS to see if it has any known current outages? I guess my question really is "what is an event"?
That's a very great question, Health API would give you the overall result and you'd need to add a logic to further parse it for specific service. Refer this documentation.
There are two types of AWS Health events:
Public events are service events that aren't specific to an account. For example, if there is an issue with Amazon EC2 in an AWS Region, AWS Health provides information about the event, even if you don't use services or resources in that Region.
Account-specific events are specific to your account or an account in your organization. For example, if there's an issue with an Amazon EC2 instance in a Region that you use, AWS Health provides information about the event and the list of affected Amazon EC2 instances.
Also, take a look at this blog post, which is very well written.
Important: I didn't mention this, AWS Health is only available to Business or Enterprise support plan. Hope you already have one of those.
Do you have any additional questions, happy to help.