
## S3 のパブリックアクセスブロックの 4 つの各設定項目の挙動を確認してみた背景

以下の画面は Amazon S3 のパブリックアクセスブロックの設定画面です。
各設定に関して日本語で書かれていますが、わかりづらく、挙動の想像がつかないので、実際に各設定の挙動を確認してみた。

![パブリックアクセスブロックの設定画面](/images/posts/tech-posts/1641291341/public_access.png)

## S3 のパブリックアクセスブロックの 4 つの各設定項目

### 新しいアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする ( BlockPublicAcls )

`BlockPublicAcls` についてドキュメントでは以下のように記載しています。

[Amazon S3 ストレージへのパブリックアクセスのブロック \- Amazon Simple Storage Service](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-control-block-public-access.html)

> このオプションを TRUE に設定すると、次のように動作します。
> ・ 指定されたアクセスコントロールリスト (ACL) がパブリックの場合、PUT Bucket acl 呼び出しと PUT Object acl 呼び出しは失敗します。
> ・ リクエストにパブリック ACL が含まれていると、PUT Object 呼び出しは失敗します。
> ・ この設定がアカウントに適用されている場合、リクエストにパブリック ACL が含まれていると PUT Bucket の呼び出しは失敗します。

とりあえず PUT Object (アップロード) ができなくなるようです。

検証準備します。
`BlockPublicAcls` をオフの状態でオブジェクト A にオブジェクト ACL でパブリックアクセスを許可します。
この設定により、オブジェクト A にオブジェクト URL で外部からアクセスが可能になります。

![パブリックアクセス許可](/images/posts/tech-posts/1641291341/public_access_ok.png)

`BlockPublicAcls` をオンにします。

![BlockPublicAclsの有効化](/images/posts/tech-posts/1641291341/block_public_acls_on.png)

#### 検証 1: オブジェクト A のオブジェクト URL にアクセスする

オブジェクト A が正常に表示されました。
どうやら既存のオブジェクトには影響がなし。

#### 検証 2: オブジェクト B をプライベート設定でアップロードする

以下のようにプライベート設定でのアップロードは成功しました。

![プライベート設定](/images/posts/tech-posts/1641291341/private_off.png)

#### 検証 3: オブジェクト B をパブリック設定でアップロードする

以下のようにパブリック設定でのアップロードはエラーが発生しました。
どうやら新規のオブジェクトをパブリック設定でのアップロードを防ぐようです。

![パブリック設定](/images/posts/tech-posts/1641291341/private_on.png)

### 任意のアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする ( IgnorePublicAcls )

`IgnorePublicAcls` についてドキュメントでは以下のように記載しています。

[Amazon S3 ストレージへのパブリックアクセスのブロック \- Amazon Simple Storage Service](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-control-block-public-access.html)

> このオプションを TRUE に設定すると、Amazon S3 はバケットとそれに含まれるオブジェクトのすべてのパブリック ACL を無視します。この設定を使用すると、パブリック ACL を含む PUT Object 呼び出しを許可しながら、ACL によって許可されたパブリックアクセスを安全にブロックできます (BlockPublicAcls はパブリック ACL を含む PUT Object 呼び出しを拒否します)。この設定を有効にしても、既存の ACL の永続性には影響せず、新しいパブリック ACL の設定も妨げられません。

とりあえず全てのオブジェクトのパブリック設定が無視されるようです。

検証準備します。
`IgnorePublicAcls` をオフの状態でオブジェクト A にオブジェクト ACL でパブリックアクセスを許可します。
この設定により、オブジェクト A にオブジェクト URL で外部からアクセスが可能になります。

![パブリックアクセス許可](/images/posts/tech-posts/1641291341/public_access_ok.png)

`IgnorePublicAcls` をオンにします。

![IgnorePublicAclsの有効化](/images/posts/tech-posts/1641291341/ignore_public_acls_on.png)

#### 検証 1: オブジェクト A のアクセス許可を確認

パブリックアクセスの許可が上書きされ、パブリックアクセスできなくなっています。

![上書き後のアクセス許可画面](/images/posts/tech-posts/1641291341/overwrite_public.png)

