AWS Security Monitoring Guide: How to Detect Threats in Your AWS Environment

AWS is the most targeted cloud environment in the world. The same openness that makes it powerful — API-first, accessible from anywhere, granular IAM — makes it a rich attack surface. Effective AWS security monitoring requires understanding both the native services AWS provides and the investigation layer on top that makes alerts actionable.

Background: The Shared Responsibility Model and Why Monitoring Falls on You

AWS operates on a shared responsibility model: AWS secures the underlying infrastructure (data centers, hypervisors, physical network), while the customer is responsible for securing what they put on it — operating systems, IAM configuration, network rules, and application data. This division, formalized as AWS adoption scaled in the early-to-mid 2010s, means AWS will never tell you when your S3 bucket is publicly exposed or your IAM keys are being abused from an unfamiliar IP — that visibility has to come from logging and monitoring you configure yourself. As AWS environments have grown more complex (multi-account organizations, hundreds of IAM roles, dozens of interconnected services), the monitoring burden has grown proportionally, which is exactly why AWS built native detection services like GuardDuty and Security Hub on top of CloudTrail — and why most teams still need an investigation layer beyond what AWS provides natively.

AWS Native Security Services: What to Enable First

AWS CloudTrail (Enable Immediately)

CloudTrail logs every API call made in your AWS account — who made it, from where, what resource was affected. It's the foundational audit trail for AWS security. Enable CloudTrail in all regions (not just your primary region), enable log file integrity validation, and send logs to an S3 bucket in a separate security account.

Key CloudTrail events to monitor:

• IAM changes: CreateUser, AttachUserPolicy, CreateAccessKey, UpdateAssumeRolePolicy
• Root account usage: any event where userIdentity.type = Root
• Resource exposure: ModifyImageAttribute (AMI), ModifySnapshotAttribute (snapshot), PutBucketPolicy (S3 public access)
• Security service changes: StopLogging (CloudTrail), DeleteTrail, DisableGuardDuty

Amazon GuardDuty (Enable and Configure)

GuardDuty analyzes CloudTrail, VPC Flow Logs, and DNS query logs using ML to detect threats. Unlike CloudTrail (which logs everything), GuardDuty generates targeted findings for specific threat behaviors:

• Cryptocurrency mining (EC2 instances contacting mining pools)
• Compromised credentials (API calls from unusual locations)
• Unauthorized network reconnaissance (port scanning from EC2 instances)
• Data exfiltration (unusual S3 API calls, DNS exfiltration patterns)

Enable GuardDuty in all regions. Use GuardDuty threat intel integration for enhanced detection. Set up EventBridge rules to route GuardDuty findings to your investigation platform.

AWS Security Hub (Aggregate and Prioritize)

Security Hub aggregates findings from GuardDuty, Inspector, Macie, and third-party tools into a unified view. Enable AWS Foundational Security Best Practices standard for automated compliance checks. Use Security Hub as your aggregation layer, not your investigation layer.

The Most Common AWS Attack Patterns to Detect

1. IAM Credential Compromise

Attack chain: phishing or leaked access key → attacker uses key from new IP → enumerate permissions → escalate privileges → create backdoor user → exfiltrate data. Detection signals: new IP/region for existing key, permission enumeration calls (ListPolicies, GetCallerIdentity), creation of new IAM users or access keys, policy changes granting broad permissions.

Case study scenario: A developer at a 90-person ed-tech SaaS company accidentally commits an AWS access key to a public GitHub repository. Within 40 minutes, an attacker uses the leaked key from an IP in a region the company has no business presence in, calls GetCallerIdentity and ListAttachedUserPolicies to map permissions, then creates a new IAM user with AdministratorAccess as a backdoor. GuardDuty fires three separate findings — UnauthorizedAccess, Recon:IAMUser, and PrivilegeEscalation — but they land as three disconnected alerts. An AI SOC platform correlates all three CloudTrail events plus the new-IAM-user creation into a single attack timeline within 60 seconds, flagging the backdoor account before the attacker can use it to access production S3 buckets.

2. S3 Data Exfiltration

Attack chain: compromised application → attacker discovers S3 buckets → bulk download → data sold or ransomed. Detection signals: unusual GetObject volumes from new IP, bucket policy changes enabling public access, large data egress to external IPs, ListBuckets calls from new principals.

3. Cryptomining via EC2

Attack chain: exposed EC2 API or compromised credentials → launch GPU-heavy instances in unused regions → mine cryptocurrency. Detection signals: RunInstances in unusual regions, high-cost instance types (p3, g4) launched by non-standard principals, network connections to known mining pool addresses.

Adding AI Investigation on Top of Native AWS Security

AWS native tools (GuardDuty, Security Hub) generate alerts but don't investigate them. When GuardDuty fires an IAM finding, you still need to manually answer: "Was this the attacker's first action, or have they been in the environment for days? Which resources did they touch? Have they created backdoors?" This investigation takes 30–60 minutes manually.

ZonForge Sentinel connects to CloudTrail, GuardDuty, and Security Hub and automatically investigates every finding — correlating AWS activity with Okta authentication, M365 access, and other connected sources to reconstruct the complete attack timeline in under 60 seconds. The same identity-correlation approach applies to the broader SaaS application stack and to IAM security more generally — AWS credential compromise is frequently just one link in a cross-platform attack chain.

Frequently Asked Questions