AWSトラブル解決2026年10月30日

Aurora クローン作成エラーの原因と対処法

結論：クローン失敗の大半は「作成条件」と「権限」のどちらか
エラーメッセージから原因を切り分ける
クローンは作成できたのに接続できない・遅いとき
クローンのストレージ課金が想定より増える理由
よくある質問
再発防止：クローンを安全に使い回す運用ルール
さらに学ぶには

本記事にはプロモーション（広告）が含まれています。

Auroraのクローンは数分で本番相当のデータを持つ検証環境を作れます。ただし実際に使うと、コンソールの「クローンの作成」が選べない、CLIがInvalidDBClusterStateFaultを返す、作れたのに接続できない、翌月のストレージ課金が増える、といった形で詰まりがちです。

ここではエラーメッセージと確認コマンドから原因を切り分ける手順と、コピーオンライト構成が引き起こす「遅い」「課金が増える」の中身を整理します。

結論：クローン失敗の大半は「作成条件」と「権限」のどちらか

クローン作成の失敗は、ほぼ次の2系統に収まります。

作成条件を満たしていない。同一リージョンでない、クラスターのステータスがavailableでない、クローン数の上限に達している、エンジンモードやクラスター構成が対象外、パラメータグループのファミリーが合っていない
権限が足りない。rds:RestoreDBClusterToPointInTimeやrds:CreateDBInstanceが許可されていない、暗号化クラスターのKMSキーに対するkms:CreateGrant／kms:DescribeKeyがない

一方「作れたが接続できない」「遅い」「課金が増えた」は、クローンが引き継ぐ設定の範囲とコピーオンライトの挙動によるものです。前半で作成失敗、後半で作成後の事象を扱います。

なおAuroraのクローンは、APIレベルではRestoreDBClusterToPointInTimeの--restore-type copy-on-writeです。これを知っておくと、エラーメッセージの読み方とドキュメントの探し方が楽になります。

# クローン作成（クラスターのみ。インスタンスは別途作成が必要）
aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier prod-aurora-cluster \
  --db-cluster-identifier clone-test-01 \
  --restore-type copy-on-write \
  --use-latest-restorable-time \
  --db-subnet-group-name db-subnet-private \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-cluster-parameter-group-name aurora-pg-custom

エラーメッセージから原因を切り分ける

まず確認する前提条件（リージョン・アカウント・エンジン・クローン数・クラスター状態）

エラー文を読む前にソースクラスターの状態をまとめて確認すると、手戻りが減ります。

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}'

クローンはソースと同一リージョン内にしか作れません。別リージョンに持っていくならスナップショットのクロスリージョンコピーを使います。ステータスがavailable以外（modifying、upgrading、failing-overなど）だと作成要求が弾かれます。

クローンは最新の復元可能時刻を使うため、EarliestRestorableTimeが返らない場合やバックアップ保持期間が極端に短い場合は、まずバックアップ設定を見てください。Aurora Serverless v1やGlobal Database構成、プロビジョンドとサーバーレスの混在構成などは、クローン可否に制約が付く場合があります。コンソールのメニューが灰色のままなら、まずここを疑ってください。対応状況はバージョンで変わるので、利用中のエンジン・バージョンのユーザーガイドで確認します。

同一ソースから作れるクローン数には上限があり、クローンのクローンも数に含まれます。現在のクローン一族はCloneGroupIdで数えられます。

# 同じクローングループに属するクラスターを一覧化する
aws rds describe-db-clusters \
  --query 'DBClusters[?CloneGroupId!=`null`].[DBClusterIdentifier,CloneGroupId,Status]' \
  --output table

代表的なエラーメッセージと対処

エラー	主な原因	対処
`InvalidDBClusterStateFault`	ソースのステータスが `available` でない / クローン対象外の構成	`describe-db-clusters` でステータス確認。変更作業やフェイルオーバーの完了を待つ
`InvalidParameterCombination: Cannot specify RestoreToTime ...`	`--restore-type copy-on-write` と任意時刻指定の併用	クローンは `--use-latest-restorable-time` を使う。過去時点が必要なら通常の PITR（`full-copy`）に切り替える
`DBClusterQuotaExceededFault`	アカウント／リージョンの DB クラスター数上限	不要なクローンを削除、または Service Quotas から引き上げ申請
`StorageQuotaExceededFault`	アカウントの合計ストレージ上限	不要クラスター・スナップショットの整理、またはクォータ引き上げ
`DBClusterParameterGroupNotFound` / ファミリー不一致	指定したパラメータグループのファミリーがソースのエンジンバージョンと違う	`describe-db-cluster-parameter-groups` でファミリーを確認して合わせる
`DBSubnetGroupDoesNotCoverEnoughAZs`	サブネットグループの AZ 数が不足	複数 AZ を含むサブネットグループを指定
`KMSKeyNotAccessibleFault`	暗号化クラスターの KMS キーに権限がない／キーが無効	後述の KMS 確認手順へ
`InsufficientDBInstanceCapacity`	指定インスタンスクラスの在庫不足（クラスターではなくインスタンス作成時）	インスタンスクラスや AZ を変更して再試行

