AWS CloudTrail FAQs

No, nothing is required to begin viewing your account activity. You can visit the AWS CloudTrail console or AWS CLI and begin viewing up to the past 90 days of account activity.

AWS CloudTrail will only show the results of the CloudTrail Event history for the current Region you are viewing for the last 90 days, and supports a range of AWS services . These events are limited to management events that create, modify, and delete API calls and account activity. For a complete record of account activity, including all management events, data events, and read-only activity, you must configure a CloudTrail trail.

You can specify Time range and one of the following attributes: event name, user name, resource name, event source, event ID, and resource type.

Yes, you can visit the CloudTrail console or use the CloudTrail API/CLI and begin viewing the past 90 days of account activity.

Set up a CloudTrail trail to deliver your CloudTrail events to Amazon Simple Storage Service (Amazon S3), Amazon CloudWatch Logs, and Amazon CloudWatch Events. This helps you use features to archive, analyze, and respond to changes in your AWS resources.

Yes, CloudTrail integrates with AWS Identity and Access Management (IAM), which helps you control access to CloudTrail and to other AWS resources that CloudTrail requires. This includes the ability to restrict permissions to view and search account activity. Remove the "cloudtrail:LookupEvents" from the Users IAM policy to prevent that IAM user from viewing account activity.

There is no cost for viewing or searching account activity with CloudTrail Event History. 

For any CloudTrail trails created, you can stop logging or delete the trails. This will also stop account activity delivery to the Amazon S3 bucket you designated as part of your trail configuration and delivery to CloudWatch Logs if configured. Account activity for the past 90 days will still be collected and visible within the CloudTrail console and through the AWS Command Line Interface (AWS CLI). 

CloudTrail records account activity and service events from most AWS services. For the list of supported services, see CloudTrail Supported Services in the CloudTrail User Guide.

Yes. CloudTrail records API calls made from any client. The AWS Management Console, AWS SDKs, command line tools, and higher-level AWS services call AWS API operations, so these calls are recorded.

Activity information for services with Regional endpoints (such as Amazon Elastic Compute Cloud [Amazon EC2] or Amazon Relational Database Service [Amazon RDS]) is captured and processed in the same Region as the action is made. It is then delivered to the Region associated with your S3 bucket. Activity information for services with single endpoints such as IAM and AWS Security Token Service (AWS STS) is captured in the Region where the endpoint is located. It is then processed in the Region where the CloudTrail trail is configured and delivered to the Region associated with your S3 bucket.

Applying a trail to all AWS Regions refers to creating a trail that will record AWS account activity across all Regions in which your data is stored. This setting also applies to any new Regions added. For more details on Regions and partitions, refer to the Amazon Resource Names and AWS Service Namespaces page .

You can create and manage a trail across all Regions in the partition in one API call or a few selections. You will receive a record of account activity made in your AWS account across all Regions to one S3 bucket or CloudWatch Logs group. When AWS launches a new Region, you will receive the log files containing event history for the new Region without taking any action.

In the CloudTrail console, you select yes to apply to all Regions in the trail configuration page. If you are using the SDKs or AWS CLI, you set the IsMultiRegionTrail to true. 

Once you apply a trail in all Regions, CloudTrail will create a new trail by replicating the trail configuration. CloudTrail will record and process the log files in each Region and deliver log files containing account activity across all Regions to a single S3 bucket and a single CloudWatch Logs log group. If you specified an optional Amazon Simple Notification Service (Amazon SNS) topic, CloudTrail will deliver Amazon SNS notifications for all log files delivered to a single SNS topic.

Yes. You can apply an existing trail to all Regions. When you apply an existing trail to all Regions, CloudTrail will create a new trail for you in all Regions. If you previously created trails in other Regions, you can view, edit, and delete those trails from the CloudTrail console . 

Typically, it will take less than 30 seconds to replicate the trail configuration to all Regions.

