0
votes

I am facing an architecture-related problem:

I have created a new environment in ElasticBeanstalk and pushed my app there. All good so far. I have set it to auto scale up/down.

My app depends on filesystem storage (it creates files and then serves them to users). I am using an EBS volume (5gb large) to create the files and then push them to S3 and delete them from EBS. The reason I'm using EBS is because of ephemeral filesystem in EC2 instances.

When AWS scales up new instances don't have the EBS volume attached because EBS can be attached to one instance at a time.

When it scales down, it shuts down the instance that had the EBS volume attached, which totally messes things up.

I have added to /etc/fstab a special line that will automatically mount the EBS volume to /data but that only applies for the instance I add the file to /etc/fstab. I guess the solution here would be to create a customized AMI image with that special line. But again, EBS can't be attached to more than one instance at a time, so it seems like a dead end.

What am I thinking wrong? What would be a possible solution or the proper way of doing it?

For some reason, I believe that using S3 is not the right way of doing it.

1
you have to have one EBS volume per each instance. not sure how to make this in EB though. on EC2 you just change AMI to start with mounted EBS volume and update autoscaling conf to use this AMI.Dmitry Mukhin

1 Answers

1
votes

S3 is a fine way to do it: your application creates the file, uploads to S3, removes the file from the local filesystem, and hands a URL to access the file back to the client. Totally reasonable. Why you can't use ephemeral storage for this. Instance store-backed instances have additional storage available, mounted to /mnt by default. Why can't the application create the file there? If the files don't need to be persisted between instance start/stop/reboot then there's no great reason to use EBS (unless you want faster boot times for your autoscale instances I suppose).