Forem: Matt Marks 🐣

How to add Geo Location Search with AWS Amplify and ElasticSearch

Matt Marks 🐣 — Fri, 20 Aug 2021 20:23:41 +0000

ElasticSearch is a powerful tool that allows flexible searches based on all kinds of parameters, which also happens to include geospatial data.

It just so happens that AWS Amplify supports ElasticSearch with a few commands and with a little bit of tweaking, we can modify CloudFormation to integrate Geo Locations.

I'll walk you throw how to use Amplify and GraphQL Api via AppSync to set up ElasticSearch for geo searches.

This tutorial assumes you have some familiarity with Amplify and have already initiated a project

Step 1:

Add an Establishment Type w/ @searchable directive and type GPS

type Establishment @searchable {
  gps: GPS
}

type GPS {
  lon: Float
  lat:  Float
}

Then in the terminal

$: amplify api push

(This usually takes about 15-20 minutes as its waiting for the deployment of the ElasticSearch instance)

What happens here is Amplify creates resources for your ElasticSearch instance, including a lambda function (in python) that will process data from a DynamoDB stream and insert the data into ElasticSearch.

If you're unfamiliar with DynamoDB streams, they're notifications/callbacks that occur when records are created, updated or deleted. These streams can trigger multiple AWS services, including Lambda

If your curious about the python function Amplify creates in order to insert data in ElasticSearch, go unzip the file here : amplify/api/your-api-name/build/functions/ElasticSearchStreamingLambdaFunction.zip

Step 2

Update Access Policy for ElasticSearch / Kibana

