AWS CloudTrail Reviews

I am working on a project where we are using Amazon infrastructure service with Lambda. We are using multiple services on Amazon. I'm working in a company where we are using AWS CloudTrail. We are using Amazon EC2 instances as infrastructure service, and we are using S3 bucket, Lambda function, step function. We have moved to DynamoDB and I'm using DynamoDB and a few databases.

For monitoring, we use Dynatrace. Dynatrace is connected with AWS CloudTrail, so AWS CloudTrail sends the notifications via SNS to Dynatrace. We get notifications, and Dynatrace will send notifications.

AWS CloudTrail is a log function that will store all logs easily for whatever services we are using on Amazon. All logs will be stored in AWS CloudTrail for 15 years, as we have the service purchased for that duration. The logs will be stored in AWS CloudTrail via S3 bucket.

In AWS CloudTrail, we have enabled CPU, disk, and RAM monitoring. These are three services we are monitoring from AWS CloudTrail. AWS CloudTrail will monitor and produce graphs. We have separate L1 teams for monitoring; they will monitor and share the information. Also, Dynatrace will receive the information, and if any service goes beyond the threshold limit, AWS CloudTrail will create an alert.

CloudTrail and CloudWatch are sister services. Both should be preconfigured internally. We only watch the dashboards because we can't go and watch each service; there are multiple servers running and multiple services configured, so we watch only the dashboard graphs. If any graph goes beyond the normal limit, we take action.

We watch the graph. If any of the graphs show abnormal activity, then immediately we dig into AWS CloudWatch and AWS CloudTrail. We check the reason by verifying the logs. The graph will show you the time period, so we go into AWS CloudWatch, filter the logs for that particular time period, and from there, we identify the cause of the issue, and then we troubleshoot.

API is a main element that allows us to connect AWS CloudWatch to AWS CloudTrail and AWS CloudTrail to Dynatrace. That connection is done via API. By API, everything is integrated. The integration part is managed by the API, transferring information from one service to another. We are not working on the API; the configuration team, the cloud operations team, they take care of it.

AWS CloudTrail, as the name suggests, is used for backtracking AWS console activities or finding unauthorized access, deletion, creation, or anything happening in AWS. It is used for historical tracking purposes of AWS console activities.

It is very useful when working in a large team where you need visibility into team member activities. When everyone has admin access, there will be numerous creations and deletions of AWS resources. If permissions are attached to a role used by an organization or third-party service such as Jenkins, that role should have all necessary permissions to execute Jenkins jobs daily. AWS CloudTrail can track if any policy is detached or deleted, or if a role is removed from a user group. We can filter activities by date, day, month or year.

In my recent company, I was responsible for cleaning up users after they left the company. I accidentally removed a user from user groups which stopped the company's Jenkins deployments. Through AWS CloudTrail, they traced it back to my IAM username. This served as a learning experience and demonstrated a useful case for AWS CloudTrail.

We did not utilize AWS CloudTrail's integration with CloudWatch for real-time observability. We used it for backtracking since access was already least privileged for people. With modularized access, individuals take ownership of their actions.

We make use of AWS CloudTrail's feature to send log files to an Amazon S3 bucket for long-term storage and analysis. Most organizations perform this activity because CloudWatch is integral to the AWS console where logs are generated. Third-party log generations can also be integrated. For services such as Lambda, CloudWatch integration is essential for troubleshooting errors. CloudWatch logs can be dumped to S3 for review or audit purposes. S3 features Glacier for long-term, cost-effective storage of large amounts of data.

For Lambda, we implemented Python code that would invoke AWS CloudTrail upon any AWS console action, feeding logs into CloudWatch and subsequently to services such as S3. We also had the option to receive notifications for selected service creations or destructions via email.

AWS CloudTrail can be scaled to monitor all services and provide notifications for any changes. Beyond simple CloudWatch logs, it can send targeted notifications via email or Teams integration when CRUD operations affect specific services by IAM users.

The service maintains a comprehensive trail of all AWS activities. If an account is seven years old, it potentially contains all historical data from that period. This proves invaluable during audits requiring data from several years back.

AWS CloudTrail is currently underutilized and has potential for many more use cases.

I work in a security domain, and my primary use case for AWS CloudTrail is to generate logs that track all the activities in AWS. These logs are used to identify and investigate incidents related to the instances and containers within AWS.

AWS CloudTrail provides detailed logs of every event linked to movements within AWS. This allows for easy tracking of activities. It's beneficial to have a clear overview, especially for identifying incidents. However, it can sometimes be noisy, with an overwhelming amount of information. Still, if I know what I am looking for, I can easily query the necessary information from the logs.

I have worked in different phases and parts. I have been the consumer myself, a service provider, a consultant, and a trainer for CloudTrail.

The management events and CloudTrail Insights are valuable. The management events are useful for monitoring the compliance and standards when creating any service like an EC2 instance or S3 bucket. CloudTrail Insights provides an analysis of all events and actions taken.

I use AWS CloudTrail to monitor the API calls to the service and to see who has been connected. Whenever somebody logs in, I utilize CloudTrail to ensure that I receive notifications through SNS for our notification service.

AWS CloudTrail has significantly improved the monitoring of API calls within our network, allowing us to keep track of logins and access to our services. It is a straightforward solution from AWS that helps integrate well with any service we choose, thereby improving our workflow.

We use AWS CloudTrail as a complete data centre. It is working on a cloud. We have different operating systems. We have completely deployed in the cloud.

There are requirement variations depending on the organisation and their specific needs. There are fundamental concepts related to deployment, AWS, and computing that must be understood. Support is available based on the individual's knowledge of computing and their ability to handle cloud technologies.

CloudTrail is available 24/7. There is no downtime and administration is very simple. The single window console has so many features.

Some use cases with AWS CloudTrail include monitoring services running within your AWS environment, ensuring they function as expected. With AWS CloudTrail enabled, you can track who is logging in and out, access logs, and perform accounting and auditing of services and networks to monitor user activity and access to information.

In one specific scenario, we encountered a situation where a terminated employee still had access to our environment without our knowledge. With AWS CloudTrail, we could track and monitor the employees' activities, revealing that they were downloading specific files from our customer's environment. Without it enabled, we wouldn't have been aware of this.

We can use it to trigger Lambda functions for authorization and terminate unauthorized access. Integrating it with Amazon Simple Notification Service also allows us to receive alerts when specific metrics are reached, helping us take prompt action when needed.

For example, if a server exceeds its limit, we get notifications. This helps us act fast, like adding more servers or adjusting resources. Also, if someone unauthorized tries to access it, we get alerts. For example, we know immediately if a terminated employee tries to get in.