AWS CloudTrail Event Types: Management, Data, Network, Insights

CloudTrail log types explained

Most teams already have management events running (they are on by default). The next step is usually adding data events for your most sensitive S3 buckets and Lambda functions. Network activity events and Insights are worth enabling once you understand your account’s traffic patterns and have a clear security or compliance driver.

Why this matters

Security visibility. Management events alone do not show data access. If an attacker assumes a role and downloads thousands of S3 objects, management events will show the AssumeRole call but nothing about the data exfiltration. You need data events for that. For patterns to watch for, see detecting suspicious activity in AWS logs.

Auditability. Compliance frameworks like PCI-DSS, HIPAA, and SOC 2 often require evidence of who accessed what data and when. Data events provide that evidence for S3, DynamoDB, and other services. Network activity events prove that API calls stayed within your private network boundary.

Cost control. Enabling every event type on every resource can cost thousands of dollars per month in a busy account. Understanding the four types lets you enable the right logging for the right resources: full coverage where it matters, selective logging everywhere else.

How CloudTrail event types work

AWS services operate on two planes. The control plane manages the service itself: creating a bucket, modifying a security group, changing a role policy. The data plane operates on the data inside the service: reading an object, invoking a function, querying a table. CloudTrail management events cover the control plane. Data events cover the data plane.

Network activity events add a third dimension. They capture API calls made through VPC endpoints using AWS PrivateLink. Instead of answering “what happened” or “who did it,” they answer “which network path did the call take?” This matters for organisations that route AWS API traffic through private endpoints and need proof that calls never left their VPC.

Insights events sit on top of the other types. CloudTrail continuously analyses your management events (and optionally your data events) to build a baseline of normal activity. When it detects a significant deviation, such as a spike in API call rate or an unusual surge in error rates, it generates an Insights event. This helps you catch compromised credentials, runaway automation, or misconfigured services without writing custom detection rules.

CloudTrail event types at a glance

Management events

What they capture

Management events (also called control plane events) record operations that create, modify, configure, or delete AWS resources. These are the events you care about most for security and governance.

• IAM changes: creating users, modifying roles, attaching policies
• Infrastructure changes: launching EC2 instances, modifying security groups, creating VPCs
• Service configuration: changing CloudTrail settings, modifying service control policies, updating Config rules
• Authentication: console logins, STS AssumeRole calls, federated access
• Encryption: KMS key creation, key policy changes, key deletion scheduling
• Bucket-level S3 operations: creating or deleting buckets, changing bucket policies (not object-level access)

Read vs write events

Management events split into two categories:

• Write events change state: RunInstances, CreateRole, DeleteBucket. These are security-critical because they modify your environment.
• Read events retrieve information: DescribeInstances, GetPolicy, ListBuckets. Higher volume, lower immediate security priority.

If you need to reduce log volume without losing security coverage, log only write management events and add reads later for specific investigations.

Cost and defaults

The first copy of management events delivered to a trail is free. If you send the same management events to additional trails (for example, an organisation trail and an account-level trail), additional copies cost $2.00 per 100,000 events. For most accounts, management event logging costs nothing.

When to use management events

Always. Every AWS account should have at least one trail logging management events. This is your baseline audit trail for who did what to your infrastructure. It is the foundation that Security Hub and other detection services build on.

Configure management events via CLI

# Log only write management events (reduces volume, keeps security coverage)
aws cloudtrail put-event-selectors \
  --trail-name organization-trail \
  --event-selectors '[
    {
      "ReadWriteType": "WriteOnly",
      "IncludeManagementEvents": true
    }
  ]'

Data events

What they capture

Data events record resource-level operations: actions performed on the data inside AWS services. They are not enabled by default and must be turned on per service and per resource.

High-value services and examples

Cost and scoping advice

Data events cost $0.10 per 100,000 events. That sounds small until you consider volume. An S3 bucket receiving 10 million requests per day generates $10/day or roughly $300/month in CloudTrail charges alone. A busy Lambda function invoked millions of times per day adds similar costs.

Always scope data events to specific resources. Use advanced event selectors to target individual bucket ARNs, specific Lambda functions, or particular event names rather than enabling data events across all resources in a service.

When to use data events

Enable data events when you need visibility into who is accessing your data, not just your infrastructure. Common use cases:

• S3 exfiltration detection: log GetObject on buckets containing PII, financial data, or intellectual property.
• Lambda invocation auditing: track who triggers payment-processing or data-export functions.
• Compliance evidence: prove that only authorised principals accessed regulated data in DynamoDB or S3.
• Secrets access monitoring: detect unusual patterns of GetSecretValue calls that may indicate credential theft.

Enable data events for specific S3 buckets

aws cloudtrail put-event-selectors \
  --trail-name organization-trail \
  --event-selectors '[
    {
      "ReadWriteType": "All",
      "IncludeManagementEvents": true,
      "DataResources": [
        {
          "Type": "AWS::S3::Object",
          "Values": [
            "arn:aws:s3:::sensitive-data-bucket/",
            "arn:aws:s3:::pci-data-bucket/"
          ]
        }
      ]
    }
  ]'

The trailing slash in the ARN (e.g. arn:aws:s3:::bucket-name/) means “all objects in this bucket.” To log all S3 buckets, use arn:aws:s3 with no bucket name, but check the cost implications first.

Enable data events for a specific Lambda function

