Amazon has seemed rather dishonest about the true breadth of the outage.
Either their availability zones are ludicrously skewed (supposedly they are random per customer), or they in fact pushed some kind of update that took almost everything down at once, and are relying on the fact that no one could determine what zone they were in.
Actually, on that note, who else here was affected? If your company had stuck EBS volumes during this extended outage period, could you look up your one year m1.small reserved instance offering id for the zone you are in? Mine (Cydia was affected by the outage) is: 438012d3-80c7-42c6-9396-a209c58607f9.
To do this, run this script (slightly modified from the one at the site below to update it for a couple years of drift: Amazon VPC instances were confusing it into showing two identifiers), and make certain to change the last grep to look for the availability zone in which your outage occurred:
ec2-describe-regions | cut -f2 | while read -r region; do
ec2-describe-reserved-instances-offerings --region $region
done | grep 'm1\.small.*1y.*UNIX$' | grep us-east-1a #<- change this
Thanks for pointing out that trick, by the way. Given AWS is exposing this anyway, they might as well just give them friendly aliases so that their status updates don't come across as quite so evasive. Probably they don't even know they're exposing this though!
Perhaps the mapping isn't strictly random but actually load-based. If there are 6 underlying AZs, and Zynga hits 4 of them, then perhaps most other customers would be in the remaining two zones, so it's a 50/50 chance.
I do totally agree that something isn't quite right - AWS status updates do imply they deliberately disabled API calls; perhaps they did that across otherwise unaffected AZs. We'll have to see what the PR department comes up with for the post-mortem.