A developer reads items of 3 KB each from a DynamoDB table using GetItem. The table is in provisioned capacity mode, and the developer must size read capacity correctly. One requirement allows eventually consistent reads, while a separate latency-sensitive path on the same table needs strongly consistent reads of the same item size. How does the read capacity unit cost differ between the two read types for these items?
- AAn eventually consistent read of the 3 KB item costs one read unit, and a strongly consistent read of the same item costs two read units, so the eventual read is the cheaper option.
- BBoth read types cost the same one read unit for the 3 KB item, because read consistency changes only the latency of the response and never the read unit accounting at all.
- CAn eventually consistent read of the 3 KB item costs half a read unit, and a strongly consistent read of the same item costs one read unit, so the strong read costs twice as much. Correct
- DAn eventually consistent read of the 3 KB item costs two read units, and a strongly consistent read of the same item costs one read unit, so the strong read is the cheaper option.
Why A is wrong: This doubles both figures, since a strong read of an item up to 4 KB costs one unit and an eventual read costs half a unit, not two units and one unit respectively.
Why B is wrong: Consistency does affect cost here, because an eventual read is billed at half the unit cost of a strong read for the same item, so the two read types are not equal.
Why C is correct: A strong read of an item up to 4 KB costs one whole read unit and an eventual read of the same item costs half a unit, so for this 3 KB item the strong read costs twice the eventual read.
Why D is wrong: This inverts the relationship, since the strong read is the more expensive type at one unit per 4 KB while the eventual read costs only half a unit, not the reverse.