はじめに
本ドキュメントは、AWSのスナップショット機能に関する基礎から実践までを分かりやすくまとめたガイドです。クラウド上でのデータ保護やバックアップ戦略を検討するエンジニアやシステム管理者を主な対象としています。
目的は次のとおりです。スナップショットの基本概念を理解し、バックアップやAMIとの違いを把握したうえで、実装時の注意点や効率的な運用方法を学ぶことです。加えて、OpenSearch Serverlessでのスナップショット機能や、S3を使ったアーカイブ戦略についても触れます。
本書の構成は全7章です。第2章で基本概念、第3章でバックアップとの比較、第4章でAMIとの違いを説明します。第5章では作成の仕組みと効率化、第6章でOpenSearch Serverless固有の扱い方、第7章でS3アーカイブ戦略を扱います。
読み方の目安として、基礎知識があれば本書を順に読むことで実務に役立つ知見を得られます。各章は実例を交えて丁寧に説明しますので、運用設計やトラブルシュートの参考にしてください。
AWSスナップショットの基本概念
概要
AWSのスナップショットは、ある時点のシステムやストレージの「状態を記録する機能」です。たとえばファイルやディスクの“写真”を撮るように保存します。必要なときにその時点へ戻したり、複製して別の環境で使ったりできます。
仕組みのイメージ
初回は対象データを丸ごと記録しますが、以降は差分だけを保存することが多いです。イメージで説明すると、最初の写真は全体を写し、次回は前回から変わった部分だけを追加で撮影するような形です。これにより保存時間と容量を節約します。
主な用途
- データ復旧：障害時に元の状態へ戻す
- 複製：同じ構成の環境を素早く用意する
- 過去参照：ある時点のデータを検証・確認する
対象と注意点
代表的な対象はEBSのボリュームや、S3に格納するアーカイブイメージです。整合性（ファイルが中途半端にならないか）や保存ポリシー、コストを事前に決めておくと運用が楽になります。
スナップショットとバックアップの違い
概要
バックアップはデータ全体や重要なファイルを別の場所にコピーして保存する手法です。スナップショットは「ある時点の状態」を効率的に保存する仕組みで、多くの場合は差分（変更分）だけを記録します。どちらも復元に使えますが目的や特性が異なります。
主な違い（分かりやすい例）
- 作成時間と容量
- バックアップ：フルコピーは時間と容量を多く使います。例）サーバー丸ごと夜間にフルバックアップ。
-
スナップショット：初回は大きめですが、以降は差分のみ保存するため短時間で済み容量も抑えられます。例）システム更新前に瞬時にスナップショットを作る。
-
復元と粒度
- バックアップ：ファイル単位やアプリ単位で細かく復元できます。個別ファイルを戻したい場合に便利です。
-
スナップショット：特定時点のボリューム全体を素早く戻せます。テスト環境の復元やロールバックに向きます。
-
一貫性と整合性
- バックアップ：アプリケーションの停止や専用ツールで整合性を保つことが多いです。
- スナップショット：ストレージレベルで高速に取得しますが、アプリの状態によっては一貫性確保のための工夫が必要です（例：トランザクション中のデータ）。
コストと運用
スナップショットは保存効率が良く短期間の復元に適します。バックアップは長期保存やファイル単位の復元、監査用に向きます。運用では両者を組み合わせ、スナップショットで即時復旧、定期バックアップで長期保存といった戦略が一般的です。
実用的な使い分け例
- ソフトウェア更新前：スナップショットを取り、問題があればすぐ戻す。
- 月次の保管：フルバックアップを取って長期保存と監査対応。
注意点
スナップショットだけに頼ると長期的な保管やファイル単位の復旧で不便になることがあります。定期的に復元テストを行い、両方の仕組みを補完的に使うことをおすすめします。
スナップショットとAMIの違い
概要
スナップショットはEBSボリュームの中身（ブロックデータ）を保存するバックアップです。AMIはスナップショットに加え、インスタンスの起動設定やメタデータを含む起動テンプレートです。
含まれるもの
- スナップショット：ボリュームのデータのみ。差分方式で効率化されます。稼働中でも取得可能です。
- AMI：ルートボリュームのスナップショット＋起動時の設定（ブロックデバイス、ユーザーデータ、仮想ハードウェア情報など）。
主な違いと使い分け
- 用途：単純なデータ復元はスナップショット。インスタンスをまるごと複製して起動したいときはAMIを使います。
- 作成の影響：AMIは完全な再現性を求めるため停止して作ることが推奨されます。スナップショットは差分で高速です。
実例
- データベースの定期バックアップ：スナップショット（整合性確保のためアプリ側でフラッシュ）。
- 新しい環境を複製：AMIを作って複数台起動。
注意点
スナップショットはボリューム単位で復元しアタッチします。AMIはそのままEC2を起動できます。運用上は目的に応じて両者を組み合わせると効率的です。
スナップショット作成の仕組みと効率性
1) 仕組みの概要
AWSでは、ボリューム（例：EBS）のスナップショットを単一のAPI呼び出しで取得できます。呼び出すと、まずボリュームのメタデータと差分管理の準備を行い、その時点でのディスク内容を「クラッシュ整合性」の状態で記録します。インスタンスを停止したりファイルを手動で移動したりする必要は基本的にありません。
2) インクリメンタル方式と高速化の理由
初回スナップショットは実データのブロックを保存します。以降は「変更されたブロック」だけを保存するインクリメンタル方式を使います。これにより通信量と保存容量を節約し、作成処理も短時間で済みます。復元時は必要なブロックを組み合わせて元に戻します。
3) クラッシュ整合性とアプリ整合性
スナップショットはクラッシュ時の状態を再現します。ファイルシステムやプロセスがちょうど停止した状態を再現するイメージです。データベースなどでより厳密な整合性が必要な場合は、事前にフラッシュやトランザクションの停止（例：一時的なクエリ停止やfsync）を行うとアプリ整合性を確保できます。
4) 効率化の実践例
- 定期スナップショットは間隔を最適化して不要な重複を減らす。例：短時間で多数のスナップショットを撮らない。
- 重要な複数ボリュームは同時に取得するAPIを使い、一貫性を保つ。
- 復元時間を短くしたい場合は、必要なボリュームだけを復元して段階的に稼働させる。
これらにより、運用負担を減らしつつ迅速なバックアップと復元を実現できます。
OpenSearch Serverlessにおけるスナップショット機能
概要
Amazon OpenSearch Serverlessは、コレクションのデータ保護と業務継続性を確保するために、定期的にスナップショットを作成します。標準で毎時1回の自動スナップショットを保持し、運用での復旧を支援します。
AWS管理の自動スナップショット
AWS側が自動でスナップショットを作成・管理します。ユーザーは特別な操作をしなくても短時間で復旧できる状態を維持できます。スナップショットは増分方式で保存されるため、効率的に容量を使います。
Snapshot Management（ユーザー管理機能）
ユーザーはSnapshot Managementを使って日次スナップショットの取得や保持期間の設定、失敗時の通知などを細かく設定できます。たとえば業務時間外に毎日スナップショットを取得し、重要データを長期間保存する運用が可能です。
復元と運用上の注意点
復元は対象のコレクション単位で行い、別のコレクションへ復元して動作確認することを推奨します。アクセス権や保持期間、コスト影響を事前に確認してください。定期的に復元テストを実施して、実際の復旧手順を確認しておくと安心です。
S3へのスナップショットアーカイブ戦略
概要
30日以上保存するデータは、S3のGlacierやGlacier Deep Archiveにアーカイブすることでコストを下げられます。これらは長期保存向けで、即時取得に向きません。取得にはリクエストと時間が必要で、用途に応じて取得速度を選びます。
取得速度（Expedited / Standard / Bulk）
- Expedited：数分から数十分で取得。緊急復旧向けでコスト高。例：直近の障害で即時復旧する場合。
- Standard：数時間で取得。通常の復元作業向け。
- Bulk：低コストだが数時間～数十時間かかる。大量データの復元や非緊急の調査向け。
ライフサイクル戦略例
- スナップショット作成 → 30日経過でGlacierへ移行 → 365日経過でDeep Archiveへ移行、のように段階移行します。業務での復旧頻度に合わせて期間を調整してください。
実装上の注意点
- ライフサイクルルールで自動化し、タグでポリシーを分けます。暗号化とアクセス制御を必ず設定してください。
- 定期的に復元テストを行い、リトリーブ時間とコストを確認します。ログと費用アラートを設定すると安心です。
運用のコツ
- 頻繁にアクセスするスナップショットはアーカイブしない。アーカイブ前にメタデータ（スナップショットの説明、保持期限）を整備すると復元時に探しやすくなります。
- 法的保存やコンプライアンス要件がある場合は保持期間を明確にしておくことが重要です。
