AWS CloudTrail Pricing & Cost-Optimization Complete Guide (2026 Edition): The Free Boundary, the Double-Billing Trap, the Data-Event Explosion, and the Cost Design of CloudTrail Lake/Athena

"I can't read the cost of audit logs," "before I knew it, the CloudTrail bill had become several times the estimate" — these are surprisingly common worries in sites that introduced CloudTrail for audit/security requirements.

To say the conclusion first, CloudTrail is a service that's nearly free if designed correctly, and increases by orders of magnitude if designed wrong. It's not that the fee can't be read — it's that avoidable cost is incurred by increasing trails without knowing the "boundaries" of the billing model, or by opening data events wide. That's all.

I led the reliability layer of a serverless payment platform and kept production double charges at 0. "The correctness of cost" and "the correctness of money" are both guaranteed by the structure of the code — the cost of audit logs is exactly the same, and if you design with structure rather than intuition, it can certainly be read. This article is that blueprint.

This article is the "cost" spoke of the CloudTrail cluster. The trail-creation procedure, the overall picture of event types, and the security design itself are consolidated in CloudTrail Audit Logging, Governance, and Security Complete Guide (the pillar article). This article shows minimal code only for the range directly tied to cost, and leaves the deep dive to the pillar.

Pricing varies. All amounts in this article are based on us-east-1, as of 2026, and before actual decision-making, always check the latest values and regional differences on the official AWS CloudTrail pricing page.

0. Conclusion: a quick-reference of the free boundary and cost explosion

First, grasp the overall picture on one sheet. CloudTrail's cost is decided by whether you know "how far is free, and from where and what is billed."

And "cost explosion" almost always comes from one of the following 3.

An intuition you should hold as a sense of the going rate: a configuration of management-events-only, one multi-region trail delivered to S3 is nearly $0 as a CloudTrail fee (the 1st copy is free per region). What you actually pay is mainly the S3 storage fee, which, depending on scale, fits within the range of tens of yen to a few dollars per month for many small/medium accounts (estimate, verify). Sites where "audit logs are expensive" have almost always stepped on one of ①–③ above.

1. The overall picture of the billing model: the 5 billing dimensions + separately-billed peripheral services

CloudTrail's bill becomes far clearer at once if you understand it divided into "the 5 billing dimensions" and "peripheral cost that CloudTrail doesn't bill (but you pay to another service)."

1-1. The 5 dimensions CloudTrail itself bills

1. Management events — control-plane operations (resource creation, IAM changes, etc.). The 1st copy is free in each region, and the 2nd copy onward is $2.00/100k.
2. Data events — high-volume data-plane operations (S3 object GetObject/PutObject, Lambda Invoke, DynamoDB item operations, etc.). Billed from the 1st copy, $0.10/100k.
3. Network activity events — API activity via VPC endpoints. $0.10/100k.
4. Insights events — detect with machine learning a different-from-usual API-call volume or error rate. Management events $0.35/100k per analysis, data events $0.03/100k per analysis (both per insight type).
5. CloudTrail Lake — billed by ingestion (GB unit price) and query (scan GB unit price). Details in Chapter 5.

The official's decisive sentence: "For data events, all deliveries incur CloudTrail costs, including the first." The management events' "1st copy free" doesn't apply to data events. Confuse this and your estimate is fundamentally off.

1-2. The peripheral cost CloudTrail doesn't bill (but the bill comes)

CloudTrail doesn't bill as CloudTrail for the destination S3 bucket. But that bucket's storage, requests, KMS encryption, and notifications are each billed by their respective services. The official pricing page also explicitly states that S3 and CloudWatch Logs costs are separate.

That is, looking only at "the CloudTrail bill" doesn't tell you the real cost. The cost of audit logs is the sum of CloudTrail + S3 (+ KMS/CloudWatch/Athena as needed). Grasping this premise first is the first step to a readable estimate.

2. Accurately on the free boundary: the true meaning of "the 1st copy is free per region"

This is the most important section in this article. Many billing accidents arise from misinterpreting this one sentence.

The official expression is this:

"The first copy of management events within each region is delivered free of charge."

The point is that it's free only when all 3 conditions of "per region," "management events only," and "the 1st copy" are met. Let me organize the official documentation's examples in a form where the presence or absence of billing is clear.

Case A: 2 single-region trails (different regions) → free

1 trail in us-east-1, 1 trail in us-west-2. Each is the "1st copy" in its region, so no CloudTrail billing occurs.

