What Is AWS CloudTrail? Who Did What in Your AWS Account

AWS CloudTrail is the audit log of your AWS account — a record of who did what, when, from where, for every console click, command-line call, and API request that touches your account. It has been recording since the minute the account was created, it costs nothing to look at, and the last 90 days are sitting in the console right now waiting for you. That is the part everyone learns eventually. Here is the part almost nobody learns until it matters: the audit log that records everything does not, by default, record the things you would most want audited. CloudTrail will tell you who deleted a server, who changed a permission, and who signed in as root at 3 a.m. It will not tell you who downloaded the customer file from your S3 bucket — not because it can’t, but because that category of event is switched off until you turn it on and agree to pay for it. This post explains how CloudTrail works, exactly what it records and what it quietly doesn’t, where the free ends and the bills begin, and it keeps the promise the last post in this series made: a $0 alarm that emails you the moment anyone signs in as the root user.

This is the eighteenth stop in the Learn AWS for Free series, and it is the natural sequel to the CloudWatch post. That one answered "what happened?" — the graphs, the logs, the alarm that wakes you. The first question after "what happened?" is always "who did that?", and CloudWatch cannot answer it. CloudTrail can, usually within five minutes of it happening.

What is CloudTrail used for? The key-card log and the CCTV

My friend Ethan, who has explained more of AWS to me over coffee than any certification course, put it this way. An office building has a smoke detector — that is CloudWatch, the thing that notices something is burning. It also has a key-card system at every door, logging which badge opened which door at what time. That key-card log is CloudTrail. It does not know what you did inside the room; it knows you went in, when, and which badge you used. And notice the thing it is not: it is not a camera pointed at every desk. If you want to know who read which file once they were inside, you have to install those cameras separately — and in AWS, those cameras are called data events, they are off by default, and they are the only part of CloudTrail that routinely ends up on the bill. Hold on to that picture; the whole post fits inside it.

Technically, CloudTrail records events. An event is one API call — and in AWS, everything is an API call. Clicking "Terminate" on an EC2 instance in the console is a call to TerminateInstances. Running aws s3 mb in a terminal is a call to CreateBucket. Attaching a policy to a user in IAM is AttachUserPolicy. Every one of those produces a CloudTrail event that names the identity that made the call, the time, the source IP address, the tool used (browser, CLI, SDK), the parameters sent, and what came back — including the error code if it failed. Failed calls are recorded too, which matters more than it sounds: a run of AccessDenied errors against your bucket at 3 a.m. from an IP address you do not recognize is the most useful line CloudTrail will ever show you.

How does CloudTrail work? One event, dissected

Every event is a JSON document, and once you can read one, the whole service makes sense. These are the fields you will actually use, in the order you will reach for them when something has gone wrong.

Two fields deserve a second look. userIdentity includes the access key ID used to sign the call, which is how you trace a mystery action back to a specific laptop, CI runner, or leaked credential — the key ID is the fingerprint. And invokedBy explains the moments CloudTrail seems to show far more activity than you remember causing: one CloudFormation deployment fans out into dozens of EC2, RDS, and IAM calls, each logged, each attributed to CloudFormation acting for you. This is normal and expected, and it is why the log of a small account can look busy.

Event history, trails, and Lake — three ways to keep the same record

CloudTrail confuses beginners because it offers three containers for what is essentially one stream of events, and the console presents them as if you should already know the difference. You do not need all three. Most readers of this series need exactly the first two.

The plain reading: Event history is the free viewer and it is where you will do most of your looking. A trail is how you stop the 90-day clock — the same events, written as compressed JSON files into an S3 bucket you own, forever. Lake is the grown-up option for organizations that need to ask "show me every IAM change made by a contractor in the last three years" and get an answer in seconds rather than an afternoon. There is a fourth path worth one sentence: a trail can also forward events into CloudWatch Logs, which is how CloudTrail plugs into the alarms you already learned to build.

Is CloudTrail enabled by default? Yes — with a 90-day memory

Yes. Every AWS account has Event history switched on from the moment it exists, at no charge, with no configuration. Open the CloudTrail console, click Event history, and you will see the last 90 days of management events for whichever region the console is currently set to. Management events are the control-plane actions — creating, changing, and deleting things: launching instances, editing security groups, attaching policies, signing in. If you have done anything in the account in the last three months, it is there.

