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

215件のシェア(すこし話題の記事)

この記事は公開されてから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で指定は現状できないのでご注意ください。

【新機能】新しいロードバランサー Application Load Balancer(ALB)が発表されました

[新機能] ALBのターゲットにIPアドレスを指定可能になりました

パフォーマンスの改善

ロードバランサー自体のパフォーマンスが向上しています。また、HTTP/2をサポートしているのでこちらでもパフォーマスの改善が期待できます。

WAFを利用したい

CLBではAWS WAFを利用できませんが、ALBへ移行するとAWS WAFを利用できます。地域制限や、レートベースでの制限も可能なので導入を検討しましょう。

AWS WAFがALB(Application Load Balancer)で利用出来るようになりました

AWSセキュリティホワイトペーパー「Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities」のご紹介

[新機能] AWS WAFでレートベースのルールが作成可能になりました [DDoS/Brute force対策]

AWS WAFが正規表現と地域条件をサポートしました

CLBからALBへ移行した場合のコスト計算※あくまで概算

CLBではALBへ移行する時に、移行後のコストを把握できるCloudWatchメトリクスが用意されています。 どれくらい安くなるのか計算して見ましょう。

Classic Load Balancer の CloudWatch メトリクス

現在利用中のCLBのCloudWatchのメトリクスから以下を確認します。

  • EstimatedALBConsumedLCUs:LCUの予測数

ALBの料金はLCUを元に計算されるので上記を利用し予測されるALBでの利用料金を計算しましょう。

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

ALBの料金は、1時間あたりの料金 + 利用したLCUでの課金になります。

  • 1時間あたり(東京リージョンの場合): 0.0243$ + (LCUの予測数 * 0.008$)

※ALBを1時間起動で0.0243$

※1時間で1LCU利用で0.008$

移行方法

CLBからALBへの移行ツールが用意されています。移行時はこちらのツール利用を検討しましょう。

elastic-load-balancing-toolsを使ってELBをALBに移行してみた

http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/migrate-to-application-load-balancer.html

最後に

環境によってはALBへ移行するだけでパフォーマンス向上、コストが安くなる可能性があります。CLBを利用されている方はCloudWatchからLCU予測数が出力されているので、計算して安くなるようであれば移行を検討しましょう。

参考