CloudTrail & AWS Config
Recording every API call made in your account for audit purposes, and continuously checking whether your resources' configuration matches the rules you've defined.
Want a visual for this topic?
Generate a diagram tailored to CloudTrail & AWS Config — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what CloudTrail records and why it's essential for security investigations
- •Explain the difference between CloudTrail (what happened) and AWS Config (current/historical state and compliance)
- •Write a basic AWS Config rule that flags a non-compliant resource
- •Explain why CloudTrail logs should be sent to a separate, restricted account
What is it?
AWS CloudTrail records every API call made within your AWS account — who made it, what action, on what resource, when, and from where — providing a complete audit trail of account activity. AWS Config continuously monitors and records your AWS resources' configuration, and can evaluate that configuration against rules you define, flagging or even auto-remediating non-compliant resources.
Why it exists
Security investigations, compliance audits, and simply understanding 'who changed this and when' all require a reliable record of account activity — without it, you're left guessing based on incomplete memory or scattered evidence. CloudTrail exists to make this record automatic and comprehensive from the moment an account is created. Separately, knowing a resource's current configuration is correct at the moment you set it up doesn't guarantee it stays correct — configuration drift happens as people make changes over time. AWS Config exists to continuously track configuration state and actively check it against your defined rules, catching drift as it happens rather than discovering a problem much later.
Problem it solves
CloudTrail solves the 'what happened' problem (a definitive, tamper-evident record of every API call for security investigation, audit, and troubleshooting). AWS Config solves the 'is this still configured correctly' problem (continuous compliance checking against defined rules, plus a historical timeline of exactly how a resource's configuration has changed over time).
Intuition
CloudTrail is like a building's security camera system, recording every single entry, exit, and action taken by everyone, all the time, so if something goes wrong you can review exactly what happened. AWS Config is more like a building inspector who continuously re-checks whether every room still meets code requirements, immediately flagging (or in some cases automatically fixing) any room that's drifted out of compliance since the last check, rather than only inspecting once at initial construction.
Analogy
CloudTrail is a financial institution's transaction ledger — an immutable record of every single transaction, who initiated it, and when, essential for any later audit or fraud investigation. AWS Config is more like a compliance officer running continuous automated checks against every account's balance and status, flagging anything that violates a defined policy the moment it happens, rather than only during an annual audit.
Technical explanation
CloudTrail is enabled by default in every AWS account for the last 90 days of management events, viewable in the Console — but a CloudTrail Trail (a persistent, configured log delivery to S3 and optionally CloudWatch Logs) is needed for long-term retention, and is considered essential for any production account. Trail logs should be delivered to a separate, tightly restricted logging account (a standard multi-account security pattern) so that even a compromised or malicious administrator in the monitored account cannot delete or tamper with the audit evidence of their own actions. AWS Config Rules can be AWS Managed Rules (pre-built, covering common compliance checks like 's3-bucket-public-read-prohibited') or custom rules backed by a Lambda function for organization-specific logic; rules can be configured to trigger automatic remediation via Systems Manager Automation documents for certain non-compliant findings, not just flag them for manual review.
Architecture
A regulated company's AWS Organization sends every member account's CloudTrail logs to a centralized, dedicated logging account with highly restricted access (only the security team, and even they cannot delete logs due to S3 Object Lock configured on the destination bucket) — ensuring audit evidence survives even a full compromise of any individual workload account. AWS Config runs across all accounts with rules checking for common security misconfigurations (public S3 buckets, unencrypted EBS volumes, overly permissive security groups), feeding a compliance dashboard the security team reviews continuously rather than only during periodic manual audits.
Workflow
- Enable a CloudTrail Trail (beyond the default 90-day event history) delivering logs to S3, ideally in a separate, access-restricted logging account. 2) Enable AWS Config and select which resource types to track (or track all supported types for comprehensive coverage). 3) Enable relevant AWS Config Managed Rules covering your organization's actual security and compliance requirements. 4) For high-confidence, low-risk violations, configure automatic remediation; for anything requiring human judgment, route findings to a review queue instead. 5) Periodically review both CloudTrail (for anomalous activity) and Config compliance dashboards (for configuration drift) as an ongoing security practice, not a one-time setup.
Example
During a security investigation into an unexpected IAM policy change, a team queries CloudTrail and finds the exact API call (PutUserPolicy), the specific IAM user who made it, their source IP address, and the precise timestamp — information that would be effectively unrecoverable without CloudTrail's automatic recording. Separately, an AWS Config rule continuously checks that no S3 bucket in the account has public read access enabled; when a developer accidentally misconfigures a bucket, Config flags it as non-compliant within minutes, well before it might otherwise have been discovered during a periodic manual security review.
Real-world usage
CloudTrail is considered a non-negotiable baseline control in essentially every AWS security compliance framework (SOC 2, PCI DSS, HIPAA) and AWS's own security best practices; AWS Config is widely used for continuous compliance monitoring, commonly paired with AWS Security Hub to aggregate findings from Config and other security services into one unified dashboard.
Trade-offs
CloudTrail's default 90-day Console-viewable history is free and requires no setup, but a proper long-term Trail with S3 delivery costs storage and requires deliberate configuration — the tradeoff of setup effort against actually having audit evidence available beyond 90 days, which most compliance and serious incident-investigation needs require. AWS Config's automatic remediation is powerful for fast response to common misconfigurations, but automating remediation for anything involving nuanced judgment risks incorrectly 'fixing' something that was actually an intentional exception — manual review remains appropriate for anything without a very high-confidence, unambiguous fix.
Visual explanation
Picture every API call made in your account — from the Console, CLI, or SDK — flowing into CloudTrail, which records it as an immutable event with full detail (caller identity, source IP, action, resource, timestamp, success/failure). Separately, picture AWS Config maintaining a continuously updated record of every tracked resource's configuration, evaluating each one against a set of Config Rules (e.g. 'every S3 bucket must have encryption enabled') and flagging any resource currently out of compliance, along with a full historical timeline of exactly when its configuration changed and to what.
Advantages
- —
CloudTrail provides a comprehensive, automatic audit trail with no application code changes needed — every API call is captured regardless of how it was made
- —
AWS Config catches configuration drift continuously, rather than only during periodic manual audits, significantly shortening the window a misconfiguration goes unnoticed
- —
AWS Config's historical configuration timeline lets you see exactly what a resource's configuration was at any past point in time, not just its current state
- —
Both integrate natively with the rest of AWS's security tooling (Security Hub, GuardDuty, EventBridge for automated response)
Disadvantages
- —
CloudTrail and Config both generate real storage and (for Config) rule-evaluation cost at scale, which needs to be budgeted for rather than assumed negligible
- —
The default 90-day CloudTrail event history isn't sufficient for most compliance requirements — a properly configured Trail with appropriate retention is essential, not optional
- —
AWS Config rules require genuine tuning to your organization's actual policies — the managed rules cover common cases but won't catch every organization-specific requirement without custom rules
- —
Neither service prevents a misconfiguration or malicious action from happening — they detect and record it; preventive controls (SCPs, IAM policies) are still needed as the first line of defense
Common mistakes
- —
Relying on CloudTrail's default 90-day Console history without configuring a proper Trail with S3 delivery, losing audit evidence beyond that window when it's later needed
- —
Sending CloudTrail logs to the same account being monitored, allowing a compromised administrator in that account to potentially delete or tamper with the very evidence of their own actions — logs should go to a separate, restricted account
- —
Enabling AWS Config without actually reviewing and acting on its compliance findings, turning it into unused overhead rather than a genuine active control
- —
Configuring automatic remediation for a Config rule without fully considering edge cases where the flagged configuration was actually an intentional, legitimate exception
- —
Treating CloudTrail/Config as sufficient security controls on their own, without recognizing they're detective (recording/flagging what happened) rather than preventive (stopping it from happening in the first place) — both are needed together
In the AWS Console
- 1
AWS Console → CloudTrail → Trails → Create trail
Name the trail, select or create an S3 bucket for log delivery (ideally in a separate logging account), and enable log file validation for tamper-evidence.
Apply the trail to 'all Regions' so activity is captured account-wide, not just in the Region you happened to be viewing when creating it.
- 2
AWS Console → Config → Settings → Get started
Choose which resource types to record (or all supported types) and specify the S3 bucket for configuration history and snapshot delivery.
Recording all resource types gives the most comprehensive coverage but does have a small per-resource cost — scope deliberately if cost is a specific concern.
- 3
Config → Rules → Add rule
Search for and add relevant AWS Managed Rules (e.g. 's3-bucket-public-read-prohibited', 'encrypted-volumes'), or create a custom rule backed by a Lambda function for organization-specific logic.
Review each rule's evaluation results after enabling it, since a newly-added rule may immediately flag existing resources that were already non-compliant before the rule existed.
- 4
CloudTrail → Event history
Search and filter recorded events by resource, user, event name, or time range to investigate a specific action.
For investigations beyond the 90-day default window, you'll need to query the S3-delivered Trail logs (directly, or via Athena for structured querying) rather than this Console view.
🎤 Interview questions
What's the fundamental difference between what CloudTrail and AWS Config each track? (Listen for: CloudTrail records every API call — the 'who did what, when' activity log; Config tracks resource configuration state over time and evaluates it against compliance rules.)
Why should CloudTrail logs be sent to a separate AWS account rather than staying in the monitored account? (Listen for: prevents a compromised or malicious administrator in the monitored account from being able to delete or tamper with the evidence of their own actions.)
How would you detect that an S3 bucket was accidentally made publicly readable, and how quickly? (Listen for: an AWS Config rule like s3-bucket-public-read-prohibited continuously evaluates this and flags it as non-compliant typically within minutes, much faster than a periodic manual audit would catch it.)
Are CloudTrail and Config preventive or detective controls? (Listen for: detective — they record/flag what happened or what's currently misconfigured, but don't themselves prevent the action; preventive controls like SCPs and IAM policies are still needed as the first line of defense.)
How would you investigate who deleted a specific S3 bucket last week? (Listen for: query CloudTrail (via Event History for recent activity, or the S3-delivered Trail logs / Athena for longer-term history) filtering for the DeleteBucket event on that specific resource.)