When a zone reaches capacity or experiences performance issues, or when you need cross-data-center disaster recovery, you can move an RDS for SQL Server instance to a different zone within the same region. The migration runs in the background without taking your instance offline, and there is no charge for this operation.
Before you begin
Check whether your instance is eligible for cross-zone migration.
Instance eligibility
| Condition | Eligible | Not eligible |
|---|---|---|
| Instance role | Primary instances | Read-only instances |
| Read-only instances attached | None attached | Has attached read-only instances |
| Instance state | Running | Any other state |
| Region | Has multiple zones | Single-zone region |
Unsupported instance types
The following instance types cannot be migrated across zones:
| Instance type | Notes |
|---|---|
| Shared instances | Not supported |
| Serverless instances | Not supported |
| Instances on the classic network | Not supported |
| Instances joined to an Active Directory (AD) domain | Not supported |
| RDS Cluster Edition primary instances with read-only instances attached | Not supported |
If the Migrate Data Across Zones button does not appear in the console, your instance likely does not meet one of the conditions above.
Migration scenarios
| Goal | Migration path |
|---|---|
| Resolve zone capacity issues or performance problems | Single zone to another single zone |
| Set up cross-data-center disaster recovery | Single zone to multiple zones |
| Meet specific feature requirements | Multiple zones to single zone |
Single-zone vs. multi-zone resilience: A single-zone instance can withstand server and rack failures. A multi-zone instance places primary and secondary instances in separate zones, which adds protection against full data center failures.
Service impact
Understand the impact on your services before you start:
| Phase | Impact |
|---|---|
| Data relocation | The instance remains accessible. Services are not affected while data is copied to the destination zone. |
| Switchover | The instance is unavailable for a few minutes. Make sure your application has an automatic reconnection mechanism. |
| After switchover | The virtual IP address (VIP) changes. Use the instance endpoint rather than the IP address — the endpoint resolves to the new VIP automatically. |
For Java applications: Set the Java Virtual Machine (JVM) DNS time-to-live (TTL) to 60 seconds or less so your application re-resolves the endpoint after the VIP changes.
To apply globally: in
$JAVA_HOME/jre/lib/security/java.security, setnetworkaddress.cache.ttl=60.To apply to a single application: call
java.security.Security.setProperty("networkaddress.cache.ttl", "60")in your initialization code, before the first call toInetAddress.getByName().
Billing
Zone migration is free, including migrations from single-zone to multi-zone deployment.
Migrate an instance across zones
Migration typically takes about 20–30 minutes depending on data volume. Schedule the migration during off-peak hours.
Before you start:
Back up host programs: Migration moves the instance to a different host, which clears the host account and any programs or files on the original host — including SQL Server Integration Services (SSIS), SQL Server Analysis Services (SSAS), and SQL Server Reporting Services (SSRS). Back up or migrate these before proceeding.
ImportantRDS for SQL Server provides a managed SQL Server kernel. If your workloads rely on SSIS, SSAS, or SSRS, make sure you have a plan to restore these on the new host before you start the migration.
Pause metadata changes: Do not add or delete databases, or change the recovery model during migration. These operations can cause data inconsistency.
Plan for Data Transmission Service (DTS) tasks: If a DTS task is running, you must manually restart it after migration completes.
Migration cannot be canceled: Once started, a migration task cannot be stopped.
Steps:
Go to the Instances page. In the top navigation bar, select the region where the instance resides, then click the instance ID.
In the Basic Information section, click Migrate Data Across Zones.
In the dialog box, select the destination zone, virtual private cloud (VPC), virtual switch (vSwitch), and migration time:
Switch Now — traffic switches immediately after data is copied. The instance is unavailable for a few minutes during the switchover. Choose this during off-peak hours.
Switch Within Maintenance Window — traffic switches during the next scheduled maintenance window. Choose this to minimize risk to production workloads.
Click Yes.
The system begins copying data to the destination zone. The instance stays online during this phase. Traffic switches to the new zone at the time you specified.
Verify the migration
After the switchover completes:
Clear the DNS cache on your application hosts to prevent stale-cache connection failures.
Connect to the instance using the endpoint and run a test query to confirm access.
Confirm that the instance name, port, tags, and database accounts are unchanged.
Restart any DTS tasks that were running before migration.
FAQ
Can I change a Web Edition (Basic Series) instance from single-zone to multi-zone deployment?
No. SQL Server Web Edition on RDS Basic Edition does not support multi-zone deployment. Upgrade the instance to Standard Edition (High-availability Series with a primary/secondary architecture) first. After the upgrade, you can migrate the secondary node to a different zone.
What's next
To trigger zone migration programmatically, call the MigrateToOtherZone API operation.