--- title: "AWS Security Monitoring, Logging, and Alerting - Cybr" description: "How CloudTrail, CloudWatch, EventBridge, and Athena work together for security monitoring in AWS, plus the AWS logging, aggregation, and visualization services." url: https://cybr.com/cloud-security/aws-security-monitoring-logging-alerting/ --- # AWS Security Monitoring, Logging, and Alerting How CloudTrail, CloudWatch, EventBridge, and Athena work together for security monitoring in AWS, plus the AWS logging, aggregation, and visualization services. Christophe Published February 7, 2024 · Updated October 27, 2026 Good monitoring, logging, and alerting is how you find out something is wrong in your AWS accounts before the bill or a customer tells you. This post explains how the core AWS services fit together, then lists the AWS services for logging, log aggregation, and visualization. ## Build it, or start from something that exists? Before you dedicate a significant amount of time doing this, ask yourself first if it's worth the effort to build from scratch. There are many solutions out there that already exist and that may satisfy your requirements, or that will provide a solid starting point. If that's the case, it may be best to use those pre-existing solutions instead, so that you can focus on your core competency. For example, the [AWS Security Survival Kit (ASSK)](https://github.com/zoph-io/aws-security-survival-kit) provides a great starting point, and we walk through it in our [must-have AWS security monitoring and alerting cheat sheet](https://cybr.com/cloud-security/must-have-aws-security-monitoring-alerting-cheat-sheet/). But, if you really want to build out your own solution or if you want to add on to something like the ASSK because maybe it doesn't monitor or alert for something you want/need, then read on. ## CloudTrail First things first, we need to make sure your CloudTrail settings are in order. CloudTrail is the heart of AWS logging. It gathers activity in your AWS environment, and it saves some (or all) of it, depending on how you have it configured. This enables other AWS or third-party services to then act on these CloudTrail-generated logs. If you're not already familiar with CloudTrail, this free and short course is a must: [Beginner's Guide to AWS CloudTrail for Security - Full Course](https://www.youtube-nocookie.com/embed/1ZKuwyATV3c) Otherwise, here's a quick refresher: - **Event history** keeps the last 90 days of management events in each Region for free, but it's only meant for quick lookups. - **Trails** deliver events to an S3 bucket (and optionally to CloudWatch Logs), so you keep them as long as you need. Create an organization trail that covers every account and every Region, so activity in a Region you don't use doesn't go unnoticed. - **Management events** record control plane activity like creating users or changing security groups. **Data events**, like S3 object reads and Lambda invocations, are off by default because of their volume, so turn them on selectively for your most sensitive resources. - Protect the trail itself: store logs in a dedicated logging account, turn on log file validation, and alert on anyone stopping or deleting the trail. Our [AWS CloudTrail best practices checklist](https://cybr.com/cloud-security/aws-cloudtrail-best-practices-checklist-and-cheat-sheet/) goes deeper. ## CloudWatch If CloudTrail is the heart of logging, then CloudWatch is the part of the brain that can make sense of the data being collected by CloudTrail. To get there, configure your trail to send events to a CloudWatch Logs log group (or ingest them through CloudWatch pipelines), then build metric filters, alarms, and Logs Insights queries on top. CloudTrail has its own query options: Event history covers 90 days of management events for free. CloudTrail Lake, its SQL-based event store, closed to new customers on May 31, 2026, and AWS now points people to CloudWatch for CloudTrail analytics instead. CloudWatch has been around for a long time, and it has *a lot* more functionality out of the box. You can use it to create metrics, set up alarms based on those metrics, create visual dashboards with graphs, and run queries against data sets. On top of that, CloudWatch has a generous free tier so it's great for smaller companies or pilot projects. ## EventBridge Continuing with our anatomy analogies, if CloudTrail is the heart and CloudWatch is part of the brain, then EventBridge is the central nervous system. EventBridge is a large service that you can use for quite a few things, but in the context of this page, it really only reacts to certain events and then either pushes that event to another service (like CloudWatch or SNS), or first *transforms* the event's data and *then* pushes it to another service. This means we can use EventBridge to send out alerts through SNS to an email address or phone number. We can also have it clean up the event information so that it's easier for the recipient to understand what the alert is about. Here's an example. This EventBridge rule matches any console sign-in by the root user, which you almost never want to see: ``` { "detail-type": ["AWS Console Sign In via CloudTrail"], "detail": { "userIdentity": { "type": ["Root"] } } } ``` Point the rule at an SNS topic with an email subscription, and you get an alert every time someone signs in as root. Sign-in events are delivered to the Region of the sign-in endpoint that was used, which for the root user is usually US East (N. Virginia), so create the rule there and in any other Region your users sign in through. ## Athena While the above solutions alone can give you a great starting point for monitoring, logging, and alerting in AWS, you can take it a step further by using a service like Athena which can help you with incident response. Athena lets you query CloudTrail logs stored in S3 with SQL, which is what AWS's own incident response playbooks rely on. See our [incident response playbook for exposed IAM credentials](https://cybr.com/cloud-security/my-aws-iam-access-keys-were-exposed-what-should-i-do-cheat-sheet/) for an example. ## AWS logging services The primary security logging services in AWS are: - [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) - [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) - [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) - [Amazon Route 53 Resolver query logs](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html) ## Types of logs There are generally two broad categories of logging: - Control plane events (CloudTrail calls these management events) - Service logs (CloudTrail data events, like S3 object reads, plus the logs that services and applications write themselves) Control plane events are events that happen at the management layer, meaning the layer responsible for managing and controlling cloud resources. This could be creating, modifying, or deleting a resource. For example, if someone modifies a security group's rules, that would be considered a control plane event. Service logs, instead, are more specific logs that are generated by individual services or applications. For example, if you have AWS Lambda functions executing code and writing logs, those would be considered service logs. If someone goes in and creates a new Lambda function, then that would be a control plane event. ## Log aggregators The primary security logging aggregators in AWS are: - [Amazon S3](https://aws.amazon.com/s3/) - [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) - [Amazon Security Lake](https://aws.amazon.com/security-lake/) - [Amazon Data Firehose](https://aws.amazon.com/firehose/) (formerly Kinesis Data Firehose) ## Query and analysis - [Amazon Athena](https://aws.amazon.com/athena/) - SQL queries over logs stored in S3 - [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) - Queries over logs in CloudWatch ## Visualization The primary security visualization services in AWS: - [Amazon OpenSearch](https://aws.amazon.com/opensearch-service/) - [Amazon Quick Sight](https://aws.amazon.com/quick/quicksight/) (formerly QuickSight) - [Amazon Managed Grafana](https://aws.amazon.com/grafana/) - [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) (offers custom dashboards) ## Next steps - [AWS CloudTrail events to monitor and alert on](https://cybr.com/cloud-security/aws-cloudtrail-events-to-monitor/) - [Open-source AWS monitoring tools](https://cybr.com/cloud-security/open-source-aws-security-tools/#monitoring) - [AWS threat detection](https://cybr.com/cloud-security/aws-threat-detection/) ## Filed under - [Cloud Security](https://cybr.com/cloud-security/) - [Blue Team](https://cybr.com/blue-team/) - [AWS](https://cybr.com/tag/aws/) - [AWS Security](https://cybr.com/tag/aws-security/) - [Monitoring & Logging](https://cybr.com/tag/monitoring-logging/) - [CloudTrail](https://cybr.com/tag/cloudtrail/) ## Comments Loading comments… Recommended resources [![Explore the AWS Certified Security Specialty course](https://media.cybr.com/2023/12/cybr-aws-security-specialty-banner-768x432.jpg)](https://cybr.com/courses/aws-certified-security-specialty-course/) ## Build practical AWS security skills Start with the core services, then prepare for the AWS Certified Security Specialty exam with guided lessons and hands-on practice. [Introduction to AWS Security](https://cybr.com/courses/introduction-to-aws-security/) [Security Specialty course](https://cybr.com/courses/aws-certified-security-specialty-course/)