WS-HTTP binding in an HA (High Availability) environment

To use WS-HTTP bindings in an HA Cloud environment, use a specific client method.

In an HA Cloud environment, you communicate with the Core Service on the Content Manager server through a load balancer. The load balancer exposes the following types of Core Service endpoints:
Basic HTTP endpoints
These stateless endpoints expose the basic ICoreService contract. These endpoints are most suitable for load balancing. You should use these endpoints in an HA environment.
WS-HTTP endpoints
These endpoints expose the ISessionAwareCoreService contract, which requires that a session between client and server is established.

On the one hand, SDL recommends that you use a Basic HTTP binding in HA environments, because a WS-HTTP binding (using "sticky sessions" in the load balancer) gives you a lesser degree of High Availability. Specifically, all work for a single session would be routed to one of the Content Manager back-end servers behind the load balancer, and if that server would fail, so would the session. In other words, this approach would partly circumvent, and therefore defeat the purpose of, load balancing.

On the other hand, if you do not use WS-HTTP bindings, this adds some limitations to your implementation. Specifically, you cannot do the following:
Impersonation of another user by name
By default, Cloud environments disallow impersonation. You can work around this by presenting the Core Service with the credentials of the user to impersonate.
Privilege elevation
This means performing an action on behalf of a user that may have insufficient privilege to perform that action. By default, Cloud environments disallow privilege evelation. You can work around this by performing the action on behalf an account with system administration privileges.
Transaction flow
This functionality is not supported by RDS and therefore unavailable in the Cloud.

With all this in mind, you may still want to use WS-HTTP bindings in an HA environment. If you do, you need to do the following things.

First, in the configuration file of your custom client application that talks to the Core Service, ensure that your binding element has an allowCookies attribute set to true. Here's an example of such a binding element:
<binding name="wsHttp" 
    allowCookies="true"
    openTimeout="01:00:00"
    sendTimeout="01:00:00">
    <security mode="TransportWithMessageCredential">
        <transport clientCredentialType="None" />
        <message clientCredentialType="UserName" />
    </security>
</binding>

Second, in the client you create, use the SessionAwareCoreServiceClient.WsHttpHAClient() method, which is part of the Tridion.ContentManager.CoreService.Client.dll assembly, rather than the standard SessionAwareCoreServiceClient.WsHttpClient() method.