The primary role of load balancing is to evenly distribute load among all servers, but here we will pursue the security-related path. Splitting the datastream into a number of separate streams and directing each of them to a different virtual server is one way of preventing the traffic analysis attacks. Since co-location attacks, described elsewhere in this tutorial, are shown to be possible means of compromising a single server, such splitting of datastream among many distinct (and due to cloud's inherent architecture - possibly physically separate computers adds to data security.

The unit responsible for distributing load among virtual serves in the cloud is load balancer. It connects to a number of virtual servers, that can possibly be brought up or down, depending on current need for servicing incoming connections.

Upon arrival of a connection-request packet, the balancer makes the decision on which of the available servers can process it and redirects the connection to that server. Since, by design, all servers are the same (in terms of content they store), the decision is oblivious to the requesting side.

The routing decision can be made based on a number of facts:

1. current load of servers: the least busy one serves the request;
2. TCP/IP headers: servers can have certain subnets assigned, or range of TCP ports, etc.
3. state of the connection: consecutive requests originating from the same machine may be directed to the same server; this requires that the load balancer keeps history of recent connections and the connections are distinguishable in some way.
4. ...

This all works well until a point when client and server need to establish a secure communication channel using SSL/TLS mechanisms. If there is a potentially large number of servers behind the balancer, it is possible that the client establishes the channel with one server (which, as you remember, requires establishing a symmetric key) at first, and then its connection is redirected to another server, which has no idea of the key, and thus cannot even decipher the connection!

There are two general solutions, the common session memory, and the "sticky sessions" approach.

Differences

There are some huge differences between the two approaches and we discuss them shortly.

• The balancing on lower layers allows for simpler and more effective balancers, they don't need to perform authentication and store session data. On the other hand, this burden is shifted to end-servers, which might degrade their performance. The latter approach alleviates this problem for the end-servers, while creating a bottle-neck at the load balancer. A solution would be to create a hierarchy of load balancers, first L3/L4 and then L7, or using a high-end (costly) harware encryption accelerators in balancers.
• When the balancer decrypts messages, they are later sent plaintext to end-servers, which can possibly lead to information disclosure. One can counteract this by introducing a simple (symmetric) encryption between the balancer and the servers, which is plausible since they all operate within an infrastructure of one provider.
• Note also that certificate management differs when applying L3 or L7 balancing. Namely, in the latter case it is the load balancer that stores certificates for all servers. When the balancing is done on L3/L4 layers, the certificates are issued and handled by the end-servers.