The constraint is often visibility, not attacker sophistication
When an AWS incident is investigated late, discussion often focuses on how advanced the intrusion was. In many environments the real constraint is simpler: there is not enough telemetry to reconstruct what happened.
CloudTrail, VPC Flow Logs and data events are imperfect. They do not reveal intent or capture payloads. Their value is preserving independent pieces of evidence that, together, answer basic questions: which identity acted, when, from where, on which resource, and with what result.
How the trail disappears
In multi-account environments, event volume grows quickly. Someone reviews storage, indexing or SIEM cost and asks the inevitable question: do we need this much logging?
Optimisations usually arrive in pieces:
- read events are dropped as “noise”
- Flow Logs are limited to production, or to rejected traffic only
- S3 data events are disabled because of volume
- retention is cut to 30 or 90 days
Each decision can sound reasonable. Together, they can remove the context required to understand a compromise.
Reconnaissance is still activity
After obtaining valid credentials, an attacker does not necessarily start by deleting data. They ask questions. They enumerate. They map.
In AWS API terms that looks like legitimate Get*, List* and Describe* operations. To a product team they may look like noise. To an attacker they are a map.
If read telemetry disappears from the security pipeline, a later action such as a policy change may still be visible. What is lost is the beginning of the story: the minutes of enumeration beforehand.
The inverse pattern also exists: keep reads and filter writes. Exploration remains visible… and the moment roles, trust policies or security groups change becomes incomplete.
Read and write events describe different phases. Choosing only one is not “optimised visibility”; it is asymmetric blindness.
What useful logging architecture should preserve
A sound posture is not “log everything without judgement”. It is defining minimum signals that are affordable and useful for forensics and detection:
- CloudTrail management events with retention aligned to risk
- coverage of relevant accounts and regions, not only the “main” environment
- Flow Logs where network context matters
- selective data events on high-value resources
- a clear path from log storage to the people who investigate
The goal is not an event museum. It is the ability to answer security and business questions with evidence when it matters.
How this connects to TechRebel work
In AWS security and observability engagements we start from a simple premise: visibility is an architecture decision, not an optional add-on. We assess what is recorded, what is retained and what can still be reconstructed before discussing additional controls.
To review logging and detection posture in your AWS organisation, book a meeting or see AWS & Cloud Security.