Two limits define the free viewer, and both bite at the worst moment. First, 90 days is a hard wall. Day 91, the oldest events are gone, and no support ticket brings them back. The moment you need CloudTrail is usually the moment someone asks "when did this bucket become public?" — and if the answer is "four months ago," Event history has already forgotten. The trail in the next-but-one section fixes this for free. Second, Event history is per region. It shows the region selected in the top-right corner of the console. Actions in Ohio do not appear while you are looking at Virginia, and there is a special case that catches everyone once: global services — IAM, STS, CloudFront, and console sign-ins — log their events in US East (N. Virginia), regardless of where you were working. If you are searching for a sign-in or an IAM change and finding nothing, switch to N. Virginia before you conclude it never happened. Readers of the CloudWatch post will recognize the pattern: billing metrics live only in N. Virginia too. It is the region where AWS keeps the things that belong to the whole account.

The audit log’s blind spot: data events are off

Here is the reveal from the top of the post, in full. CloudTrail divides the world into management events (actions on the account’s furniture: create, modify, delete, sign in) and data events (actions on the contents: reading or writing an object in S3, invoking a Lambda function, getting or putting an item in DynamoDB). Management events are logged by default and the first copy is free. Data events are not logged unless you turn them on, and when you do, they are billed at $0.10 per 100,000 events (US East, as of August 2026).

Think about what that means in practice. Someone with a leaked access key downloads every file in your customer-uploads bucket. CloudTrail, in its default state, records nothing about it — the bucket was not created, modified, or deleted, so nothing management-shaped happened. You would see the sign-in, the ListBuckets call, perhaps a policy change. The thousand GetObject calls that actually walked out with the data are invisible. The audit log does not log the thing you would most want audited, and it is not a bug: data events on a busy bucket run into the millions per day, and AWS made the sane default of not charging everyone for a firehose most people never read.

The honest arithmetic, because this is exactly where the "why is CloudTrail so expensive" searches come from. S3 charges roughly $0.40 per million GET requests to serve your objects. CloudTrail charges $1.00 per million data events to log that they were served. Recording the read costs two and a half times more than the read itself. A bucket doing 50 million object reads a day would pay about $20 a day to S3 and about $50 a day to CloudTrail for the diary — roughly $1,500 a month of logging on a $600-a-month bucket. So the rule is not "never enable data events." It is: enable them surgically, on the one bucket holding the sensitive files, filtered to write events or to a prefix, using the advanced event selectors that exist precisely for this. For a personal project with a few thousand objects, data events on that one bucket cost pennies and buy you the one line you would beg for after a breach.

Who deleted my EC2 instance? Finding the answer in four minutes

Jake called on a Tuesday with the calm voice people use when they are not calm. A client’s staging server — an EC2 instance that had run for eight months — was simply gone. Not stopped. Terminated, disappeared from the list, the way instances do an hour after termination. The client’s first theory was that AWS had "lost" it. The client’s second theory, delivered more quietly, was that Jake had. Jake knew the answer lived in CloudTrail; he just had not opened it before. Four minutes later he had the event: TerminateInstances, 11:52 p.m. the previous night, userIdentity an IAM user named cleanup-script, userAgent a Python SDK, sourceIPAddress a small VPS the client had rented years earlier. A former contractor’s cost-saving cron job, still running, still holding a key nobody had rotated, had finally matched a tag it was told to match. Nobody lost anything. Something did exactly what it was told, and the key-card log named it. The instance was rebuilt from the AMI; the key was deleted the same hour. What Jake remembers is not the bill or the rebuild — it is that the accusation dissolved the moment he could show the line.

That search, step by step, so it takes you four minutes too:

1. Open the CloudTrail console and click Event history in the left menu. Check the region selector in the top right — it must be the region the instance lived in.
2. In the Lookup attributes dropdown choose Resource name and paste the instance ID (i-0abc…). If you no longer have the ID, choose Event name and type TerminateInstances instead.
3. Widen the time range if needed — the default view is short. Anything within 90 days will appear.
4. Click the event. The summary shows the user, time, and source IP; click View event for the full JSON, including the access key ID under userIdentity.
5. If the identity is an assumed role, the sessionContext block names who or what assumed it — follow that one level up.
6. From a terminal, the same search is one line: aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=i-0abc123 --region us-east-1.

The same recipe answers every variant of the question: who made the bucket public (PutBucketPolicy, PutBucketAcl), who changed the security group (AuthorizeSecurityGroupIngress), who created that access key (CreateAccessKey), who turned off logging (StopLogging — and yes, CloudTrail logs the attempt to silence CloudTrail).

