The intention of this documentation is to provide the building blocks to create critical CloudWatch alarms which are fit for onboarding to Incident Detection and Response. It contains specific alarm best practices for AWS Services commonly used in the Energy and Utilities Industries.
Overview
Energy and utilities organizations use AWS to power SCADA systems, grid monitoring, IoT telemetry ingestion, production surveillance, and renewable energy analytics. End users depend on reliable energy delivery. "Down" means grid instability, missed safety alerts, or loss of operational visibility over critical infrastructure.
Operational characteristics for Incident Detection and Response:
- 24/7 continuous monitoring — Grid operations and production systems run around the clock. There are no "off-peak" hours for safety-critical telemetry.
- High device count, low per-device throughput — IoT workloads ingest telemetry from thousands of sensors/devices. The critical signal is aggregate connection health and message throughput, not individual device metrics.
- Safety and compliance — Delayed telemetry can mask dangerous conditions. Energy and utilities workloads require timely alerting on data pipeline failures.
Baseline Alarms
For alarm configurations (metric names, thresholds, periods, statistics), see the individual IDR recommended AWS service articles linked below. This page identifies which services matter for energy & utilities workloads and why.
Critical Path Architecture
Energy & utilities workloads typically have two distinct critical paths:
Path 1 — IoT Telemetry Ingestion & Operational Monitoring
Sensors/Devices --> IoT Core --> Streaming Service (Kinesis)
--> Compute (Lambda/ECS) --> Data Store --> Alerting (SNS)
Path 2 — Operational Applications (SCADA dashboards, field apps, customer portals)
User/Operator --> ALB / API Gateway --> Compute (ECS/EKS/Lambda)
--> Data Store
Critical Path Services
| Service | Role in Workload | Why It Matters |
|---|
| IoT Core | Device connectivity and telemetry ingestion | Connection failures or throttling = blind spots in field monitoring; missed safety conditions |
| Kinesis Data Streams | Real-time telemetry streaming from devices | Processing lag means stale sensor data; delayed detection of anomalous readings |
| Lambda | Event processing, data transformation, rule execution | Errors or throttles block telemetry pipeline; safety alerts not generated |
| ECS / EKS | Operational applications, SCADA dashboards, field apps | Compute failures degrade operator visibility into grid/production state |
| Elastic Load Balancer | Entry point for operator dashboards and customer portals | Single point of failure for all human-facing applications |
| API Gateway | Device management APIs, external partner integrations | Errors block device provisioning and partner data exchange |
| RDS | Operational data, meter data, asset registry | Database unavailability = loss of historical context for operators |
| SNS | Safety alerts, operational notifications, SMS to field crews | Failed notifications = missed safety alerts, delayed field response |
| SQS | Command queues, async processing of telemetry batches | Queue backlog = delayed processing of sensor data |
Industry-Specific Threshold Considerations
| Service | Consideration | Reason |
|---|
| IoT Core | TreatMissingData = Breaching for connection metrics | Missing data from devices likely means devices are disconnected; this IS the failure mode |
| Kinesis | Lower iterator age tolerance than default | Stale telemetry data can mask safety-critical conditions in the field |
| SNS | Zero tolerance for failed notifications | Safety alerts (gas leak, voltage anomaly) cannot be missed |
| RDS | Lower storage space threshold | Meter data accumulates predictably; running out of space halts ingestion |
Reference Architectures
Power & Utilities (P&U) Workloads
Oil & Gas (O&G) Workloads
Industry-Specific Operational Notes
- Weather events — Severe weather drives both demand spikes and infrastructure damage. Alarm thresholds may need dynamic adjustment during storm seasons or extreme temperature events.
- Planned maintenance windows — Grid maintenance requires telemetry systems to remain operational for safety. Deployment freezes are common during maintenance windows.
- Regulatory reporting — Data pipeline failures that prevent compliance reporting need immediate response.
- Seasonal patterns — Utility demand follows seasonal curves (summer cooling, winter heating). Baseline telemetry volume changes predictably; use anomaly detection rather than static thresholds for traffic metrics.
- Edge/hybrid — Many energy workloads have an on-premises or edge component (substations, wellheads). IoT Core connection metrics are the bridge between edge and cloud visibility.