AWS CloudTrail 料金・コスト最適化 完全ガイド（2026年版）：無料の境界・二重課金の罠・データイベント爆発・CloudTrail Lake/Athenaのコスト設計

「監査ログのコストが読めない」「気づいたら CloudTrail の請求が想定の何倍にもなっていた」——監査・セキュリティ要件で CloudTrail を入れた現場で、これは驚くほどよく聞く悩みです。

結論から言うと、CloudTrail は正しく設計すればほぼ無料、設計を間違えると桁で増えるサービスです。料金が読めないのではなく、課金モデルの「境界」を知らないまま証跡を増やしたり、データイベントを全開にしたりすることで、避けられたはずのコストが発生している。それだけです。

私はサーバーレス決済基盤の信頼性レイヤーを主導し、本番での二重課金を 0 件に保ってきました。「コストの正しさ」と「お金の正しさ」は、どちらもコードの構造で担保するもの——監査ログのコストもまったく同じで、勘ではなく構造で設計すれば確実に読める。本記事はその設計図です。

この記事は CloudTrail クラスタの「コスト」担当（スポーク）です。証跡の作成手順・イベント種別の全体像・セキュリティ設計そのものは CloudTrail 監査ログ・ガバナンス・セキュリティ完全ガイド（ピラー記事）に集約しています。本記事ではコストに直結する範囲だけ最小限のコードを示し、深掘りはピラーに任せます。

料金は変動します。本記事の金額はすべて us-east-1 基準・2026年時点であり、実際の意思決定の前に必ず公式の AWS CloudTrail 料金ページで最新値とリージョン差を確認してください。

0. 結論：無料の境界とコスト爆発の早見表

まず全体像を 1 枚で押さえます。CloudTrail のコストは「どこまでが無料で、どこから・何が課金されるか」を知っているかどうかで決まります。

そして「コスト爆発」は、ほぼ必ず次の 3 つのどれかから来ます。

直感として持っておくべき相場観：管理イベントのみ・1本のマルチリージョン証跡を S3 に配信する構成は、CloudTrail の料金としてはほぼ $0 です（リージョンごとに 1 コピー目が無料）。実際に払うのは主に S3 ストレージ代で、規模次第ですが多くの中小アカウントでは月数十円〜数ドル規模に収まります（概算・要確認）。「監査ログが高い」現場は、ほぼ必ず上の①〜③のどれかを踏んでいます。

1. 課金モデルの全体像：5つの課金次元 ＋ 別途課金される周辺サービス

CloudTrail の請求は「5 つの課金次元」と「CloudTrail が課金しない（が、あなたは別サービスに払う）周辺コスト」に分けて理解すると一気に見通しが良くなります。

1-1. CloudTrail 本体が課金する 5 次元

1. 管理イベント（Management events） — コントロールプレーンの操作（リソース作成・IAM 変更など）。各リージョンで 1 コピー目は無料、2 コピー目以降が $2.00/10万件。
2. データイベント（Data events） — データプレーンの高ボリュームな操作（S3 オブジェクトの GetObject/PutObject、Lambda の Invoke、DynamoDB の項目操作など）。1 コピー目から課金 $0.10/10万件。
3. ネットワークアクティビティイベント（Network activity events） — VPC エンドポイント経由の API アクティビティ。$0.10/10万件。
4. Insights イベント — 通常と異なる API コール量や error rate を機械学習で検知。管理イベント $0.35/10万件・分析、データイベント $0.03/10万件・分析（いずれも insight 種別ごと）。
5. CloudTrail Lake — 取り込み（GB 単価）とクエリ（スキャン GB 単価）で課金。詳細は第 5 章。

公式の決定的な一文："For data events, all deliveries incur CloudTrail costs, including the first."（データイベントは 1 コピー目を含むすべての配信が課金対象）。管理イベントの「1 コピー目無料」はデータイベントには適用されません。ここを混同すると見積もりが根本から狂います。

1-2. CloudTrail が課金しない周辺コスト（しかし請求は来る）

