How six services combine to form a modern security-operations fabric

IN THE EARLY days of cloud computing, security monitoring meant little more than eyeballing a handful of log files. Today, an enterprise AWS environment generates billions of events daily—API calls, network flows, container runtime telemetry, database logins, object-storage access patterns. Making sense of this deluge is the central challenge of cloud detection. Amazon Web Services has responded by assembling a layered, increasingly integrated portfolio of detection tools that span from real-time threat identification to long-range forensic analysis. What follows is a tour of the six pillars that constitute the detection backbone of AWS security: GuardDuty, Security Hub, Security Lake, Config conformance packs, CloudWatch Logs Insights, and the Athena–OpenSearch analytics duo.

Amazon GuardDuty: The Perimeter That Learns

GuardDuty is the service closest in spirit to a traditional intrusion-detection system, though it sheds all the operational baggage that phrase implies. There are no sensors to deploy, no signature databases to update, no infrastructure to scale. A single API call or console click activates it across an account—or, via AWS Organizations, across an entire enterprise footprint [1].

Under the hood, GuardDuty consumes three foundational data streams: CloudTrail management events (the audit trail of every API call), VPC Flow Logs (metadata about network traffic), and DNS query logs. It also ingests S3 data-plane events, EKS audit logs, RDS login activity, Lambda network telemetry, and runtime signals from EC2, ECS, and Fargate workloads. The service then subjects this torrent—tens of billions of events—to machine-learning models, anomaly detection, and threat intelligence drawn from AWS's own global visibility and third-party sources [1].

The taxonomy of GuardDuty findings is deliberately pragmatic. It classifies threats into buckets any incident responder will recognize: reconnaissance (port scans, unusual API probing), instance compromise (cryptocurrency mining, command-and-control, data exfiltration via DNS), account compromise (calls from Tor exit nodes, credential exfiltration, attempts to disable CloudTrail), bucket compromise (suspicious S3 access patterns), malware detection (trojans, rootkits, crypto miners in EC2 and containers), and container compromise [1].

In December 2024, AWS introduced Extended Threat Detection, which uses AI to correlate disparate GuardDuty signals into multi-stage attack sequences [3]. Rather than leaving analysts to stitch together a port scan here and a credential theft there, the service now produces consolidated attack sequence findings, complete with MITRE ATT&CK mappings and prescriptive remediation guidance. Custom entity lists—arriving in 2025—allow organizations to supply their own domain and IP threat intelligence, closing the gap between AWS's global view and a company's private intelligence [2].

GuardDuty also extended runtime coverage to EC2 and ECS workloads in late 2025, and its Malware Protection for AWS Backup now scans EBS snapshots and S3 backups incrementally—inspecting only net-new data between successive backups to keep costs manageable [1]. The result is a threat-detection surface that spans compute, storage, containers, databases, serverless functions, and backup repositories, all without a single agent to maintain.

AWS Security Hub: From Noise to Narrative

If GuardDuty is the scout, Security Hub is the command center. It reached general availability in its reimagined form in December 2025, after a preview at re:Inforce earlier that year [5]. The thesis behind Security Hub is that security teams drown not in a lack of data but in a lack of correlation. An organization might run GuardDuty for threats, Inspector for vulnerabilities, Macie for sensitive-data discovery, and Config for posture management—each feeding its own console, each speaking its own dialect of severity and priority. Security Hub collapses those silos.

The service ingests findings from GuardDuty, Inspector, Macie, and its own CSPM component, then enriches and correlates them into exposures—composite security issues that reflect how real attacks materialize. For example, a publicly reachable EC2 instance with a critical vulnerability, an over-permissive IAM role, and unencrypted attached volumes is not three separate low-priority tickets. It is one exposure titled something like Potential Remote Execution: EC2 instance reachable with software vulnerabilities and excessive privileges [5].

The exposure detail page includes a visual attack-path graph that maps how an adversary could traverse from the internet through security groups, network interfaces, and IAM roles to compromise the resource. A remediation section provides prioritized guidance—which trait to fix first for maximum risk reduction. All of this updates in near real-time: deploy a vulnerable EC2 instance and Security Hub generates the exposure within seconds, not hours [5].

The Summary dashboard now stores up to a year of historical trends, with period-over-period comparisons—day-over-day, week-over-week, month-over-month—so security leaders can answer the question executives actually ask: Are we getting better or worse? [5]. A Security Coverage widget identifies which accounts and Regions lack GuardDuty, Inspector, Macie, or CSPM coverage, addressing the perennial problem of blind spots in multi-account estates.

On the automation front, Security Hub integrates with Jira and ServiceNow for direct ticket creation, supports EventBridge-based automated response workflows (triggering Lambda functions or Systems Manager runbooks), and exposes findings in the Open Cybersecurity Schema Framework (OCSF) format—an open standard now supported by over twenty partners including Splunk, CrowdStrike, Datadog, and SentinelOne [5].

Amazon Security Lake: The Single Source of Truth

Security Lake addresses a structural problem that has bedeviled security operations for decades: data fragmentation. Logs live in different accounts, different Regions, different formats—CloudTrail in JSON, VPC Flow Logs in their own schema, firewall logs from an on-premises appliance in yet another dialect. Security Lake's proposition is to centralize all of it, normalize it to OCSF, and store it in a customer-owned S3 bucket, organized into purpose-built tables partitioned by account, Region, and time [6].

