🚪🔐

Amazon Cognito
Pre Sign-up Lambda トリガー

ユーザー登録の「門番」を理解しよう!

🏨 たとえ話で理解しよう

🎯 Pre Sign-up トリガー = 高級会員制クラブの「入会審査員」

🏰

会員制クラブ

入会希望者が来たら、
まず 審査員
チェックする

☁️

Amazon Cognito

ユーザー登録時に、
まず Lambda関数
チェックする

🚶 入会希望者 = サインアップするユーザー

メールアドレスやパスワードを持って、クラブ(アプリ)に入りたい人

📋 入会申込書 = サインアップリクエスト

ユーザーが入力した情報(メール、電話番号、カスタム属性など)

🕵️ 審査員 = Pre Sign-up Lambda

申込書をチェックして「OK」か「NG」か判断する人

✅ 審査基準 = Lambda内のロジック

「このドメインのメールだけOK」「この国からはNG」などのルール

📊 サインアップの流れ

1

👤 ユーザーがサインアップ開始

メールアドレス、パスワード、その他の情報を入力してサインアップボタンをクリック

⬇️
2

☁️ Cognitoがリクエストを受信

User Pool がサインアップリクエストを受け取る

⬇️
3

🚀 Pre Sign-up Lambda が呼び出される

Cognitoがユーザーを作成する 前に 、Lambda関数が実行される。ここでカスタム検証やデータ変更が可能!

⬇️
4

🔀 Lambdaの判断

✅ 許可 :サインアップ続行
❌ 拒否 :エラーを返してサインアップ中止

⬇️
5

📧 確認コード送信(許可された場合)

ユーザーにメールまたはSMSで確認コードが送信される(自動確認を設定した場合はスキップ可能)

💡 主な使用ケース

📧

メールドメイン制限

特定のドメインのメールアドレスのみ登録を許可する

例:@company.com のみ許可して、社内システムへのアクセスを制限
🌍

地域・IP制限

特定の国や地域からの登録を許可または拒否する

例:日本国内からのアクセスのみ許可するサービス

自動確認

特定条件を満たすユーザーの確認をスキップする

例:信頼済みドメインからの登録は自動で確認済みにする
🔗

外部データ検証

外部システムと照合してユーザーを検証する

例:社員DBに存在するメールアドレスのみ登録許可
🚫

使い捨てメール拒否

一時メールサービスからの登録をブロックする

例:guerrillamail.com などの使い捨てメールを拒否
🔄

ユーザー属性の変更

登録時にユーザー属性を自動的に設定・変更する

例:メールドメインに基づいてロールを自動付与

📥 イベントオブジェクトの構造

📋 Lambdaが受け取るイベント

