Sorry for the late response. Remember that RTMP is a session based-protocol, so when you send your stream to one of the two EC2 instances, and that instance crashes, your encoder will have to reconnect, even when you use a NLB between your encoder and the instances.
If you use an ALB or NLB for the output, when server #1 crashes, the LB will logically route HTTP requests to server #2, but there’s no guarantee that it will be in sync with #1, so the player may get an error. It’s up to the player - or how you have configured the player - to decide what happens in that case. Some players reconnect automatically, others will simply stop.
Best practice is probably to write some JavaScript against the player’s API so that they player automatically restarts when it stops. But then, if you’re Live streaming an event, you’ll have to notify your front-end when the event stops, thus when the stream ends, or your player may try to restart indefinitely.
Back to syncing server #1 and #2 - there may be some way to sync if you can use an external clock (will require customization of the packager in Wowza), or if you use a HTTP proxy with some intelligence between the LB and the EC2 instances, e.g. rewrite the chunk names and/or use EXT-X-DISCONTINUITY in the chunklist That’s just thinking out loud though, would require some research and experimenting.