In D13421#150566, @epriestley wrote:

(under certain, unknown conditions).

I don't want to upstream this kind of stuff.

To be clear "certain, unknown conditions" doesn't mean "it doesn't happen". We observe this scenario occurring frequently, we just don't have access to the internal Amazon implementation to find out why their networking behaves like this (does the connection terminate while EC2 is assigning IPs, does the connection terminate because the box temporarily brings up a firewall that REJECTs instead of DROPs, etc.) The actual causes for why the connection might be refused instead of waiting for the timeout are numerable and impossible to know (and may vary for different people).

But this bug fix is still required because in the event the connections are refused, we don't want to hammer the EC2 API in a fast-running loop and consume all of the API credits. When all of the API credits / limits have been exhausted for the time period, AWS blocks API access to all applications on the account, and thus when this scenario occurs, Phabricator essentially ends up DoS'ing any other applications using the AWS API.