You can create up to five trails in a Region. A trail that applies to all Regions exists in each Region and is counted as one trail in each Region.

With multiple trails, different stakeholders such as security administrators, software developers, and IT auditors can create and manage their own trails. For example, a security administrator can create a trail that applies to all Regions and configure encryption using one Amazon Key Management Service (Amazon KMS) key. A developer can create a trail that applies to one Region for troubleshooting operational issues.

Yes. Using resource-level permissions, you can write granular access control policies to allow or deny access to specific users for a particular trail. For more details, go to CloudTrail documentation . 

By default, CloudTrail log files are encrypted using S3 server-side encryption (SSE) and placed into your S3 bucket. You can control access to log files by applying IAM or S3 bucket policies. You can add an additional layer of security by enabling S3 multi-factor authentication (MFA) Delete on your S3 bucket. For more details on creating and updating a trail, see the CloudTrail documentation .

You can download a sample S3 bucket policy and an SNS topic policy from the CloudTrail S3 bucket. You must update the sample policies with your information before you apply them to your S3 bucket or SNS topic.

You control the retention policies for your CloudTrail log files. By default, log files are stored indefinitely. You can use S3 Object lifecycle management rules to define your own retention policy. For example, you might want to delete old log files or archive them to Amazon Simple Storage Service Glacier (Amazon S3 Glacier).

An event contains information about the associated activity: who made the request, the services used, the actions performed, the parameters for the action, and the response elements returned by the AWS service. For more details, see the CloudTrail Event Reference section of the user guide. 

Typically, CloudTrail delivers an event within 5 minutes of the API call. For more information on how CloudTrail works, see here .   

CloudTrail delivers log files to your S3 bucket approximately every five minutes. CloudTrail does not deliver log files if no API calls are made on your account. 

Yes. You can turn on Amazon SNS notifications to take immediate action on delivery of new log files. 

Although uncommon, you may receive log files that contain one or more duplicate events. Duplicate events will have the same eventID. For more information about the eventID field, see CloudTrail record contents . 

CloudTrail log files are delivered in accordance with the S3 bucket policies that you have in place. If the bucket policies are misconfigured, CloudTrail will not be able to deliver log files. 

CloudTrail is designed to support at least one delivery of subscribed events to customer S3 buckets. In some situations, it is possible that CloudTrail could deliver the same event more than once. As a result, customers may notice duplicated events. 

Data events provide insights into the resource (data plane) operations performed on or within the resource itself. Data events are often high-volume activities and include operations such as S3 object level API operations and AWS Lambda function invoke API. Data events are deactivated by default when you configure a trail. To record CloudTrail data events, you must explicitly add the supported resources or resource types you want to collect activity on. Unlike management events, data events incur additional costs. For more information, see CloudTrail pricing . 

Data events that are recorded by CloudTrail are delivered to S3, similar to management events. Once enabled, these events are also available in Amazon CloudWatch Events. 

S3 data events represent API activity on S3 Objects. To get CloudTrail to record these actions, you specify a S3 bucket in the data events section when creating a new trail or modifying an existing one. Any API actions on the Objects within the specified S3 bucket are recorded by CloudTrail. 

Lambda data events record runtime activity of your Lambda functions. With Lambda data events, you can get details on Lambda function runtime. Examples of Lambda function runtime include which IAM user or service made the Invoke API call, when the call was made, and which function was applied. All Lambda data events are delivered to an S3 bucket and CloudWatch Events. You can turn on logging for Lambda data events using the CLI or CloudTrail console and select which Lambda functions get logged by creating a new trail or editing an existing trail. 

Network activity events record AWS API actions made using VPC endpoints from a private VPC to the AWS service and help you meet your network security investigations use cases. This includes AWS API calls that have successfully passed the VPC endpoint policy and those that were denied access. Unlike management and data events that are delivered to both the API caller and the owner of the resource, network activity events are only delivered to the owner of the VPC endpoint. To record network activity events, you must explicitly enable them when configuring your trail or event data store and choose event source(s) of the AWS service(s) you want to collect activity on. You may also add additional filters such as filtering by VPC endpoint ID or logging only the Access Denied errors. Network activity events incur additional charges. For more information, see CloudTrail pricing.

