【Azure】AzureStorageアカウントの冗長化、結局どれ？6つのプランを"守りたい障害レベル"から逆引きで選ぶ

はじめに

こんにちは、パナソニックコネクト株式会社の山本です。

Azure で Storage アカウントを作ろうとして、「冗長性」のプルダウンで手が止まったことはないでしょうか。LRS、ZRS、GRS、RA-GRS、GZRS、RA-GZRS——似た略語が 6 つ並んでいて、どれを選ぶと何から守られるのかがプルダウンの文言だけでは読み取りにくいのです
しかもこの 6 つ、単純な「松竹梅」ではなく、コスト順・耐久性順・守れる障害の広さ順が微妙にズレているのが厄介なところです。

この記事は、6 つの冗長化オプションを機能の浅いほうから順に解説するのではなく、「何の障害から守りたいか」という障害レベルを起点に、必要なプランを逆引きする構成にしています。6 つの略語を丸暗記するのではなく、自分の要件からスッと引けるようになることをゴールにします。

（補足）
冗長化は Blob だけの設定ではなく、Storage アカウント単位の設定です。アカウントに冗長化を設定すると、そのアカウント上の Blob・Files・Queue・Table すべてに同じ冗長性が効きます。とはいえ「Blob を冗長化したい」という入口で検討を始める方が多いと思うので、本記事では Blob Storage を主な例にしつつ、アカウント全体の話として進めます。

なお、AWS の S3 を触ってきた方向けに、記事の後半で「S3 とは冗長化の決め方がどう違うのか」を耐久性・障害範囲の対応づけ中心にまとめています。S3 の感覚のまま Azure を選ぶとはまりやすい点があるので、AWS 経験者はそちらもあわせて読んでみてください。

冗長化は「どこに・何個コピーするか」で決まる

6 つの略語は一見バラバラですが、実は 2 つの軸の組み合わせでできています。ここを押さえると、略語が一気に読めるようになります。

• 軸1：プライマリリージョン内でどう複製するか
  • LRS（Locally Redundant Storage / ローカル冗長）: 1 つのデータセンター内に 3 コピー
  • ZRS（Zone Redundant Storage / ゾーン冗長）: リージョン内の 3 つ以上の可用性ゾーンに分散
• 軸2：別のリージョン（セカンダリ）にもコピーするか
  • コピーしない → LRS / ZRS のまま
  • コピーする（Geo 冗長）→ 頭に G が付く（GRS / GZRS）
• おまけの軸：セカンダリを平常時に読めるようにするか
  • 読めるようにする → 頭に RA-（Read-Access）が付く（**RA-**GRS / **RA-**GZRS）

つまり GZRS = ゾーン冗長(ZRS) + Geo コピー、RA-GZRS = それ + セカンダリ読み取り、という足し算で理解できます。

先に用語も補足しておきます。

• 可用性ゾーン（AZ）: 同一リージョン内で電源・冷却・ネットワークが独立した物理的に別の区画。1 ゾーンが落ちても他ゾーンは生きている、という単位
• RPO（Recovery Point Objective）: 障害時にどの時点まで戻せるか。Geo 冗長はセカンダリへの複製が非同期なので、障害の瞬間にセカンダリへ未反映の書き込みがあると、その分はデータ損失になりうる

6 つのプランを一枚の表で

まず全体像です。個別解説の前に、この表で「自分の要件がどの行に触れるか」のあたりを付けてください。

「年間耐久性」は、公式ドキュメントが示す「1 年間でオブジェクトが失われずに残っている確率」の目標値です。たとえば 99.999999999%（9 が 11 個） は、ざっくり言えば「1,000 万個のオブジェクトを預けても、1 年で 1 個失うか失わないか」という水準。9 が 1 個増えるごとに、失う確率がさらに 1 桁小さくなる、と捉えてください。数字の桁を追うより「下の行ほど 9 が増えて、より堅牢」という読み方で十分です。

プラン	コピーの置き場所	年間耐久性（目標）	守れる障害範囲	コスト感
LRS	1 データセンター内に 3 コピー	99.999999999%（9 が 11 個）	ドライブ / サーバー / ラック障害	最安
ZRS	同一リージョンの 3 AZ に分散	99.9999999999%（9 が 12 個）	＋データセンター（ゾーン）障害	低〜中
GRS	プライマリは LRS ＋別リージョンに非同期コピー	99.99999999999999%（9 が 16 個）	＋リージョン災害（※平常時セカンダリは読めない）	中〜高
RA-GRS	GRS ＋セカンダリを読み取り可	99.99999999999999%（9 が 16 個）	＋災害中もセカンダリから読み取り継続	高
GZRS	プライマリは ZRS ＋別リージョンに非同期コピー	99.99999999999999%（9 が 16 個）	ゾーン障害もリージョン災害も両対応	高
RA-GZRS	GZRS ＋セカンダリを読み取り可	99.99999999999999%（9 が 16 個）	最も手厚い（ゾーン＋リージョン＋災害中の読み取り）	最高

