AWS Non-Production Multi-AZ RDS Detector
Uncover development, testing, and staging RDS databases configured with redundant Multi-AZ standbys that double monthly compute costs.
1. Detection Scope & Operational Boundaries
Every ArthaOps detector enforces strict epistemic honesty. We clearly separate what can be mathematically proven via agentless telemetry from what requires contextual human judgement.
What This Detector Identifies
- Amazon RDS PostgreSQL, MySQL, and MariaDB instances configured with Multi-AZ = true in non-production accounts or environments.
- Database instances bearing environment tags such as dev, staging, test, qa, or sandbox.
- Instances where standby replica infrastructure doubles hourly instance and storage rates without serving live customer traffic.
What It Cannot Establish Alone
- Whether the non-production cluster is actively conducting automated failover testing, disaster recovery drills, or chaos engineering experiments.
- Whether contractual client SLAs or compliance certifications mandate identical Multi-AZ configuration in staging environments.
2. Telemetry & Evidence Requirements
ArthaOps operates strictly via Plane 1 (Read-Only Discovery). The following CloudFormation / IAM permissions and CloudWatch metrics are evaluated:
AWS::RDS::DBInstanceVerification Protocol: Tested against synthetic PostgreSQL and MySQL multi-AZ database fixtures.
Validation Context: Validated in development and QA environments where staging instances accidentally inherited production high-availability configurations.
3. Reproducible AWS CLI Verification Recipe
List all RDS database instances in ap-south-1 that have Multi-AZ enabled and evaluate instance identifiers and tags.
# List non-production Multi-AZ database instances in ap-south-1
aws rds describe-db-instances \
--region ap-south-1 \
--query "DBInstances[?MultiAZ==`true` && (contains(DBInstanceIdentifier, 'dev') || contains(DBInstanceIdentifier, 'staging') || contains(DBInstanceIdentifier, 'test') || contains(DBInstanceIdentifier, 'qa'))].{Identifier:DBInstanceIdentifier,Class:DBInstanceClass,Engine:Engine,MultiAZ:MultiAZ,AllocatedStorage:AllocatedStorage}" \
--output table---------------------------------------------------------------------------------------------
| DescribeDBInstances |
+------------------+---------------+-------------+----------+-------------------------------+
| AllocatedStorage | Class | Engine | MultiAZ | Identifier |
+------------------+---------------+-------------+----------+-------------------------------+
| 200 | db.m6g.xlarge | postgres | True | staging-orders-db-instance |
+------------------+---------------+-------------+----------+-------------------------------+💡 Multi-AZ synchronously provisions a hot standby replica in an adjacent availability zone. In staging and dev environments, this configuration doubles the monthly bill with zero production protection.
4. Transparent Economic Model
- 730 operational hours per standard calendar month.
- Multi-AZ doubles both compute instance hours and provisioned storage costs.
- Non-production environments do not require synchronous cross-AZ failover outside planned testing windows.
- Provisioned IOPS rates on io1/io2 and backup retention charges beyond 1 day are excluded from base savings calculation.
5. False-Positive Scenarios & Operational Risks
Never delete or terminate cloud resources blindly. These validated architectural scenarios must be reviewed before initiating remediation:
Documented False-Positive Scenarios
- Pre-Production Load & Failover Testing: Staging environments running automated chaos tests or load benchmarking must replicate production Multi-AZ behavior.
- Regulatory Mirroring: Specific financial services mandates require pre-production topologies to exactly mirror production infrastructure configurations.
Blast Radius & Remediation Risks
- Brief Maintenance Window: Converting an RDS instance from Multi-AZ to Single-AZ deletes the secondary standby replica. This causes zero primary downtime, but subsequent failover capabilities are unavailable until re-enabled.
- Mitigation: Capture a manual DB snapshot prior to modifying the instance configuration.
6. Remediation Procedure & Rollback Runbook
Follow this ordered sequence of verified AWS CLI actions to remediate the resource with complete rollback availability:
Capture Manual Pre-Modification DB Snapshot
Create an explicit manual snapshot before modifying database topology.
aws rds create-db-snapshot --region ap-south-1 --db-instance-identifier staging-orders-db-instance --db-snapshot-identifier staging-orders-pre-single-az-backupWait for Snapshot Completion
Confirm snapshot state reaches available.
aws rds wait db-snapshot-completed --region ap-south-1 --db-snapshot-identifier staging-orders-pre-single-az-backupConvert Instance to Single-AZ
Modify instance to remove the Multi-AZ standby replica. The standby replica is decommissioned without primary interruption.
aws rds modify-db-instance --region ap-south-1 --db-instance-identifier staging-orders-db-instance --no-multi-az --apply-immediatelyForensic Rollback Procedure
To re-enable Multi-AZ at any time, execute `aws rds modify-db-instance --region ap-south-1 --db-instance-identifier <id> --multi-az --apply-immediately`. AWS will synchronously provision and sync a new secondary standby replica within 15–30 minutes.
🔒 ArthaOps Assurance: ArthaOps requires snapshot confirmation before executing RDS configuration changes and verifies non-production tag fencing.
Converting to Single-AZ immediately deletes the standby replica. In the rare event of a primary host failure prior to re-enabling Multi-AZ, recovery must be executed via snapshot restore.
How This Appears in the ArthaOps Control Plane
db.m6g.xlarge PostgreSQL instance running with Multi-AZ standby in staging environment with zero external failover testing.
Test Your Infrastructure in 180 Seconds
Explore our zero-setup interactive sample report covering real Mumbai findings, or launch a 100% read-only agentless scan across your AWS environment.