Auroraのクローンは数分で本番相当のデータを持つ検証環境を用意できます。ところが実務では、コンソールの「クローンの作成」が選択できない、CLIがInvalidDBClusterStateFaultを返す、作成できたのに接続できない、翌月のストレージ課金が増える、といった形で止まります。症状が分かれて見えるのは、クローンが「作成条件と権限の審査」と「コピーオンライトで共有ストレージを参照する仕組み」という別々の性質を持つためです。
この記事は要約版です。代表的なエラーメッセージと原因別の対処表、IAMとKMSの権限不足を見分ける確認コマンド、課金内訳の調べ方は、ブログの完全版にまとめています: Aurora クローン作成エラーの原因と対処法
結論
作成そのものが失敗する場合、原因はほぼ2系統です。1つは作成条件の不足で、同一リージョンでない、クラスターのステータスがavailableでない、クローン数の上限に達している、エンジンモードや構成が対象外、パラメータグループのファミリー不一致などが該当します。もう1つは権限の不足です。rds:RestoreDBClusterToPointInTimeやrds:CreateDBInstanceが許可されていないか、暗号化クラスターのKMSキーに対するkms:CreateGrant／kms:DescribeKeyがありません。アクセス拒否のメッセージを読めばIAM側かKMS側かを区別できます。
一方で「作れたのに接続できない」「初回だけ遅い」「課金が増えた」は、作成失敗とは原因が異なります。クローンが共有するのはストレージ上のデータだけで、セキュリティグループやパラメータグループ、リーダーインスタンスは引き継ぎません。遅さについては、新規インスタンスのバッファキャッシュが空であること、クローン上で初めて更新するページに追加のページ割り当てが伴うことが主な要因です。課金も同じ理屈で、共有ページ分は二重に課金されず、新しく書かれた差分ページとI/Oリクエストが増えた分が請求に乗ります。
なおAuroraのクローンは、APIレベルではRestoreDBClusterToPointInTimeの--restore-type copy-on-writeです。この対応関係を知っておくと、エラーメッセージの読み方とドキュメントの探し方が楽になります。
まず実行する確認コマンド
エラー文を読む前に、ソースクラスターの状態をまとめて確認してください。ステータス、暗号化とKMSキー、CloneGroupId、EarliestRestorableTimeが一度に取れるため、手戻りが減ります。
aws rds describe-db-clusters \
--db-cluster-identifier prod-aurora-cluster \
--query 'DBClusters[0].{Status:Status,Engine:Engine,Version:EngineVersion,
Encrypted:StorageEncrypted,KmsKeyId:KmsKeyId,StorageType:StorageType,
CloneGroupId:CloneGroupId,EarliestRestorableTime:EarliestRestorableTime}'
完全版で扱っている内容
- エラーメッセージから原因を切り分ける対応表。
InvalidDBClusterStateFault、InvalidParameterCombination、DBClusterQuotaExceededFault、StorageQuotaExceededFault、DBSubnetGroupDoesNotCoverEnoughAZs、KMSKeyNotAccessibleFaultなどを原因と対処の組で整理 - IAMポリシーとKMSキーの権限不足を見分ける手順。必要アクションを並べた最小ポリシー例、
kms describe-key／get-key-policyでの確認、CloudTrailのerrorCode／errorMessageを引く方法 - クローンが引き継がない設定の一覧と、ソースとクローンの差分を並べて比較するシェルスクリプト
- 初回アクセスだけ遅い理由の内訳。キャッシュヒット率を追う統計値、書き込み時のページ複製が増える操作、RDS（非Aurora）のスナップショット復元で起きる遅延ロードとの違い
- ストレージ課金とI/O課金が増える具体的な操作、
VolumeBytesUsedとCost Explorerの使い分け、クローン数上限やクロスアカウント共有のFAQ、放置を防ぐ運用ルール4点