I'd imagine with the number of requests they make to various analytics, internal services etc it is not a super simple migration.
HTTPS is pretty fast now with SPDY (and soon HTTP/2) but there is no avoiding the fact that is slows down that first page load ever so slightly. No doubt they have studied this carefully and opted for maximum speed, as this maximizes income.
For organizations that are doing SSL termination on their frontend webservers, it depends on their traffic flow: what percentage of page hits are new vs already established ssl sessions that can hit the cache. Different kinds of sites are going to have different traffic mixes that will affect that cost.
Does Amazon use the google strategy of software SSL termination, or do they use hardware like F5 terminators? Either way, they already have some ssl termination capability, since the secure parts of their website rely on it, so it's only a matter of beefing up existing capability rather than implementing it from zero. They may already have a lot of excess SSL termination capacity that they're not using.
If SSL everywhere always costs a company money, why did Google switch so early? I think there are benefits that at least partially compensate for increased infrastructure costs.
I think it's more likely that embedded resources from non-ssl external pages are blocking SSL deployment. Or Amazon has a bunch of hardcoded http://www.amazon.com links in different parts of their codebase, that have to be tracked down and fixed. Mixed content is what I think is blocking ssl deployment on most sites. Small sites that have switched to SSL-everywhere often haven't spent the time to do it right, and whether because their software has hardcoded http embedded links, or they're linking content from other sites, mixed content warnings are common. (Protip: //domain/path [without the initial http or https] is a protocol-relative link, if you need to link to a different host but keep the protocol the same)