I think timeouts are still a concern with even a syn scan. What happens if this packet gets dropped or it takes a second for it to come back? It can be relatively disastrous when an EC2 node suddenly believes it has been removed from EC2 and makes configuration changes accordingly for that one run.
We've been discussing this and our ideas so far are:
(Are we on Linux && are we a Xen Guest) || Are we on Windows?
Do a DNS lookup on the IP address of eth0, does it end with 'compute-1.internal'?
We must be on EC2, look at the metadata server
I don't have a VPC node handy, so I wonder if the first two steps are true there.
Also, I haven't tested outside of us-east, and I have a hint in my memory about DNS being different in some EC2 zones.
If we're willing to assume that DNS should either always fail immediately (no DNS or blocked, our resolver should not misbehave) or succeed quickly (DNS is almost always local, or should always be local) than we can use this approach.
This may be useful for Rackspace cloud as well, although we usually have the problem there with differentiating between Rackspace Cloud and Rackspace managed hosting, which we fourtunately do not have with AWS.