Yes—AWS integrates with PagerDuty through CloudWatch, enabling automated incident alerting and on-call response workflows when your infrastructure detects problems.
Overview
AWS and PagerDuty work together to bridge infrastructure monitoring and incident management. When CloudWatch—AWS’s native monitoring service—detects an alarm condition (high CPU, failed health checks, API errors, or custom metrics), it can automatically trigger a PagerDuty incident. This eliminates manual notification delays and ensures the right on-call engineer gets paged immediately, with full context about what failed and where.
For IT teams managing production workloads on AWS, this integration is foundational. It transforms CloudWatch from a passive monitoring dashboard into an active incident response engine, routing alerts through PagerDuty’s escalation policies, notification channels, and incident tracking.
How the Integration Works
- CloudWatch Alarms as Triggers: You configure CloudWatch alarms in AWS for metrics like EC2 CPU utilization, RDS database connections, Lambda error rates, or custom application metrics. When an alarm transitions to the ALARM state, it sends a notification.
- SNS Topic Routing: CloudWatch alarms publish to an Amazon SNS (Simple Notification Service) topic. You configure this SNS topic to forward messages to PagerDuty’s integration endpoint, which acts as a subscription target.
- Incident Creation in PagerDuty: PagerDuty receives the alarm payload from SNS and automatically creates an incident. The incident includes the alarm name, description, metric value, and AWS account details, giving responders immediate context.
- Escalation and Notification: PagerDuty routes the incident through your configured escalation policy—paging the primary on-call engineer, then managers or backup teams if the incident isn’t acknowledged within a set time. Notifications go out via SMS, email, phone, or push notification based on user preferences.
- Bidirectional Workflow: When an engineer resolves the incident in PagerDuty, the resolution is logged. You can also manually resolve CloudWatch alarms in the AWS console, and both systems stay synchronized through proper configuration.
Key Features & Capabilities
- Automatic Incident Creation: Every CloudWatch alarm automatically becomes a PagerDuty incident with full AWS context—no manual ticket creation, no delays.
- Multi-Channel Alerting: Engineers receive notifications via their preferred channels (SMS, email, phone, Slack, mobile app), ensuring critical alerts don’t get missed.
- Escalation Policies: Define who gets paged first, second, and third based on time of day, team, or service. If the primary on-call engineer doesn’t acknowledge within 5 minutes, the incident escalates to a manager or backup team.
- Rich Alert Context: Incidents include the CloudWatch alarm description, metric name, threshold, and current value, so responders understand the problem before they even pick up the phone.
- Service Mapping: Link CloudWatch alarms to PagerDuty services (e.g., “Payment API,” “Database Cluster”) so incidents are grouped by business-critical component and tracked for SLA compliance.
- Incident Analytics: PagerDuty tracks response time, resolution time, and escalation patterns across all AWS-triggered incidents, helping you identify systemic issues and improve on-call processes.
Setup Difficulty: Medium
Setting up the AWS-PagerDuty integration takes 15–30 minutes and requires basic AWS and PagerDuty console access. No coding is required, but you’ll need to navigate IAM policies and SNS configuration.
High-level setup steps:
- In PagerDuty, create or select a service and generate an integration key (a unique URL endpoint).
- In AWS, create an SNS topic (or use an existing one) in the region where your CloudWatch alarms live.
- Add PagerDuty’s integration endpoint as an SNS subscription, using the integration key from step 1.
- Configure your CloudWatch alarms to publish to this SNS topic.
- Test by triggering a test alarm and verifying that a PagerDuty incident is created.
If you have dozens of alarms across multiple AWS regions or accounts, consider using AWS CloudFormation or Terraform to automate SNS topic and subscription creation. This reduces manual configuration and ensures consistency.
Alternatives & Workarounds
If the native CloudWatch-to-PagerDuty integration doesn’t meet your needs, consider these options:
- Zapier or Make (formerly Integromat): Low-code automation platforms that can listen for CloudWatch alarms via webhooks and create PagerDuty incidents with custom formatting or additional logic (e.g., enriching alerts with data from a CMDB or ticketing system).
- Custom Lambda Function: Write a Python or Node.js Lambda function triggered by SNS that transforms CloudWatch alarm data before sending it to PagerDuty. This gives you full control over incident title, severity, and custom fields.
- AWS EventBridge: For more complex routing rules, use EventBridge to listen for CloudWatch alarm state changes and conditionally route them to PagerDuty, Slack, or other targets based on alarm tags or metadata.
- Competing Incident Management Platforms: Datadog, New Relic, or Splunk offer their own native AWS integrations and incident management features. If you’re already using one of these for monitoring, you may not need PagerDuty.
Frequently Asked Questions
Do I need to modify my existing CloudWatch alarms to use PagerDuty?
No. You don’t need to change your alarm thresholds or logic. You simply add an SNS topic as an alarm action. Existing alarms will continue to work as before, and the SNS topic will forward notifications to PagerDuty in parallel with any other notification channels you’ve configured.
What happens if PagerDuty is unavailable—will I lose alerts?
SNS will retry delivery to PagerDuty for a limited time (default is 3 hours). If PagerDuty remains unreachable, you should have a fallback notification channel (e.g., email or SMS directly from CloudWatch) to ensure critical alerts don’t go unnoticed. Configure multiple SNS subscriptions for redundancy.
Can I send alerts from multiple AWS accounts to a single PagerDuty service?
Yes. Each AWS account can have its own SNS topic, and all topics can subscribe to the same PagerDuty integration endpoint. However, you’ll want to include the AWS account ID in the alarm description or use PagerDuty’s custom fields to distinguish which account triggered the incident.
How do I prevent alert fatigue from too many CloudWatch alarms?
Use PagerDuty’s alert grouping and deduplication features. Configure CloudWatch alarms to include consistent identifiers (e.g., service name, environment) so PagerDuty can merge related alarms into a single incident. You can also set alert thresholds more carefully and use composite alarms to reduce noise.