How to enable CloudTrail: create the free trail, step by step

A trail is what stops the 90-day clock. AWS lets you deliver one copy of your management events to an S3 bucket at no CloudTrail charge; the only cost is S3 storage, and a small account’s management events amount to a few megabytes a month — cents. Do this once, today, and future-you will have the answer to a question that has not been asked yet.

1. In the CloudTrail console click Trails, then Create trail.
2. Give it a name (account-audit is fine). Leave Create new S3 bucket selected; CloudTrail names and configures it. Trails created in the console are multi-region automatically — all enabled regions, one bucket. Keep that.
3. Log file SSE-KMS encryption is on by default and creates a KMS key. For a personal account you may uncheck it to avoid the small KMS charge; S3’s own encryption still applies. Organizations should leave it on.
4. Check Log file validation. It is free, and it is what lets you prove later that nobody edited the log.
5. Leave CloudWatch Logs off for now. It works, but it routes every event through CloudWatch Logs ingestion at $0.50 per GB — small for a small account, but not $0. We build the root-sign-in alarm below without it.
6. Click Next. On the events page keep Management events checked with Read and Write. Leave Data events and Insights events unchecked unless you have read the two sections above and chosen a bucket on purpose.
7. Review and Create trail. Within about five minutes the first compressed JSON files appear in the bucket under AWSLogs/<account-id>/CloudTrail/<region>/. Set an S3 lifecycle rule to move them to Glacier after 90 days if you want the storage cents to become storage fractions of cents.

One limit and one warning. You can have up to five trails per region; you need one. And if the trail is ever misconfigured — the bucket deleted, the bucket policy broken — CloudTrail keeps trying to deliver for 30 days and bills the attempts at the standard rate for anything beyond the free copy. A trail you no longer want should be deleted, not abandoned.

Is CloudTrail free? The honest allowance

For most readers of this series: yes, entirely. The prices below are US East as of August 2026, checked against AWS’s pricing page the day this was written; the free items are permanent, not a 12-month trial.

Read the table top-down and the shape is clear: the things a beginner needs are in the first two rows and cost nothing. Everything below the line is either a duplicate, a firehose, or an analytics product — all legitimate, none accidental if you know they exist. The trouble is that two of them can be switched on with a single check box in the trail wizard, which is why the next section exists.

Why is CloudTrail so expensive? The four ways a free service bills you

A CloudTrail line item on a personal bill almost always traces to one of four decisions, usually made by accident, usually in the trail wizard.

1. Data events on every bucket. The wizard’s data-events section offers "All current and future S3 buckets" as a convenient default. On an account that hosts a static website or an app that reads objects on every request, that one check box turns a free audit log into the arithmetic from the blind-spot section: $1 per million reads, two and a half times the cost of the reads. The fix is the advanced event selectors: name the one bucket, choose write-only if reads are noise to you, add a prefix if the sensitive files live in one folder. Or use S3 server access logs for the busy bucket — a different, cheaper product for a different question (traffic, not identity).

2. A second trail. The first copy of management events is free; the second is $2 per 100,000. Organizations create a second trail on purpose (one for security, one for operations). Individuals create one by accident — a tutorial said "create a trail," the account already had one, and now every event is paid for twice. Check the Trails page; if there are two and you cannot say why, delete one.

3. CloudWatch Logs delivery. Checking "send to CloudWatch Logs" in the trail routes every event through CloudWatch Logs ingestion at $0.50 per GB, then stores it there at the default retention of never expire. For a quiet account that is cents; for a busy one with data events on, it is the CloudWatch surprise bill from the last post wearing a new hat. If you need alarms on specific API calls, the EventBridge route in the next section is free.

4. Lake with the wrong retention plan. Lake’s seven-year plan costs $2.50 per GB against $0.75 for the one-year extendable plan, and the extendable plan can be extended to ten years anyway. Unless a regulator has told you in writing which plan to use, the extendable one is the right default. And the 30-day trial is generous — 5 GB ingested, 5 GB scanned — but it ends, and an event data store you forgot about keeps ingesting at full price on day 31.

The $0 "who pressed the button" alarm, step by step — promise kept

The CloudWatch post ended with a promise: an alarm for "who pressed the button." The button that matters most in any AWS account is the root sign-in. The root user can do anything, including closing the account, and the IAM post told you to lock it in a drawer and use it almost never. So a root sign-in is either you, on purpose, on a day you will remember — or it is the worst email you will ever be glad you received. This alarm sends that email within minutes, costs $0, and does not need a trail, CloudWatch Logs, or a single metric filter. It uses the fact that CloudTrail hands every management event to Amazon EventBridge as it happens, and EventBridge rules that match AWS service events are free.

