What Consistent Means, Service by Service on AWS - The Same Word, a Different Contract, and What You Must Not Carry Across

First Published: 2026-09-22
Last Updated: 2026-09-22

An IAM role is created. The return value says success, so the next step is to assume that role. The call fails. The response indicates insufficient permissions, prompting an examination of the role's spelling, trust policy, and permission boundaries. After a few minutes, the same call succeeds, despite no changes having been made.

This is not a configuration error. The fact that the role was successfully created and the fact that the role is now usable for authorization decisions are, in themselves, separate events. The tendency to conflate these two events is a habit that often develops when using other services. For example, immediately reading an object after writing it to S3 always returns the new content. Applying this expectation to IAM leads to the failure described above.

AWS documentation, for both services, is technically accurate. S3 promises strong consistency, while IAM states that it provides eventual consistency. The problem lies in the fact that both documents use the same word, "consistent," around which their descriptions are structured. This same word represents different contracts for each service. What exactly is being guaranteed? Whose view is the guarantee stated from? How does the caller learn that the guarantee has not arrived? These three answers differ from document to document.

Worse, the fault line does not run along service boundaries. Within S3, reading and writing objects provides strong consistency, while bucket configurations offer eventual consistency. Similarly, within IAM, the path to create a resource and read it back differs in its guarantees from the path where that resource is used for authorization. Service names are too coarse-grained to effectively delineate these differences.

This article is not an introduction to AWS consistency models. It addresses a single point: whether the way of waiting and the way of reading learned in one service may be carried into another. To illustrate this, the article presents side-by-side excerpts from documentation that use the term "consistent," comparing them along three axes: what the guarantee is about, whose view it is stated from, and how the caller learns that it has not arrived. The conclusion is not a classification table, but rather a naming of the assumptions that must not be carried across.

This article does not address transaction isolation levels. Although the terms are closely related, transaction isolation is a separate topic, covered in Transaction Isolation on AWS Databases. It also does not delve into the internal mechanisms by which S3 achieves strong consistency. That information is available in How Amazon S3 Achieves Strong Consistency and Durability. This article focuses solely on the wording of the contracts as described in the documentation.

The technical details in this article have been verified against official AWS documentation. The verification date is 2026-09-21. The quotes appear in their original form, and every number carries its source. No claim of comprehensiveness is made. This article compares a selection of representative services, and does not cover the entirety of AWS.

Failing Twice on the Same Word
The Word Is Attached to a Surface, Not to a Service
The First Axis - What the Guarantee Is About
The Second Axis - Whose View the Guarantee Is Stated From
The Third Axis - How the Caller Learns the Guarantee Has Lapsed
The Comparison Across Services
Where the Primary Sources Disagree
Assumptions That Must Not Travel
Failure Modes
Frequently Asked Questions
Summary
References

1. Failing Twice on the Same Word

This chapter settles the shape of the problem. What matters is not the definition of a word, but what happens when an understanding that was correct in one source is carried into another.

1.1 The Assumption That Travels

Here is the opening failure again, rewritten from the side of the assumptions.

The designer learned S3 first. With S3, if writing an object is successful, the next read always returns the new content. This is clearly documented.
This understanding is then generalized: if a write operation is successful, subsequent operations will reflect a new state.
This generalized assumption applies to IAM. However, IAM does not meet this assumption. It takes time for a change to be reflected in authorization decisions.

The same type of failure can occur in reverse. A designer who learned DynamoDB first might understand that consistency can be chosen on a per-call basis. In DynamoDB, ConsistentRead is a parameter that allows for this. Carried into Route 53, that understanding expects the same choice for a DNS change. It is not there, so a fixed wait time goes into the design instead. What never gets looked for is the mechanism Route 53 does have, the one that removes any need to estimate a wait at all.

Neither failure comes from misreading a document. The understanding itself is correct inside the source it came from. The error only arises when that understanding is applied to a different system.

1.2 What This Article Does Not Cover

The line is drawn first, because several adjacent subjects use similar words.

Covers	Does Not Cover
Sections where the documentation states "consistent," detailing what those statements promise.	Transaction isolation levels.
Differences in what the guarantee is about, whose view it is stated from, and how the gap shows.	The internal mechanisms by which S3 achieves strong consistency.
The means by which a caller learns that a guarantee has lapsed.	Distributed systems theory.
Comparisons of contracts across different services.	A list detailing the time it takes for changes to be reflected.
The assumptions that must not be carried across.	Pricing.

Transaction isolation levels are not covered in this article. The names of these levels, the fact that the same name can mean different behaviors depending on the engine, and the fact that a single statement can have different meanings depending on the path, are all discussed in Transaction Isolation on AWS Databases. This article does not contain any discussion of isolation levels.

The internal architecture of S3 is also outside the scope of this article. Details on what changed in December 2020, and how S3 keeps availability while holding strong consistency, are held by How Amazon S3 Achieves Strong Consistency and Durability. This article treats S3 as a single entry in a comparison table.

