CloudTrail Lake vs CloudWatch for Fast Audit Review (AU.L2-3.3.5)

For CloudTrail Lake vs CloudWatch CMMC audit review, use CloudWatch Logs and CloudWatch alarms to establish a review-and-escalation baseline in roughly four hours, then use CloudTrail Lake for repeatable investigation queries and management reporting as the environment matures. AU.L2-3.3.5 does not require a SIEM; it requires defined audit review, analysis, and reporting processes that are correlated well enough to investigate and respond to suspicious activity. The fastest defensible approach is a centralized CloudTrail feed, a small set of high-value detections, named reviewers, and ticketed evidence of review and response.

What is the minimum-viable definition of compliant for a CloudTrail Lake vs CloudWatch CMMC audit review?

For NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice AU.L2-3.3.5, a minimum viable implementation is not “we turned on CloudTrail.” A vCISO should be able to show an assessor that the organization can review audit records, connect related records during an investigation, report an indication of suspicious or unauthorized activity to the right people, and retain evidence that the process occurred.

For a fast baseline, define the process around AWS management events affecting the CUI environment. CloudWatch is the better first operational tool because it supports near-real-time metric filters, alarms, and Logs Insights searches. CloudTrail Lake is the better second tool because it gives the reviewer a durable, queryable event data store for incident scoping, recurring review questions, and evidence exports.

The control’s wording matters: audit review, analysis, and reporting must be correlated. That means a reviewer must not treat a failed authentication, an IAM policy change, and a security-group change as unrelated alerts when they share the same principal, IP address, time window, or affected workload. The process can begin manually, provided the procedure tells personnel what to connect and where to record the conclusion.

What should you complete in Hour 0–4?

When responding to a new DFARS 252.204-7012 flow-down, I would spend the first four hours creating a narrow but operational baseline for the AWS accounts that store, process, or transmit CUI. Do not begin by designing a perfect enterprise logging architecture. Begin by making review possible today.

1. Identify the CUI AWS boundary. List the production account or accounts, the security or logging account, the CUI S3 buckets, EC2 or ECS workloads, IAM roles, and administrators with privileged access. Record this as the initial logging scope.
2. Validate or create a Multi-Region CloudTrail. Enable management events for both read and write activity, include global service events, enable log file validation, and send logs to an encrypted S3 bucket. If the client uses AWS Organizations, use an organization trail so new in-scope accounts are not silently excluded.
3. Deliver CloudTrail to CloudWatch Logs. Use a dedicated log group such as /aws/cloudtrail/cui-production, protect access through IAM, and set a retention period that matches the client’s documented retention decision. Ninety days in CloudWatch plus longer-term encrypted S3 retention is a practical quick-start pattern.
4. Create four high-value detections. Start with CloudTrail disabled or changed, IAM privilege changes, root-account activity, and security-group or network ACL changes. These events are meaningful, reviewable, and closely tied to unauthorized or unusual activity.
5. Assign the reviewer and escalation clock. Name a primary reviewer, backup reviewer, and system owner. Require review of critical alarms within one business day and immediate escalation for suspected compromise, unauthorized privilege escalation, or log tampering.
6. Create a single investigation ticket template. Include event time, AWS account, user or role ARN, source IP, affected resource, related events, conclusion, corrective action, and notification recipients.

A useful first CloudWatch Logs Insights query for weekly review is:

fields @timestamp, eventName, eventSource, userIdentity.arn,
       sourceIPAddress, errorCode, requestParameters
| filter eventSource in ["iam.amazonaws.com", "ec2.amazonaws.com", "cloudtrail.amazonaws.com"]
| filter eventName in ["AttachUserPolicy", "PutUserPolicy", "CreateAccessKey",
                       "AuthorizeSecurityGroupIngress", "StopLogging",
                       "UpdateTrail", "DeleteTrail"]
| sort @timestamp desc
| limit 100

Save the query under a descriptive name such as AU-3.3.5 Privilege-and-Logging-Changes. The reviewer should not merely run it. They should identify whether events represent authorized change activity, correlate questionable events with change tickets and adjacent CloudTrail records, and open an investigation ticket where the conclusion is not immediately clear.

What should happen during Day 1–7?

During the first week, make the baseline repeatable and add CloudTrail Lake where it reduces investigation time. The CloudTrail Lake-versus-CloudWatch decision should be based on the question being asked: CloudWatch answers “what needs attention now?” while Lake answers “what happened across this period, account, and principal?”

