S3静的ウェブサイトホスティングのリダイレクト設定はPOSTリクエストに対応しているの確認してみた

S3静的ホスティングのリダイレクト機能のPOSTリクエスト処理について検証してみました。S3リダイレクトの制限とCloudFront Functionsが必要になるケースを解説します。
2025.10.26
CloudFront経由でWEBサイトを配信している場合、ドメインA（sampleweb1.said.com）をドメインB（www.said.com）にリダイレクトする方法はいくつかあります。

代表的なのはCloudFront FunctionsやLambda@Edgeを使う方法ですが、単純なドメイン間リダイレクトであれば、S3静的ウェブサイトホスティングのリダイレクト機能でもシンプルに実現できるのではないかと考えました。
ただし、S3のリダイレクト機能がGETリクエストだけでなくPOSTリクエストにも対応しているのかが気になったため、実際に検証してみることにしました。
 先に結論検証の結果、S3静的ウェブサイトホスティングで許可されているHTTPメソッドはGET, HEAD, OPTIONSのみであることがわかりました。
フォーム送信などPOSTを含むサイトのドメインリダイレクトには、CloudFront FunctionsまたはLambda@Edgeが必要です。
では実際の挙動を確認していきます。
 やってみる
上記のような構成で、sampleweb1.said.comをwww.said.comへとリダイレクトする設定をしていきます。
 S3の作成まずはリダイレクト用のS3バケットを作成します。
適切な名前を付けてACLは無効のままで作成します。
静的ホスティングを行いたいので、今回ブロックパブリックアクセス設定はオフにします。

