Fix: The instance could not be created because storage is full (RDS)

When an RDS instance exhausts its allocated storage, writes start failing and the instance status moves to STORAGE_FULL. Depending on the engine you may also be unable to connect, and pending maintenance or restore operations fail with storage errors. This is a real production stopper: the database will not accept new data until space is added or reclaimed, and the fastest safe move is almost always to increase allocated storage first and investigate second.

The instance could not be created because storage is full (RDS)

What this error means

RDS allocates a fixed block of storage per instance. When free space reaches zero, the engine cannot extend data files, write ahead logs or binary logs cannot grow, and temporary space for queries disappears. RDS marks the instance STORAGE_FULL and blocks operations that need space. Because MySQL can crash uncleanly on a full disk, RDS may also prevent connections to protect the instance. The condition does not resolve itself: something filled the disk, and either the allocation grows or the space gets reclaimed.

Common causes

• Organic data growth that outpaced the original allocation, with no FreeStorageSpace alarm to warn anyone.
• Binary logs or write ahead logs accumulating because a replica is broken or a replication slot is abandoned, which pins log retention indefinitely.
• A runaway query or ETL job filling temporary storage with huge sorts, hash joins, or temp tables.
• Bloat: PostgreSQL dead tuples that vacuum never reclaimed, or InnoDB tablespaces full of internal free space after mass deletes.
• Long running transactions preventing vacuum or purge from cleaning up old row versions.
• Local backups, oversized general or slow query logs, or audit logging written to the instance volume.

How to fix it

STABILIZE first. Increase allocated storage now. It applies while the instance stays available and it is the one action that reliably gets writes working again. Remember the six hour cooldown between storage modifications, so add enough in one move.

1. Confirm the state and current allocation:

aws rds describe-db-instances \
  --db-instance-identifier prod-db \
  --query 'DBInstances[0].{Status:DBInstanceStatus,AllocatedGB:AllocatedStorage,MaxGB:MaxAllocatedStorage}'

2. FIX immediately by growing storage (and enable autoscaling with a max threshold in the same call):

aws rds modify-db-instance \
  --db-instance-identifier prod-db \
  --allocated-storage 500 \
  --max-allocated-storage 1000 \
  --apply-immediately

3. DIAGNOSE what consumed the space. Check the FreeStorageSpace trend to see whether this was a slow climb or a sudden spike:

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name FreeStorageSpace \
  --dimensions Name=DBInstanceIdentifier,Value=prod-db \
  --start-time 2026-07-06T00:00:00Z --end-time 2026-07-13T00:00:00Z \
  --period 3600 --statistics Minimum

4. Then look inside the engine. On PostgreSQL, find the biggest relations and check for abandoned replication slots, which pin WAL forever:

SELECT relname, pg_size_pretty(pg_total_relation_size(oid))
FROM pg_class ORDER BY pg_total_relation_size(oid) DESC LIMIT 10;

SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
FROM pg_replication_slots;

On MySQL, check binary log volume and shrink retention if logs are the culprit:

SHOW BINARY LOGS;
CALL mysql.rds_set_configuration('binlog retention hours', 24);

5. Reclaim what you can: drop an abandoned replication slot, run VACUUM (or schedule a VACUUM FULL or pg_repack for bloated tables during a window), run OPTIMIZE TABLE on InnoDB tables after mass deletes, and archive or drop tables nobody reads.

How to prevent it

• Enable storage autoscaling with a maximum threshold on every production instance.
• Alarm on FreeStorageSpace at 20 percent and again at 10 percent, routed to a human.
• Monitor replication slot lag and broken replicas, since abandoned slots are the classic silent disk filler on PostgreSQL.
• Keep binary log retention as short as your replicas and CDC tooling actually need.
• Review table bloat and run reclamation (vacuum tuning, pg_repack, OPTIMIZE TABLE) as routine maintenance, not as incident response.

When to call a senior engineer

Call for help when the instance is in STORAGE_FULL and a storage modification is stuck or blocked by the cooldown, when WAL or binlog growth keeps returning and nobody can say why, or when reclaiming space needs table rewrites on a database that cannot take a maintenance window. Erzon engineers can get writes flowing again safely, identify the exact consumer of the space, and set up the autoscaling, retention, and alerting that keeps a full disk from ever being a surprise again.