Aurora backup restore fails with snapshot not found error despite valid snapshot ID

Cloud Platforms Amazon Web Services (AWS)
, , , , , , , ,
1

We’re experiencing a critical issue with Aurora database restoration. When attempting to restore from an automated backup snapshot, we consistently receive a ‘snapshot not found’ error despite the snapshot being visible in the RDS console.

The error occurs during restore:


Error: DBSnapshotNotFound
Snapshot 'aurora-prod-snapshot-2025-03-14' not accessible
Status Code: 404

The snapshot shows as ‘available’ in the console and was created 18 hours ago. We’ve verified the snapshot ARN matches exactly. Our Aurora cluster uses KMS encryption with a custom CMK, and we’re restoring within the same region. IAM permissions appear correct as we can list and describe snapshots successfully.

This is blocking our disaster recovery testing. Has anyone encountered similar snapshot accessibility issues with encrypted Aurora clusters?

2

This is a common gotcha with cross-account or cross-role restores. Beyond kms:CreateGrant, you also need to ensure the snapshot is shared properly if you’re restoring to a different account or region. Even within the same account, the IAM principal needs explicit permissions. I’d recommend creating a dedicated restore role with all necessary KMS and RDS permissions rather than using admin credentials.

3

Update: I’ve updated the KMS key policy to include kms:CreateGrant but still getting the same error. I’m wondering if there’s a propagation delay or if I need to modify something else. The snapshot is definitely in the same account and region.

4

After reviewing similar cases, here’s the complete solution for Aurora snapshot restoration with KMS encryption:

Aurora Snapshot Permissions: First, ensure your IAM principal has the required RDS permissions:


rds:RestoreDBClusterFromSnapshot
rds:DescribeDBSnapshots
rds:DescribeDBClusters

KMS Encryption Keys: This is where most issues occur. Your KMS key policy must grant these permissions to the IAM principal performing the restore:

  • kms:Decrypt (to decrypt the snapshot)
  • kms:DescribeKey (to validate key access)
  • kms:CreateGrant (critical for Aurora to create grants during restore)
  • kms:RetireGrant (to clean up grants after restore)

Update your KMS key policy:

{
  "Sid": "AllowAuroraRestore",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::ACCOUNT:role/RestoreRole"},
  "Action": ["kms:Decrypt", "kms:DescribeKey", "kms:CreateGrant", "kms:RetireGrant"],
  "Resource": "*"
}

IAM Permissions: Your restore role needs an IAM policy allowing KMS operations:

{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:DescribeKey", "kms:CreateGrant"],
  "Resource": "arn:aws:kms:REGION:ACCOUNT:key/KEY-ID"
}

Common Pitfalls:

  1. Key Policy vs IAM Policy: Both must allow the operations. KMS key policy takes precedence, so even if your IAM policy allows kms:CreateGrant, the key policy must also permit it.

  2. Service Role Confusion: Aurora uses a service-linked role (AWSServiceRoleForRDS) for some operations. Ensure this role also has access to your CMK by adding it to the key policy.

  3. Snapshot Ownership: Verify the snapshot owner matches your account. Run:


aws rds describe-db-snapshots --db-snapshot-identifier aurora-prod-snapshot-2025-03-14

Check the “SnapshotOwner” field.

  1. Region-Specific Keys: If you copied the snapshot across regions, you need KMS permissions in both source and destination regions, as each region uses different CMKs.

Propagation Time: KMS key policy changes take effect immediately, but IAM policy changes can take up to 5 minutes. If you just updated policies, wait a few minutes and retry.

Testing Access: Before attempting restore, test your permissions:

aws kms decrypt --ciphertext-blob fileb://test.enc --key-id KEY-ID
aws rds describe-db-snapshots --include-shared

After implementing all three components (Aurora snapshot permissions, KMS key policy, and IAM permissions), your restore should succeed. The ‘snapshot not found’ error is misleading-it’s actually a permissions denial that RDS reports as a not-found error for security reasons.

5

I’ve seen this before with KMS-encrypted snapshots. The issue is usually related to KMS key permissions rather than snapshot permissions. Can you verify that the IAM role or user attempting the restore has kms:Decrypt and kms:DescribeKey permissions on the CMK used to encrypt the snapshot? Also check if the key policy allows the restore operation from your account.

6

We had identical symptoms last month. The root cause was that our KMS key had automatic rotation enabled, and the snapshot was encrypted with an older key version that wasn’t explicitly granted to our restore role. Make sure your key policy includes permissions for all key versions, not just the current one.

7

Good point Sarah. I checked the KMS key policy and found that while we have kms:Decrypt, we’re missing kms:CreateGrant permission which Aurora needs during restore operations. The key policy only grants this to the original cluster’s service role, not to our admin role attempting the restore.