Go to the ElasticSearch console in AWS and click Modify Access Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:<AWS-ACCOUNT-ID>:domain/amplify-elasti-fw023i2ikk3/*"
    }
  ]
}

🚨 WARNING 🚨

This will grant full access to ANYONE and this should only be used in the development process. For this project, I'll scope these permission down to my auth/unauth roles from Cognito and IAM afterwards.

After

 {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWS-ACCOUNT-ID>:role/amplify-restaurantreviewapp-dev-000000-authRole"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:<AWS-ACCOUNT-ID>:domain/amplify-elasti-w023i2ikk3/*"
    }

Step 3:

Create ElasticSearch mappings for Geo Coordinates

In order to search by coordinates in ElasticSearch, we have to tell it specifically which fields from our DB are considered geo_point, so that it can index them to be queried by lat, lon.

There's a couple ways you can add this mapping to our ElasticSearch index, including directly from the Kibana Console. The problem with adding our mapping directly in Kibana is that it can be overwritten after deployments, forcing us to manually add our geo_point after each new build.

There's a 100% chance I would forget to do that some point 😳

Instead, we're going to add a post deployment lambda to our amplify/backend/api/your-api-name/stacks/CustomResources.json.

Add the following to the Resources block: gist here

Inside that gist, you'll see an inline python function under ConfigureES. The important line to notice here is:

action = {\"mappings\": {\"doc\": {\"properties\": {\"gps\": {\"type\": \"geo_point\"}}}}}"

This will create a mapping for a field from DynamoDB called gps that takes a geo_point type value, which is lat, lon.

Now it's time to deploy our new lambda function, so run

$: amplify api push

Before we go any further, I have to give a lot of credit to
Ramon Postulart and his commentor Ross Williams in this article on Geo Search with Amplify. Ross's comment in this article was the inspiration and base for the code I shared in the gist, so thanks to the both of you 🙏🏻

Step 4:

Create Query findEstablishments and attach the ElasticSearch data source in CustomResources along with VTL templates

When we added the @searchable directive in Step 1, Amplify created a Query called searchEstablishments, which is awesome for keyword searching values or doing calculations or other search combinations. It won't have the logic for searching by gps though, so we have to add it manually by creating a Query called findEstablishments

Add the to your schema.graphql:

type Query {
  findEstablishments(
    input: FindEstablishmentsInput!
  ): SearchableEstablishmentConnection @aws_iam @aws_cognito_user_pools
}

type GPS {
  lon: Float
  lat: Float
}

input GPSInput {
  lon: Float!
  lat: Float!
}

input GPSQueryInput {
  gps: GPSInput!
  radius: Float!
}

input FindEstablishmentsInput {
  byGPS: GPSQueryInput
  byPlaceID: String
  limit: Int
  nextToken: String
  from: Int
}

type SearchableEstablishmentConnection @aws_iam @aws_cognito_user_pools {
  items: [Establishment]
  nextToken: String
  total: Int
}

Next we need to go back to our CustomResources.json and add a resolver for findEstablishments that's attached to ElasticSearch

"FindEstablishmentsResolver": {
      "Type": "AWS::AppSync::Resolver",
      "Properties": {
        "ApiId": {
          "Ref": "AppSyncApiId"
        },
        "DataSourceName": "ElasticSearchDomain",
        "FieldName": "findEstablishments",
        "TypeName": "Query",
        "RequestMappingTemplateS3Location": {
          "Fn::Sub": [
            "s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers/${ResolverFileName}",
            {
              "S3DeploymentBucket": {
                "Ref": "S3DeploymentBucket"
              },
              "S3DeploymentRootKey": {
                "Ref": "S3DeploymentRootKey"
              },
              "ResolverFileName": {
                "Fn::Join": [".", ["Query", "findEstablishments", "req", "vtl"]]
              }
            }
          ]
        },
        "ResponseMappingTemplateS3Location": {
          "Fn::Sub": [
            "s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers/${ResolverFileName}",
            {
              "S3DeploymentBucket": {
                "Ref": "S3DeploymentBucket"
              },
              "S3DeploymentRootKey": {
                "Ref": "S3DeploymentRootKey"
              },
              "ResolverFileName": {
                "Fn::Join": [
                  ".",
                  ["Query", "searchEstablishments", "res", "vtl"]
                ]
              }
            }
          ]
        }
      }
    },

The ElasticSearch data source ("DataSourceName": "ElasticSearchDomain") was created for us by @searchable directive, so we're just referencing it by name.

If you looked carefully, you'll see I used ["Query", "searchEstablishments", "res", "vtl"] for the response mapping template, instead of ["Query", "findEstablishments", "res", "vtl"]. Amplify already generated an appropriate response template for ElasticSearch with searchEstablishments, so instead of writing it again, we're pointing to the searchEstablishments response.

Next up, we need to create our resolver template for findEstablishments. Create a file at amplify/api/<your-api-name>/resolvers/Query.findEstablishments.req.vtl and add the following:

#set( $indexPath = "/establishment/doc/_search" )

#set($query = {
  "bool": {

  }
})

#set($sort = [])

#if (!$util.isNull($context.args.input.byGPS ))
  $util.qr($query.bool.put("must", {"match_all" : {}}))
  $util.qr($query.bool.put("filter", {
    "geo_distance": {
      "distance": "${context.args.input.byGPS.radius}km",
      "gps": $context.args.input.byGPS.gps
    }
  }))

  $util.qr($sort.add({
    "_geo_distance":  {
      "gps":  $context.args.input.byGPS.gps,
      "order": "asc",
      "unit": "mi", 
      "distance_type": "plane" 
    }
  }))
#end


#if (!$util.isNull($context.args.input))
  #set($from = $util.defaultIfNull($context.args.input.nextToken, 0))
  #set($size = $util.defaultIfNull($context.args.input.limit, 20))
#else
  #set($from = 0)
  #set($size = 20)
#end

{
  "version":"2017-02-28",
  "operation":"GET",
  "path":"$indexPath",
  "params":{
    "body": {
      "from": $util.toJson($from),
      "size": $util.toJson($size),
      "query": $util.toJson($query),
      "sort": $util.toJson($sort)
    }
  }
}

Okay, let's give it a push

$: amplify api push

Step 5:

Searching Locations

Now that we have a Query called findEstablishments that's attached to ElasticSearch, let's test it out. First, we need to create an Establishment with gps data.

mutation {
  createEstablishment(input:{
    id:"test-restaurant",
    name: "Test Raustaurant",
    gps:{
      lat: 41.88337459649123,
      lon: -87.69204235097645
    }
  }) {
    id
    gps {
      lat
      lon
    }
  }
}

Next, we need to query byGPS (Radius is in kilometers):

query {
  findEstablishments(input:{
        byGPS:{
        gps: {lat: 41.86260812331178, lon: -87.79148237035405},
      radius:10
    }
  }) {
    items {
      id
      gps {
        lat
        lon
      }
    }
  }
}

And drumrollllllll please, the final results:

{
  "data": {
    "findEstablishments": {
      "items": [
        {
          "id": "cc7ea996-1568-4ef7-a640-bd4136eb88f9",
          "gps": {
            "lat": 41.88337459649123,
            "lon": -87.69204235097645
          }
        }
      ]
    }
  }
}

That's right, we got ourselves a Geo Location search with AWS Amplify and ElasticSearch working y'all, give yourself a pat on the back!

Hope you enjoyed this tutorial and for more Amplify and Serverless content, follow me on twitter @andthensumm

Direct Lambda Resolvers with AWS Amplify and AppSync

Matt Marks 🐣 — Wed, 12 Aug 2020 22:43:40 +0000

How I feel about VTL on any given day

Haha okay, okay. I'm just kiddin' (mostly).

AWS recently announced Direct Lambda Resolvers support, which means you can write AppSync resolvers in your favorite Lambda runtimes without relying on the Velocity Template Language.

I wanted to take advantage of this, as I had some complicated logic that that I didn't know how to write with VTL and it was much easier to do with javascript. I'll share with you how I added Direct Lambda Resolvers to an Amplify project with a little magic from the @function directive.

I'm gonna assume you've already created a GraphQL API for
your Amplify project. If you haven't, follow the steps here on how to Create a GraphQL API

Step 1: Create a Lambda with Amplify cli

amplify add function
? Provide a friendly name for your resource to be used as a label for this category in the project: DirectLambdaResolver
? Provide the AWS Lambda function name: DirectLambdaResolver
? Choose the function runtime that you want to use: NodeJS
? Choose the function template that you want to use: Hello World
? Do you want to access other resources created in this project from your Lambda function? No
? Do you want to invoke this function on a recurring schedule? No
? Do you want to edit the local lambda function now? Yes

Go to amplify/backend/function/DirectLambdaResolver/src/index.js and update it with the following:

let response;

exports.handler = async (event, context) => {
    console.log({event, context})
    try {
        response = "this lambda is super direct"
    } catch (err) {
        console.log({err})
        console.log(err);
        return err;
    }

    return response
};

Alright, save the file and press enter in the terminal to continue.

Step 2: Auto-generate code with `@function` and copy code to CustomResources.json

Now we're gonna go to amplify/backend/api/[your-api-name]/schema.graphql and take advantage of the @function directive

### schema.graphql
type Todo @model {
  id: ID
  task: String @function(name: "DirectLambdaResolver-${env}")
}

then

$: amplify api gql-compile

This will create all the files inside amplify/backend/api/[your-api-name]/build/. What we're looking for is the file FunctionDirectiveStack.json. Open it up and you'll see the following:

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "An auto-generated nested stack.",
    "Metadata": {},
    "Parameters": {
      ...
    },
    "Resources": {
      // IAM Role
      "DirectLambdaResolverLambdaDataSourceRole": {
         ...
      },
      // DataSource
      "DirectLambdaResolverLambdaDataSource": {
         ...
      },
      // Direct Lambda Resolver
      "InvokeDirectLambdaResolverLambdaDataSource": {
         ...
      },
      // Pipeline Resolver
      "TodotaskResolver": {
         ...
      }
    }

When amplify auto-generates with @function, it creates a Lambda DataSource, an IAM Role for that DataSource, the Direct Lambda Resolver and a Pipeline Resolver.

We're going to copy everything from the Resources object and paste it in our CustomResources.json file located at amplify/backend/api/[your-api-name]/stacks/. It should now look like the following:

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "An auto-generated nested stack.",
  "Metadata": {},
  "Parameters": {
     ...
  },
  "Resources": 
    "DirectLambdaResolverLambdaDataSourceRole": {
      ...
    },
    "DirectLambdaResolverLambdaDataSource": {
      ...
    },
    "InvokeDirectLambdaResolverLambdaDataSource": {
      ...
    },
    "TodotaskResolver": {
      ...
    }
  },
  "Conditions": {
    ...
  },
  "Outputs": {
    ...
  }
}

We also need to update our DirectLambdaResolverLambdaDataSourceRole to replace GetAttGraphQLAPIApiId with AppSyncApiId

"DirectLambdaResolverLambdaDataSourceRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "RoleName": {
          "Fn::If": [
            "HasEnvironmentParameter",
            {
              "Fn::Join": [
                "-",
                [
                  "DirectLambdaResolver774c",
                  {
                    "Ref": "AppSyncApiId" // Used to be GetAttGraphQLAPIApiId
                  },
                  {
                    "Ref": "env"
                  }
                ]
              ]
            },
            {
              "Fn::Join": [
                "-",
                [
                  "DirectLambdaResolver774c",
                  {
                     "Ref": "AppSyncApiId" // Used to be GetAttGraphQLAPIApiId
                  }
                ]
              ]
            }
          ]
        },
        "AssumeRolePolicyDocument": {
         ...
        },
        "Policies": [
          ...
        ]
      }
    },

Next up, in order to make our new Lambda a Direct Lambda Resolver with AppSync, we'll need to remove the request and response mapping templates from our function InvokeDirectLambdaResolverLambdaDataSource. They're nested inside the Properties object

"InvokeDirectLambdaResolverLambdaDataSource": {
  "Type": "AWS::AppSync::FunctionConfiguration",
  "Properties": {
    "ApiId": {
        "Ref": "AppSyncApiId"
    },
    "Name": "InvokeDirectLambdaResolverLambdaDataSource",
    "DataSourceName": "DirectLambdaResolverLambdaDataSource",
    "FunctionVersion": "2018-05-29",
    // REMOVE ME 
    "RequestMappingTemplateS3Location": {
      ...
    },
    // REMOVE ME 
    "ResponseMappingTemplateS3Location": {
      ...
    }
  },

  "DependsOn": "DirectLambdaResolverLambdaDataSource"
}

We'll also need to copy Todo.task.req.vtl and Todo.task.res.vtl from amplify/backend/api/[your-api-name]/build/resolvers to amplify/backend/api/[your-api-name]/resolvers.

Wait a minute. I thought we said no more VTL? What gives?
TodotaskResolver is a Pipeline Resolver. InvokeDirectLambdaResolverLambdaDataSource is our Direct Lambda Resolver.

Don't wan't a Pipeline resolver? Don't worry, I got you covered towards the end 😉

Step 3: Remove autogenerated code

Remember how we added @function(name: "DirectLambdaResolver-${env} directive in our task: String field within our schema.graphql? We need to remove all the generated code, including FunctionDirectiveStack.json.

Luckily that's pretty easy. Just remove the @function and run:

$: amplify api gql-compile

If you look inside amplify/backend/api/[your-api-name]/build/, you'll see our updated CustomResources.json file and that the FunctionDirectiveStack.json has been removed.

Puh-push it real good

$: amplify push

If you go to your AppSync console, click on schema and search Todo inside the Resolvers search field, and scroll down to task and it should say Pipeline. Click on it and it will take you to the Todo.task Pipeline Resolver with your DirectLambdaResolver listed. Notice the mapping templates disabled?

Yeaaa buddy, no more VTL (kind of) 😆 😆 😆

Bonus Round: Remove Pipeline Resolver

As I promised earlier, if you want to get rid of the Todo.task Pipeline Resolver, we need to make two changes inside amplify/backend/api/[your-api-name]/stacks/CustomResources.json.

First, delete TodotaskResolver.
Second, replace your InvokeDirectLambdaResolverLambdaDataSource with the following:

"TodotaskDirectLambdaResolver": {
  "Type": "AWS::AppSync::Resolver",
  "Properties": {
    "ApiId": {
        "Ref": "AppSyncApiId"
    },
    "DataSourceName": "DirectLambdaResolverLambdaDataSource",
    "TypeName": "Todo",
    "FieldName": "task"
  },

  "DependsOn": "DirectLambdaResolverLambdaDataSource"
}

$: amplify api push

Now, go forth and banish VTL templates at will!

I hope you enjoyed this post and if you did, follow me on twitter for all things AWS Amplify, AppSync, and React-Native 🙌 🙌 🙌
https://twitter.com/andthensumm

Resources:
Add a custom resolver that targets an aws lambda
How to add pipelineResolvers - Github Issue

Enforcing attribute uniqueness in Cognito with AWS Amplify and React

Matt Marks 🐣 — Wed, 27 May 2020 16:27:23 +0000

In this walkthrough, you'll learn how create a PreSignUp Lambda for Cognito in AWS Amplify. When a user signs up with email as an optional attribute, we'll fire up our PreSignUp trigger to search Cognito for users who already signed up with that email attribute.

What you need to get started

That's it, Lezzzgo!

$  npx create-react-app pre-signup
$  cd pre-signup
$  yarn add aws-amplify
$  yarn add aws-amplify-react

Next we'll intialize amplify

$  amplify init
? Enter a name for the project: presignup
? Enter a name for the environment: dev
? Choose your default editor: Visual Studio Code
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using react
? Source Directory Path:  src
? Distribution Directory Path: build
? Build Command:  npm run-script build
? Start Command: npm run-script start
Using default provider  awscloudformation

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use: default

After initializing our project, we'll add authentication. When we run amplify add auth we'll do a manual configuration so that we can add our pre-signup trigger. Use the same configurations I've listed below.

$  amplify add auth
 Do you want to use the default authentication and security configuration? Manual configuration
 Select the authentication/authorization services that you want to use: User Sign-Up, Sign-In, connected with AWS IAM controls 
 (Enables per-user Storage features for images or other content, Analytics, and more)
 Please provide a friendly name for your resource that will be used to label this category in the project: presignup9aa404bb9aa404bb
 Please enter a name for your identity pool. presignup9aa404bb_identitypool_9aa404bb
 Allow unauthenticated logins? (Provides scoped down permissions that you can control via AWS IAM) No
 Do you want to enable 3rd party authentication providers in your identity pool? No
 Please provide a name for your user pool: presignup9aa404bb_userpool_9aa404bb
 Warning: you will not be able to edit these selections. 
 How do you want users to be able to sign in? Email and Phone Number
 Do you want to add User Pool Groups? No
 Do you want to add an admin queries API? No
 Multifactor authentication (MFA) user login options: OPTIONAL (Individual users can use MFA)
 For user login, select the MFA types: (Press <space> to select, <a> to toggle all, <i> to invert selection)SMS Text Message
 Please specify an SMS authentication message: Your authentication code is {####}
 Email based user registration/forgot password: Disabled (Uses SMS/TOTP as an alternative)
 Please specify an SMS verification message: Your verification code is {####}
 Do you want to override the default password policy for this User Pool? No
 Warning: you will not be able to edit these selections. 
 What attributes are required for signing up? 
 Specify the app's refresh token expiration period (in days): 30
 Do you want to specify the user attributes this app can read and write? Yes
 Specify read attributes: Email, Phone Number, Preferred Username, Email Verified?, Phone Number Verified?
 Specify write attributes: Email, Phone Number, Preferred Username
 Do you want to enable any of the following capabilities? (Press <space> to select, <a> to toggle all, <i> to invert selection)
 Do you want to use an OAuth flow? No
? Do you want to configure Lambda Triggers for Cognito? Yes
? Which triggers do you want to enable for Cognito Pre Sign-up
? What functionality do you want to use for Pre Sign-up Create your own module
Succesfully added the Lambda function locally
? Do you want to edit your custom function now? Yes
Please edit the file in your editor: Desktop/pre-signup/amplify/backend/function/presignup9aa404bb9aa404bbPreSignup/src/custom.js
? Press enter to continue 
Successfully added resource presignup9aa404bb9aa404bb locally

Whooooakay, still with me 😅

Now we're gonna dive into the fun stuff!

In the prompt above, it will ask you if you'd like to edit your function. It will open up the custom.js file at /amplify/backend/function/<lambda-name>/custom.js. At this point you can delete the custom file and add the following code to /amplify/backend/function/<lambda-name>/index.js

exports.handler = async (event, context, callback) => {
  console.log({event}, event.request, event.request.userAttributes)
  callback(null, event)
}

A little side note
With a PreSignUp trigger, we must return the original event back to Cognito after we add our custom logic. To demonstrate this, we’re going to deploy the code below with some console.logs of the event data, so you can see what to expect.

$  amplify push

While that's deploying our resources to the cloud, let's add some Amplify Auth configurations to App.js

import React from "react";
import Auth from "@aws-amplify/auth";
import { withAuthenticator } from "aws-amplify-react";

import config from "./aws-exports";

Auth.configure(config);

const App = (props) => {
  return (
    <div style={{ color: "white", fontSize: 13}}>
      Wooohoooo, Succcessfully signed up user with username
    </div>)
};

  export default withAuthenticator(App, {
  signUpConfig: {
    signUpFields: [{ key: 'phone_number', required: false }]
  }
});

After amplify push is finished, run yarn start

You'll be presented with a SignIn screen. Click create account and sign up with the following credentials (do not fill in phone number field, fill in username as phone number)

Username: +1111111111
Password: Password1@
Email: example@example.com

If you're presented with the Confirm Sign Up page, congratulations! Our PreSignUp Lambda forwarded the event correctly and Cognito was able to continue with SignUp. Now try signing up again, but this time with the following credentials:

Username: +2222222222
Password: Password1@
Email: example@example.com

Ahhh, just as we expected. Cognito allowed us to sign up with the same email when used as an optional attribute. Cognito is only enforcing uniqueness for username, which is a phone number.

I would take this time to check the cloudwatch logs for your lambda as we'll be using the event data for something later 😉 (hint, hint: quick way to find the logs is to find your presignup lambda inside the lambda console, click on monitoring, then view in cloudwatch)

What our logs should look like:

2020-03-02T20:37:56.850Z    d740d6f7-71be-4634-a36b-23d916e1cdb9    INFO    
{ event:
   { version: '1',
     region: 'us-east-1',
     userPoolId: 'us-east-1_HQBTO8LlF',
     userName: '5f1fa3d5-acfe-4e65-80b0-7e5753c83c25',
     callerContext:  { 
       awsSdkVersion: 'aws-sdk-unknown-unknown',
       clientId: '2b7j54vvm9a7c1inqum0nkq4v' 
     },
     triggerSource: 'PreSignUp_SignUp',
     request: { 
       userAttributes:  { 
         phone_number: '+11111111111', 
         email: 'example@example.com' 
       },
       validationData: null 
      },
      response: { 
        autoConfirmUser: false,
        autoVerifyEmail: false,
        autoVerifyPhone: false 
      } 
   } 
}

Now we've seen the problem in action, we're going to add the code for our PreSignUp lambda. It will looks for users with email that matches the one from provided from user signup. Replace the code at /amplify/backend/function/<lambda-name>/index.js with the following:

const AWS = require('aws-sdk');
AWS.config.region = 'us-east-1';

const identity = new AWS.CognitoIdentityServiceProvider();

exports.handler = async (event, context, callback) => {
  if (event.request.userAttributes.email) {
    const {email} = event.request.userAttributes
    const userParams = {
      UserPoolId: event.userPoolId,
      AttributesToGet: ['email'],
      Filter: `email = \"${email}\"`,
      Limit: 1,
    };
    try {
      const {Users} = await identity.listUsers(userParams).promise();
      console.log({Users})
      if (Users && Users.length > 0) {
          callback('EmailExistsException', null);
      } else {
        callback(null, event);
      }
    } catch (error) {
      console.log({error}, JSON.stringify(error))
      callback({error}, null);
    }
  } else {
    callback('MissingParameters', null);
  }
};

What's happening here is that we're making a request for all users in our user pool and filtering it down to users with the email we've provided. If a user exists, we return EmailExistsException error message.

Protip: With Amplify, we can test our functions locally 🤯

Remember those cloudwatch logs from earlier? They're about to come in handy. Copy the event data into /amplify/backend/function/<lambda-name>/events.json

{
  "version": "1",
  "region": "us-east-1",
  "userPoolId": "us-east-1_HQBTO8LlF",
  "userName": "5f1fa3d5-acfe-4e65-80b0-7e5753c83c25",
  "callerContext": {
    "awsSdkVersion": "aws-sdk-unknown-unknown",
    "clientId": "2b7j54vvm9a7c1inqum0nkq4v"
  },
  "triggerSource": "PreSignUp_SignUp",
  "request": {
    "userAttributes": {
      "phone_number": "+1111111111",
      "email": "example@example.com"
    },
    "validationData": null
  },
  "response": {
    "autoConfirmUser": false,
    "autoVerifyEmail": false,
    "autoVerifyPhone": false
  }
}

Run the following from your terminal

$  amplify function invoke <your-lambda-name>

Niiiiiiiice. Although our lambda works locally, it will need permissions to call Cognito:Identity-ServiceProvider.listUsers() when it's deployed. We're gonna step into our lambda's cloudformation template and add a Policy. Go to /amplify/backend/function/<lambda-name>/<lambda-name>-cloudformation-template.json

Nested under "Resources" you'll see the following:

"LambdaExecutionRole": {
  "Type": "AWS::IAM::Role",
  ...
},
"lambdaexecutionpolicy": {
  "DependsOn": [
    "LambdaExecutionRole"
   ],
  "Type": "AWS::IAM::Policy",
  ...
}

We're going to add a policy between the existing role and policy


"LambdaExecutionRole": {
  "Type": "AWS::IAM::Role",
  ...
},
"lambalistuserspolicy": {
  "DependsOn": [
    "LambdaExecutionRole"
  ],
  "Type": "AWS::IAM::Policy",
  "Properties": {
    "PolicyName": "lambda-list-users-policy",
    "Roles": [
      {
        "Ref": "LambdaExecutionRole"
      }
    ],
    "PolicyDocument": {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "cognito-idp:ListUsers"
          ],
          "Resource": {
            "Fn::Sub": [
              "arn:aws:cognito-idp:${region}:${account}:userpool/us-east-1_HQBTO8LlF",
              {
                "region": {
                  "Ref": "AWS::Region"
                },
                "account": {
                  "Ref": "AWS::AccountId"
                }
              }
            ]
          }
        }
      ]
    }
  }
},
"lambdaexecutionpolicy": {
  "DependsOn": [
    "LambdaExecutionRole"
   ],
  "Type": "AWS::IAM::Policy",
  ...
}

Now it's time to deploy our pride and joy 🥳

amplify function push

Let's try signing up with any username and an email of example@example:

Ohhhh, the sweet, sweet taste of a fully functioning PreSignUp lambda that enforces email uniqeuness 🙌 🙌 🙌 🙌 🙌 🙌

To learn more about the resources used in this walkthrough, check out the following:
Cognito List Users
Amplify Authentication
Pre Sign-up Lambda Trigger

Follow me on Twitter @andthensumm