静的サイトホスティング

このパターンは？

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

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

構成

横にスクロール

各コンポーネントの役割

• Cloud Storage: ビルド成果物を保存するバックエンドバケット。公開サイトでは専用バケットを公開読み取りにし、通常の閲覧経路を ALB に集約する。機密コンテンツは公開サイト用バケットと分離し、署名付き URL / Cookie 等を検討する
• 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 で暗号鍵を管理し、ALB 側に Cloud Armor を適用する
• 運用上の優秀性: Cloud Build や GitHub Actions でビルド→デプロイ→キャッシュ無効化を自動化

よくある落とし穴

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