They've been working on it for at least three years. We were really interested in deploying our application on the AWS infrastructure, until they made it clear that IPv6 wasn't going to happen for the foreseeable future. I guess they do get good marks for being transparent on their roadmap and not getting our hopes up.
They might have had issues with various gear, tooling, etc. You'd be surprised how many routing vendors screwed up IPv6 subnetting. Hence, why you need to assign a /126 on PtP links for some gear, instead of a /127. Some vendors still thought IPv6 had a broadcast address (it doesn't). Sure that's just an example and doesn't preclude them from offering it, but maybe they're conservative and wanted to get everything working right before releasing it?
Also, some older gear routed/forwarded IPv6 in software; making it much slower.
Our biggest problem had nothing to do with network hardware. It all came down to developers still writing IP regex's wrong for our app. Maybe I should write an e-book "IPv6 for the node/jquery developer?"
tl;dr it's not in Amazon's market interests to delay IPv6 adoption
"Some vendors still thought IPv6 had a broadcast address"
I have never known anyone working with IPv6 for more than a day who doesn't understand that IPv6 does not have a broadcast address. I do not believe any vendor writing a routing stack would fail to understand that. Though, I do agree in early days, they screwed things up. For example, Dell would not route RFC 4193 (FC/7) addresses around 2005. I had to rip out and ship back a dozen of their routers when I realized they weren't going to fix that.
I think you might be onto something about gear though - I've read that Amazon builds their own routers, and routing stack - which means they can't simply deploy a well tested/regressed IPv6 stack, they have to write and test it from scratch. The dark side of doing everything yourself.