CloudTrail は配信先の S3 バケットに対して CloudTrail としては課金しません。しかしそのバケットの保管・リクエスト・KMS 暗号化・通知は、それぞれのサービスが別途課金します。公式の料金ページも S3 と CloudWatch Logs のコストは別である旨を明記しています。

つまり「CloudTrail の請求書」だけを見ても本当のコストはわかりません。監査ログのコストとは、CloudTrail＋S3（＋必要に応じて KMS/CloudWatch/Athena）の合算です。この前提を最初に握ることが、読める見積もりへの第一歩です。

2. 無料の境界を正確に：「1 コピー目はリージョンごとに無料」の本当の意味

ここが本記事で最も重要なセクションです。多くの請求事故は、この一文の解釈を間違えることから起きます。

公式の表現はこうです：

"The first copy of management events within each region is delivered free of charge." （各リージョン内で、管理イベントの 1 コピー目は無料で配信される）

ポイントは「リージョンごとに」「管理イベントのみ」「1 コピー目」の 3 条件すべてが揃ったときだけ無料、という点です。公式ドキュメントの例を、課金の有無がはっきりわかる形で整理します。

ケース A：単一リージョン証跡 × 2 本（別リージョン）→ 無料

us-east-1 に証跡 1 本、us-west-2 に証跡 1 本。それぞれのリージョンで「1 コピー目」なので、CloudTrail 課金は発生しません。

us-east-1: [単一リージョン証跡A]  ← そのリージョンの1コピー目 → 無料
us-west-2: [単一リージョン証跡B]  ← そのリージョンの1コピー目 → 無料
合計 CloudTrail 課金: $0

ケース B：マルチリージョン証跡 ＋ 単一リージョン証跡 → 単一リージョン側が課金

マルチリージョン証跡はすべてのリージョンで 1 コピー目を既に配信している状態です。そこに同じ管理イベントを拾う単一リージョン証跡を足すと、そのリージョンでは「2 コピー目」になり課金されます。

全リージョン: [マルチリージョン証跡]  ← 各リージョンの1コピー目 → 無料
us-east-1:    [単一リージョン証跡]     ← us-east-1の2コピー目 → 課金($2.00/10万件)

これがいわゆる 「2 コピー目の罠」。「念のためもう 1 本」「チームごとに証跡を分けたい」という善意の運用が、知らぬ間に 2 コピー目を量産します。異なるユーザーグループ（開発・セキュリティ・監査）に別々のログを渡したい、という要件自体は正当ですが、その追加配信は課金されると理解した上で意図的に選ぶべきです。

ケース C：Organizations 組織トレイル ＋ メンバーの個別証跡 → メンバー側が課金

組織トレイルは各メンバーアカウントに証跡を複製します。メンバーアカウントが、組織トレイルと同じ管理イベントを集める証跡を別途作ると、それは 2 コピー目としてそのメンバーアカウントに課金されます。

組織トレイル → 各メンバーに複製（1コピー目）→ 無料
メンバーX が同じ管理イベントの個別証跡を追加 → 2コピー目 → メンバーXに課金

マルチアカウント環境では、組織トレイルを「正」と決め、メンバー側の重複証跡を棚卸しするだけで、地味だが確実なコスト削減になります。

まとめると、管理イベントのコストを 0 に保つ鉄則は「1 つの管理イベントは、1 リージョンにつき 1 コピーだけ」。これを破った瞬間に $2.00/10万件のメーターが回り始めます。

3. コスト爆発の 3 大要因と対策

3-1. ① 2 コピー目の罠（管理イベント）

対策は第 2 章のとおり「重複証跡の棚卸し」です。現状の証跡をすべて列挙し、各リージョンでマルチリージョン証跡と単一リージョン証跡が同じ管理イベントを二重に拾っていないかを確認します。

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

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

IsMultiRegionTrail=true の証跡が既にあるなら、同じ管理イベントを拾う単一リージョン証跡は原則不要です。配信先（S3 プレフィックスや別バケット）を分けたいだけなら、追加証跡ではなく配信先設計で解決できないか先に検討します。

