Copy an Amazon EC2 Instance to use locally

Is GlusterFS a good solution to share data across all the instances in the Autoscaling group?

Possibly.. The only way you'll get a definitive answer is with your own tests, however. In the past, I've set up a 4 node webserver cluster on Linode instances, using GlusterFS to distribute/share the assets directory of images and so on.
We found 2 main problems with this approach:

1. GlusterFS is pretty IO intensive, and works really well on hardware with uncontended IO
2. Occasionally, a Linode server would experience less-than-optimal access to the backend SAN, and IO-Wait time would go up dramatically. When this happened, Gluster would copy more data between the remaining nodes, which caused IO performance to suffer on those nodes in turn. The result of this was that a minor IO blip, caused by suboptimal SAN configuration, or timesharing would mean that the entire webserver cluster would go poot, and the entire shared filesystem might become unavailable.

Purely anecdotal evidence, but I'd not run GlusterFS on a virtual machine with SAN/shared storage ever again.

Does Gluster ensure there is no loss of data ?

It can... In Gluster 3.0, there's a better recognition of "replication pools" where you can define how many copies of the data exists throughout the cluster. Setting a replication level of 2, means that there's 2 copies on the entire cluster.. This effectively halves your storage capacity, but means that you've got greater resilience to node failure.
Importantly, it also means that you have to add more nodes as multiples of the replication level, in this case, pairs of nodes.

What will happen if all the instances in Autoscaling are terminated, will I lose user data ?

If the instances are only using ephemeral instance storage, yes. If they're EBS based, or using mounted EBS instances, then no.

What happens if a user uploads a image and the server processing the request goes down ?

That greatly depends on how your application is designed. I strongly suspect that the user would lose their data (almost certain in a naively architected solution.)

Is there an impact on IO if clients go down ?

See above.. If the client goes down because of backend storage problems, it can easily destroy the performance of the cluster entirely.

There are a number possibilities when dealing with storage on AWS.

First off, there is instance-storage (the 850 GB you are talking off). This storage is hooked to your EC2-instance. It can not be moved or recovered to another instance once the instance is gone. This is useful to store thing of low importance. (OS files, files to process, ...). When the instance is gone, your data is also gone.

Then there are EBS-blocks. These are like hard drives you can attach to any EC2-instance that holds your data persistent, whether your EC2-instance goes down or not. When you need the drive for another instance, just detach it and reattach it. The size of an EBS block is predefined. When you run out of space, add another one. Resizing is not really possible (unless you use the hacky way described in the link you provided).

Lastly you can use an S3-Bucket. Your can store as much data as you want in these buckets. It works a bit like EBS but has no real filesystem implementation. Some sites use this to host their images etc.

So, for your problem:

You should be able to run them using the ec2-tools. Q1 & 2 I think I addressed above. As always with AWS. Don't get attached to EC2-instaces. When they go bad, get rid of them and set up a new one by using a pre made image and attach your EBS-blocks.