No table of how long a change takes to appear is built here either. A worked example that lays out the delay layer by layer for one path can be found in Identity-Aware Data Access on AWS. This article focuses on whether the documentation promises a specific timeframe, rather than the timeframe itself.

Contracts that stack inside a single system are also out of scope. How Amazon S3 Files Keeps a Bucket and a File System in Sync describes one product that layers three different consistency models. The definition of "close-to-open" on the file system side, and the fact that this term does not appear in the specifications, are also covered in that document. This article focuses on horizontal comparisons, not layered structures.

1.3 The Three Questions That Separate the Contracts

When a document states something is "consistent," there are three things you should be able to derive from that single sentence. The chapters that follow take them in this order.

What is the scope of the guarantee? Is it related to a single object, a single item, a collection of changes submitted together, the range visible from the next API call, or a Region-spanning scope?
From whose perspective is the guarantee being made? Is it the caller that performed the write, another caller, another Region, or the authorization system rather than the API that was called?
How does the caller learn that the guarantee has not arrived? Can it be determined through a state, measured as a value, or does it only manifest in a way that cannot be distinguished from a correct response?

If even one of these three is misread, the design will fail, even if the other two are correct. The IAM example mentioned earlier misread the first and the third. The Route 53 example misread the third.

2. The Word Is Attached to a Surface, Not to a Service

A unit has to be settled before the comparison starts, because a comparison by service name breaks on its first row. This article calls the thing a word is attached to a surface. A single service has several surfaces, and the contract differs from surface to surface.

2.1 One Service, Two Contracts - Amazon S3

The S3 User Guide states the following regarding guarantees for objects:

Amazon S3 provides strong read-after-write consistency for PUT and DELETE requests of objects in your Amazon S3 bucket in all AWS Regions.

A few paragraphs later on the same page, the following sentence appears:

Bucket configurations have an eventual consistency model.

The same page carries two contracts side by side, for the same service. Object reads and writes have strong consistency. Bucket configurations, however, are eventually consistent. And the same page even provides specific waiting times for the latter.

If you enable versioning on a bucket for the first time, it might take a short amount of time for the change to be fully propagated. We recommend that you wait for 15 minutes after enabling versioning before issuing write operations (PUT or DELETE requests) on objects in the bucket.

The summary that S3 is a service with strong consistency is correct. But carrying that summary into the moment just after versioning is first enabled skips the wait the same page recommends.

That a contract belongs to a surface shows in the structure of the documentation itself. While the section on consistency models does not specifically mention bucket types, a separate page restates the same guarantee for directory buckets.

S3 Express One Zone provides strong read-after-write consistency for PUT and DELETE requests of objects in your directory buckets in all AWS Regions.

This practice of rewriting the same guarantee for each type suggests that each type should be reviewed individually. The comparison table in this article only includes a row for general-purpose buckets.

2.2 One Service, Two Contracts - AWS IAM

IAM also follows a similar structure. The troubleshooting section of the IAM User Guide states the following regarding the service as a whole:

As a service that is accessed through computers in data centers around the world, IAM uses a distributed computing model called eventual consistency. Any changes that you make in IAM (or other AWS services), including attribute-based access control (ABAC) tags, take time to become visible from all possible endpoints.

Reading this single sentence alone, one might conclude that all operations related to IAM are eventually consistent. The AWS Security Blog, however, splits the same service in two.

When you call the IAM control plane APIs to create, update, or delete resources, you can expect a read-after-write consistent response. This means that you can retrieve (read) the resource and its latest updates immediately after it's written. In contrast, the IAM data plane, where authorizations occur, is eventually consistent.

The ability to immediately read back a role you have created, and the ability for that role to immediately grant permissions, are two separate processes. The documentation calls the former read-after-write consistent and the latter eventually consistent. The initial failures often occur when assuming that these two are a single entity. Reading the role back confirms that it exists. Assuming it still fails.

The resilience chapter of the IAM User Guide describes the same structure.

There is one IAM control plane for all commercial AWS Regions, which is located in the US East (N. Virginia) Region. The IAM system then propagates configuration changes to the IAM data planes in every enabled AWS Region. The IAM data plane is essentially a read-only replica of the IAM control plane configuration data.

This article does not address the specific process by which IAM policies are ultimately evaluated. Details regarding the precedence of explicit denials and the relationships between different policy types can be found in IAM Policy Evaluation Logic Step-by-Step. The evaluation process itself is deterministic. What is non-deterministic is whether the policy being evaluated is actually delivered to the evaluator.

2.3 Why the Service Name Is Too Coarse a Unit

The key takeaway from the two examples above is this: The statement that a service is "eventually consistent" has no settled meaning until the surface is named.