#### 検証 2: IgnorePublicAcls をオフにしてオブジェクト A のアクセス許可を確認

パブリックアクセスの許可が `IgnorePublicAcls` をオンによる上書き前の設定に戻りました。

![上書き前のアクセス許可画面](/images/posts/tech-posts/1641291341/public_access.png)

### 新しいパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする ( BlockPublicPolicy )

`BlockPublicPolicy` についてドキュメントでは以下のように記載しています。

[Amazon S3 ストレージへのパブリックアクセスのブロック \- Amazon Simple Storage Service](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-control-block-public-access.html)

> バケットに対してこのオプションを TRUE に設定すると、Amazon S3 は、指定されたバケットポリシーでパブリックアクセスが許可されている場合に、PUT バケットポリシーの呼び出しを拒否します。また、指定されたポリシーでパブリックアクセスが許可されている場合に、バケットのすべてのアクセスポイントで PUT アクセスポイントポリシーの呼び出しを拒否します。アクセスポイントに対してこのオプションを TRUE に設定すると、Amazon S3 は、指定されたポリシー (アクセスポイントまたは基になるバケットのいずれかのポリシー) がパブリックである場合に、アクセスポイントを経由した PUT アクセスポイントポリシーと PUT バケットポリシーの呼び出しを拒否します。
> この設定により、バケットやバケット内のオブジェクトをパブリックに共有することを許可することなく、アクセスポイントとバケットポリシーを管理することをユーザーに許可できます。この設定を有効にしても、既存のアクセスポイントやバケットポリシーには影響しません。

とりあえずバケットポリシーの更新( PUT )を拒否するようになるようです。

検証準備します。
`BlockPublicPolicy` をオフにしてバケットポリシーの設定を空にしておきます。

#### 検証 1: バケットポリシーを更新する

`BlockPublicPolicy` をオンにしてバケットポリシーに以下のようなパブリックアクセス許可のポリシーを適用しようとするとエラーになりました。

```json
{
  "Version": "2012-10-17",
  "Id": "ExamplePolicy01",
  "Statement": [
    {
      "Sid": "ExampleStatement01",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": ["s3:GetObject", "s3:GetBucketLocation", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::public-access-1234/*",
        "arn:aws:s3:::public-access-1234"
      ]
    }
  ]
}
```

### 任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックする ( RestrictPublicBuckets )

`RestrictPublicBuckets` についてドキュメントでは以下のように記載しています。

[Amazon S3 ストレージへのパブリックアクセスのブロック \- Amazon Simple Storage Service](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-control-block-public-access.html)

> このオプションを TRUE に設定すると、パブリックポリシーを持つアクセスポイントやバケットへのアクセスは、バケット所有者のアカウント内の AWS のサービスプリンシパルと承認されたユーザーのみに制限されます。この設定は、アカウント内のユーザーにアクセスポイントやバケットの管理を許可しながら、アクセスポイントやバケットへのすべてのクロスアカウントアクセス (AWS のサービスプリンシパルによるアクセスを除く) をブロックします。
> この設定を有効にしても、既存のアクセスポイントポリシーやバケットポリシーには影響しません。ただし、Amazon S3 は、特定のアカウントへのパブリックではない委任を含むパブリックアクセスポイントポリシーやパブリックバケットポリシーから派生したパブリックアクセスやクロスアカウントアクセスをブロックします。

とりあえず既存のアクセスポイントポリシーやバケットポリシーを無視して、アクセスをブロックするようです。

検証準備します。
オブジェクト A を以下のようにプライベート設定でアップロードします。
![プライベート設定](/images/posts/tech-posts/1641291341/private_off.png)

オブジェクト A のアクセス許可は以下のようになっていると思います。
![アクセス許可画面](/images/posts/tech-posts/1641291341/overwrite_public.png)

