AWS RDSで「DBInstanceNotFound」エラーが発生した場合、まず確認すべきこととして最も適切なものはどれか？

解説

正解と要点正解は「DBインスタンス識別子とリージョンを確認する」です。このエラーは「そんなインスタンス存在しないよ」とAWSが言っているだけなので、まず疑うべきは名前の打ち間違いか、リージョンの向き先です。なぜその答えなのかセキュリティグループのポート開放 — これは接続タイムアウトの話です。そもそもインスタンスが見つからないのにポートを開けても意味がありません。パラメータグループの再適用 — パラメータグループはDB設定のチューニングに使うもので、インスタンスの存在確認とは無関係です。IAMにRDSフルアクセスを付与 — 権限不足ならAccessDeniedが返ります。DBInstanceNotFoundとは別のエラーです。ちなみにフルアクセスを安易に付与するのはセキュリティ上やめましょう。背景・仕組みRDSインスタンスはリージョンスコープのリソースです。つまり東京リージョン（ap-northeast-1）に作ったインスタンスを、バージニア（us-east-1）に向けたCLIやSDKから探しても当然見つかりません。これが実務で最もありがちな原因です。確認はCLIなら以下のように行えます。aws rds describe-db-instances \ --db-instance-identifier my-db \ --region ap-northeast-1ここで注意したいのは、識別子自体は大文字・小文字を区別しない点です。MyDBもmydbも同じインスタンスを指します。一方で、ハイフンとアンダースコアの取り違え（my-db vs my_db）はよくあるミスです。もう一つ厄介なのが「さっきまであったのに消えた」パターンです。誰かがインスタンスを削除済みの場合、自動バックアップの保持期間内ならポイントインタイムリストアで復旧できます。スナップショットが残っていればrestore-db-instance-from-db-snapshotで別名インスタンスとして復元可能です。実務での活用例IaCとの食い違いに注意 — TerraformやCloudFormationでリージョンをハードコードしていると、環境ごとに向き先がずれてこのエラーが出ることがあります。環境変数やパラメータストアでリージョンを一元管理するのが安全です。CI/CDパイプラインでの頻発 — デプロイスクリプトが本番とステージングでリージョンを切り替え忘れるケースも多いです。パイプラインの冒頭でaws sts get-caller-identityとaws configure get regionを出力しておくと、トラブルシュートが格段に楽になります。削除保護の有効化 — 意図しない削除でこのエラーに悩まされないよう、本番インスタンスにはDeletionProtection: trueを設定しておくのが鉄板です。