need to reliably get new user's sub during pre sign-up trigger

Hello,

I have recently discovered an issue that I am would appreciate your assistance with please.

I have tested multiple different scenarios so far with the following two as the main examples or the multiple configuration variations I have tried.

Scenario 1:
User Pool is configured with an alias as follows:
UsernameAttributes:
- email

to allow the user's to login with either their sub/username or the email address

Scenario 2:
User Pool is configured with:
AliasAttributes:
- preferred_username

Please note that no UsernameAttributes are configured in this case (as we ultimately do not want email and/or phone number as aliases).

Both of the above scenarios are also configured to have a Pre Sign-Up Lambda trigger.

The issue is that I need to be able to reliably access and store the user's Sub during account creation.

This is very easy in Scenario 1. It is handily included right on the event parameter provided to the Lambda under the "userName" key. Please note that multiple tests have confirmed that, in this configuration, the value provided here under "userName" is also in fact the user's sub. Handily gives us exactly what we need in this scenario.

Unfortunately, Scenario 1 is not an option for us as we cannot have either the email or phone number be aliases for an account as our user's may need to be able to have more than one account associated with a given email and/or phone number - i.e. the may not be unique across the pool in our case. Per the documentation (and confirmed via testing), aliases must be globally unique within the pool, so this rules out Scenario 1 for us.

Scenario 2 unfortunately does not have the same behavior. In this case the "userName" value is populated with the username we specify to the signUp invocation (a generated UUID in our case). However, this value is NOT used as the sub and the account gets created with our generated UUID as the username and an unknown generated value/UUID as the sub. Frustratingly, nothing under the event or context parameters provided to the Lambda include the generated value that will become the user's sub in this case. This is where we are stuck and need some assistance please. How can we access what will become the user's sub, without aliases, within the pre sign-Up trigger please?

Other alternatives that have been considered, but determined to be not workable:
As there is some unknown lag of time between initial creation an the subsequent confirmation of the account storing this information at that point (i.e. under a post-Confirmation trigger) is too late/risky. Similarly, attempting to update from the client side with the results returned from the sign-up call is also deemed as risky as the update may fail even though the cognito account was created leaving things in an inconsistent state. The atomic transactional behavior associated with a single signUp invocation and it's associated pre sign-Up trigger is what we are looking for.

I look forward to your assistance please.

TIA!