Is there downtime for aurora serverless 2 capacity change

Hi,

According to this, changing capacity will not reboot your database and will be applied immediately.

Note: When you modify the capacity range for an Aurora Serverless v2 DB cluster, the change takes place immediately, regardless of whether you choose to apply it immediately or during the next scheduled maintenance window.

But, some parameters calculating based on the capacity and will be recalculated only during reboot (which you will need initiate separately).

Aurora automatically sets certain parameters for Aurora Serverless v2 DB instances to values that depend on the maximum ACU value in the capacity range. For the list of such parameters, see Maximum connections for Aurora Serverless v2. For static parameters that rely on this type of calculation, the value is evaluated again when you reboot the DB instance. Thus, you can update the value of such parameters by rebooting the DB instance after changing the capacity range. To check whether you need to reboot your DB instance to pick up such parameter changes, check the ParameterApplyStatus attribute of the DB instance. A value of pending-reboot indicates that rebooting will apply changes to some parameter values.

The change applies to all* the Serverless v2 instances in the cluster immediately. There's no downtime, as already stated. Connections stay connected, transactions and queries continue to run. For example, you could have a long-running query and the buffer cache could grow or shrink while the query continued to run.

• Although all the Serverless v2 instances scale within the same min/max values, the scaling that happens for each instance also depends on the priority tier for the instance. Instances in priority tier 0 or 1 keep their ACUs at least as high as the writer instance, so they're ready to assume the writer role in case of a failover. Instances in other priority tiers can scale independently, so they could be used for specialized purposes such as running reports or ad hoc testing.