AWS environments rarely suffer from a shortage of logs. VPC Flow Logs record network flows. CloudTrail records API activity. Application Load Balancer and AWS WAF logs describe web requests. GuardDuty turns several of those signals into findings.
The difficult part is not collecting more data. It is knowing which part of an intrusion each source can prove—and joining those fragments without inventing certainty that the logs do not contain.
What “AWS native logs” actually means
“AWS native logs” is an operational term, not a single AWS product. It usually refers to logs and security outputs generated by AWS services and delivered to destinations such as Amazon S3, CloudWatch Logs, or Data Firehose. Much of the data is JSON or follows a defined schema, although traditional ALB access logs are space-delimited and VPC Flow Logs support default and custom formats.
There is also an important distinction between evidence and analysis. VPC Flow Logs, CloudTrail, ALB access logs, and WAF logs are observations. A GuardDuty finding is an analytical result produced from logs, threat intelligence, and detection models. Treating all five as equivalent raw events leads to weak detection logic.
Five sources, five parts of the attack
VPC Flow Logs: the shape of a connection
VPC Flow Logs describe IP traffic to and from network interfaces. Records can include addresses, ports, protocol, packet and byte counts, accept or reject actions, and custom fields such as tcp-flags, pkt-srcaddr, flow-direction, and traffic-path.
They are not packet captures. A record aggregates a five-tuple flow over a capture window of up to one or ten minutes, and TCP flags can be OR-ed during that interval. Flow Logs cannot prove that a host sent “100 SYN packets in one second.” What they can reveal is a pattern: SYN-heavy flows to an unusual number of destinations, a sudden rise in outbound traffic, repeated rejected connections, or communication with infrastructure absent from the workload baseline.
tcp-flags=2 is not a verdict. Evaluate packet and byte counts, duration, destination cardinality, reverse SYN-ACK or RST flows, the network action, and the role of the asset. Where NAT or another intermediate layer is involved, preserve packet-level address fields so normalization does not hide the original endpoint.
CloudTrail: identity, privilege, and persistence
Most AWS console actions eventually become API calls. CloudTrail records who made a request, when and where it was made, the service and action, source address, client, request parameters, response elements, and errors. The investigation pivots are userIdentity, eventName, sourceIPAddress, userAgent, requestParameters, responseElements, and errorCode.
Assume an access key was exposed through an application vulnerability or public repository. An attacker will usually discover the credential’s reach before creating a more durable path. Discovery calls such as GetCallerIdentity, ListUsers, ListRoles, and ListBuckets become more significant when followed by CreateUser, CreateAccessKey, CreateRole, policy attachment, PassRole, AssumeRole, or changes to logging, KMS, security groups, and bucket policies.
Failed calls matter too. A burst of AccessDenied results across unrelated services and Regions can expose permission probing. A principal that normally uses the console but suddenly calls APIs from a new network through aws-cli or an unfamiliar SDK adds valuable context. Coverage must be explicit: S3 object operations such as GetObject and PutObject are data events, not ordinary management events.
ALB access logs: what reached the application edge
Application Load Balancer access logs sit in a similar investigative position to Apache access.log, with additional AWS context. They expose the client, request line, User-Agent, load balancer and target status codes, processing times, routing actions, TLS details, and trace identifiers. Requests that never reached a target can still appear.
This is where activity missed by WAF may become visible. A request can be allowed because no rule covers a new payload, yet still cause a target-side 500 response or an abnormal delay. A client may rotate encoding while probing the same vulnerable route. ALB logs do not replace WAF logs; they explain the traffic WAF allowed and the application behavior that followed it. Once a new payload is verified, that evidence can be fed back into a WAF custom rule or label-based policy.
AWS WAF logs: the first contact with the web surface
WAF logs capture request details, the applied action, the terminating rule, non-terminating matches, labels, and rate-based rule information. They are useful for reconstructing RCE and injection attempts, path traversal, automated crawling, scans for administrative or backup paths, and changes in payload after a block.
Do not treat every X-Forwarded-For value as the attacker address. Define which proxies are trusted and whether they append or overwrite the header, then align WAF forwarded-IP configuration and SIEM normalization to that trust model. Tor or hosting-provider addresses, scanner User-Agents, unusual headers, and rapid URI expansion are supporting signals—not sufficient reasons for an automatic block by themselves.
GuardDuty findings: a starting point, not a conclusion
GuardDuty analyzes foundational sources including CloudTrail management events, VPC Flow Logs, and DNS logs. Depending on enabled protection plans, it can also analyze S3 data events, EKS audit activity, RDS logins, Lambda network activity, runtime events, and other workload-specific signals.
Map type, severity, resource details, action, remote address and port, first and last seen times, and occurrence count into the SIEM. More importantly, retain a path back to the CloudTrail or flow evidence supporting the finding.
GuardDuty currently classifies findings as Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), and Low (1.0–3.9). Opening tickets only at severity 7 or above may be a useful baseline, but severity alone is not enough. A production role, internet-facing instance, and unused Region do not carry the same risk as their development equivalents. Protection-plan scope should follow the workloads the organization actually runs and the signals it can respond to, rather than a memorized number of plans.
The SIEM should join evidence, not merely store it
Correlation rules remain the center of a useful SIEM. AI can summarize alerts and help an analyst write queries, but it cannot rescue a SOC whose detection logic does not reflect how attacks unfold.
Consider this sequence:
- An external address repeatedly targets SSH on an EC2 instance and generates a GuardDuty finding.
- Within 12 hours, the address appears as a CloudTrail
sourceIPAddress, using a compromised IAM credential for discovery calls. - A new role or access key is created and a policy is attached.
- S3 data events show unusual
GetObjectorPutObjectactivity. - VPC Flow Logs show the workload communicating with a new external destination.
Joined into one case, this sequence has far more evidentiary value than five independent alerts. The analyst no longer has to move between consoles simply to prove that the events belong to the same incident.
IP address alone is not a safe join key. Corporate NAT, VPNs, mobile networks, CDNs, and proxies create shared addresses, while attackers rotate infrastructure. Strong correlation combines an appropriate time window with IAM principal ARN, access key, role session and sourceIdentity, account, Region, instance or ENI, bucket, API action, outcome, and volume.
Normalization must not destroy source-specific evidence. A common schema enables search and joining, but the true-positive decision often depends on requestParameters, WAF match details, or the unmodified ALB request line. Keep the original event identifier and S3 location with the case so that every conclusion can be reproduced.
Separate detection from automated response
| Layer | Purpose | Example | Default treatment |
|---|---|---|---|
| Single-source detection | Fast visibility | New access key, WAF RCE match, High GuardDuty finding | Alert or enrichment |
| Correlated detection | Confirm an attack sequence | SSH targeting → credential use → privilege change → S3 access | High-priority case |
| Automated response | Execute a tested, reversible action | Temporary block or evidence collection | SOAR workflow |
SOAR should not disable a production identity merely because a severity score is high. Confidence and reversibility both matter. Enrichment, evidence collection, historical-ticket lookup, notification, and a temporary WAF IP Set entry are relatively safe to automate. Disabling credentials, isolating workloads, or deleting policies should retain an approval step until the workflow has earned trust through measured outcomes.
The goal is not to pour every AWS-native source into one expensive index. It is to preserve the evidence that matters, normalize the fields used for detection, separate single-source and correlated rules, and automate only the response paths whose true-positive rate has been demonstrated.
A mature SOC is not the one with the most logs. It is the one that can explain scattered events as a defensible timeline.