CloudTrail vs CloudWatch

Think of CloudTrail as an audit log and CloudWatch as a service to write and explore logs and metrics to. Indeed CloudTrail can be configured to write the audit log to CloudWatch.

CloudWatch has a number of features that supposedly help you make sense of all the information. It does however not give you a human readable CloudTrail like Narratrail does.

It seems a bit strange that CloudTrail is its own service. If AWS could do it all over I would think each service would post their events to EventBridge and CloudTrail or CloudWatch would subscribe to audit events and log them down as they see fit.

If you create any CloudTrail at all then EventBridge will be able to catch the events sent to it and you can distribute them via any of EventBridge's many target types, like CloudWatch or Lambda.

Heads up

If you configure EventBridge to write CloudTrail events to CloudWatch it will create a new LogStream for each event, which will generate a new CloudTrail event and create a feedback loop. You need to exclude the CreateLogStream event from the rule to avoid this.

What does Narratrail use

Narratrail does not use this CloudTrail + EventBridge feature to trigger a Lambda on each event because it’s per region. There are ways around this of course but for now it’s easier to go with S3 and SNS, old school style.

Get started with Narratrail in minutes via AWS Marketplace

Heads up

If you want to create a Lambda target on a EventBridge Rule via CloudFormation it will happily do so without warning you that you need to add a Lambda Permission for the rule to invoke your lambda. If you create the rule via the console it will create the permission for you.

                        
EventBridgePermission:
Type: AWS::Lambda::Permission
Properties:
    FunctionName: !Ref Lambda
    Action: lambda:InvokeFunction
    Principal: events.amazonaws.com
    SourceArn: !GetAtt EventBusRule.Arn