LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@thu_san

エンタープライズ対応AWS静的サイト用Terraformモジュール：自動キャッシュ無効化とクロスアカウントログ配信

Posted at

AIと共同執筆

image-1749954954641.png

TL;DR

🎯 何これ: AWS静的サイト（S3 + CloudFront）を企業レベルの機能付きで簡単デプロイできるTerraformモジュール

🚀 解決する課題:

  • ✅ 自動キャッシュ無効化 - 手動でのCloudFrontキャッシュクリア不要
  • ✅ クロスアカウントログ配信 - セキュリティチームの一元管理対応
  • ✅ ワイルドカードドメイン対応 - PRプレビュー環境に最適
  • ✅ エンタープライズセキュリティ - OAC、IAM最小権限、TLS 1.2+

⚡ 時短効果: 5分でセットアップ完了 vs 手動構築2〜3時間

📦 使い方:

source = "thu-san/static-site/aws"
enable_cache_invalidation = true

🔗 入手先: Terraformレジストリ | OpenTofuレジストリ | GitHub

AWSでの静的サイトホスティングは一見簡単に見えますが、企業レベルの要件（自動キャッシュ無効化、クロスアカウントログ配信、ワイルドカードドメイン対応など）を満たそうとすると、手動設定や複雑なカスタムソリューションが必要になり、メンテナンスが困難になります。

既存のTerraformモジュールは基本的なS3 + CloudFront構成にとどまり、企業が実際に必要とする機能が欠けています。そこで、これらの課題を解決する包括的なTerraformモジュールを開発しました。

既存ソリューションの問題点

手動キャッシュ管理の課題

多くのAWS静的サイト構成では、コンテンツ更新後にCloudFrontキャッシュを手動で無効化する必要があります：

  • 古いコンテンツ表示: 手動無効化まで更新が反映されない
  • CI/CDの複雑化: ビルドパイプラインに無効化ステップの追加が必要
  • 運用コスト増加: デプロイごとに30分以上の手作業

企業要件への対応不足

標準的なチュートリアルや既存モジュールでは、以下の企業要件が考慮されていません：

  • クロスアカウントログ配信: セキュリティチームによる一元管理
  • コンプライアンス: 複数AWSアカウント間での監査証跡
  • ワイルドカードドメイン: PRプレビュー環境やマルチテナント構成
  • エンタープライズセキュリティ: 適切なIAM境界と最小権限アクセス

このモジュールの特徴

🔄 組み込み型自動キャッシュ無効化

他のモジュールと異なり、Lambdaベースの包括的な無効化システムが標準装備：

module "static_site" {
  source = "thu-san/static-site/aws"
  
  # 自動キャッシュ無効化を有効化
  enable_cache_invalidation = true
  invalidation_mode = "custom"
  
  # インテリジェントな無効化パターン
  invalidation_path_mappings = [
    {
      source_pattern = "^images/.*"
      invalidation_paths = ["/images/*"]
      description = "画像アップロード時に画像キャッシュを無効化"
    },
    {
      source_pattern = "^(index\\.html|home\\.html)$"
      invalidation_paths = ["/*"]
      description = "ホームページ変更時に全キャッシュ無効化"
    }
  ]
}

仕組み:

  1. S3イベントがSQSメッセージをトリガー
  2. Lambda関数がバッチ処理でコスト効率化
  3. 正規表現パターンマッチングで柔軟な無効化パス指定
  4. デッドレターキューでエラーハンドリング

📊 ネイティブクロスアカウントログ配信

企業環境でよく必要となるセキュリティアカウントへのログ集約をネイティブサポート：

module "static_site" {
  source = "thu-san/static-site/aws"
  
  # セキュリティアカウントへのログ配信
  log_delivery_destination_arn = "arn:aws:logs:us-east-1:SECURITY-ACCOUNT:delivery-destination:central-cloudfront-logs"
  
  # カスタムログフィールド指定
  log_record_fields = [
    "timestamp", "c-ip", "sc-status", 
    "cs-method", "cs-uri-stem", "cs-referer"
  ]
  
  # S3配信設定のカスタマイズ
  s3_delivery_configuration = [
    {
      suffix_path = "/cloudfront/{DistributionId}/{yyyy}/{MM}/{dd}"
      enable_hive_compatible_path = true
    }
  ]
}

🌐 高度なドメイン管理

ワイルドカードドメインの完全サポートで、モダンなアプリケーション要件に対応：

