We know from AWS Best Practice that monitoring, keeping logs and collecting data for analysis is important for many reasons. But as CloudTrail and CloudWatch both do this, how are you meant to know what the differences are?
To understand the differences between AWS CloudTrail and AWS CloudWatch, we’ll review the fundamentals of these two services and how best to use them individually and collectively. Leveraging simple use cases, you integrate CloudTrail to understand who is accessing your AWS services, where CloudWatch will capture AWS sign in events.
On the surface, AWS CloudTrail and AWS CloudWatch seem to provide very similar services because of their monitoring abilities and their insights into account activity and resource use. Even from the AWS definitions, you’d be forgiven for thinking there isn’t much difference:
The Differences between CloudTrail and CloudWatch
The main difference between AWS CloudTrail and AWS CloudWatch is what we like to call the ‘who’ or ‘what’ question:
- AWS CloudTrail is mainly concerned with “Who did what on AWS?” and the API calls to the service or resource.
- AWS CloudWatch is mainly concerned with “What is happening on AWS?” and logging all the events for a particular service or application.
AWS CloudTrail provides much greater visibility into user activity by recording AWS console actions and API calls, including who made the call, from which IP address and when. AWS CloudTrail logs high volume activity events on other services such as AWS Lambda, S3, and EC2, and is turned on from the moment you create an AWS account.
For these services, CloudTrail’s focus is on the related API calls including any creation, modification, and deletion of the settings or instances inside. Additionally, the logs themselves can be sent to an S3 bucket automatically, so that when the time comes to investigate, you have access to all the information.
AWS CloudWatch has quite a few differences to CloudTrail once you drill into it. The service is able to collect logs from far more resources; native logs from AWS services, optional published logs from over 30 AWS services, and any custom logs from other applications or your own on-premise resources.
It also provides users the ability to dig deep into the metrics and pull out only those that are relevant to you. Covering over 70 AWS services, AWS CloudWatch provides a variety of built-in metrics so you can understand how well your resources are running, including latency, errors or any changes in state.
Going deeper into the analysis, AWS CloudWatch provides up to 15 months of metric data and using CloudWatch Metric Math, you’re able to perform calculations across multiple metrics to really understand and fine-tune utilization, performance and the operational health of your infrastructure.
The crux of AWS CloudWatch, however, is its live monitoring abilities. With its own unified dashboard showing graph metrics and logs side-by-side, the root causes of issues can be found more quickly. Using the metrics you have, you’re also able to set CloudWatch Alarms to trigger an action in real-time from simple notification to stopping an under-utilized EC2 instance.
The CloudWatch logs, metrics and alarms work in a clear and simple way to help users find, diagnose and rectify issues for a highly-efficient cloud environment.
CloudTrail or CloudWatch: Which is best for what? And when?
The truth is CloudTrail and CloudWatch are incredibly useful and you should use both.
AWS CloudTrail provides users with the valuable insight of who did what and when. The service is turned on as soon as you create an AWS account because finding audit trails and working backward from issue to root cause, is greatly helped when you have the timestamps and logs of the actions and their owners.
AWS CloudWatch is more of a real-time function that looks after your resources. While it indeed records historical logs and data, it’s value lies in the extensive integration with other AWS services and the on-going live, actionable insights it provides to keep your infrastructure healthy and secure.
AWS CloudWatch and CloudTrail: How do they work together?
AWS CloudWatch is integrated with a whole host of AWS services, including CloudTrail. Using CloudTrail’s ability to log a change to a resource, a CloudWatch Event rule can be created to recognize this and then trigger a Lambda function to open a ticket for investigation.
So, it’s definitely worth using both services!
CloudWatch and CloudTrail Best Practices
Just like any AWS service, these great monitoring tools have some best practices that ensure they’re working well for you. Here are a few of the security practices that can often get overlooked or forgotten for CloudTrail and CloudWatch.
An obvious one to start with because it’s that important! Any configuration changes at a CloudTrail level need to be monitored as any unauthorized modifications could open up your entire infrastructure to high-security threats.
The logs in which CloudTrail logs are kept are monitored as mentioned before, but it’s best practice to keep this checked. Should this bucket be left open to the public, your organization’s reputation is at risk.
The CloudWatch Event bus feature allows accounts to share events with each other, which is incredibly useful for accounts within the same organization or that are associated. However, it’s important to ensure that only friendly AWS accounts are specified on the event bus to avoid sensitive data getting into the wrong hands.
As mentioned above, this share feature is very useful, however, managing permissions is key. The event bus should not be configured to allow access to just anyone to share and send the data within it.
Cloud Conformity provides continuous assurance that your AWS infrastructure is compliant with AWS Best Practice. The Five-Pillars of the Well-Architected Framework are each deeply acknowledged in our Knowledge Base of over 450 rules. Head over to Cloud Conformity today to see for yourself with a free 14-day trial.