クローンのボリューム自体はコピーオンライトなので、データ量に比例して時間が伸びることはありません。作成に時間がかかると感じる場合、待たされているのはDBインスタンスのプロビジョニングです。進行状況はイベントで確認します。

aws rds describe-events \
  --source-identifier clone-test-01 --source-type db-cluster --duration 120

IAM ポリシーと KMS キーの権限不足を見分ける

アクセス拒否は2種類あり、メッセージで区別できます。User: arn:aws:sts::... is not authorized to perform: rds:RestoreDBClusterToPointInTimeならIAM側、KMSKeyNotAccessibleFault: Specified KMS key ... does not exist, is not enabled or you do not have permissions to access itならKMS側の不足です。

クローン一式を作るには、クラスター作成以外のアクションも必要です。最低限、次のあたりが揃っているか確認します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "rds:RestoreDBClusterToPointInTime",
        "rds:CreateDBInstance",
        "rds:DescribeDBClusters",
        "rds:DescribeDBInstances",
        "rds:AddTagsToResource"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": ["kms:DescribeKey", "kms:CreateGrant"],
      "Resource": "arn:aws:kms:ap-northeast-1:111122223333:key/xxxxxxxx-...",
      "Condition": {
        "Bool": { "kms:GrantIsForAWSResource": "true" }
      }
    }
  ]
}

KMS側は、キーポリシーに呼び出し元プリンシパルが含まれているか、キーがEnabledかを見ます。

aws kms describe-key --key-id <key-arn> --query 'KeyMetadata.{State:KeyState,Manager:KeyManager}'
aws kms get-key-policy --key-id <key-arn> --policy-name default --output text

暗号化されたソースのクローンは、原則としてソースと同じKMSキーで暗号化されます。クローン先で別キーに変えたいならスナップショットのコピーと復元が必要です。タグベースのアクセス制御（aws:RequestTag条件など）を入れている環境では、クローン作成時のタグ指定漏れで拒否されることもあります。拒否が出たらCloudTrailのerrorCode／errorMessageを見るのが最短です。

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RestoreDBClusterToPointInTime \
  --max-results 5 --query 'Events[].CloudTrailEvent' --output text

クローンは作成できたのに接続できない・遅いとき

セキュリティグループ・サブネットグループ・パラメータグループの引き継ぎを確認する

クローンが共有するのはストレージ上のデータだけで、クラスターの付帯設定をすべて引き継ぐわけではありません。CLIでパラメータを省略すると、VPCのデフォルトセキュリティグループやデフォルトのパラメータグループが割り当てられ、接続できない、設定値が本番と違う、といった状態になります。

作成後は差分を確認してください。

for c in prod-aurora-cluster clone-test-01; do
  echo "=== $c"
  aws rds describe-db-clusters --db-cluster-identifier "$c" \
    --query 'DBClusters[0].{SG:VpcSecurityGroups[].VpcSecurityGroupId,
              Subnet:DBSubnetGroup,CPG:DBClusterParameterGroup,
              Port:Port,Logs:EnabledCloudwatchLogsExports,IAMAuth:IAMDatabaseAuthenticationEnabled}'
done

引き継がれない、または指定が必要になりやすい代表例は次のとおりです。

セキュリティグループ（省略時はデフォルト SG）
DB サブネットグループ（別 VPC・別サブネットに置ける＝置き場所を間違えやすい）
クラスター／DB パラメータグループ（省略時はデフォルト）
CloudWatch Logs のエクスポート設定、拡張モニタリング、Performance Insights
IAM データベース認証、関連付けた IAM ロール（aws rds add-role-to-db-cluster が別途必要）
タグ（コスト配賦タグが付かないと、後述の課金調査で困ります）
リーダーインスタンス（クローンは自分で追加しないとリーダーエンドポイントが機能しません）

