Order counts are continuously published as a CloudWatch custom metric. One-minute Sum varies by hour and weekday; normal history is available.
Notify SNS for both unusually high and low order counts without repeatedly flagging normal weekly peaks against a fixed threshold.
Which monitoring configuration is most appropriate?
Model the order-count Sum with anomaly detection and notify SNS for breaches above or below the expected band.
Detailed explanation
CPU usage is not the specified order-count signal.
CPU usage is not the specified order-count signal.
A displayed band alone does not notify SNS.
A displayed band alone does not notify SNS.
This does not adapt to the changing normal range or detect unusually low counts.
This does not adapt to the changing normal range or detect unusually low counts.
The model learns the metric/statistic's expected range and supports both breach directions.
The model learns the metric/statistic's expected range and supports both breach directions.
Check official documentation
Compare the following points with the official documentation.
Review the model statistic, band width, breach directions, and SNS action.
Official references
What to confirm
Separate graph overlays from notification alarms and explain training exclusions and sensitivity.
Key points
- Anomaly detection
- Expected band
- Seasonality
Notes
- Environment: AWS SOA-C03 exam guide and the linked AWS documentation
- Reviewed against the linked AWS documentation on 2026-10-04.
Foundation review
Match the metric and statistic
Models consider hourly, daily, and weekly patterns and are specific to a metric and statistic. A displayed band needs an alarm condition and SNS action for notification.
Tune training and sensitivity
Training uses up to two weeks, but a full two weeks is not required to enable it. Exclude unusual periods. Wider bands reduce breaches; review results rather than assuming perfect classification.