Calling S3 eventually consistent is a statement about bucket configuration. It is not a statement about objects.
Calling IAM eventually consistent is a statement about authorization. It is not a statement about reading a resource back.

The comparison table that follows cuts its rows by surface rather than by service. Consequently, the same service may appear on multiple rows.

Taking the surface as the unit is not something this article does first. How Amazon S3 Files Keeps a Bucket and a File System in Sync describes one product that has two writable surfaces, a separate contract on each, and a further contract on the layer that joins them. That document analyzes a single system vertically, while this article examines multiple services horizontally. Because the method of defining units is similar, the two approaches can be connected without overlap.

3. The First Axis - What the Guarantee Is About

The first axis is what the guarantee encloses. When documentation states a guarantee, it always writes the scope, and the scope is the first thing lost when summarizing.

3.1 One Object, and Nothing About the Relation Between Objects

S3's strong consistency is a guarantee about a single key. The same page explicitly denies anything outside it.

Updates are key-based. There is no way to make atomic updates across keys. For example, you cannot make the update of one key dependent on the update of another key unless you design this functionality into your application.

The same section promises atomicity within a single key.

Updates to a single key are atomic. For example, if you make a PUT request to an existing key from one thread and perform a GET request on the same key from a second thread concurrently, you will get either the old data or the new data, but never partial or corrupt data.

These two sentences define boundaries from both the inside and the outside. Within a single key, there is no possibility of failure. There is nothing between two separate keys. Designs that treat manifests and entities as distinct objects, assuming the manifest appears first, fall outside of this boundary.

3.2 One Item, and Only on Tables and Local Secondary Indexes

The unit of the DynamoDB guarantee is the item, and where that guarantee can be used is limited.

Strongly consistent reads are only supported on tables and local secondary indexes. Strongly consistent reads from a global secondary index or a DynamoDB stream are not supported.

The DynamoDB Developer Guide also states the default explicitly. The default is eventual consistency for read operations; a caller asks for a strongly consistent read with the ConsistentRead parameter on GetItem, Query, and Scan.

There are places where no choice is offered at all. Reads from global secondary indexes are always eventually consistent, and using the parameter will not result in strong consistency.

How to incorporate this limitation into the DynamoDB design is outside the scope of this article. The Amazon DynamoDB Capacity and Global Tables Guide covers capacity modes and global table design, while the Amazon DynamoDB Single Table Design Complete Guide addresses the design decisions regarding which paths to use for strong consistency reads. This article takes only the wording of the contract on this surface, and does not provide design recommendations.

3.3 One Set of Changes, All of Them or None

The guarantee provided by Route 53 applies not to individual records, but to batches of changes. The API Reference states:

Change batches are considered transactional changes. Route 53 validates the changes in the request and then either makes all or none of the changes in the change batch request.

This guarantee does not cover the protection of a single record. Instead, a batch of changes will either be fully applied or not applied at all. You will not see an intermediate state where only some records in the batch have landed.

The design of DNS switching, particularly the combination of health checks and failover, is held by Route 53 Health Check and Failover. This article focuses solely on how to determine whether changes have been received.

3.4 What the Next Call Can See

The EC2 guarantee applies to a sequence of API calls, not to the data itself.

The Amazon EC2 API follows an eventual consistency model, due to the distributed nature of the system supporting the API. This means that the result of an API command you run that affects your Amazon EC2 resources might not be immediately visible to all subsequent commands you run.

The guarantee does not cover whether the result of the previous call is visible in the subsequent call. While discussions about S3 and DynamoDB relate to the content of the items, the EC2 discussion concerns the very existence of the resources.

3.5 Beyond a Single Region

The previous four sections have all focused on scenarios within a single Region. However, the scope of guarantees may extend beyond that boundary.

A DynamoDB global table covers the visibility of an item across Regions. In the default mode, reads from other Regions will be eventually consistent. In strong consistency mode, any strong consistency read against any replica will return the most recent version of the item.

This represents the broadest scope. Anything that holds true within a single Region is also covered by the guarantees that extend beyond that Region. However, broad does not necessarily mean strong. The level of guarantee provided depends on the mode selected, even when considering the same scope.

The perspective from which these guarantees are viewed changes when spanning Regions. That is the subject of the next chapter.

3.6 The Configuration Surface Is Not the Data Surface

The two examples from Chapter 2 restate cleanly in the vocabulary of this axis. S3 bucket configuration and IAM authorization are both configuration surfaces. Neither carries the guarantee that the data surface carries.

Across the examples this article gives, the split holds. What the documentation promises strong consistency for is the data surface, and what it calls eventually consistent is the side that distributes configuration. However, the documentation does not explain why this is the case. All that can be said is that when telling surfaces apart, whether the surface is configuration or data is a useful clue.

4. The Second Axis - Whose View the Guarantee Is Stated From

