Difficulties Reusing UserPool

[rpattcorner]

Having some problems reusing a userpool in a migration scenario.

@ottokruse For context, we have existing installations with a V1 auth@edge backend. I've read the advice that migrating from v1 to v2 is discouraged if not unfeasible, but we have existing application installations using v1 infrastructure with substantial artifacts we need to preserve.

We have no problem creating new installations with a@e v2, but manual migration of the artifacts is difficult and error prone and we're looking to future-proof for other breaking changes.

Our migration strategy is:

• CloudFormation Export key artifacts from our existing stacks, most importantly the UserPool itself with its users, and a wide range of application specific artifacts
• Build a new v2 installation CFN template that imports the above artifacts with a cross-stack import, and then:
  • Creates its own CognitoApplication Client on the imported UserPool
  • Creates its own Cloudfront and related artifacts
  • Invokes auth@edge v2.x with references to the original user pool and existing client

The only change I've made is to remove the DependsOn: UserPoolDomain because it was created in the exporting stack and is guaranteed to exist.

The relevant invocation of a@e looks like:

  LambdaEdgeProtection:
    Type: AWS::Serverless::Application
    # DependsOn:
    #   - UserPoolDomain
    Properties:
      Location:
        ApplicationId: arn:aws:serverlessrepo:us-east-1:520945424137:applications/cloudfront-authorization-at-edge
        SemanticVersion: !Ref SemanticVersion
      Parameters:
        CreateCloudFrontDistribution: "false"
        HttpHeaders: !Ref HttpHeaders
        UserPoolArn:
          Fn::ImportValue: !Sub ${ImportStackName}-UserPoolArn
        UserPoolClientId: !Ref UserPoolClient

Seems to me this should work fine. But I'm seeing:

Embedded stack arn:aws:cloudformation:us-east-1:111111111111:stack/testj6b-LambdaEdgeProtection-X0O0IFFNH3FR/feefc9d0-1e1b-11eb-a2c8-0a726edfb5e3 was not successfully created: The following resource(s) failed to create: [LambdaCodeUpdateHandlerRole, UserPoolDomainLookup].

To the best of my knowledge the missing parms (SPAMode, etc) are defaultable and therefore not needed -- and not present in the working v1 config or in working v2 standalone configs that are not used in migration.

Can you advise me how I might debug this configuration or problem, given that it doesn't look like CFN is returning much in the way of information? The UserPoolArn looks reasonable and is of the form:
arn:aws:cognito-idp:us-east-1:111111111111:userpool/us-east-1_ABCDEFGHI

I'm concerned about the domain lookup especially because a UserPool can have only one domain as far as I can tell. We're just using the Cognito default domain.

As an alternative, do you have any advice on actual inplace migration from V1 to V2? Sounds difficult.

[rpattcorner]

Closing for now as it's looking like a CFN issue. Will post back or reopen once certain.