1. Switch the console to US East (N. Virginia). Console sign-ins are global events and CloudTrail records them in this region only. A rule built anywhere else will never fire — this is the step that breaks nearly every first attempt.
2. Have an SNS topic with a confirmed email subscription. If you built the billing alarm in the CloudWatch post you already have one in N. Virginia; reuse it. Otherwise open SNS, create a standard topic named account-alerts, add an email subscription, and click the confirmation link that arrives. Unconfirmed subscriptions deliver nothing, silently.
3. Open Amazon EventBridge, click Rules, then Create rule. Name it root-sign-in, leave the event bus as default, choose Rule with an event pattern, and click Next.
4. Under Event source choose AWS events or EventBridge partner events. Scroll to the pattern editor, choose Custom patterns (JSON editor), and paste:

   {
     "detail-type": ["AWS Console Sign In via CloudTrail"],
     "detail": {
       "userIdentity": { "type": ["Root"] }
     }
   }

5. Click Next. For the target choose AWS service, then SNS topic, and select account-alerts. Click Next through tags, review, and Create rule.
6. Test it honestly. Sign out, sign in as root once (MFA and all), sign out again. The email arrives within a few minutes with the raw event: time, source IP, and whether MFA was used. If nothing arrives in fifteen minutes, the rule is almost certainly not in N. Virginia, or the subscription was never confirmed.
7. Optional, still free: add a second rule that matches "eventName": ["StopLogging", "DeleteTrail", "UpdateTrail"] under "source": ["aws.cloudtrail"]. Anyone trying to blind the log now announces it to your inbox.

Seven steps, $0 a month, and the single highest-value security control a small account can have. The billing alarm from last time tells you when money is leaving. This one tells you when the keys to the building were used. Wear both.

CloudTrail vs CloudWatch vs AWS Config: which one answers which question

Three services, three questions. Ethan’s building again: the smoke detector, the key-card log, and the building inspector who walks the floors and writes down the state of every room. Nobody asks the smoke detector who came in; nobody asks the key-card log whether the fire door is currently propped open. Pick the service by the question.

The confusion between CloudTrail and CloudWatch is the most-searched of these, and the fix is one sentence: CloudWatch is what your resources say; CloudTrail is what your people say to AWS. A Lambda function printing "order failed" goes to CloudWatch Logs. A person deleting that Lambda function goes to CloudTrail. The two connect — a trail can forward into CloudWatch Logs — but they are different rooms. Config is different again: it does not care who changed the security group, it cares that the security group currently allows port 22 from the world, and it will keep telling you until it doesn’t. And GuardDuty is the reader nobody has time to be — the service that reads the key-card log so you do not have to. It gets its own post.

What CloudTrail does not record

Knowing the edges is what separates people who trust CloudTrail from people who are surprised by it. It does not record anything that happens inside an operating system: the commands someone typed after SSH-ing into an EC2 instance, the files they edited, the packages they installed. From CloudTrail’s point of view, the instance was launched and the instance was stopped; the eight hours in between are the OS’s business, and you need the CloudWatch agent or a proper endpoint tool for those. It does not record your application’s own logs — that is CloudWatch Logs. It does not record data events until asked, as discussed at length. It does not record traffic — who visited your website, what they requested; that is CloudFront and load-balancer access logs. And a small number of AWS services and specific API actions are not integrated with CloudTrail at all; AWS publishes the list, and it shrinks every year, but "not in CloudTrail" does not always mean "did not happen."

One more edge that reads like a bug and is not: CloudTrail records the request, not the content. For a PutBucketPolicy call it records the whole policy document, because the policy is a parameter. For a PutObject data event it records the bucket, the key, and the size — never the bytes. It is a log of doors, not a copy of what walked through them.

CloudTrail delay: why the event isn’t there yet

You did the thing, you opened Event history, it is not there. Breathe; this is the most common CloudTrail "not working" report and it is almost never a fault. AWS states that CloudTrail typically delivers an event within about five minutes of the API call, and that the time is not guaranteed. Trail files land in S3 on roughly the same rhythm — a new batch every five minutes or so. If you are refreshing at minute two, wait. If it has been fifteen minutes, run down this list in order: wrong region (the action happened in Ohio, you are looking at Virginia); global service (IAM, STS, sign-ins — look in N. Virginia); it was a data event (an S3 read or a Lambda invocation, which Event history never shows and a trail only shows if data events are on); it was a read-only call and your trail is write-only (Event history shows both; a trail shows what its selectors say); or it was a call CloudTrail does not support. Genuinely missing events, after all five, are rare enough to be worth a support case.

