ALBでドメイン統合!URL・ホストヘッダー書き換えをTerraformコードで設定してみた
はじめに
2025年10月のアップデートにより、ALBでURLとホストヘッダーの書き換えが可能となりました。
今回は、アップデートされた機能を使用したTerraformコードをもとに、どのような点で便利になったのか解説します。
背景
解説を進めていく中で解決したい課題を先に提示した方がわかりやすいため、背景として先に解決したい課題を記載します。
- SEO評価(ドメインパワー)の維持と最大化
- 別ドメイン(example.net)のコンテンツを、評価の高い既存ドメイン(example.com)のサブディレクトリとして公開することで、既存のSEO資産を有効活用したい。
- ユーザー体験(UX)の統一
- コンテンツの実体が別ドメインであっても、ユーザーのブラウザ表示URLを固定し、サイト移動による違和感を与えたくない。
※わかりにくいので補足
ユーザーから見えるサイトアドレス
- example.com/example-path
裏側での処理
- example.com/example-path → example.net/example-pathへホストヘッダーを変換します。
- ユーザーには、example.com/example-pathのアドレスでexample.net/example-pathサイトを表示します。
フローチャート
簡単なフローチャートを用意しました。
参考になれば幸いです。
前提条件
- 「ALBでURLとホストヘッダーの書き換え」についてのTerraformコード部分のみ抜粋するため、Terraformの基礎的な知識がある前提としています。
- AWS各コンポーネントの周辺知識は、解説しません。
- EC2側でApacheを利用しており、ヘッダー書き換え部分のみの紹介にとどめ、周辺知識の解説はしません。
Terraformコード
Terraformを使用してAWS Application Load Balancer(ALB)のリスナールールを設定する例です。
特定のドメイン名やパスに一致するリクエストを検知し、転送先のターゲットグループへ書き換え処理(URL・ホスト名のリライト)を定義する内容になっています。
Terraform AWSプロバイダーバージョン6.19.0以降で利用可能となっています。
試す際には、Terraform AWSプロバイダーのバージョンを確認するようにしてください。
# ALBリスナールールの例: 特定ホスト/パスへのリクエストを別ドメイン・パスへ書き換えて転送
resource "aws_lb_listener_rule" "example_rule" {
# 適用するリスナーのARNと評価順序を指定
listener_arn = aws_lb_listener.example.arn
priority = 50
# 転送アクション: マッチしたリクエストを指定ターゲットグループへフォワード
action {
type = "forward"
target_group_arn = aws_lb_target_group.example.arn
}
# 条件1: Hostヘッダーが example.com / www.example.com に一致
condition {
host_header {
regex_values = ["^(www\\.)?example\\.com$"]
}
}
# 条件2: パスが /example-path から始まるものに一致
condition {
path_pattern {
regex_values = ["^\\/example-path"]
}
}
# 変換1: Hostヘッダーを書き換え (例: example.com -> example.net)
transform {
type = "host-header-rewrite"
host_header_rewrite_config {
rewrite {
regex = "^(www\\.)?example\\.com$"
replace = "example.net"
}
}
}
# 変換2: パスを書き換え (例: /example-path* -> /example-path*)
transform {
type = "url-rewrite"
url_rewrite_config {
rewrite {
regex = "^\\/example-path"
replace = "/example-path"
}
}
}
}EC2側設定(Apache)
example.comサイトは、Movable Typeを利用したサイトです。
example.netサイトは、WordPressを利用したサイトです。
ALBからホストヘッダーを変換した値(example.net)をApache側で受け取ります。
受け取ったホストヘッダーに基づいてApacheがルーティング処理を行います。
WordPress内部でexample.comとして処理させる必要があります。
RequestHeader set Host "example.com"を、example.netのVirtualHost内に設定します。
正常に動作しない場合は、RequestHeader set Hostにearlyを付けることで解決できる可能性があります。
earlyを付けることで、確実にWordPressへ伝えることが可能となります。
earlyについては、筆者が動作確認していないため、付ける際はご注意ください。
- フローチャート
EC2からWordPressへのフロー部分を表した図になります。
RequestHeaderを記述することで、WordPress内で動的生成されるURLがexample.com基準となります。
これにより、CORSエラーやリンク生成に不整合が発生しなくなります。
また、WP_HOMEやWP_SITEURL等に関しても、example.comに合わせておく必要がある点に注意してください。
利点
書き換え処理(URL・ホスト名のリライト)機能の追加アップデートにより、EC2側でのRewrite処理やプロキシ設定が不要となり、設定の簡素化につながります。
マイクロサービス向けのアーキテクチャ構成であれば、今回のアップデートにより専用のプロキシサーバを介する必要がなくなるため、よりスマートな構成にできます。
欠点
EC2前提のサービス提供の場合、ALBでの書き換え処理(URL・ホスト名のリライト)設定とEC2側の設定で分離されるため、ALBとEC2双方の設定を意識した運用が必要になります。
まとめ
ALBでの書き換え処理(URL・ホスト名のリライト)およびEC2側での内部処理によって、example.netのコンテンツをあたかもexample.comのコンテンツとして処理できます。
Apache設定やコンテンツ側の変更により、ユーザーに対して統一されたコンテンツとして見せることができます。
多岐にわたる設定や変更が必要になるため、実施する際には検証が必須となります。



Share this page