災害、ランサムウェア、人為ミス、機器故障からどうやってデータを守るか？――クラウドでも重要な「ストレージのデータ保護」超入門：AWSで学ぶクラウド時代のサーバ＆ストレージ基礎知識（7）
これまであまり物理的なサーバとストレージに触れてこなかった方を対象に、AWSを用いてサーバとストレージの基礎知識を解説する連載。最終回となる第7回は、オンプレミス／クラウドにおける「ストレージのデータ保護」の考え方を詳しく解説します。
本連載「AWSで学ぶクラウド時代のサーバ＆ストレージ基礎知識」は、これまで仮想マシン（Virtual Machine：VM）は使っていたけれど、物理的なサーバに触れてこなかったエンジニアやサーバ管理者、情報システム部門担当者（情シス）などを対象に、サーバとストレージの基礎知識を「Amazon Web Services」（AWS）の操作を例に解説しています。
本連載は全7回で、各回は下記のテーマで基礎知識を解説して、テーマに関連するAWSのサービスを紹介してきました。
- 第1回：サーバ
- 第2回：ブロックストレージ
- 第3回：仮想化
- 第4回：サーバ運用に必要な技術
- 第5回：ファイルストレージ
- 第6回：オブジェクトストレージ
- 第7回：ストレージのデータ保護
最終回となる今回は「ストレージのデータ保護」をテーマに、オンプレミスのストレージにおけるデータ保護の考え方とパブリッククラウド（AWS）のストレージサービスを利用した場合のデータ保護の考え方について解説します。これまで第2回（ブロックストレージ）、第5回（ファイルストレージ）、第6回（オブジェクトストレージ）でさまざまなストレージの形態やAWSのサービスを紹介し、その中でも一部のデータ保護機能にも触れていますが、今回あらためてデータ保護の全体像を解説します。
データ保護の重要性と基本的な考え方
データ保護の技術的な話に入る前に、「なぜデータ保護が重要なのか」を振り返ってみましょう。「データ保護」と聞くと、単純に「バックアップ」と考える人も多いと思いますが、バックアップはデータ保護の一要素にすぎず、可用性や耐障害性、災害復旧といった広い視点からの設計が必要です。
データ保護の重要性
ITインフラ運用の現場では、「データ保護」は最優先事項の一つです。なぜなら、ストレージに格納されている情報は、企業活動の基盤そのものであり、失われれば業務継続が困難になるだけでなく、顧客や取引先からの信頼も失いかねないからです。あなたが開発しているサービスの顧客データベースが、ある日突然消えてしまったらどうなるでしょうか？ データ消失がビジネスに与えるインパクトは計り知れません。
- 直接的な経済損失
売り上げ機会の損失、顧客への補償など、直接的な金銭的被害が発生します。 - 信用の失墜
「あの会社は顧客データを守れない」という評判が広まれば、顧客離れやブランドイメージの低下は避けられません。一度失った信用を取り戻すのは非常に困難です。 - 事業継続性の危機
業務に必要なデータが失われれば、事業そのものが停止してしまう可能性があります。 - 法的／コンプライアンス上の責任
個人情報保護法やGDPR（EU一般データ保護規則）などの法規制、あるいは業界のガイドラインで定められたデータ保持義務を果たせなくなり、法的な罰則や訴訟のリスクにつながります。
このように、データは単なる情報の集まりではなく、“ビジネスの継続性を支える生命線”です。だからこそ、私たちはあらゆる脅威に対して「データ保護」を真剣に考え、実装しなければなりません。
データ保護の2つの指標「RPO」と「RTO」
データ保護戦略を立てる上で、絶対に欠かせない2つの重要な指標があります。それが「RPO」と「RTO」です。システムの要件定義などで耳にしたことがあるかもしれませんが、ここであらためてその意味を正確に理解しておきましょう。
- RPO（Recovery Point Objective／目標復旧時点）
RPOは「どの時点のデータまで復旧できればよいか」を示す目標値です。これは「許容できるデータ損失量」と言い換えることもできます。
- RPO ＝ 24時間
システム障害が発生した場合、最大で24時間前までのデータが失われることを許容する、という意味です。例えば、毎日深夜0時にバックアップを取得しているシステムが、翌日の23時に障害を起こした場合、前日の0時の状態にまでしか戻せません。この場合、約23時間分のデータが失われます。 - RPO ＝ 1時間
1時間ごとにバックアップやデータを複製しているシステムで、最大1時間分のデータ損失を許容します。 - RPO ＝ 0秒
データ損失を一切許容しない、という最も厳しい目標です。データの書き込みが常に複数の場所に同時に行われる（同期レプリケーションなど）必要があります。
- RTO（Recovery Time Objective／目標復旧時間）
RTOは「システム障害が発生してから、どれくらいの時間で復旧させるか」を示す目標値です。これは「許容できるシステム停止時間（ダウンタイム）」です。
- RTO ＝ 24時間
障害発生後、24時間以内にシステムを復旧させ、サービスを再開させることを目標とします。 - RTO ＝ 1時間
1時間以内に復旧させる必要があります。バックアップからのリストアだけでなく、待機系システムへの切り替え（フェイルオーバー）など、より迅速な復旧手段が求められます。 - RTO ＝ 0秒
システム停止を一切許容しない、無停止での運用が目標です。常に稼働している冗長化構成が必須となります。
- RPO／RTOとコストの関係
ここで重要なのは、RPOとRTOをゼロに近づければ近づけるほど、データ保護のレベルは上がっていきますが、同時にシステムの実装コストと運用コストは指数関数的に増大するという点です。
例えば、金融機関の勘定系システムのように1秒の停止や1件の取引データ損失も許されないシステムでは、「RPO＝0、RTO＝0」を目指すために、非常に高価なハードウェアやソフトウェア、専用線を用いたリアルタイムでのデータ同期など、莫大（ばくだい）な投資が必要になります。
一方で、社内の情報共有ポータルのようなシステムであれば、「RPO＝24時間（前日のバックアップがあればOK）、RTO＝8時間（翌営業開始までに復旧すればOK）」といった要件で十分かもしれません。この場合、夜間バッチでバックアップを取得するといった比較的安価な手法で対応できます。データ保護を設計する最初のステップは、対象となるシステムやデータの重要性を評価し、ビジネス要件として適切なRPOとRTOを定義することです。これが後述する具体的な技術選定の指標となります。
オンプレミスストレージにおけるデータ保護の世界
企業は自社内のデータセンターやサーバルームに物理的なサーバやストレージを設置してシステムを運用しています。これが「オンプレミス」環境です。オンプレミスでは、データ保護に関する全ての責任を自分たちで負わなければなりません。物理的なハードウェアの故障への対策から、データのバックアップ、災害対策まで、全てを自前で設計、構築、運用する必要があります。
ここでは、そんなオンプレミスで培われてきた伝統的かつ重要なデータ保護の手法を解説します。これらの知識は、AWSのサービスが解決している課題を深く理解するために役に立ちます。
データに対する脅威と保護
オンプレミスにおけるデータ保護は、大きく分けて2つの脅威を想定する必要があります。
1.物理的な脅威
HDDの故障、電源ユニットの故障、サーバ本体の故障といったハードウェア障害。そして、火災、地震、水害などの自然災害。さらには、機器の盗難なども含まれます。
2.論理的な脅威
オペレーターによるファイルの誤削除や、間違ったデータへの更新といった人為的な操作ミス。そして、ランサムウェア（身代金要求型マルウェア）のようにデータを暗号化して身代金を要求するマルウェア感染やサイバー攻撃。
これらの多様な脅威に対抗するため、オンプレミスでは複数の技術を階層的に組み合わせる「多層防御」のアプローチが取られます。特に、昨今ではランサムウェアの被害に遭う企業が増加傾向にあり、世界的な脅威の一つと見なされています。そのため、サイバー攻撃への対策は今や必須レベルになっています。
ドライブの冗長化「RAID」
本連載第2回でも述べていますが、データ保護の最も基本的な第一歩が、HDDやSSDの故障に備える「RAID」技術です。
「RAID」（Redundant Arrays of Inexpensive Disks）は、複数の安価な（Inexpensive）ディスクを束ねて、あたかも1つの大きなディスクのように見せる技術で、その組み合わせ方（RAIDレベル）によって、信頼性や性能を向上させます。HDDやSSDに障害が発生したとしてもデータは失われず、業務サービスを継続できます。そのため、どのようなストレージシステムも備えている機能です。しかし、RAIDはディスク単体の物理故障に対しては非常に有効ですが、万能ではなく、以下のケースには対応できません。
- RAIDコントローラーの故障
RAIDを制御する専用カードやチップが故障した場合、ディスクが無事でもデータにアクセスできなくなることがあります。 - 複数台の同時故障
「RAID 5」で2台、「RAID 6」で3台など、許容範囲を超える数のディスクが同時に故障した場合はデータを失います。 - 論理障害
「ファイルを誤って削除した」「ランサムウェアに感染した」といった、ディスクが物理的に壊れていない障害には全く無力です。RAIDは変更を即座に全てのディスクに反映するため、誤った削除も即座にミラーリング先に反映されてしまいます。 - 災害
火災や地震でサーバごと破壊されれば、RAID構成もろともデータを失います。
RAIDはあくまで「システムの可用性を高めるための技術」であり、「データをバックアップするための技術」ではない、ということを強く認識する必要があります。
データ保護の要「バックアップ」
RAIDなどの物理コンポーネント冗長化技術の限界を補うのが「バックアップ」です。バックアップは、データのコピーを別のストレージ媒体（別のディスク、テープなど）に保存することです。これにより、RAIDでは防げない論理障害や災害からのデータ復旧が可能になります。このバックアップをデータ保護要件を満たすように、設計、実装することが重要です。
- バックアップの3つの方式
バックアップには主に3つの方式があり、それぞれにメリット／デメリットがあります。RPOや許容されるバックアップ時間（バックアップウィンドウ）に応じて使い分けます。
■フルバックアップ（完全バックアップ）
対象となる全てのデータを毎回コピーする方式です。
・メリット：復旧（リストア）は、このバックアップデータ1つを戻すだけで完了するため、非常にシンプルで高速です。
・デメリット：毎回全データをコピーするため、バックアップに時間がかかり、保存先のストレージ容量も大量に消費します。
■差分バックアップ
一度フルバックアップを取得し、その後は「前回のフルバックアップからの変更点」だけを毎回バックアップする方式です。
・メリット：日々のバックアップは変更点のみなので、時間と容量を節約できます。
・デメリット：復旧には「最後のフルバックアップ」と「最後の差分バックアップ」の2つが必要です。フルバックアップ後に取得した差分バックアップのデータは、回を追うごとに肥大化していきます。
■増分バックアップ
一度フルバックアップを取得し、その後は「前回のバックアップ（フルまたは増分）からの変更点」だけをバックアップします。
・メリット：差分バックアップよりもさらに日々のバックアップ量が最も少なく、時間も容量も最小限で済みます。
・デメリット：「最後のフルバックアップ」と、そこから復旧したい時点までの「全ての増分バックアップ」を順番に適用していく必要があるため、復旧に時間がかかります。途中の増分データが1つでも破損していると、そこから先は復旧できません。
一般的には、これらのバックアップ方式を組み合わせて運用します。最近では各バックアップのいいとこ取りした「永久増分（差分）バックアップ」というのも主流のバックアップとなっています。
- バックアップメディアと保管場所「3-2-1ルール」
バックアップデータをどこに保存するかも非常に重要です。ここで登場するのが、データ保護の黄金律と言われる「3-2-1ルール」です。
- 3：データを3つ持つ（本番データ＋2つのバックアップコピー）
- 2：2種類の異なるメディアに保存する（例：HDDとテープ）
- 1：バックアップのうち、1つはオフサイト（遠隔地）に保管する
なぜ、3-2-1ルールが重要なのでしょうか。例えば、バックアップデータを本番サーバ内の別ディスクに保存しているだけでは、サーバが火災に遭えば本番データもバックアップもろとも失われてしまいます。
そこで、テープなどの可搬メディアにバックアップを取得し、それを遠隔地の倉庫や別の支社に物理的に輸送して保管する、といった「オフサイト保管」を行います。これにより、データセンターレベルの大規模災害からもデータを守ることができるのです。昨今では、「Amazon Simple Storage Service」（Amazon S3）などのパブリッククラウドのストレージサービスを疑似オフサイトとして利用し、クラウドにバックアップのコピー（二次バックアップ）を配置するというケースも増えてきています。
迅速な復旧と災害対策「スナップショットとレプリケーション」
バックアップは確実なデータ保護手段ですが、GB（ギガバイト）、TB（テラバイト）単位のデータをテープからリストアするには数時間〜数日かかることもあり、RTOが短いシステムには向きません。そこで、より迅速な復旧を実現する技術として「スナップショット」と「レプリケーション」が利用されます。
■スナップショット
ある特定時点のストレージのファイルやボリュームの状態を、瞬時に複製して保存する機能（詳細は本連載第2回記事を参照）です。多くのストレージ製品や仮想化基盤が標準で備えています。
・メリット：実際のデータコピーを伴わない（差分情報のみを管理する）方式が多いため、バックアップの取得が非常に高速（数秒）で、ディスク容量もあまり消費しません。復元も高速です。
・デメリット：スナップショットは元のボリュームに依存しているため、元のボリュームが破損するとスナップショットも意味を成さなくなる場合があります。スナップショットはバックアップの代替にはなりません。
・用途：「パッチ適用の直前に念のためスナップショットを取得し、問題があればすぐに切り戻す」「誤操作でファイルを消してしまったのですぐに戻したい」といった、短時間のRTOが求められる一時的な復旧ポイントとして非常に有効です。
■レプリケーション（複製）
あるストレージ（プライマリー）から別のストレージ（セカンダリー）へ、データをリアルタイムまたは定期的に複製（コピー）する技術です。主に災害対策（DR: Disaster Recovery）目的で、遠隔地のデータセンター間などで利用されます。
・同期レプリケーション
プライマリーへの書き込みが、セカンダリーにも書き込まれたことを確認してから完了応答を返します。
・メリット：RPO=0が実現でき、データ損失がありません。
・デメリット：遠隔地との通信遅延がそのまま書き込みの遅延となるため、パフォーマンスが低下します。近距離（数キロ〜数十キロ）での利用に限られます。
・非同期レプリケーション
プライマリーへの書き込み完了を待たずに応答を返し、バックグラウンドでセカンダリーへデータを転送します。
・メリット：通信遅延の影響を受けにくく、パフォーマンスが良いです。大陸間などの長距離でも利用可能です。
・デメリット：プライマリーに障害が発生した際、まだセカンダリーに転送されていないデータは失われるため、「RPO ＞ 0」となります（数秒〜数分のデータロス）
オンプレミスでDR（ディザスタリカバリー：災害復旧）サイトを構築する場合は、高価なストレージ製品とサイト間を結ぶ広帯域な専用線が必要で、非常に高コストなソリューションになりますが、得られるメリットも大きいです。
サイバー攻撃（ランサムウェアなど）の対策「WORM」
サイバー攻撃の中でも、ストレージにとって特に大きな脅威となっているのが「ランサムウェア」です。近年、多くの企業がその被害に遭っており、今後も増加が予測されています。多くの場合、ネットワーク側やエンドポイント（端末、仮想マシンなど）で対策されることが多いですが、攻撃を100％防ぐことは困難です。
ランサムウェアの特徴は、単にデータを暗号化するだけでなく、バックアップデータまでも標的にする点にあります。バックアップが暗号化や削除の被害に遭うと、せっかく取得していたデータから復旧できなくなってしまうため、バックアップ自体を保護する仕組みが不可欠です。そのため、データを格納するストレージ側での対策も考える必要があります。
そこで、注目されているストレージ機能の一つ「WORM」（Write One Read Many）機能です。WORMはその名の通り、「一度書き込んだデータは変更、削除できず、読み取りのみ可能とする」機能です。もともとは、企業の重要データを一定期間改ざん不可の状態で保持する、というコンプライアンス要件に応えるために登場した技術です。
近年はランサムウェア対策の有効な手段として、多くのストレージベンダーに採用される重要な技術になっています。従来の複製を中心としたデータ保護に加え、バックアップデータやスナップショットをWORMストレージ上に保管することで、改ざんや消去から確実に守ることが可能になります。
オンプレミスではここまで述べたようなデータの脅威に対し、正しくRPO/RTOの要件を定義し、それに従った可用性、耐障害性を維持するようデータ保護を設計することが重要になってくるのです。
クラウドのデータ保護
ここまでオンプレミスでのデータ保護を説明してきましたが、ここからはクラウドのデータ保護はどのように考えればよいかについて解説してきます。
クラウドの責任共有モデル
クラウドを理解する上で最も重要な概念が「責任共有モデル」（Shared Responsibility Model）です。これは、セキュリティとコンプライアンスに関する責任を、AWSと利用者（顧客）で分担するという考え方です。
- AWSの責任範囲（クラウド“の”セキュリティ）
AWSは、サービスを稼働させている物理的なインフラストラクチャを保護する責任を負います。
具体的には、データセンターの物理的なセキュリティ（入退室管理など）、サーバ、ストレージ、ネットワーク機器といったハードウェア、そしてそれらを動かすための基盤ソフトウェア（ハイパーバイザーなど）の管理、運用、保護が含まれます。つまり、オンプレミスで解説したRAIDなどのハードウェア障害や、データセンターの電源／空調管理といった物理層のことは、利用者の責任で管理する必要はありません。 - 利用者の責任範囲（クラウド“における”セキュリティ）
利用者は、AWSというクラウド“上”に構築したものに対して保護の責任を負います。
具体的には、OSのパッチ管理、セキュリティグループ（ファイアウォール）の設定、IAM（Identity and Access Management：アイデンティティーおよびアクセス管理）によるアクセス権管理、そしてクラウド上にあるデータの暗号化やバックアップなどが含まれます。
この責任共有モデルにより、利用者は面倒でコストのかかる物理インフラの管理から解放され、アプリケーションやデータといった、よりビジネス価値に近い部分の保護に集中できます。逆に言うと、利用者自身がデータを保護する責任があるのです。つまり、物理障害を意識しなくてよいわけではなく、オンプレミスと同様、データ保護の計画、設計が重要となります。
AWSのリージョンとAZ
AWSには「リージョン」や「AZ」（Availability Zone）といった概念があります。これらはAWSの物理的なインフラ構成を示す非常に重要な概念です。オンプレミスで例えると「リージョン＝都市」と「AZ＝データセンター」と捉えることでイメージしやすいでしょう。
例えば、東京リージョン（ap-northeast-1）には4つのAZ（ap-northeast-1a、ap-northeast-1b、ap-northeast-1c、ap-northeast-1d）があります。これは、東京という都市に4つのデータセンターがあると考えることができ、サービスにもよりますが、データは最終的にいずれかのAZに配置されることになります。
物理的なデータセンターである以上、地理的な災害が発生した場合はデータセンター全体がその影響を受け、データが失われるケースもあります。そのため、オンプレミスでのデータ保護の考え方と同じく、データセンター全体の障害に耐え得るように重要なデータの配置やバックアップを検討する必要があります。
オンプレミスで対策するには、複数の地理的に離れたデータセンターを契約し、データセンター内のストレージの冗長化とデータセンター間をつなぐ拠点間ネットワーク構築などが必要となり、設計としても複雑かつ多額のコストのかかるソリューションが必要ですが、AWSではリージョンとAZ、およびそれらのデータ保護を実現する機能をサービス内またはサービスを連携することで提供されていることが大きなメリットです。利用者はデータ保護要件に応じて、AZ障害に対応する場合は「マルチAZ構成」、リージョン障害にも対応すべき場合には「クロスリージョン構成」でデータの保護を実現できるのです。
では実際に、AWSのストレージサービスではどのようなデータ保護機能があるのかを見ていきましょう。
AWSの主要ストレージサービスのデータ保護機能
ここからは、AWSの主要なストレージサービスがどのようなデータ保護機能を提供しているのかを解説していきます。
Amazon S3：オブジェクトストレージのデータ保護
Amazon S3は、その圧倒的な耐久性、スケーラビリティ、低コストから、バックアップデータの保存先や静的Webサイトのホスティング、データ分析基盤など、あらゆる用途で利用されるAWSのコアサービスです。Amazon S3に関しては本連載第6回でも解説しているので併せてご確認ください。
・バージョニング
「バージョニング」を有効にすると、S3バケット内の全てのオブジェクトのバージョンが“世代”として保持されます。ファイルを上書きしても古いバージョンは消えずに残り、誤って削除してしまっても「削除マーカー」が付くだけで、実体は残っています。人為的な誤操作（上書きや削除）からデータを簡単に保護できるので、ランサムウェア対策としても有効な場合があります。
バージョニングの設定はS3バケットのプロパティから有効／無効を設定できます。
オブジェクトの過去のバージョンを確認するには、「バージョンの表示」をオンにすることで確認可能です。
・レプリケーション（CRR/SRR）
あるS3バケット（ソース）へのオブジェクトの追加や変更を、別のS3バケット（ターゲット）へ自動的に複製する機能です。
- CRR（クロスリージョンレプリケーション）
あるバケット内のオブジェクトを別のリージョン（例：東京リージョン → オレゴンリージョン）のS3バケットに複製します。 - SRR（同一リージョンレプリケーション）
あるバケット内のオブジェクトを同じリージョン内の別バケットにオブジェクトを複製します。
CRRは地理的に離れた場所へデータを複製するため、リージョン全体に影響が及ぶような大規模災害に対するDR対策として極めて有効です。SRRはログデータを集約するバケットを作成するなどの用途で使われます。
CRR/SRRはS3バケットを選択し、レプリケーションルールを定義することで設定できます。「送信先」としては、同一リージョン内のバケットや他のリージョンにあるバケットを指定します。なお、設定内では「CRR」や「SRR」という名称は使われていないので注意してください。
・S3オブジェクトロック
WORMモデルを提供し、オブジェクトが一度書き込まれた後、指定した期間または永久に変更／削除されることを防ぎます。訴訟や規制要件など、法的なデータ保持義務（コンプライアンス）が求められる場合に、データの完全性を保証します。ランサムウェア対策としても数多くのバックアップベンダーが、S3オブジェクトロックとの連携機能を提供しています。
S3オブジェクトロックはバージョニングと同様、S3バケットのプロパティから設定できますが、前提としてバージョニングが有効である必要があります。また、保持モードとして「ガバナンス」と「コンプライアンス」があり、コンプライアンスモードの方がより強力です。ガバナンスモードではS3バケットの管理者であれば、オブジェクトを削除できますが、コンプライアンスモードでは管理者でも保護されたオブジェクトを削除、上書きすることはできません。
Amazon EBS：ブロックストレージのデータ保護
「Amazon EBS」（Elastic Block Store）は、「Amazon EC2」（Elastic Compute Cloud）インスタンスにアタッチして利用する、OSやデータベースのディスク領域として使われるブロックストレージです。オンプレミスで言うところの「サーバ内蔵ディスク」や「SAN（Storage Area Network）ストレージ」に相当します。Amazon EBSに関しては本連載第2回をご確認ください。
・スナップショット
ある時点のEBSボリュームのコピーをS3に保存する機能です。これがEBSの最も基本的なバックアップ手段となります。「スナップショット」という名称ですが、実際にはバックアップに近い手法です。スナップショットはインスタンス全体（EBSボリューム含む）とEBSボリューム単位で作成できます。
スナップショットは対象のEBSボリュームを選択し、「アクション」メニューから「スナップショットを作成」を実行することで作成できます。
- スナップショットからの復元
スナップショットから新しいEBSボリュームを作成し、EC2インスタンスにアタッチすることですぐに利用できます。オンプレミスストレージのスナップショット機能では元のボリュームに瞬時にリストア可能ですが、EBSはできないため注意が必要です。また、ファイルレベルでS3に復元することも可能です。 - 別AZ／別リージョンへのコピー
スナップショット自体は元のEBSボリュームと同一AZ内に作成されますが、簡単に別のAZやリージョンにコピーできるため、DR対策にも利用できます。 - スナップショットロック
スナップショットに対して指定した期間、削除、上書きができないように設定できます。
・Amazon Data Lifecycle Manager（DLM）
EBSスナップショットの作成、保持、削除のライフサイクルを自動化するためのポリシー管理サービスです。「毎日深夜2時にバックアップを取得し、最新の7世代分だけを保持して、古いものから自動で削除する」といった運用を、手動やスクリプト実行なしで実現できます。バックアップの運用負荷を劇的に削減し、取得漏れや消し忘れといったヒューマンエラーを防ぐことができます。
Amazon EFS：ファイルストレージのデータ保護
「Amazon EFS」（Elastic File System）は、複数のEC2インスタンスから同時にマウントして利用できる、フルマネージドなNFS（Network File System）ファイル共有サービスです。オンプレミスで言うところの「NAS」（Network Attached Storage）に相当します。EFSに関しては本連載第5回をご確認ください。
・設計思想による高い可用性と耐久性
EFSは「Standardストレージクラス」を選択すると、デフォルト（既定）でデータを複数のAZにまたがって自動的に冗長保存します。そのため、利用者がEFSのマルチAZ構成を意識して構成する必要はありません。これにより、AZ障害時にもデータ損失なく、ファイルシステムへのアクセスを継続できます。
・レプリケーション
同一リージョン内および別のリージョンに対してレプリケーションを実行できます。
・AWS Backupとの統合
EFSは自動バックアップを有効化すると、「AWS Backup」によって「バックアップボールト」と呼ばれる領域にバックアップできます。
AWS Backupで実現する統合データ保護戦略
ここまでで、S3やEBS、EFSが持つ個別のデータ保護機能に触れてきましたが、システムが複雑化し、これら複数のAWSサービスを組み合わせて利用するようになると、サービスごとにバックアップ設定の管理がバラバラになってしまうという新たな課題が生まれます。
これでは、バックアップの取得漏れや設定ミスといったヒューマンエラーのリスクが高まり、組織全体のデータ保護ポリシーを統一的に適用することも困難になります。
この課題を解決するのがAWS Backupです。AWS Backupは、複数のAWSサービスにまたがるバックアップを一元的に管理し、自動化するためのフルマネージドサービスです。AWS Backupがもたらす主な価値は以下の通りです。
・一元管理による運用の簡素化
EC2インスタンスやEBSボリューム、EFSファイルシステム、「Amazon RDS」（Relational Database Service）データベース、「Amazon DynamoDB」テーブル、S3バケットなど、多岐にわたるAWSリソースのバックアップ設定を、単一のコンソールから集中管理できます。サービスごとに管理画面を行き来する必要がなくなり、運用負荷が劇的に軽減されます。
・ポリシーベースの自動化
「バックアッププラン」という形で、組織のデータ保護ポリシー（RPO/RTOに準じた要件）を定義できます。例えば、「毎日深夜2時にバックアップを取得し、日次バックアップは35日間保持、月次バックアップは1年間保持する。さらに月次バックアップは災害対策として別リージョンにコピーする」といった複雑な要件も、一度ポリシーとして設定すれば、後はAWS Backupが自動で実行します。
・ランサムウェアからの保護
バックアップデータを「バックアップボールト」と呼ばれる専用のコンテナに格納します。このボールトに「ボールトロック」というWORM機能を適用することで、一度保存したバックアップデータを指定した期間、誰にも（たとえルートユーザーであっても）削除、変更できないように設定できます。これは、万が一、システムがランサムウェアに感染しても、安全なバックアップからの復旧を保証できます。
まとめ
本稿では、オンプレミス環境におけるデータ保護の基本的な考え方と手法、さらにAWSが提供するストレージサービスのデータ保護機能を解説しました。クラウド環境に移行したからといって「バックアップを取らなくても問題ない」という考え方は非常に危険です。AWSでもデータの保護責任は利用者にあり、設計や運用を誤ればデータ損失のリスクは避けられません。
一方で、AWSではスナップショット、ライフサイクル管理、AZ／リージョンをまたいだレプリケーションなど、オンプレミスでは構築や運用コストが膨らみがちな機能がサービスとして提供されています。これらを適切に組み合わせることで、堅牢（けんろう）かつ効率的なデータ保護を実現できます。
重要なのは、提供される機能を単に利用するのではなく、自社の要件に合わせて「どのサービスを、どのレベルで、どの範囲に」適用するかを設計段階で明確にすることです。例えば、RPOやRTOの定義に基づき、スナップショット頻度やマルチリージョン冗長化の有無を決定する、といった具体的な検討が必要となります。
本稿では詳細な設計手法やベストプラクティスまでは踏み込んでいませんが、これまでデータ保護の設計を十分に検討できていなかった方にとって、AWSにおけるデータ保護を再考するための一助となれば幸いです。
筆者紹介
金只圭司
ネットワンシステムズ ビジネス開発本部 応用技術部 クラウドインフラチーム
2008年にネットワンシステムズに新卒として入社。ストレージ、バックアップ製品の評価、検証、案件支援を主な業務として担当。オンプレミスやクラウド問わず、データを取り巻く最新技術動向の調査や先進技術評価に従事している。
Copyright © ITmedia, Inc. All Rights Reserved.