AWS site monitoring: watch your website from inside and outside AWS
Dashboard demo · sample data
Sample values only: your website is not checked. Real measurements start after sign-up.
Connect to Search ConsoleThis is the real dashboard layout with sample values. Hover over a chart to see daily values.
Monitor this website for realShort answer
To monitor a website hosted on AWS, combine two views. Inside AWS, Amazon CloudWatch collects metrics and logs from EC2, load balancers, Lambda, CloudFront and databases and raises alarms; Route 53 health checks and CloudWatch Synthetics canaries test endpoints from AWS locations. Outside AWS, an independent uptime monitor checks the site the way visitors reach it, so you still get an alert when an AWS region, your account or your monitoring itself has a problem. Track availability, response time, error rates (5xx), latency and resource use, and alert on symptoms visitors feel. monitordefend checks your site’s uptime and response time every five minutes from outside AWS and alerts by email.
- CloudWatch: metrics, logs and alarms for AWS resources.
- Route 53 health checks and Synthetics canaries: endpoint tests.
- External uptime monitoring: an independent view from outside AWS.
Hosting a website on Amazon Web Services gives you reliable infrastructure, but not a website that monitors itself. Instances run out of memory, deployments break pages, certificates and DNS settings get changed, autoscaling hits limits and, occasionally, an AWS service in a region has problems. AWS offers a rich set of monitoring tools, from CloudWatch to Route 53 health checks and synthetic canaries. This guide explains which of them to use for website monitoring, what they cost in effort, which metrics matter, and why an external monitor outside AWS belongs in every setup.
What AWS site monitoring involves
Monitoring a website on AWS means watching two things: the experience of visitors and the health of the AWS resources behind it. The first tells you whether there is a problem; the second helps you find out why. A complete setup measures availability and response time from outside, error rates and latency at the entry points, and resource metrics of the compute, database and storage services.
AWS provides the building blocks, but you have to assemble them: choose metrics, create alarms, decide who gets notified and keep the configuration up to date as your architecture changes.
Amazon CloudWatch
CloudWatch is the central monitoring service of AWS. Most services publish metrics there automatically: CPU utilisation of EC2 instances, request counts and latency of load balancers, error counts of API Gateway and Lambda, connections and storage of RDS databases, cache hit rates of CloudFront. Memory and disk usage of EC2 instances need the CloudWatch agent. CloudWatch Logs collects application and web server logs, and Logs Insights lets you query them.
- Visitor Browser, anywhere
- Route 53 & CloudFront DNS and CDN
- Load balancer Distributes requests
- EC2 / ECS / Lambda Your application
Alarms turn metrics into notifications. An alarm watches a metric, compares it with a threshold over a number of periods and triggers an action, typically a message to an Amazon SNS topic that forwards it to email, SMS, chat tools or incident platforms. Dashboards combine the most important metrics on one screen.
Route 53 health checks
Route 53 health checks request an endpoint from several AWS locations at regular intervals and mark it healthy or unhealthy. They can check HTTP and HTTPS status codes, look for a string in the response and measure from different regions. Their main purpose is DNS failover: Route 53 can stop sending traffic to an unhealthy endpoint. Combined with a CloudWatch alarm, they also work as a simple uptime monitor for public endpoints.
CloudWatch Synthetics canaries
Synthetics canaries are scripts that run on a schedule and test your website like a user: load a page, click through a flow, check an API, take screenshots and record load times. They catch broken user journeys that simple health checks miss, such as a failing login or checkout. Canaries need scripting and maintenance and are billed per run, so most teams reserve them for the few journeys that matter most.
Metric AWS/ApplicationELB · HTTPCode_Target_5XX_Count Statistic Sum over 5 minutes Threshold > 20 for 2 consecutive periods Action SNS topic → email / chat / on-call
Real user monitoring and Internet Monitor
CloudWatch RUM collects performance data and errors from real visitors’ browsers via a small script, including Core Web Vitals. Internet Monitor uses AWS’s view of global internet traffic to show availability and performance problems between your users and your application. Both are useful for larger applications with users in many regions.
Why you still need external monitoring
Monitoring that runs inside the same cloud shares some of its risks. If a region has a problem, alarms can be delayed; if an account is suspended, credentials expire or someone deletes the wrong configuration, the monitoring may go silent at the same moment as the website. And internal metrics do not always reflect what visitors see: an application can be healthy behind a misconfigured CDN, an expired certificate or a broken DNS record.
- Regional network problem affects the website
- Internal alarms delayed: monitoring in the same region
- External uptime monitor alerts: site down
- Region recovers, external monitor sends all-clear
An external uptime monitor run by a different provider checks the public URL the way visitors reach it. It is cheap, independent of your AWS configuration and gives you an uptime history you can compare with AWS’s own status information. Think of it as the smoke detector that does not depend on the building’s power.
Which metrics to watch
Alert on symptoms that visitors feel, such as errors and latency, and use resource metrics to diagnose. Alerts on every CPU spike create noise.
- Availability of the public URL from outside, every one to five minutes
- Response time from outside and p95/p99 latency at the load balancer
- 5xx error rate at load balancer, API Gateway or CloudFront
- Healthy host count behind the load balancer
- CPU, memory and disk of instances; throttles and errors of Lambda functions
- Database connections, CPU, free storage and replica lag
- Certificate expiry for certificates not managed by AWS Certificate Manager
Monitoring static sites on S3 and CloudFront
Static websites served from S3 through CloudFront have fewer moving parts, but they can still fail: an expired or misconfigured certificate, a changed bucket policy, a broken deployment that deletes files, or DNS mistakes. CloudFront publishes error rates and request counts to CloudWatch. An external uptime check of the homepage and a few key pages, plus a link check after each deployment, covers most risks.
Costs and effort
Basic CloudWatch metrics are included for most services; detailed metrics, custom metrics, alarms, logs, dashboards, health checks and canary runs are billed by usage. For small websites the cost is modest, but configuration effort is not: someone has to choose metrics, set thresholds and maintain alarms as the architecture changes. External uptime monitoring adds little cost and almost no maintenance.
A practical setup
For a typical website on AWS: an external uptime monitor for the public URLs; CloudWatch alarms for 5xx errors, latency and healthy hosts at the load balancer or CloudFront; resource alarms for the database and instances with generous thresholds; log retention and a few saved queries for troubleshooting; and notifications to a shared channel. Add Synthetics canaries for critical journeys once the basics are reliable.
What to do when an alert fires
Start with the outside view: is the site down for everyone, or only slow? Check the AWS Health Dashboard for service events in your region. Then follow the request path: DNS and certificate, CloudFront, load balancer health and error counts, application logs, database metrics. Recent deployments and configuration changes are the most frequent cause, so check them early.
monitordefend for websites on AWS
monitordefend provides the outside view: it checks each website’s URL every five minutes from servers in Germany, independent of AWS, confirms outages with a second attempt and alerts by email when the site is down or slower than your threshold. It does not integrate with CloudWatch or read AWS metrics. Its other checkers cover broken links, sitemap, indexing, traffic, checkout and security signals of the website itself.
Frequently asked questions
How do I monitor a website hosted on AWS?
Use CloudWatch metrics and alarms for your AWS resources, Route 53 health checks or Synthetics canaries for endpoints, and an external uptime monitor outside AWS for an independent view.
Does AWS have a website uptime monitor?
Route 53 health checks and CloudWatch Synthetics canaries can test public endpoints and trigger CloudWatch alarms. They run inside AWS.
Why use external monitoring if I have CloudWatch?
Because monitoring inside AWS can be affected by the same problems as your website, and internal metrics do not always show what visitors experience.
What should I alert on for a website on AWS?
Availability from outside, 5xx error rates, latency percentiles and unhealthy hosts. Use CPU and memory metrics mainly for diagnosis.
How much does CloudWatch monitoring cost?
Basic metrics are included for many services. Custom metrics, alarms, logs, health checks and canary runs are billed by usage.
Where should my external monitor run?
Outside AWS, at a different provider, so that it does not share failures with your website. A location near your main audience gives realistic response times.
How do I avoid alert fatigue with CloudWatch?
Alert on a few symptom metrics with thresholds over several periods, send warnings and critical alerts to different channels and review alarms that fire without action.
Can I monitor an S3 static website?
Yes. Use CloudFront metrics in CloudWatch and an external uptime check of the public URLs.
Related pages
Add an outside view to your AWS monitoring
Start for free and set up your first check in minutes.
Start for free