us-east-1: [single-region trail A]  ← the 1st copy of that region → free
us-west-2: [single-region trail B]  ← the 1st copy of that region → free
Total CloudTrail billing: $0

Case B: a multi-region trail + a single-region trail → the single-region side is billed

A multi-region trail is a state where the 1st copy is already delivered in all regions. Add a single-region trail that picks up the same management events there, and in that region it becomes the "2nd copy" and is billed.

All regions: [multi-region trail]   ← the 1st copy of each region → free
us-east-1:   [single-region trail]  ← the 2nd copy of us-east-1 → billed ($2.00/100k)

This is the so-called "2nd-copy trap." Well-meaning operations of "one more just in case" or "I want to split a trail per team" unknowingly mass-produce 2nd copies. The requirement itself of "wanting to give separate logs to different user groups (dev, security, audit)" is legitimate, but you should choose that additional delivery deliberately, understanding that it's billed.

Case C: an Organizations org trail + a member's individual trail → the member side is billed

An org trail replicates the trail to each member account. If a member account separately creates a trail that collects the same management events as the org trail, it's a 2nd copy and billed to that member account.

Org trail → replicated to each member (1st copy) → free
Member X adds an individual trail for the same management events → 2nd copy → billed to member X

In a multi-account environment, just deciding the org trail is "canonical" and inventorying the members' duplicate trails is a plain but certain cost reduction.

To summarize, the iron rule to keep management-event cost at 0 is "one management event is only 1 copy per region." Break this and the $2.00/100k meter starts spinning.

3. The 3 big factors of cost explosion and countermeasures

3-1. ① The 2nd-copy trap (management events)

The countermeasure, as in Chapter 2, is "inventorying duplicate trails." List all current trails and confirm whether, in each region, a multi-region trail and a single-region trail double-pick the same management events.

# 全証跡の一覧と、マルチリージョン/単一リージョンの別を確認
aws cloudtrail list-trails

# 個別証跡の設定（IsMultiRegionTrail / IncludeGlobalServiceEvents）を確認
aws cloudtrail get-trail --name <trail-name> \
  --query '{Name:Name,MultiRegion:IsMultiRegionTrail,Global:IncludeGlobalServiceEvents}'

If a trail with IsMultiRegionTrail=true already exists, a single-region trail that picks up the same management events is in principle unneeded. If you just want to split the delivery destination (S3 prefix or another bucket), first consider whether it can be solved with delivery-destination design rather than an additional trail.

3-2. ② High-volume data events

Data events are $0.10/100k from the 1st copy. At a glance it looks cheap, but S3 object accesses and Lambda Invokes can be orders-of-magnitude counts. For example, unconditionally record a bucket that emits 100 million data events a day, and it's 3 billion events/month × $0.10/100k = about $3,000/month (estimate, verify). This is the typical "audit logs are expensive."

The countermeasure is to stop "record everything" and surgically select, with advanced event selectors, only the data events truly needed for audit/security. Concrete HCL is shown in the next chapter.

3-3. ③ KMS events (the side effect of SSE-KMS)

A pitfall the official explicitly states:

"using AWS KMS-managed server-side encryption (SSE-KMS) on your S3 buckets can result in a large number of AWS KMS management events in CloudTrail."

If you apply SSE-KMS to an S3 bucket, a large number of KMS management events occur on each encrypt/decrypt, and if they ride on the 2nd copy onward of management events, they're billed. The countermeasure is simple — at trail creation/update, choose "Exclude AWS KMS events," or if you use the RDS Data API, "Exclude Amazon RDS Data API events."

# 基本イベントセレクタでは管理イベントのみフィルタ可能。
# KMS と RDS Data API を管理イベントから除外する例。
aws cloudtrail put-event-selectors \
  --trail-name <trail-name> \
  --event-selectors '[
    {
      "ReadWriteType": "All",
      "IncludeManagementEvents": true,
      "ExcludeManagementEventSources": ["kms.amazonaws.com", "rdsdata.amazonaws.com"]
    }
  ]'

Caution: depending on audit requirements, there are cases where recording KMS events is needed. Exclusion is a trade-off between cost optimization and audit requirements. Rather than "silently erasing for cost," exclude deliberately after cross-checking with the audit requirements. What I thoroughly practiced in the payment platform too was exactly this "cross-check with requirements before erasing" discipline.

4. Surgically narrow data events (advanced event selectors)

