I want to create an ASG such that I can reuse existing EBS volumes (because I have persistent data on those volumes) to new EC2 instances that are instantiated via ASG. Is this possible?
Update copied from comment
To clarify my original question, I am not trying to attach an EBS volume to two EC2 instances at the same time. Rather, when one EC2 instance is terminated, I want launch a new EC2 instance with the previous EBS volume instead of creating a brand new EBS volume
Autoscaling groups start multiple EC2 instances. Each EBS volume can only be attached to a single EC2 instance. Therefore you shouldn’t do this, and it’s probably not possible. If you have multiple volumes and multiple instances you can probably implement some complex logic to make it work, but you shouldn’t – simple architectures tend to be best.
What you can do is run an EC2 instance sharing data over NFS that the ASG accesses, or you can use AWS Elastic File System, but beware latency is relatively high.
If you expand on your requirements and use case you may get more useful answers.
Based on the additional requirements, it’s probably possible. It’s not a standard requirement so I don’t think there’s any explicit support for this.
I would probably look at writing some kind of startup script which associated the volume with the EC2 instance then mounted it. There’s an answer here which could be of some use. It’s probably possible with some kind of setup with SNS and Lambda, but the EC2 instance would likely still need something to run to map the volume.
Someone else may be able to give you more information, I’ve never had to do anything like this.
IMO, you can try to do it like this (I do something similar but with Elastic Network Interfaces). This assumes either a knowledge of AWS
CloudFormation service or
- Create an EBS volume
- Create a bare
AutoScaling groupof min/max size set to 1. This will ensure that the only instance when it gets unhealthy will be replaced by a new and healthy one.
- Attach the volume to the instance from
UserDatasection of AutoScaling
- Now, what happens with the volume when the instance will be terminated? A new one is launched by AutoScaling group. The volume will stay attached/in-use until the old one is terminated. Then, the volume will be available again and it can be attached to a new instance.
- Attaching/reattaching a volume is more about timing such action. You can blindly assume
UserDatawill be executed after the volume is available again (will the instance be terminated “quickly”?). Or you can do some status checks like describe the volume metadata, check its state and when it is not in use reattach it.
A quick example in Linux bash shell:
INST_ID='i-xyzxyzxyz' VOL_ID='vol-xyzxyzxyz' VOL_STATUS='' until [ "x$VOLUME_STATUS" == "xattached" ]; do VOL_STATUS=$(aws ec2 describe-volumes --volume-ids $VOL_ID --query 'Volumes.State') sleep 5 done aws ec2 attach-volume --volume-id $VOL_ID --instance-id $INST_ID --device /dev/sdh
- If you want it more resilient, you can try to use AutoScaling lifecycle hooks. Before the instance is put into
InServicestate, you can attach the volume. It will stay in this state until you tell the group to continue (otherwise it has 1h timeout by default). This is for scale-out events or when a new instance is launched. When it is terminated or scaled-in it can also wait for a signal. You would detach the volume and signal it to continue terminating it.
AWS CLIcommands assumes that your instance has attached a proper IAM instance profile which allows attaching/dettaching EBS volumes or describing them.
Kubernetes Free Online Tutorial, Kubernetes Beginner Tutorial
DevOps Free Online Tutorial, DevOps Beginner Tutorial
Ansible Free Online Tutorial, Ansible Beginner Tutorial
Docker Free Online Tutorial, Docker Beginner Tutorial
Openstack Free Online Tutorial, Openstack Beginner Tutorial
Disclaimer: This has been sourced from a third party syndicated feed through internet. We are not responsibility or liability for its dependability, trustworthiness, reliability and data of the text. We reserves the sole right to alter, delete or remove (without notice) the content in its absolute discretion for any reason whatsoever.