三歩あるけば物も忘れる

DynamoDBのテーブル設計は複雑ですね、自動で行われる部分と手動でコントロールできる部分を意識した設計が必要そうです。
大体検討できたので、追加で情報があれば追記したいと思います。
異論や間違いあればコメントに・・・ぜひ

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html

DynamoDBで扱うデータによって設計が変わるので、今回は以下の条件で記載しようと思います。

以下3点について、比較したい。
・性能：スロットル(キャパシティ上限による読み/書きエラー)が発生しないこと
・運用負荷：キャパシティのモニタリングおよびモニタリング結果によるキャパシティ上限変更作業の有無
・費用：検討案ごとの月額AWS利用料金を試算する(運用費用は対象外とする)

①DynamoDBで扱うデータは、ユーザIDとトークンを管理し、プライマリーキーはユーザIDとする。
②プライマリーキー(ユーザID)はユニークな値で重複させない。(パーティションキーのみとしソートキーは利用しない、パーティションごとに均等に分散されて格納される)
③ユーザIDとトークンはそれぞれユニークな値の為、セカンダリインデックスを必要としない
④1項目(item)のサイズは1kB以下で、1つの処理では1項目(item)のみ読み書きされる想定

・テーブルイメージ

利用開始時～5年後の性能条件は以下とする。

https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb

・データは3つのAZに格納される。
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/25
・テーブルは、計算式に基づきパーティションが分割される。
・テーブルの性能(キャパシティ)はパーティション数で分割された数値がパーティションごとの性能となる。
→性能分割の仕様は変わらないが、アダプティブキャパシティーの「キャパシティの余っているパーティションのユニットを利用できる機能」により意識する必要が無くなった。
・データは3つのAZに格納され、結果的に整合性が保たれる。 (通常は 1 秒以内)
・データの書き込みは 少なくとも２つのAZでの書き込み完了が確認とれた時点で書き込み完了とみなす。
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/9
・読み込みモードは、結果整合性と強い整合性がある。
　結果整合性は、書き込みから1秒以内の読み込みでは、更新されていないデータが読み込まれることがある。
　強い整合性は、更新が反映された最新データの応答を返す。(2箇所のAZからデータを読み取り、結果が違った場合に残りのAZの値で判断)
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html

テーブルへのデータのWCU(書き込み)/RCU(読み込み)の指標として、キャパシティユニットが定義されている。
それぞれのキャパシティユニット上限値は以下の通り。

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/32

下記の計算結果のうち大きいほうでパーティション数が決まる。
・テーブルサイズを10GBで割った数値
・WCUを1000で割った数＋RCUを3000で割った数

例：
・テーブルサイズが25GB＝25/10＝2.5 → 繰り上げて3パーティション
・WCUを1500、RCUを3000＝(1500/1000)+(3000/3000)＝1.5+1=2.5 → 繰り上げて3パーティション

今回の条件を当てはめると以下のようになる。

https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/38

・パーティション数は上記計算式に基づいて、自動で拡張されるが縮小は自動で行われない。(性能試験をしたらパーティション数は増える。)
・プロビジョンドでキャパシティを縮小する場合は、拡張されたパーティション数で割った数が上限値となるため、パーティション単位の性能が落る場合がある。
→アダプティブキャパシティーの「キャパシティの余っているパーティションのユニットを利用できる機能」により意識する必要が無くなった。
※アダプティブキャパシティが有効の場合は、パーティション間でキャパシティを分け合えるため性能は落ちない。らしい
※格納するデータにもよるが、メンテナンスが可能であればキャパシティを縮小する場合はテーブルの作り直しを検討すること。

パーティションへ書き込まれるデータは、パーティションキーによって分散される
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html

スロットル(読み書きエラー)は、以下の条件で発生する。
■オンデマンド
・30 分以内に前回のトラフィックピークの 2 倍を超えると、スロットルが発生する可能性があります。
・テーブルの各パーティションで、最大 3,000 の読み取りリクエスト単位または 1,000 の書き込みリクエスト単位を超えた場合。

■プロビジョンド
・テーブルの各パーティションで、設定したキャパシティを超えた場合。
・テーブルの各パーティションで、最大 3,000 の読み取りリクエスト単位または 1,000 の書き込みリクエスト単位を超えた場合。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/on-demand-table-throttling-dynamodb/

・キャパシティの余っているパーティションのユニットを利用できる機能
・アクセス頻度の高いデータを分離する機能　※別途新規のパーティションを追加して分離する。
・アダプティブキャパシティーはすべての DynamoDB テーブルで自動的に有効化されます。追加料金はありません。
・アダプティブキャパシティーを明示的に有効化あるいは無効化する必要はない。

※「アクセス頻度の高いデータを分離する機能」は、ローカルセカンダリインデックス、プロビジョンドでDynamoDB Streamsが有効となっている場合は適用されない。

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-partitions-adaptive

下記の特徴があるが、利用者の利用頻度に左右されるので期待しない保険程度と思ったほうが良い。
・読み取りまたは書き込みアクティビティが時折バーストする間、余分なキャパシティーユニットが利用できる機能
・未使用の読み取りおよび書き込みキャパシティーは、最大 5 分 (300 秒) 保持される。
・テーブルに対して定義したスループットキャパシティーよりも高速らしい。高速？？先に使われるという意味かな・・？
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-throughput-bursting

・上限と下限値と使用率を設定して、その範囲内で設定した使用率を維持するようキャパシティユニットを変動させる機能
・Amazon CloudWatch アラームによってトリガーされるため、急なバーストには対応できない
https://aws.amazon.com/jp/premiumsupport/knowledge-center/dynamodb-auto-scaling/
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/78

結果整合性でも強い整合性でも、DynamoDBからエラーレスポンスがあることを考慮して適切なアクションを組み込んでおく。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Programming.Errors.html

・性能が高くなるにつれて、プロビジョンドの方が遥かにオンデマンドより費用が抑えられる。
・プロビジョンドのキャパシティは余裕を持たせた設計が望ましいため、費用は下記表よりも多くなります。※オンデマンドより遥かに安いのは変わらない。
・高い性能を求められるシステムに関しては、プロビジョンドで適切な運用を行いながらのチューニングが良いと思う。
・DynamoDB Streamsを有効にする場合は、オンデマンドでないとアダプティブキャパシティの恩恵が受けられない。(Kinesis Data Streams for DynamoDBであればたぶん大丈夫)
・性能が高くないシステムに関しては、運用負荷や運用対処が不要なことからオンデマンドとした方が良いと思う。
※何れの案でも、スロットルが発生してしまった場合は何かしらの対策が必要なため、ConsumedReadCapacityUnits/ConsumedWriteCapacityUnitsのモニタリングは必要

■オンデマンド

https://aws.amazon.com/jp/dynamodb/pricing/on-demand/

■プロビジョンド

https://aws.amazon.com/jp/dynamodb/pricing/provisioned/

以下の条件で費用算出した結果、リクエスト数に応じてオンデマンドの料金が爆上がりなのがわかります。
・ストレージの料金はオンデマンド、プロビジョンドとも同額のため含めていません。
・オンデマンドの1*100万単位リクエストに合わせて、プロビジョンドのキャパシティユニットを計算しています。
・書き込み数＝読み込み数として算出しています。