静的サイトホスティング

サーバー管理なしで静的サイトを世界に速く安く配信。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 経由だけにできます。

横にスクロール

利用者がAzure DNSとFront Doorを経由してBlob Storageの静的Webサイトへアクセスする配信経路と、GitHub Actionsがビルド成果物を配備してキャッシュを更新する経路、障害時に待機系オリジンへ切り替える経路を示す構成図
利用者の入口はFront Doorに一本化し、PremiumではStorage静的WebサイトのwebサブリソースへPrivate Linkで接続します。配備はビルド、差分同期、キャッシュ更新を一連の処理にし、静的資産はハッシュ名、index.htmlは短いTTLまたはパージで更新します。

構成

[ユーザー]
   │ 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 LinkStorage 静的 Web サイト(web)高(直接公開を遮断)Private Endpoint 接続を承認し、Storage のパブリックネットワークアクセスを拒否
Front Door StandardStorage 静的 Web サイト(公開)Private Link 非対応。強いオリジン分離が必要なら Premium を選ぶ
Static Web Apps を採用(マネージド配信込み)そもそも自前で Front Door を組まず、配信まで一体のサービスに寄せる選択肢
Static Web Apps という近道

ルーティング・カスタムドメイン・無料 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 で差分のみ転送

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 DoorCloudFront
オリジン非公開Private Link(Premium、web サブリソース)OAC(Origin Access Control)
TLS 証明書AFD マネージド証明書 / Key Vault(BYOC)ACM(us-east-1)
DNS / apexAzure DNS エイリアスレコードRoute 53 Alias
キャッシュ無効化Purge(パス / `/*` / 全消去)Invalidation
一体型の近道Azure Static Web AppsAWS 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

costperformancesecurityoperationalAzure Blob StorageAzure Front Door / CDNAzure DNS / Traffic ManagerAzure Key Vault