serverless-application-model: The event source and function provided mapping already exists. Please update or delete the existing mapping with UUID

I also ran into and fixed this by calling aws lambda list-event-source-mappings to find the orphaned mapping then aws lambda delete-event-source-mapping --uuid {uuid} to remove it

For future Googlers: I had this issue, and it was because there was a manually-created trigger hanging around that wasn’t deleted with my stack. Using the CLI to delete by UUID, or going to SQS -> the queue -> Lambda triggers should have let me find it.

2 and half years later and still running into that problem. With a Lambda with an event source mapping in a SAM template. simply adding a layer to the lambda triggered this error. I am sure doing a lot of ClickOps today for something that is supposedly IAC.

I was able to execute the following manually, then the corresponding CloudFormation template succeeded:

UUID=$(aws lambda list-event-source-mappings --function-name HotDogs --query 'EventSourceMappings[0].UUID' --output text 2>/dev/null)
aws lambda delete-event-source-mapping --uuid "$UUID"

However, I would advocate that the bug be resolved internally with AWS engineers. That way we don’t have to do one-off scripts/commands to ensure something expected to work correctly, actually works.

Thanks all for the input, very informative.

I’m able to reproduce this with a pure CloudFormation template:

Resources:
  MyTable:
    Type: AWS::DynamoDB::Table
    Properties:
      BillingMode: PAY_PER_REQUEST
      KeySchema:
        - AttributeName: MyAttribute
          KeyType: HASH
      AttributeDefinitions:
        - AttributeName: MyAttribute
          AttributeType: S
      StreamSpecification:
        StreamViewType: KEYS_ONLY
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      Runtime: python3.8
      Handler: index.handler
      Role: !GetAtt MyFunctionRole.Arn
      Code:
        ZipFile: |
          def handler(event, context):
              return {'body': 'Hello World!', 'statusCode': 200}
  MyFunctionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action:
              - sts:AssumeRole
            Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
        Version: "2012-10-17"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole
  MyFunctionMyTableEvent:
    Type: AWS::Lambda::EventSourceMapping
    Properties:
      EventSourceArn: !GetAtt MyTable.StreamArn
      FunctionName: !Ref MyFunction
      StartingPosition: TRIM_HORIZON

That template will deploy fine.

But as @MatteoGioioso mentioned, if you change StartingPosition from TRIM_HORIZON to LATEST and deploy again, you’ll get the error:

The event source arn ([...]) and function ([...]) provided mapping already exists. Please update or delete the existing mapping with UUID [...]

Please fix, same issue here!

The issue also happens with AWS CDK (v1.134.0) generated CloudFormation templates. When the Lambda event source is a SQS queue.

Ok, this is a long standing bug with Cloudformation. Similar happening with Kinesis and it was already spotted in 2018 on the serverless framework. This is a minimal reproducible case with kinesis: https://github.com/MatteoGioioso/sls-event-source-mapping-bug You just need to change startingPosition from TRIM_HORIZON to LATESTto trigger the bug.

Use the aws cli as: aws lambda delete-event-source-mapping to delete the uuid that is “broken” then re-apply the cloud formation stack See: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-event-source-mapping.html

@hoffa I’m hitting the same. Can you please re-open and publish the status from “I’ve routed this issue internally.” ?

I also ran into and fixed this by calling aws lambda list-event-source-mappings to find the orphaned mapping then aws lambda delete-event-source-mapping --uuid {uuid} to remove it

I also faced this issue while deploying the Terraform code 2nd time. Do we need to get rid of existing mapping everytime we make any change related to mapping ?

Hit the issue same day trying to update the kinesis source mapping settings.