(Strange post, so hopefully this won't be as strange a reply).
On the subject of security flaws: it is considered general bad practice to store cgi-bin scripts within the document root of the web server. Even the W3C eludes to it under "Are compiled languages such as C safer ..." in their World Wide Web Security FAQ:
Consider the following scenario. For convenience's sake, you've decided
to identify CGI scripts to the server
using the .cgi extension. Later on,
you need to make a small change to an
interpreted CGI script. You open it up
with the Emacs text editor and modify
the script. Unfortunately the edit
leaves a backup copy of the script
source code lying around in the
document tree. Although the remote
user can't obtain the source code by
fetching the script itself, he can now
obtain the backup copy by blindly
requesting the URL:
http://your-site/a/path/your_script.cgi~
(This is another good reason to limit
CGI scripts to cgi-bin and to make
sure that cgi-bin is separate from the
document root.)
This is not as significant a threat as the ability to write a file within the document root. However, an attacker could obtain the source code of the cgi, devise a directed attack against it, and use it as a stepping stone into the server.
To mitigate this, you can add the following lines to the lighttpd.conf (or some variation therein) to direct cgi-bin to a directory separate from the /var/www/lighttpd document root.
$HTTP["url"] =~ "/cgi-bin/" { cgi.assign = ( "" => "" ) }
alias.url = ( "/cgi-bin/" => "/usr/lib/cgi-bin/" )
This requires both the cgi and alias modules for lighttpd.
The only fastest way is that which you have mentioned already, that make a small ami and host a static maintenance page on it, by attaching elastic IP to it.
There is no hard and fast rule that which AMI should be used in this scenario. Any micro instance of Debian/RHEL/Ubuntu would work fine.
Best Answer
You cannot transfer an EC2 instance (or any other resources) to a different AWS account.
If the instance is EBS boot (recommended), you might try an approach like this:
Stop the current instance (ec2-stop-instances)
Create an AMI from the instance (ec2-register-image)
Give the second AWS account permission to run that AMI (ec2-modify-image-attribute)
Run a new instance of the AMI under the second AWS account (ec2-run-instances)
DNS would need to be updated to point to the IP address of the new instance (preferably using an Elastic IP Address). Any other AWS/EC2 resources would also need to be copied/recreated in the second account.
After sufficient testing, you might want to free up the original instance (ec2-terminate-instances).
The second account should create their own snapshots / AMIs of the instance to protect themselves if their instance/EBS volume fails after the AMI owned by you is deleted.
Even better, you should have documented/scripted exactly how your instance was created so that the client can reproduce this at will.