3-2. ② データイベントの高ボリューム

データイベントは 1 コピー目から $0.10/10万件。一見すると安く見えますが、S3 のオブジェクトアクセスや Lambda の Invoke は桁違いの件数になり得ます。たとえば 1 日 1 億件のデータイベントが出るバケットを無条件に記録すれば、月 30 億件 × $0.10/10万件 = 約 $3,000/月（概算・要確認）。これが「監査ログが高い」の典型です。

対策は「全部記録する」をやめ、監査・セキュリティ上で本当に必要なデータイベントだけを高度なセレクタ（advanced event selectors）で外科的に選ぶことです。具体的な HCL は次章で示します。

3-3. ③ KMS イベント（SSE-KMS の副作用）

公式が明示している落とし穴です：

"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."

S3 バケットに SSE-KMS をかけていると、暗号化/復号のたびに KMS の管理イベントが大量に発生し、それが管理イベントの 2 コピー目以降に乗ると課金されます。対策はシンプルで、証跡の作成/更新時に 「Exclude AWS KMS events（AWS KMS イベントを除外）」、あるいは 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"]
    }
  ]'

注意：監査要件によっては KMS イベントの記録が必要なケースもあります。除外はコスト最適化と監査要件のトレードオフです。「コストのために黙って消す」のではなく、監査要件と突き合わせて意図的に除外すること。私が決済基盤で徹底したのも、まさにこの「消す前に要件と照合する」規律でした。

4. データイベントを外科的に絞る（advanced event selectors）

データイベントのコスト最適化は「記録しない勇気」が 9 割です。高度なセレクタを使えば、管理イベントもデータイベントも include/exclude でき、readOnly・eventName・resources.ARN などの条件で本当に必要なものだけを残せます。

4-1. 「書き込み系だけ」「特定バケットだけ」に絞る Terraform

監査で最も価値が高いのは多くの場合「書き込み・削除（readOnly=false）」です。読み取り（GetObject 等）は件数が膨大になりがちなので、まず除外を検討します。

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

このセレクタが効かせているコスト最適化は 3 点です。

1. readOnly=false — 高ボリュームな読み取りデータイベントを記録対象から外す。
2. resources.ARN の starts_with — 全 S3 バケットではなく、本当に監査が必要な機微バケットだけに限定。
3. 管理イベントから KMS/RDS をノイズ除外 — 2 コピー目に乗ったときの KMS 爆発を未然に防ぐ。

ハマりどころ：field_selector の field 名（eventCategory・resources.type・resources.ARN・readOnly）と、resources.type ごとに使える ARN 形式は公式に定義があります。証跡の作成手順や対応リソースタイプの全体像はピラー記事で扱っているので、ここではコスト観点の絞り込みに集中します。

4-2. 「ノイズの多いプレフィックスだけ除外」する発想

逆に、ほとんどのデータイベントは必要だが特定の高ボリュームプレフィックス（サムネイル・一時ファイル等）だけが邪魔、というケースでは not_starts_with で除外する設計も有効です。include を絞るか exclude で削るかは、ログの「必要 9 割・ノイズ 1 割」か「必要 1 割・ノイズ 9 割」かで選びます。

5. 長期保管と分析のコスト設計

監査ログは「貯める」と「使う」で別物のコスト構造を持ちます。ここを分けて設計するのが FinOps の肝です。

5-1. 貯める：S3 ライフサイクルでストレージクラスを落とす

CloudTrail のログは「直近は速くアクセスしたいが、古いものはめったに見ない」典型的なコールドデータです。S3 ライフサイクルでアクセス頻度に応じてストレージクラスを段階的に下げ、保管コストを大きく削れます。

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
    }
  }
}

ストレージクラスの選択指針（公式の遷移ルールに準拠・料金はS3 料金ページで要確認）：

重要な制約：128KB 未満の小さいオブジェクトは既定では遷移しません（2024年9月以降の S3 既定挙動）。CloudTrail のログファイルは集約されてある程度のサイズになりますが、遷移リクエスト課金が保管削減を上回らないかは件数で確認を。