VPC Flow Logs enable you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data can be published to the following locations: Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose. Network activity events for VPC endpoints capture the AWS API actions made using VPC endpoints from a private VPC to the AWS service . This provides you details of who is accessing resources within your network giving you greater ability to identify and respond to unintended actions in your data perimeter. You can view logs of actions that were denied due to VPC endpoint policies or use these events to validate the impact of updating existing policies. 

Yes, CloudTrail now supports adding up to three delegated administrators per organization.

The management account will remain the owner of any organization trails or event datastores created at organization level, regardless of whether it was created by a delegated admin account or by a management account.

Currently, delegated administrator support for CloudTrail is available in all Regions where AWS CloudTrail is available. For more information, see the AWS Regions table.

CloudTrail Insights events help you identify unusual activity in your AWS accounts such as spikes in resource provisioning, bursts of AWS Identity and Access Management (IAM) actions, or gaps in periodic maintenance activity. CloudTrail Insights uses machine learning (ML) models that continually monitor CloudTrail write management events for abnormal activity.

When abnormal activity is detected, CloudTrail Insights events are shown in the console, and delivered to CloudWatch Events, your S3 bucket, and optionally to the CloudWatch Logs group. This makes it easier to create alerts and integrate with existing event management and workflow systems.

CloudTrail Insights detects unusual activity by analyzing CloudTrail write management events within an AWS account and a Region. An unusual or abnormal event is defined as the volume of AWS API calls that deviates from what is expected from a previously established operating pattern or baseline. CloudTrail Insights adapts to changes in your normal operating patterns by considering time-based trends in your API calls and applying adaptive baselines as workloads change.

CloudTrail Insights can help you detect misbehaving scripts or applications. Sometimes a developer changes a script or application that begins a repeating loop or makes a large number of calls to unintended resources such as databases, data stores, or other functions. Often this behavior isn't noticed until the month-end billing cycle when costs have increased unexpectedly or an actual outage or disruption occurs. CloudTrail Insights events can make you aware of these changes in your AWS account so that you can take corrective action quickly.

CloudTrail Insights identifies unusual operational activity in your AWS accounts that helps you address operational issues, minimizing operational and business impact. Amazon GuardDuty focuses on improving security in your account, providing threat detection by monitoring account activity. Amazon Macie is designed to improve data protection in your account by discovering, classifying, and protecting sensitive data. These services provide complementary protections against different types of problems that could arise in your account.

Yes. CloudTrail Insights events are configured on individual trails, so you must have at least one trail set up. When you turn on CloudTrail Insights events for a trail, CloudTrail starts monitoring the write management events captured by that trail for unusual patterns. If CloudTrail Insights detects unusual activity, a CloudTrail Insights event is logged to the delivery destination specified in the trail definition.

CloudTrail Insights tracks unusual activity for write management API operations.

You can enable CloudTrail Insights events on individual trails in your account by using the console, the CLI, or the SDK. You can also enable CloudTrail Insights events across your organization by using an Organizational trail configured in your AWS Organizations management account. You can turn on CloudTrail Insights events by choosing the radio button in your trail definition. 

CloudTrail Lake helps you examine incidents by querying all actions logged by CloudTrail, configuration items recorded by AWS Config, evidence from Audit Manager, or events from non-AWS sources. It simplifies incident logging by helping remove operational dependencies and provides tools that can help reduce your reliance on complex data process pipelines that span across teams. CloudTrail Lake does not require you to move and ingest CloudTrail logs elsewhere, which helps maintain data fidelity and decreases dealing with low-rate limits that throttle your logs. It also provides near real-time latencies as it is fine-tuned to process high-volume structured logs, making them available for incident investigation. It provides a familiar, multi-attribute query experience using SQL, with the ability to schedule and handle multiple concurrent queries. For users less experienced with SQL, natural language query generation is available to help create SQL queries, simplifying data analysis. The ability to summarize query results using AI (in preview) further enhances your capacity to derive meaningful insights from your activity logs and efficiently investigate incidents.

