This post explains how to implement cloud audit log alerts in AWS and Azure to meet AU.L2-3.3.4 (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2) requirements, with step-by-step guidance, example alert rules and queries, small-business scenarios, and operational best practices to keep evidence and responders timely and effective.
What AU.L2-3.3.4 requires (context for Compliance Framework / Practice)
AU.L2-3.3.4 maps to the Audit and Accountability family in NIST SP 800-171 and CMMC. At a practical level it requires that auditable events are recorded and that your organization has monitoring/alerting so suspicious or important events generate timely notifications to appropriate personnel. For organizations using cloud providers, that means enabling platform audit events (console/API activity, admin changes, data access where applicable), centralizing them, creating alerting rules for critical events, and ensuring alerts are delivered to a monitored channel consistent with your incident response processes.
AWS implementation — enable, centralize, alert
Begin by ensuring CloudTrail is enabled organization-wide: create an Organization Trail that logs Management Events (Read/Write), and enable Data Events for critical S3 buckets and Lambda functions where needed. Deliver CloudTrail logs to a centralized S3 bucket in a logging account. Protect that bucket with a restrictive bucket policy, enable S3 Object Lock (WORM) or versioning and MFA delete where available, and enable server-side encryption (SSE-KMS).
Practical alerting details for AWS
Use CloudWatch Logs + EventBridge (formerly CloudWatch Events) to create alert rules. Two common approaches: (1) CloudWatch Logs metric filters for specific CloudTrail log patterns (for older workflows), and (2) EventBridge rules that match CloudTrail event fields and forward to SNS, SQS, Lambda, or a ticketing webhook. Example targets to alert on immediately: CreateUser, DeleteTrail, UpdateTrail, ConsoleLogin failures/success from unusual geolocations, IAM policy changes, and S3 DeleteObject or PutObject on CUI-designated buckets. For example, an EventBridge pattern can match CloudTrail events where detail.eventName equals "ConsoleLogin" or IAM write operations; route that to an SNS topic subscribed by your security on-call email and a Lambda that enriches the event with GeoIP and user agent details.
Azure implementation — diagnostic settings, Log Analytics, and alerts
In Azure, enable Activity Logs (subscription-level) and resource Diagnostic Settings to send platform and resource logs to a central Log Analytics workspace, an Event Hub, or a secured Storage Account. Ensure Azure AD sign-in and audit logs are exported to the same or an accessible location; for organizations with Azure AD P1/P2, route these into Log Analytics and enable built-in analytics rules. Protect storage with Role-Based Access Control (RBAC), soft-delete and immutability where available.
Practical alerting details for Azure
Create Log Analytics queries and Scheduled Alerts or Metrics alerts. Example Kusto query to detect role changes or destructive operations: AzureActivity | where OperationNameValue has_any ("Delete", "Delete Role Assignment", "Delete KeyVault") and TimeGenerated > ago(1h). Use that query to create an alert rule and attach an Action Group that calls an Azure Logic App (for enrichment and automated containment) and notifies the security distribution list. For sign-in anomalies, use the AzureAD SignInLogs: SignInLogs | where ResultType != 0 and TimeGenerated > ago(1h) to surface failed sign-ins and feed them to an Action Group for escalation. Where available, integrate with Microsoft Sentinel for detection rules and playbooks.
Real-world small-business scenarios
Scenario A (small MSP with 10 staff): Create a single logging AWS account. Enable organization-wide CloudTrail with Data Events on the single S3 bucket that stores customer CUI; create an EventBridge rule to alert on DeleteBucket and PutBucketAcl. Route EventBridge to an SNS topic that emails the owner and opens a ticket via an inexpensive webhook to a ticketing system (e.g., Freshservice). Retention: 1 year on hot S3, longer on Glacier for archive.
Scenario B (single-Azure subscription small engineering firm): Turn on Diagnostic Settings for Key Vaults, Storage Accounts, and App Service to a Log Analytics workspace. Create Log Alert rules for suspicious role assignments and for any Key Vault deletion/soft-delete operations. Use an Action Group that sends SMS and triggers a Logic App which disables the implicated service principal until a human reviews; document the runbook so auditors can see the detection-to-response chain.
Compliance tips and best practices
Map each alert to a control objective and incident response playbook and keep that mapping in your compliance evidence. Tune alerts to reduce noise—start broad, then add filters (source IP ranges, trusted service principals) to lower false positives. Maintain alert proof-of-delivery (SNS delivery logs, Action Group invocation logs) and periodically test the entire path with tabletop exercises and synthetic events (e.g., perform a controlled ConsoleLogin failure or simulate a role assignment change). Encrypt audit logs at rest and in transit; use centralized KMS/Key Vault keys with restricted access and logging on key usage. Retain logs per your policy (often 1+ years for controlled unclassified information) and provide immutable backups or records to meet evidence requirements.
Risks of not implementing timely audit log alerts
Without alerting you risk delayed detection of account compromise, unauthorized data access or deletion, and privilege escalation. That leads to longer dwell time for attackers, incomplete forensic timelines, and likely failure of CMMC/NIST audits—potentially losing contracts that require compliance. Operationally, lack of alerts also increases mean time to detection (MTTD) and resolution (MTTR), which can translate to greater data exposure and legal/reporting consequences.
Summary: To satisfy AU.L2-3.3.4 you must enable platform audit logging, centralize and protect those logs, implement tuned alerting rules that notify a monitored channel, and document the detection-to-remediation workflow. On AWS use Organization Trails, EventBridge/CloudWatch + SNS/Lambda and protected S3 storage; on Azure use Activity Logs, Diagnostic Settings to Log Analytics, and Alert Rules + Action Groups (or Sentinel). For small businesses, prioritize a minimal central logging account/workspace, a short list of high-value alerts (account creation/deletion, privilege changes, data deletion), and a tested notification/runbook — then expand and automate as you mature.
