Azure Site Recovery（ASR）は便利だけれど、「自社サイト間」と「Azure宛て」で何が違うのか、そしてフェールバックやリプロテクションのときにエグレス課金がどう効いてくるのかは、意外と分かりにくいポイントです。本記事では、料金モデルとデータ転送料金の考え方を整理しつつ、どちらのプランを選ぶべきかを具体的に解説します。
Azure Site Recovery（ASR）とは何かを整理する
Azure Site Recovery は、サーバーや仮想マシン（VM）のレプリケーション、フェールオーバー、フェールバックを Azure ポータルから一元管理できるディザスタリカバリ（DR）サービスです。オンプレミス同士（自社データセンター間）、オンプレミスから Azure へのレプリケーション、さらには Azure リージョン間のレプリケーションに対応しており、業務継続計画（BCDR）を支える中核サービスのひとつと位置付けられます。
ASR はあくまで「オーケストレーションとレプリケーションの仕組み」を提供するサービスであり、どこにレプリカを置くか（自社サイトか Azure か）によって、必要なインフラと料金構造が変わってきます。この違いが、そのまま「自社サイト間 vs Azure宛て」の検討ポイントになります。
「自社サイト間」と「Azure宛て」のプラン概要
ASR には大きく分けて次の2パターンの利用形態があります。
- 自社サイト間（customer‑owned sites）：オンプレミス／プライベートクラウド同士でのレプリケーション
- Azure宛て（Site Recovery to Azure / S2A）：オンプレミスから Azure へのレプリケーション
構成イメージの違い
| 項目 | 自社サイト間（customer‑owned sites） | Azure宛て（S2A） |
|---|---|---|
| レプリカの置き場所 | 自社が保有するセカンダリサイト（第2データセンター、支社DC、ホスティングなど） | Azure Storage / Managed Disks（Azure リージョン） |
| ハードウェア | セカンダリサイト側のサーバー・ストレージ・ネットワーク機器を自社で調達・運用 | DRサイトとしてのハードは不要。Azure 側のコンピュート・ストレージを利用 |
| ネットワーク | 自社WAN / MPLS /専用線 / VPN などで2サイトを接続 | インターネット VPN または ExpressRoute でオンプレと Azure を接続 |
| ASR の役割 | オンプレ同士のレプリケーション制御・フェールオーバー/フェールバックの自動化 | オンプレ→Azure のレプリケーション制御、Azure VM の自動生成、フェールオーバー/フェールバック |
| 典型ユースケース | 既にセカンダリDCあり／法令・社内規定でデータをクラウド外に留めたい | セカンダリDCを持たず、クラウド側にDRを集約したい・クラウド移行も視野に入れたい |
料金モデルの違い（ASRライセンス＋周辺コスト）
ASR のライセンス自体は、「保護対象インスタンス（1台のサーバーまたはVM）」単位で課金されます。また、全ての保護インスタンスについて最初の31日間は無料という共通ルールがあります。
31日を過ぎると、一般的な目安として以下のような単価がよく紹介されています（ドル建ての代表例）。
| 項目 | 自社サイト間 | Azure宛て（S2A） |
|---|---|---|
| ASR ライセンス（31日以降） | 約 USD 16 / インスタンス / 月 | 約 USD 25 / インスタンス / 月 |
| レプリカ側のストレージ | 自社ストレージの購入・保守費用 | Azure Storage / Managed Disk の容量・スナップショット料金 |
| レプリカ側のコンピュート | 常時起動サーバーを自社で用意 | 平常時はほぼゼロ（フェールオーバー中だけ Azure VM のコンピュート課金） |
| ネットワーク | 自社WAN/専用線の回線費用 | ExpressRoute/VPN の回線費用＋Azure 側のエグレス（条件次第） |
| 運用コスト | 2拠点分のハード／電力／保守要員 | Azure ポータルに集約された運用。オンプレ側のみ運用要員が必要 |
なお、Azure China など一部リージョンでは現地通貨で「Azure Site Recovery to customer owned sites 月額 約100元」「to Azure 月額 約254元」といった形で公開されていますが、為替やリージョンにより数値は変動します。
公式の料金は必ず Azure 公式の Site Recovery 料金ページと Azure Pricing Calculator で最新情報を確認してください。
Azure のエグレス／イングレス課金の基本ルール
エグレスとイングレスの定義
- イングレス（Ingress）：Azure に入ってくるデータ（オンプレ→Azure、インターネット→Azure など）
- エグレス（Egress）：Azure から出ていくデータ（Azure→オンプレ、Azure→インターネット、Azure リージョン間など）
Azure では、基本的にイングレスは無料で、エグレスは転送量に応じて課金されます。
帯域料金の代表的な例として、北米・欧州リージョンでは「最初の 100GB/月は無料、その後は数セント/GB 程度の段階制課金」といった価格帯が公開されています。
| データの流れ | Azure 側の課金 | 備考 |
|---|---|---|
| オンプレ → Azure | イングレス：無料 | ASR の平常時レプリケーションなど |
| Azure → オンプレ | エグレス：容量に応じて課金 | フェールバック、Azure を一次側としたレプリケーションなど |
| Azure リージョン A → リージョン B | エグレス：リージョン間転送として課金 | Azure VM のリージョン間レプリケーションなど。ASR 公式ドキュメントでも明示。 |
| 同一リージョン内の通信 | 多くのケースで無料または低単価 | ゾーン間など条件により別料金（例：ゾーン間 0.01 USD/GB 程度）。 |
ここまでが「Azure ネットワーク料金の一般ルール」です。次に、これを ASR のフェールオーバー／フェールバック／リプロテクションの動きに当てはめてみます。
ASR のフェールオーバー／フェールバック／リプロテクションとエグレス課金
フェールオーバー（オンプレ → Azure）の場合
オンプレミスから Azure 宛ての ASR（S2A）を利用している場合、フェールオーバー前から以下のようなレプリケーションが動いています。
- オンプレミスの VM / 物理サーバーに ASR エージェントやプロバイダーを導入
- 変更ブロック（差分データ）を Azure のキャッシュストレージに送信（オンプレ → Azure）
- ASR が Azure Storage / Managed Disks にレプリカを反映
このときの 通信方向は「オンプレ → Azure」なので、Azure 側から見るとイングレスであり、通信そのものにはエグレス料金は発生しません。（もちろん、自社側の回線費やキャリア課金は別途です。）
フェールオーバー実行時は、Azure 側でレプリカディスクから VM を起動する処理が中心であり、ネットワーク的にはレプリカ更新の延長です。Azure の課金的には、主に以下のコストに注目します。
- ASR ライセンス（インスタンスごとの月額）
- Azure Storage / Managed Disks（レプリカディスク＋スナップショット）
- フェールオーバー後に起動する Azure VM のコンピュート料金
まとめると、オンプレ→Azure のフェールオーバーでは Azure のエグレス課金は基本的に気にしなくてよい、というのがポイントです。
フェールバック（Azure → オンプレミス）の場合
障害や計画停止などで Azure 側にフェールオーバーした後、復旧したオンプレミスを「元の一次サイト」として戻すのがフェールバックです。このときのデータの流れは次のようになります。
- Azure 上で更新され続けていたディスクの変更差分をオンプレミスにレプリケーション
- オンプレミス側で差分を適用し、データを同期状態に近づける
- 最終切替時に短時間停止して最後の差分を転送し、オンプレを一次側として起動
ここで重要になるのが、データの向きが「Azure → オンプレミス」になっていることです。このトラフィックは Azure から見ればエグレスであり、Azure の帯域料金の対象になります。
公式の Site Recovery 料金ページでも、「アウトバウンド データ転送（エグレス）は、トラフィックが Azure リージョンを離れるときに課金される」「ASR は転送前にデータを圧縮し、圧縮後の容量に対してエグレスが課金される」と明記されています。
したがって、オンプレミスへのフェールバックでは、Azure→オンプレ方向のレプリケーションと最終切替のデータ転送に対してエグレス課金が発生すると考える必要があります。
フェールバック時のエグレス課金イメージ
例として、次のようなケースを考えてみます。
- 保護対象 VM：5 台
- 1 台あたりディスク容量：500 GB
- Azure で稼働していた期間：3 日
- 変更データ率：1 日あたり 5%
- ASR による圧縮率：50% と仮定
この場合、Azure → オンプレに送り返すデータ量はおおよそ次の通りです。
- 総変更データ量：500GB × 5台 × 5% × 3日 = 375GB
- 圧縮後の転送量：375GB × 50% = 187.5GB
帯域料金の例として、北米リージョンで「最初の100GB/月は無料、以降 0.087 USD/GB」と仮定すると、課金対象は 87.5GB（187.5 − 100）で、帯域コストは約 7.6 USD 程度になります。
もちろん、実際にはリージョンや最新の単価により変わりますが、フェールバックは「台数が多く」「稼働期間が長く」「変更率が高い」ほどエグレス課金が効いてくるというイメージを持っておくと、見積もりの感覚値が掴みやすくなります。
リプロテクション（再保護）時のエグレス課金
リプロテクション（再保護）は、フェールオーバー／フェールバック後に新しい一次サイトから再び DR 先へレプリケーションを張り直す操作を指します。ASR ドキュメントやポータルの用語としても登場します。
ここで重要なのは、「どちらを一次サイトにするか」によってデータの向き（＝エグレスの有無）が変わる点です。
パターン1：オンプレを一次サイトに戻して、再び Azure 宛てに保護するケース
- フェールバック完了後、オンプレミス側を一次サイトとして運用
- ASR で「オンプレ → Azure」方向にリプロテクション（再保護）を構成
この場合の通信は オンプレ → Azure（イングレス）なので、Azure のエグレス課金は発生しません。発生するのは、従来どおり ASR ライセンス＋Azure Storage＋オンプレ側回線費用などです。
パターン2：Azure を一次サイトのままにして、オンプレを DR サイトにするケース
- フェールオーバー後、あえて Azure を一次サイトとして継続運用
- ASR で「Azure → オンプレ」方向にリプロテクションを構成
この場合、通信は Azure → オンプレ（エグレス）となるため、レプリケーションの継続的なデータ転送に Azure のエグレス課金がかかることになります。このパターンは、クラウドファーストな設計で「オンプレをバックアップ的な DR サイト」として使う場合に選択肢となります。
今回のご質問のように、「オンプレミス→Azure の再保護（リプロテクション）」を想定する場合、Azure 側でのエグレス課金は発生しないと考えて問題ありません。ただし、フェールバックに伴う Azure→オンプレのデータ転送にはエグレス課金が発生する点はしっかり押さえておく必要があります。
自社サイト間 vs Azure宛て：どちらを選ぶべきか
判断軸を整理する
どちらのプランが「正解」かは、環境や制約によって変わりますが、代表的な判断軸を整理すると次のようになります。
| 観点 | 自社サイト間が向くケース | Azure宛て（S2A）が向くケース |
|---|---|---|
| 既存インフラ | 既にセカンダリDCやホスティング環境があり、空きリソースもある | セカンダリDCを持っていない／老朽化したDCを廃止したい |
| 法令・コンプライアンス | データを国内・自社設備内に留める必要がある（金融・公共など） | クラウド利用が認められており、クラウド側への移行も検討中 |
| RPO / RTO | 超低レイテンシが必要、専用線でミラーリング済みなど | 数分〜数十分レベルの RPO/RTO で許容できる |
| コスト構造 | 初期投資は許容できるが、月額のクラウド費用は抑えたい | 初期投資を抑え、利用量に応じた OPEX モデルに寄せたい |
| 運用要員 | 2拠点分の運用チームを維持できる | インフラ運用はできるだけクラウドに寄せたい |
| 将来構想 | オンプレ中心のまま今後も運用していく方針 | 将来的に Azure への段階的な移行（リホスト／リプラットフォーム）も視野に入る |
ざっくりと言えば、
- 自社でしっかりセカンダリサイトを持ち続ける前提 → 自社サイト間
- セカンダリサイトをクラウドにアウトソースしたい → Azure宛て（S2A）
という整理になります。ただし、エグレス課金を含めたトータルコストと、運用体制のシンプルさの両方を見ないと、数字だけでは判断を誤りがちです。
エグレス課金を含めた見積もりの考え方
ASR の見積もりをするとき、ASR ライセンスと Azure Storage だけに目が行きがちですが、ネットワーク（エグレス課金）を含めて考えると、より現実に近いコスト感が見えてきます。
ステップ1：保護対象とデータ量を棚卸しする
- 保護対象インスタンス数（サーバー・VM 台数）
- 各インスタンスのディスク容量（OS ディスク＋データディスク）
- 1日あたりの変更データ率（%）
- 想定される障害時の継続運用日数（Azure で何日動かすか）
変更データ率は ASR の Deployment Planner や実際の監視ツールで推定するのがベストです。
ステップ2：ASR ライセンス＋ストレージを試算する
- ASR ライセンス：インスタンス数 ×（約 USD16 or 25）
- レプリカストレージ：合計ディスク容量 × Azure Storage 単価（LRS/ZRS、Standard/Premium 等）
- スナップショット／リカバリポイントの保持期間と個数
これらは Azure Pricing Calculator で比較的簡単に見積もれます。
ステップ3：エグレス課金が発生するシナリオを洗い出す
ASR 関連でエグレス課金が発生する代表パターンは次の通りです。
- オンプレへのフェールバック（Azure → オンプレ）
- Azure を一次サイトとしてオンプレにレプリケーションするリプロテクション（Azure → オンプレ）
- Azure リージョン間のレプリケーション（Azure → Azure 別リージョン）
これらのケースで、
- 転送するデータ量（フル／差分、圧縮前後）
- どのリージョンからどこへ出すか（エグレス単価）
を掛け合わせることで、だいたいのエグレス費用を概算できます。
大規模フェールバック時のイメージ
仮に、合計 10TB のデータを一気にオンプレにフェールバックするとします。圧縮率や無料枠などを考慮しつつも、単純化して「ほぼ 10TB をエグレス」と見なすと、
- 10TB = 10,000GB
- （最初の100GB無料を無視して）0.087 USD/GB とすると、おおよそ 870 USD 弱
実際には圧縮や無料枠、リージョン別単価があるため前後しますが、「一度だけの大規模フェールバック」か「小さな差分を長期間継続して送り続ける」かによって、エグレスの負担感は大きく変わります。
エグレス課金を抑えるための設計・運用Tips
1. フェールバック戦略を事前に決めておく
- 「障害から復旧したら必ずオンプレに戻す」のか
- 「これを機に Azure を一次サイトにしてしまう」のか
この方針次第で、フェールバックの回数やデータ量が変わり、エグレスコストにも直結します。クラウド移行を視野に入れている場合は、最初のフェールオーバーを「半分移行」くらいの気持ちで捉え、戻さず Azure 側を一次にしてしまう選択肢も現実的です。
2. リプロテクションの向きを意識する
前述の通り、
- オンプレ → Azure の再保護：イングレスなので Azure 側エグレスなし
- Azure → オンプレの再保護：エグレス課金あり
という違いがあります。設計段階で「最終的にどちらを一次サイトに固定したいか」を決めておくことで、無駄なエグレスを抑えられます。
3. フェールオーバー／テストフェールオーバーの頻度を計画する
ASR では、定期的なテストフェールオーバーによって DR 手順の検証ができますが、これに伴い スナップショット／一時ディスク／コンピュートなどのコストが積み上がっていきます。
- 本番テストを年数回に抑え、検証用の小規模テストで頻度を上げる
- テスト終了後のリソース削除を自動化し、無駄なコンピュート・ストレージを残さない
といった運用のチューニングで、トータルコストを最適化できます。
4. ExpressRoute / VPN の設計にも注意
Azure のエグレス料金とは別に、
- VPN ゲートウェイの時間単価
- ExpressRoute 回線の月額＋帯域単価
なども全体コストに影響します。特にフェールバック時には大きなトラフィックが一度に流れやすいため、ネットワーク帯域のボトルネックと回線料金のバランスも合わせて設計する必要があります。
実務にそのまま使えるチェックリスト
コスト見積もり用チェックリスト
- 保護対象インスタンス
- 対象 VM / サーバーの一覧（役割・重要度）
- 各インスタンスの OS / アプリライセンス（DR サイト分のライセンス要件も確認）
- ストレージ
- ディスク容量（OS / データ / ログ）
- Azure Storage の冗長化オプション（LRS / ZRS / GRS）
- バックアップやスナップショット保持期間
- ネットワーク
- オンプレと Azure 間の回線種別（VPN / ExpressRoute）
- 必要な帯域（レプリケーションの RPO から逆算）
- フェールバック時に想定されるピークトラフィック
- ASR ライセンス
- customer‑owned sites：インスタンス数 × 約 USD16/月
- to Azure：インスタンス数 × 約 USD25/月
- 最初の31日無料をどう試験期間に活かすか
- テスト運用
- テストフェールオーバーの頻度と対象範囲
- テスト用リソースの自動クリーンアップ手順
まとめ：ポイントのおさらい
最後に、本記事の要点を整理します。
- ASR には「自社サイト間」と「Azure宛て（S2A）」の2パターンがあり、前者はセカンダリサイトを自前で持つ構成、後者は Azure をセカンダリサイトとして使う構成です。
- ASR ライセンスはインスタンス単位で、最初の31日間は無料。31日以降は、おおよそ「自社サイト間：USD16／S2A：USD25」程度が目安ですが、リージョンや為替で変動するため、常に公式料金を確認する必要があります。
- Azure のイングレス（オンプレ→Azure）は無料、エグレス（Azure→オンプレ／他リージョン）は従量課金であり、フェールバックや Azure→オンプレのリプロテクションではエグレス課金が発生します。
- オンプレ→Azure のリプロテクション（再保護）はイングレスのみなので、Azure 側エグレス課金はかかりません。ただしストレージや回線など別コストは考慮が必要です。
- どちらのプランを選ぶかは、既存インフラ・法規制・RPO/RTO・コスト構造・運用体制・将来のクラウド移行構想といった観点を総合して決める必要があります。
- 実際の見積もりでは、ASR ライセンス＋ストレージ＋コンピュート＋ネットワーク（エグレス含む）をセットで評価し、Deployment Planner や Pricing Calculator を併用すると精度の高い試算ができます。
ASR は「とりあえず有効化してみる」だけでも 31 日間はライセンス無料で試せるため、小規模な範囲から PoC を行い、実際の変更データ量やフェールオーバー／フェールバック時間、エグレス量を体感しながら設計をブラッシュアップしていくアプローチがおすすめです。
コメント