RDSスナップショットからの復元：既存インスタンスは上書きされるのか、新しいエンドポイントが作成されるのか

本番環境でデータ破損が発生し、RDSスナップショットから急いで復元しようとしたとき、多くのエンジニアが同じ疑問にぶつかる。「既存のインスタンスが上書きされるのか、それとも別のエンドポイントを持つ新しいインスタンスが作られるのか」——この挙動を誤解したまま復元操作を実行すると、アプリケーションの接続先が変わらず、復元したはずのデータに誰もアクセスできないという状況が生まれる。RDSスナップショット復元の動作原理を正確に理解しておくことは、障害対応の成否を左右する。

TL;DR：RDSスナップショット復元の要点

項目挙動
既存インスタンスの上書き行われない。常に新しいインスタンスが作成される
エンドポイント新しいインスタンス固有のエンドポイントが割り当てられる
元のインスタンス復元操作後も変更されずそのまま稼働し続ける
パラメータグループ / セキュリティグループデフォルト設定が適用される。元の設定は引き継がれない
アプリケーション切り替えエンドポイントの手動変更またはRoute 53 CNAMEの更新が必要
マルチAZ / リードレプリカ復元時に再設定が必要。スナップショットには含まれない

RDSスナップショット復元の仕組み

RDSのスナップショット復元は、既存インスタンスへの変更操作ではなく、スナップショットを元にした新規インスタンスのプロビジョニングとして実装されている。これはAWSの設計上の意図であり、復元操作が元のデータを誤って破壊するリスクを排除するための安全機構でもある。

スナップショット自体はS3上に保存されたストレージボリュームのポイントインタイムコピーであり、インスタンスの設定情報（パラメータグループ、セキュリティグループ、マルチAZ設定など）は含まれない。復元時にAWSは新しいDBインスタンス識別子を要求し、そのIDに基づいた新しいエンドポイントを生成する。