表の上から下に向かうほど「守れる障害の範囲」が広がり、そのぶんコストも上がります。逆に言えば、守りたい障害が上の行で収まるなら下のプランは過剰、ということです。

【本題】守りたい障害レベルから逆引きする

ここがこの記事のいちばん伝えたいところです。プラン選びでつまずくのは、「どのプランが何から守ってくれるのか」がプルダウンの文言から読み取りにくいからです。発想を逆にして、「自分は何の障害から守りたいのか」を先に決め、そこから必要なプランを引くと迷いが減ります。

障害を 4 段階に分けて整理したのが次の逆引き表です。

守りたい障害レベル	具体例	必要なプラン	理由
① ハードウェア障害まで	ディスク故障、サーバー・ラック障害	LRS	1 DC 内 3 コピーでラック障害までは吸収できる
② データセンター（ゾーン）障害	1 つの AZ が火災・停電で全損	ZRS（または GZRS）	3 AZ に分散しているので 1 ゾーン喪失でも読み書き継続
③ リージョン全体の災害	地震・大規模停電でリージョンごと停止	GRS / GZRS	数百 km 離れたセカンダリにコピーがある
④ 災害発生中もアプリを止めたくない（読み取り）	リージョン障害中でも参照系を動かし続けたい	RA-GRS / RA-GZRS	セカンダリを平常時から読めるので、障害中も参照できる

読み解き方のポイントを補足します。

• ①と②の分岐が最初の関門です。「1 つのデータセンターが丸ごと落ちても耐えたいか？」で LRS と ZRS が分かれます。クラウドのデータセンターは滅多に全損しませんが、落ちたときに LRS は全コピーを失います。ミッションクリティカルなら最低でも ZRS が出発点です。
• ③で GRS と GZRS のどちらにするかは、①②で ZRS 相当（ゾーン障害耐性）が欲しいかどうかで決めます。欲しいなら GZRS、プライマリ内はローカル冗長で十分なら GRS です。Microsoft は高可用性が必要なら GZRS を推奨しています。
• ④の RA- は「書き込み」ではなく「読み取り」の話です。後述しますが、GRS/GZRS は平常時にセカンダリを読めません。災害中もセカンダリから読みたいなら RA- 付きを選びます。

各プランの性格とハマりどころ

逆引きで目星を付けたら、候補プランの落とし穴も確認しておきましょう。メリットは表のとおりなので、ここでは特につまずきやすい点に寄せて整理します。

全プラン共通：冗長化は「消した／壊した」を守らない

最初に、最も誤解されやすい点を。冗長化が守るのはハードウェア障害や災害であって、誤削除・誤上書き・ランサムウェアによるデータ破壊ではありません。削除や上書きは全コピーに即時反映されるため、GZRS であっても「間違って消したファイル」は冗長化では戻せません。これに備えるのは冗長化ではなく、BLOB の論理削除（ソフトデリート）やバージョン管理、不変ストレージといった別機能です。冗長化とバックアップは別物、という前提をまず押さえてください。

LRS：安く小さく始めるためのプラン

最安でシンプル。再生成できる一時データ、ログ、キャッシュのように「最悪失っても作り直せる」データや、データガバナンス上リージョン外に出せないデータに向きます。

気をつけたい点:

• データセンター単位の災害（火災・水害）が起きると、全コピーが失われる可能性がある
• ゾーン障害・リージョン障害はカバーしない

ZRS：可用性のベースライン

3 つ以上の AZ に同期的に書き込むため、1 ゾーンが落ちても読み書きを継続できます。高可用性が要る本番ワークロードの出発点です。

気をつけたい点:

• 書き込みは全ゾーンへの同期書き込み完了をもって成功になる（整合性は強いが、その分の仕組みが背後にある）
• ゾーン切り替え時は DNS 再ポイントなどが走るため、アプリ側で指数バックオフ付きのリトライを実装しておくと安全
• アーカイブ アクセス層は ZRS / GZRS / RA-GZRS では未対応。アーカイブ層を使いたい構成では要注意

Geo 冗長（GRS / GZRS）：リージョン災害に備える

数百 km 離れたセカンダリにコピーを持ち、リージョンごと失われても復旧できます。GRS はプライマリ内が LRS、GZRS はプライマリ内が ZRS、という違いだけで、セカンダリ側はどちらも LRS で複製されます。

気をつけたい点:

• セカンダリへの複製は非同期。障害の瞬間にセカンダリ未反映の書き込みがあると、その分は失われうる（＝ RPO がゼロではない）
• 平常時はセカンダリを読み書きできない。セカンダリが使えるのは、原則フェールオーバー後
• プライマリ内のゾーン障害耐性が欲しいなら GRS ではなく GZRS を選ぶ

