Trying Out the New "UserIdentity Filtering" Feature in CloudTrail Network Activity Events
This page has been translated by machine translation. View original
Introduction
On July 20, 2026, AWS CloudTrail Network Activity Events added support for UserIdentity-based filtering.
Network Activity Events is an event type that records API calls made through VPC endpoints. Until now, you could narrow down the recorded targets by eventSource, eventName, vpcEndpointId, and so on, but with this update userIdentity.arn has been added as a condition field, making it possible to control what is recorded on a per-Identity basis for the entity that made the API call.
Verification Details
Verification Environment
IAM Role (ec2-ssm-core)
└─→ VPC Endpoint (STS, Interface型)
└─→ sts:GetCallerIdentity
└─→ CloudTrail Network Activity Event (記録される/されない)
- Region: us-east-1
- VPC: Default VPC
- EC2: t3.nano (Amazon Linux 2023), connected via SSM Session Manager
- VPC endpoint:
com.amazonaws.us-east-1.sts(Interface type, private DNS enabled) - CloudTrail Trail: Dedicated to Network Activity Events (configured to record only
eventCategory: NetworkActivity) - Log destination: S3 bucket
Baseline (No Filter)
With no UserIdentity filter, I called STS from EC2 via the VPC endpoint and confirmed that it was recorded as a Network Activity Event.
aws sts get-caller-identity
After waiting a few minutes, I confirmed that the log had been delivered to the corresponding path in the S3 bucket. Unlike regular management events (CloudTrail/), Network Activity Events are delivered under the CloudTrail-NetworkActivity/ prefix.
aws s3 ls s3://<log-bucket>/AWSLogs/123456789012/CloudTrail-NetworkActivity/us-east-1/2026/07/20/
| Item | Result |
|---|---|
| STS call time | 2026-07-20T19:07:40Z |
| Log delivery time | 2026-07-20T19:12:33Z (about 5 minutes later) |
| eventCategory | NetworkActivity |
| eventType | AwsVpceEvent |
| eventSource | sts.amazonaws.com |
| vpcEndpointId | vpce-xxxxxxxxxxxxxxxxx |
| sourceIPAddress | 10.0.x.x |
| userIdentity.arn | arn:aws:sts::123456789012:assumed-role/ec2-ssm-core/i-xxxxxxxxxxxxxxxxx |
Full Event (JSON)
{
"Records": [
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAXXXXXXXXXXXXXXXXX:i-xxxxxxxxxxxxxxxxx",
"arn": "arn:aws:sts::123456789012:assumed-role/ec2-ssm-core/i-xxxxxxxxxxxxxxxxx",
"accountId": "123456789012",
"accessKeyId": "ASIAXXXXXXXXXXXXXXXX",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAXXXXXXXXXXXXXXXXX",
"arn": "arn:aws:iam::123456789012:role/ec2-ssm-core",
"accountId": "123456789012",
"userName": "ec2-ssm-core"
},
"attributes": {
"creationDate": "2026-07-20T18:55:18Z",
"mfaAuthenticated": "false"
},
"ec2RoleDelivery": "2.0"
},
"inScopeOf": {
"issuerType": "AWS::EC2::Instance",
"credentialsIssuedTo": "arn:aws:ec2:us-east-1:123456789012:instance/i-xxxxxxxxxxxxxxxxx"
}
},
"eventTime": "2026-07-20T19:07:40Z",
"eventSource": "sts.amazonaws.com",
"eventName": "GetCallerIdentity",
"awsRegion": "us-east-1",
"sourceIPAddress": "10.0.x.x",
"requestID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"eventID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"eventType": "AwsVpceEvent",
"recipientAccountId": "123456789012",
"sharedEventID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"vpcEndpointId": "vpce-xxxxxxxxxxxxxxxxx",
"vpcEndpointAccountId": "123456789012",
"eventCategory": "NetworkActivity"
}
]
}
UserIdentity Filter Configuration
I added a NotStartsWith condition on userIdentity.arn to the Advanced Event Selectors, and applied a configuration that excludes events matching the session ARN of the ec2-ssm-core role (arn:aws:sts::....:assumed-role/ec2-ssm-core/).
aws cloudtrail put-event-selectors \
--trail-name <trail-name> \
--advanced-event-selectors file://selectors.json
Contents of selectors.json:
[
{
"Name": "Log STS network activity excluding ec2-ssm-core",
"FieldSelectors": [
{ "Field": "eventCategory", "Equals": ["NetworkActivity"] },
{ "Field": "eventSource", "Equals": ["sts.amazonaws.com"] },
{ "Field": "userIdentity.arn", "NotStartsWith": ["arn:aws:sts::123456789012:assumed-role/ec2-ssm-core/"] }
]
}
]
Verifying Filter Behavior
After applying the filter, I ran sts get-caller-identity again from the same EC2 instance.
aws sts get-caller-identity
Allowing a margin over the delivery time observed during baseline verification (about 5 minutes), I waited 21 minutes and then checked the corresponding log path in S3.
aws s3 ls s3://<log-bucket>/AWSLogs/123456789012/CloudTrail-NetworkActivity/us-east-1/2026/07/20/
A new file corresponding to the call made after the filter was applied could not be found as of 21 minutes later.
2026-07-20 19:12:33 738 123456789012_CloudTrail-NetworkActivity_us-east-1_20260720T1910Z_eQlnTuU10ITkCJ3z.json.gz
| Item | Result |
|---|---|
| STS call time | 2026-07-20T19:16:30Z |
| Last check time | 2026-07-20T19:37:07Z (21 minutes elapsed) |
| New log delivery | None |
No new log file was found as of 21 minutes later, which is consistent with the NotStartsWith condition excluding Network Activity Events that match the ec2-ssm-core role session.
Findings During Verification
- STS (
sts.amazonaws.com) is not listed in the official documentation's list of eventSources supported by Network Activity Events, but it could actually be configured and recorded (as of the 2026-07-20 verification). - In this article, I verified the
userIdentity.arnfilter on a Trail. Whether it is supported on an Event Data Store is outside the scope of this verification.
Summary
With UserIdentity filtering, it is now possible to narrow down what Network Activity Events record by using conditions on userIdentity.arn.
Network Activity Events is a feature with limited use cases, but there are situations where an audit trail is required for AWS API access via VPC endpoints while it is not necessary to retain events from all Identities. One example is an environment that includes access from networks outside AWS or from Direct Connect connection sites, where you want to target API access via VPC endpoints for review.
In such cases, excluding role sessions that may be dropped from monitoring by userIdentity.arn gives you an option to narrow down the volume of recorded events while keeping the necessary ones.
