[AWS]CLBからALBへ移行してコストを安くする[ELB]

千葉淳

2017.10.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンニチは、千葉です。

ELBは2017年10月現在3種類あります。

Classic Load Balancer(CLB)
Application Load Balancer(ALB)
Network Load Balancer(NLB)

ALBとNLBが出たため、CLBは旧世代のロードバランサーと位置付けられています。昔から利用している方の中で、現在もCLBを利用している方がいるかと思いますが、ALBへの移行モチベーションを整理したのでこれを機に検討してみてください。もしかしたらALBへ移行することでコストが安くなるかも？因みにこのネタは、ある方からいただきました。ご査収ください！

※ALBはHTTP/HTTPSを喋りますのでご注意ください。(TCPが必要な場合はNLBへ移行を検討ですね)

ALBへ移行するモチベーション

CLBからALBへ移行するモチベーションは以下となります。

ロードバランサーを統合することによるコストメリット
EC2の集約によるコストメリット
利用料金の計算式の違いによるコストメリット
リバースプロキシ機能の統合によるコストメリット
パフォーマンスの改善
WAFを利用したい

細かく見ていきましょう。

ロードバランサを統合することによるコストメリット

ALBはホストベースでルーティングができます。つまり、クライアントからのホストヘッダをみて、どのEC2へ振り分けるかを定義できます。

【新機能】ALBのHost-based routingを試してみた

これの何が嬉しいかというと、例えばサイトA、サイトB、サイトCがあったとして、CLBの場合は3台必要になります。これを、ALBに置き換えると1台で対応できます。ALB1台で複数のSSL証明書にも対応したのでhttpsでの通信が可能です。(※複数証明書を利用するにはクライアントがSNIに対応している必要があるのでご注意ください)

ALBで複数のSSL/TLS証明書を設定できるSNIに対応しました

EC2の集約によるコストメリット

1台のEC2上で複数アプリが実行されている環境で、パスベース、ホストベースで特定のポートに振り分けができます。複数EC2でアプリが動いている場合集約できます。またCLBだとヘルスチェックエンドポイントは1つしか指定できませんでしたが、ALBはアプリケーションごとに指定できます。ただし、アプリケーションを1インスタンスに集約するとリソースを共有してしまうため結合度が高まりますので注意が必要です。可用性が強く求められないアプリケーションで利用しましょう。

利用料金の計算式の違いによるコストメリット

ELBの台数を減らすだけでもコストメリットがありますが、ALBの利用料に対してもコストが低くなる可能性があります。 CLBの場合は、1時間あたりの料金 + データ転送量に応じて課金となります。ALBの場合は、1時間あたりの料金 + キャパシティーユニット(LCU)による料金で課金となります。

LCUの計算式の特徴としては、以下に記載ありますが、ALBだとデータ転送量ではなく帯域幅という単位になっています。もしCLBでデータ転送量が多い場合は、ALBに変更するだけでコストメリットの可能性があります。

https://aws.amazon.com/jp/elasticloadbalancing/pricing/

下の移行の項目に、CLBからALBに移行した場合の予想コストの算出方法を書いてますのでそちらをご確認ください。

リバースプロキシ機能の統合によるコストメリット

もしリバースプロキシ既存で運用している場合、ALBではパスベースのルーティングが可能なためリバースプロキシサーバが不要になるかもしれません。注意事項としては、パスベースのルーティングでのバックエンドの指定方法は、EC2またはIP(指定可能な範囲には制限あり)になります。FQDNで指定は現状できないのでご注意ください。