I tried the new "UserIdentity filtering" feature of CloudTrail Network Activity Events

Introduction

On July 20, 2026, AWS CloudTrail Network Activity Events added support for UserIdentity-based filtering.

https://aws.amazon.com/jp/about-aws/whats-new/2026/07/aws-cloudtrail-filter-useridentity-advance-selectors/

Network Activity Events is an event type that records API calls made through VPC endpoints. While it was already possible to narrow down recorded targets using eventSource, eventName, vpcEndpointId, and other fields, this update added userIdentity.arn as a condition field, enabling control over recorded targets on a per-Identity basis for API calls.

https://aws.amazon.com/blogs/mt/announcing-aws-cloudtrail-network-activity-events-for-vpc-endpoints/

Verification

Test Environment

IAM Role (ec2-ssm-core)
  └─→ VPC Endpoint (STS, Interface type)
        └─→ sts:GetCallerIdentity
              └─→ CloudTrail Network Activity Event (recorded/not recorded)

• 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)

Without UserIdentity filtering, I called STS from EC2 via VPC endpoint and confirmed it was recorded as a Network Activity Event.

aws sts get-caller-identity

After waiting a few minutes, I confirmed that logs were 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/

{
  "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 to exclude 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/"] }
    ]
  }
]

Filter Behavior Verification

After applying the filter configuration, I ran sts get-caller-identity again from the same EC2 instance.

aws sts get-caller-identity

Allowing extra time beyond the delivery duration observed during baseline testing (approximately 5 minutes), I waited 21 minutes before checking the corresponding log path in S3.

aws s3 ls s3://<log-bucket>/AWSLogs/123456789012/CloudTrail-NetworkActivity/us-east-1/2026/07/20/

No new file corresponding to the call made after the filter was applied could be found after 21 minutes had elapsed.

2026-07-20 19:12:33        738 123456789012_CloudTrail-NetworkActivity_us-east-1_20260720T1910Z_eQlnTuU10ITkCJ3z.json.gz

With no new log file found after 21 minutes, the behavior is consistent with Network Activity Events matching the ec2-ssm-core role session being excluded by the NotStartsWith condition.

Findings During Verification

• STS (sts.amazonaws.com) is not listed in the official documentation's supported eventSource list for Network Activity Events, but configuration and recording were actually possible (as of the July 20, 2026 verification).
• This article verified userIdentity.arn filtering on a Trail. Whether this is supported for Event Data Stores was outside the scope of this verification.

Summary

With UserIdentity filtering, it is now possible to narrow down the recording targets of Network Activity Events using conditions on userIdentity.arn.

Network Activity Events is a feature with limited use cases, but there are situations where audit trail collection is required for AWS API access via VPC endpoints while not every Identity's events need to be retained. For example, this applies to environments that include access from networks outside AWS or Direct Connect connection points, where you want to monitor API access made through VPC endpoints.

In such cases, excluding role sessions that do not need to be monitored using userIdentity.arn becomes an option for keeping the necessary events while reducing the volume of recorded data.