{
  "version": "1",
  "triggerSource": "PreSignUp_SignUp",
  "region": "ap-northeast-1",
  "userPoolId": "ap-northeast-1_XXXXXXXX",
  "userName": "test-user-123",
  "callerContext": {
    "awsSdkVersion": "aws-sdk-js-2.xxx.x",
    "clientId": "1abc2defghijk3lmnop4qrst"
  },
  "request": {
    "userAttributes": {
      "email": "user@example.com",
      "phone_number": "+819012345678",
      "custom:department": "Engineering"
    },
    "validationData": { // クライアントから送られた検証用データ },
    "clientMetadata": { // クライアントから送られたメタデータ }
  },
  "response": {
    "autoConfirmUser": false,
    "autoVerifyPhone": false,
    "autoVerifyEmail": false
  }
}
triggerSource トリガーの種類。 PreSignUp_SignUp (通常)、 PreSignUp_AdminCreateUser (管理者作成)、 PreSignUp_ExternalProvider (外部IdP)など
userAttributes ユーザーが入力した属性(メール、電話番号、カスタム属性など)
validationData クライアントから送られた検証用データ(サーバー側での検証に使用)

📤 レスポンスで制御できること

✅ autoConfirmUser

ユーザーを自動的に確認済みにする

🎯 使用例

信頼済みドメイン(@company.com)からの登録は確認コード不要にする

📧 autoVerifyEmail

メールアドレスを自動的に検証済みにする

🎯 使用例

外部IdP(Google、Facebook)経由の登録時にメールを自動検証

📱 autoVerifyPhone

電話番号を自動的に検証済みにする

🎯 使用例

電話番号確認済みの外部サービスと連携している場合

🚫 サインアップを拒否する方法

Lambda関数内でエラーをスロー(throw)すると、サインアップが拒否されます

// サインアップを拒否する例
throw new Error("このメールドメインは登録できません");

// ユーザーにはこのエラーメッセージが表示されます

💻 実装例(Lambda関数)

📧 特定ドメインのみ登録を許可
例:@example.com と @example.co.jp のメールアドレスのみサインアップを許可
// Node.js Lambda 関数
exports.handler = async (event) => {
  // 許可するドメインのリスト
  const allowedDomains = ['example.com', 'example.co.jp'];
  
  // ユーザーのメールアドレスを取得
  const email = event.request.userAttributes.email;
  const domain = email.split('@')[1];
  
  // ドメインチェック
  if (!allowedDomains.includes(domain)) {
    throw new Error(`許可されていないドメインです: ${domain}`);
  }
  
  // OKの場合はeventをそのまま返す
  return event;
};
✅ 信頼済みドメインは自動確認
例:@trusted.com のユーザーは確認コード不要で即座にアカウント有効化
// Node.js Lambda 関数
exports.handler = async (event) => {
  // 信頼済みドメインのリスト
  const trustedDomains = ['trusted.com', 'partner.co.jp'];
  
  const email = event.request.userAttributes.email;
  const domain = email.split('@')[1];
  
  // 信頼済みドメインの場合は自動確認
  if (trustedDomains.includes(domain)) {
    event.response.autoConfirmUser = true;
    event.response.autoVerifyEmail = true;
  }
  
  return event;
};
🔗 外部DBと照合して検証
例:社員データベースに存在するメールアドレスのみ登録を許可
// Node.js Lambda 関数
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB.DocumentClient();

exports.handler = async (event) => {
  const email = event.request.userAttributes.email;
  
  // DynamoDBで社員データを検索
  const params = {
    TableName: 'EmployeeTable',
    Key: { email: email }
  };
  
  const result = await dynamodb.get(params).promise();
  
  // 社員データが見つからない場合は拒否
  if (!result.Item) {
    throw new Error('このメールアドレスは登録されていません');
  }
  
  // 部署情報を自動設定
  event.request.userAttributes['custom:department'] = result.Item.department;
  
  return event;
};

ベストプラクティス

✅ やるべきこと

  • 処理を高速に保つ - Lambdaのタイムアウトは5秒以内に設定(ユーザー体験のため)
  • 📝 詳細なエラーメッセージ - ユーザーに分かりやすいエラーメッセージを返す
  • 📊 ログを記録 - CloudWatch Logsで全てのリクエストを記録して監査に備える
  • 🔄 リトライ処理を考慮 - 外部APIを呼ぶ場合は適切なリトライとフォールバックを実装

❌ 避けるべきこと

  • 🐌 重い処理を入れる - 複雑な処理はPost Confirmation トリガーで行う
  • 🔓 機密情報をハードコード - APIキーなどはSecrets Managerを使用
  • 🎭 曖昧なエラーメッセージ - 「エラーが発生しました」だけでは不親切
  • 🚫 全てを拒否する設定 - テスト不足で本番環境で全ユーザーをブロックしないように注意

⚖️ 他のトリガーとの比較

トリガー タイミング 主な用途 ユーザー作成
ユーザー作成 検証、登録制限、自動確認 ❌ まだ作成されていない
Post Confirmation ユーザー確認 ウェルカムメール、初期設定 ✅ 作成済み・確認済み
Pre Authentication 認証 ログイン制限、追加検証 ✅ 作成済み

🎯 使い分けのポイント

Pre Sign-up は「この人を入会させるか?」を判断する 門番 です。
Post Confirmation は「入会完了後の手続き」を行う 事務係 です。
Pre Authentication は「毎回のログイン時にチェック」する 警備員 です。

🎓 まとめ

🚪

Pre Sign-up = 入口の門番

ユーザー登録前にチェックして、許可/拒否を決める

サーバーレス実行

Lambda関数で柔軟にカスタムロジックを実装

🔐

セキュリティ強化

ドメイン制限や外部検証でセキュリティを向上

自動確認機能

信頼済みユーザーは確認コード不要にできる

🏰 覚えておこう!

Pre Sign-up Lambda = 会員制クラブの 入会審査員
「この人を入れていいか?」を 登録前に 判断する最初の砦!

Created by SSuzuki1063

AWS SAP Learning Resources