By using AWS re:Post, you agree to the Terms of Use

Need help with Autoscaling and warm pool

0

We are currently testing a scenario where we will run two Ec2 instances (Running custom application) at a time in autoscaling group. One will be hot and another will be warm ready to go. When the active server goes down due to application failure, the autoscaling will bring the warm one to the active state. While the active server is up and running we are taking snapshot of the attached EBS volume every hour. Is there a way when the active server goes down and the warm one comes up, it has the EBS volume attached and mounted to it with the latest snapshot? I am aware of triggering a Lambda and have it attached an EBS volume to the instance but then I am not sure how will I mount it when the warm pool ec2 instance is in autoscaling:EC2_INSTANCE_LAUNCHING state? The application will be running on RHEL8 AMI. Any guidance, suggestion are appreciated. Thanks

1 Answer
0

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

answered 14 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions