AWS CloudTrail vs AWS CloudWatch

Monitoring and observability play a critical role in the AWS environment. Monitoring with a great alert system makes operation life simple. Amazon Web Service(AWS) offers plethora services ranging from GuardDuty, Security Hub and many more.

With all these services there are two essential products CloudWatch and CloudTrail that function a key role in day to day operation.

In this blog post, we will cover the differences, but first we will start with an introduction.

*AWS CloudWatch AWS CloudTrail
Description CoudTrail functions as an audit service where it records API calls. CloudWatch collects data and offers monitoring service and log collection.
Use case Helpful to find out details about an API activity such as IP address, user, date time and resource details Operational performance, log storage and analysis, Can help you find out the performance issue of a service.
Retention Logs are retained for 90 days, longer retention days can be configured. Varies based on the settings. By default logs are kept indefinitely. Retention days can be between 10 years and one day.

What is AWS CloudWatch?

AWS CloudWatch collects data from your AWS account ranging from metrics,events or logs and can notify you when a certain activity happens.
The metrics can be for example CPU usage, API Gateway status code and more more.
It provides insights about each and every service. With CloudWatch you will have a clear understanding of how well services are operating.

With the help of CloudWatch we can:

  • Collect
  • Monitor
  • Act

Collect

This feature lets Amazon CloudWatch to ingest data from various sources.A key unique aspect is the integration with AWS Services. If a service is not supported by it, we can put data through the API.


Monitor

Once, data is collected. We can monitor the data. This can be done either through searching through the data captured or creating dashboards.


Act

The act functionality lets CloudWatch act as a response on an event. This can be triggering auto-scaling, notifying users by email(SNS)


CloudWatch key components

Metrics

Metrics represent data key points from services. Each AWS service has its own unique list of metrics. For example API Gateway has the following metrics:

  • Integration Latency
  • 5xx,4xx status code
  • Latency
  • Data Processed
  • Count [total number API requests]

There might be situations in which you want faster data update. As a result, we are offered with two types of types of monitoring options:

  • Basic: free, data is updated every 5 minutes.
  • Detail: chargeable, data is updated every 1 minute.

CloudWatch Logs

Logs are critical to every application. With CloudWatch logs, we are offered a fully managed log solution that not only allows us to save logs but search functionalities. With Insights we can search and analyse over the data stored and receive the results in seconds. Both of these are managed by AWS in terms of scaling and redundancy. As an end user our primary function is simply to write and search.


CloudWatch Alarms

When a certain event counts, as an end user we either like to be notified or a certain action to take place. This is where CloudWatch alarms come in place. The alarms react based upon the metric data. They can either invoke a certain action or publish to SNS a topic.

There are two types of alarms:

  • Metric alarm: this alarm keeps an eye on a single metric.
  • Composite alarm: this alarm reacts based upon multiple alarm states.
Example
  • We can have an alarm configured when the 5xx of API Gateway goes above 10 in 5 minutes.
  • Alarm when the root user login has been detected.

CloudWatch Dashboards

While operating multiple accounts in a typical landing zone, having a dashboard makes day to day job easy. CloudWatch dashboards support cross account integration, widgets and can group data from multiple sources in a single window.

What is AWS CloudTrail

Any operations that occur in AWS, from a simple bucket creation to a modification of an IAM policy requires auditing. We can either invest resources in creating an auditing software or use an AWS service. This is where CloudTrail comes in place, a fully managed auditing service.

With the help of CloudTrail we can find out the following information as an example:

  • IP address of the user or the source
  • date/time when the event occurred
  • The request details for example, EC2 server name, security group configuration
  • Who created the request? This is helpful as we can identify the user or role which is responsible for the API call.

Example of an event, where the root user logged in

In the below example, we can come to know the IP address, eventName and datetime

 {
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "Root",
        "principalId": "xxx21111409",
        "arn": "arn:aws:iam::xxx21111409:root",
        "accountId": "xxx21111409",
        "accessKeyId": ""
    },
    "eventTime": "2023-10-02T09:34:06Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "ConsoleLogin",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "89.186.162.238",
    "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36",
    "requestParameters": null,
    "responseElements": {
        "ConsoleLogin": "Success"
    },
    "additionalEventData": {
        "LoginTo": "https://console.aws.amazon.com/console/home?hashArgs=%23&isauthcode=true&state=hashArgsFromTB_eu-north-1_b9c2672f5793933b",
        "MobileVersion": "No",
        "MFAIdentifier": "arn:aws:iam::xxx21111409:mfa/aax+prod",
        "MFAUsed": "Yes"
    },
    "eventID": "0a7a4f88-bc6c-4824-9a84-1f887d508609",
    "readOnly": false,
    "eventType": "AwsConsoleSignIn",
    "managementEvent": true,
    "recipientAccountId": "xxx21111409",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.3",
        "cipherSuite": "TLS_AES_128_GCM_SHA256",
        "clientProvidedHostHeader": "signin.aws.amazon.com"
    }
}

It maintains a record of every single activity happening in an AWS account and integrates with all AWS services, can track user changes or service changes. This makes it a very useful tool for auditing. With few setting changes we write the logs into S3 or CloudWatch logs where we can invoke a lambda action or more complex controls. This is extremely useful for CIS benchmark.

CloudTrail is a free service offered by AWS which means we don’t need to pay for it. By default when you create an AWS account, a CloudTrail is created and lets you search the 90 days of log data. If you require additional configuration for example writing to S3,CloudWatch log it falls under AWS pricing scheme.


Getting to know AWS CloudTrail

While being a fully managed service, there are few key things to familiarise

There are three different types of event types:

  • Management Events: This type of event covers operation activities such as VPC creation/ EC2 creation or any other resource interaction.
  • Insight Events: Unusual account activities. This works by CloudTrail studying your normal API pattern and API error rates, if at a certain point there is a huge spike in API call, insights will flag it. For example: usually we make 20 calls to SSM but suddenly it has gone to 1000.
  • Data events: This type of data is not stored by default and there is an additional cost. They display actions performed within a resource. For example: When data is updated on DynamoDB, S3 etc.

How to create alarms for certain CloudTrail events?

Sinc, it acts as an audit service, we might need to create alarms for certain activites. There few use cases where we like to be recommend.

  • Root Account Activity
  • Transit Gateway changes
  • VPC changes on production workload
  • Security group changes
  • Failed ConsoleLogin

While, it is possible to create the alarms, but if you are look for a fully automated solution, you might want to try our be-spoke alerting system.

Related Posts