AWS上でブラウザリダイレクトを実装するパターンを制約とともにまとめてみた
AWSでブラウザリダイレクトを実装したい
おのやんです。
みなさん、AWSでブラウザリダイレクトを実装したいと思っても、選択肢が複数あってどれを使えばいいか迷ってしまうことはありませんか?私はあります。
複数あるリダイレクトの選択肢の中では、それぞれルール数の条件があったり、コードで実装する場合はコードサイズの上限など、さまざまな制約があります。これらの制約は多岐に渡るため、今回はAWSでブラウザリダイレクトを行うパターンを制約・制限事項とともにまとめておきたいと思います。
ざっくりまとめ
今回は、次の4パターンに分けて、AWS上のブラウザリダイレクト方法とその制約についてまとめていきます。
| パターン | 主な制約 |
|---|---|
| S3 Website Hosting | HTTPのみ、ルールは50件まで |
| ALB リスナールール | ルールは100件まで(増加可能)、1ルールあたりの条件数は5個まで・ワイルドカードは6個まで |
| CloudFront Functions | コードは10KBまで、標準のJSで書ける処理のみ |
| Lambda@Edge | us-east-1のみ、他にも制約多数あり |
静的ウェブサイトホスティング
S3の静的ウェブサイトホスティングを使用している場合は、S3のオプション機能としてリダイレクトを設定できます。アクセス先はS3のバケット名(宛先ドメイン)であり、そのアクセスが静的Webサイトホスティングのリダイレクト設定で指定したURLへリダイレクトされます。
この静的Webサイトホスティングですが、エンドポイント自体の仕様により、エンドポイントを提供できるプロトコルはHTTPのみ(HTTPSは利用不可)です。どういうことかというと、リダイレクトされるのはエンドポイントに対してHTTPでアクセスした場合のみです。コマンドで実行してみると、HTTPでのアクセスの場合は指定のURLへリダイレクトされます。
$ curl -sI "http://s3-redirect-p1-xxxxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com"
HTTP/1.1 301 Moved Permanently
x-amz-id-2: nxQXuPL5giHzh0Ho0758OTOtAXcHLFPD4NKS2VMuVcleeUtCC8XzuW9vCAwjrQ/G/zwoelp4Mi03xp0TGInAX4YhywA0fkka
x-amz-request-id: JKW0MZK18VTNP3ZE
Date: Mon, 02 Mar 2026 05:17:04 GMT
Location: https://www.example.com/
Content-Length: 0
Server: AmazonS3
Cf-Team: 2d4e9394a40001e429ae141400000001
一方で、HTTPSでのアクセスは、curlの実行に数秒かかる上に、レスポンスもありません。
curl "https://s3-redirect-p1-xxxxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com"
# 実行に数秒かかる上に、レスポンスなし
上記のリダイレクト設定の他には、リダイレクトルールを静的Webサイトホスティングに対して設定できます。このルールによって、S3内の特定のオブジェクトキー名やリクエストの中のプレフィックス、レスポンスコードなどでリダイレクトの挙動を設定可能です。
例えば、S3のフォルダ名をdocs/からdocuments/に変更し、docs/に対するリクエストをdocuments/にリダイレクトするようなケースでは、次のJSONを指定できます。
[
{
"Condition": {
"KeyPrefixEquals": "docs/"
},
"Redirect": {
"ReplaceKeyPrefixWith": "documents/"
}
}
]
このリダイレクトルールですが、ルール数(細かくいうとJSON配列内の要素数)の上限は50個です。51個以上のルールを記述すると、このように編集しようとしてもエラーが出ます。
51 routing rules provided, the number of routing rules in a website configuration is limited to 50.

こちらは上限数を引き上げることはできませんので、上限に引っかかった場合は別パターンで構築する必要があります。
ちなみに、静的Webサイトホスティング単体だとHTTPしか利用できませんが、HTTPSを使用する場合はCloudFrontを置く必要があります。この場合、制約としてCloudFrontのクオータも考慮する必要がありますので、併せてご確認ください。
また静的Webサイトホスティング使用時は、S3側の設定でブロックパブリックアクセスを無効にする必要があります。CloudFrontを利用していたとしても、S3側のリダイレクトルールなどを使う場合はオリジンアクセスコントロール(OAC)は利用できません。OACを有効にした状態でリダイレクト処理を実装する場合は、CloudFront Functionsを使用する必要があります。
ちなみに、S3静的ウェブサイトホスティングの機能としてのリダイレクトなので、AWS内の宛先はS3のみです。ALBなどの別の宛先も設定したい場合は他のパターンを採用する必要があります。
ALB リスナールール
ALBのリスナールールにリダイレクトアクションを設定することも可能です。あらかじめ運用されているターゲットグループ内のリソース(EC2インスタンスやECSサービスなど)があり、それと並行してリダイレクトさせたい宛先がある場合は検討する候補に上がってきます。
リスナールールでこのように設定すれば、ALBのエンドポイントリクエスト時にリダイレクトされます。