graph TD A["稼働中のRDSインスタンス
prod-db"] -->|"スナップショット取得"| B["DBスナップショット
rds:prod-db-2024-01-15"] B -->|"restore-db-instance-from-db-snapshot"| C["新しいRDSインスタンス
prod-db-restored"] C --> D["新しいエンドポイント
prod-db-restored.xxxx.rds.amazonaws.com"] A --> E["元のエンドポイント
prod-db.xxxx.rds.amazonaws.com"] E -->|"変更なし・引き続き稼働"| A F["アプリケーション"] -->|"復元前"| E F -->|"手動切り替えが必要"| D
  1. スナップショット取得：稼働中のRDSインスタンス（prod-db）のストレージボリュームがS3にコピーされる。
  2. 復元操作の実行：AWSは新しいDBインスタンス識別子（例：prod-db-restored）を使って新規インスタンスをプロビジョニングする。
  3. 新エンドポイントの生成：復元されたインスタンスには元のインスタンスとは異なるエンドポイントが割り当てられる。
  4. 元のインスタンスは無変更：prod-dbは復元操作の影響を受けず、引き続き稼働する。
  5. アプリケーション切り替え：接続先を新しいエンドポイントに向けるには手動での設定変更が必要。

スナップショットからの復元：実際のCLI手順

復元操作はAWS Management ConsoleまたはCLIで実行できる。CLIを使う場合、restore-db-instance-from-db-snapshotコマンドを使用する。最低限必要なパラメータは--db-instance-identifier（新しいインスタンスの名前）と--db-snapshot-identifier（復元元スナップショットのID）の2つだ。

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier prod-db-restored \
  --db-snapshot-identifier rds:prod-db-2024-01-15-00-00 \
  --db-instance-class db.t3.medium \
  --no-multi-az \
  --region us-east-1

復元が完了したら、新しいインスタンスのエンドポイントを確認する。

aws rds describe-db-instances \
  --db-instance-identifier prod-db-restored \
  --query 'DBInstances[0].Endpoint.Address' \
  --output text \
  --region us-east-1

このコマンドが返す文字列が新しいエンドポイントになる。元のprod-dbのエンドポイントとは異なる値が返ってくることを必ず確認すること。

スナップショット復元は「既存インスタンスの巻き戻し」ではなく「スナップショットを元にした新しいインスタンスの建設」だ。元の建物は取り壊されず、隣に新しい建物が建つイメージに近い。

復元後に必要な設定の再適用

スナップショットにはストレージの内容しか含まれていないため、復元後のインスタンスはデフォルト設定で起動する。本番環境と同等の動作をさせるには、以下の設定を手動で再適用する必要がある。

パラメータグループの適用

aws rds modify-db-instance \
  --db-instance-identifier prod-db-restored \
  --db-parameter-group-name your-custom-parameter-group \
  --apply-immediately \
  --region us-east-1

セキュリティグループの適用

aws rds modify-db-instance \
  --db-instance-identifier prod-db-restored \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --apply-immediately \
  --region us-east-1

パラメータグループの変更によっては再起動が必要になる場合がある。--apply-immediatelyを指定しても、静的パラメータの変更は次回の再起動まで反映されない点に注意が必要だ。

エンドポイント切り替えの戦略

復元後のインスタンスへアプリケーションを切り替える方法は主に2つある。どちらを選ぶかは、ダウンタイム許容度と既存インフラ構成によって決まる。

graph LR A["復元完了
新エンドポイント確認"] --> B{"接続切り替え方法"} B -->|"シンプルな構成"| C["環境変数 / Secrets Manager
エンドポイントを直接書き換え"] B -->|"DNS抽象化済み"| D["Route 53 CNAME更新
アプリ変更不要"] B -->|"RDS Proxy使用中"| E["Proxyターゲットグループ更新"] C --> F["アプリケーション再起動"] D --> G["TTL経過後に自動反映"] E --> H["Proxy設定変更を確認"]
  1. アプリケーション設定の直接変更：最もシンプルな方法。環境変数やSecretsManagerの値を新しいエンドポイントに書き換え、アプリケーションを再起動する。変更の反映には再デプロイが伴うため、計画的なメンテナンスウィンドウが必要。
  2. Route 53 CNAMEの更新：アプリケーションがカスタムDNS名（例：db.internal.example.com）を参照している場合、そのCNAMEレコードを新しいエンドポイントに向け直すことで、アプリケーション側の変更なしに切り替えが可能。ただしTTLの設定によっては切り替えに時間がかかる。
  3. RDS Proxy経由の接続：RDS Proxyを使用している場合、Proxyのターゲットグループを更新することで切り替えを行う。ただしRDS Proxyの設定変更は別途確認が必要。

よくある誤解と実際の障害パターン

本番障害の対応中に「スナップショットから復元したのにデータが変わっていない」という報告を受けることがある。調査すると、復元は正常に完了しているが、アプリケーションは依然として元のインスタンスのエンドポイントに接続し続けていた——というケースが繰り返し発生する。

誤った前提：「restore操作を実行すれば、既存インスタンスが自動的にスナップショット時点の状態に戻る」
実際の挙動：新しいインスタンスが作成されるだけで、アプリケーションの接続先は変わらない。

この誤解が生まれる背景には、他のサービス（例えばEC2のAMIからの起動など）との混同がある。EC2でも既存インスタンスの上書きは行われないが、RDSの場合はエンドポイントという「見えない変更点」が存在するため、問題が表面化しにくい。

復元完了後の確認として、必ず以下を実行すること。

# 元のインスタンスと復元後インスタンスのエンドポイントを並べて確認
aws rds describe-db-instances \
  --query 'DBInstances[*].[DBInstanceIdentifier,Endpoint.Address,DBInstanceStatus]' \
  --output table \
  --region us-east-1

このコマンドで2つのインスタンスがavailable状態で並んでいることを確認できれば、復元は成功している。あとはアプリケーションがどちらのエンドポイントを向いているかを確認するだけだ。

復元後の元インスタンスの扱い

復元が完了し、新しいインスタンスへの切り替えが確認できたら、元のインスタンスをどうするかを決める必要がある。不要であれば削除できるが、削除前に最終スナップショットを取得しておくことを強く推奨する。

aws rds delete-db-instance \
  --db-instance-identifier prod-db \
  --final-db-snapshot-identifier prod-db-final-before-delete \
  --region us-east-1

--skip-final-snapshotを指定しない限り、削除時に最終スナップショットが自動的に作成される。障害対応の混乱の中で元のインスタンスを誤って削除してしまうリスクを考えると、このデフォルト動作は安全側に倒れた設計だ。

RDSスナップショット復元に関するまとめと次のステップ

RDSスナップショットからの復元は、既存インスタンスを上書きするのではなく、常に新しいインスタンスを作成する。新しいエンドポイントが生成されるため、アプリケーションの接続先を手動で切り替える必要がある。パラメータグループやセキュリティグループはデフォルト設定にリセットされるため、本番環境と同等の設定を再適用することも忘れてはならない。

次のステップとして、以下のドキュメントを参照することを推奨する。

障害対応の事前準備として、復元手順をRunbookに記載し、エンドポイント切り替えの方法（Route 53 CNAMEまたは環境変数）をチームで合意しておくことが、実際の障害時の対応速度を大きく左右する。

用語集

用語説明
DBスナップショットRDSインスタンスのストレージボリュームのポイントインタイムコピー。S3に保存される。
DBインスタンス識別子RDSインスタンスを一意に識別する名前。エンドポイントのホスト名の一部として使用される。
エンドポイントアプリケーションがRDSに接続するためのホスト名とポートの組み合わせ。インスタンスごとに固有。
パラメータグループDBエンジンの設定パラメータをまとめたグループ。スナップショットには含まれない。
ポイントインタイムリカバリ（PITR）自動バックアップとトランザクションログを使い、特定の時刻の状態に復元する機能。スナップショット復元とは異なる仕組み。

コメント

コメントを投稿

このブログの人気の投稿

EC2 SSH接続タイムアウトの原因と修正方法 — セキュリティグループのインバウンドルール完全ガイド

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...
続きを読む

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...
続きを読む

EC2インスタンスIDをメタデータから取得する方法 — IMDSv2が安全な理由

サーバー上で動作するスクリプトから自分のインスタンスIDを取得したい場面は多い。デプロイスクリプト、ログ集約、Auto Scalingグループのインベントリ管理など、用途は様々だ。ただし、EC2インスタンスメタデータサービス（IMDS）には2つのバージョンが存在し、 IMDSv1とIMDSv2の選択はセキュリティ上の重大な差異 を生む。本番環境でIMDSv1を使い続けることは、SSRF（Server-Side Request Forgery）攻撃の踏み台になるリスクを放置することと同義だ。 TL;DR — IMDSv1 vs IMDSv2 早見表 観点 IMDSv1 IMDSv2 認証方式 なし（直接GETのみ） セッショントークン必須（PUT → GET） SSRF耐性 なし あり（PUT不可なSSRFはトークン取得不可） TTL制御 なし X-aws-ec2-metadata-token-ttl-secondsで指定 デフォルト状態 新規インスタンスでも有効（設定次第） IMDSv2-onlyに変更可能 推奨度 非推奨 AWS公式推奨 IMDSの仕組み — なぜインスタンス内からだけ到達できるのか EC2インスタンスメタデータサービスは、リンクローカルアドレス 169.254.169.254 で提供される。このアドレスはRFC 3927で定義されたリンクローカル範囲であり、インスタンスのネットワークインターフェース外には到達できない。つまり、インターネット経由や他のインスタンスから直接アクセスすることは原理的に不可能だ。 ただし、 SSRF脆弱性があるアプリケーションが動作している場合は話が変わる 。攻撃者がアプリケーションを経由して http://169.254.169.254/latest/meta-data/iam/security-credentials/ へリクエストを誘導できれば、インスタンスにアタッチされたIAMロールの一時クレデンシャルを盗める。IMDSv1はこのシナリオに対して無防備だ。 graph TD subgraph v1[...
続きを読む