接続できない場合の切り分けは通常のRDSと同じで、セキュリティグループ、サブネットの経路、パブリックアクセス設定の順に見ます。手順はRDS 接続できない・タイムアウトの原因と切り分け手順にまとめてあります。

初回アクセスだけ遅いのはコピーオンライト構成が原因

クローン直後に本番と同じクエリが遅くなる原因は、大きく2つです。

1つはバッファキャッシュが空なこと。新規インスタンスなのでAurora MySQLのバッファプールやAurora PostgreSQLの共有バッファ、インスタンスローカルのキャッシュがすべてコールドです。本番では共有バッファにヒットしていたページがストレージノードからの読み取りになり、同一クエリでも応答時間が伸びます。pg_stat_databaseのblks_read／blks_hit、Aurora MySQLならInnodb_buffer_pool_read_requestsとInnodb_buffer_pool_readsの比で、キャッシュヒット率の立ち上がりを追えます。性能比較の前に、ウォームアップ用の読み取りを一巡させてください。

もう1つは書き込み時のページ複製です。クローンはソースと同じデータページを参照し、どちらかが書き込んだページだけを新しいページとして切り離します。そのため、クローン上で初めて更新するページには追加のページ割り当てが伴います。大量UPDATE/DELETE、VACUUM FULL、OPTIMIZE TABLE、インデックス再構築を初回に走らせると、定常状態より書き込みI/Oが増えます。

これはRDS（非Aurora）のスナップショット復元で起きるEBSの遅延ロードとは原因が異なります。Auroraクローンは共有ストレージをそのまま参照するため、ブロック単位のレストアを待つ必要はありません。混同すると「遅延ロードが終わるのを待つ」という無駄な待ちが発生します。非Auroraの復元後が遅い場合はRDSスナップショット復元後が遅い原因と対処｜遅延ロードが該当します。

クローンが本番と同じインスタンスクラスとは限らない点も見落としがちです。コスト削減で小さいクラスを選んだなら、遅いのは単にスペック差です。性能議論に入る前にdescribe-db-instancesでDBInstanceClassを比べてください。

クローンのストレージ課金が想定より増える理由

「クローンはストレージ課金がかからない」は不正確です。ソースと共有しているページ分は二重に課金されず、差分として新しく書かれたページ分が課金されます。したがって次の操作をすると差分が増え、課金も増えます。

クローン上での大量データ更新・削除、バッチの試験実行
VACUUM（特に VACUUM FULL）、pg_repack、OPTIMIZE TABLE によるページ書き換え
インデックスの作成・再構築、テーブル再編成を伴う DDL
マイナーバージョンアップグレードなど、内部的にページを書き換える操作
クローン側でのバックアップ保持（クローンにも独自のバックアップストレージとスナップショットの課金が発生します）

見落としやすいのがI/O課金です。Aurora Standard構成ではリクエストI/Oが従量課金なので、クローン上で重いバッチを流せばその分のI/O課金が乗ります。クローン検証でコストが増えたとき、原因がストレージ容量ではなくI/Oだったケースは少なくありません。I/Oの数え方と試算手順はAurora料金の見積もり方｜I/Oコストを実測で試算する手順を参照してください。

CloudWatchのVolumeBytesUsedはクローンでも値が返りますが、共有ページと差分ページの内訳までは分かりません。実際の請求内訳は、Cost Explorerでリソース単位・使用タイプ単位（ストレージ／I/O／バックアップ）に分解するのが確実です。クローンに専用のコスト配賦タグを付けておくと、この切り分けが楽になります。

# クラスター単位のボリューム使用量の推移を見る（内訳判定はCost Explorerで補う）
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name VolumeBytesUsed \
  --dimensions Name=DBClusterIdentifier,Value=clone-test-01 \
  --start-time 2026-10-01T00:00:00Z --end-time 2026-10-30T00:00:00Z \
  --period 86400 --statistics Maximum

この記事のテーマをさらに学べる本

IAMやRDS、バックアップ/リストアなどAWS運用の基本を体系的に解説しており、切り分けの土台になります。

AWS運用入門佐竹陽一/山崎翔平/小倉大/峯侑資

楽天ブックスで詳しく見る Yahoo!ショッピングで見る

よくある質問

Aurora クローンは別リージョンや別アカウントに作れる？

別リージョンには作れません。クローンはストレージボリュームを共有する仕組みなので、同一リージョン内に限られます。別リージョンに本番相当のデータが欲しいなら、スナップショットをクロスリージョンコピーして復元するか、Aurora Global Databaseを検討します。

