As the hosting operator, use an approved package or option change to resize an RDS-backed PD AWS MySQL database. The module does not perform an in-place Lightsail database resize.

Review the intended change

Identify the service’s current backing, region, plan, storage and engine version. Check that the intended RDS class is supported for that engine and region, and review the associated billing change.

Arrange a suitable application window and verify a usable recovery copy. The module attempts a pre-change snapshot and can continue with the change if that attempt fails.

Apply through the billing workflow

1. Review the target package or customer option values.
2. Process the supported upgrade or plan change through Blesta.
3. Inspect PD AWS MySQL → Activity for the requested change and queue result.
4. Follow the actual database status until AWS finishes applying it.
5. Compare the provider result, recorded service and intended billing configuration.
6. Test the application after the change.

A queued change or updated plan label alone is not proof the database already uses the new class. Some supported changes can be combined, while others are refused; inspect the reported applied and not-applied results.

Respect the change boundaries

The module does not reduce allocated storage or change an existing database’s engine version here. Editing a package’s region or backing does not migrate it. A Lightsail size change needs a separate new-resource migration process, rather than this in-place workflow.

Use storage growth for that dimension. If the module and billing record show a requested change but AWS has not finished it, compare the existing Activity operation with the database’s current and pending state in your own AWS account before requesting another change.

See the PD AWS MySQL Blesta guide for related tasks, or explore PD AWS MySQL.