For example, Northline Circuits, an 86-person PCB manufacturer, operates separate AWS accounts for its customer portal, engineering document repository, and production-support systems. Its engineering team uploads controlled Gerber packages and manufacturing instructions to designated S3 buckets. After an alert shows a security-group rule added by an unfamiliar IAM role, the reviewer uses CloudWatch to see the alert immediately, then uses CloudTrail Lake to identify all actions by that role over the prior seven days, including access-key creation, policy attachment, and S3 configuration changes. The resulting ticket ties the alert, the investigator’s query results, the infrastructure owner’s explanation, and the corrective action into one record.

Complete these actions during the first week:

• Write the AU.L2-3.3.5 procedure. Keep it short: sources reviewed, review frequency, correlation fields, alert thresholds, ticketing path, reporting contacts, response authority, and evidence location.
• Create a CloudTrail Lake event data store. Start with management events from the in-scope accounts. Set a retention period consistent with the client’s retention policy and expected investigation needs, rather than collecting every possible data event without a cost decision.
• Build two saved Lake queries. One should investigate privileged IAM activity by principal and time range; the other should identify changes to logging, encryption, network exposure, and S3 bucket access controls.
• Test one end-to-end scenario. In a nonproduction account, make an authorized security-group change or create and remove a temporary IAM policy. Confirm that CloudTrail records it, CloudWatch identifies it, the reviewer correlates it with the change record, and a ticket is closed with evidence.
• Bring in one additional source where available. GuardDuty findings, AWS Config changes, or VPC Flow Logs can provide useful corroboration. Do not claim correlation if the procedure never instructs anyone to compare those sources.

For the PCB manufacturer, a practical reportable condition might be: “An IAM role used by the production-support deployment pipeline added inbound SSH access from an unapproved public IP range.” The investigator correlates the CloudTrail AuthorizeSecurityGroupIngress record with the deployment change ticket, the role’s preceding AssumeRole event, and any GuardDuty findings. If no approved change exists, the reviewer removes the rule, preserves the records, notifies the accountable executive, and documents the corrective action.

What have you intentionally deferred, and why is that acceptable?

For a four-hour baseline, intentionally defer a full SIEM migration, 24x7 security operations coverage, automated remediation, and collection of every S3 object-level or Lambda data event. Those capabilities can improve detection and response, but AU.L2-3.3.5 does not prescribe a specific product or require a large-company automation model. Its implementation notes expressly recognize that smaller organizations may use manual review when procedures are well-defined and managed.

You may also defer complex cross-account subscription filters and custom correlation code if CloudTrail delivery to CloudWatch Logs is functioning and the reviewer can use CloudTrail Lake or S3 records to investigate. Do not defer ownership, a review schedule, escalation criteria, or ticketed reporting. Those are the process elements that turn AWS logs into audit evidence.

Likewise, do not confuse deferred sophistication with deferred scope. If CUI is processed in a workload, the audit sources needed to investigate that workload’s access and administration must be included now. A quick-start is acceptable; an unexplained logging gap is not.

When should you upgrade from quick-start to mature audit review?

Upgrade from the quick-start model when the manual reviewer cannot reliably complete reviews within the defined interval, when the client adds multiple AWS accounts or third-party integrations, when CloudWatch query volume becomes difficult to manage, or when incidents repeatedly require reconstruction from several log sources. Those are operational signals that the organization has outgrown a mostly manual CloudTrail Lake and CloudWatch workflow.

A mature model typically centralizes logging in a dedicated security account, uses organization-wide trails, expands CloudTrail Lake queries for recurring investigations, incorporates GuardDuty, AWS Config, VPC Flow Logs, and identity-provider records, and forwards prioritized findings into a SIEM or case-management platform. Automation should enrich tickets with account, principal, IP, asset owner, and change-record context before the analyst begins review.

For a vCISO managing several clients, the key maturity measure is not how many AWS services are enabled; it is whether a reviewer can consistently answer who acted, what changed, where it happened, whether it was authorized, who was informed, and what corrective action closed the issue.

Next step: schedule a four-hour working session with each client’s AWS administrator and system owner to validate the CUI account scope, enable the initial CloudWatch detections, and approve the AU.L2-3.3.5 review-and-escalation procedure.