Skip to content

AWS Cost Anomaly Detection - How to Monitor Total Account Spending Instead of Per-Service?

0

I'm implementing AWS Cost Anomaly Detection using AWS CDK (CloudFormation CfnAnomalyMonitor) and need to monitor total account spending (sum of all services) rather than individual service-level monitoring for a single standalone account.

Problem: This configuration monitors each AWS service independently, which causes:

  • New service alerts: When we add a new AWS service and start using it, we immediately get anomaly alerts because it crosses the threshold with just one use
  • Scheduled job alerts: Our monthly PDA cron jobs trigger alerts every time they run, even though this is expected behavior
  • Noise from

individual services: Individual service fluctuations create unnecessary alerts What I Need I want to monitor the aggregate/total account spending across all services, so that:

  • New services are absorbed into the overall spending pattern
  • Monthly scheduled jobs are learned as part of the baseline
  • Only significant changes in total account cost trigger alerts (not individual service spikes)

What I've Tried I've reviewed the AWS Cost Anomaly Detection documentation, including: AWS::CE::AnomalyMonitor CloudFormation Reference CreateAnomalyMonitor API Reference Getting Started Guide

The documentation describes:

  • DIMENSIONAL monitors with SERVICE dimension - monitors each service independently (current setup)
  • DIMENSIONAL monitors with LINKED_ACCOUNT dimension - for AWS Organizations to monitor member accounts
  • CUSTOM monitors - for filtering specific subsets with MonitorSpecification

However, I cannot find clear documentation on how to configure a monitor for total account spending (sum of all services) for a single standalone account (not part of AWS Organizations).

Questions

  1. Is there a way to configure AWS Cost Anomaly Detection to monitor total account spending (aggregate of all services) for a single account?
  2. If using CUSTOM monitor type, what should the MonitorSpecification be to achieve account-level monitoring?
  3. If this isn't possible, what is the recommended approach to avoid alerts from new services and scheduled monthly jobs?
3 Answers
1

Hi, In the management account you can set up cost monitors within cost anomaly detection against service, account, cost allocation tag and cost category methods. If it is a standalone account, the services cost monitor will be available.

If you are using the notifications via the Alert subscriptions you can adjust the threshold.

Another suggestion is to also consider AWS Budgets for the account, in addition to cost anomaly detection.

AWS
answered a month ago
0

Based on AWS Cost Anomaly Detection's capabilities, you can configure monitoring at the total account level rather than per-service by using the appropriate monitor configuration.

Solution for Total Account Monitoring:

When creating your anomaly monitor, you have the flexibility to configure how costs are evaluated. You can choose to analyze all of your AWS services independently (which is your current setup causing the issues) or configure the monitor differently to evaluate aggregate spending patterns.

For a single standalone account, you should configure your monitor to evaluate costs at the account level rather than the service dimension. This allows the machine learning models to:

  • Learn your overall spending patterns including seasonal variations (weekly or monthly seasonality)
  • Recognize natural growth in your account
  • Absorb new service adoption into the baseline spending pattern
  • Account for scheduled workloads like your monthly PDA cron jobs as part of normal behavior

Addressing Your Specific Issues:

The machine learning models are designed to minimize false positive alerts by evaluating spend patterns over time. When you monitor at the aggregate account level instead of per-service:

  1. New services become part of your total spending baseline rather than triggering immediate alerts
  2. Scheduled jobs are learned as recurring patterns in your overall cost trend
  3. Individual service fluctuations are smoothed out in the aggregate view, reducing noise

Configuration Approach:

Instead of using a DIMENSIONAL monitor with SERVICE dimension, configure your monitor to evaluate total account costs. The service allows you to define spend segments you want to evaluate, and for your use case, you want the broadest segment (entire account) rather than granular service-level segments.

Alert Threshold Strategy:

When setting up your alert subscriptions, configure appropriate cost impact thresholds and alerting frequency (individual alerts, daily summary, or weekly summary) that align with your total account spending patterns. Start with conservative thresholds and refine them based on your actual usage patterns over time to minimize false positives while ensuring significant anomalies are caught.

This approach transforms the detection from a reactive per-service alert system into a proactive account-level financial monitoring strategy that understands your overall spending behavior.
Sources
Detecting unusual spend with AWS Cost Anomaly Detection - AWS Cost Management
COST01-BP06 Monitor cost proactively - AWS Well-Architected Framework
Determining the Right Threshold for Alerts in AWS Cost Anomaly Detection | AWS re:Post

answered a month ago
EXPERT
reviewed a month ago
0

Hello.

Unfortunately, I don't think there's a way to monitor the entire cost of a single AWS account using Cost Anomaly Detection.
However, if you're using AWS Organizations, you can detect anomalies in the total cost of a target AWS account.
Alternatively, if the AWS services you normally use support cost allocation tags, you can set up tags to detect anomalies in cost allocation tags.
https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html

EXPERT
answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.