Need help with Autoscaling and warm pool

I'm not sure if a warm pool is a good solution for this scenario. Warm pools are designed for instances with long initial startup times, which are then relatively static afterwards, which doesn't sound like the case for your environment (although the initial config time wasn't mentioned). There isn't currently any native way to 're-warm' an instance in a warm pool, so you'd need to launch a new instance each time you made a new AMI, and then replace the old one, which would add up quite a bit cost wise from the few minutes of running time on each new instance each hour.

When using AutoScaling, you want instances to be stateless so that they're interchangeable. Are you able to store the data off instance somewhere so that you don't have to worry about the constant snapshots/AMI changes? If you could use a secondary EBS volume which isn't deleted on termination, you could then have a userdata script in the new instance re-attach that volume to a replacement instance (with or without a warm pool) when that replacement instance goes InService. Another option would be using EFS as the secondary data volume, which would be even simpler since EFS can be attached to multiple instances at once, so there's no issues with concurrency/race conditions as the new instance is coming InService while the old one is being shutdown

+1 for @Shadah_C's recommendation of using EFS. You mention that there is an expected application failure and using EFS with multiple active-active EC2 instances in an Auto Scaling group would provide strong availability and may reduce data loss risk. (Though only testing will validate that.) While Warm Pool instances may come into service faster, it doesn't seem that it will address the potential gap in time that your service would need to detect application failure, terminating the active instance, activate the WP instance, and then manage the EBS lifecycle that you're considering.