シンプルな会議アプリケーション（DynamoDB？）のAWSバックエンドアーキテクチャのセキュリティと効率

私は、各ユーザーが1人または複数のFacebook友人にミーティング招待状を送ることができる簡単なアプリケーション（IOS）を構築しています。会議は、日付、場所、関係者のグループから成り立っています（Facebookはイベントのために何をしているのか何とか再現しています）。私はバックエンドにAWSを使用することにしましたが、これは単純で古典的なユースケースと思われますが、私は効率的で安全なソリューションを考えることはできません。以下では、今まで私がバックエンドを構築した方法を公開し、私が考えることができる弱点のいくつかを指摘します。シンプルな会議アプリケーション（DynamoDB？）のAWSバックエンドアーキテクチャのセキュリティと効率

私はhereの理由でCognitoではなくFacebookでWeb Identity Federationを使用しています。主キーがユーザーのFacebook IDである私のすべてのユーザー（これは、Amazon documentに触発されています）に固有のDynamoDBテーブルを使用します。各ユーザーは、自分のFacebook IDに対応する行のみを照会して取得することができますが、必要な主キーを使用して行を書き込むことができます。ここで

は、私が作成した役割に添付IAMポリシーです：

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Effect": "Allow", 
      "Action": [ 
       "dynamodb:GetItem", 
       "dynamodb:Query" 
      ], 
      "Resource": [ 
       "arn:aws:dynamodb:eu-west-1:528570751657:table/Meetings", 
       "arn:aws:dynamodb:eu-west-1:528570751657:table/Meetings/index/*" 
      ], 
      "Condition": { 
       "ForAllValues:StringEquals": { 
        "dynamodb:LeadingKeys": [ 
         "${graph.facebook.com:id}" 
        ] 
       } 
      } 
     }, 
     { 
      "Effect": "Allow", 
      "Action": [ 
       "dynamodb:PutItem" 
      ], 
      "Resource": [ 
       "arn:aws:dynamodb:eu-west-1:528570751657:table/Meetings", 
       "arn:aws:dynamodb:eu-west-1:528570751657:table/Meetings/index/*" 
      ] 
     } 
    ] 
}

それが実際にどのように機能するか

：のは、FacebookのID 1001を持つユーザーは、のうちの2つにミーティングの招待状を送信したいとしましょうこれを行うために、彼女は、同一の行の3回、同じ会議情報を書きますが、3つの異なるプライマリキー、1001,1002、および1003を使用します。その後、各ユーザは、彼女はDynamoDB（クエリ要求）と同期しながらテーブルから取得できます。私は考えることができる

問題：次善のストレージ管理：