November 2, 2022 . 1 MIN READ
Before scaling your database instance, ensure that the appropriate licensing is in place for commercial database engines such as SQL Server or Oracle. This is especially important when using a Bring Your Own License (BYOL) model. With commercial database engines, scaling options may be limited by licensing terms, which are often based on the number of CPU cores or sockets used.
When performing a scaling operation, you must decide when the change should take effect. AWS provides two options: you can apply the change immediately or schedule it during the maintenance window configured for the DB instance.
It is also important to note that storage and instance type are independent of each other. Scaling the database instance up or down does not change the allocated storage size. If you need additional storage capacity or improved storage performance, you must modify the storage settings separately. For example, you can increase the allocated storage or switch to a different storage type such as General Purpose SSD or Provisioned IOPS SSD.
Downtime during scaling depends on the database deployment configuration. In a Multi-AZ environment, scaling typically results in minimal downtime because AWS upgrades the standby instance first and then performs a failover to the newly scaled instance. However, if the database runs in a Single-AZ configuration, the instance will be temporarily unavailable during the scaling process.
For more details, see the AWS blog on scaling Amazon RDS instances vertically and horizontally.
Reference:
https://repost.aws/questions/QUwczwWSybSQuqvwKiqOlW4w/best-practices-when-upgrading-rds-instance-generations