CloudTrail is the canonical source of logs for user activity and API usage across AWS services. You can use CloudTrail Lake to examine activity across AWS services once the logs are available in CloudTrail. You can query and analyze user activity and impacted resources, and use that data to address issues such as identifying bad actors and baselining permissions.

You can find and add partner integrations to start receiving activity events from these applications in a few steps using the CloudTrail console, without having to build and maintain custom integrations. For sources other than the available partner integrations, you can use the new CloudTrail Lake APIs to set up your own integrations and push events to CloudTrail Lake. To get started, see Working with CloudTrail Lake in the CloudTrail User Guide .

AWS Config advanced query is recommended for customers who want to aggregate and query on current state AWS Config configuration items (CI). This helps customers with inventory management, security and operational intelligence, cost optimization, and compliance data. AWS Config advanced query is free if you are an AWS Config customer. 

CloudTrail Lake supports query coverage for AWS Config configuration items, including resource configuration and compliance history. Analyzing configuration and compliance history for resources with related CloudTrail events helps infer who, when, and what changed on those resources. This helps with root-cause analysis of incidents related to security exposure or non-compliance. CloudTrail Lake is recommended if you must aggregate and query data across CloudTrail events and historical configuration items.  

CloudTrail Lake will not ingest AWS Config configuration items that were generated before CloudTrail Lake was configured. Newly recorded configuration items from AWS Config, at an account level or organization level, will be delivered to the specified CloudTrail Lake event data store. These configuration items will be available in the lake for query for the specified retention period, and can be used for historical data analysis. 

If multiple configuration changes are attempted on a single resource by multiple users in quick succession, only one configuration item may be created that would map to the end state configuration of the resource. In this and similar scenarios, it may not be possible to provide 100% correlation on which user made what configuration changes by querying CloudTrail and configuration items for a specific time-range and resource-id.

Yes. The CloudTrail Lake import capability supports copying CloudTrail logs from an S3 bucket that stores logs from across multiple accounts (from an organization trail) and multiple AWS Regions. You can also import logs from individual accounts and single-region trails. The import capability also lets you specify an import date range, so that you import only the subset of logs that are needed for long-term storage and analysis in CloudTrail Lake. After you've consolidated your logs, you can run queries on your logs, from the most recent events collected after you enabled CloudTrail Lake, to historic events brought over from your trails.

The import capability copies the log information from S3 to CloudTrail Lake and keeps the original copy in S3 as is.

You can begin querying the activities that occur after enabling the feature almost immediately.

Common use cases include investigating security incidents, like unauthorized access or compromised user credentials, and enhancing your security posture by performing audits to regularly baseline user permissions. You can perform necessary audits to make sure the right set of users are making changes to your resources (such as security groups), and track any changes not adhering to your organization’s best practices. Additionally, you can track actions taken on your resources and assess modifications or deletions, and get deeper insights on your AWS services bills including the IAM users subscribing to services.

If you are a current or new CloudTrail customer, you can immediately begin using the CloudTrail Lake capability to run queries by enabling the feature through the API or the CloudTrail console.

Select the CloudTrail Lake tab on the left panel of the CloudTrail console, and select the Create Event Data Store button. When you create an event data store, you choose the pricing option you want to use for the event data store. The pricing option determines the cost for ingesting events and the maximum and default retention period for the event data store. Then, select the event categories you want to log (management, data, and network activity events). Additionally, you can take advantage of enhanced event filtering capabilities to control which CloudTrail events are ingested into your event data stores, helping you increase efficiency and reduce costs while maintaining visibility into relevant activities. Once your event data store is set up, you can query any event data stores that you own or manage using SQL-based queries. For users less familiar with SQL, natural language query generation is available to help create SQL queries.