RA 付き（RA-GRS / RA-GZRS）：災害中も読み取りを止めない

セカンダリに平常時からアクセスできるのが RA- の価値です。セカンダリのエンドポイントはアカウント名に -secondary が付く形（例: myaccount-secondary.blob.core.windows.net）で、プライマリ障害中でも参照系を動かし続けられます。

気をつけたい点:

• 読めるのは**セカンダリ（読み取り専用）**であって、書き込みはできない。更新系を動かすにはフェールオーバーが必要
• セカンダリは非同期複製の遅れ分だけ古いデータを返しうる（結果整合）。読み取ったデータが最新とは限らない前提で設計する
• Azure Files は RA-GRS / RA-GZRS に非対応。Files 主体のアカウントでは選べない

選定フロー

ここまでを一枚のフローにまとめます。「何の障害から守りたいか」を上から順にたどってください。

図：守りたい障害レベルから冗長化プランを引く分岐フロー

【AWS 経験者向け】S3 の感覚で選ぶと事故る、ここだけ押さえる

AWS で S3 を触ってきた方は、ここまでの話を S3 の知識に重ねて読んでいると思います。ただ、冗長化の「決め方」そのものが S3 と Azure で違うため、S3 の感覚のまま選ぶと落とし穴にはまります。耐久性・障害範囲の対応づけを中心に、考え方の違いを整理します。

違い①：冗長化を決める「単位」が違う

S3 では冗長性はストレージクラス（S3 Standard、One Zone-IA、Glacier など）に紐づき、オブジェクト／バケット単位で選びます。しかもストレージクラスは「冗長性 ＋ アクセス頻度 ＋ コスト」がセットになった概念です。

一方 Azure の冗長化はストレージアカウント単位の独立した設定で、アクセス層（Hot/Cool/Cold/Archive）とは別の軸です。「冗長性」と「アクセス頻度によるコスト最適化」を分けて指定する、と捉えると混乱しません。

• S3: ストレージクラス = 冗長性 + アクセス頻度（束になっている）
• Azure: 冗長化（LRS〜RA-GZRS） と アクセス層（Hot/Cool/…） は別設定

違い②：マルチ AZ が「デフォルト」か「オプトイン」か

ここが最大の落とし穴です。S3 Standard は、何も意識しなくても最低 3 つの AZ にまたがって保存されます（耐久性は 9 が 11 個）。AWS 技術者の頭の中では「オブジェクトストレージ＝勝手にマルチ AZ」が標準感覚になっているはずです。

ところが Azure の LRS は単一データセンターです。S3 Standard のつもりで「とりあえず LRS」を選ぶと、ゾーン障害でデータを失いうる構成になってしまいます。Azure でマルチ AZ 相当にするには ZRS を明示的に選ぶ必要があります。

ちなみに **LRS も S3 Standard も耐久性は同じ「9 が 11 個」**ですが、安全性が同じという意味ではありません。耐久性の 9 の数は「平常時にデータが静かに失われない確率」で、DC 全損やゾーン障害に耐えられるか（守れる障害範囲）は別の軸です。この記事の比較表で両者を別の列に分けているのは、そのためです。

言い換えると、マルチ AZ 分散がデフォルトか、オプトインかが真逆です。

• S3: マルチ AZ がデフォルト。単一ゾーンにしたいときだけ One Zone-IA / Express One Zone をあえて選ぶ
• Azure: 単一 DC（LRS）が最安のベース。マルチ AZ にしたいときに ZRS をあえて選ぶ

違い③：耐久性・障害範囲の対応づけ

「何から守られるか」を軸に、S3 の考え方と Azure のプランを対応づけると次のようになります。耐久性目標はどちらも 9 が 11 個（99.999999999%）が基準で、Azure はゾーン／Geo 冗長を足すと 9 が 12〜16 個まで増えます。

守れる障害範囲	AWS S3 の考え方	Azure の相当プラン
単一ゾーンのみ（最安・ゾーン障害に弱い）	S3 One Zone-IA / Express One Zone	LRS
リージョン内で複数 AZ に分散	S3 Standard（デフォルトで 3 AZ 以上）	ZRS
別リージョンへ複製して災害に備える	CRR（クロスリージョンレプリケーション）を構成	GRS / GZRS
災害発生中もセカンダリ側を参照したい	CRR 先バケットを直接読む（常時アクセス可）	RA-GRS / RA-GZRS

注意したいのは、S3 Standard の対抗馬は LRS ではなく ZRS という点です。「S3 Standard ≒ Azure のデフォルト」と考えて LRS を選ぶのが、最も多い勘違いです。