Protecting the log from the person you are logging

An audit log is only worth something if the person it might incriminate cannot edit it. Event history is immutable by design — nobody, including the root user, can alter or delete it inside its 90 days. A trail’s files in S3 are ordinary objects, which is why a few settings exist to make them trustworthy. Log file validation, the free check box from the trail wizard, makes CloudTrail write an hourly digest file containing a SHA-256 hash of every log file it delivered, signed with a key only AWS holds; aws cloudtrail validate-logs later proves nothing was changed or removed. The bucket itself should be private, with a policy that lets only CloudTrail write and only a security role read; for real paranoia, S3 Object Lock in compliance mode makes deletion impossible for a set period, by anyone. In a company, an organization trail created from the management account logs every member account into one bucket that the member accounts cannot switch off — the person being logged does not own the log. And the free EventBridge rule from step seven above means any StopLogging or DeleteTrail lands in your inbox before whoever ran it has finished typing the next command.

CloudTrail Lake and Insights — when 90 days and grep stop being enough

CloudTrail Lake is what you graduate to when the questions get harder than one filter can express. It ingests events into an event data store — a managed, columnar database — and lets you ask in SQL: every access key created in the last year and never used; every security group change made outside working hours; every call from an IP range that is not your office. It comes with fourteen managed dashboards and a "Highlights" view that surfaces oddities such as a spike in cross-account access, refreshed every six hours. It can also swallow AWS Config snapshots and events from outside AWS, which is how it competes with a SIEM for organizations that do not want to run one. Its cost is the ingestion price in the table plus half a cent per gigabyte scanned by a query, and its first 30 days give you 5 GB each way to decide.

CloudTrail Insights is narrower and cleverer: it learns your account’s normal rate of management calls and error rates, then emits an Insights event when either goes strange — a burst of RunInstances that looks like crypto-mining on a stolen key, a wave of AccessDenied that looks like someone probing permissions. It takes up to 36 hours after enabling to establish a baseline, costs $0.35 per 100,000 management events analyzed, and is the closest CloudTrail comes to reading its own log for you. If that sentence sounds like what you actually want — something that reads the log and taps you on the shoulder — that is GuardDuty, and it is the next promise this series makes.

If you’re here for the certification

CloudTrail is exam furniture. AWS Certified Cloud Practitioner wants the one-liner (CloudTrail = who did what; CloudWatch = performance; Config = configuration state) and the fact that it is on by default with 90 days of history. Solutions Architect Associate adds the operational details this post walked through: multi-region trails, log file validation, S3 as the destination, global services logging to N. Virginia, data events as a separate opt-in. The Security Specialty lives here — organization trails, KMS-encrypted logs, Object Lock, EventBridge rules on StopLogging, Insights, and knowing what CloudTrail does not capture. If a question offers CloudTrail as the answer to "why is my instance slow," it is a distractor; if it offers CloudWatch as the answer to "who changed the bucket policy," same. The 2026 certification changes post has the current exam lineup.

FAQ — AWS CloudTrail, answered straight

What is AWS CloudTrail in one sentence?

The audit log of your AWS account: one recorded event for every API call and console action, naming who did it, when, from where, with what, and whether it worked.

Is CloudTrail enabled by default?

Yes. Event history has recorded management events since the account was created and shows the last 90 days per region at no charge. Anything longer, or any data events, needs a trail or Lake.

Is AWS CloudTrail free?

The 90-day Event history is free, and one trail delivering management events to your S3 bucket is free apart from S3 storage (cents). Data events, extra trail copies, Insights, and Lake are paid.

How does CloudTrail work?

Every AWS service reports each API call to CloudTrail, which packages it as a JSON event (identity, time, IP, action, parameters, result), shows it in Event history, and optionally delivers it to S3, CloudWatch Logs, EventBridge, or a Lake data store.

What is the difference between CloudTrail and CloudWatch?

CloudWatch records what your resources are doing (metrics, application logs, alarms). CloudTrail records what people and programs did to your account (API calls tied to an identity). Health versus audit.

What is the difference between CloudTrail and AWS Config?

CloudTrail is a log of actions ("user X changed the security group at 3 p.m."). Config is a record of state ("this security group allows port 22 from anywhere, and has since Tuesday"). Config has no free tier.

