S3 の 11 ナイン (99.999999999%) はどう実現されているのか - オブジェクトストレージの耐久性の裏側
S3 が公称する 99.999999999% の耐久性を支える内部アーキテクチャを、データ分散、整合性検証、自動修復の 3 つの仕組みから解説し、11 ナインが実際に何を意味するのかを具体的な数字で示します。
11 ナインとは具体的にどういう数字なのか
99.999999999% という数字は、直感的に理解しにくい桁数です。具体的に言い換えると、S3 に 1,000 万個のオブジェクトを保存した場合、1 万年に 1 個のオブジェクトが失われる確率です。この数字は「可用性」ではなく「耐久性」(Durability) である点に注意が必要です。可用性はサービスにアクセスできる時間の割合で、S3 Standard の可用性は 99.99% (年間約 52 分のダウンタイム) です。耐久性はデータが失われない確率で、AWS は 1 年あたり 99.999999999% の耐久性を提供する設計だと明記しています。この設計値は S3 Standard 固有のものではなく、S3 Intelligent-Tiering、S3 Standard-IA、S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive にも共通して適用されます (2026 年 8 月時点)。つまり、S3 に一時的にアクセスできない瞬間はあり得ますが、データ自体が消えることは事実上ないという設計です。この区別を理解していないと、S3 の障害時に「データが消えたのでは」と誤解するケースがあります。
データ分散 - 最低 3 つの AZ に冗長化する仕組み
S3 の耐久性の第 1 の柱は、データの物理的な分散です。S3 Standard にオブジェクトをアップロードすると、AWS は同一リージョン内の最低 3 つの Availability Zone (AZ) にまたがる複数のデバイスへデータを冗長化します (2026 年 8 月時点)。公式ドキュメントでは、アップロードを成功と見なす前に、データが複数のストレージデバイスへ正しく冗長に格納されたことを検証すると説明されています。つまり、PUT リクエストへの成功応答は、冗長化の検証が済んだことを意味します。各 AZ は、電力系統・ネットワーク・接続が冗長化された 1 つ以上の独立したデータセンターで構成されます。AZ 同士は意味のある距離 (数キロメートル単位) だけ物理的に離れており、その一方でリージョン内の AZ はすべて互いに 100 km (60 マイル) 以内に収まります。この配置により、1 つの AZ が自然災害や大規模障害で完全に失われても、残りの AZ にデータが存在するため、オブジェクトは失われません。AWS も、S3 Standard などのストレージクラスは AZ 1 つの喪失に耐えてデータを維持する設計であると明記しています。S3 One Zone-IA は例外で、単一の AZ 内の複数デバイスにのみデータを保存するため、耐久性の設計値は 99.999999999% のままですが、AZ 全体の物理的破壊に対しては脆弱です。
整合性検証 - すべてのビットを常に監視する
データを複数の AZ に分散するだけでは、11 ナインは達成できません。ディスクの経年劣化、宇宙線によるビット反転、ファームウェアのバグなど、データが静かに破損する「サイレントデータコラプション」への対策が不可欠です。S3 はアップロード時にチェックサムでデータの整合性を検証します。クライアント側の値と S3 が独立に計算した値が一致した場合にのみオブジェクトを受け付け、チェックサム値はオブジェクトのメタデータとして保存されます。2022 年 2 月には追加のチェックサムアルゴリズムを選択できる機能が加わり、2026 年 8 月時点では CRC-64/NVME、CRC-32、CRC-32C、SHA-1、SHA-256、SHA-512、XXHash64、XXHash3、XXHash128、MD5 から選べます。アルゴリズムを指定しない場合は CRC-64/NVME が自動的に使われます。保存後も、これらのストレージクラスはチェックサムを使ってデータの整合性を定期的に検証する設計であると公式ドキュメントに明記されています。ストレージ分野で一般にデータスクラビングと呼ばれる、保存済みのデータを定期的に読み直して照合する考え方です。検証の実行頻度や規模は公表されていませんが、破損が検出された場合は、冗長に保持されている正常なコピーから修復されます。この検出と修復のサイクルが、データの劣化を未然に防ぐ仕組みです。
自動修復 - 障害を検知したら人間の介入なしに復旧する
S3 の自動修復メカニズムは、ディスク障害、サーバー障害、AZ レベルの障害に対して段階的に動作します。個々のディスクが故障した場合、S3 はそれを検知し、そのディスクが保持していたデータを他の正常なデバイスへ再複製します。大規模なストレージ基盤はディスクの故障が日常的に発生する前提で設計されており、この修復は 24 時間 365 日、人間の介入なしに実行されます。サーバー単位の障害でも同様のプロセスが動作します。公式ドキュメントも、S3 Standard などのストレージクラスは、複数のデバイスが同時に故障する事象を、失われた冗長性を迅速に検知して修復することで扱う設計だと説明しています。重要なのは、この修復の速度です。障害が発生してから再複製が完了するまでの間は、冗長性が一時的に低下した状態になります。この「脆弱ウィンドウ」をいかに短く保つかが耐久性の要点ですが、AWS は具体的な修復時間を公表していません。同様に、S3 がオブジェクトをどのように分割・符号化して保存しているかという内部実装も公表されていないため、レプリカ方式か消失訂正符号かといった前提を置いて設計を組み立てるのは避けるべきです。設計時に依拠できるのは、公表されている耐久性の設計値と、最低 3 つの AZ にまたがって冗長化されるという保存方式です。
11 ナインでもデータが失われるシナリオ
S3 の耐久性は極めて高いですが、データ損失のリスクがゼロになるわけではありません。11 ナインが保証するのは、AWS 側の物理的な障害によるデータ損失に対してです。ユーザー側の操作ミスは保証の対象外です。最も多いデータ損失の原因は、誤った DELETE 操作です。S3 のバージョニングを有効にしていない状態でオブジェクトを削除すると、即座に完全に削除されます。バージョニングを有効にしていても、バージョン ID を指定した DELETE は永久削除です。この問題への対策として、S3 Object Lock (WORM: Write Once Read Many) を設定すれば、指定期間中はオブジェクトの削除や上書きを物理的に不可能にできます。MFA Delete を有効にすれば、削除操作に MFA 認証を要求できます。もう一つの見落としがちなリスクは、暗号化キーの紛失です。SSE-C (顧客提供キー) で暗号化したオブジェクトは、キーを紛失すると復号不可能になります。S3 側にはデータが存在しますが、読み取れない状態です。SSE-KMS を使用し、KMS キーの削除に待機期間 (7〜30 日) を設定することで、このリスクを軽減できます。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。