Cost optimization of data events is 90% "the courage to not record." Use advanced selectors and you can include/exclude both management and data events and leave only what's truly needed with conditions like readOnly, eventName, and resources.ARN.

4-1. Terraform that narrows to "writes only" and "a specific bucket only"

What's most valuable in audit is, in many cases, "writes/deletes (readOnly=false)." Reads (GetObject, etc.) tend to be enormous in count, so consider exclusion first.

resource "aws_cloudtrail" "audit" {
  name                          = "org-audit-trail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail.id
  is_multi_region_trail         = true
  include_global_service_events = true
  enable_log_file_validation    = true

  # 管理イベント（1コピー目・無料）。KMS/RDS Data API のノイズは除外。
  advanced_event_selector {
    name = "Management events (exclude KMS/RDS noise)"

    field_selector {
      field  = "eventCategory"
      equals = ["Management"]
    }
    field_selector {
      field           = "eventSource"
      not_equals      = ["kms.amazonaws.com", "rdsdata.amazonaws.com"]
    }
  }

  # データイベント：監査対象バケットの「書き込み系のみ」に外科的に限定。
  advanced_event_selector {
    name = "S3 write-only data events on sensitive bucket"

    field_selector {
      field  = "eventCategory"
      equals = ["Data"]
    }
    field_selector {
      field  = "resources.type"
      equals = ["AWS::S3::Object"]
    }
    field_selector {
      field  = "readOnly"
      equals = ["false"] # 書き込み・削除のみ。読み取りは記録しない＝コスト削減
    }
    field_selector {
      field       = "resources.ARN"
      starts_with = ["arn:aws:s3:::sensitive-prod-bucket/"]
    }
  }
}

The cost optimization this selector applies is 3 points.

1. readOnly=false — take high-volume read data events off the recording target.
2. starts_with of resources.ARN — limit to only the sensitive bucket that truly needs audit, not all S3 buckets.
3. Noise-exclude KMS/RDS from management events — preemptively prevent the KMS explosion when it rides on the 2nd copy.

A sticking point: the field names of field_selector (eventCategory, resources.type, resources.ARN, readOnly) and the ARN format usable per resources.type are officially defined. The trail-creation procedure and the overall picture of supported resource types are handled in the pillar article, so here I concentrate on cost-perspective narrowing.

4-2. The idea of "excluding only noisy prefixes"

Conversely, in the case where most data events are needed but only a specific high-volume prefix (thumbnails, temp files, etc.) is in the way, the design of excluding with not_starts_with is also effective. Whether to narrow include or cut with exclude is chosen by whether the logs are "90% needed, 10% noise" or "10% needed, 90% noise."

5. The cost design of long-term storage and analysis

Audit logs have a different cost structure for "storing" and "using." Designing these separately is the crux of FinOps.

5-1. Store: lower the storage class with S3 lifecycle

CloudTrail logs are typical cold data of "the recent ones you want to access fast, but the old ones you rarely look at." With S3 lifecycle, you can stepwise lower the storage class according to access frequency and greatly cut the storage cost.

resource "aws_s3_bucket_lifecycle_configuration" "cloudtrail" {
  bucket = aws_s3_bucket.cloudtrail.id

  rule {
    id     = "tier-down-and-expire"
    status = "Enabled"

    filter {
      prefix = "AWSLogs/"
    }

    # 30日後: 低頻度アクセス層へ（S3-IA）。※IA系は最低30日保管が前提
    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    # 90日後: アーカイブ即時取得層へ
    transition {
      days          = 90
      storage_class = "GLACIER_IR"
    }

    # 365日後: 長期アーカイブ（取り出しに時間を許容）
    transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }

    # 保持期間(例:7年)を過ぎたら失効。監査要件に合わせて調整。
    expiration {
      days = 2555
    }
  }
}

The selection guideline for storage classes (per the official transition rules; verify pricing on the S3 pricing page):

An important constraint: small objects under 128KB don't transition by default (the S3 default behavior since September 2024). CloudTrail log files are aggregated to a certain size, but confirm by count whether the transition request billing doesn't exceed the storage reduction.

A security-design caveat: S3 lifecycle doesn't work on a bucket with MFA Delete enabled (also mentioned in CloudTrail's security best practices). If you want to guarantee tamper resistance with MFA Delete, you need to grasp at design time that it's incompatible with lifecycle-based auto-tiering/expiry. If you prioritize tamper resistance, consider S3 Object Lock (compliance mode) and a design that uses it together with lifecycle is realistic.

5-2. Use: cut Athena's scan volume with "partition projection"