Additionally, query results can be summarized (in preview) using generative AI, further enhancing your ability to derive insights from your CloudTrail data. To help visualize your CloudTrail Lake data, you can use pre-curated dashboards available directly within the CloudTrail console, providing out-of-the-box visibility and key insights from your audit and security data.

Yes. You can update the pricing option from seven-year retention pricing to one-year extendable retention pricing as part of the event data store configuration. Your existing data will remain available in the event data store for the configured retention period. This data will not incur any extended retention charges. However, any newly ingested data will follow the one-year extendable retention pricing charges for both ingestion and extended retention. 

No. We currently do not support migration of an event data store from one-year extendable retention pricing to seven-year retention pricing. However, you will be able to turn-off logging for the current event data store, while creating a new event data store with seven-year retention pricing for newly ingested data. You will still be able to retain and analyze the data in both event data stores with the respective pricing option and configured retention period.

CloudTrail Lake is an audit lake that helps customers meet their use case needs around compliance and auditing. Based on their compliance program mandates, customers need to retain audit logs for a specified duration from when the logs were generated, irrespective of when they were ingested into CloudTrail Lake.

No. Since this was a historical event with an event-time in the past, this event will be retained in CloudTrail Lake for a retention period of 1 year starting from event-time. So the duration for which that event will be stored in CloudTrail Lake will be less than 1 year. 

Today, CloudTrail Lake dashboards support CloudTrail management and data events.

Dashboards are enabled at an account level today, and will apply to all event data stores active in that account that have CloudTrail management or data events enabled.

CloudTrail Lake dashboards are powered by CloudTrail Lake queries. When you enable CloudTrail Lake dashboards, you will be charged for the data scanned. See pricing page for more details.

No. Today, all CloudTrail Lake dashboards are curated and pre-defined, and cannot be customized.

Auditing and compliance engineers can use the CloudTrail Lake dashboards to track progress of compliance mandates such as migration to TLS 1.2 and beyond. CloudTrail Lake dashboards will help security engineers closely track sensitive user activities such as deletion of trails or repeated access denied errors. Cloud operation engineers can get visibility to issues such as top service throttling errors from the curated dashboard.

Yes. You can configure one S3 bucket as the destination for multiple accounts. For detailed instructions, refer to aggregating log files to a single S3 bucket section of the CloudTrail user guide.

CloudTrail integration with CloudWatch Logs delivers management and data events captured by CloudTrail to a CloudWatch Logs log stream in the CloudWatch Logs log group you specify.

This integration helps you receive SNS notifications of account activity captured by CloudTrail. For example, you can create CloudWatch alarms to monitor API calls that create, modify, and delete Security Groups and Network access control lists (ACLs).

You can turn on CloudTrail integration with CloudWatch Logs from the CloudTrail console by specifying a CloudWatch Logs log group and an IAM role. You can also use the AWS SDKs or the AWS CLI to turn on this integration.

After you turn on the integration, CloudTrail continually delivers account activity to a CloudWatch Logs log stream in the CloudWatch Logs log group you specified. CloudTrail also continues to deliver logs to your S3 bucket as before.

This integration is supported in the Regions where CloudWatch Logs is supported. For more information, see Regions and endpoints in the AWS General Reference.

CloudTrail assumes the IAM role you specify to deliver account activity to CloudWatch Logs. You limit the IAM role to only the permissions it requires to deliver events to your CloudWatch Logs log stream. To review IAM role policy, go to the user guide of the CloudTrail documentation.

After you turn on CloudTrail integration with CloudWatch Logs, you incur standard CloudWatch Logs and CloudWatch charges. For details, go to the CloudWatch pricing page . 

