Cloud Logging Gap Checker
In a cloud incident, the first hard questions are about logs: who downloaded the bucket? What did the leaked key do? Which identities did the attacker create? Pick your provider, tick what you have enabled and how long you keep it, and see which questions you could answer today, which you could not, and what to turn on first. Everything runs in your browser.
Intrusions are often found weeks or months after they start, and questions from regulators, customers or lawyers can arrive later still. A common baseline is 12 months retained with the last 3 months quickly searchable (the PCI DSS v4.0 logging requirement uses those figures).
What is turned on in AWS?
Starts from what you get out of the box. Tick what you have enabled and set how long you keep it.
Management events only, per region, for the last 90 days. On by default; cannot be extended.
Retention90days· shorter than your look-backA multi-region (ideally organisation) trail delivering to S3. Not created by default.
GetObject, PutObject, DeleteObject and similar object-level calls. Off by default; charged per event.
Who invoked which function. Off by default.
Network connections in and out of your VPCs. Off by default.
Threat findings such as crypto-mining, credential use from unusual places, and (with S3 Protection) suspicious bucket access. Off by default.
Per-request access records for a bucket, delivered best-effort. Off by default.
Requests reaching your public applications. Off by default.
Configuration history of resources: what a bucket policy or security group looked like and when it changed. Off by default.
Alerts when spend jumps. May already exist on newer accounts; check who receives the alerts.
The questions you will be asked in an incident
- Cannot answer“Would we have been told about a spend spike within hours?”No enabled log can answer this.
- Cannot answer“Were we alerted to known-bad behaviour such as crypto-mining or key use from unusual places?”No enabled log can answer this.
- Cannot answer“Which IP addresses did a compromised instance talk to, and how much data left?”No enabled log can answer this.
- Cannot answer“Was a Lambda function invoked with stolen credentials, and by whom?”No enabled log can answer this.
- Cannot answer“What hit our public application before the breach?”No enabled log can answer this.
- Only partly“Who downloaded objects from the bucket?”Partly, from CloudTrail event history (bucket-level calls only, not object reads).
- Only partly“What did a bucket policy or security group look like before it was changed?”Partly, from CloudTrail event history (shows the new value in the request).
- Not far enough back“What API calls did the leaked key make (creates, changes, deletes)?”Only for the last 90 days, from CloudTrail event history.
- Not far enough back“Which IAM users, roles, keys or policies did the attacker create or change?”Only for the last 90 days, from CloudTrail event history.
- Not far enough back“Did they launch resources in regions we never use?”Only for the last 90 days, from CloudTrail event history.
Retention against your look-back
- CloudTrail event history: 90 days kept, 275 days short.
Fixes in priority order
- 1Create a multi-region organisation trail to an S3 bucket in a separate log-archive account, with log file validation and Object Lock or a tight bucket policy. Keep at least 12 months.Cost: low · Helps answer: “What API calls did the leaked key make (creates, changes, deletes)?”, “Which IAM users, roles, keys or policies did the attacker create or change?”, “Did they launch resources in regions we never use?” and 1 more
- 2Enable GuardDuty in every region through a delegated administrator, with S3 Protection, and export findings to S3 or your SIEM.Cost: medium · Helps answer: “Would we have been told about a spend spike within hours? (partly)”, “Were we alerted to known-bad behaviour such as crypto-mining or key use from unusual places?”, “Which IP addresses did a compromised instance talk to, and how much data left? (partly)”
- 3Turn on server access logging for buckets with sensitive data, writing to a separate logging bucket.Cost: low · Helps answer: “Who downloaded objects from the bucket?”
- 4Enable S3 data events for buckets holding sensitive data (use advanced event selectors to limit cost to those buckets).Cost: medium · Helps answer: “Who downloaded objects from the bucket?”
- 5Set up Cost Anomaly Detection monitors and budget alerts that reach a person who will act out of hours.Cost: low · Helps answer: “Would we have been told about a spend spike within hours?”
- 6Enable VPC Flow Logs on VPCs with production or sensitive workloads; send to S3 for cheap long retention.Cost: medium · Helps answer: “Which IP addresses did a compromised instance talk to, and how much data left?”
- 7Enable the Config recorder in all regions (an aggregator gives one view across accounts).Cost: medium · Helps answer: “What did a bucket policy or security group look like before it was changed?”
- 8Enable access logs on internet-facing load balancers.Cost: low · Helps answer: “What hit our public application before the breach?”
- 9Enable Lambda data events for functions that touch sensitive data or hold privileged roles.Cost: medium · Helps answer: “Was a Lambda function invoked with stolen credentials, and by whom?”
What this tool is
- Pick AWS, Azure or Google Cloud, tick the logs you have enabled and set how long you keep them.
- The checker shows which incident questions you could answer — "who downloaded the bucket?", "what did the leaked key do?", "which identities did the attacker create?" — and which you could not.
- It compares each log's retention with how far back you may need to look, and lists the fixes in priority order, weighted by how much each one closes.
- Starts from the providers' out-of-the-box defaults, which is where most organisations discover the gaps. Copy the result as a plain-text report.
- Runs entirely in your browser. Nothing is uploaded and no cloud account is touched.
You cannot turn logging on after the breach
Every other part of incident response can be improvised under pressure. Logging cannot. If object-level storage logs were off when the attacker read your bucket, no amount of forensics will tell you which files they took — and the notification decision then has to assume the worst. The same is true for network flows, secret reads and sign-ins older than the provider's default retention.
The defaults differ by provider. Some control-plane history is always there (AWS CloudTrail event history, the Azure Activity Log, Google Cloud Admin Activity audit logs), which is why “what did the key change?” is usually answerable for recent events. Data access is the gap: reads of objects, blobs, secrets and databases are off by default almost everywhere, because they are the most voluminous and cost money to keep. Turn them on where the sensitive data lives, not everywhere.
Retention is the second gap. A 90-day window sounds generous until an intrusion is found in month four. Export control-plane and identity logs to storage you control — ideally a separate, locked log-archive account or project — and keep them at least a year.
Frequently asked questions
What cloud logs are on by default?
Less than most people assume. AWS keeps 90 days of management events in CloudTrail event history, but object-level S3 access, VPC Flow Logs, GuardDuty and Config are off until you enable them. Azure keeps the Activity Log for 90 days and Entra ID sign-in and audit logs for a period that depends on your licence (Microsoft documents 7 days on the free tier and 30 days with P1 or P2); storage, Key Vault and flow logs are off. Google Cloud always records Admin Activity audit logs and keeps them for 400 days, but Data Access audit logs — the ones that show who read data — are off for most services and kept for 30 days by default.
Which log tells me who downloaded files from an S3 bucket?
CloudTrail data events for S3 or S3 server access logs. CloudTrail management events and event history only show bucket-level calls such as listing buckets or reading a bucket policy, not who read individual objects. If neither was enabled when the incident happened, you cannot reconstruct object downloads afterwards, and you have to tell counsel that access cannot be ruled out.
How long should we keep cloud logs?
Long enough to cover the time between an intrusion starting and you investigating it, plus the time it takes for questions to arrive from regulators, customers or litigation. Intrusions are commonly found weeks or months after they start. A widely used baseline is 12 months retained with the last 3 months quickly searchable; regulated sectors may need more. Older data can go to cheap archive storage.
Is this tool accurate for my account?
It reflects documented provider defaults as of late 2026 and simplifies some details (for example, logs that only cover some services, or licence-dependent retention). Providers change defaults over time. Use it to find the questions you would struggle to answer, then confirm against your own configuration and the provider documentation.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.