When you investigate stored logs with SQL, the cost is decided by Athena's scan volume ($5/TB, us-east-1, verify). Not the query's speed but "how many bytes you read" becomes the bill — this is the counterintuitive point.

CloudTrail logs naturally have a date partition with the structure AWSLogs/<account>/CloudTrail/<region>/<year>/<month>/<day>/. Embed this in the table definition with partition projection, and you scan only the partitions matching the WHERE's date/region conditions, avoiding a full read.

-- パーティション射影でスキャン量を日付・リージョンに限定する例
CREATE EXTERNAL TABLE cloudtrail_logs (
  eventversion      STRING,
  useridentity      STRUCT<type:STRING, arn:STRING, accountid:STRING>,
  eventtime         STRING,
  eventsource       STRING,
  eventname         STRING,
  awsregion         STRING,
  sourceipaddress   STRING,
  errorcode         STRING,
  readonly          STRING
)
PARTITIONED BY (region STRING, `date` STRING)
ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
LOCATION 's3://my-cloudtrail-bucket/AWSLogs/123456789012/CloudTrail/'
TBLPROPERTIES (
  'projection.enabled'            = 'true',
  'projection.region.type'        = 'enum',
  'projection.region.values'      = 'us-east-1,us-west-2,ap-northeast-1',
  'projection.date.type'          = 'date',
  'projection.date.range'         = '2024/01/01,NOW',
  'projection.date.format'        = 'yyyy/MM/dd',
  'projection.date.interval'      = '1',
  'projection.date.interval.unit' = 'DAYS',
  'storage.location.template'     =
    's3://my-cloudtrail-bucket/AWSLogs/123456789012/CloudTrail/${region}/${date}'
);

-- パーティションを必ず WHERE で絞る。これがスキャン量＝コストを決める。
SELECT eventtime, eventname, useridentity.arn, sourceipaddress
FROM cloudtrail_logs
WHERE region = 'ap-northeast-1'
  AND date BETWEEN '2026/06/01' AND '2026/06/27'
  AND eventname = 'DeleteBucket'
  AND readonly = 'false'
ORDER BY eventtime DESC;

Iron rule: in Athena, always narrow the partitions (region/date) with WHERE. A query with no date condition scans the whole bucket, and $5/TB takes effect as-is. Just by being conscious of "how many bytes you read to get the same answer," the analysis cost changes by orders of magnitude. As a FinOps mindset, it's the same as Startup Cost Optimization Built with Terraform and DynamoDB Capacity Design — it's controlling, with structure, that "what's billed is the amount reserved, the amount read."

5-3. CloudTrail Lake's ingestion/query fees and retention tiers, and the reality of "new acceptance ending"

CloudTrail Lake is a managed option that SQL-queries audit logs without ETL, but its cost structure differs greatly from S3 + Athena (us-east-1, verify).

What's notable is the difference in query unit price. Lake's query is $0.005/GB scanned, Athena is $5/TB (= $0.005/GB) scanned, and the scan unit price itself is nearly equivalent. The difference appears in the trade-off of "ingestion billing (Lake bills by GB unit price at ingestion time, S3 + Athena is S3 storage only)" and operational burden (the presence of ETL/table definitions). If query frequency is high and you want to delegate operation, Lake; if the main purpose is storing and you only investigate occasionally, S3 + Athena is cost-efficient — that's the discernment.

Important (the reality of 2026): CloudTrail Lake ended new-customer acceptance as of May 31, 2026. Existing customers can continue to use it, but if you're newly building an audit-log foundation from here, S3 + Athena (+ CloudWatch as needed) is the de facto standard option. AWS itself also recommends migrating Lake data to CloudWatch. This article's long-term-storage/analysis design being built S3 + Athena-centric also takes this circumstance into account. (CloudTrail Lake availability change)

6. Cost visualization and the brake

To structurally crush "expensive before you knew it," you need a mechanism to notice before billing starts spinning.

6-1. See it per service and per usage type in Cost Explorer

In Cost Explorer, filter service = CloudTrail / S3 / Athena / KMS and look at the breakdown by UsageType (PaidEventsRecorded, etc.), and you can decompose which dimension the cost comes from. If CloudTrail itself is cheap but the bill is high, the culprit is almost always S3 storage or Athena scan.

6-2. AWS Budgets + cost anomaly detection

