Why should I monitor AWS instead of relying on their health dashboard?

AWS's health dashboard (health.aws.amazon.com) is notoriously slow to update during major outages — sometimes taking 30+ minutes to acknowledge issues. During the famous us-east-1 S3 outage, the dashboard itself was hosted on S3 and couldn't display the outage. External monitoring from outside AWS catches issues in 1-2 minutes and works even when AWS's own tools are down.

Which AWS endpoints should I monitor?

Rather than monitoring AWS APIs directly (which require Signature V4 auth), create simple health check endpoints: 1) A public S3 object (health.txt) to monitor S3 availability, 2) An API Gateway health endpoint for your APIs, 3) Lambda function URLs for serverless apps, 4) Your application's own health endpoint running on EC2/ECS/Fargate.

Monitor AWS API - Get Alerted on Infrastructure Issues

Q: Should I monitor from inside or outside AWS?

Monitor from outside AWS. If you monitor from within the same region, you won't detect regional outages or network connectivity issues that affect your users. UptimeSignal monitors from external infrastructure, so it detects issues that internal health checks like CloudWatch would miss.

Q: How do I monitor AWS services that require signed requests?

AWS APIs require Signature V4 authentication which most monitoring tools can't generate. Instead, create lightweight proxy endpoints: a public S3 object, an unauthenticated API Gateway health route, or a Lambda function URL. These let you monitor the underlying service without needing signed requests.

Monitor AWS API

Get alerted when AWS services have issues before your users notice downtime. Learn which services to monitor and how to set up proactive alerting for your infrastructure.

AWS runs a significant portion of the internet. When services like S3, Lambda, or API Gateway have issues, the blast radius is enormous. Your application may depend on dozens of AWS services, and an outage in any one of them can cascade through your entire stack. This guide covers how to monitor AWS from outside its own ecosystem.

Why Monitor AWS Externally?

AWS maintains a health dashboard at health.aws.amazon.com. So why set up external monitoring?

The problem with AWS's own monitoring

• Dashboard on affected infra: During the famous S3 outage, the AWS status dashboard itself was hosted on S3 and couldn't display the outage status
• Extremely slow updates: AWS's health dashboard can take 30+ minutes to acknowledge issues, sometimes longer than it takes to resolve them
• Regional blind spots: AWS outages are almost always region-specific. CloudWatch in the affected region may also be impacted
• Service-specific: S3 might be fine while Lambda is struggling. You need per-service monitoring for your specific dependencies

External monitoring from outside AWS catches issues that internal tools miss. If your monitoring runs on AWS and AWS is down, you won't know about it.

Which AWS Endpoints to Monitor

AWS APIs require Signature V4 authentication, so instead of monitoring APIs directly, create lightweight health check endpoints:

GET https://s3.{region}.amazonaws.com/{bucket}/health.txt

Upload a public health.txt file to S3. If it's unreachable, S3 in your region is down.

Critical

GET https://{api-id}.execute-api.{region}.amazonaws.com/health

API Gateway health endpoint. Create an unauthenticated /health route that returns 200.

Critical

GET https://{function-url}.lambda-url.{region}.on.aws/

Lambda function URL. Direct monitoring of your serverless functions without API Gateway.

High

GET https://your-app.{region}.elb.amazonaws.com/health

Your application's health endpoint behind an ALB/ELB. Tests the full stack.

High

GET https://{distribution}.cloudfront.net/health

CloudFront distribution health. Tests CDN availability for your static assets.

Medium

Strategy tip: Monitor your endpoints, not AWS's APIs directly. Create simple canary endpoints that exercise your AWS dependencies. A Lambda function that reads from S3 and writes to DynamoDB is a better health check than monitoring each service individually.

How to Set Up AWS Monitoring

Create health check endpoints

Upload a simple health.txt to a public S3 bucket. Add an unauthenticated /health route to your API Gateway. Create a Lambda function URL that tests your critical dependencies.

Add monitors in UptimeSignal

Create HTTP monitors for each health endpoint:

URL: https://s3.us-east-1.amazonaws.com/your-bucket/health.txt

Method: GET

Expected status: 200

Body contains: ok

Configure alerting

Set up alerts that work even when AWS is down:

• Email -- Immediate notification (not dependent on AWS)
• Slack -- Alert your infrastructure team
• PagerDuty/Webhook -- Critical for production incidents

Monitor multiple regions

If you run multi-region, add monitors for each region's health endpoints. AWS outages are almost always region-specific.

What to Watch For

Configure your monitors to alert on these conditions:

HTTP Status

200 -- Service is responding
403 -- Permission/auth issue (check IAM)
500, 502, 503 -- AWS service issue

Response Time

< 500ms -- Normal for most services
500ms-2s -- Degraded (Lambda cold start?)
> 2s -- Severe latency, investigate

Response body validation

For your health endpoints, check that the response body contains expected content (like "status":"healthy"). This catches cases where a CDN or load balancer returns a 200 with an error page instead of your actual application response.

When AWS Goes Down: Response Playbook

When your monitoring alerts you to an AWS issue, here's how to respond:

1. Identify the scope

Determine which region and services are affected. Check health.aws.amazon.com (if accessible) and Twitter for @AWSSupport. Your monitoring data will often be more current.

2. Failover if multi-region

If you have multi-region infrastructure, failover to your backup region. Update DNS records (Route 53 in another region, or an external DNS provider) to route traffic away from the affected region.

3. Communicate proactively

Update your status page and notify affected customers. "We're experiencing issues due to an AWS service disruption" is better than silence.

4. Enable degraded mode

If failover isn't available, enable a degraded mode: serve cached content, disable non-essential features, and queue operations for later processing. Even limited functionality is better than a full outage.

Frequently Asked Questions

Why monitor AWS instead of relying on their health dashboard?

AWS's health dashboard is notoriously slow to update during major outages -- sometimes taking 30+ minutes to acknowledge issues. During the famous S3 outage, the dashboard itself was hosted on S3 and couldn't display the outage status. External monitoring from outside AWS catches issues in 1-2 minutes and works even when AWS's own tools are down.

Which AWS services should I monitor?

Rather than monitoring AWS APIs directly (which require Signature V4 auth), create simple health check endpoints: a public S3 object for storage, an API Gateway /health route, Lambda function URLs for serverless, and your application's health endpoint. Monitor the services you depend on, not all of AWS.

Can I monitor AWS for free?

Yes. UptimeSignal's free tier includes 25 monitors with 5-minute check intervals. You can monitor multiple AWS endpoints plus your own API and website. Commercial use is allowed on the free tier.

Should I monitor from inside or outside AWS?

Monitor from outside AWS. If your monitoring runs within the same region and that region goes down, you won't detect the outage. UptimeSignal runs on infrastructure outside AWS, so it detects issues that internal health checks like CloudWatch would miss entirely.

How do I monitor services that require signed requests?

AWS APIs require Signature V4 authentication. Instead of trying to monitor them directly, create lightweight proxy endpoints: a public S3 object, an unauthenticated API Gateway health route, or a Lambda function URL. These let you monitor the underlying AWS service availability without needing signed requests.

Monitor Other APIs