CloudTrail log file encryption using SSE-KMS helps you add an additional layer of security to CloudTrail log files delivered to an S3 bucket by encrypting the log files with a KMS key. By default, CloudTrail will encrypt log files delivered to your S3 bucket using S3 server-side encryption.

With SSE-KMS, S3 will automatically decrypt the log files so that you do not need to make any changes to your application. As always, you must make sure that your application has appropriate permissions such as S3 GetObject and AWS KMS Decrypt permissions.

You can use the AWS Management Console, or AWS CLI or the AWS SDKs to configure log file encryption. For detailed instructions, refer to the documentation .

Once you configure encryption using SSE-KMS, you will incur standard AWS KMS charges. For details, go to AWS KMS pricing page .

The CloudTrail log file integrity validation feature helps you determine whether a CloudTrail log file was unchanged, deleted, or modified since CloudTrail delivered it to the specified S3 bucket.

You can use the log file integrity validation as an aid in your IT security and auditing processes.

You can enable the CloudTrail log file integrity validation feature from the console, AWS CLI or AWS SDKs.

Once you turn on the log file integrity validation feature, CloudTrail will deliver digest files on an hourly basis. The digest files contain information about the log files that were delivered to your S3 bucket and hash values for those log files. They also contain digital signatures for the previous digest file and the digital signature for the current digest file in the S3 metadata section. For more information about digest files, digital signatures, and hash values, go to CloudTrail documentation .

The digest files are delivered to the same S3 bucket where your log files are delivered. However, they are delivered to a different folder so that you can enforce granular access control policies. For details, refer to the digest file structure section of the CloudTrail documentation .

You can use the AWS CLI to validate the integrity of a log file or digest file. You can also build your own tools to do the validation. For more details on using the AWS CLI for validating the integrity of a log file, refer to the CloudTrail documentation .

Yes. CloudTrail will deliver the digest files across all Regions and multiple accounts into the same S3 bucket.

The CloudTrail Processing Library is a Java library that makes it easier to build an application that reads and processes CloudTrail log files. You can download the CloudTrail Processing Library from GitHub .

CloudTrail Processing Library provides functionality to handle tasks such as continually polling an SQS queue and reading and parsing Amazon Simple Queue Service (Amazon SQS) messages It can also download log files stored in S3, and parse and serialize log file events in a fault-tolerant manner. For more information, go to the user guide in the CloudTrail documentation. 

You need aws-java-sdk version 1.9.3 and Java 1.7 or higher.

CloudTrail helps you view, search, and download the last 90 days of your account’s management events for free. You can deliver one copy of your ongoing management events to S3 for free by creating a trail. Once a CloudTrail trail is set up, S3 charges apply based on your usage.

You can deliver additional copies of events, including data events and network activity events (in preview), using trails. You will be charged for data events, network activity events, and additional copies of management events. Learn more on the pricing page .

No. The first copy of management events is delivered free of charge in each Region.

Yes. You will be charged for only the data events. The first copy of management events is delivered free of charge. 

When you use CloudTrail Lake, you pay for ingestion and storage together, where the billing is based on the amount of uncompressed data ingested and the amount of compressed data stored. When you create an event data store, you choose the pricing option you want to use for the event data store. The pricing option determines the cost for ingesting events and the maximum and default retention period for the event data store. Querying charges are based on the compressed data you choose to analyze. Learn more on the pricing page .

Yes. Each CloudTrail event, on average, is around 1500 bytes. Using this mapping, you will be able to estimate the CloudTrail Lake ingestion based on past month’s CloudTrail usage in trails by number of events.

Multiple partners offer integrated solutions to analyze CloudTrail log files. These solutions include features like change tracking, troubleshooting, and security analysis. For more information, see the CloudTrail partners section .

To get started with your integration you can review the Partner Onboarding Guide . Engage with your partner development team or partner solutions architect to connect you with the CloudTrail Lake team for a deeper dive or further questions.

No. Turning on CloudTrail has no impact on performance for your AWS resources or API call latency.