terraform applyは成功している。

GitHub Actionsも成功している。

S3にはファイルが存在する。

でも、個別記事のURLにアクセスすると403が返ってくる。

トップページは表示される。記事一覧も表示される。でも/posts/helloにアクセスすると403。なぜ。

Terraform + GitHub Actionsでデプロイパイプラインを組んだ直後にこの403に直面した。この記事は、その原因を突き止めるまでに半日かかった話だ。

環境

フロントエンド: Next.js（静的エクスポート）
ホスティング: S3 + CloudFront
IaC: Terraform
デプロイ: GitHub Actions

症状

デプロイ直後から、個別記事のURLだけ403になっていた。

https://example.cloudfront.net/          → 200 OK
https://example.cloudfront.net/posts/    → 200 OK
https://example.cloudfront.net/posts/hello → 403 Forbidden

トップページと一覧ページは問題ない。個別記事だけ403。

試したこと（全部外れ）

403だから、最初は権限の問題だと思った。S3バケットポリシー、OAC、CloudFrontのキャッシュ。全部疑った。でも原因はURLリライトだった。

CloudFrontのキャッシュを疑った

まず思ったのはキャッシュだった。

aws cloudfront create-invalidation \
  --distribution-id XXXXXXXXXXXXXX \
  --paths "/*"

無効化しても直らない。

S3のバケットポリシーを疑った

CloudFrontからS3へのアクセスが拒否されているのかと思い、バケットポリシーを確認した。OACの設定も確認した。問題なかった。

S3上のファイルの存在を確認した

aws s3 ls s3://my-blog-bucket/posts/hello/

hello/index.htmlは存在する。ファイルはある。でも403になる。

CloudFrontのエラーページ設定を疑った

カスタムエラーページの設定が悪さをしているのかと思い、確認した。問題なかった。

原因

1時間以上調べてようやく気づいた。

Next.jsの静的エクスポートの仕組みの問題だった。

Next.jsをoutput: 'export'で静的エクスポートすると、/posts/helloというURLは/posts/hello/index.htmlとしてファイルが生成される。CloudFrontはデフォルトでは、/posts/helloというリクエストに対してS3の/posts/helloというキーを探しに行く。でもそんなキーは存在しない。

トップページが表示されていたのは、CloudFrontのdefault_root_objectにindex.htmlを指定していたから。でもサブパスにはその設定が効かない。

解決策：CloudFront FunctionでURLを書き換える

CloudFrontにはViewerリクエストをフックしてURLを書き換える仕組みがある。それがCloudFront Functionだ。

リクエストが来たタイミングで、/posts/helloを/posts/hello/index.htmlに書き換えてからS3に渡す。

// functions/url-rewrite.js
async function handler(event) {
  const request = event.request;
  const uri = request.uri;

  // 拡張子がある場合はそのまま通す（CSS、JS、画像など）
  if (uri.match(/\.[a-zA-Z0-9]+$/)) {
    return request;
  }

  // トレイリングスラッシュがある場合はindex.htmlを追加
  if (uri.endsWith('/')) {
    request.uri += 'index.html';
    return request;
  }

  // それ以外は/index.htmlを追加
  request.uri += '/index.html';
  return request;
}

そしてTerraformでこのFunctionをCloudFront Distributionに関連付ける。

resource "aws_cloudfront_function" "url_rewrite" {
  name    = "url-rewrite"
  runtime = "cloudfront-js-2.0"
  publish = true
  code    = file("${path.module}/functions/url-rewrite.js")
}

resource "aws_cloudfront_distribution" "blog" {
  # ... 省略 ...

  default_cache_behavior {
    # ... 省略 ...

    function_association {
      event_type   = "viewer-request"
      function_arn = aws_cloudfront_function.url_rewrite.arn
    }
  }
}

本当の詰まりポイント：Functionが存在しなかった

ここまで読んだ人は「それで解決したの？」と思うかもしれない。

違う。もう一段あった。

TerraformにはCloudFront Function用のコードファイル（url-rewrite.js）は置いていた。でもTerraformリソースとして管理しておらず、AWS上にFunctionが作成されていなかった。さらにDistributionとの関連付けも存在しなかった。

ファイルはある。でもTerraformが管理していないので、AWSには何も作られていない。

症状は変わらず403のまま。

# FunctionがAWS上に存在するか確認
aws cloudfront list-functions

# 出力にurl-rewriteが存在しない

terraform planで確認すると、Functionがcreateされていないことが分かった。

terraform plan

# Plan: 1 to add, 1 to change, 0 to destroy.
# + aws_cloudfront_function.url_rewrite（作成されていなかった）
# ~ aws_cloudfront_distribution.blog（function_associationを追加）

terraform applyを実行してFunctionを作成し、Distributionに関連付けた。

terraform apply

# Apply complete! Resources: 1 added, 1 changed, 0 destroyed.

これで個別記事が表示されるようになった。

まとめ：原因は2層あった

振り返ると、問題は2層に重なっていた。

第1層：Next.jsの静的エクスポートとCloudFrontのURLマッピングの不一致

/posts/helloというリクエストに対して、S3に/posts/hello/index.htmlが存在してもCloudFrontが見つけられない。CloudFront Functionでのリライトが必要。

第2層：CloudFront FunctionがTerraformの管理対象になっていなかった

URLリライト用のJavaScriptファイルは存在していたが、aws_cloudfront_functionリソースとして定義されておらず、AWS上にはFunction自体が作成されていなかった。また、CloudFront Distributionとの関連付けも存在しなかった。

どちらか片方だけ解消しても直らない。両方を解消して初めて動いた。

教訓

CloudFrontで静的サイトをホストするときは、最初からCloudFront FunctionでURLリライトを設定する
Terraformでコードを書いたら、terraform planで作成・更新されるリソースを確認する。意図したリソースが差分に出ているかを確認してからterraform applyする
403の原因はS3ポリシーだけではない。URLマッピングの問題も疑う

半日かかったが、おかげで以前よりも、Terraformのplan/applyの重要性とCloudFront Functionの役割を理解できた。

詰まった時間は無駄じゃなかった、と思うことにしている。

こうしてブログの土台が整ったところで、次は実際にAWS上で動くサービスを作り始めた。その話は介護士がAWSでAI事故報告支援ツールを作った話に書く。

この記事は筆者のブログからの転載です → 元記事