静的サイトホスティング

このパターンは？

HTML/CSS/JS（や SPA、静的サイトジェネレータの出力）を、サーバーレスで世界配信する Google Cloud の最小・最安構成。Cloud Storage に成果物を置き、外部 Application Load Balancer（外部 ALB）に Cloud CDN を有効化して、Google のグローバルエッジから HTTPS 配信します。

AWS の「S3 + CloudFront」に相当しますが、Google Cloud では CDN が独立製品ではなく外部 ALB の機能である点が最大の違いです。

構成

[ユーザー]
   │ HTTPS
   ▼
Cloud DNS (A/AAAA → Anycast IP)
   │
   ▼
外部 Application Load Balancer
  ├─ グローバル静的 IP（Anycast, IPv4/IPv6）
  ├─ Google マネージド SSL 証明書（TLS 終端）
  ├─ URL マップ（パス/ホストのルーティング）
  └─ Cloud CDN（--enable-cdn / バックエンドバケット）
        │  キャッシュフィル
        ▼
   バックエンドバケット → Cloud Storage（ビルド成果物）

CI/CD: Cloud Build / GitHub Actions ─(build)→ out/
        ─(gcloud storage rsync)→ バケット
        ─(invalidate-cdn-cache)→ Cloud CDN

各コンポーネントの役割

• Cloud Storage: ビルド成果物を保存するバックエンドバケット。均一なバケットレベルのアクセスを有効にし、公開せず ALB 経由で読ませる
• Cloud Load Balancing: 外部 ALB がグローバル Anycast IP・HTTPS 終端・ルーティングを担う。Cloud CDN を有効化する「入れ物」
• Cloud CDN: バックエンドバケットに --enable-cdn を付け、Google のエッジ（PoP）でキャッシュ配信
• Cloud DNS: 独自ドメインを LB の**静的 IP（A/AAAA）**に向ける
• Google マネージド SSL 証明書: LB にアタッチする TLS 証明書。自動発行・自動更新で無料

AWS との対応

設計の勘所

• デプロイは build → バケットへ rsync → Cloud CDN を invalidate
• キャッシュはファイル名にハッシュを付け、index.html は短い TTL（または毎回 invalidate）に
• バケットのオブジェクトに Cache-Control を設定し、Cloud CDN のキャッシュモードを USE_ORIGIN_HEADERS にすると制御しやすい
• バックエンドバケットには --enable-cdn のほか、ディレクトリ URL（/gcp/）を index.html に解決するためカスタムレスポンスヘッダや 404/301 リダイレクトの設計を検討
• IPv4/IPv6 両対応にするならグローバル静的 IP を IPv4・IPv6 で 2 つ確保し、A/AAAA を両方登録

Well-Architected の観点

• コスト最適化: サーバーレスで固定費が小さい。Cloud CDN のキャッシュヒットでオリジンの下り（egress）と Cache Fill を削減
• パフォーマンス効率: Google のグローバルエッジ＋プライベートバックボーンで低遅延配信
• セキュリティ: バケット非公開＋ALB 経由、HTTPS 必須。必要なら Cloud KMS の CMEK でバケット暗号化、Cloud Armor で WAF/DDoS 対策
• 運用上の優秀性: Cloud Build や GitHub Actions でビルド→デプロイ→キャッシュ無効化を自動化

よくある落とし穴

アクセス分析・配信状況の監視は Cloud Monitoring と Cloud CDN／LB のログ（Cloud Logging）で行います。