「パブリックアクセスのブロックをすべてオフにすると、このバケットとバケット内のオブジェクトが公開される可能性があります。」にチェックを入れましょう。
他の設定はデフォルトで一旦作成します。
静的ホスティングを行う場合は、バケットポリシーを下記のように編集します。
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::作成したバケット名/*"
            ]
        }
    ]
}
プロパティタブを一番下までスクロールすると静的ウェブサイトホスティングの設定欄があるので有効化しましょう。
ホスティングタイプはオブジェクトのリクエストをリダイレクトするに設定し、リダイレクト先のホスト名を記入します。

今回はwww.said.comにリダイレクトしたいので、www.said.comを記入します。

CloudFrontで配信をしており、HTTPSでのアクセスが前提のためプロトコルはHTTPSを選択します。
これで静的ホスティングの準備は完了です。

設定が完了するとパブリックウェブサイトエンドポイントが表示されるようになります。
このエンドポイントをオリジンとしたCloudFrontを作成し、リダイレクトしたいドメインを代替ドメインとして登録することでドメインのリダイレクトが可能です。
 ディストリビューション作成次にディストリビューションを作成していきます。
適切な名前を付け、Custom domainにリダイレクトさせたいドメインを記入します。今回sampleweb1.said.comとなります。
Origin typeはS3で、S3 originには先ほど作成したS3のパブリックウェブサイトエンドポイントを記入します。

※Browses S3から対象バケットを選択するのではなくパブリックウェブサイトエンドポイントを記入してください。
キャッシュ設定はカスタムします。

HTTP→HTTPSのリダイレクトはディストリビューション側で行います。
HTTPメソッドは、POSTに対応しているのかを確認したいので「GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE」を選択します。

キャッシュは必要ないのでキャッシュポリシーは「CachingDisabled」とします。
今回はWAFやOACの設定をしていませんが、必要に応じてセキュリティ対策を行ってください。
最後に適切な証明書を設定します。
しばらくCloudFrontを触っていませんでしたがドメインを登録すると自動的にアカウント内のバージニア北部リージョンのACMに登録されてる該当の証明書が選択されるようになっていました。

便利でいいですね。
DNS設定を行って準備完了です。

私はドメインをRoute53で管理しているのでエイリアスレコードでCloudFrontディストリビューションにドメインを関連付けます。
ではテストしてみましょう。
 確認 GETリクエスト$  curl -I https://sampleweb1.said.com/
HTTP/2 301
content-length: 0
location: https://www.said.com/
date: Fri, 24 Oct 2025 12:42:46 GMT
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 ca2dbad52453a70499700112dd35023c.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P8
x-amz-cf-id: vBCLGRmAd5yo2jgwJ5UceXvjDwPlmmJiiAh_PZkLDyv41cdYbzHUnQ==
S3が301リダイレクトを返していますね。

www.said.comへリダイレクトされています。
ではパスは保持されるのかを確認します。
$ curl -I https://sampleweb1.said.com/test.html
HTTP/2 301
content-length: 0
location: https://www.said.com/test.html
date: Fri, 24 Oct 2025 12:43:19 GMT
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 b5241e5e1af7d07ac0cadb805cbe4594.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P8
x-amz-cf-id: v5rB3OHB-AdILdXP-6OSvfHlGLr40JBAG_sXeOHFuJaUX4eLjypVLg==
パスの保持も問題ありません。

クエリストリングの保持はどうでしょうか。
$ curl -I "https://sampleweb1.said.com/?param1=value1&param2=value2"
HTTP/2 301
content-length: 0
location: https://www.said.com/
date: Fri, 24 Oct 2025 12:43:26 GMT
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 ca2dbad52453a70499700112dd35023c.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P8
x-amz-cf-id: sw9qvNSSrvgOM650A2K-uzwE2nG4zF7KnM95x9P57RCtxsbjkI4mpw==
locationの項目を確認してみましょう。クエリストリングは保持されず、https://www.said.com/となってしまっていますね。

クエリストリングの保持をしたい場合はCloudFrontFunctionsやLambda@Edgeを使用したリダイレクトが必要そうです。
 POSTリクエストではPOSTリクエストはどうでしょうか。
$ curl -X POST -d "test=data" -i https://sampleweb1.said.com/
HTTP/2 405
content-type: text/html; charset=utf-8
content-length: 442
allow: GET, HEAD, OPTIONS
date: Fri, 24 Oct 2025 12:45:12 GMT
server: AmazonS3
x-cache: Error from cloudfront
via: 1.1 b5241e5e1af7d07ac0cadb805cbe4594.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P8
x-amz-cf-id: YSIfmpDkrH4rvSXfyD9t3AVWaOa6eiiJNSrGdxlpnDPH7d22VTqexA==

<html>
<head><title>405 Method Not Allowed</title></head>
<body>
<h1>405 Method Not Allowed</h1>
<ul>
<li>Code: MethodNotAllowed</li>
<li>Message: The specified method is not allowed against this resource.</li>
<li>Method: POST</li>
<li>ResourceType: OBJECT</li>
<li>RequestId: Y1CYEN4010361K0D</li>
<li>HostId: y/0Z6nS8NT7Pk6ab8CFfwPyU0ZgqSvUPpDju3Pq1lmM7buTp0pYfs0tU/4A6iKGMhiBItwfQWTFxJmNBVGb0tklWfwztLD7f</li>
</ul>
<hr/>
</body>
</html>
S3が405を返していますね。

x-cacheの値がError from cloudfrontとなっており、これはオリジン（S3）がエラーレスポンス（4xx/5xx）を返したことを示しています。正常なレスポンスの場合はMiss from cloudfrontとなります。
allow: GET, HEAD, OPTIONS の部分を確認するとAllowヘッダーで、許可されているメソッドが明示されています。

CloudFrontではPOSTメソッドも許可したはずですよね。
どうやらS3静的ウェブホスティングで許可されているメソッドはGET, HEAD, OPTIONSだけでPOSTが許可されていないようです。

つまり、CloudFrontではPOSTを許可していても、オリジンのS3がPOSTを拒否するため、リダイレクト処理に到達する前にエラーになってしまいます。
POSTリクエストにも対応したい場合もCloudFrontFunctionsやLambda@Edgeを使用したリダイレクトが必要そうです。
 まとめドキュメントには2025年10月現在、明記されている部分が見つけられませんでしたが、検証の結果、S3静的ウェブサイトホスティングで許可されているHTTPメソッドはGET, HEAD, OPTIONSのみでした。

POSTリクエストに対応する必要がある場合、S3リダイレクトは使えません。
S3リダイレクトが使えるのは下記の場合でした。
GETリクエストだけで完結するサイト
クエリストリングが不要な静的コンテンツ
設定をできるだけシンプルにしたい場合
動的なWebアプリやフォーム機能があるサイトには適していませんね。

この記事がPOSTリクエストやクエリストリングの保持という要件に対応したい場合のリダイレクト設定について検討されている方のお役に立てれば幸いです。