Managing data consistency in CloudTrail

CloudTrail uses a distributed computing model called eventual consistency. Any change that you make to your CloudTrail configuration (or other AWS services), including tags used in attribute-based access control (ABAC), takes time to become visible from all possible endpoints. Some of the delay results from the time it takes to send the data from server to server, from replication zone to replication zone, and from Region to Region around the world. CloudTrail also uses caching to improve performance, but in some cases this can add time. The change might not be visible until the previously cached data times out.

You must design your applications to account for these potential delays. Ensure that they work as expected, even when a change made in one location is not instantly visible at another. Such changes include creating or updating trails or event data stores, updating event selectors, and starting or stopping logging. When you create or update a trail or event data store, CloudTrail delivers logs to the S3 bucket or event data store based on the last known configuration until the changes propagate to all locations.

For more information about how this affects other AWS services, see the following resources:

• Amazon DynamoDB: What is the consistency model of DynamoDB? in the DynamoDB FAQ, and Read consistency in the Amazon DynamoDB Developer Guide.

• Amazon EC2: Eventual consistency in the Amazon Elastic Compute Cloud API Reference.

• Amazon EMR: Ensuring Consistency When Using Amazon S3 and Amazon Elastic MapReduce for ETL Workflows in the AWS Big Data Blog.

• AWS Identity and Access Management (IAM): Changes that I make are not always immediately visible in the IAM User Guide.

• Amazon Redshift: Managing data consistency in the Amazon Redshift Database Developer Guide.

• Amazon S3: Amazon S3 data consistency model in the Amazon Simple Storage Service User Guide.