Most AWS environments have AWS CloudTrail enabled, but very few teams actually detect critical events in real time. The recent announcement from AWS Re-invent simplified CloudWatch integration for CloudTrail.
So instead of just recording history, you can now react to every sensitive API call within seconds by streaming CloudTrail events directly into CloudWatch Logs for alerts, dashboards, and automation.
In this article, I will try to share some interesting insights regarding this topic by answering these following questions
Why is Cloudtrail alone not enough for monitoring ?
CloudTrail is excellent at answering “who did what, where, and when” for AWS API calls. But its main purpose is auditing, not operational monitoring.
It’s true that the CloudTrail console is optimized for compliance investigations but not continuous detection. Why ? because it doesn't provide native real-time alerting, metrics, or rich dashboards. This is exactly why you still need another service for that and that’s what CloudWatch Logs is designed for.
How was cloudwatch monitoring done before the announcement ?
Before this update, achieving observability of CloudTrail events in CloudWatch required a multi-step configuration.
Firstly, you had to create a Trail and explicitly configure it to push events to an S3 bucket primary and CloudWatch Logs log group optionally using an IAM role
Secondly, you had to explicitly create an IAM Role with a trust policy allowing the cloudtrail principal to assume it, and the required permission policies.
In addition, enabling this across an Organization often mean complex StackSets or Control Tower customizations to ensure every new account had this Trail-to-CloudWatch configuration.
How can you achieve it now after the update ?
Now with the new update, you can now configure everything directly from the Cloudwatch console.
You no longer need to create or manage a CloudTrail "Trail" object just to get logs into CloudWatch. The integration uses Service-Linked Channels (SLCs), which acts as background pipes that AWS services use to communicate securely.
One of the advantages of using Service-Linked Channels and Service-Linked Roles, the IAM permissions are managed automatically by AWS. You do not need to manually create and maintain an IAM role for this ingestion pipeline.
After these Re-invent updates, The workflow is now consistent with other AWS native logs such as VPC, EKS … providing a simplified way for configuring all telemetry ingestion in one place.
What are the key benefits of cloudtrail monitoring ?
Monitoring CloudTrail events in CloudWatch Logs can have several benefits:
Real-time alerts and automation
You can turn log patterns into metrics and then create CloudWatch alarms that notify via SNS, PagerDuty, etc., or trigger remediation via Lambda.
Single pane for all logs
CloudWatch Logs can centralize app logs, OS logs, VPC Flow Logs, and CloudTrail in one place, with a consistent query language and dashboards. This makes correlation like “API call happened here, app error happened there” much easier. More details are available in this announcement
Powerful querying and visualization
CloudWatch Logs Insights lets you run ad‑hoc queries, aggregate, group, and visualize CloudTrail events alongside other logs. This can be done in the cloudwatch console or using tools such as AWS managed Grafana with cloudwatch plugin.
A real-world Use case
Let suppose that you want to get alerted when some critical IAM changes happen such as CreateAccessKey. CloudTrail records this as a management event with eventSource = "iam.amazonaws.com" and eventName = "CreateAccessKey".
After configuring CloudTrail events to be delivered to a CloudWatch Logs log group using the new cloudwatch console -> Log management -> Data source -> Select Cloudtrail, You need to create a metric filter using this filter pattern:
{ ($.eventSource = "iam.amazonaws.com") && ($.eventName = "CreateAccessKey") }
This matches any CloudTrail event where IAM’s CreateAccessKey API was called.
Now every time CreateAccessKey appears in the logs, CloudWatch increments your metric by 1. Now the only thing left to do is to configure you alarm so that If at least one access key was created in the last 5 minutes as an example, go into ALARM state … and sends a notification (and/or executes remediation if needed)
Do I still need to use trails or Cloudtrail Lake ?
The answer is Yes. Using CloudTrail Lake or Trails with S3 will always be useful for long-term audit, compliance and data storage.
Trails are a foundational system of records with continuous capturing management events and writing them to hardened S3 buckets with long retention. Organization trails centralize activity from all accounts and regions so you can prove to auditors that logging is consistent across the entire organization.
On the other side, CloudTrail Lake builds on that stream as an audit analytics warehouse, storing events in dedicated event data stores with multi‑year, policy‑driven retention and letting you run SQL queries that are more efficient than searching raw S3 logs.
What’s next ?
By streaming events into CloudWatch Logs using the new simplified integration, you unlock real-time detection of threats like failed logins, IAM escalations, and access key creations, turning passive audit logs into active defenses.
You can start and implement this today in your AWS account. From a FinOps perspective, there is no difference as you will still be charged for both CloudTrail event delivery charges and CloudWatch Logs ingestion fees based on custom logs pricing.
Top comments (0)