aws cloudtrail put-event-selectors \
  --trail-name organization-trail \
  --event-selectors '[
    {
      "ReadWriteType": "All",
      "IncludeManagementEvents": true,
      "DataResources": [
        {
          "Type": "AWS::Lambda::Function",
          "Values": ["arn:aws:lambda:us-east-1:123456789012:function:payment-processor"]
        }
      ]
    }
  ]'

Use advanced event selectors for precise scoping

Advanced event selectors allow field-level conditions so you can log exactly the events you need. For example, log only GetObject and PutObject calls on a specific S3 prefix:

aws cloudtrail put-event-selectors \
  --trail-name organization-trail \
  --advanced-event-selectors '[
    {
      "Name": "SensitivePrefixAccess",
      "FieldSelectors": [
        {"Field": "eventCategory", "Equals": ["Data"]},
        {"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
        {"Field": "eventName", "Equals": ["GetObject", "PutObject"]},
        {"Field": "resources.ARN", "StartsWith": ["arn:aws:s3:::data-lake/pii/"]}
      ]
    }
  ]'

This gives you surgical precision: compliance-grade logging at a fraction of the cost of broad data event capture. For detection patterns to layer on top of these logs, see detecting suspicious activity in AWS logs.

Network activity events

What they capture

Network activity events record API calls made through VPC endpoints using AWS PrivateLink. While management and data events tell you what happened and who did it, network activity events tell you which network path the API call took, specifically which VPC endpoint was used.

These events capture details like the VPC endpoint ID, the VPC ID, and whether the call was allowed or denied by the endpoint policy. This visibility is essential for organisations that require proof that API traffic stayed within their private network.

When they matter

• Zero-trust network verification: confirm that API calls to services like STS, KMS, and S3 route through your VPC endpoints, not the public internet.
• Regulatory compliance: in industries like finance and healthcare, you may need evidence that sensitive API calls never left your private network boundary.
• VPC endpoint policy auditing: identify which calls are being denied by endpoint policies and whether endpoint configurations need adjustment.
• Detecting unauthorised endpoint use: spot unexpected principals or accounts using your VPC endpoints.

VPC endpoint examples and audit use cases

Network activity events are available for services commonly accessed through VPC endpoints, including EC2, STS, KMS, Secrets Manager, S3, and others. A typical network activity event record includes:

• The VPC endpoint ID through which the call was made
• The VPC ID where the endpoint lives
• The API action called (e.g. sts:AssumeRole, kms:Decrypt)
• Whether the VPC endpoint policy allowed or denied the call
• The calling principal and source IP (private IP within the VPC)

This information lets you answer questions like: “Did any API call to KMS originate from outside our approved VPC endpoints?” or “Which principals used the STS endpoint in the production VPC last week?”

Cost and default behaviour

Network activity events are not logged by default. When enabled, they cost $0.10 per 100,000 events, the same rate as data events. You enable them using advanced event selectors by specifying the eventCategory as NetworkActivity and selecting the service-specific resource types you want to log.

# Enable network activity events for STS VPC endpoint calls
aws cloudtrail put-event-selectors \
  --trail-name organization-trail \
  --advanced-event-selectors '[
    {
      "Name": "STSNetworkActivity",
      "FieldSelectors": [
        {"Field": "eventCategory", "Equals": ["NetworkActivity"]},
        {"Field": "resources.type", "Equals": ["AWS::EC2::VPCEndpoint"]}
      ]
    }
  ]'

Insights events

What they detect

CloudTrail Insights events fire when CloudTrail detects unusual activity: a significant deviation from the normal baseline of API call volume or error rate. Instead of requiring you to write custom detection rules, Insights automatically flags anomalies.

Examples of what Insights can catch:

• A sudden spike in AuthorizeSecurityGroupIngress calls (possible automated security group modification)
• An abnormal volume of iam:CreateUser calls in a short period (potential credential abuse)
• A surge in error rates for a specific API (misconfiguration or failed attack)
• Unusual volume of TerminateInstances calls (potential sabotage or ransomware)
• A spike in S3 GetObject calls (possible data exfiltration, via data event Insights)

Management vs data event Insights

Insights can analyse both management events and data events for anomalies:

• Management event Insights detect anomalies in control plane activity. They catch unusual spikes in infrastructure changes, IAM modifications, or authentication patterns.
• Data event Insights detect anomalies in data plane activity. They catch unusual patterns in S3 object access, Lambda invocations, or other data operations. Particularly valuable for spotting data exfiltration attempts that appear as abnormal GetObject volume.

You can enable both independently. Data event Insights require that data events are also being logged on the same trail.

Baseline and timing

When to use Insights

Enable Insights for security-sensitive accounts where early breach detection matters: production accounts, accounts with access to sensitive data, and accounts that are targets for privilege escalation. The cost is modest relative to the detection value: $0.35 per 100,000 events analysed.

Insights works well as a complement to Security Hub findings and custom CloudWatch Logs metric filters. It catches patterns that rule-based detection might miss because it adapts to your account’s actual usage patterns.

Enable Insights for a trail

aws cloudtrail put-insight-selectors \
  --trail-name organization-trail \
  --insight-selectors '[
    {"InsightType": "ApiCallRateInsight"},
    {"InsightType": "ApiErrorRateInsight"}
  ]'

Which CloudTrail event type should you enable?

Use this decision matrix to match event types to your situation. Most teams work through this list from top to bottom.