ALBのエンドポイントにリクエストを送るとこのようにリダイレクトされます。
$ curl -sI http://alb-redirect-demo-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com
HTTP/1.1 301 Moved Permanently
Server: awselb/2.0
Date: Mon, 02 Mar 2026 08:00:14 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: https://www.example.com:443/
Cf-Team: 2d4f28fb9a0001e42937c48400000001
$ curl -sI http://alb-redirect-demo-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com/docs/guide
HTTP/1.1 301 Moved Permanently
Server: awselb/2.0
Date: Mon, 02 Mar 2026 08:01:28 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: http://alb-redirect-demo-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com:80/documents/
Cf-Team: 2d4f2a1ee50001e42938843400000001
このリスナールールですが、まずルール数の上限は100個であり、こちらはクオータ引き上げ申請が可能です。
一方でルール1個あたりの条件数の上限は5個であり、この値はクオータ引き上げ申請ができません。またワイルドカード数上限は6個で、こちらもクオータ引き上げ申請はできません。これらの上限に引っかかりそうな場合は、他の構成を採用することになります。
こちらはALBの設定内でのリダイレクトなので、AWS内の宛先で接続できるのはVPC内のインスタンスやAWSのIPアドレス・ポートでアドレス可能なリソースなどになります。
CloudFront Functions
CloudFront Functionsでも、コードに記述する形でリダイレクト処理を実装可能です。
例えば、こんな感じで記述できます。言語はJavaScript限定です。
async function handler(event) {
var request = event.request;
var uri = request.uri;
// /redirect → https://www.example.com/ に 301 リダイレクト
if (uri === '/redirect') {
return {
statusCode: 301,
statusDescription: 'Moved Permanently',
headers: {
location: { value: 'https://www.example.com/' }
}
};
}
// /external/* → https://external-site.example.com に 301 リダイレクト
if (uri.indexOf('/external/') === 0) {
var newPath = uri.replace('/external', '');
return {
statusCode: 301,
statusDescription: 'Moved Permanently',
headers: {
location: { value: 'https://external-site.example.com' + newPath }
}
};
}
// その他はオリジン(S3)にそのまま転送
return request;
}
$ curl -sI "https://xxxxxxxxxxxxxe.cloudfront.net/redirect"
HTTP/1.1 301 Moved Permanently
Server: CloudFront
Date: Tue, 10 Mar 2026 05:44:47 GMT
Content-Length: 0
Connection: keep-alive
Location: https://www.example.com/
X-Cache: FunctionGeneratedResponse from cloudfront
Via: 1.1 d148799fe664d933eb8d6afff0dbacb8.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: KIX82-P3
X-Amz-Cf-Id: ESM4blbUySorJ8LW9OuBSrCXIet1xZxqdFVCWsbGaNz_InVmXnAPxQ==
$ curl -sI "https://xxxxxxxxxxxxxe.cloudfront.net/external/some/path"
HTTP/1.1 301 Moved Permanently
Server: CloudFront
Date: Tue, 10 Mar 2026 05:44:47 GMT
Content-Length: 0
Connection: keep-alive
Location: https://external-site.example.com/some/path
X-Cache: FunctionGeneratedResponse from cloudfront
Via: 1.1 1955a35a2db92d617ec0931122fe6a84.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: KIX82-P3
X-Amz-Cf-Id: aInNueoDPEI1samsu5L8ArUkOXPXIZ3tHNLysvVlqKu9fNdYNFgdNg==
リダイレクト先以外にALBやS3など複数のオリジンがある場合は、CloudFront Functions(と、後述のLambda@Edge)がやりやすいかと思います。S3の静的ウェブサイトホスティングの場合はバケット内の静的ページ、ALBの場合はターゲットグループのみですからね。
これを見ると、後述のLambda@Edgeと同じように利用可能かと思ってしまいますが、CloudFront Functionsのコードサイズ上限は10KBであり、クオータ引き上げはできません。そこそこ長めのコードになったり、複雑なルールを記述しようとすると、案外すぐ達してしまうファイルサイズだと思います。リダイレクトルールが多い場合はCloudFront KeyValueStoreを使ってルールを外に出すこともできますが、ここは注意したいですね。
また、CloudFront FunctionsはCloudFrontに閉じた関数であり、外部ライブラリの使用やネットワークアクセスなどはできません。あくまで正規表現や文字列操作など、標準のJavaScriptで書ける処理に限られます。意外と厳しめの制約がありますので、採用には注意が必要です。
Lambda@Edge
Lambda@Edgeも、CloudFront同様にCloudFrontのイベントにLambda関数を紐づけ、リクエストとレスポンスを動的に操作できます。CloudFront Functionsのコードサイズ10KBを超えそうな場合や、npmのライブラリを使いたいケースでは、後述するLambda@Edgeの制約と天秤にかけた上で、Lambda@Edgeを採用することになると思います。
例えば、このようなコードをLambda@Edgeにデプロイして、オリジンを動的に変えたりすることができます。
def handler(event, context):
request = event['Records'][0]['cf']['request']
uri = request['uri']
# /redirect → https://www.example.com/ に 301 リダイレクト
if uri == '/redirect':
return {
'status': '301',
'statusDescription': 'Moved Permanently',
'headers': {
'location': [{'key': 'Location', 'value': 'https://www.example.com/'}]
}
}
# /external/* → https://external-site.example.com に 301 リダイレクト
if uri.startswith('/external/'):
new_path = uri.replace('/external', '', 1)
return {
'status': '301',
'statusDescription': 'Moved Permanently',
'headers': {
'location': [{'key': 'Location', 'value': 'https://external-site.example.com' + new_path}]
}
}
# その他はオリジン(S3)にそのまま転送
return request
$ curl -sI "https://xxxxxxxxxxxxxx.cloudfront.net/redirect"
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Connection: keep-alive
Server: CloudFront
Date: Tue, 10 Mar 2026 06:49:52 GMT
Location: https://www.example.com/
X-Cache: Miss from cloudfront
Via: 1.1 7b6afd329ec93047d9d66526d7d0c22c.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: KIX82-P4
X-Amz-Cf-Id: 4mLBz1GEN-yMCLuZJZhXN-GqshxWvScxGgL4rNWGfyXsU7sVj86Kjw==
$ curl -sI "https://xxxxxxxxxxxxxx.cloudfront.net/external/some/path"
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Connection: keep-alive
Server: CloudFront
Date: Tue, 10 Mar 2026 06:49:52 GMT
Location: https://external-site.example.com/some/path
X-Cache: Miss from cloudfront
Via: 1.1 24dbe851fbf0a37d67de659f1f3828f6.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: KIX82-P4
X-Amz-Cf-Id: KYgxTjt49CsWc0ZFCwJ8lYNT8w1GJmq85N67iFY8W3dmwSlmF4T48g==
Lambda@Edgeは、CloudFront Functionsとは違ってnpmライブラリなども使用可能です(ただし、後述の通りLambdaレイヤーが使えないので、デプロイパッケージに含める必要あり)。
上述でちょくちょく触れましたが、Lambda@Edgeは制約が非常に多いです。通常のLambda関数のクオータ(参考:Lambda クォータ - AWS Lambda)に加えて、Lambda@Edge特有の制限があります。一部抜粋だけでも、Lambda@Edgeにはこれだけ特有の制約があります。
- Lambda関数のデプロイリージョンはバージニア北部(us-east-1)のみ
- オリジンドメインのDNSサービス障害時は呼び出し不可
- レスポンスのHTTPステータスコードは変更不可
- Lambda関数の番号付きバージョン必須(
$LATESTは使用不可) - VPCへのアクセスは不可
- 環境変数の使用不可(コードに埋め込むか、SSM Parameter Store等から取得する必要あり)
- Lambdaレイヤーは使用不可
- AWS X-Rayは使用不可
- プロビジョニング済み同時実行不可
- コンテナイメージ不可
- arm64アーキテクチャ不可
- エフェメラルストレージ上限は512MB
- ランタイムは最新バージョンのNode.jsかPythonのみ
他にも細かい制約がありますので、ブラウザリダイレクトをLambda@Edgeで実装する場合は必ず確認するようにしましょう。
それぞれの制約のバランスを考える必要がありそう
以上、AWSでブラウザリダイレクトを実現する方法を制約ベースでまとめてみました。
今回紹介した制約以外にも、要件によって許容できる制約・できない制約があるかと思います。本記事を参考に公式ドキュメントなども読んでいただいた上で、技術選定を実施いただければと思います。