The second key consideration is perspective. Guarantees are always presented from a particular viewpoint. A guarantee seen by the caller that performed the write, one seen by a different caller, and one seen from another Region are different things even when the same word is used.

4.1 From the Writer's Own View

The phrase read-after-write names the situation where whoever performed the write reads it back. Guarantees regarding S3 objects, as well as descriptions concerning the IAM control plane, take this form.

This type of guarantee can be used as a means of verification. If you read what you have just written and it appears as expected, then the write operation has been delivered. However, that confirms only that surface. In the case of IAM, being able to read a role back says nothing about whether that role has taken effect in authorization.

4.2 From Another Caller's View

S3's strong consistency is not limited to the writer. The documentation speaks about reads that follow a successful response, and it does not make the reader's identity a condition.

Amazon S3 achieves high availability by replicating data across multiple servers within AWS data centers. If a PUT request is successful, your data is safely stored. Any read (GET or LIST request) that is initiated following the receipt of a successful PUT response will return the data written by the PUT request.

The condition that applies is that the read must occur after a successful response. For concurrent writes, the same page states a separate condition.

Amazon S3 does not support object locking for concurrent writers. If two PUT requests are simultaneously made to the same key, the request with the latest timestamp wins. If this is an issue, you must build an object-locking mechanism into your application.

The condition under which a guarantee is valid is that the write operation has completed. During periods of overlapping writes, a different rule applies, where the last writer prevails.

4.3 From Another Region's View

As the end of Chapter 3 showed, the scope of a DynamoDB global table spans Regions. What this section looks at is whose view is taken of that scope.

The view belongs to whoever reads the table from another Region. In the default mode, what a reader in another Region sees is eventually consistent. In strong consistency mode, writes are replicated to at least one other Region synchronously before a success is returned, so a strongly consistent read of any replica returns the latest item.

However, the ability to switch perspectives is not available to the caller. While ConsistentRead is a per-call option, cross-Region consistency is a configuration determined when the table is created and cannot be changed by modifying the caller's code.

The design of cross-Region replication and failover itself is held by AWS Multi-Region Active-Active Architecture Guide. For alternative approaches to distribution, such as those used by Amazon Aurora DSQL, refer to Amazon Aurora DSQL Design Decision Guide.

4.4 From the Authorization System, Which Is Not the API You Called

The eventual consistency of the IAM data plane sits at a different place from the previous three. The delay is not due to the response of the API that was called. Instead, the delay sits in the system that decides on a call to a completely different service.

When a role update fails, what fails is not the IAM API but the service called with that role. From the caller's perspective, the delay occurs outside of the service they directly interact with. Examining the responses from any service, there is no indication that a delay is occurring.

5. The Third Axis - How the Caller Learns the Guarantee Has Lapsed

The third key area is the most practical, because it asks how the caller finds out that a guarantee has not arrived. The documentation offers three methods for determining this.

5.1 Readable as a State

Route 53 holds the state of propagation in a readable form.

When you submit a ChangeResourceRecordSets request, Route 53 propagates your changes to all of the Route 53 authoritative DNS servers managing the hosted zone. While your changes are propagating, GetChange returns a status of PENDING. When propagation is complete, GetChange returns a status of INSYNC. Changes generally propagate to all Route 53 name servers managing the hosted zone within 60 seconds.

The ChangeResourceRecordSets operation returns a change ID. Passing this ID to GetChange will return either PENDING or INSYNC. There is no need to estimate wait times. You can simply query to determine if the operation is complete.

That same sentence carries a duration. What it carries is generally, not an upper bound. Building the 60 seconds into a design as an upper bound states something the documentation does not. Once the state answers, there is nothing left to estimate.

5.2 Measurable as a Number

The Aurora reader publishes its lag as a number. The Aurora User Guide puts it this way.

The Aurora Replicas are subject to a replica lag, even though that lag is usually 10 to 20 milliseconds. You can monitor the replication lag and decide whether it is within the range of your data consistency requirements. In some cases, your read queries might require strong read consistency (read-after-write consistency). In these cases, you can continue using the cluster endpoint for them and not the reader endpoint.

That sentence hands the judgment to the caller. It makes the lag measurable and then says that deciding whether it sits inside the requirement belongs to the user. It even names a way out for the reads that do not fit, which is not to use the reader endpoint.

An observable value is not a guaranteed value. AuroraReplicaLag is a measurement, not an upper bound. The 10 to 20 milliseconds is simply a reference to a typical figure stated by AWS, and it is not a promise that the figure will not be exceeded.

Turning one more page of documentation shows exactly how typical a typical value is. For the same lag, AWS documentation gives three different figures. Chapter 7 holds the detail.

5.3 Visible Only as an Answer That Cannot Be Told Apart from a Correct One

The third case is the most dangerous. The fact that a guarantee has not arrived comes back in the shape of a response that looks perfectly legitimate on its own.

