This chapter covers AWS CloudTrail Insights, a feature that automatically detects unusual API activity in your AWS account. For the SOA-C02 exam, understanding CloudTrail Insights is critical because it appears in questions about monitoring, security, and operational troubleshooting—roughly 5-8% of exam questions touch on CloudTrail or related monitoring services. You will need to know how Insights works, how to enable it, what it detects, and how it differs from standard CloudTrail event logging. This chapter provides the depth required to answer exam questions confidently, including specific configuration steps, pricing considerations, and common pitfalls.
Jump to a section
Imagine a security guard monitoring a building's entrance. Normally, employees enter between 8-10 AM, take lunch breaks, and leave by 6 PM. The guard logs every entry and exit, but only reviews logs if an incident occurs. CloudTrail Insights is like hiring a detective who constantly studies the logs in real time. The detective learns the baseline: typical entry times, duration of stays, and frequency of visits. One day, the detective notices an employee entering at 3 AM and staying only 2 minutes—unusual compared to their normal 9-hour workday. The detective immediately flags this as an anomaly. Similarly, CloudTrail Insights establishes a baseline of normal API call patterns (e.g., number of calls per hour, types of operations, error rates) and continuously analyzes new events against that baseline. When it detects a deviation—like a sudden spike in DeleteBucket calls from an unfamiliar IP—it generates an Insights event. The detective doesn't stop there; they correlate multiple anomalies: the same employee using a badge to enter a restricted area they never visit, at an odd hour. CloudTrail Insights can also correlate multiple unusual API calls (e.g., excessive DescribeInstances followed by TerminateInstances) to surface a potential security threat. The key is that Insights is not a rule-based alert—it's statistical anomaly detection that adapts to changing baselines, just as the detective learns new patterns over time (e.g., after a policy change).
What is CloudTrail Insights?
AWS CloudTrail Insights is an optional feature of AWS CloudTrail that uses machine learning models to automatically detect unusual API activity in your AWS account. Unlike standard CloudTrail event history, which records every API call as a management event, Insights analyzes the volume and timing of those events to establish a baseline of normal behavior. When it detects deviations from that baseline—such as a sudden spike in error rates, a surge in calls to a specific API, or unusual patterns of access—it generates an Insights event. This event is logged in a separate Insights trail, which you can view in the CloudTrail console, via the AWS CLI, or through integration with Amazon CloudWatch and AWS Lambda.
Why CloudTrail Insights Exists
Standard CloudTrail logs can be overwhelming—even a modest AWS account can generate thousands of events per hour. Manually sifting through these logs to identify security incidents or operational issues is impractical. Traditional rule-based alerting (e.g., CloudWatch alarms) requires you to know what to look for in advance, but you cannot anticipate every type of anomalous behavior. CloudTrail Insights addresses this by automatically learning what 'normal' looks like for your account and flagging deviations without requiring you to define explicit thresholds. This is particularly valuable for detecting:
Compromised credentials: an attacker using stolen keys to make API calls at unusual times or from unusual locations.
Misconfigurations: a script that accidentally calls TerminateInstances thousands of times.
Insider threats: an employee performing actions they don't normally perform, like deleting S3 buckets.
Operational anomalies: a sudden increase in throttling errors indicating a resource bottleneck.
How CloudTrail Insights Works Internally
CloudTrail Insights operates by continuously analyzing management events that CloudTrail records. Here is a step-by-step breakdown of the mechanism:
Baseline Establishment: When you enable Insights on a trail, it begins collecting data on the volume of API calls per API name (e.g., RunInstances, DescribeInstances, DeleteBucket) and per error code (e.g., AccessDenied, ThrottlingException). It groups events by 5-minute intervals. Over a learning period (typically 7 days), it builds a statistical model of the expected number of calls and error rates for each API and error code. The baseline is dynamic—it updates continuously as new events arrive, so it adapts to gradual changes in usage patterns.
2. Anomaly Detection: After the baseline is established, Insights compares each new 5-minute window of events against the expected range. It uses a statistical technique called 'density-based clustering' to identify outliers. Specifically, it calculates the probability of observing the current volume given the historical distribution. If the probability is below a certain threshold (the default is 0.01, meaning a 1% chance or less), the event is flagged as anomalous. Insights detects two types of anomalies: - Volume anomalies: A significant increase or decrease in the number of calls to a specific API. For example, if your account normally makes 100 DescribeInstances calls per hour but suddenly makes 10,000 in one hour, that is a volume anomaly. - Error rate anomalies: A significant increase in the rate of errors for a specific API. For example, if your account normally has a 0.1% error rate on PutObject but suddenly has a 50% error rate, that is an error rate anomaly.
Insights Event Generation: When an anomaly is detected, CloudTrail records an Insights event in the trail. This event is not a copy of the individual API calls—it is a summary event that describes the anomaly. The Insights event includes:
- Event type: AwsCloudTrailInsight
- Insight type: ApiCallRateInsight or ApiErrorRateInsight
- Event time: the start and end time of the anomalous period
- Associated API name: the API that triggered the anomaly (e.g., DeleteBucket)
- Baseline details: the expected volume and actual volume, or expected error rate and actual error rate
- Insight state: either Start (the beginning of the anomalous period) or End (when the anomaly returns to baseline)
- Insight context: a summary of the anomaly, such as "The number of calls to DeleteBucket increased by 500% compared to the baseline."
Delivery: Insights events are delivered to the same Amazon S3 bucket and CloudWatch Logs log group as the trail's management events, but they are stored in a separate prefix (e.g., CloudTrail-Insight/). You can also configure the trail to send Insights events to CloudWatch Logs for real-time monitoring and alerting.
Key Components, Values, Defaults, and Timers
Trail requirement: CloudTrail Insights can only be enabled on a trail that is logging management events. It is not available for data events. You must use a trail that applies to all regions (multi-region trail) or a single-region trail. Insights is supported for both.
Learning period: The initial baseline requires approximately 7 days of data. During this period, Insights does not generate any anomaly events. After the baseline is established, Insights continuously updates it with a sliding window of the most recent data (typically 7 days of historical data).
Anomaly threshold: The default statistical threshold is 0.01 (1% probability). This means that only events that have a 1% or lower chance of occurring under normal conditions are flagged. You cannot adjust this threshold via the console or CLI—it is fixed by the service.
Event frequency: Insights evaluates events in 5-minute intervals. An anomaly must persist for at least one full interval to be reported.
Retention: Insights events are retained for the same period as the trail's management events, based on the S3 bucket's lifecycle policy and CloudWatch Logs retention settings.
Pricing: CloudTrail Insights charges based on the number of management events analyzed. The first 1 million events per month are free; beyond that, you pay $0.50 per million events analyzed. There is no additional charge for storing Insights events in S3 (standard S3 rates apply).
Configuration and Verification Commands
#### Enabling CloudTrail Insights via AWS CLI
# Create a new trail with Insights enabled
aws cloudtrail create-trail --name my-insights-trail --s3-bucket-name my-bucket --is-multi-region-trail --enable-insight-selectors '[{"InsightType": "ApiCallRateInsight"}]'
# Update an existing trail to enable Insights
aws cloudtrail put-insight-selectors --trail-name my-trail --insight-selectors '[{"InsightType": "ApiCallRateInsight"}, {"InsightType": "ApiErrorRateInsight"}]'#### Viewing Insights Events
# List Insights events for a trail
aws cloudtrail list-insight-selectors --trail-name my-trail
# Lookup Insights events (use --insight-type parameter)
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventId,AttributeValue=example-insight-event-id
# Get a specific Insights event by ID
aws cloudtrail get-insight-selectors --trail-name my-trail#### Verifying Insights is Enabled
# Check the insight selectors on a trail
aws cloudtrail get-insight-selectors --trail-name my-trail
# Output should show the insight types enabledInteraction with Related Technologies
Amazon CloudWatch: You can configure the trail to send Insights events to CloudWatch Logs. Then, you can create metric filters and alarms to trigger notifications (e.g., SNS) when certain Insights events occur. For example, you could alert on an ApiCallRateInsight for DeleteBucket.
AWS Lambda: You can trigger a Lambda function from CloudWatch Logs when an Insights event is logged. This allows automated response, such as revoking IAM keys or disabling a compromised instance.
Amazon S3: Insights events are stored in S3 under the prefix CloudTrail-Insight/. You can use S3 events to trigger workflows when new Insights events are delivered.
AWS Config: While not directly integrated, you can correlate Insights events with Config rule changes to understand the context of an anomaly.
AWS Security Hub: CloudTrail Insights events can be ingested into Security Hub as findings, providing a centralized view of security anomalies.
Limitations
Insights only analyzes management events, not data events (e.g., S3 object-level operations).
It does not analyze read-only events separately from write events—both are included in the same baseline.
The baseline is account-specific and region-specific. If you have multiple accounts, you must enable Insights on each account's trail.
Insights does not detect anomalies based on geographic location, source IP, or user identity—it only looks at volume and error rates per API.
The learning period of 7 days means that new accounts or accounts with rapidly changing usage patterns may not have accurate baselines immediately.
Enable CloudTrail Insights on a Trail
To enable CloudTrail Insights, you must first have a trail that logs management events. You can create a new trail or modify an existing one. In the AWS Management Console, navigate to CloudTrail, select your trail, and under 'Insights events', choose 'Configure'. Select the insight types you want: 'API call rate' and/or 'API error rate'. Alternatively, use the CLI as shown earlier. Once enabled, CloudTrail begins collecting baseline data. Note that Insights cannot be enabled on trails that are logging data events only—management events are required. Also, Insights is not supported in the CloudTrail event history (the 90-day default view); you must have a trail configured.
Baseline Collection and Learning Period
After enabling Insights, CloudTrail starts collecting data on the volume of API calls and error rates per API. The learning period lasts approximately 7 days. During this time, no Insights events are generated because the baseline is not yet established. The baseline is built from the last 7 days of data and is updated continuously. If you enable Insights on a trail that already has 7 days of management events logged, the baseline can be established more quickly—CloudTrail uses historical data if available. However, the official learning period is still 7 days from enablement. You can monitor the status of the baseline via the CloudTrail console, where it shows 'Baseline established' once ready.
Detection of Anomalous Activity
Once the baseline is established, CloudTrail evaluates each 5-minute window of management events. For each API and error code, it compares the observed volume/error rate to the expected range derived from the baseline. If the probability of the observed value is below 0.01 (1%), an anomaly is detected. The anomaly is recorded as an Insights event. For example, if your account normally makes 50 DescribeInstances calls per hour but suddenly makes 5,000 in one hour, that triggers a volume anomaly. Similarly, if the error rate for DeleteObject jumps from 0.5% to 30%, that triggers an error rate anomaly. The Insights event includes the start time of the anomaly.
Generation and Delivery of Insights Event
When an anomaly is detected, CloudTrail generates an Insights event with type 'AwsCloudTrailInsight'. The event is delivered to the same S3 bucket as the trail's management events, under the prefix 'CloudTrail-Insight/'. It is also delivered to the CloudWatch Logs log group if configured. The event contains details such as the insight type (ApiCallRateInsight or ApiErrorRateInsight), the associated API name, the baseline and actual values, and the time range. An 'End' event is generated when the anomaly resolves (i.e., the activity returns to baseline). This allows you to track the duration of the anomaly.
Review and Respond to Insights Events
You can review Insights events in the CloudTrail console under 'Insights' tab. They appear as separate entries from management events. You can also query them using the AWS CLI or via CloudWatch Logs Insights. For automated response, set up CloudWatch alarms on the Insights events. For example, create a metric filter for 'ApiCallRateInsight' and trigger a Lambda function to investigate. Alternatively, use AWS Security Hub to aggregate Insights events as findings. It is important to note that Insights events are not real-time—there is a delay of up to 15 minutes from the anomaly occurrence to the event delivery. This is because the analysis is performed on 5-minute windows and then processed.
Scenario 1: Detecting Compromised Credentials
A financial services company uses CloudTrail Insights across all production accounts. One day, Insights detects a volume anomaly for the DescribeInstances API call in an account that normally averages 200 calls per hour. The anomaly shows 12,000 calls in a 5-minute window from an IP address outside the corporate network. The security team investigates using the Insights event context and finds that an IAM user's access keys were leaked. They immediately rotate the keys and block the IP. Without Insights, this attack might have gone unnoticed for days because standard CloudTrail logs are not continuously monitored for volume changes. The company configured a CloudWatch alarm on Insights events to trigger an SNS notification to the security team, reducing response time to under 30 minutes.
Scenario 2: Troubleshooting Application Error Spikes
An e-commerce platform experiences intermittent errors during flash sales. The operations team enables CloudTrail Insights and notices an error rate anomaly for the PutObject API call during a sale event. The error rate spikes from a baseline of 0.2% to 15%. The Insights event reveals that the errors are AccessDenied. The team discovers that an S3 bucket policy was recently changed, inadvertently denying write access to the application's IAM role. They revert the policy and the error rate returns to normal. This proactive detection prevented a prolonged outage. The team now uses Insights to monitor error rate anomalies for all critical APIs and has automated remediation via Lambda.
Scenario 3: Insider Threat Detection
A healthcare organization requires strict monitoring of access to patient data. They enable CloudTrail Insights on trails covering all management events. One day, Insights flags a volume anomaly for GetObject calls on an S3 bucket containing protected health information. The anomaly shows a 300% increase over baseline from a specific IAM user. The user is a system administrator who normally makes fewer than 10 GetObject calls per day but suddenly made 500 calls in one hour. The security team investigates and finds that the user was downloading patient records without authorization. The organization uses this information to revoke access and initiate disciplinary action. Insights provided the early warning that would have been missed by standard logging.
Common Misconfigurations and Pitfalls
Not enabling Insights on all regions: If you use a single-region trail but have resources in multiple regions, you might miss anomalies in other regions. Use a multi-region trail for comprehensive coverage.
Ignoring the learning period: New accounts or accounts with recent major changes (e.g., migrating workloads) will have inaccurate baselines. Wait at least 7 days before relying on Insights for alerts.
Over-reliance on Insights alone: Insights only detects volume and error rate anomalies. It does not detect anomalies based on source IP, user identity, or geographic location. Combine Insights with other services like GuardDuty for comprehensive threat detection.
Not setting up automated response: Insights events are useful only if someone reviews them. Use CloudWatch alarms and Lambda to automate remediation or notification.
What SOA-C02 Tests
SOA-C02 objective 1.2 specifically mentions 'Implement and manage monitoring and reporting solutions' which includes CloudTrail. Exam questions on CloudTrail Insights focus on:
Understanding that Insights is an optional feature that detects unusual API activity.
Knowing the two types of insights: ApiCallRateInsight and ApiErrorRateInsight.
Recognizing that Insights requires a trail logging management events.
The 7-day learning period before Insights becomes active.
That Insights events are stored in the same S3 bucket under a separate prefix (CloudTrail-Insight/).
That Insights does not analyze data events.
Pricing: first 1 million events free, then $0.50 per million.
Common Wrong Answers
'CloudTrail Insights can detect anomalies based on source IP address.' This is false. Insights only looks at volume and error rates per API. For IP-based anomalies, use GuardDuty.
'CloudTrail Insights analyzes data events by default.' False. Insights only analyzes management events. Data events require separate configuration and are not analyzed by Insights.
'You can configure the anomaly threshold for CloudTrail Insights.' False. The threshold is fixed at 0.01 (1% probability). You cannot change it.
'CloudTrail Insights provides real-time detection.' False. There is up to a 15-minute delay due to the 5-minute evaluation window and processing time.
Key Numbers and Terms
7 days: learning period.
5 minutes: evaluation window.
0.01: default statistical threshold.
ApiCallRateInsight and ApiErrorRateInsight: the two insight types.
AwsCloudTrailInsight: event type for Insights events.
CloudTrail-Insight/: S3 prefix for Insights events.
$0.50 per million events after first 1 million free.
Edge Cases
Trail with existing 7 days of data: If you enable Insights on a trail that already has 7 days of management events, the baseline may be established faster, but officially it still takes 7 days.
Disabling and re-enabling Insights: If you disable Insights and re-enable it later, the baseline is reset and a new 7-day learning period begins.
Multiple trails: You can enable Insights on multiple trails, but each trail has its own baseline. The cost is aggregated per account.
How to Eliminate Wrong Answers
Look for keywords: If a question mentions 'unusual API activity', 'anomaly detection', or 'baseline', the answer likely involves CloudTrail Insights.
Eliminate options that mention 'data events' or 'real-time'.
If the question asks about 'source IP', 'user identity', or 'geographic location', the answer is not CloudTrail Insights.
Remember that Insights is a 'detective' control, not 'preventive'.
CloudTrail Insights detects unusual API activity by analyzing volume and error rate anomalies for management events.
Insights requires a trail logging management events; it does not analyze data events.
There is a 7-day learning period before Insights starts generating anomaly events.
Anomalies are detected based on a fixed 1% probability threshold (0.01).
Insights events are stored in the same S3 bucket under the prefix 'CloudTrail-Insight/'.
Two insight types: ApiCallRateInsight and ApiErrorRateInsight.
Pricing: first 1 million events per month free, $0.50 per million events thereafter.
CloudTrail Insights is not real-time; events have up to a 15-minute delay.
Combine Insights with CloudWatch alarms and Lambda for automated response.
Insights is a detective control, not preventive.
These come up on the exam all the time. Here's how to tell them apart.
CloudTrail Insights
Detects unusual API activity based on volume and error rate anomalies.
Analyzes CloudTrail management events only.
Uses statistical baseline with fixed threshold (1% probability).
No additional cost for the first 1 million events per month; $0.50 per million thereafter.
Provides summary Insights events, not individual threat details.
Amazon GuardDuty
Detects threats using threat intelligence and machine learning, including unusual API calls, network traffic, and DNS requests.
Analyzes multiple data sources: CloudTrail, VPC Flow Logs, DNS logs, and more.
Uses curated threat intelligence and ML models to identify known and unknown threats.
Pricing based on data source volume: CloudTrail events ($4 per million events), VPC Flow Logs ($0.05 per GB), DNS logs ($0.05 per GB).
Generates detailed findings with severity levels, threat types, and recommended actions.
Mistake
CloudTrail Insights can detect anomalies in real time.
Correct
Insights events are delivered with up to a 15-minute delay because they are based on 5-minute evaluation windows plus processing time. It is not real-time.
Mistake
CloudTrail Insights analyzes all API calls, including data events like S3 object-level operations.
Correct
Insights only analyzes management events (e.g., CreateBucket, DeleteBucket). Data events (e.g., GetObject, PutObject) are not analyzed by Insights.
Mistake
You can set custom thresholds for what constitutes an anomaly in CloudTrail Insights.
Correct
The anomaly threshold is fixed at a 1% probability (0.01). You cannot adjust it via the console, CLI, or API.
Mistake
CloudTrail Insights provides a detailed log of every anomalous API call.
Correct
Insights events are summary events that describe the anomaly (e.g., 'calls increased by 500%'). They do not include individual API call details. To see the individual calls, you must look at the standard management events in CloudTrail.
Mistake
CloudTrail Insights works immediately after enabling it.
Correct
There is a 7-day learning period during which Insights collects baseline data and does not generate any anomaly events. Only after the baseline is established does it begin detecting anomalies.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can enable CloudTrail Insights on an existing trail via the AWS Management Console, CLI, or SDK. In the console, navigate to CloudTrail, select your trail, and under the 'Insights events' section, click 'Configure'. Choose the insight types you want (API call rate and/or API error rate) and click 'Save'. Using the CLI, run `aws cloudtrail put-insight-selectors --trail-name my-trail --insight-selectors '[{"InsightType": "ApiCallRateInsight"}, {"InsightType": "ApiErrorRateInsight"}]'`. The trail must already be logging management events. After enabling, there is a 7-day learning period before Insights generates events.
CloudTrail events are the standard logs that record every API call made in your account. They provide detailed information about each call, such as who made it, when, and what the response was. CloudTrail Insights, on the other hand, analyzes the volume and error rates of those events to detect anomalies. Insights events are summary events that indicate unusual activity (e.g., 'calls to DeleteBucket increased by 500%'). While standard events are useful for auditing and troubleshooting individual actions, Insights is designed for proactive detection of operational and security anomalies.
No. CloudTrail Insights only analyzes management events. Data events, such as S3 object-level operations (GetObject, PutObject) or Lambda function invocations, are not analyzed by Insights. If you need anomaly detection for data events, consider using Amazon GuardDuty or custom solutions with CloudWatch Logs Insights.
After enabling Insights, there is a 7-day learning period during which CloudTrail collects baseline data. During this period, no Insights events are generated. After the baseline is established, Insights begins detecting anomalies. If the trail already has 7 days of management events logged, the baseline may be established more quickly, but the official learning period is still 7 days.
No, the sensitivity (anomaly threshold) is fixed at a 1% probability (0.01). You cannot change this threshold. If you need more or less sensitive detection, you would need to implement a custom solution using standard CloudTrail logs and your own statistical analysis.
When an anomaly is detected, CloudTrail generates an Insights event with type 'AwsCloudTrailInsight'. This event is delivered to the same S3 bucket as the trail's management events, under the prefix 'CloudTrail-Insight/'. If configured, it is also sent to CloudWatch Logs. The event includes details such as the insight type (ApiCallRateInsight or ApiErrorRateInsight), the associated API name, the baseline and actual values, and the time range. An 'End' event is generated when the anomaly resolves.
CloudTrail Insights pricing is based on the number of management events analyzed. The first 1 million events per month are free. After that, you pay $0.50 per million events. There is no additional charge for storing Insights events in S3 (standard S3 rates apply) or for sending them to CloudWatch Logs (standard CloudWatch Logs rates apply).
You've just covered CloudTrail Insights for Unusual API Activity — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?