# 監査ログ関連サービスに対する月次予算とアラートの考え方（簡略例）
aws budgets create-budget \
  --account-id <account-id> \
  --budget '{
    "BudgetName": "audit-logging-monthly",
    "BudgetLimit": {"Amount": "50", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST",
    "CostFilters": {"Service": ["AWS CloudTrail", "Amazon Simple Storage Service"]}
  }'

In addition to budget-overage notifications, setting AWS Cost Anomaly Detection toward CloudTrail/S3 lets you catch early a data-event misconfiguration or a sudden KMS-event explosion as a "different-from-usual increase." A two-stage setup of a threshold-based budget (notice later) and trend-based anomaly detection (notice early) is effective.

6-3. Cost-allocate with tags

Attach cost-allocation tags (CostCenter, Environment, etc.) to the trail's delivery-destination bucket and EDS, and make them viewable per tag in Cost Explorer, and "which team's / which environment's audit logs are driving the cost" is clear at a glance. The more multi-account/multi-team, the larger the effect of this move.

7. A real example of monthly-cost estimation (estimate, verify)

Let me show the actual sense of the going rate with 2 scenarios. The amounts are estimates based on us-east-1, and always recompute with your count, region, and the latest unit prices.

Scenario A: a correctly-designed mid-size account (management events only, 1 multi-region trail)

• 1 multi-region trail of management events → the 1st copy of each region → CloudTrail $0
• KMS events already Excluded (no 2nd copy either)
• Logs delivered to S3: about tens of MB to hundreds of MB per month, tiered to IA/Glacier with lifecycle

This is the reality of "CloudTrail is nearly free if designed correctly." While meeting audit requirements, the cost fits at the noise level.

Scenario B: data events wide open (if the design is wrong in the same account)

• Unconditionally record read/write data events of all S3 buckets
• Suppose 3 billion data events a month

Even with the same account and the same audit purpose, depending on the design, there's a difference of $0 vs $3,000 (estimate, verify). This difference arises not "because it's an expensive service" but because you didn't narrow the recording target without knowing the boundaries. Cost optimization, after all, comes down to "a design that records only what's needed."

8. Summary: the CloudTrail cost-optimization checklist

Finally, let me summarize it into a checklist you can use as-is in the field.

• Are management events "1 copy per region" (haven't you stepped on the double-delivery of a multi-region trail + single-region trail = the 2nd-copy trap)
• In an Organizations environment, have you inventoried the members' duplicate trails (an individual trail picking up the same management events as the org trail is billed)
• Have you surgically narrowed data events with advanced selectors (readOnly=false, specific ARNs only / not the unconditional recording of all S3, all Lambda)
• Have you suppressed the KMS-event explosion from SSE-KMS with Exclude (after cross-checking with audit requirements)
• Have you tiered storage classes with S3 lifecycle (IA → Glacier IR → Deep Archive, expiring by retention period)
• Have you understood the incompatibility of MFA Delete and lifecycle, and substituted tamper resistance with Object Lock
• Is Athena WHERE-required with partition projection, controlling scan volume
• For new builds, did you choose S3 + Athena rather than CloudTrail Lake (Lake ended new acceptance on 2026/5/31)
• Have you put a brake on with Cost Explorer, AWS Budgets, and cost anomaly detection
• Have you attached cost-allocation tags to the delivery destination and visualized the breakdown

CloudTrail's cost isn't a story of being tossed about by a complex price table. Correctly understand the "free boundary," narrow the recording target with structure, and design "store" and "use" separately — just this brings you to a state where you can read the cost while meeting audit requirements.

I led the reliability layer of a serverless payment platform and realized 0 production double charges not with "prayer" but with the structure of the code. With one person × generative AI (Claude Code), fast, cheap, and safe. The cost design of audit logs and the correctness of payments share the same root discipline of "guarantee with structure."

If you can't read the cost of audit logs, it's ballooning unexpectedly, or you want to review the FinOps including CloudTrail / S3 / Athena from the structure of the code — at such a time, feel free to consult via Contact. I'll inventory your current trail configuration and lean it, by the shortest path, toward a design along the free boundary.

Sources (all official; verify the latest values on each page)

• AWS CloudTrail Pricing — https://aws.amazon.com/cloudtrail/pricing/
• Managing CloudTrail trail costs — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trail-manage-costs.html
• CloudTrail Lake availability change — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-service-availability-change.html
• Amazon S3 Lifecycle transitions — https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html
• Amazon Athena Pricing — https://aws.amazon.com/athena/pricing/
• Amazon S3 Pricing — https://aws.amazon.com/s3/pricing/