On this page · 12 sections
- What actually shipped
- The nine steps, and the one that will stop you
- The trap in the ungraceful path
- Where AWS contradicts AWS
- You cannot declare it in CloudFormation yet
- Cost, and what AWS does not charge for
- What AWS has not published
- India-specific considerations
- What to do this week
- FAQ
- How eCorpIT can help
- References
Summary. On 20 August 2026 AWS added the Amazon RDS Switchover Read Replica execution block to Application Recovery Controller (ARC) Region switch. It is the third RDS block, after the two promote and create blocks that landed on 27 February 2026, and the only one AWS describes as lossless: the docs promise a switchover "without data loss in the graceful path". The graceful path is nine steps long, and step 6 reads "Region switch validates that the primary instance in the other Region is available." That single line decides where this block belongs in your runbook. A switchover is a role swap, so it needs both databases up. During an actual Region outage the graceful path cannot complete, and you fall back to the same destructive promotion you already had. The block supports Oracle 19c and later only, not Aurora and not RDS Custom. ARC Region switch costs $70 per plan per month, with no separate per-execution charge published. And as of 21 August 2026 the block is absent from the CloudFormation ExecutionBlockConfiguration type, whose 17 properties include RdsPromoteReadReplicaConfig but nothing containing the string "Switchover".
What actually shipped
ARC Region switch is the plan-and-rehearse layer for multi-Region failover. You build a plan, fill it with execution blocks, and run it. The execution-block table now lists 17 block types, and row 13 is the new one. Its function cell reads: "Perform a switchover of an Amazon RDS Oracle read replica to make it the primary database instance." Its ungraceful-configuration cell reads: "Promote the read replica directly (can potentially cause data loss)."
That two-cell summary is the whole story compressed. The block gives you a clean role swap when everything is healthy, and the old lossy promotion when it is not.
Before this, AWS's own February announcement described the state of play plainly: "Coordinating Amazon RDS database recovery during Regional failover requires manual steps to promote read replicas and recreate replication, introducing delays and errors." The two blocks that arrived then, RDS Promote Read Replica and RDS Create Cross-Region Replica, automated promotion and re-replication. Neither preserved the replication relationship. As the promote block's page puts it, "the promoted instance will no longer replicate from the original primary database."
The RDS User Guide draws the distinction that matters: "A switchover differs from a read replica promotion. In a switchover, the source and replica DB instances change roles. In a promotion, a read replica becomes a source DB instance, but the source DB instance doesn't become a replica."
The nine steps, and the one that will stop you
The block documentation lists the graceful sequence in full. Reproduced verbatim:
- "Region switch waits for the target read replica instance to reach an available state."
- "Region switch verifies that the target instance is an Oracle 19c or later read replica in a valid standby mode (mounted or open-read-only)."
- "Region switch confirms that replication is active between the primary and standby instances."
- "Region switch validates that automatic backups are enabled on the standby instance."
- "Region switch checks for blocking pending maintenance actions on both instances."
- "Region switch validates that the primary instance in the other Region is available."
- "Region switch calls SwitchoverReadReplica to promote the standby to primary."
- "Region switch waits for the instance to become the primary and reach an available state."
- "If the original primary had Multi-AZ enabled, Region switch enables Multi-AZ on the new primary to match the original configuration."
Steps 3, 5 and 6 all reach back into the Region you are trying to leave. Step 7 goes further. The Oracle Data Guard switchover procedure requires RDS to "Block new transactions on the original primary database" and then "Ship unapplied transactions to the original standby database, and apply them." The preparation page states the precondition without hedging: "The original primary database and the original standby database are in the available state."
So the lossless promise is real, and it is conditional on the failing Region answering API calls and shipping redo. That is a planned-migration tool and a rehearsal tool. It is not an outage tool.
The trap in the ungraceful path
ARC does provide the outage path, and it is opt-in twice over. From the block page: "When an ungraceful execution is requested with the promoteReadReplica behavior, Region switch promotes the read replica directly using PromoteReadReplica. This is faster but may result in data loss if replication has not fully synchronized."
Then the sentence that belongs in your incident review: "If an ungraceful execution is requested without specifying a behavior, Region switch falls back to the graceful switchover path."
Read that at 3am. You hit ungraceful because a Region is on fire, you never configured a behaviour, and ARC quietly routes you into a path whose step 6 waits on the dead Region. The IAM page confirms the opt-in is explicit: rds:PromoteReadReplica is not in the base policy and must be added "If you configure an ungraceful behavior (promoteReadReplica)". Absent that permission and that configuration, the ungraceful button does not do the ungraceful thing.
The fix is a one-line configuration change, made now rather than during the event.
| Execution mode | What ARC calls | Source Region must be healthy | Data loss | Extra IAM action needed |
|---|---|---|---|---|
| Graceful (default) | SwitchoverReadReplica |
Yes, step 6 validates it | None, per AWS docs | No |
Ungraceful with promoteReadReplica |
PromoteReadReplica |
No | Possible if replication lags | Yes, rds:PromoteReadReplica |
| Ungraceful, behaviour unset | Falls back to graceful | Yes | None, but may not complete | No |
Where AWS contradicts AWS
Four gaps between the ARC documentation and the RDS documentation are worth checking before you trust the block.
Multi-AZ. ARC step 9 says Region switch "enables Multi-AZ on the new primary to match the original configuration." The RDS switchover preparation page says the opposite about the underlying operation: "You configure your desired Multi-AZ deployment before initiating a switchover. Amazon RDS doesn't manage Multi-AZ as part of the switchover. The Multi-AZ deployment remains as it is." Both can be true, because ARC is issuing an extra ModifyDBInstance on top, which is why that action appears in the sample IAM policy. Neither page tells you ARC is adding a chargeable, availability-affecting mutation to your failover.
Pending maintenance. The runtime sequence checks "both instances". The plan-evaluation list on the same page checks only the "in-region instance". Steady-state evaluation and the thing that blocks you during the event are looking at different scopes.
Option groups. ARC treats a failed plan-evaluation check as advisory: "If any of the checks fail, Region switch returns warning messages, which you can view in the console." RDS treats the same condition as fatal: the primary and its replicas "must be the only DB instances to use the option group of the current primary database. Otherwise, Amazon RDS prevents the switchover."
Licensing and options. ARC never mentions that running the standby in open-read-only mode requires an Active Data Guard licence, which the Oracle read replica overview spells out. It also restores backup and Multi-AZ settings while staying silent on the RDS warning that "If the original primary database had options such as SSL, NNE, OEM, and OEM_AGENT, Amazon RDS doesn't propagate them to the new primary database."
You cannot declare it in CloudFormation yet
The February 2026 release sold infrastructure-as-code management of Region switch plans. The CloudFormation AWS::ARCRegionSwitch::Plan ExecutionBlockConfiguration type currently exposes 17 properties: ArcRoutingControlConfig, AuroraProvisionedScalingConfig, AuroraServerlessScalingConfig, CustomActionLambdaConfig, DocumentDbConfig, Ec2AsgCapacityIncreaseConfig, EcsCapacityIncreaseConfig, EksResourceScalingConfig, ExecutionApprovalConfig, GlobalAuroraConfig, LambdaEventSourceMappingConfig, NeptuneGlobalDatabaseConfig, ParallelConfig, RdsCreateCrossRegionReadReplicaConfig, RdsPromoteReadReplicaConfig, RegionSwitchPlanConfig and Route53HealthCheckConfig.
None contains "Switchover". Checked 21 August 2026. If your DR plans are managed as code, this block is console-and-API only for now, and adopting it means a plan that your template no longer fully describes. That is the kind of drift that turns a rehearsed failover into an improvised one.
Cost, and what AWS does not charge for
The ARC pricing page renders in full, unlike most AWS pricing pages. Region switch plan: "$70 per plan per month", prorated, no commitment. A plan covers a single application. Cluster pricing is "$2.50 per hour per cluster" and readiness check is "$0.045 per hour per readiness check", with readiness checks closed to new customers from 30 April 2026.
There is no per-execution or per-block charge published. The pricing documentation says only: "You pay a fixed monthly cost per Region switch plan that you configure." The Oracle operation underneath is free of AWS surcharge too: "The Oracle Data Guard switchover feature doesn't incur additional costs."
At $70 per application per month, rehearsal is cheap. The expensive part is discovering during a real event that your plan was built around a step that needs the Region you are leaving.
| Item | Published price | Notes |
|---|---|---|
| Region switch plan | $70 per plan per month | One plan covers one application, prorated |
| Cluster | $2.50 per hour per cluster | Routing control clusters, separate feature |
| Readiness check | $0.045 per hour per readiness check | Closed to new customers from 30 April 2026 |
| Plan execution | Not published | No per-execution or per-block charge listed |
| Oracle Data Guard switchover | No additional cost | Active Data Guard licence needed for open read-only |
What AWS has not published
No RTO or RPO figure appears anywhere on the block page. Do not borrow the Aurora numbers: the Aurora Global Database block states "RPO is 0 (no data loss)" for its switchover and "typically a non-zero value measured in seconds" for failover, and those apply to Aurora, not to RDS Oracle. ARC measures recovery time after the fact rather than promising it: actual recovery time is "the total of the time is takes for a plan execution to complete, and any additional time that elapses before specific Amazon CloudWatch alarms that you configure return to a green state."
Region availability is inherited, not block-specific. Region switch is "available in all commercial AWS Regions, as well as AWS GovCloud (US) Regions". AWS has published no separate Region list for this block.
India-specific considerations
For workloads whose personal data must stay inside India, a cross-Region Oracle DR pair typically means ap-south-1 and ap-south-2. That keeps both copies in-country, which matters under the Digital Personal Data Protection Act 2023 where a data fiduciary has to know where every replica sits. The block changes nothing about residency, but it does change what your DR evidence looks like: a graceful switchover is a rehearsable, auditable event you can run on a schedule for $70 a month per application, and a rehearsal log is a stronger control artefact than a runbook nobody has executed. Teams building this out often pair it with multi-region resilience and disaster recovery engineering, and the same failover-scope questions come up in cross-region failover on Cloud Run and in Aurora DSQL versus Serverless v2 cost planning.
What to do this week
Check whether your ARC plans set an ungraceful behaviour. If they do not, set promoteReadReplica and add rds:PromoteReadReplica to the execution role, or accept that ungraceful means graceful. Confirm your standby is Oracle 19c or later in mounted or open-read-only mode with automatic backups on and a non-zero retention period, because steps 2 and 4 will stop the plan otherwise. Audit option-group sharing now, since ARC will only warn about it while RDS will block. And if your plans are Terraform or CloudFormation managed, decide whether a console-only block is acceptable drift before you add it.
FAQ
How eCorpIT can help
eCorpIT designs and rehearses multi-Region recovery for regulated workloads, including cross-Region Amazon RDS topologies where the difference between a switchover and a promotion decides your data-loss exposure. Our senior engineering teams map each execution block to a tested runbook, confirm the IAM and configuration prerequisites hold before an event, and keep plans declarable in code where the provider allows it. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified. Talk to us via /contact-us/.
References
Last updated 21 August 2026.