次に、`RestrictPublicBuckets` をオフにしてバケットポリシーに以下のようなパブリックアクセス許可のポリシーを適用しておきます。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ExampleStatement01",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": ["s3:GetObject", "s3:GetBucketLocation", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::public-access-1234/*",
        "arn:aws:s3:::public-access-1234"
      ]
    }
  ]
}
```

この設定により、オブジェクト A にオブジェクト URL で外部からアクセスが可能になります。

#### 検証 1: RestrictPublicBuckets をオンにして、オブジェクト A のオブジェクト URL にアクセスする

`RestrictPublicBuckets` をオンにします。

![RestrictPublicBucketsの有効化](/images/posts/tech-posts/1641291341/restrict_public_buckets_on.png)

オブジェクト A にオブジェクト URL で外部からアクセスができなくなりました。

![アクセス拒否](/images/posts/tech-posts/1641291341/access_denied.png)

マネジメントコンソール上でも、バケットポリシーに「このバケットに対してブロックパブリックアクセス設定が有効になっているため、パブリックアクセスがブロックされています」と表示されています。

![パブリックアクセスブロック](/images/posts/tech-posts/1641291341/public_access_block.png)


S3 のパブリックアクセスブロックの 4 つの各設定項目について


## S3 バケットへのリクエスト毎の TLS バージョンを確認したい

外部公開している S3 バケットへのリクエストに利用可能な TLS のバージョンを 1.2 のみに制限したい場合に、既存ユーザーにどれくらい影響が出るかわからないので、TLS バージョンの利用状況を確認したい。

## S3 バケットへのリクエスト毎の TLS バージョンを確認するにはどうすればいいの？

### サーバーアクセスのログ記録機能を使う

S3 バケットの「プロパティ」に「サーバーアクセスのログ記録」という設定項目があります。

![サーバーアクセスのログ記録](/images/posts/tech-posts/1639303169/server_access_log.png)

こちらを有効にすることで S3 バケットに対するリクエストの詳細が記録されるようになります。
このサーバーアクセスログから TLS のバージョンを確認することができます。
以下のように TLS バージョンはログの末尾に出力されます。

```log fn=サンプルログ(長いので前半省略)
... TLSV1.1
```

[ベストエフォート型のサーバーログ配信](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/ServerLogs.htmll)

> サーバーアクセスログレコードの配信は、ベストエフォートで行われます。ログ記録用に適切にバケットを設定した場合、そのバケットへのほとんどのリクエストについてログレコードが配信されます。ほとんどのログレコードは、記録された時間から数時間以内に配信されますが、配信間隔は短くなる場合もあります。
> サーバーログの完全性や適時性は保証されません。リクエストのログレコードが、リクエストが実際に処理されてからかなり後に配信されたり、配信すらされないこともあり得ます。サーバーログの目的は、バケットに対するトラフィックの特性を理解することです。ログレコードが失われることはまれですが、すべてのリクエストが完全に報告されるとは限りません。
> サーバーのログ作成機能はベストエフォート型であるため、AWS ポータルで利用できる使用状況レポート (AWSManagement Console でレポートされる請求およびコスト管理レポート) には、サーバーログに記録されていないアクセスリクエストが含まれる場合があります。

一方で、上記の記述のように、サーバーアクセスログレコードの配信は、ベストエフォートで行われ、完全性や適時性は保証されません。
つまり、リクエストが実際に処理されてからかなり後に配信される可能性があるので、実際にログが確認できるまで数時間かかる
可能性があります。
また、そもそもサーバーアクセスログレコードが配信されていない可能性もあります。

> ログの保存先のバケットとして、ソースバケットと同じリージョンにあるユーザー所有のバケットを指定できます。これにはソースバケット自体も含まれます。ただし、ログを管理しやすくするため、アクセスログは別のバケットに保存することをお勧めします。

また、上記の記述のように、アクセスログの書き込み先のバケットには、サーバーアクセスログを有効にしたバケットと異なるバケットを指定することを推奨しているようです。

## 参考文献

<https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/ServerLogs.html>

<https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/LogFormat.html>


S3 バケットへのリクエスト毎の TLS バージョンを確認したい時の方法


Terraform で Vue.js や Rect などで作られた SPA サイトを独自ドメインで HTTPS 配信するためのインフラを構築していきます。
サンプルソースをリポジトリにまとめてみたのでこれを参考に紹介していきます。

:::info

- terafform のバージョンを 1.0.11 から 1.1.6 に変更
- aws provider のバージョンを 3.68.0 から 4.2.0 に変更
- aws provider のバージョンが 3.68.0 の場合のソースはサンプルリポジトリにて [tag(aws-provider-3.68.0)](https://github.com/grasswake/terraform_aws_static_site/tree/aws-provider-3.68.0) 付けしてるのでそちらを参照してください。

:::

## サンプルリポジトリ

サンプルとなるソースをリポジトリにまとめてみたのでこれを参考に紹介していきます。

<https://github.com/grasswake/terraform_aws_static_site>

※本記事の内容と基本的に一緒ですが、一気に作るのでなく Route53 と ACM、CloudFront の３ディレクトリに分けてます。
その為 remote state を使用した構成になっています。因みに リソース名の定義が下手だったり、access_key などの扱いが雑ですので使ってみる場合は使いやすい形に直してください。

## 前提

- 独自ドメインでのアクセスを行うために、お名前.com などでドメインを購入してください。
  - この記事ではお名前.com で `example.com` というドメインを購入していると想定でいます
- アクセス URL は `example.com` になります。`www.example.com` でのアクセスは想定していません。

## Terraform

### Terraform の Provider 定義

基本的には `region` は `ap-northeast-1` ですが、一部のリソース(ACM, CloudFunctions)の作成は `us-east-1` で行うので、以下のように定義している想定です。

```hcl
provider "aws" {
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
  region     = var.region
}

provider "aws" {
  alias      = "us_east"
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
  region     = "us-east-1"
}
```

## Route53 に Terraform で ホストゾーンを作成

まず Route53 でホストゾーンを作成します。
作成するホストゾーン名はパラメータで指定します。

```hcl
resource "aws_route53_zone" "main" {
  name = var.zone_name
}
```

`terraform apply` を実行し、AWS マネジメントコンソールなどでホストゾーンが作成されていることと、NS レコードが作成されていることを確認しましょう。
もし、ドメインを Route53 で購入または Route 53 に移管していないようであれば、この NS レコードをお名前.com などのドメインを購入したところで、Route53 に追加された NS レコードの値を使い、そのドメインに対する NS(ネームサーバー)の変更をしましょう。

## Terraform で ACM による SSL 証明書を発行

Route53 へのホストゾーンの作成と必要であれば NS 変更が終わったら、ACM で SSL 証明書を発行します。

```hcl
resource "aws_acm_certificate" "main_cert" {
  provider                  = aws.us_east
  domain_name               = data.terraform_remote_state.route53.outputs.main_zone_name
  # wwwありのドメインも対象にしたい場合は以下を追加、使用予定はないけどリダイレクトしやすい環境に移行などした時のことを考え一応入れとく
  subject_alternative_names = ["www.${data.terraform_remote_state.route53.outputs.main_zone_name}"]
  # DNSを使ったドメイン認証
  validation_method         = "DNS"
}

# DNSを使ったドメイン認証のためにRoute53にcnameレコードを作成
resource "aws_route53_record" "main_cnames" {
  for_each = {
    for dvo in aws_acm_certificate.main_cert.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }
  zone_id = data.terraform_remote_state.route53.outputs.main_zone_id
  name    = each.value.name
  records = [each.value.record]
  type    = each.value.type
  ttl     = 60
}

resource "aws_acm_certificate_validation" "main_cert_validation" {
  provider                = aws.us_east
  certificate_arn         = aws_acm_certificate.main_cert.arn
  validation_record_fqdns = [for record in aws_route53_record.main_cnames : record.fqdn]
}
```

## Terraform で CloudFront と OAI と S3 　を作成

ここから一気に色々作成していきます。

### Terraform で S3 を作成

```hcl
# vueなど配信コンテンツ用のバケット
resource "aws_s3_bucket" "origin_bucket" {
  bucket = local.domain_name
  force_destroy = true
}

#  CloudFront 以外からアクセスできる必要はないので、ACL をプライベートにします
resource "aws_s3_bucket_acl" "origin_bucket_acl" {
  bucket = aws_s3_bucket.origin_bucket.id
  acl    = "private"
}

# CloudFront 以外からアクセスできる必要はないので、パブリックアクセスを全てオフにします
resource "aws_s3_bucket_public_access_block" "origin_bucket" {
  bucket                  = aws_s3_bucket.origin_bucket.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# CloudFrontのアクセスログ用のバケット
resource "aws_s3_bucket" "logging_bucket" {
  bucket = "cloudfront-logs.${local.domain_name}"
  force_destroy = true
}

# パブリックアクセスを全てオフにします
resource "aws_s3_bucket_public_access_block" "logging_bucket" {
  bucket                  = aws_s3_bucket.logging_bucket.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# ログのバケットのライフサイクルを設定します
# この辺はお好みで変更してください
resource "aws_s3_bucket_lifecycle_configuration" "logging_bucket_lifecycle_config" {
  bucket = aws_s3_bucket.logging_bucket.bucket

  rule {
    id      = "s3-cloudfront-logs-transitions"
    status = "Enabled"

    expiration {
      days = 365
    }

    transition {
      days          = 90
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 180
      storage_class = "GLACIER"
    }
  }
}
```

### Terraform で OAI (Origin Access Identity)　を作成

パブリックアクセスでない S3 に CloudFront がアクセスできるようにするために、OAI を作成します

```hcl
# OAIの作成
resource "aws_cloudfront_origin_access_identity" "oai" {
  comment = "access-identity-ap-northeast-1-cloudfront-resource-periosprint-dev"
}

data "aws_iam_policy_document" "origin_access_identity_policy" {
  statement {
    sid       = "OriginAccessIdentity"
    actions   = ["s3:GetObject"]
    resources = ["${aws_s3_bucket.origin_bucket.arn}/*"]

    principals {
      type        = "AWS"
      identifiers = [aws_cloudfront_origin_access_identity.oai.iam_arn]
    }
  }
}

# OAIを利用したCloudFrontからのアクセスを許可するポリシーをS3のバケットに設定
resource "aws_s3_bucket_policy" "origin_bucket_policy" {
  bucket = aws_s3_bucket.origin_bucket.id
  policy = data.aws_iam_policy_document.origin_access_identity_policy.json
}
```

### Terraform で CloudFront を作成

```hcl
# キャッシュポリシーの作成
resource "aws_cloudfront_cache_policy" "this" {
  name        = local.uppercase_domain_name
  comment     = local.uppercase_domain_name
  # default_ttl と max_ttl min_ttl は開発環境なら0にしてキャッシュしない方が開発しやすいです
  default_ttl = 86400
  max_ttl     = 31536000
  min_ttl     = 1
  parameters_in_cache_key_and_forwarded_to_origin {
    cookies_config {
      cookie_behavior = "none"
    }
    headers_config {
      header_behavior = "none"
    }
    query_strings_config {
      query_string_behavior = "none"
    }
    enable_accept_encoding_brotli = true
    enable_accept_encoding_gzip = true
  }
}

# オリジンリクエストポリシーの作成
resource "aws_cloudfront_origin_request_policy" "this" {
  name    = local.uppercase_domain_name
  comment = local.uppercase_domain_name
  cookies_config {
    cookie_behavior = "none"
  }
  headers_config {
    header_behavior = "none"
  }
  query_strings_config {
    query_string_behavior = "none"
  }
}

resource "aws_cloudfront_distribution" "cfd" {
  aliases = [local.domain_name]

  comment             = local.domain_name
  enabled             = true
  is_ipv6_enabled     = true
  price_class         = "PriceClass_200"
  default_root_object = "index.html"

  origin {
    domain_name = aws_s3_bucket.origin_bucket.bucket_regional_domain_name
    origin_id   = local.domain_name

    s3_origin_config {
      origin_access_identity = aws_cloudfront_origin_access_identity.oai.cloudfront_access_identity_path
    }
  }

  logging_config {
    include_cookies = false
    bucket          = aws_s3_bucket.logging_bucket.bucket_domain_name
  }

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = local.domain_name
    # httpでアクセスされた場合、httpsにリダイレクト
    viewer_protocol_policy = "redirect-to-https"
    compress               = true
    cache_policy_id = aws_cloudfront_cache_policy.this.id
    origin_request_policy_id = aws_cloudfront_origin_request_policy.this.id
  }

  custom_error_response {
    error_caching_min_ttl = "300"
    error_code            = "403"
    response_code         = "200"
    # Nuxt や Next.js で SSG を用いていて 404.html など専用ページがあれば置き換えてください。
    response_page_path    = "/index.html"
  }

  custom_error_response {
    error_caching_min_ttl = "300"
    error_code            = "404"
    response_code         = "200"
    # Nuxt や Next.js で SSG を用いていて 404.html など専用ページがあれば置き換えてください。
    response_page_path    = "/index.html"
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    acm_certificate_arn      = data.terraform_remote_state.acm.outputs.acm_main_cert_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2019"
  }
}

```

### Terraform で Route53 (A レコード) を作成

Route53 に A レコードを追加して、独自ドメインにアクセスされた場合、CloudFront にアクセスされるようにします

```hcl
resource "aws_route53_record" "www" {
  zone_id = local.zone_id
  name    = local.domain_name
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.cfd.domain_name
    zone_id                = aws_cloudfront_distribution.cfd.hosted_zone_id
    evaluate_target_health = false
  }
}
```

## おまけ (Basic 認証と URL の書き換え）

開発環境などアクセスされたくない場合に便利

### Terraform で CloudFront Functions (Basic 認証用の処理) を作成

```js fn=basic_auth/function.js
function handler(event) {
  var request = event.request
  var uri = request.uri
  var headers = request.headers

  // Basic 認証に用いる文字列(dXNlcjpwYXNzd29yZA==)の部分は shell などで以下のコマンドで生成します。
  // echo -n user:password | base64
  var basicAuth = 'Basic dXNlcjpwYXNzd29yZA=='

  if (
    typeof headers.authorization === 'undefined' ||
    headers.authorization.value !== basicAuth
  ) {
    return {
      statusCode: 401,
      statusDescription: 'Unauthorized',
      headers: { 'www-authenticate': { value: 'Basic' } },
    }
  }

  if (uri === '/') {
    return request
  }

  if (uri.endsWith('/')) {
    // リクエスト URL が https://hogehoge.com/foo/ の様に "/" で終わる場合は、この分岐に入ります。
    // その際の扱いは要件によって変えてください。

    // パターン1: Nuxt の例ですが、pages/bar/index.vue のような構成の場合は、
    // リクエスト URL が https://hogehoge.com/bar/ であれば、
    // https://hogehoge.com/bar/index.html にルーティングして欲しいので request.uri の末尾に index.html を付与します。
    request.uri = request.uri.concat('index.html')
    return request

    // パターン2: "/" で終わる場合は "/" を削ってリダイレクト
    return {
      statusCode: 302,
      statusDescription: 'Found',
      headers: {
        location: {
          value: request.uri.slice(0, -1),
        },
      },
    }
  } else if (!uri.includes('.')) {
    // ファイル名に "." が含まれていない = 拡張子がない場合、request.uri の末尾に  ".html" をつける
    request.uri = request.uri.concat('.html')
  }

  return request
}
```

### Terraform で CloudFront Functions を CloudFront に設定

```hcl
resource "aws_cloudfront_function" "basic_auth" {
  name    = "basic_auth"
  runtime = "cloudfront-js-1.0"
  comment = "basic_auth function"
  publish = true
  code    = file("${path.module}/basic_auth/function.js")
}

resource "aws_cloudfront_distribution" "cfd" {
  default_cache_behavior {
    function_association {
      event_type = "viewer-request"
      function_arn = aws_cloudfront_function.basic_auth.arn
    }
  }
}
```


Amazon S3 の記事一覧

S3 のパブリックアクセスブロックの 4 つの各設定項目について

S3 バケットへのリクエスト毎の TLS バージョンを確認したい時の方法

Terraform で SPA を配信する HTTPS 静的サイトのインフラを構築する[Route53 + ACM + CloudFront + S3 + CloudFront Functions(Basic 認証 + α)]