So we’ve actually got several mysteries here - why the connection fails, why it re-establishes with swapped roles of the peers, as you say that the AWS peer acts as a responder only, and why the tunnel doesn’t work in this case.
As already said, only logging can shed some light on what actually happens.
So disable the peer or identity representing the AWS at the Mikrotik end (and if possible, also any other peers so that the log doesn’t collect “noise” from other IPsec sessions), open a command line window (by pressing the [Terminal] button), and write the following there:
/system logging add topics=ipsec,!packet
/log print follow-only file=ipseclog where topics~“ipsec”
Then, enable the AWS peer/identity and wait until the failure happens again and you can see the Responder row to appear in the Active Peers table. Once that happens, stop the /log print … command, download the file ipseclog.txt and read it - the answers should be there.
If you cannot find the answers on your own, follow the hint in my automatic signature just below to anonymise the log file and post it; just be aware that the public IPs are also present in the hexadecimal dumps in the log so you should sanitize these also (169.255 will be seen as a9 ff, translate the other two bytes too).
Also post the configuration export and the output of /ip ipsec policy print detail both when the tunnel is OK and when the Active Peers row is the Responder one.