For IAM, the assessment is based on the configuration before the update. For a change that adds permission, the request is evaluated against the configuration from before the change until the update arrives, and a denial comes back. The policy is correct and the spelling is correct. A denial comes back all the same. The same denial comes back when the caller genuinely lacks the permission. There is no information in the response that allows you to distinguish between these two scenarios. On this point the IAM User Guide states that the delay happens, and offers the caller no way to tell whether it is happening.

For EC2, what comes back is an error saying the resource does not exist. The documentation explicitly identifies this as the symptom.

If you successfully run the RunInstances command, and then immediately run another command using the instance ID that was provided in the response of RunInstances, it may return an InvalidInstanceID.NotFound error. This does not mean the instance does not exist.

The documentation goes on to recommend repeating the Describe calls with exponential backoff, and adding wait time between calls. While there is no way to directly read the state, the symptom is clearly identified. Knowing the symptom allows you to differentiate between errors that warrant retries and those that do not.

For DynamoDB, the response returns an outdated item. It is neither an error nor a denial. The response is perfectly valid in shape, and only the content is stale. Without knowing that the default read operation provides eventual consistency, there is no reason to suspect an issue.

There is another key difference between these three examples: whether the documentation provides a name for the symptom, or whether it provides no such identification.

5.4 These Three Are Not a Ranking

The three above are not a list in order of preference. A readable state is not always the desirable thing.

Designs that provide a clear state require mechanisms to maintain that state and respond to inquiries. Changes to Route 53 have the appropriate frequency and weight to support this approach.
Designs that return a value allow user requirements to dictate the criteria for decision-making. This is the correct approach in areas where requirements vary from case to case.
Designs that return nothing are chosen where a very large number of decisions has to be returned every second, in exchange for that scale.

The three are different design choices, not stages of maturity. What the caller has to do is find out first which one it is facing, rather than expect a particular one.

How the Caller Learns the Guarantee Has Lapsed

6. The Comparison Across Services

The three axes so far drop into a single table. Each row is a surface, not a service. Each cell includes a citation indicating the source of the information.

6.1 How to Read the Table

When selecting a row, look at the surface being touched. If you select a row based on the service name, the mix-up from Chapter 2 happens again.

In practical terms, the two columns to read first are what is guaranteed and how the gap shows. Check that what is guaranteed matches the unit of your own operation, and that some means exists of learning that it has not arrived. Once those two line up, you can then focus on the specific design details.

6.2 The Table

Surface	The word the documentation uses	What is guaranteed	Whose view	How the gap shows	Primary source
Amazon S3 general purpose bucket, objects	strong read-after-write consistency	One key. Atomicity across keys is explicitly denied.	Any reader after a successful response, not only the caller that wrote.	There is no gap.	S3 User Guide
Amazon S3 bucket configuration	eventual consistency model	Not stated.	Not stated.	Nothing. A 15 minute wait is recommended when versioning is first enabled.	S3 User Guide
Amazon DynamoDB table or local secondary index	strongly consistent reads	One read request, reflecting every prior successful write.	The caller that asked for it.	Without `ConsistentRead`, a stale item comes back in a perfectly valid shape.	DynamoDB Developer Guide
Amazon DynamoDB global secondary index or stream	eventually consistent	Strongly consistent reads are not offered.	Not applicable.	Setting `ConsistentRead` returns a `ValidationException`.	DynamoDB API Reference
Amazon DynamoDB global table	eventual by default, strong by choice	Visibility of an item across Regions.	A reader in another Region.	In the default mode, nothing. A stale item comes back from the other Region.	DynamoDB Developer Guide
AWS IAM control plane	read-after-write consistent	The IAM resource that was just written.	The caller reading it back.	There is no gap.	AWS Security Blog
AWS IAM data plane	eventually consistent	Not stated. The delay can run to several seconds or longer.	Whatever decides authorization in each Region.	Nothing. The answer comes from the configuration as it stood before the change.	AWS Security Blog, IAM User Guide
Amazon EC2 API	eventual consistency model	Not stated. What one call created may not be visible to the next.	The calls that follow.	An error. `InvalidInstanceID.NotFound` is named in the documentation.	Amazon EC2 Developer Guide
Amazon Route 53 record change	transactional changes, then propagation	One change batch, applied in full or not at all.	The authoritative DNS servers managing the hosted zone.	A state. `PENDING` becomes `INSYNC`.	Route 53 API Reference
Amazon Aurora reader in the same Region	replica lag	Not stated as a guarantee. The typical values differ between documents.	A reader connected to the reader endpoint.	A number. `AuroraReplicaLag`.	Aurora User Guide

6.3 What the Table Cannot Say

This table is a tool for comparison, not a claim of comprehensiveness. Three limits are worth stating plainly.

