AWSにおけるドメインリダイレクト手法について整理してみた

Posted at 2025-02-15

本サイトの「ドメイン」は「Zone Apex」を意味します。
ホスト名を含むFQDNではないためご注意ください。

概要

ドメインリダイレクトの仕組みをAWSサービスで実装する機会があり、そもそもAWSサービスでドメインリダイレクトを実装するときの手法って何があるか調べたので備忘録としてまとめておきます。

ドメインリダイレクトとは

ユーザーからブラウザで、あるドメイン(例. oldsite.com)にアクセスした際、別のドメイン(例. newsite.com)へリクエストを自動転送する仕組みです。
イメージはこんな感じです。

最終的には、ユーザーから見ると初めにアクセスしたドメインとは異なるドメインのURLへアクセスすることになります。「サーバー移行して既存のドメインを変更したけど、ユーザーからは既存のドメインでアクセスさせたい」などの要望がある場合に利用を検討するかと思います。

CNAMEとの違い

以下のサイトが非常にイメージが湧く内容だったので載せさせていただきます
結論、同一ドメインにおけるホストの別名を定義するためのレコードであり、別ドメインへのリダイレクトはできません。

AWSにおける実現方法

S3 静的ウェブサイトホスティングのリダイレクト機能

S3の機能の一つである、静的ウェブサイトホスティング(S3に配置した静的ファイルをWEBサイトとして公開する機能)のオプションとして用意されているリダイレクト機能を使用する方法です。

バケットのプロパティタブの設定にある「静的ウェブサイトホスティング」を有効化することで発行される、AWSリージョン固有のウェブサイトエンドポイントへのリクエストに対してのみ、別のバケットもしくはドメインにリダイレクトすることができます。

# ウェブサイトエンドポイント形式(リージョンにより形式が異なる)
http://bucket-name.s3-website-Region.amazonaws.com
# or
http://bucket-name.s3-website.Region.amazonaws.com

リダイレクト設定は大きく3つ

バケット全体(ウェブサイトエンドポイント)に対する設定

ウェブサイトエンドポイントへの全てのリクエストがリダイレクトされる設定です。URLにどんなPathが含まれていても、リダイレクト先として設定したホスト名にリダイレクトされます。
ホスティングタイプは「オブジェクトのリクエストをリダイレクトする」になります。

リクエスト条件に応じた設定(リダイレクトルール)

Json形式のリダイレクトルールにマッチするリクエストがウェブサイトエンドポイントにされた時、リダイレクト先として設定したホスト名にリダイレクトされます。
ルールとしては、「URLのPath(オブジェクトキー)」「URLのPath(Prefix)」「ウェブサイトエンドポイントへのリクエストに対するレスポンスコード」があります。
リダイレクトルールに一致しないリクエストは、通常のウェブサイトエンドポイントへのリクエストとして処理されます。
ホスティングタイプは「静的ウェブサイトをホストする」になります。

個々のオブジェクトに対する設定(オブジェクトメタデータ)

オブジェクトごとにリダイレクトを設定する方式です。ホスティングタイプは「静的ウェブサイトをホストする」になります。
オブジェクトに対してユーザー定義タイプのメタデータを付与することで、設定した値のホスト名にリダイレクトされます。オブジェクトを含めたリクエストがウェブサイトエンドポイントにされた時、リダイレクト先として設定したホスト名にリダイレクトされます。

# キー: 値
x-amz-website-redirect-location: https://www.example.com

メタデータは、オブジェクトアップロード時のオプションで付与できます。

既存のオブジェクトに対しても付与は可能ですが、5GB未満の場合はコピーアクションを使用して付与することが可能です。詳細は公式ドキュメントを参照してみてください。

難点：ウェブサイトエンドポイントへのリクエストはHTTPのみサポート

ドキュメントに記載がある通り、ウェブサイトエンドポイントへのリクエストはHTTPのみサポートされており、HTTPSでのリクエストができません。つまり、ユーザーからウェブサイトエンドポイント間の通信はHTTPとなり、盗聴のリスクがあります。
そのため後述しますが、ユーザーのリクエストをHTTPS化する場合は、ユーザーとウェブサイトエンドポイントの間にAmazon CloudFront(後述)もしくはAmazon API Gateway(省略)を挟む必要があります。

Amazon S3 ウェブサイトエンドポイントは HTTPS またはアクセスポイントをサポートしていません。

CloudFront + S3 静的ウェブサイトホスティングのリダイレクト機能

S3静的ウェブサイトホスティングのリダイレクト機能を使用しつつ、ユーザーからのリクエストをHTTPS化する際の構成です。CloudFrontのCustom Originにウェブサイトエンドポイントを指定します。
CloudFrontにてリダイレクトの設定をするわけではなく、SSL終端した通信をウェブサイトエンドポイントに転送するのみです。

難点：Origin Access Identity(OAI)/Origin Access Control(OAC)が使えないのでバケットポリシーでCloudFront経由のアクセスだけに絞れない

OAI/OACについての詳細は割愛しますが、ウェブサイトエンドポイントに対するOAI/OACは設定できません。
OAI/OACが設定できるのはREST APIエンドポイントのみです。

REST APIエンドポイントとは、バケット固有で存在するHTTPSアクセス時に使用するURLのことです。

バケットポリシーのPrincipalやConditionでのCloudFront経由のみのアクセスに制御することは現状厳しい。
少しでもセキュリティ強度を上げる方法としては、CloudFrontでカスタムヘッダーを付与しバケットポリシーのConditionで制御することくらいですが完全ではありません。

Amazon CloudFront Edge Computing

CloudFrontはキャッシュを使った静的・動的コンテンツの高速配信を可能にするサービスです。
キャッシュを保持する場所は、エッジロケーションに加えリージョン別エッジキャッシュでも保持する多段構成となっています。
後述する2つの機能は、適用できる場所が異なります。

CloudFront Functions

CloudFront Functionsは、エッジロケーションにおけるビューワーリクエスト及びビューワーレスポンスに対して処理を実行します。実行可能時間が1ミリ秒未満という制約はありますが、リダイレクトさせるだけの軽量な処理であれば問題はないと思います。

CloudFront + Lambda@Edge

Lamda@Edgeは、リージョン別エッジキャッシュにおけるビューワー及びオリジンのリクエスト/レスポンスに対して処理を実行します。CloudFront Functionsでは処理しきれないような高度な処理が必要な場合に利用を検討するかと思います。

Application Load Balancing

ALBのリスナーに紐づけるリスナールールでリダイレクト設定する方法です。
設定詳細は割愛しますが、リクエストのPathに対してや、全てのリクエストに対してリダイレクトの設定をすることが可能です。

まとめ

今回はAWSにおけるドメインリダイレクト手法について簡潔ではありますが整理してみました！
ちょっとボリューミーではありますが、少しでも誰かの役に立てば幸いです。