share facebook facebook facebook twitter twitter menu hatena pocket slack

2020.12.21 MON

ALBリスナールールで転送・リダイレクト・固定レスポンス

新川 貴章

WRITTEN BY 新川 貴章

概要

  • 今回はALBのリスナールールを使って、複数のターゲットに転送するアクション、別のURL(FQDN)にリダイレクトするアクション、固定レスポンスを返すアクションの3つの使い方を記載します。EC2であればApache, Nginxなどを利用したリバースプロキシで実現しますが、ALBのリスナールールでも同様の機能が実現できます。
  • シチュエーションとしては、パスによってターゲット(ターゲットグループ)を振り分けたい、特定パスだけ別のURL(FQDN)にリダイレクトしたい、いずれのパスにも該当しなければ404を返したいといったケースに活用できます。
  • ポイントは、間違えやすい、ALBで”転送”と”リダイレクト”の違いを理解する。そして、ALBリスナールールで転送・リダイレクト・固定レスポンスの設定を使いこなすこと!

転送とリダイレクトの違い

  • ALBのリスナーで設定する“転送アクション”は、クライアントから受け取ったリクエストを別のサーバーに転送することです。クライアントから受け取ったリクエストURI に変更を加えず、オリジンサーバーに送ります。転送アクションは、ターゲットグループのみ設定可です。(外部URLは設定できない)
  • ALBのリスナーで設定する”リダイレクトアクション”は、URI が移動したことをレスポンスで返し、リクエストの完了にはクライアントで追加の処理が必要なことを示します。一時的 (HTTP 302) または恒久的 (HTTP 301) としてリダイレクトを設定します。

ALBリスナールールの活用

リスナールールで転送先を振り分け

  • 今回はテストのため、ターゲットにLambda関数を使用します。ターゲットグループを2つ作成し、ターゲットに各Lambda を登録します。
  • 先ず、ターゲットグループ [niikawa-test-tgt-lmd01] に、Lambda関数 [niikawa-test-lambda1]を登録し、下記のコードをデプロイします。ALBのバックエンドとして使用するため、今回のLambdaはVPC内に配置します。サブネット, セキュリティグループは適切に設定して下さい。
import json
def lambda_handler(event, context):
    # TODO implement
    return {
        'statusCode': 200,
        'body': json.dumps('Good morning. Let\'s work hard today.')
    }
  • 次に、ターゲットグループ [niikawa-test-tgt-lmd02] に、Lambda関数 [niikawa-test-lambda2]を登録し、下記のコードをデプロイします。
import json
def lambda_handler(event, context):
    # TODO implement
    return {
        'statusCode': 200,
        'body': json.dumps('Hello, let\'s relax in the afternoon.')
    }
  • ロードバランサーを選択、リスナーをチェックし、[ルールの表示/編集] を押します。

  • リスナールールで、”+” を選択します。[ルールの挿入]を押します。

  • 条件に”パス”、アクションに”転送先”、ターゲットグループに先ほどのLambda関数を登録したターゲットグループを設定します。

  • 2つのパスによってターゲットを振り分けるルールが追加できました。

  • curlコマンドでテストしてみます。パスによって異なるサーバー(ターゲットグループ)に転送されました。
niikawa@niikawa1:~$ curl http://niikawa-test-alb1-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com/morning
"Good morning. Let's work hard today."

niikawa@niikawa1:~$ curl http://niikawa-test-alb1-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com/afternoon
"Hello, let's relax in the afternoon."

リスナールールで外部URL にリダイレクト

  • 次は、外部URLにリダイレクトを行います。特定のパス(例: /night)を指定すると、HTTP 301 を返し、外部URL(例: https://www.gnavi.co.jp/)にリダイレクトします。
  • リスナールールで、”+” を選択します。[ルールの挿入]を押します。
  • 条件に”パス”、アクションに”リダイレクト先”、プロトコル,ポートに”HTTPS”, “443″を指定、ホストに”www.gnavi.co.jp”、パスに”/”、ステータスに”301″を設定します。

  • 特定のパスによって外部URL にリダイレクトするルールが追加できました。

  • curlコマンドでテストしてみます。301 Moved Permanently が返され、”Location: https://www.gnavi.co.jp:443/” が渡されました。
niikawa@niikawa1:~$ curl http://niikawa-test-alb1-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com/night -vv
*   Trying xx.xx.xx.xx...
* TCP_NODELAY set
* Connected to niikawa-test-alb1-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com (xx.xx.xx.xx) port 80 (#0)
> GET /night HTTP/1.1
> Host: niikawa-test-alb1-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: awselb/2.0
< Date: Sun, 06 Dec 2020 11:04:42 GMT
< Content-Type: text/html
< Content-Length: 134
< Connection: keep-alive
< Location: https://www.gnavi.co.jp:443/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
</body>
</html>
* Connection #0 to host niikawa-test-alb1-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com left intact
  • curlコマンドではなく、ブラウザでアクセスした場合は、自動的に"www.gnavi.co.jp" が表示されました。

リスナールールで固定レスポンス

  • 最後に固定レスポンスを設定します。いずれのパスにも該当しない場合は、404 を返します。
  • リスナールールで"編集" を押し、最後のデフォルトアクションを選択します。
  • アクションに"固定レスポンスを返す"を選択します。レスポンスコードに"404″、Content-Typeに"text/html"、レスポンス本文に"404 Sorry, page not found…"指定します。

  • curlコマンドでテストしてみます。ステータスに404、指定の本文が返されました。
niikawa@niikawa1:~$ curl http://niikawa-test-alb1-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com/other
<html>
<body>
<h1>404 Sorry, page not found...</h1>
</body>
</html>
  • ブラウザでアクセスした場合は、下記表示となりました。

  • 本日のポイントは、間違えやすい、ALBで”転送”と”リダイレクト”の違いを理解する。そして、ALBリスナールールで転送・リダイレクト・固定レスポンスの設定でした!

参考資料

Application Load Balancerのリスナーを設定する方法を説明します。

元記事はこちら

ALBリスナールールで転送・リダイレクト・固定レスポンス

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。