別アカウントには作れます。AWS Resource Access Manager（RAM）でソースクラスターを共有先アカウントに共有し、共有先が自アカウント内にクローンを作ります。この場合も同一リージョン内です。暗号化クラスターならKMSキーも共有し、キーポリシーで相手アカウントにkms:DescribeKey／kms:CreateGrantを許可します。クロスアカウントクローンには「クローンのさらなる共有」などの制約が付くため、実施前に最新のユーザーガイドで可否を確認してください。組織のポリシーで禁止したい場合は、IAMの条件キーで拒否する運用も取れます。

ソースクラスターを削除してもクローンは残る？

残ります。クローンはソースから独立したクラスターとして動作し、ソースを削除してもデータは失われません。ただし削除後は、ソース側で計上されていた共有ページ分のストレージがクローン側に寄るため、クローンのストレージ課金が増えて見えることがあります。「ソースを消したのにコストが下がらない」という相談の多くはこれです。

コスト削減が目的なら、クローンも含めて不要なものを整理してください。クローンが残っている限り、そのデータ分のストレージは課金対象です。

クローンは何台まで作れる？クローンのクローンは作れる？

クローンのクローンは作れます。1つのソースから作成できるクローンの数には上限があり、クローンのクローンもその数に含まれます。上限値はサービス側で定義されているため、正確な数値はAuroraのユーザーガイドおよびService Quotasで確認してください。実務上は「CloneGroupIdが同じクラスターを数える」と考えれば把握できます。

上限に達していなくても、クローンの系譜が深くなるとページ共有関係が複雑になり、どのクラスターがどれだけの差分を持つのか追いにくくなります。検証用途なら「本番から1世代だけ」をルールにしておくと運用しやすくなります。

再発防止：クローンを安全に使い回す運用ルール

クローンを放置すると、誰が何のために作ったか分からないクラスターが課金され続けます。最低限、次の4つを決めておくと事故が減ります。

作成を手順化する。セキュリティグループ、サブネットグループ、パラメータグループ、タグを必ず明示指定するスクリプトやCloudFormation／Terraformに寄せる。CLIの引数省略がそのまま事故になります
命名とタグを強制する。clone-<用途>-<YYYYMMDD>のような命名と、Owner／Purpose／ExpireOnタグを必須化する。タグ必須化はIAMの条件キーで強制できます
寿命を決める。ExpireOnを過ぎたクローンを検出して通知・削除する仕組み（EventBridge Scheduler + Lambdaなど）を用意する。削除時は最終スナップショットの要否も手順に含めます
検証結果の前提を揃える。インスタンスクラス、パラメータ、キャッシュ状態が本番と違えば性能値はそのまま比較できません。ウォームアップ後の値を見るか、クラスを本番と揃えるかを明示的に決めます

作る前に「本当にクローンが最適か」も一度考えてください。過去時点のデータが必要なら通常のPITR、別リージョンならスナップショットコピー、読み取り負荷の分散ならリーダーインスタンスの追加が本来の手段です。クローンが向くのは、最新データを使い、同一リージョン・同一アカウント（またはRAM共有）で、短期間、破壊的な検証をしたいケースです。

さらに学ぶには

Auroraの挙動は「共有ストレージ＋コピーオンライト」「redoをストレージ層で処理する」という設計を押さえると理解が速くなります。接続断や性能劣化の切り分けを含めた運用全体の流れはRDS・Aurora運用トラブルの切り分け｜接続断と性能劣化から辿れます。

結論：クローン失敗の大半は「作成条件」と「権限」のどちらか

エラーメッセージから原因を切り分ける

まず確認する前提条件（リージョン・アカウント・エンジン・クローン数・クラスター状態）

代表的なエラーメッセージと対処

IAM ポリシーと KMS キーの権限不足を見分ける

クローンは作成できたのに接続できない・遅いとき

セキュリティグループ・サブネットグループ・パラメータグループの引き継ぎを確認する

初回アクセスだけ遅いのはコピーオンライト構成が原因

クローンのストレージ課金が想定より増える理由

よくある質問

Aurora クローンは別リージョンや別アカウントに作れる？

ソースクラスターを削除してもクローンは残る？

クローンは何台まで作れる？クローンのクローンは作れる？

再発防止：クローンを安全に使い回す運用ルール

さらに学ぶには

関連記事

新着記事