静的サイトホスティング
サーバー管理なしで静的サイトを世界に速く安く配信。Blob Storage にビルド成果物を置き、Front Door(CDN)で安全・高速・低コストにする Azure 版の構成。
このパターンは?
HTML/CSS/JS(や SPA、静的サイトジェネレータの出力)を、サーバーレスで世界配信する Azure の最小・最安構成です。AWS の S3 + CloudFront に相当する組み合わせを、Azure では Blob Storage(静的 Web サイト)+ Front Door で実現します。
Storage の静的 Web サイトエンドポイントは $web 内のファイルを匿名読み取りで返します。ただし Front Door Premium から web サブリソースへ Private Link 接続し、Storage のパブリックネットワークアクセスを拒否すれば、利用者からの直接接続を閉じて Front Door 経由だけにできます。
横にスクロール
構成
[ユーザー]
│ HTTPS
▼
Azure DNS (エイリアスレコード) ──► Front Door (CDN/POP, WAF, マネージド証明書)
│ Premium: Private Link (web)
▼
Blob Storage (静的 Web サイト: $web コンテナー)
│ 既定エンドポイント:
│ https://<account>.z??.web.core.windows.net
CI/CD: GitHub Actions ─(build)→ out/ ─(azcopy sync)→ $web ─(purge)→ Front Door
各コンポーネントの役割
- Blob Storage: ビルド成果物を保存。「静的 Web サイト」機能を有効化すると、
$webという専用コンテナとプライマリ静的 Web サイトエンドポイント(web.core.windows.net)が生える。index.html(インデックスドキュメント)と404.html(エラードキュメント)を指定できる - Front Door: Microsoft のグローバルエッジ(POP)からのキャッシュ配信+HTTPS(SSL オフロード)+WAF。オリジンを
$webエンドポイントに向ける - Azure DNS: 独自ドメイン。apex(
example.com)は CNAME を置けないためエイリアスレコード(A/AAAA) で Front Door へ。wwwなどのサブドメインは CNAME でazurefd.netを指してもよい - Key Vault: 独自証明書を持ち込む(BYOC)場合の格納先。Front Door マネージド証明書なら不要(自動発行・自動更新・無料)
$web のコンテナアクセスレベルを Private にしても、静的 Web サイトエンドポイントは匿名読み取りで配信されます。直接到達を止めるには、Front Door Premium + Private Link(対象サブリソース web)を構成し、Storage のパブリックネットワークアクセスを拒否します。
オリジン保護(S3 の OAC に相当)
AWS では CloudFront の OAC で S3 を非公開のまま読ませます。Azure では Front Door Premium の Private Linkを使い、Storage 静的 Web サイトの web / web_secondary サブリソースへ非公開接続できます。
| 方式 | オリジン | 非公開度 | 備考 |
|---|---|---|---|
| Front Door Premium + Private Link | Storage 静的 Web サイト(web) | 高(直接公開を遮断) | Private Endpoint 接続を承認し、Storage のパブリックネットワークアクセスを拒否 |
| Front Door Standard | Storage 静的 Web サイト(公開) | 低 | Private Link 非対応。強いオリジン分離が必要なら Premium を選ぶ |
| Static Web Apps を採用 | (マネージド配信込み) | — | そもそも自前で Front Door を組まず、配信まで一体のサービスに寄せる選択肢 |
ルーティング・カスタムドメイン・無料 TLS・グローバル配信・GitHub Actions 連携までを一体で提供する Azure Static Web Apps を使えば、Blob + Front Door を自分で組まずに静的サイト(+ 軽量 API)を公開できます。本パターンは「素材を理解し、自前で最適化したい」場合の組み立て方です。
設計の勘所
- デプロイは
build → $web へ azcopy sync → Front Door を purge - キャッシュはファイル名にハッシュを付け(
app.abcd123.js)、index.htmlは短い TTL(または毎回 purge)に - TTL はオリジンの
Cache-Controlヘッダ、または Front Door のルールエンジン「キャッシュ有効期間の上書き」で制御 - SPA / ディレクトリ URL(
/azure/)の扱いは、静的 Web サイトの インデックスドキュメントでルート補完しつつ、未知パスをindex.htmlに寄せたい場合は Front Door ルールエンジンのリライト/404 上書きで調整 - 証明書は Front Door マネージド証明書(自動更新)を第一候補に。組織方針で持ち込みが必要なときだけ Key Vault の BYOC
azcopy sync ./out https://<account>.blob.core.windows.net/$web --delete-destination=true で、変更分だけを高速同期しつつ削除済みファイルも反映できます(S3 の aws s3 sync 相当)。同期後に Front Door を az afd endpoint purge --content-paths "/*" で無効化します。
Well-Architected の観点
- コスト最適化: サーバー常駐なし。Blob は Hot アクセス層の保存+転送、Front Door は基本料金+送信データ転送+リクエスト。要件が静的配信主体で WAF 不要なら Front Door Standard で十分
- パフォーマンス効率: エッジ(POP)キャッシュ+ Microsoft バックボーンで高速。
gzip / brotli圧縮と HTTP/2 を活用 - セキュリティ: Front Door Premium から
webサブリソースへ Private Link 接続し、Storage のパブリックネットワークアクセスを拒否。HTTPS 強制(TLS 1.2 以上)、WAF、必要に応じて Key Vault で証明書を管理 - 運用上の優秀性: GitHub Actions で
build → sync → purgeを自動化。Azure Monitor でキャッシュヒット率・4xx/5xx・オリジンレイテンシを可観測に
よくある落とし穴
- Storage のパブリックネットワークアクセスを許可したまま、静的 Web サイトのURLを直接配信(Front Door のWAFやキャッシュを迂回される)
$webのコンテナアクセスレベルを Private にすれば静的 Web サイトも非公開になる、と誤解する- デプロイ後に Front Door の purge を忘れ、古いコンテンツがエッジに残る(または
index.htmlを長 TTL でキャッシュしてしまう) - Private Endpoint の対象を
blobにして、静的 Web サイト用のwebエンドポイントへ接続できない - 廃止後の CNAME / エイリアスをゾーンに残し、サブドメインテイクオーバーの的になる
| 観点 | Azure(本パターン) | AWS(S3 + CloudFront) |
|---|---|---|
| 静的ストレージ | Blob Storage(静的 Web サイト / $web) | S3(静的ウェブサイトホスティング) |
| CDN / 配信 | Front Door | CloudFront |
| オリジン非公開 | Private Link(Premium、web サブリソース) | OAC(Origin Access Control) |
| TLS 証明書 | AFD マネージド証明書 / Key Vault(BYOC) | ACM(us-east-1) |
| DNS / apex | Azure DNS エイリアスレコード | Route 53 Alias |
| キャッシュ無効化 | Purge(パス / `/*` / 全消去) | Invalidation |
| 一体型の近道 | Azure Static Web Apps | AWS Amplify Hosting |
監視・アクセス分析は Azure Monitor のメトリクスと、Front Door のアクセスログ / WAF ログを Log Analytics に送って行います。
Azure Pattern
静的サイトホスティングを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cost
比較で見る軸
クラウド: Azure / 難易度: basic / 関連サービス: 5件
導入後に効く点
サーバー管理なしで静的サイトを世界に速く安く配信。Blob Storage にビルド成果物を置き、Front Door(CDN)で安全・高速・低コストにする Azure 版の構成。
先に潰すリスク
パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。
- クラウド
- Azure
- 難易度
- basic
- 関連サービス
- 5件
- 設計柱
- cost / performance / security / operational
判断チェックリスト
- 自社の用途が「cost / performance」に近いか確認する。
- 強みである「サーバー管理なしで静的サイトを世界に速く安く配信。Blob Storage にビルド成果物を置き、Front Door(CDN)で安全・高速・低コストにする Azure 版の構成。」が本当に評価軸になるか確認する。
- 注意点の「パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。