module "static_site" {
  source = "thu-san/static-site/aws"
  
  # ワイルドカードドメイン対応
  domain_names = [
    "dev.example.com",
    "*.dev.example.com"  # pr123.dev.example.com、pr456.dev.example.com
  ]
  hosted_zone_name = "example.com"
  
  # サブフォルダールートオブジェクト自動設定
  subfolder_root_object = "index.html"
}

実装例：PR毎のプレビュー環境

開発チームでよく使われるPR毎のプレビュー環境の完全な実装例：

# CloudFront関数でインテリジェントルーティング
resource "aws_cloudfront_function" "pr_router" {
  name    = "pr-preview-router"
  runtime = "cloudfront-js-2.0"
  comment = "PRプレビューリクエストを適切なS3フォルダにルーティング"
  publish = true
  
  code = <<-EOT
    function handler(event) {
      var request = event.request;
      var host = request.headers.host.value;
      
      // サブドメインからPR番号を抽出（例：pr123.dev.example.com）
      var prMatch = host.match(/^pr(\d+)\./);
      if (prMatch) {
        var prNumber = prMatch[1];
        // URIにPRフォルダをプレフィックス
        request.uri = '/pr' + prNumber + request.uri;
      }
      
      // ディレクトリリクエストにindex.htmlを追加
      if (request.uri.endsWith('/')) {
        request.uri += 'index.html';
      }
      
      return request;
    }
  EOT
}

module "pr_preview_site" {
  source = "thu-san/static-site/aws"
  
  s3_bucket_name = "company-pr-previews"
  cloudfront_distribution_name = "pr-preview-distribution"
  
  # ワイルドカードドメイン設定
  domain_names = [
    "dev.example.com",
    "*.dev.example.com"
  ]
  hosted_zone_name = "example.com"
  
  # PR ルーティング関数を添付
  cloudfront_function_associations = [{
    event_type   = "viewer-request"
    function_arn = aws_cloudfront_function.pr_router.arn
  }]
  
  # 高速なPR更新のための自動無効化
  enable_cache_invalidation = true
  invalidation_mode = "direct"
  
  tags = {
    Environment = "development"
    Project     = "pr-previews"
    Team        = "frontend"
  }
  
  providers = {
    aws           = aws
    aws.us_east_1 = aws.us_east_1
  }
}

結果:

  • メインブランチのコンテンツ: dev.example.com
  • PR #123のコンテンツ: pr123.dev.example.com（S3の/pr123/フォルダから配信）
  • PR #456のコンテンツ: pr456.dev.example.com（S3の/pr456/フォルダから配信）

基本セットアップ

最もシンプルな設定から始める場合：

# プロバイダー設定（2つ必要：CloudFrontはus-east-1の証明書が必要）
provider "aws" {
  region = "ap-northeast-1"  # 東京リージョン
}

provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}

module "static_site" {
  source  = "thu-san/static-site/aws"
  version = "~> 1.2"
  
  # 必須パラメータ
  s3_bucket_name               = "my-company-website-bucket"
  cloudfront_distribution_name = "my-company-website"
  
  # 基本タグ設定
  tags = {
    Environment = "production"
    Project     = "company-website"
    Team        = "platform"
  }
  
  providers = {
    aws           = aws
    aws.us_east_1 = aws.us_east_1
  }
}

# 出力値
output "cloudfront_domain" {
  value = module.static_site.cloudfront_distribution_domain_name
}

output "s3_bucket" {
  value = module.static_site.bucket_id
}

セキュリティとパフォーマンス

セキュリティファーストアーキテクチャ

  • プライベートS3バケット: すべてのパブリックアクセスをブロック
  • Origin Access Control (OAC): CloudFrontのみのアクセスを許可
  • 最小TLS 1.2: 強制的なセキュア接続
  • IAM最小権限: 各コンポーネントに必要最小限のアクセス権

パフォーマンス最適化

# 自動的に設定される最適化（設定不要）
# - HTTP/2とHTTP/3のサポート
# - Gzip圧縮の有効化
# - 適切なキャッシュポリシー
# - エッジロケーションでの最適化

コスト最適化

インテリジェントな無効化バッチング

Lambda関数には複数のコスト節約機能を実装：

