AWS CloudTrail, CloudWatch, and Config Compared

CloudTrail is a services which provides governance, compliance, and auditing of your AWS account by logging and monitoring account activities.

 

What’s the difference between CloudWatch and CloudTrail

 

AWS CloudWatch

 

CloudWatch is a monitoring tool used for real-time monitoring of AWS resources and applications. It provides a monitoring service that analyzes the performance of the system.  

 

CloudWatch can be used to detect irregular behaviour in AWS environments. It monitors various AWS resources including EC2, RDS,  S3, Elastic Load Balancer, etc. It can also be used with CloudWatch Alarms. 

 

2. AWS CloudTrail

 

CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. It continuously logs and monitors the activities and actions across your AWS account. It provides the event history of your AWS account including data about who is accessing your system.  Remediation actions can also be taken by CloudTrail.      

 

While CloudWatch reports on the activity and health and performance of your AWS services and resources,  CloudTrail by contrast is a log of all the actions that have taken place inside your AWS environment.

 

CloudTrail can record API activity in your AWS account and reports an event within 15 minutes of the API call.

 

 

It provides auditing services for AWS accounts. In CloudTrail, Logs are saved in an S3 bucket.

 

However, you can receive notifications of specific CloudTrail events immediately by sending them via the CloudWatch Event Bus.

 

While CloudTrail only writes to your S3 bucket once every five minutes, it sends events to the CloudWatch Event bus in near real-time as these API calls are observed.

 

CloudWatch monitors performance. For example, tracking metrics of an EC2 instance or keeping track of your Amazon DynamoDB performance or seeing how Amazon S3 is performing. CloudWatch allows you to collect default metrics for over 70 AWS services.

 

It also has a “Custom Metrics” feature that enables you to collect a metric that is specifically important to your system. For example, to measure how people are using your application.

 

 

AWS CloudTrail

 

AWS CloudTrail is principally used for auditing API activity, tracking who did what and when, and securely logging this information to Amazon S3 for later analysis.

 

Thus CloudTrail keeps track of what is done in your AWS account, when, and by whom. For example, with CloudTrail you can view, search, and download the latest activity in your AWS account to check it there are any abnormal or unusual actions and if so, by whom. This type of reporting is called auditing and it is the core service of CloudTrail.

 

 

CloudTrail tracks data events and management events:

 

Data events are object-level API requests made to your resources. For example, when an item is created or deleted in a DynamoDB table.

 

Management events log changes (mostly creation or deletion changes) to your environment, such as the creation or deletion of the entire DynamoDB itself.

 

CloudTrail tracks which applications or persons took these actions and stores the details in logfiles. These logfiles are encrypted and stored in S3.

 

 

Note that CloudWatch has CloudWatch Alarms which you can configure and metric data is retained for 15 months. CloudTrail on the other hand has no native alarms. However, you can configure CloudWatch Alarms for CloudTrail, but you have to store logs in S3.

 

In a nutshell:

 

CloudWatch is for performance. Think of CloudWatch as monitoring application metrics.

CloudTrail is for auditing. Think of CloudTrail as tracking API activity within an account.

 

 

 

 

AWS Config vs. CloudTrail

 

In the configuration and monitoring category AWS, there are two major AWS monitoring tools that are similar and are easy to confuse. They are AWS Config and AWS CloudTrail.

 

Config and CloudTrail are different tools with different purposes.

 

What is AWS Config?

 

AWS Config is a service that lets you set configuration rules for your AWS resources to comply with. It then tracks whether the resources comply with those rules.

 

Whenever a resource has changed, Config records the change in a configuration history in an S3 bucket. It stores a snapshot of the system at a regular period of time set by you. It also has a dashboard that presents an overview of your resources and their configurations.

 

 

What is AWS CloudTrail?

 

CloudTrail is a logging service that records all API calls made to any AWS service. It records the details of the API call such as which user or application made the call, the time and date it happened and the IP address it originated from.

 

There is also another AWS logging service called CloudWatch Logs, but unlike CloudWatch Logs which reports application logs, CloudTrail reports on how AWS services are being used in your environment.

 

Where CloudTrail and Config are Similar

 

Config and CloudTrail have a number of things in common.

 

Both are monitoring tools for your AWS resources. Both track changes and store a history of what happened to your resources in the past. Both are used for compliance and governance, auditing and security policies.

 

 

If you notice something unusual or going wrong with your AWS resources, then chances are you’ll see it reported in both CloudTrail and Config.

 

Where CloudTrail and Config are Different

 

 

Note that AWS Config Rules is not a cheap service. There is no free tier, you pay a fee per config item per region.

 

Though both often report on the same events, their approach is different. Config reports on what has changed in the configuration, whereas CloudTrail reports on who made the change, and when, and from which IP address.

 

Config reports on the configuration of your AWS resources and creates detailed snapshots of how your resources have changed.

 

CloudTrail focuses on the events or API calls behind those changes, focusing on users, applications, and activities performed in your environment.

 

Where CloudTrail and Config work together

 

By taking a different approach to the same events, CloudTrail and Config make a good combination. Config is a great starting point for ascertaining what has happened to your AWS resources, while CloudTrail can give you more information from your CloudTrail logs.

 

Config watches and reports on instances of rules for your resources being violated. It doesn’t actually allow you to make changes to these resources from its own console.

 

By contrast, CloudTrail gives you more control by integrating with CloudWatch Events to allow you to set automated rule-based responses to any event affecting your resources.

 

In the case of security breaches, if multiple changes have been made by an attacker in a short period of time, Config might not report this in detail.

 

Config stores the most recent and important changes to resources but disregards smaller and more frequent changes.

CloudTrail by contrast records every single change in its logs. It also has an integrity validation feature that checks if the intruder or attacker manipulated the API logs to cover their activity track.

 

 

Should You Use AWS Config or CloudTrail for Security?

 

 

Both Config and CloudTrail have a role to play together. Config records and notifies about changes in your environment. CloudTrail helps you find out who made the change, from where, and when.

 

A good way to think of it is that AWS Config will tell you what your resource state is now or what it was at a specific point in the past whereas CloudTrail will tell you when specific events in the form of API calls have taken place.

 

So you ought to use both. Config Rules triggers on a change in the status of your system, but it will often only give you an update on the state of the system itself.

 

CloudTrail meanwhile provides you with a log of every event which details everything that has taken place and when and by whom. This helps identify all the causes that may have led to the security problem in the first place.

 

 

Remember also that AWS Config Rules does not prevent actions from happening – it is not a “deny”.

 

But – you can do “remediations” of resources that are identified as non-compliant. This can be done for example via SSM Automation Documents. Config then triggers an auto-remediation action that you define.

 

Notifications:

 

you can use EventBridge to receive notifications from Config, from there you can also send the notifications onto eg Lambda functions, SNS or SQS.