mysql innodb_flush_log_at_trx_commit clarification
What I want to know is, this does not affect the time that the query
  is actually committed does it? It only affects its recovery ?


It only affects recovery.


  I just want to make sure that when I do an insert or update that the
  query will run right at the time of processing and not 1 second later,
  no matter what the flush_log is set to.


Correct.  There may be reasons to hide changes that other transactions see (as part of multi-version concurrency control).  If you're trying to build tests to prove things - make sure you understand how transaction-isolation levels work :)


  My understanding is that in the case of a crash , setting to 1 will
  allow it to recover all queries run on the server, where as setting it
  to 2 may lose the last second or two of data when trying to recover
  from the crash, is this correct?


Correct.  To be able to recover all (setting: 1) ti also assumes that the underlying hardware is not adding additional buffering to improve IO performance.  I have no reason to assume that Amazon doesn't do this, so I think setting it to 2 is a good cloud practice.


  Also, if there is slow periods of updates/inserts (ie, not much
  happening on the server) does setting it to 2 add additional overheads
  on the server, or is it a case of the benefits of applying
  innodb_flush_log_at_trx_commit=2 to the database when the database is
  busy outweighs any additional overhead caused during slow times?


What happens when you set to 2 (and why you get better performance) is that you just buffer changes for longer, and therefor get more IO request merging, and better performance.  It doesn't create more work.

Shameless plug for additional reading - When does MySQL perform IO?