The service ingests data from AWS sources (CloudTrail, Route 53 resolver queries, security findings) as well as SaaS providers, on-premises systems, and custom sources. Because the data lands in the customer's own S3, the customer retains complete ownership and can bring any analytics tool to bear—Athena, OpenSearch, SageMaker, or third-party SIEMs [6].

Security Lake also supports rollup Regions, allowing global organizations to aggregate security data into one or more central locations for compliance reporting and cross-regional investigations. The promise is straightforward: stop hunting across seventeen accounts and four Regions to answer a single question about a suspicious IP address.

Config Conformance Packs: Detection by Design

Where the previous services are reactive—detecting threats or correlating findings after the fact—Config conformance packs operate in the domain of preventive and detective controls. A conformance pack is a deployable bundle of Config rules and optional remediation actions that can be applied to a single account or an entire AWS Organizations structure [7].

AWS provides pre-built sample packs aligned with major compliance frameworks: PCI-DSS, HIPAA, NIST 800-53, CIS Benchmarks, and operational best practices. Each pack contains rules like S3 buckets must have versioning enabled, IAM policies must not grant full administrative privileges, or CloudTrail must be enabled in all Regions—all continuously evaluated against the live configuration of resources [8].

The key metric is the compliance score: the percentage of rule-resource combinations that are compliant. This quantifies configuration hygiene in a single number that can be tracked over time and compared across business units. When rules include auto-remediation—correcting non-compliant resources without human intervention—conformance packs blur the line between detection and enforcement. A misconfigured security group might be auto-corrected before it ever appears on a dashboard.

Conformance packs integrate with AWS Control Tower, making them the natural compliance layer for organizations that provision accounts through the Landing Zone model. They provide what auditors have long sought: continuous, automated evidence of control effectiveness rather than point-in-time snapshots [8].

CloudWatch Logs Insights: The Ad-Hoc Interrogator

For all the sophistication of GuardDuty and Security Hub, security analysts still need to ask ad-hoc questions of raw log data. CloudWatch Logs Insights is the purpose-built query engine for that task. It supports a concise query language with aggregation, filtering, regular expressions, and time-series operations—all without provisioning servers or defining schemas in advance [9].

A typical security query might filter for AccessDenied or UnauthorizedOperation error codes, then aggregate by IAM identity, source IP, and API action to identify credential misuse or privilege-escalation attempts. Another might count failed database logins per hour to detect brute-force attacks against RDS instances.

Since late 2024, CloudWatch Logs has layered machine-learning capabilities on top of its query engine: anomaly detection that surfaces unusual patterns in log volumes and content, and pattern analysis that automatically identifies recurring log structures to help operators spot deviations [10]. The service also includes data-protection features that scan log streams for sensitive data—credit card numbers, PII, credentials—and either mask or redact them before they land in persistent storage.

Logs Insights is lightweight compared to a full SIEM, but its deep integration with the CloudWatch ecosystem—alarms, dashboards, Contributor Insights—makes it the natural first stop for operators investigating incidents in AWS-native workloads.

Athena and OpenSearch: The Heavy Analytics Pair

When Security Lake has centralized years of security data in S3, and when CloudWatch Logs Insights is too constrained for complex correlation, two services take over: Amazon Athena and Amazon OpenSearch Service.

Athena is a serverless SQL query engine that runs directly against data in S3. It supports standard SQL, requires no indexing or ETL, and charges only for the data scanned. Security teams use Athena to run forensic queries across months or years of CloudTrail, VPC Flow Logs, and Security Lake data—joining tables, applying complex filters, and exporting results to QuickSight dashboards. The federated query capability extends Athena's reach beyond S3 into OpenSearch, relational databases, and other data sources, enabling cross-source joins without data movement [11].

OpenSearch Service provides the complementary capability: near-real-time search, dashboards, and security analytics over indexed data. Its Security Analytics plugin includes a correlation rules engine that can define threat scenarios spanning multiple log types—for example, matching a GuardDuty finding against a CloudTrail event and a VPC flow anomaly to identify a coordinated attack [12]. OpenSearch also offers Piped Processing Language (PPL), an alternative to the traditional DSL that many operators find more approachable for exploratory analysis [13]. Since 2023, Security Analytics has supported OCSF-formatted logs natively, making the integration with Security Lake seamless [14].

The division of labor is straightforward: OpenSearch for operational dashboards, alerting, and real-time threat hunting; Athena for deep-dive investigations, audit preparation, and answering questions nobody anticipated when the data was ingested.

Putting the Pieces Together

The six services form a detection stack whose layers complement rather than compete. GuardDuty watches continuously for known and anomalous threats. Security Hub correlates those findings with vulnerabilities and misconfigurations, producing a prioritized list of exposures. Security Lake ensures all the underlying data is normalized, centralized, and queryable. Config conformance packs prevent the drift that creates exposures in the first place. CloudWatch Logs Insights gives operators a fast, flexible query tool for tactical investigations. Athena and OpenSearch provide the strategic analytics platform for long-range hunting and cross-source correlation.

The direction of travel is unmistakable: AWS is stitching these services together into an increasingly coherent fabric. Security Hub's consumption of GuardDuty findings, its OCSF-native partner ecosystem, Security Lake's normalization layer, and the convergence around a common schema all point toward a future where the distinction between detection tool and analytics platform becomes irrelevant. The analyst simply asks a question, and the answer arrives—regardless of which service produced the underlying data. That, at least, is the vision. The pieces are now on the board.