Amazon Web Services ブログ
2025 年版 – ALB、S3、PrivateLink による閉域静的ウェブサイトのホスティング
はじめに
近年、金融機関や公共機関をはじめとする多くの組織では、クラウドネイティブなアプリケーション構築のメリットが広く認識され始めています。一方で、セキュリティやガバナンス上の理由から、依然として「インターネットに接続しない閉域環境でのシステム構築」が求められるケースも少なくありません。
特に Web アプリケーションを閉域環境で提供する場合、静的コンテンツのホスティングをどのように実現するかが課題となります。これまで、ALB（Application Load Balancer）、S3、PrivateLink を組み合わせて閉域環境で SPA（Single Page Application）をホスティングする構成が一般的に利用されてきました（参考：ALB、S3、PrivateLinkによる内部 HTTPS 静的ウェブサイトのホスティング）。
しかし、この構成には S3 のバケット名と ALB のカスタムドメイン名を一致させる必要があるという制約が存在していました。2025 年 10 月 15 日に Application Load Balancer の「URL およびホストヘッダーの書き換え機能」が追加され、この制約が解消されました。アップデートの詳細については下記の記事をご参照ください。
参考：AWS Application Load Balancer で URL とホストヘッダーの書き換えが可能に
本記事では、これまで紹介してきた閉域 SPA 構成をベースに、新たな ALB の機能を活用した最新アーキテクチャと、その仕組みがどのように成り立っているのかを解説します。
全体構成
以下は、閉域環境で静的ウェブサイトをホスティングする構成例です。
この構成では、ALB・S3・PrivateLink を組み合わせて、インターネットに接続せずに HTTPS での静的コンテンツ配信を実現しています。設定のポイントは以下のとおりです。
- ALB の IP ターゲットとして S3 の Interface Endpoint の IP アドレスを登録
- リスナールールにホストヘッダー・URL 変換のルールを追加
次の章では、それぞれの設定ポイントについて詳しく解説します。
ALB のターゲットに S3 の Interface Endpoint の IP を登録
S3 には Gateway Endpoint と Interface Endpoint の 2 種類の VPC エンドポイントが存在します。この構成では、Interface Endpoint のプライベート IP アドレスを ALB のターゲットとして登録します。
Interface Endpoint のネットワークインターフェイスは、VPC エンドポイントの存続期間中は同じプライベート IP アドレスを維持するため、安定したルーティングが可能です。
設定のポイントとして、ALB のヘルスチェックは GET メソッドで実行されますが、S3 の Interface Endpoint へのリクエストはリダイレクト（307）で返されるため、ヘルスチェックの正常判定コードを 307 に設定する必要があります。
例えば、curl コマンドで S3 の Interface Endpoint へアクセスした例を見てみましょう。
$ curl -v 10.0.1.xx
* Trying 10.0.1.xx:80...
* Connected to 10.0.1.xx (10.0.1.xx) port 80
> GET / HTTP/1.1
> Host: 10.0.1.xx
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< x-amz-id-2: TS9ySeNbBtaQsWaK1EZ3WyKR2lkgQ5bm4llTfUX+TTjFfCuIxxxxxxxxxxxxxxx=
< x-amz-request-id: GDV3AZME5xxxxxx
< Date: Tue, 04 Nov 2025 05:25:14 GMT
< Location: https://aws.amazon.com/s3/
< Content-Length: 0
< Server: AmazonS3
これを踏まえ、Target Group のヘルスチェックの設定例は下記のようになります。
プロトコルは HTTP、ポート番号は 80 番、ヘルスチェックの成功コードは 307 を設定しています。
リスナールールとホストヘッダー変換
ALB にアクセスした際、リクエストのホストヘッダーには通常、ALB 側で設定されたカスタムドメイン名が含まれます。一方、S3 の Interface Endpoint ではホストヘッダーを元にアクセス先のバケットを特定します。
例えば、VPC Endpoint 経由で sample-bucket という名前の S3 バケットへアクセスしたい場合はホストヘッダーにバケット名を入れる必要があります。この際、VPC Endpoint へのアクセスは IP アドレスでも構いません。
curl -v \
http://10.0.1.xx/test.txt \
-H "Host: sample-bucket"
そのため、従来の構成では ALB のドメイン名と S3 バケット名を一致させる必要がありました。今回追加された ALB の「ホストヘッダー書き換え」機能を利用することで、ALB 内でホストヘッダーを動的に変換できるようになり、ALB のカスタムドメイン名と S3 バケット名を一致させる制約が不要になりました。
設定例は下記の通りです。「トランスフォームホストヘッダー」においてホストヘッダーを S3 のバケット名へ変換しています。
これにより、運用や証明書管理の柔軟性が大きく向上します。
SPA 側の考慮事項
フロントエンドのライブラリで URL のパスに依存するようなルーティングを行なっている場合（React の場合、BrowserRouter など）、/index.html 以外のパスに直接アクセスした場合に XML のエラーが表示されます。
この場合、URL のハッシュを利用したルーティング（React の場合、HashRouter など）を利用することで、トップページ以外へも URL で直接アクセスができるようになります。URL の表示は https://app.example.local/index.html#/about のようになります。
また、今回導入された URL パス変換の機能を利用すれば、app.example.local/ のように URL を表示することができます。
-
- リスナールールの設定例
-
- SPA の画面表示例
URL のハッシュを利用したルーティングをしている場合は、URL の表示は https://app.example.local/#/about のようになります。
ただし、ハッシュを利用したルーティングを利用している場合でも、存在しない URL へ直接アクセスした場合（例: app.example.local/test）は XML のエラーが表示される点には注意が必要です。
まとめ
本記事では、ALB の URL・ホストヘッダー書き換え機能を活用した、閉域環境での最新の静的ウェブホスティング構成を紹介しました。このアップデートにより、これまで制約となっていた S3 バケット名とカスタムドメイン名の一致要件が解消され、閉域環境でもより柔軟でシンプルなサーバーレス構成が可能になりました。
金融・公共分野をはじめ、セキュリティ要件の高い環境でのクラウド利用において、ぜひこのアーキテクチャをご活用ください。
参考情報
著者について