# Lambda関数内のコスト最適化例（自動実装済み）
def optimize_invalidation_paths(paths):
    """CloudFront無効化コストを最小化するパス最適化"""
    
    # 重複除去
    unique_paths = list(set(paths))
    
    # ディレクトリごとにグループ化してワイルドカード機会を検出
    optimized = []
    for directory, files in group_by_directory(unique_paths):
        if len(files) > 3:  # 3ファイル以上の場合はワイルドカード使用
            optimized.append(directory + '*')
        else:
            optimized.extend(files)
    
    return optimized[:1000]  # CloudFrontの上限1000パス

SQSバッチ処理

コスト効率的なイベント処理：

# デフォルト設定（カスタマイズ可能）
invalidation_sqs_config = {
  batch_window_seconds = 60    # 60秒間でイベントを蓄積
  batch_size = 100            # 最大100イベントをバッチ処理
  message_retention_days = 4   # 4日間メッセージを保持
}

他ソリューションとの比較

機能 このモジュール 手動構築 他のモジュール
キャッシュ無効化 ✅ 組み込み ❌ 別ツール必要 ❌ 通常未対応
クロスアカウントログ ✅ ネイティブサポート ❌ 複雑なIAM設定 ❌ 未対応
ワイルドカードドメイン ✅ 完全サポート ❌ 手動証明書管理 ⚠️ 限定的サポート
セットアップ時間 ⏱️ 5分 ⏱️ 2-3時間 ⏱️ 30分以上
メンテナンス 🔄 自動管理 🛠️ 手動更新必要 🛠️ 部分的自動化

トラブルシューティング

よくある問題と解決方法

証明書検証の失敗

# Route53ホストゾーンの確認
data "aws_route53_zone" "main" {
  name = var.hosted_zone_name
}

output "hosted_zone_id" {
  value = data.aws_route53_zone.main.zone_id
}

キャッシュ無効化が動作しない

# SQSキューの確認
aws sqs get-queue-attributes \
  --queue-url $(terraform output sqs_queue_url) \
  --attribute-names All

# Lambdaログの確認
aws logs describe-log-streams \
  --log-group-name $(terraform output lambda_log_group_name)

運用のベストプラクティス

環境別設定

# terraform.tfvars.prod
s3_bucket_name = "company-website-prod"
domain_names = ["example.com", "www.example.com"]
enable_cache_invalidation = true

# terraform.tfvars.staging
s3_bucket_name = "company-website-staging"
domain_names = ["staging.example.com"]
enable_cache_invalidation = false  # ステージングではコスト節約

CI/CDとの統合

GitHub Actionsでの自動デプロイ例：

name: Deploy Static Site
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-1
          
      - name: Build site
        run: npm run build
        
      - name: Deploy to S3
        run: |
          aws s3 sync ./dist/ s3://$(terraform output -raw bucket_id)/ --delete
          echo "Deployed to https://$(terraform output -raw cloudfront_domain)"

モニタリングと観測性

CloudWatchメトリクス

モジュールが自動作成する主要メトリクス：

  • キャッシュヒット率: 80%以上を目標
  • オリジンレイテンシ: S3レスポンス時間
  • 4xxエラー率: クライアントエラーの監視
  • 5xxエラー率: サーバーエラーの監視

アラート設定

# 自動作成されるアラーム例
resource "aws_cloudwatch_metric_alarm" "cache_hit_rate" {
  alarm_name = "${var.cloudfront_distribution_name}-cache-hit-rate"
  comparison_operator = "LessThanThreshold"
  threshold = "80"
  metric_name = "CacheHitRate"
  namespace = "AWS/CloudFront"
}

今後の予定

コミュニティ貢献

  • GitHubリポジトリ: terraform-aws-static-site
  • イシュー報告: バグ報告や機能要求
  • プルリクエスト: コミュニティからの貢献を歓迎
  • ディスカッション: 質問やベストプラクティスの共有

まとめ

AWSでのエンタープライズレベル静的サイトデプロイは、適切な自動化により複雑さを排除できます。このTerraformモジュールは、実際の本番環境での学習と最適化を重ねた結果であり、開発チームが直面する課題を解決します。

主な価値：

  • 時間節約: 手動作業の95%を自動化
  • コスト最適化: インテリジェントなリソース管理
  • 信頼性向上: 本番実績のあるベストプラクティス
  • スケーラビリティ: 小規模から大規模まで対応

ぜひ次のプロジェクトで試してみて、フィードバックをお聞かせください。

あなたのチームではAWS静的サイトデプロイでどのような課題に直面していますか？このモジュールを試してみた感想をコメントで教えてください！

タグ

#terraform #aws #devops #infrastructure #cloudfront #s3 #静的サイト #iac

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?