RAIDはもう組まなくていい — EBSの冗長性とスナップショット設計

オンプレのサーバ設計で当たり前だった「まずRAIDをどう組むか」。AWSに移行した途端、この問いはほぼ消滅します。EBSはボリューム自体がAZ内で複製されているからです。この記事では「じゃあ何もしなくていいのか」に正確に答えます——原則イエス、ただし例外と、代わりにやるべきことがあります。

01EBSは最初から複製されている

EBSボリュームは、同一アベイラビリティゾーン内で自動的に複製されています。オンプレでRAID1/5/6が担っていた「ディスク単体の故障でデータを失わない」という役割は、AWSではサービス側に織り込み済みです。移行したサーバでソフトウェアRAID5を組み直す——これは冗長の二重化ではなく、単なる性能と管理コストの無駄です。

02例外はRAID0、それも最後の手段

唯一意味があるのはRAID0（ストライピング）で、目的は冗長ではなく単一ボリュームの上限突破です。gp3の上限（最大80,000 IOPS・2,000MiB/s、160GiB以上かつ8,000IOPS以上で到達）を超えたいとき、複数ボリュームを束ねて性能を合算します。

ただし順番を間違えないでください。先に検討すべきは、①io2への変更（2025年4月以降io2は全てBlock Express化。Nitro系インスタンスで最大256,000 IOPS、非Nitro系では最大64,000 IOPS）、②インスタンスのEBS帯域がボトルネックになっていないかの確認、の2つです。RAID0はスナップショットと復元を複雑にするので、他の手段で足りるなら使わないのが正解です。

03RAID0を組んだ場合のスナップショット整合性

複数ボリュームにまたがるデータは、バラバラのタイミングでスナップショットを取ると復元時に整合しません。RAID0やLVMでボリュームを束ねた場合は、マルチボリュームスナップショット（複数ボリュームを同一時点でまとめて取得するEBSの機能）を必ず使ってください。AWS Backupからも指定できます。

04オンプレの冗長設計は、こう置き換わる

• RAID1/5/6（ディスク故障対策） → EBS標準の複製（何もしない）
• ホットスペア → 不要。故障はAWS側で吸収
• 筐体冗長・レプリケーション → スナップショット＋Multi-AZ配置（サーバ2台をAZに分ける）。可用性の桁は構成SLA計算で確認を
• バックアップ（テープ等） → スナップショット世代管理＋AWS Backup（テープ移行の記事へ）

05浮いた工数と費用の使いみち

RAIDを設計しない、スペアを持たない、故障交換に駆けつけない。オンプレでストレージ保守に使っていた工数と保守費は、移行後は世代設計と復元テストに振り向けてください。ディスクは壊れなくなりましたが、「間違ってデータを消す」「ランサムウェアに暗号化される」は変わらず起きます。冗長の敵がハードウェア故障から人とマルウェアに変わった——これが移行後のストレージ運用の本質です。