AmplifyでAppSync + Lambdaによってmutation createUserする際の最適解について

Question

以下の手順でユーザーの新規登録時に情報をDynamoDBに書き込む際の最適解についておたずねしたく思います。

1. クライアントサイドからAmplify.Auth.signUp()でサインアップを実行する
2. PostConfirmation Lambda Triggerによってmutation createUserを行う関数が実行される

作成されたユーザーは以下の情報を持ちます。

フィールド名	書き込まれる内容	読み取り権限
id	識別子	全ユーザー（ユーザープールへのログインを問わない）
firstName	姓	本人のみ
lastName	姓	本人のみ
nickname	識別子	全ユーザー（ユーザープールへのログインを問わない）

また、以下の場合においてIAM認証を用います

• Lambdaからmutation createUserを実行する際
• アカウントを持たない（Cognitoユーザープールにログインしていない）閲覧者が登録されたユーザーのidとnicknameを参照する際

この場合、恐らくスキーマは以下のようになると思います。

type User
  @model
  @auth(rules: [
    { allow: public, provider: iam },
    { allow: owner, ownerField: "id", operations: [read, update] }
  ])
{
  id: ID!
  firstName: String!
  @auth(rules: [{ allow: owner, ownerField: "id" }])
  lastName: String!
  @auth(rules: [{ allow: owner, ownerField: "id" }])
  nickname: String!
}

ここで一点疑問があります。
Lambdaからmutation createUserを実行するためIAM認証は必要不可欠ですが、それは同時に一般ユーザーも同じIAM権限を使ってUserに対しCRUDを行えてしまうということになります。
これは明らかに設計として不自然なので行うべきではないと思うのですが、このような場合には一般的にどういった対応を行うのが正解でしょうか。

---

ちなみに以下の対応も考えましたが、いずれも後述する理由からなるべく採用したくないと思っています。

DynamoDBClientを使って直接書き込みを行う

• _version lastChangedAt _deletedなどAmplify側で自動生成された属性値を手動で書き込む必要が出てくる

Cognitoのカスタム属性を用いる

• 一度作成したカスタム属性が削除できなくなる
• Userだけでなく他のモデルでも起こりうることなので一時しのぎにしかならない

Answer 1

自己解決しました。
LambdaからAppSyncを呼び出す際はallow: privateが適用され、それ以外のユーザーに関してはallow: publicが適用されるため、それぞれで必要なoperationsのみ記述する形で対応することが可能でした。

@auth(
  rules: [
    { allow: private, provider: iam, operations: [create] },
    { allow: public, provider: iam, operations: [read] }
  ]
)