なお ZRS（9 が 12 個）と S3 Standard（9 が 11 個）は同じ複数 AZ 分散ですが、耐久性の数値は各社が独自モデルで出した目標値で、刻み方のポリシーも違います（AWS は横並びで 11 個、Azure はオプション別に刻む）。桁の大小をベンダー間で単純比較しないのが安全です。

違い④：クロスリージョンの思想が逆

リージョン間複製の設計思想も S3 と Azure で向きが逆です。S3 の CRR は複製先に任意のリージョン・バケットを選べ、複製先も普通に読み書きできます。一方 Azure の GRS/GZRS はアカウント設定一つで自動な代わりに、複製先はペアリージョンに固定（東日本なら西日本）で、平常時はセカンダリを読めません（RA- なら読み取りのみ）。S3＝自分で組む・柔軟／ Azure＝設定一つ・固定、という住み分けです。

そのため「GRS を選べば好きなリージョンへ複製できる」は誤解で、たとえば東日本から任意の海外リージョンへ複製したいなら、冗長化ではなく Object Replication（S3 CRR 相当）を使います。任意リージョンの別アカウントへブロック BLOB を非同期コピーできますが、両アカウントでのバージョニング有効化などの前提があり、対象はブロック BLOB 限定です。海外へ出す場合はデータレジデンシー（データ所在地）要件に触れないかも要確認です。

AWS 技術者がまず押さえる一点: 「Azure の LRS は単一 DC。S3 Standard の感覚で LRS を選ぶとゾーン障害に弱い」。マルチ AZ 相当が欲しいなら ZRS から、が合言葉です。

後からプラン変更できる？移行時の注意点

「まず LRS で始めて、必要になったら上げればいい」と考えたくなりますが、変更のしやすさは「何を変えるか」で変わります。ポイントは、Geo 冗長（G）を付け外しするのか、ゾーン冗長（Z）を付け外しするのかです。

• Geo 冗長の付け外し（例: LRS ⇄ GRS）は手軽。ポータル / PowerShell / CLI から設定を変えるだけで切り替わる
• ゾーン冗長の付け外し（例: LRS ⇄ ZRS）は「コンバージョン（変換）」という扱いで、少し重い。ダウンタイムやデータ損失なしで実行できるものの、開始まで時間がかかり（目安で最大 72 時間程度）、完了時刻の保証もない

やっかいなのは、Geo とゾーンの両方をまたぐ変更（例: LRS → GZRS）は 1 回では済まない点です。「Geo 冗長の変更」と「ゾーン冗長のコンバージョン」をそれぞれ別の操作として、2 段階に分けて実施する必要があります（間に待機時間が入る場合もあります）。手順の順序や待機条件は構成によって変わるので、公式ドキュメントで最新の手順を確認してください。急ぎで確実に移したいなら、新アカウントへデータをコピーする手動移行を選ぶ手もあります。

なお、ゾーン冗長への変換はそのリージョンが ZRS/GZRS に対応していることが前提で、アーカイブ層の BLOB があると事前の階層変更が必要になるなど、構成次第の制約もあります。変更前に対象かどうかを確認しておくと安心です。

もう一点、Geo 冗長を選ぶならフェールオーバー時のデータ損失を設計に織り込んでおきましょう。前述のとおりセカンダリ複製は非同期のため、プライマリが復旧不能なまま障害が起きると、直近の書き込みは失われうる（RPO がゼロではない）という点です。参照系は RA- で読み取りを継続しつつ、更新系はデータ損失と不整合の可能性を前提にした復旧手順を用意しておくと安全です。

さらに見落としがちなのが、フェールオーバー後の冗長性の変化です。GRS / RA-GRS アカウントで（顧客起点の）フェールオーバーを実行すると、切り替わった新プライマリは LRS になります。復旧後はゾーン冗長や Geo 冗長が自動では戻らないため、必要なら改めて冗長化を設定し直す運用を前提にしておきましょう。

まとめ

障害レベルから逆引きすると、選定は次のように整理できます。

• 失っても作り直せるデータ / リージョン外に出せないデータ → LRS
• データセンター（ゾーン）障害に耐えたい本番の出発点 → ZRS
• リージョン災害にも備えたい → GRS（プライマリは局所冗長で可）/ GZRS（ゾーン障害にも強くしたい）
• 災害発生中も読み取りを止めたくない → RA-GRS / RA-GZRS

プラン選びのコツは「コピーを増やせば安心」ではなく、守りたい障害の範囲に過不足なく合わせることです。LRS と GZRS ではコストも機能も段違いなので、要件が届かない上位プランを選ぶのはそのまま無駄なコストになります。そして冗長化はあくまでハードウェア障害・災害への備えであって、誤削除やランサムウェアには別の機能（ソフトデリート・バージョン管理・不変ストレージ）で備える——この線引きを忘れないようにしたいところです。

注意事項
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。