Skip to main content

Use Case for AWS RDS DB Instances should automatically create backups

  1. Configure AWS RDS DB Instances should automatically create backups
  2. Use Case for AWS RDS DB Instances should automatically create backups
  3. Triage Guides by Violation Type
    1. Triage AWS RDS DB Instances should automatically create backups AUTO_BACKUP_NOT_ENABLED

When should I use AWS RDS DBInstance Auto-Backup?​

Pros​

  1. Simplified management and configuration: RDS auto-backup streamlines backup management for small infrastructure environments and offers a lower learning curve with direct configuration on the resource.
  2. Minimal performance impact: For MariaDB, MySQL, Oracle, and PostgreSQL, I/O activity isn't suspended on your primary during backup for Multi-AZ deployments. For SQL Server, I/O activity is suspended briefly during backup for both Single-AZ and Multi-AZ deployments. (Backup window)
  3. Cost-effective backup storage: There is no additional charge for backup storage up to 100% of your total database storage for a region, as well as no additional charge for transaction logs or instance metadata. Most databases require less raw storage for a backup than for the primary dataset, meaning that most customers will not pay for backup storage.
  4. Full daily snapshots and point-in-time recovery: Automated backup performs a full daily snapshot of your data during your preferred backup window and captures transaction logs, allowing point-in-time recovery to any point during the backup retention period. (Working with backups)

Cons​

  1. Not ideal for complex infrastructure: RDS auto-backup's limited scalability and lack of centralization make it less suitable for complex infrastructure setups. AWS Backup provides a more comprehensive and centralized solution, ideal for managing backups across various AWS resources. (Using AWS Backup to manage automated backups)
  2. Maximum backup retention: RDS auto-backup has a maximum retention period of 35 days, which may be insufficient for some use cases requiring longer-term storage of backups.
  3. Brief I/O suspension during backup initialization: During the automatic backup window, a Single-AZ DB instance results in a brief I/O suspension that can last from a few seconds to a few minutes, depending on the size and class of your DB instance. For MariaDB, MySQL, Oracle, and PostgreSQL, I/O activity is not suspended on your primary during backup for Multi-AZ deployments, because the backup is taken from the standby. For SQL Server, I/O activity is suspended briefly during backup for Multi-AZ deployments. (Backup window, Creating a DB snapshot)
  4. Backup storage costs over 100% limit: Although automated backups are cost-effective, you are charged for additional backup storage if the total size of manual snapshots and system snapshots associated with retained automated backups exceeds 100% of the allocated storage of running instances in a region (Retention costs).
  5. Storage engine limitations: For MySQL DB engine and MariaDB DB engine, automated backups are only supported with the InnoDB storage engine. Using automated backups with other storage engines, such as MyISAM (Automated backups with unsupported MySQL storage engines) or Aria (Automated backups with unsupported MariaDB storage engines) respectively, may result in inconsistent behavior during the restoration process from backups.
  6. Outage when enabling or disabling auto-backups: Enabling or disabling auto-backups can cause an outage, impacting the availability of the database. (Backup retention period)