Yeah, unfortunately they don't do a whole lot of analysis for you, if you want any information more detailed than their monthly cost summary, you're going to have to write your own scripts to process the raw data they give you. You can download it in several formats, so it's pretty easy to process, you just have to decide what you want to do with it.
(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.
Best Answer
it's likely that your server has been compromised, so do your due diligence to check this out.
start a packet capture so you can determine the nature of the traffic.
If you determine that the server was compromised, you may be able to work with AWS support to get the charges reversed.