AWS security logging is not a choice between three interchangeable log stores. CloudTrail Lake, CloudWatch Logs, and Amazon Security Lake were designed around different data and operational goals. CloudTrail Lake is an audit-event analytics service built around event data stores and SQL queries, but as of May 31, 2026 it is no longer open to new customers. CloudWatch Logs is the general operational log platform for collecting, searching, monitoring, and alerting on logs from AWS services and applications. Security Lake is an organization-scale security data lake that normalizes security data into OCSF and stores it in customer-owned S3 buckets. Understanding those roles is directly relevant to the detection domain of AWS Certified Security – Specialty SCS-C03.
The 2026 CloudTrail Lake availability change makes current architecture guidance especially important. Existing CloudTrail Lake customers can continue to use their event data stores, but net-new designs should not assume that a new customer can adopt Lake. AWS states that CloudTrail itself remains fully supported and points new customers toward CloudWatch for similar capabilities. That changes how a modern logging comparison should be read.
Start by separating audit events, operational logs, and a security data lake
CloudTrail records activity in AWS: who or what called an API, which action was requested, the source context, and related event information. CloudWatch Logs is broader. It can ingest application logs, operating-system logs, service logs, and CloudTrail events, then support search, metric filters, alarms, and operational investigation. Security Lake is broader in another direction: it centralizes security-relevant events from multiple AWS accounts, Regions, AWS services, custom sources, and supported third parties into a normalized data lake.
Those are different questions. “Who changed this IAM policy?” is an audit-event question. “Why is this application returning HTTP 500 errors while authentication latency spikes?” is an operational log-correlation question. “How do we retain and analyze security telemetry from CloudTrail, VPC Flow Logs, WAF, EKS audit logs, Security Hub findings, and third-party products across the enterprise?” is a security data-lake question.
The existing discussion of CloudTrail and CloudWatch is useful foundation, but current security architecture must also account for Security Lake and the changed status of CloudTrail Lake.
CloudTrail Lake remains useful for existing customers, with a new-customer constraint
CloudTrail Lake event data stores can hold CloudTrail events and several other supported event categories, and Lake queries are written in SQL. Existing customers can use it for investigations such as finding unusual API activity, querying management or data events, correlating selected event data stores, and building dashboards around stored events.
However, AWS documentation now states that CloudTrail Lake is closed to new customers starting May 31, 2026. Existing organization event data stores continue to operate, and existing customers can continue normal use. The closure applies to CloudTrail Lake, not to CloudTrail trails, Event History, Insights, or other CloudTrail capabilities.
This is more than a footnote. An architecture document written before 2026 might recommend CloudTrail Lake as the default managed SQL analytics layer for audit events. A current design for a new AWS customer must choose another approach. AWS specifically recommends exploring CloudWatch for similar capabilities, while traditional CloudTrail trails can continue delivering logs to S3 for long-term retention and can be analyzed with services such as Athena.
CloudWatch Logs is the operational investigation and alerting layer
Amazon CloudWatch Logs centralizes log data from applications, EC2 instances, CloudTrail, Route 53, and many other sources. Teams can search logs, query structured fields, create metric filters, build alarms, and integrate log events with operational workflows. This makes CloudWatch Logs a strong default when logs must drive near-real-time monitoring and incident response.
For a security team, CloudWatch Logs can receive CloudTrail events and trigger metric filters or alarms when sensitive actions occur. Application teams can correlate those audit signals with application logs and infrastructure logs in the same operational platform. A failed deployment, an access-denied spike, and a suspicious API call can therefore be investigated without treating security telemetry as isolated from system health.
CloudWatch Logs is not automatically a normalized enterprise security lake. Log groups still reflect the schemas of their sources, and retention, subscription filters, cross-account centralization, indexing, transformation, and query cost all need architecture. Its strength is operational use: ingest logs, search recent behavior, alert on patterns, and connect telemetry to response.
Security Lake is built for organization-scale security data
Amazon Security Lake automatically centralizes security-related log and event data into S3 buckets in the customer’s account. It can ingest supported AWS sources such as CloudTrail management and data events, VPC Flow Logs, WAF logs, EKS audit logs, Route 53 Resolver query logs, and Security Hub CSPM findings, as well as custom and third-party sources.
The service normalizes supported data into the Open Cybersecurity Schema Framework and stores it in Apache Parquet. That normalization is valuable when security analytics spans many source types because downstream tools do not have to treat every log format as an unrelated custom schema. Subscribers and analytics services can consume the data for detection, hunting, incident response, or long-term investigation.
Security Lake therefore fits a security-operations architecture that needs broad collection and retention across accounts and Regions. It is not merely “CloudWatch Logs but bigger.” The data-lake model, S3 ownership, OCSF normalization, lifecycle controls, and subscriber access are designed for security analytics rather than for every application developer tailing yesterday’s service logs.
Retention and query patterns should drive the platform decision
Short- to medium-term operational investigation often favors CloudWatch Logs because teams can query the same telemetry that drives alarms and dashboards. Long-term audit archives can use CloudTrail trails delivered to S3, with Athena or other analytics when historical SQL investigation is required. Existing CloudTrail Lake customers can continue using event data stores when its query and retention model fits their audit workflows.
Security Lake becomes attractive when the organization needs a centralized repository for many security sources, standardized schema, and downstream security analytics across tools. Its S3-backed model can align well with long retention and data-lake governance. The correct design may send different telemetry to more than one destination because operational monitoring and long-term security analytics have different latency, schema, and retention requirements.
The mistake is to copy every log everywhere without purpose. Duplicate ingestion can multiply cost, create inconsistent retention, and make investigators unsure which repository is authoritative. Each destination should have an explicit role: operational alerts, audit record, enterprise security analytics, or regulatory evidence.
Detection architecture needs routing, not just storage
A useful security log platform does more than retain bytes. Important events must reach detection logic and response workflows. CloudWatch metric filters and alarms can identify selected patterns. EventBridge can route findings and operational events. Security Hub can aggregate and prioritize security findings. Security Lake subscribers can feed SIEM, analytics, or incident-response systems.
For AWS DevOps Engineer – Professional DOP-C02 scenarios, CloudWatch often sits closest to operational monitoring, application behavior, alarms, and automated remediation. For SCS-C03, the architecture expands toward organization-wide logging, security data centralization, protected retention, and investigative access.
The existing discussion of AWS incident response and secure infrastructure is relevant because logs only create value when responders can trust, search, and act on them during an incident.
Protect the log pipeline itself
Security telemetry is evidence, so its integrity and availability matter. Central log accounts, restricted write and delete permissions, KMS encryption, S3 retention controls, CloudWatch log-group permissions, and separation of administrative duties can make it harder for a compromised workload account to erase its own history. Organization-level CloudTrail and Security Lake configurations can reduce gaps created by individual teams.
Access should be designed for investigators without turning log repositories into broadly readable stores of sensitive information. Logs can contain IP addresses, resource identifiers, user names, request details, and application data. Least privilege, data classification, retention limits, and controlled export matter as much as collecting the events.
AWS security services can generate findings and posture signals that belong in the log platform, but those signals still need a deliberate retention, enrichment, access-control, and investigation path. Choosing the collection layer does not remove the need to decide which evidence must remain queryable during an incident.
Choose by operating model, and account for the 2026 change
For an existing CloudTrail Lake customer that needs managed SQL queries over audit event data, continuing to use Lake can be reasonable. For a new customer, it is no longer an adoption option after May 31, 2026; CloudTrail trails, CloudWatch, S3, and query services must form the replacement architecture. For teams that need operational log monitoring and alerting across applications and AWS services, CloudWatch Logs is the natural center. For enterprises building a normalized, multi-account security data lake, Security Lake is the purpose-built choice.
Many mature environments use CloudWatch Logs and Security Lake together, with CloudTrail feeding one or both according to the use case. CloudWatch supports fast operational work; Security Lake supports broad security analytics and retention. The architecture should document which platform owns alerting, which owns long-term evidence, and which teams query each source.
The central lesson is not to choose a product by the word “log.” Choose the platform by the question investigators need to answer, the time horizon of the data, the schema and sources involved, and the actions triggered by detection. Currentness matters too: CloudTrail Lake is now an existing-customer technology, not a default recommendation for new AWS accounts.