The rows listed represent examples. A surface that is not listed here is not thereby a surface without the same three axes, and nothing is claimed about the contracts of surfaces that are not listed.
The absence of a description is not the absence of a guarantee. It means that the statement could not be confirmed in the documentation this article reached. The statement may sit on another page.
The information in this table is current as of the verification date. The verification date is 2026-09-21. S3's consistency model has changed in the past, and contract terms are subject to change.

7. Where the Primary Sources Disagree

In places, AWS documents state the same thing differently. This section highlights four such discrepancies. The classification of the shapes is not something this article invented.

7.1 Why This Article Borrows the Classification

The article Where the AWS Primary Sources Disagree About Launch Dates holds the question of how to sort the shapes a disagreement takes. That article sets out four shapes, and this one borrows the names as they stand. Re-deriving the classification here would leave the same thing with two names. Falsehoods AWS Architects Believe About Regions and Availability Zones borrows the same four shapes for the documents that describe Regions and Availability Zones.

One thing is worth stating before the four. None of them is a claim that the AWS documentation contradicts itself. Each document is accurate for its own purpose, and what differs is the grain. The point here is that no single document is sufficient to finalize a contract.

7.2 The First Shape - Only the API Reference Says What the Failure Looks Like

The DynamoDB Developer Guide states the following regarding global secondary indexes:

Strongly consistent reads from a global secondary index or a DynamoDB stream are not supported.

It states that certain features are not provided. However, it does not explain what happens when you request something that is not provided. Whether the parameters are silently ignored, or the call fails, changes how you write the calling side.

Among the AWS documentation this article reached, the API Reference is what documents this behavior. The Query page and the Scan page both contain the same statement.

Strongly consistent reads are not supported on global secondary indexes. If you query a global secondary index with ConsistentRead set to true, you will receive a ValidationException.

It fails. It does not silently fall back to an eventually consistent read. This is a desirable behavior for the caller. It prevents the application from continuing to operate under incorrect assumptions. Designers who only read the Developer Guide will not have this assurance.

7.3 The First Shape Again - Only a Blog Post Separates the Two Planes

The two statements quoted in Chapter 2 line up differently from the angle of this chapter.

The IAM User Guide's troubleshooting section states that changes to IAM may not be immediately visible, and it does not distinguish between the control plane and the data plane. The resilience chapter describes the structure of the two planes, but it does not associate the term "consistent" with the control plane.

The only place this article could confirm that the control plane's response is read-after-write consistent was the AWS Security Blog. It is an official source, but it belongs to a different document system from the User Guide. It is not a definitive statement that the same information does not exist in the User Guide. Inside the range this article searched, that was the only place it appeared.

This arrangement has a practical consequence. A designer who only reads the User Guide might understand that all operations on IAM are eventually consistent. This understanding, while conservative, is less likely to lead to incidents. However, it fails to explain why verifying the existence of a role by reading it back is ineffective. The opening phenomenon, where reading the role back succeeds while assuming it fails, cannot be explained without the split between the two planes.

7.4 The Second Shape - Three Typical Values for the Same Lag

AWS documentation gives three figures for the lag of an Aurora reader. In every case the figure is for a reader inside the same Region.

Document	Description
Aurora User Guide	`that lag is usually 10 to 20 milliseconds`
Aurora FAQ	`We typically observe lag times in the tens of milliseconds`
AWS Prescriptive Guidance	`Aurora Replicas typically lag behind the writer instance by a short interval (100 milliseconds or less)`

None of the three states an upper bound. All three mark the figure as typical, with usually, typically and typically. And the values presented as typical are nearly an order of magnitude apart.

This discrepancy does not necessarily mean that any of the figures are incorrect. The three documents have different purposes and different underlying assumptions for their observations. Moreover, all three are written in a way that does not imply an upper bound.

This situation directly supports the distinction outlined in Chapter 5. In systems where values are measured, the criteria for judgment reside with the user. If you simply copy the typical values from these documents and treat them as design constants, the constant will vary depending on which document you consult. What has to be measured must not be settled by reading.

7.5 The Third Shape - One Page Carries the Qualifier and the Other Does Not

Two pages display the same numerical value regarding Route 53 propagation time. The API Reference states:

Changes generally propagate to all Route 53 name servers managing the hosted zone within 60 seconds.

The note in the Developer Guide states:

Changes generally propagate to all Route 53 name servers within 60 seconds.

The difference is the presence or absence of managing the hosted zone. The former limits the statement to the name servers that manage that hosted zone. The latter does not, so it reads as a statement about every Route 53 name server.

The figure is the same, and both are qualified by generally. Even so, only one of them states what the guarantee is about. This particular form is the subject of this article. The qualifier is the first element to be lost during the summarization process, and even when lost, the resulting sentence remains grammatically sound.

7.6 What Remains Unresolved

As of the time of writing this article, there is one item that remains unresolved.

