I tried testing the improvement of AWS Cost Anomaly Detection's "faster detection"

On November 21, 2025, AWS Cost Anomaly Detection received an update to its detection algorithm.

https://aws.amazon.com/about-aws/whats-new/2025/11/aws-cost-anomaly-detection-accelerates-anomaly/

According to the official announcement, the improved algorithm has achieved "reduction in false positives" and "faster detection." In this article, I will introduce the changes in behavior after the update and points to note regarding configuration, based on opportunities to check actual logs from three AWS accounts with different characteristics (verification, large-scale DB environment, and web production environment).

1. Verification: "Detection Time" Specifications in API Logs

I conducted a verification based on the hypothesis that if "detection has been accelerated," detailed timestamps of "when it occurred" might be recorded in the historical data.

Verification Environment

Data was collected from the following three environments:

• Account A (Verification): General resource configuration
• Account B (Large-scale DB): Environment where costs fluctuate by the minute, such as Aurora Serverless v2
• Account C (Web Production): Always-connected environment where App Runner / CloudWatch are running

Results of get-anomalies Execution

AWS CLI was used to retrieve anomaly detection data after the update was applied (November 22, 2025) in Account C (Web Production).

aws ce get-anomalies --date-interval Start=2025-11-20,End=2025-11-25

The output is as follows:

{
    "Anomalies": [
        {
            "AnomalyId": "695265a4-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "AnomalyStartDate": "2025-11-22T00:00:00Z",
            "AnomalyEndDate": "2025-11-22T00:00:00Z",
            "DimensionValue": "AmazonCloudWatch",
            "Impact": {
                "TotalActualSpend": 5.8,
                "TotalExpectedSpend": 2.51,
                "TotalImpactPercentage": 131.08
            }
        }
    ]
}

For comparison, I also checked the data from Account B (Large-scale DB) just before the update (November 18), which was in the same format.

{
    "AnomalyId": "f676f2d1-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "AnomalyStartDate": "2025-11-18T00:00:00Z",
    ...
}

Results

In all three environments, I confirmed that AnomalyStartDate is still normalized to T00:00:00Z (UTC 0:00).

I determined that since the Cost Explorer API's data granularity is designed based on "Daily," even if the backend detection engine is evaluating in near real-time, the specification rounds it to a daily bucket in the API response.

2. Verification: Identifying Actual Detection Times from Notification Logs

Since no changes could be read from the API records, I focused on the time when alerts were actually notified (SNS/Chatbot incoming logs).
For Account C, where the notification setting is IMMEDIATE, I plotted the notification arrival times (91 instances) for the past two months (2025/10/01-11/24).

Notification Arrival Time Trends

Analysis

Times such as 09:00 UTC on November 21 and 02:00 UTC on November 23 are clearly different from the rhythm of the conventional daily aggregation batch. These logs confirm that evaluations run as data arrives, and notification triggers are pulled immediately.

Also, while the official announcement was on November 21, I observed changes in notification patterns from around November 14 in the logs. This suggests a phased rollout was taking place in the backend.

3. Configuration Change Verification (Email Notification Constraints)

To benefit from the "rapid detection" provided by the update, the subscription notification frequency (Frequency) must be set to IMMEDIATE.
I attempted to change the configuration via CLI for Account A, which was set to DAILY.

aws ce update-anomaly-subscription \
    --subscription-arn "arn:aws:ce::XXXXXXXXXXXX:anomalysubscription/..." \
    --frequency IMMEDIATE

The execution resulted in the following error:

An error occurred (ValidationException) when calling the UpdateAnomalySubscription operation: 
Immediate frequencies only support SNSTopic subscriptions

Error Cause and Solution

As the error message indicates, "IMMEDIATE (instant notification)" is only supported when the notification destination is an SNS topic.

If an email address is registered directly, only DAILY or WEEKLY can be selected. With this configuration, even if detection itself is accelerated, notifications will be delayed until the next morning's summary email.

As a solution, I implemented the following configuration changes:

1. Create an Amazon SNS topic and subscribe email addresses to it.
2. Change the Cost Anomaly Detection notification destination to the created SNS topic.
3. Set the notification frequency to IMMEDIATE.

Summary: For Understanding Unexpected Cost Increases and Taking Initial Action

AWS Cost Anomaly Detection is very effective in quickly identifying unexpected cost increases, and this update significantly enhances its value.

Facts Confirmed by Verification

• Acceleration Achieved: Although the API log's T00:00:00Z remains unchanged, analysis of notification logs proves that rapid detection with rolling windows is functioning.
• Biggest Challenge: With direct delivery to email addresses (DAILY setting), notification is delayed even if detection is accelerated.

Immediate Steps to Take for Rapid Initial Response

If you need a quick initial response to cost anomalies, such as "taking measures like service suspension or resource reduction on the same day they are detected," I strongly recommend the following checks and reviews:

1. Check your current settings:

   aws ce get-anomaly-subscriptions
   

2. If settings are inappropriate:

   If the Frequency is set to DAILY or WEEKLY, notifications will be delayed until the next day or later, even if detection is accelerated. I recommend changing to IMMEDIATE and reviewing your notification method.

   In particular, if you have an email address as your notification destination, attempting to change to IMMEDIATE will result in a ValidationException. Therefore, please consider migrating to a configuration using an SNS topic.