Sure, and this is what HTTPS certificates from a CA are for. If your users are willing to click through the "warning: self-signed certificate" popups, then they're vulnerable, of course. But if they don't make that mistake, then your DNS result is reliable unless someone compromises the CA. Of course, CAs do get compromised.
IsTom's comment was about how an HTTP-served page might be modified to make the "secure" links actually point to a non-HTTPS fake login page (for example). This assumes the user will not notice that the connection is not secure (which I think is a fair assumption).
Given that, another attack might be to mitm DNS and serve an entirely fake Amazon site, all in HTTP, and the user will not notice there's anything wrong.
I think that's the point mro and troels were trying to make.
The only way I can imagine to mitigate this would be to use HSTS on the amazon.com home page.
Can you explain more on how two sessions would work? I mean if the hijacker hijacks the http session he can convert it to https by following the same steps the user does. Since amazon does not ask the user to reauthenticate on https pages.
You can set the secure flag when creating a cookie which will only send it over an HTTPS connection.
It is possible to use both schemes, but it is likely better to stick to all SSL if possible in case of developer error causing something to get exposed when it shouldn't.
You have two cookies, one for HTTP, one for HTTPS. The latter uses a secure flag so it can't be seen with HTTP connections. When the user logs in, both are set.