DevOps Peach

AWS Basics · Monitoring – CloudWatch, CloudTrail, and AWS Config · Lesson 4 of 5

AWS CloudTrail

Investigate API activity, management/data events, and retention.

Practice interactively →

Audit API activity

CloudTrail records AWS API activity from the Console, CLI, SDKs, and services: who did what, when, from where. Event history provides recent management events for 90 days at no cost; create a trail or CloudTrail Lake event data store for longer retention and broader analysis.

flowchart LR
  C["Console, CLI, SDK<br/>DeleteBucket"] --> T["CloudTrail event<br/>JSON record"]
  T --> H["Event history<br/>90 days, management"]
  T --> TR["Trail<br/>all Regions"]
  TR --> S3["S3 bucket<br/>log file validation"]
  TR --> CWL["CloudWatch Logs<br/>alarms on events"]
  S3 --> ATH["Athena<br/>SQL queries"]
  %% step C: Every API call, including Console clicks, is an API request.
  %% step T: CloudTrail writes a record with identity, action, time, source IP and parameters.
  %% step H: Event history keeps 90 days of management events per Region for free.
  %% step TR: A trail, ideally multi-Region and organization-wide, delivers every event continuously.
  %% step S3: Logs land in S3; log file validation detects tampering.
  %% step CWL: Sending to CloudWatch Logs allows metric filters and alarms, such as on root sign-in.
  %% step ATH: Athena or CloudTrail Lake runs SQL over months of events.

Event types

Management events cover control-plane operations such as RunInstances, TerminateInstances, PutBucketPolicy, or IAM policy changes; trails log them by default. Data events cover high-volume resource operations such as S3 GetObject/PutObject or Lambda Invoke and are not included by default in a basic trail or Event history; enable them selectively with event selectors because they cost extra. Network activity events record API calls through VPC endpoints. Insights events — CloudTrail Insights detects unusual management write activity against a baseline when enabled, such as a sudden burst of TerminateInstances.

Reading an event

To answer “who deleted the resource?”, inspect fields such as:

Field Tells you
userIdentity IAM user, role session (and who assumed it), root, or AWS service
eventName The API action, e.g. DeleteDBInstance
eventTime When (UTC)
sourceIPAddress Where the call came from, or an AWS service name
requestParameters What was asked, e.g. which bucket
errorCode Present if the call failed, e.g. AccessDenied

A CloudWatch metric reports behavior or performance, not the audit actor.

Setting it up well

  1. Create a multi-Region trail (in AWS Organizations, an organization trail from the management account).
  2. Deliver to a dedicated, locked-down S3 bucket in a log-archive account, encrypted with KMS.
  3. Enable log file validation to prove logs were not altered.
  4. Send to CloudWatch Logs and alarm on sensitive events: root login, IAM policy changes, StopLogging, Security Group changes.
  5. Protect the trail itself: an SCP can deny cloudtrail:StopLogging and DeleteTrail.

CloudTrail answers who called which API; it does not record what happens inside an instance or a database query.

Command Purpose
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=TerminateInstances --max-results 5 Find an API event
aws cloudtrail create-trail --name org-trail --s3-bucket-name audit-logs-123 --is-multi-region-trail --enable-log-file-validation Create a trail
aws cloudtrail start-logging --name org-trail Start delivery
aws cloudtrail get-event-selectors --trail-name org-trail View data-event configuration

Traps: expecting S3 object reads in Event history; relying on the 90-day history for long audits; using CloudWatch metrics to find out who deleted something.

Practice interactively →