静的サイトホスティング

このパターンは？

HTML/CSS/JS（やSPA、静的サイトジェネレータの出力）を、サーバーを1台も持たずに世界配信する最小・最安構成の OCI 版です。ビルド成果物を Object Storage に置き、その前段に WAF エッジポリシー（OCI のエッジ配信レイヤ） を置いて、キャッシュ・TLS 終端・アプリ層防御を一手に担わせます。

構成

[ユーザー]
   │ HTTPS
   ▼
OCI DNS (権威DNS, Anycast) ──► WAF エッジポリシー (エッジ配信: キャッシュ + TLS終端 + WAF)
        CNAME/ALIAS                 │  オリジンフェッチ（PAR 経由 / 限定公開）
                                    ▼
                              Object Storage (Private バケット: ビルド成果物)

CI/CD: 任意のパイプライン ─(build)→ out/ ─(sync)→ Object Storage
       （エッジは TTL ベース。即時反映はファイル名ハッシュで世代管理）

各コンポーネントの役割

• Object Storage: ビルド成果物（オリジン）を保存。バケットは既定の Private のまま置き、エッジには PAR（Pre-Authenticated Request） か限定公開で読ませる
• WAF エッジポリシー: エッジでのキャッシュ＋TLS 終端＋WAF。OCI における CloudFront 相当の入口
• OCI DNS: 独自ドメインの権威 DNS。配信用 FQDN をエッジの CNAME ターゲットへ向ける（apex は ALIAS）
• TLS 証明書: エッジで終端する PEM 形式（フルチェーン）の証明書＋秘密鍵。TLS 1.2 以上

各レイヤの責務

設計の勘所

• デプロイは build → Object Storage へ sync。アップロード後はエッジの TTL に従って配信される
• キャッシュは TTL 制御が基本。エッジ（WAF エッジポリシー）には CloudFront の Invalidation のような「即時パス無効化」がなく、ポリシー変更の伝播に約 10〜30 分かかる
• そのため即時反映が要るアセットはファイル名にハッシュを付けて別 URL 化（app.abc123.js）し、index.html のような入口ファイルだけ短い TTL に寄せる
• キャッシュルールはパス単位で設計：静的アセット（/assets/）は TTL 長め、SPA の HTML は短めに分ける
• ディレクトリ風 URL（/blog/）を index.html に対応させたい場合、Object Storage 側のオブジェクト名やエッジのルールで吸収する（S3 の "default root object" のような自動補完はオリジン側で設計が必要）

Well-Architected の観点

• コスト最適化: サーバーレスで固定費がほぼ無い。OCI は egress 無料枠が比較的大きく、エッジのキャッシュヒットでオリジンへの往復と転送量をさらに削減できる
• パフォーマンス効率: Anycast の DNS とエッジキャッシュで、地理的に近い拠点から低遅延配信
• セキュリティ: Private バケット ＋ PAR ＋ エッジ TLS に加え、同じエッジで WAF（OWASP ルール・ボット対策・レート制限） が一体で効く。保存時暗号化は既定で有効、要件次第で Vault の顧客管理鍵に
• 運用上の優秀性: Monitoring と Logging でリクエスト・キャッシュ・WAF ブロックを可視化し、アラームで異常検知

よくある落とし穴

AWS との対応（早見表）

アクセス分析・キャッシュ状況の調査は Monitoring と WAF ログで。「ブロックされたのか・キャッシュから返ったのか・オリジンまで行ったのか」をログで切り分けると、配信トラブルの原因に早く辿り着けます。