The previously published AWS IAM Inbound Workload Federation carries a verbatim quote from the IAM User Guide about the eventual consistency of IAM. That wording differs from the wording of the current troubleshooting section, as verified on 2026-09-21. Three searches with different keywords failed to surface the quoted wording on the current page.

Failing to find it is not proof that it is gone. Whether the text was revised, whether it sits on another page, or whether the search simply did not reach it, cannot be told apart here. This article quotes the wording of the current page and records the point as unresolved.

8. Assumptions That Must Not Travel

The comparison so far, recast in the shape that a designer actually carries around. This is the conclusion of the article. Three of the six below are correct on one surface and wrong on another. One of them holds only under a condition. One, in Section 8.5, is a sentence whose truth cannot be settled at all. And one, in Section 8.6, names no surface on which it holds.

8.1 The Assumption That a Successful Write Is Visible to the Next Read

This is correct for S3 objects. It is wrong for the IAM data plane.

This assumption is the one most widely carried around. When it is carried into the authorization system, the failure shows up in the shape of a misconfigured permission. Consequently, investigations tend to focus on the configuration, and it often takes a considerable amount of time to realize the root cause.

8.2 The Assumption That Consistency Can Be Requested on Each Call

While this is correct for DynamoDB tables and local secondary indexes, it is inaccurate when referring to global secondary indexes. Route 53 and IAM do not have such parameters.

Choosing per call is a design decision inside DynamoDB. It is not a property shared across AWS.

8.3 The Assumption That Waiting a Fixed Number of Seconds Is a Design

This statement is only conditionally correct and applies only when the numbers are found in official documentation. Otherwise, it is inaccurate.

Before implementing a fixed wait time, there are two things to verify. First, is the number documented in the official materials? Second, is the documented number an upper bound, or a typical value? The 60 seconds in Route 53 is qualified by generally, not an upper bound. The 10 to 20 milliseconds in Aurora is qualified by usually, not an upper bound. The 15 minutes for S3 versioning is a recommendation, not an upper bound.

Typical values carry one more trap. As Chapter 7 showed, AWS documentation gives three different typical values for the same Aurora lag. The appropriate constant value to implement will vary depending on which documentation you consult.

8.4 The Assumption That Asking for the Status Tells You Whether It Is Done

This is correct for Route 53. It is wrong for every other surface this article lists.

Situations like INSYNC are exceptional. Looking for the same thing in another service returns nothing first. What follows is a decision to stop looking and drop back to a fixed wait time instead. Checking the third axis first removes this detour.

8.5 The Assumption That a Service Is Eventually Consistent

Until a surface is named, this sentence has no settled meaning.

S3 can be described as a service that provides strong consistency, as well as a service that provides eventual consistency. IAM is the same. The unit is not the service. The unit is the surface. When this sentence turns up in a design discussion, which surface it is about has to be settled first.

8.6 The Assumption That No Error Means the Change Took Effect

This is wrong for an eventually consistent read in DynamoDB. A stale item is not an error. It comes back as a valid response.

The assumption is wrong for IAM as well, with the shape reversed. While a change that adds permission has not arrived, the request is evaluated against the configuration from before the change, so a denial comes back. That denial cannot be told apart from a genuine one.

The presence or absence of errors cannot be used to determine whether the changes have been applied. The only usable means are the ones identified on the third axis.

9. Failure Modes

This section lists how the assumptions from the previous chapter might manifest in actual work. All of these scenarios relate to design and operation, and do not describe attack procedures.

9.1 Reading a Denial as a Permissions Problem

When a denial occurs shortly after changes to roles or policies, it's common to begin investigating it as a configuration error. The check runs through the policy spelling, trust policies, permission boundaries, and resource policies, one by one. However, after thorough examination, everything appears to be correct, and nothing is found.

If you establish a habit of checking the time elapsed since the change, this investigation might not even begin. The IAM User Guide recommends avoiding including changes in paths that require high availability and advises verifying propagation before production workflows depend on them.

However, the guide does not specify how to perform that verification. It instructs you to verify propagation, but does not provide any means to query whether propagation has actually occurred. This is not a deficiency in the documentation; it is exactly the third type from Chapter 5. On a surface that returns no status, verification is something the caller has to build separately. In practice that means retrying the operation and watching for the answer to change.

9.2 Reading a Not Found as the Resource Not Existing

The EC2 InvalidInstanceID.NotFound error gets treated as evidence that the resource was never created. The documentation explicitly refutes this interpretation. If the creation request was successful, the resource exists; it's simply not visible.

Treating this error as a permanent failure within an automated process can stop the process partway and leave an already created resource behind.

9.3 Verifying a Permission Right After Granting It

After setting permissions and immediately testing the result, you find it fails, so you adjust the settings. The issue was not that the initial settings were incorrect; the verification simply occurred too early. After making the changes and trying again, it now works, because the propagation has finished by then. A record remains showing that what initially seemed like an incorrect change was, in fact, the correct solution.

