AWS threat detection refers to identifying and prioritizing malicious or suspicious activity in AWS by analyzing cloud telemetry for signs of attacker behavior. Rather than evaluating single events in isolation, this approach examines what an actor is doing across identities, roles, and services. With 80% of organizations experiencing at least one cloud security breach in the past year and public cloud incidents averaging $5.17 million per breach, the stakes for effective AWS threat detection continue to grow.
AWS environments generate large volumes of logs and metadata that are difficult to interpret independently. Connecting this telemetry into behavioral signals helps reveal attacker movement through a cloud attack lifecycle, which matters because uncorrelated activity can delay investigation and response.
En la práctica, la detección de amenazas de AWS vincula las acciones relacionadas con patrones de comportamiento que pueden investigarse y priorizarse. En lugar de tratar cloud como una colección de alertas inconexas, interpreta la actividad como evidencia de una posible secuencia de ataques. Esta distinción es importante porque muchas acciones de AWS son técnicamente legítimas, pero siguen representando un abuso de acceso, funciones o servicios.
Activity types that reveal intent across time and services:
AWS provides several native security services that form the foundation of a cloud threat detection strategy. Understanding what each tool does — and where gaps remain — helps teams build effective detection coverage.
Amazon GuardDuty is the primary AWS threat detection service. It continuously analyzes CloudTrail management events, VPC Flow Logs, DNS query logs, and runtime telemetry using machine learning, anomaly detection, and integrated threat intelligence. In December 2025, AWS launched Extended Threat Detection for EC2 and ECS, which uses AI/ML to correlate signals across multiple data sources and map multi-stage attack sequences to MITRE ATT&CK tactics.
Security Hub aggregates findings from GuardDuty, Amazon Inspector, AWS Config, and third-party tools into a unified dashboard. It provides compliance checks against standards like CIS AWS Foundations and supports automated remediation through integrations with AWS Lambda and Amazon EventBridge.
Detective complements GuardDuty by providing deeper investigative analysis. When GuardDuty identifies a high-severity finding, Detective helps trace the origin, scope, and relationships of the suspicious activity across resources.
Table: AWS native threat detection services compared
These native tools provide essential coverage, but they focus on activity within AWS. Attacks that start outside AWS — through compromised identity providers, on-premises networks, or SaaS applications — require additional correlation across hybrid environments to detect the full attack chain.
Log-centric monitoring in AWS often fails to expose attacker behavior because events are analyzed as standalone records. Attribution frequently stops at the most recent role or temporary credential, causing investigations to focus on the wrong abstraction. As a result, defenders may not identify the original actor in time to contain activity before impact.
Failure modes when AWS activity is evaluated as isolated events:
Understanding how attackers move through AWS requires looking beyond individual service actions. Behavior-focused detection highlights progression patterns, such as role chaining, logging evasion, and lateral service access, that can appear legitimate when viewed in isolation.
Progression patterns:
No todas las señales en AWS tienen el mismo valor investigativo. Los esfuerzos de detección dan prioridad a los indicadores que reflejan un comportamiento anormal o de múltiples pasos vinculado a un actor específico. Los indicadores tempranos pueden ser sutiles y dispersos, mientras que las señales tardías a menudo solo aparecen después de que se ha producido un daño significativo.
Key signals:
Recent incidents illustrate why behavioral detection matters more than log-level monitoring alone.
The Codefinger ransomware group exploited compromised AWS credentials to encrypt S3 data using server-side encryption with customer-provided keys (SSE-C). Because the attackers used legitimate AWS encryption features rather than malware, traditional signature-based detection tools missed the activity. Only behavioral monitoring — detecting unusual bulk encryption operations tied to a suspicious credential chain — could surface the attack before data became unrecoverable.
Amazon Threat Intelligence documented a campaign in which a Russian-speaking financially motivated threat actor used commercial generative AI services to compromise over 600 FortiGate devices across 55+ countries between January 11 and February 18, 2026. The attackers leveraged AI to scale their operations, demonstrating that AI-augmented threats are accelerating attack volume for both skilled and unskilled adversaries.
In February 2026, a threat actor exploited an unpatched React frontend application running on AWS to gain initial access, then abused an over-permissive ECS task role with broad read access to AWS Secrets Manager. This enabled exfiltration of Redshift credentials, VPC maps, and millions of database records. The incident mapped to MITRE ATT&CK techniques including T1190 (exploit public-facing application), T1078 (valid accounts), and T1530 (data from cloud storage object) — underscoring why monitoring identity and role behavior is essential for AWS threat detection.
These incidents share a pattern: attackers used legitimate AWS mechanisms (encryption features, valid roles, temporary credentials) to carry out malicious activity that looked normal at the event level but revealed itself through behavioral analysis.
La detección de amenazas en AWS aún tiene sus limitaciones. Si bien puede identificar comportamientos sospechosos, la detección de amenazas no previene ni remedia automáticamente los riesgos cloud . Esto significa que los equipos aún deben depender de los flujos de trabajo de respuesta y el criterio de los analistas. Confundir la detección con la prevención puede crear puntos ciegos que retrasen la contención.
Table: Misconceptions vs. corrections
Several trends are reshaping how organizations approach threat detection in AWS environments.
Supporting AWS threat detection requires understanding attacker behavior across identity, network, and cloud activity as a single continuum. The Vectra AI Platform approaches this problem by correlating actions instead of treating AWS events as isolated alerts, which reduces uncertainty when roles, temporary credentials, and multi-service activity obscure attribution. Vectra AI's Cloud Detection and Response (CDR) for AWS extends detection beyond native tools by analyzing behaviors across hybrid attack surfaces.
Platform capabilities:
See AWS attacker behavior in action with a guided attack tour
La supervisión de CloudTrail registra eventos individuales, mientras que la detección de amenazas de AWS tiene como objetivo conectar eventos entre identidades, roles, servicios y tiempo para revelar el comportamiento de los atacantes. Los eventos de registro aislados pueden mostrar lo que sucedió, pero a menudo no muestran la intención o la progresión, especialmente cuando los atacantes utilizan credenciales temporales y roles asumidos. La diferencia práctica es investigativa: la detección de amenazas da prioridad a los patrones de comportamiento de varios pasos que se pueden atribuir y sobre los que se puede actuar, en lugar de dejar que los analistas recopilen manualmente la narrativa a partir de registros sin procesar.
No. La detección de amenazas de AWS no previene ni soluciona por sí sola los problemas de arquitectura o configuración. La gestión de configuraciones incorrectas se centra en identificar ajustes inseguros y condiciones de exposición, mientras que la detección de amenazas se centra en identificar actividades maliciosas o sospechosas que se producen dentro de un entorno AWS. Es importante no confundir estas funciones, ya que los equipos pueden asumir que la detección sustituye a la seguridad de la configuración, dejando sin abordar los puntos de entrada principales y esperando que la detección de amenazas lo compense.
La identidad y los roles son fundamentales porque los atacantes suelen operar utilizando mecanismos de acceso legítimos tras el compromiso inicial, incluyendo roles asumidos y credenciales temporales. Las acciones pueden parecer válidas a nivel de API incluso cuando representan un abuso, por lo que la atribución se vuelve esencial para comprender quién inició una secuencia y si esa secuencia se ajusta al comportamiento esperado. Esto es importante porque el encadenamiento de roles puede ocultar al actor original, y las investigaciones pueden fracasar si se detienen en el último rol temporal utilizado.
El comportamiento en varios pasos que utiliza mecanismos legítimos de AWS es más difícil de detectar cuando se evalúa evento por evento. El encadenamiento de roles, las secuencias de credenciales temporales y las acciones que parecen normales de forma aislada a menudo requieren una correlación entre servicios e identidades para cobrar sentido. Estos patrones son difíciles porque pueden distribuirse entre varios servicios de AWS y ventanas de tiempo, y porque la última credencial utilizada puede no reflejar al actor original. Esto es importante porque el comportamiento sutil en las primeras etapas puede pasarse por alto hasta que surgen los indicadores en las últimas etapas.
Sí, pero solo cuando el enfoque conecta la actividad entre entornos en lugar de tratar AWS como un dominio aislado. Los ataques híbridos pueden originarse a través de ordenadores portátiles o proveedores de identidad comprometidos y posteriormente pivotar hacia AWS utilizando relaciones de identidad de confianza y roles asumidos. Sin la correlación entre la identidad y la telemetría relacionada, la actividad de AWS puede parecer desconectada de la ruta de compromiso inicial. Esto es importante porque los defensores necesitan comprender cómo se relacionan cloud con el acceso anterior para delimitar correctamente el alcance de la respuesta y la atribución.
Amazon GuardDuty performs active threat detection by analyzing CloudTrail events, VPC Flow Logs, and DNS logs using machine learning to identify malicious behavior. AWS Security Hub is a centralized findings aggregator that collects and prioritizes alerts from GuardDuty, Amazon Inspector, AWS Config, and third-party tools. GuardDuty detects threats. Security Hub organizes and manages them. Most organizations use both together — GuardDuty as the detection engine and Security Hub as the operational dashboard for prioritizing response across accounts and regions.
Start with Amazon GuardDuty enabled across all AWS accounts and all regions — including regions not actively in use, since attackers target unmonitored regions for activities like cryptomining. Feed GuardDuty findings into AWS Security Hub for centralized visibility. Add Amazon Detective for investigating high-severity findings. Then configure EventBridge rules with Lambda functions to automate responses to critical alerts. This layered approach provides detection, aggregation, investigation, and automated response.
Threat actors increasingly use commercial generative AI services to scale their attacks against cloud infrastructure. In early 2026, Amazon Threat Intelligence documented a campaign where attackers used AI to compromise over 600 network devices across 55+ countries, then pivoted into cloud environments. AI helps attackers automate reconnaissance, generate exploit code, and identify misconfigurations faster than manual methods allow. This trend makes behavioral detection more important because AI-augmented attacks generate higher volumes of activity that can overwhelm rule-based detection systems.
Extended Threat Detection is a capability launched in December 2025 that uses AI and machine learning to identify multi-stage attack sequences across AWS services. Instead of generating separate findings for each suspicious event, it correlates signals — such as credential abuse, privilege escalation, and data exfiltration — into a single attack sequence mapped to MITRE ATT&CK tactics. This reduces triage time by showing the full attack story rather than leaving analysts to manually connect individual findings.