セキュリティ設計上の注意：MFA Delete を有効にしたバケットでは S3 ライフサイクルは機能しません（CloudTrail のセキュリティベストプラクティスでも言及）。改ざん耐性を MFA Delete で担保したい場合は、ライフサイクルによる自動階層化／失効と両立しない点を設計時に握っておく必要があります。改ざん耐性を優先するなら S3 Object Lock（コンプライアンスモード） を検討し、ライフサイクルと併用する設計が現実的です。

5-2. 使う：Athena のスキャン量を「パーティション射影」で削る

貯めたログを SQL で調べるとき、コストは **Athena のスキャン量（$5/TB・us-east-1・要確認）**で決まります。クエリの速さではなく「何バイト読んだか」が請求になる——ここが直感に反するポイントです。

CloudTrail ログは AWSLogs/<account>/CloudTrail/<region>/<year>/<month>/<day>/ という構造で日付パーティションが自然に存在します。これを パーティション射影（partition projection） でテーブル定義に埋め込むと、WHERE の日付・リージョン条件に該当するパーティションだけをスキャンし、全件読みを回避できます。

-- パーティション射影でスキャン量を日付・リージョンに限定する例
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;

鉄則：Athena では WHERE でパーティション（region/date）を必ず絞る。日付条件のないクエリはバケット全体をスキャンし、$5/TB がそのまま効いてきます。「同じ答えを得るのに、いくらバイトを読んだか」を意識するだけで、分析コストは桁で変わります。FinOps の発想としてはTerraform で作るスタートアップのコスト最適化やDynamoDB のキャパシティ設計と同じ——「課金されるのは確保した量・読んだ量」を構造で制御するということです。

5-3. CloudTrail Lake の取り込み・クエリ料金と保持階層、そして「新規終了」の現実

CloudTrail Lake は ETL なしで監査ログを SQL クエリできるマネージドな選択肢ですが、コスト構造が S3＋Athena とは大きく異なります（us-east-1・要確認）。

注目すべきは クエリ単価の差です。Lake のクエリは $0.005/GB スキャン、Athena は $5/TB（＝$0.005/GB）スキャンで、スキャン単価自体はほぼ同等。差は「取り込み課金（Lake は GB 単価で取り込み時に課金、S3＋Athena は S3 保管のみ）」と運用負荷（ETL/テーブル定義の有無）のトレードオフに出ます。クエリ頻度が高く運用を任せたいなら Lake、貯めるのが主目的でたまに調べるだけなら S3＋Athena がコスト効率的、という見極めになります。

重要（2026年の現実）：CloudTrail Lake は 2026年5月31日をもって新規顧客の受付を終了しました。既存顧客は引き続き利用できますが、これから監査ログ基盤を新規構築するなら、S3＋Athena（＋必要に応じて CloudWatch） が事実上の標準的な選択肢です。AWS 自身も Lake のデータを CloudWatch へ移行することを推奨しています。本記事の長期保管・分析設計を S3＋Athena 中心に組んでいるのは、この事情も踏まえています。(CloudTrail Lake availability change)

6. コストの可視化と歯止め

「気づいたら高い」を構造的に潰すには、課金が走り始める前に気づく仕組みが要ります。

6-1. Cost Explorer でサービス別・使用タイプ別に見る

Cost Explorer で サービス＝CloudTrail / S3 / Athena / KMS をフィルタし、UsageType で内訳（PaidEventsRecorded 等）を見れば、コストがどの次元から来ているかが分解できます。CloudTrail 本体が安いのに請求が高いなら、犯人はほぼ S3 ストレージか Athena スキャンです。

6-2. AWS Budgets ＋ コスト異常検知

# 監査ログ関連サービスに対する月次予算とアラートの考え方（簡略例）
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"]}
  }'

予算超過の通知に加え、AWS Cost Anomaly Detection（コスト異常検知） を CloudTrail/S3 に向けて設定しておくと、データイベントの設定ミスや突発的な KMS イベント爆発を「いつもと違う増え方」として早期に捕捉できます。閾値ベースの予算（後から気づく）と、傾向ベースの異常検知（早く気づく）の二段構えが効果的です。

