Sticky sessionの自体は、わりと一般的な機能だと思いますが、あまり知識がなかったころにえいやっ！で設定して理解が浅かったので、あらためて動作検証してみました。

ELBのStickiness(維持設定)について

ELBがリクエストを振り分ける際、ユーザーのセッションごとに振り分け先のインスタンスを固定するSticky sessionを提供する機能です。
一度接続が確立すると、Cookieの有効期間を超過するか、接続先インスタンスのヘルスチェックに失敗するまで、同一インスタンスにリクエストを振り分け続けます。

メリット

以下のように冗長化されたWeb/AP構成で動作を検証してみました。

1セッションごとに発生するRDS, Appサーバのコネクション数は、Sticky sessionを有効にした場合とそうでない場合とで異なります。

検証過程は冗長なので省きますが、以下のような結果になります。

ELB->Web, Web->AppでそれぞれSticky sessionを有効にしなかった場合
- RDSのコネクション数(最大)：4
- Appのコネクション数(最大)：2 * 2台
ELB->Web, Web->AppでそれぞれSticky sessionを有効にした場合
- RDSのコネクション数(最大)：1
- Appのコネクション数(最大)：1

DBやアプリケーションに最大同時接続数の制約があるにもかかわらず、前者はサーバ台数が増えれば増えるほど、サーバ間のコネクションが増大し、余分なリソースを消費するようになるため、サービス全体の同時接続数を増やすことが難しくなります。

一方、後者は１セッションあたり常に１コネクションとなるので、適切なリソース消費が行えるようになります。

デメリット

今回の検証の中では見つけられませんでした。
サーバ側の障害でエラーを返すようになったとして、ヘルスチェックで切り離されるまで、あるユーザーにはエラーが返るようになりますが、Sticky sessionを無効にした場合も数回に１回エラーが返る状況は変わらないはず。
デメリットをご存知の方に教えていただけると嬉しいです。