Skip to content

AWS Updated 2026-07-04

Restoring an RDS snapshot correctly: the new-instance surprise and what does not come back

Restoring an RDS snapshot always creates a new instance — and parameter groups, security groups, and option groups do not follow it. The restore runbook that avoids the classic surprises.

You cannot restore an RDS snapshot onto an existing instance. A restore always creates a brand-new instance with a new endpoint — and unless you say otherwise, that new instance comes up with the default parameter group and the default VPC security group, not the ones your production instance uses. Most “the restore worked but the app is broken” incidents are exactly this: the data came back fine, the configuration around it did not.

What’s happening

An RDS snapshot is a storage-level copy of the database volume plus a small amount of metadata: engine, version, storage type, and which option group applies. It is not a copy of the instance’s full configuration. When you run a restore, RDS builds a fresh instance from that volume and asks you (or applies defaults) for everything else:

  • Parameter group — if you do not pass one, the new instance gets the default parameter group for the engine family. Your tuned max_connections, shared_buffers, or innodb_buffer_pool_size settings vanish, which is why the restored instance often “feels slower” or refuses connections under load.
  • Security groups — the restored instance attaches to the default security group of the target VPC unless you specify yours. Default SGs usually allow nothing inbound from your app subnets, so the application simply cannot connect.
  • Subnet group and VPC — you choose at restore time; restoring into the wrong subnet group puts the database somewhere your app cannot reach.
  • Endpoint — the new instance gets a new DNS name. Nothing you restore will answer at the old hostname until you make it so.
  • Option groups — for Oracle and SQL Server, options like native backup/restore or TDE live in the option group and must be compatible; a mismatch blocks the restore.

Encryption follows the snapshot: an encrypted snapshot restores to an encrypted instance using the same KMS key by default, and if that key is a customer-managed key in another account, the key policy has to allow you — the sharp edges there are covered in RDS encryption with customer-managed KMS keys. What a snapshot restore also cannot do is give you a point between snapshots; for that you want point-in-time restore. The full restore option matrix is in the RDS docs at https://docs.aws.amazon.com/rds/.

What to check first

  • Which snapshot, exactly — automated vs manual, its create time, and whether that timestamp actually covers what you are trying to get back.
  • The production instance’s parameter group, security groups, and subnet group — you will need their names for the restore command.
  • The KMS key — encrypted snapshot? Confirm you can use the key, especially cross-account or cross-region.
  • Instance class and storage headroom — restoring to a smaller class than the workload needs makes the “test” invalid.
  • Who consumes the endpoint — app config, connection strings in Secrets Manager, anything hardcoded.

How to verify

List candidate snapshots and their metadata:

aws rds describe-db-snapshots \
  --db-instance-identifier prod-db \
  --query 'DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime,SnapshotType,Encrypted,Status]' \
  --output table

Capture the production configuration you need to re-attach:

aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[DBParameterGroups[0].DBParameterGroupName,VpcSecurityGroups[].VpcSecurityGroupId,DBSubnetGroup.DBSubnetGroupName,DBInstanceClass]'

After a restore, the console shows the gap plainly: RDS > Databases > (restored instance) > Configuration lists the parameter group and security groups actually attached — compare against production before declaring victory.

The runbook

  1. Restore with the configuration stated explicitly. Do not rely on defaults:

    aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier prod-db-restored \
  --db-snapshot-identifier rds:prod-db-2026-07-03-06-08 \
  --db-instance-class db.r6g.xlarge \
  --db-subnet-group-name prod-db-subnets \
  --vpc-security-group-ids sg-0abc123def456 \
  --db-parameter-group-name prod-pg16-params \
  --no-publicly-accessible

  2. Wait for available, then reboot if parameters require it. Static parameters applied at restore need a reboot to take effect; check Configuration for “pending-reboot”.

  3. Validate the data before touching traffic. Connect from a bastion or app host, verify the tables and the latest timestamps you expected the snapshot to contain.

  4. Cut applications over deliberately. Two clean options: update the connection string (Secrets Manager or config) to the new endpoint, or do the rename dance — rename the old instance out of the way, then rename the restored one to the old identifier so the endpoint hostname is regenerated to match. The rename approach keeps app config untouched but involves a brief window where the name resolves to nothing; drain traffic first.

  5. Re-point backups, monitoring, and alarms. CloudWatch alarms, Performance Insights, and backup plans reference the instance identifier — a renamed or new instance is invisible to all of them until you re-attach.

  6. Decommission the old instance on a schedule, not immediately. Keep it stopped or snapshot it, give it a deletion date, and take a final snapshot when that date arrives.

When this is the wrong move

If you need the state from 14:32 yesterday and your snapshots run nightly, a snapshot restore hands you the wrong data — use point-in-time restore instead, which replays transaction logs to the second. If only one table was damaged, restoring the whole instance and copying that table across is still the mechanism, but consider whether a logical export of that table from the restored copy is faster than a full cutover. And a snapshot restore is not a cloning strategy for Aurora — Aurora fast clones do that in minutes without duplicating storage.

Common mistakes

  • Restoring with defaults and spending an hour debugging “connection refused” that is just the default security group doing its job.
  • Forgetting the parameter group, then attributing the restored instance’s poor performance to “snapshot corruption” that does not exist.
  • Deleting the original instance immediately after cutover, before anyone has confirmed the restored data is actually complete.
  • Testing restores into public subnets with --publicly-accessible left on, exposing a copy of production data to the internet.

Prevention

  • Script the restore with all flags explicit, store it in the repo, and drill it quarterly — a restore you have never rehearsed is a theory, not a capability.
  • Tag snapshots and enable CopyTagsToSnapshot so restored instances inherit ownership and environment tags.
  • Keep parameter groups, security groups, and subnet groups in infrastructure-as-code so their names are documented and stable.
  • Record the app-side cutover procedure (secret update or rename) next to the restore script; the database half is only half the restore.

A snapshot restore done right is boring: explicit configuration in, validation, deliberate cutover, scheduled cleanup. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.