From the pricing page: "Note that the required number of units of Read Capacity is determined by the number of items being read per second, not the number of A

From the pricing page: "Note that the required number of units of Read Capacity is determined by the number of items being read per second, not the number of API calls." Maybe its just me but that makes this insanely expensive for almost all of my applications. I buy 50 'read units' which really means 50 rows / sec or 100 rows / sec if eventual consistency reads, as long as the row is < 1KB in size. So it costs ~$7 a month for sustained ~50-100KB/sec read speeds. I can think of several recent applications that required 100ish rows to build each view (lots of tabular data). It would seem I'd almost need 100 'read units' for every 2-3 users, more with caching obviously but that has its limits and sorta defeats the purpose of a ultra low latency store.