This path is not limited to IAM. In any configuration that involves identity propagation, different layers can introduce varying delays. A real-world example can be found in the relevant chapter of Identity-Aware Data Access on AWS.

9.4 Confusing a Cache Window with Eventual Consistency

Caching a credential or a token is a different mechanism from eventual consistency. Eventual consistency resolves once propagation is complete. Caching, on the other hand, persists until the cache window expires or the underlying resource is recreated. The assumption that waiting will resolve the issue does not apply to cached data.

For example, the caching of credentials within EKS Pod Identity, and the fact that changing an association does not reset that cache, are recorded in Amazon EKS Pod Identity and IRSA Decision Guide.

9.5 Looking for a Per-Call Parameter in a Service That Has None

Something equivalent to ConsistentRead gets looked for in Route 53 and in IAM. It is not there, so a fixed wait time goes in instead. Regarding Route 53, the search target is different. What Route 53 offers is not a per-call parameter but an API that answers a question about the state.

9.6 Treating a Measurable Value as a Guarantee

Because AuroraReplicaLag is usually small, a read from the reader gets used to confirm data straight after a write. A measured value is not an upper bound. The proof-of-concept page of the Aurora User Guide quoted in Chapter 5 says to measure the lag, judge whether it sits inside the requirement, and use the cluster endpoint rather than the reader endpoint for the reads that do not.

9.7 Testing Only on the Surface That Has a Guarantee

A test is built on reads and writes against S3 objects, and the result is taken as confirmation of the consistency of the whole system. The test covers only the surface whose contract is strongest. A change to bucket configuration, a change in IAM, and a change in DNS all fall outside that test.

10. Frequently Asked Questions

Each item in this chapter answers to a passage in the body. Nothing here contradicts the body.

10.1 Does AWS settle on one consistency model per service?

No. Within one service it differs from surface to surface. S3 carries strong consistency for objects and eventual consistency for bucket configuration. IAM carries separate statements for the control plane and for the data plane. Describing a consistency model based solely on the service name always drops one of the surfaces.

10.2 How long should you wait on an eventually consistent service?

Unless the documentation specifies a particular value, the answer is not determined. Even when values are provided, they are often typical values rather than upper bounds. Ask first whether the state answers at all, then decide a wait time. On a surface like Route 53, where the state answers, no wait time has to be decided at all.

10.3 What happens if you set `ConsistentRead` on a DynamoDB global secondary index?

DynamoDB returns a ValidationException. It does not silently fall back to an eventually consistent read. The DynamoDB API Reference is what documents this behavior. The Developer Guide only says that it is not supported.

10.4 Can you assume an IAM role right after creating it?

No. The successful creation of a role and the authorization system recognizing that role are separate matters. The IAM User Guide recommends avoiding introducing IAM changes into high-availability paths and verifying propagation before any production processes depend on them.

10.5 Does this article cover transaction isolation levels?

No. This article does not address transaction isolation levels. Transaction Isolation on AWS Databases holds that topic. This article, instead, explains what the passages that say "consistent" are actually promising.

10.6 If S3 objects are strongly consistent, can several objects be updated together?

No. The scope of guarantees is limited to a single key. The S3 User Guide states plainly that there is no way to make an atomic update across keys. Any processing that leans on a relationship between objects is something the user builds.

10.7 Which of the three ways of learning about the gap is preferable?

None of the three is preferable. They are different design choices. A design that allows you to read the state requires a mechanism to maintain that state. A design that lets the value be measured leaves the criterion to the user. A design that returns nothing is chosen in exchange for scale. What the caller has to do is find out first which one it is facing.

10.8 Does the comparison table cover every AWS service?

No. This table only covers a representative selection of services, and their representative surfaces. The verification date is 2026-09-21. This article does not discuss any features not included in the table.

11. Summary

The term "consistent" does not refer to a single contract. AWS documentation writes three separate things around it: what the guarantee is about, whose view it is stated from, and how the caller learns that the guarantee has not arrived.

The boundaries do not align with service boundaries. Within S3, objects possess strong consistency. Bucket configurations, however, offer eventual consistency. Within IAM, reading a resource back and having that resource take effect in authorization are separate contracts. The unit of comparison is not the service. It is the surface.

The scope of a guarantee is always explicitly stated in the documentation, and it is often the first detail overlooked. A single key. A single item. A single change batch. What the next call can see. What is visible across Regions. A guarantee that does not specify its scope is not a guarantee at all.

The ways of learning about the gap come in three shapes. The gap reads as a state. It measures as a number. Or it appears only as an answer that cannot be told apart from a correct one. The three are not a ranking. They are different design choices.

In practice, the first step is to check the third axis. Does the surface being touched offer a way to ask whether it is done? If not, does the documentation specify numerical values? If that's also missing, verification for that surface has to be built another way. And an answer learned in one service does not get carried into another without being checked.

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi