As the hosting operator, help your customer identify an address that no longer needs access to their RDS-backed MySQL service. The client-area removal steps below can interrupt dependent applications, so confirm the intended rule and remaining access first.

Identify the intended rule

Open the service’s Firewall page and compare the address, CIDR and description with the application or location being retired. Keep a record of the intended rule privately so the administrator can review a mistake, without including database passwords.

This module controls the service’s MySQL-port IPv4 rules. It does not offer the same page for Lightsail databases or manage arbitrary host-added ports.

Customer steps: remove and verify

1. Check the intended service and current allowed list.
2. Choose the remove control for the address being retired.
3. Read the confirmation and submit once.
4. Follow the request in Activity.
5. Reload the list and confirm the intended address is gone while other required rules remain.
6. Verify that the applications expected to retain access still connect.

A pending request is not proof that AWS has already changed the group. A failed response also does not establish that the previous list was restored; inspect the actual result before another edit.

Keep connectivity diagnosis separate

If an application loses access unexpectedly, compare its actual source address, the current saved list, database state and routing before changing credentials. Use the allow-address guide when a deliberate replacement rule is required.

As the hosting operator, compare the original Activity result and the module’s current list with the database’s actual AWS rules before another edit. A request that is still pending, a failed write and a completed removal followed by application access loss need different checks.

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