How long does CloudTrail keep logs?

Event history: 90 days, fixed. A trail: as long as your S3 bucket keeps the files — indefinitely by default, or governed by a lifecycle rule. Lake: up to ten years on the one-year extendable plan, seven on the seven-year plan.

Does CloudTrail log S3 object reads and downloads?

Not by default. Object-level reads and writes are data events, switched off until you enable them on a trail or Lake store, at $0.10 per 100,000 events. Enable them on the sensitive bucket only.

Why is CloudTrail so expensive?

Almost always data events enabled on every bucket or every Lambda function, then a second trail duplicating management events, CloudWatch Logs delivery, or a Lake store on the seven-year plan. The free configuration is one trail, management events only.

How do I find out who deleted or stopped my EC2 instance?

CloudTrail console, Event history, correct region, lookup attribute Resource name = the instance ID (or Event name = TerminateInstances or StopInstances). The event shows the user, access key, IP, and tool.

Why is CloudTrail not showing my event?

Delivery takes about five minutes, not guaranteed. After that: wrong region, a global-service event living in N. Virginia, a data event with data events off, a read-only call on a write-only trail, or an action CloudTrail does not support.

Is CloudTrail regional or global?

Events are recorded per region, and Event history shows one region at a time. Global services (IAM, STS, CloudFront, console sign-in) record in US East (N. Virginia). A console-created trail is multi-region and gathers every region into one bucket.

What is a CloudTrail trail?

A configuration that delivers events as compressed JSON files to an S3 bucket you own, with optional delivery to CloudWatch Logs and EventBridge. It is how you keep events past 90 days. You may have five per region; you need one.

What is CloudTrail Lake?

A managed, SQL-queryable store of CloudTrail events (and optionally Config items and outside-AWS events) with dashboards, priced per GB ingested and per GB scanned. Built for investigations and compliance, not for a first project.

What are CloudTrail Insights events?

Anomaly detections: CloudTrail learns your normal API call and error rates and emits an Insights event when they spike. Opt-in, $0.35 per 100,000 management events analyzed, up to 36 hours to baseline.

Can CloudTrail send an alert or email?

Not by itself. Management events flow into EventBridge, where a free rule can target an SNS topic that emails you — the root-sign-in alarm above. Alternatively a trail feeds CloudWatch Logs, where a metric filter and alarm do the same for a small ingestion charge.

Can the root user delete CloudTrail logs?

Event history cannot be altered by anyone. A trail’s S3 files can be deleted by whoever has bucket access — which is why log file validation, a locked-down bucket policy, Object Lock, and an organization trail owned by a different account exist.

What is the difference between CloudTrail and GuardDuty?

CloudTrail writes the log; GuardDuty reads it. GuardDuty is a threat detector that continuously analyzes CloudTrail events, DNS logs, and VPC flow logs and raises findings such as "credentials used from an unusual country." CloudTrail is free to record; GuardDuty is a paid service with a 30-day trial.

What is the CloudTrail equivalent in Azure and Google Cloud?

Azure’s Activity Log (inside Azure Monitor) and Google Cloud’s Cloud Audit Logs play the same role: a per-subscription or per-project record of who called which API, kept 90 days by default in Azure and 400 days for admin activity in Google Cloud, with longer retention by exporting to storage.

Is CloudTrail a SIEM?

No — it is the most important source a SIEM reads. CloudTrail records; GuardDuty, Security Hub, or a third-party SIEM interpret. Lake with Insights covers a surprising amount of the gap for a small team.

Where to go next

Revision note. Written August 29, 2026, with every price checked against AWS’s CloudTrail pricing page the same day and stamped "as of August 2026" where it appears — data-event rates and Lake plans are exactly the numbers AWS adjusts without announcement, so if one has moved by the time you read this, tell us through the contact page and we will bring the page back to true. This post keeps the promise the CloudWatch post made: the "who pressed the button" alarm is real, it is above, it took seven steps and costs nothing. The next promise is made twice in the text — Amazon GuardDuty in plain English: the guard who reads the log for you — because once you have a record of every door that opened, the next honest question is who is going to sit and read it. And if you found this page the way Jake did, at the wrong end of a "who did this?" conversation: open Event history before you answer anyone. The line is almost always there, it is almost always a forgotten script or an old key rather than a person, and the accusation tends to dissolve the moment you can show it. Then create the trail. Future-you will need more than 90 days.