Not all traffic. Amazon has a separate SecureOnly cookie for access to their trusted pages that isn't sent over HTTP. Without that cookie not all traffic can be proxied.
To summarise, the attacker injects herself into the traffic stream, fully controlling the Amazon side of the communication, and forwards traffic to the victim rewriting as appropriate. The account compromise occurs when Amazon asks the victim for the password (as they do before each purchase) and the attacker captures the password (because it will have been sent to her, rather to Amazon).
I never said an attacker can't do this. I'm saying an attacker can't do a s/https/http and have a user end up at an HTTP login page, where the attacker can sniff credentials.
Remember: HTTPS does not ensure the identity of the client.
It sounds like you are talking about creating a phishing page and injecting it, hoping the user enters their credentials, and stealing them. I already said this was possible.
User requests login page over http
HTTP request is intercepted, and relayed over https to amazon
https response from Amazon is modified to show http links, and presented back to the user
User fills in credentials and submits request over http
Request is intercepted, and relayed over https back to Amazon
MITM now has all credentials.
Doesn't require any special tools, or a phishing page, just a spot between Amazon and the user, and the ability to re-write responses from https back to http.
HTTPS with a HSTS setting would mitigate this, since the browser would refuse to request the HTTP page if the user had ever successfully visited https://www.amazon.com before.