Azure SQL Database traffic migration to newer Gateways
As Azure infrastructure improves, Microsoft will periodically refresh hardware to ensure we provide the best possible customer experience. In the coming months, we plan to add Gateways built on newer hardware generations, migrate traffic to them, and eventually decommission Gateways built on older hardware in some regions.
Customers will be notified via email and in the Azure portal well in advance of any change to Gateways available in each region. The most up-to-date information will be maintained in the Azure SQL Database gateway IP addresses table.
Impact of this change
The first round of traffic migration to newer Gateways is scheduled for October 14, 2019 in the following regions:
- Brazil South
- West US
- West Europe
- East US
- Central US
- South East Asia
- South Central US
- North Europe
- North Central US
- Japan West
- Japan East
- East US 2
- East Asia
The traffic migration will change the public IP address that DNS resolves for your SQL Database. You will be impacted if you have:
- Hard coded the IP address for any particular Gateway in your on-premises firewall
- Any subnets using Microsoft.SQL as a Service Endpoint but cannot communicate with the Gateway IP addresses
You will not be impacted if you have :
- Redirection as the connection policy
- Connections to SQL Database from inside Azure and using Service Tags
- Connections made using supported versions of JDBC Driver for SQL Server will see no impact. For supported JDBC versions, see Download Microsoft JDBC Driver for SQL Server.
What to do you do if you're affected
We recommend that you allow outbound traffic to IP addresses for all the Azure SQL Database gateway IP addresses in the region on TCP port 1433, and port range 11000-11999 in your firewall device. For more information on port ranges, see Connection policy.
Connections made from applications using Microsoft JDBC Driver below version 4.0 might fail certificate validation. Lower versions of Microsoft JDBC rely on Common Name (CN) in the Subject field of the certificate. The mitigation is to ensure that the hostNameInCertificate property is set to *.database.windows.net. For more information on how to set the hostNameInCertificate property, see Connecting with SSL Encryption.
If the above mitigation doesn't work, file a support request for SQL Database using the following URL: https://aka.ms/getazuresupport
- Find out more about Azure SQL Connectivity Architecture