6-3. タグでコスト配賦する

証跡の配信先バケットや EDS にコスト配賦タグ（CostCenter・Environment 等）を付け、Cost Explorer でタグ別に見られるようにしておくと、「どのチーム・どの環境の監査ログがコストを牽引しているか」が一目でわかります。マルチアカウント・マルチチームほど効果が大きい打ち手です。

7. 月額コスト試算の実例（概算・要確認）

実際の相場観を 2 つのシナリオで示します。金額は us-east-1 基準の概算であり、件数・リージョン・最新単価で必ず再計算してください。

シナリオ A：正しく設計した中規模アカウント（管理イベントのみ・マルチリージョン証跡 1 本）

• 管理イベント 1 本のマルチリージョン証跡 → 各リージョン 1 コピー目 → CloudTrail $0
• KMS イベントは Exclude 済み（2 コピー目もなし）
• S3 への配信ログ：月に数十 MB〜数百 MB 程度、ライフサイクルで IA/Glacier へ階層化

これが「CloudTrail は正しく設計すればほぼ無料」の実体です。監査要件を満たしながら、コストはノイズレベルに収まります。

シナリオ B：データイベント全開（同じアカウントで設計を間違えた場合）

• 全 S3 バケットの読み取り・書き込みデータイベントを無条件記録
• 仮に月 30 億件のデータイベント

同じアカウント・同じ監査目的でも、設計次第で $0 と $3,000 の差が出ます（概算・要確認）。この差は「料金が高いサービスだから」ではなく、境界を知らずに記録対象を絞らなかったから生まれます。コスト最適化とは、結局のところ「必要なものだけを記録する設計」に尽きます。

8. まとめ：CloudTrail コスト最適化チェックリスト

最後に、現場でそのまま使えるチェックリストにまとめます。

• 管理イベントは「1 リージョン 1 コピー」になっているか（マルチリージョン証跡＋単一リージョン証跡の二重配信＝2 コピー目の罠を踏んでいないか）
• Organizations 環境で、メンバーの重複証跡を棚卸ししたか（組織トレイルと同じ管理イベントを拾う個別証跡は課金）
• データイベントは高度なセレクタで外科的に絞ったか（readOnly=false・特定 ARN のみ／全 S3・全 Lambda の無条件記録になっていないか）
• SSE-KMS による KMS イベント爆発を Exclude で抑えたか（監査要件と照合した上で）
• S3 ライフサイクルでストレージクラスを階層化したか（IA → Glacier IR → Deep Archive、保持期間で失効）
• MFA Delete とライフサイクルの非互換を理解し、改ざん耐性は Object Lock で代替したか
• Athena はパーティション射影で WHERE 必須にし、スキャン量を制御しているか
• 新規構築なら CloudTrail Lake ではなく S3＋Athena を選んだか（Lake は 2026/5/31 新規受付終了）
• Cost Explorer・AWS Budgets・コスト異常検知で歯止めをかけたか
• 配信先にコスト配賦タグを付け、内訳を可視化したか

CloudTrail のコストは、複雑な料金表に振り回される話ではありません。「無料の境界」を正しく理解し、記録対象を構造で絞り、貯める／使うを分けて設計する——たったこれだけで、監査要件を満たしながらコストを読める状態に持っていけます。

私はサーバーレス決済基盤の信頼性レイヤーを主導し、本番二重課金 0 件を「祈り」ではなくコードの構造で実現してきました。一人 ×　生成 AI（Claude Code）で、速く・安く・安全に。監査ログのコスト設計も、決済の正しさも、根は同じ「構造で担保する」という規律です。

監査ログのコストが読めない・想定外に膨らんでいる、あるいは CloudTrail / S3 / Athena を含む FinOps をコードの構造から見直したい——そんなときは、お問い合わせからお気軽にご相談ください。現状の証跡構成を棚卸しし、無料の境界に沿った設計へ最短で寄せます。

出典（すべて公式・最新値は各ページで要確認）

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