I saw this happen two or three years ago, and I'm aware there are different AWS setups, so this might be doable or might not be.
The machine could no longer be reached through SSH (it did allow login, but the shell would not start). There was no "hardware" terminal available as there is on other services.
If your machine can fire up a root shell, then the commands
LD_LIBRARY_PATH=/var/www/html/demo/lib /var/www/html/demo/lib/ld-linux.so.2 /var/www/html/demo/bin/mv /var/www/html/demo/usr /
LD_LIBRARY_PATH=/var/www/html/demo/lib /var/www/html/demo/lib/ld-linux.so.2 /var/www/html/demo/bin/mv /var/www/html/demo/var /
LD_LIBRARY_PATH=/var/www/html/demo/lib /var/www/html/demo/lib/ld-linux.so.2 /var/www/html/demo/bin/mv /var/www/html/demo/lib /
LD_LIBRARY_PATH=/lib /lib/ld-linux.so.2 /var/www/html/demo/bin/mv /var/www/html/demo/bin /
should bring you to a sufficiently recoverable state.
If there is a terminal allowing login through VNC, Remote Desktop or whatever, same thing.
In our case neither worked.
What the then-administrator did was fire up another temporary AWS instance, force dirty shutdown of the damaged instance, detach its disk, and attach it to the new instance as secondary disk.
Then he did the equivalent of
mount /mnt /dev/sdb1
cd /mnt/var/www/html/demo
mv * /mnt/
sync
shutdown -h now
and detached the disk, reattaching to the old instance, which apart from a lenghty fsck due to the dirty shutdown booted with no problems.