Ну потому что там будет сколько-то записей/чтений в секунду

Кроме сколько-то никто ничего не гарантирует

Ну вам гарантируют подобие  IOPS через WCU и RCU

Да и скорость операций вполне может плавать день ото дня

Ну это тоже не совсем гарантия, это вам гарантируют выделение части виртуальных ресурсов

И то, даже емнип проц взять нельзя под это

То есть тебе дадут какие-то ресурсы, но точно. Эти ресурсы это и не как выделенный metal и не как виртуалка даже, это просто тебе с какого-то проца кусок отрежут

Вангую, что с наиболее свободного, а не с определенного типа

Лучше сначала послушать как она устроена )

https://m.youtube.com/watch?v=yvBR71D0nAQ

Окай, послушаю

Возможно я конечно и ошибаюсь, не претендую на истину

Но я в своем пет приложении уже видел разницу в скорости чтения почти в 2 раза, даже после перемещения с локалхоста в лондон сохранилась

Потом стало обратно получше

Ну это гарантия производительности, а как это уже дело AWS.

Ну вот видимо не поперло, что интересно - инстансы в том же регионе работали без таких лагов

Видимо с выделением ресурсов/сетью если живет отдельно под dynamodb были

Там ещё есть очень тонкий момент: количество партиций и как данные по ним распределены. Важно, что количество партиции обратно не уменьшается, даже есть уменьшить W(R)CU

А вот уменьшение W(R)CU при сохранении количества партиций приводит с их равномерному распределению по партициям. Как результат можно получить ситуацию: для прохождения пика вы выкрутили WRCU и произошло увеличение партиции. Данные перераспределены и все отлично, едем дальше. Пики прошли и вы уменьшаете WRCU, но теперь они размазаны по большему количеству партиций чем было до увеличения. Итог: каждая партиция теперь будет работать медленнее (будет throttled) чем раньше, те операции могут с тем же набором данных могут идти медленнее.

Надо быть аккуратнее со scaling в dynamodb. А лучше пообщаться с архитектором из AWS, которым я являюсь )

Прямо как реклама) А в доках это описано?