Open6

Cognitoあれこれ

mocknmockn

https://github.com/aws-amplify/amplify-swift/issues/2708

  • Social Loginではデバイス追跡は対応していない。
mocknmockn

GoogleやLINEアカウントを使用して作成したCognitoユーザーでデバイスの追跡はサポートされていますでしょうか。
使用しているCognitoの設定では[常に記憶する]としておりますが、ソーシャルアカウントを使用して作成されたアカウントにはログインしてもデバイスが紐づいておりませんでしたのでご質問となります。

お客様のご期待に沿えず大変恐縮ではございますが、現時点でCognitoのデバイス追跡の機能は外部IdP(例: Google、LINE等)を経由して認証されたユーザーには適用されません。
デバイス追跡機能はInitiateAuth APIでUSER_SRP_AUTH認証フローを使用したネイティブユーザーに対して適用されます[1]。
お客様が期待された回答と異なり恐縮ではございますが、現時点のデバイス追跡機能の制限についてご理解賜れますと幸いです。

■参考資料
[1] ユーザープールデバイス追跡設定の指定 - 記憶済みデバイスのセットアップ
https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/amazon-cognito-user-pools-device-tracking.html#amazon-cognito-user-pools-setting-up-remembered-devices
/===
デバイストラッキング機能を使用するには、USER_SRP_AUTH 認証フローを使用する必要があります。
===/

mocknmockn

クオータとスロットリングについて

https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/limits.html

  • 操作のクォータは、カテゴリ内のすべての操作について、1 秒あたりのリクエスト (RPS) の最大数として定義されます。
  • 月間アクティブユーザー数 (MAU) は、Amazon Cognito ユーザープールの請求の計算に使用されるベンチマークです。MAU は、ユーザープールがクォータ引き上げの対象であるかどうかを判断するためにも使用されます。

1ユーザーに対するリクエストクオータ

  • ユーザー情報の読み込み
    • 10 RPS
      • 例: GetUser、GetDevice
  • ユーザー情報の下書き込みユーザー
    • 10 RPS
    • 例: UpdateUserAttributes、SetUserSettings

APIカテゴリごとのリクエストレートクォータ

  • ユーザー認証オペレーション：UserAuthentication
    • 120 RPS
    • InitiateAuth
  • ユーザー作成/確認オペレーション：UserCreation
    • 50 RPS
    • SignUp, ConfirmSignUp
  • 外部ID プロバイダーの認証オペレーション：UserFederation
    • 25 RPS
  • アカウント回復/パスワード変更オペレーション：UserAccountRecovery
    • 30 RPS
    • ChangePassword
    • ForgotPassword
    • ConfirmForgotPassword

注意事項

UserAuthentication、UserCreation、または AccountRecovery のようなカテゴリに対して Amazon Cognito クォータを引き上げると他のサービスのクォータを引き上げる必要がある場合があります。例えば、Amazon Cognito が Amazon Simple Notification Service (Amazon SNS) または Amazon Simple Email Service (Amazon SES) で送信するメッセージは、これらのサービスでリクエストレートのクォータが不十分な場合に失敗することがあります。

クォータ要件を計算するには、特定の期間内にアプリケーションとやり取りするアクティブなユーザーの数を判断します。例えば、アプリケーションに 8 時間の期間内に平均 100 万人のアクティブユーザーによるサインインがあることを想定する場合、1 秒あたり平均 35 人のユーザーを認証できる必要があります。
さらに、平均的なユーザーセッションが 2 時間であると仮定し、トークンが 1 時間後に期限切れになるように設定している場合、各ユーザーは、セッション中にトークンを 1 回更新する必要があります。この負荷をサポートするために UserAuthentication カテゴリに必要な平均クォータは 70 RPS になります。
8 時間の期間内でのユーザーのサインイン頻度の変動を考慮して、ピーク対平均の比を 3:1 と仮定する場合、望ましい UserAuthentication クォータは 200 RPS にする必要があります。