CloudTrail records thousands of events every day, but security teams rarely notice a critical action until they actively investigate an incident.
What happens if someone disables logging?
What happens if an AI model is invoked unexpectedly?
What happens if a high risk administrative action occurs outside normal business hours?
Over the last two days, I built a fully serverless monitoring pipeline that detects high risk AWS events and generates near real time alerts using CloudTrail, Amazon S3, AWS Lambda, and Amazon SNS. This project was not just about connecting services. It was about building a reliable detection pipeline capable of processing real CloudTrail data, handling unexpected log formats, and generating actionable alerts automatically.
Architecture Overview
The solution follows a clean serverless pattern:
CloudTrail → Amazon S3 → AWS Lambda → Amazon SNS → Email Notification
CloudTrail continuously records management and data events. When a new log file lands in S3, it triggers a Lambda function. The function parses the events, evaluates them against detection rules, and sends alerts via SNS when a high risk action is detected.
Example Detection Flow
User invokes Amazon Bedrock model
↓
CloudTrail records InvokeModel event
↓
Log delivered to Amazon S3
↓
Lambda parses the event
↓
Detection rule matches
↓
SNS sends security alert
Security Use Cases
The pipeline currently monitors high impact events such as:
- DeleteTrail
- StopLogging
- UpdateTrail
- CreateTrail
- InvokeModel (Amazon Bedrock)
These events are especially critical because they can reduce visibility, change auditing configurations, or indicate unauthorized usage of AI services.
Event Processing Logic
import json
import gzip
import boto3
# Handle varying CloudTrail structures
records = log_data.get('Records', []) if isinstance(log_data, dict) else [log_data]
Engineering Challenges
-Incorrect Log Compression Format: I encountered repeated UnicodeDecodeError exceptions. The root cause was that test logs were compressed with 7z instead of gzip. CloudTrail processing expects gzip.
-Lambda Console Syntax Errors: Editing Python code directly in the browser led to Runtime.UserCodeSyntaxError due to indentation issues. Lesson: Develop locally and deploy via ZIP or IaC.
-Dynamic JSON Structures: CloudTrail log formats vary. The solution was a defensive parser that gracefully handles different structures.
Future Improvements
- EventBridge integration for advanced routing
- Security Hub findings generation
- Slack or Teams notifications
- Automated remediation workflows
- Risk scoring for detected events
- Additional Bedrock specific detections
Conclusion
Cloud security monitoring is often presented as a tooling problem. In reality, it is an engineering problem. CloudTrail, Lambda, SNS, and Bedrock were relatively easy to connect. Building a pipeline that could reliably process real world data, survive unexpected failures, and generate actionable alerts was the actual challenge.
As organizations continue adopting AI services, visibility into cloud activity becomes increasingly important. Automated monitoring pipelines like this provide a practical foundation for detecting high risk events before they become security incidents.
As someone transitioning from enterprise infrastructure and support into cloud security, projects like this provide valuable hands on experience with AWS monitoring, automation, and security operations.
References
-AWS Lambda Developer Guide:
https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html
-AWS CloudTrail Event Reference:
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html
-Amazon Bedrock Documentation: https://docs.aws.amazon.com/bedrock
-AWS Well Architected Framework:
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html
Top comments (0)