Azure SQL Database and Azure Synapse Analytics connectivity architecture
This article explains architecture of various components that direct network traffic to a server in Azure SQL Database or Azure Synapse Analytics. It also explains different connection policies and how it impacts clients connecting from within Azure and clients connecting from outside of Azure.
This article does not apply to Azure SQL Managed Instance. Refer to Connectivity architecture for a managed instance.
The following diagram provides a high-level overview of the connectivity architecture.
The following steps describe how a connection is established to Azure SQL Database:
- Clients connect to the gateway, that has a public IP address and listens on port 1433.
- The gateway, depending on the effective connection policy, redirects or proxies the traffic to the right database cluster.
- Inside the database cluster traffic is forwarded to the appropriate database.
Servers in SQL Database and Azure Synapse support the following three options for the server's connection policy setting:
Redirect (recommended): Clients establish connections directly to the node hosting the database, leading to reduced latency and improved throughput. For connections to use this mode, clients need to:
- Allow outbound communication from the client to all Azure SQL IP addresses in the region on ports in the range of 11000 11999. Use the Service Tags for SQL to make this easier to manage.
- Allow outbound communication from the client to Azure SQL Database gateway IP addresses on port 1433.
Proxy: In this mode, all connections are proxied via the Azure SQL Database gateways, leading to increased latency and reduced throughput. For connections to use this mode, clients need to allow outbound communication from the client to Azure SQL Database gateway IP addresses on port 1433.
Default: This is the connection policy in effect on all servers after creation unless you explicitly alter the connection policy to either
Redirect. The default policy is
Redirectfor all client connections originating inside of Azure (for example, from an Azure Virtual Machine) and
Proxyfor all client connections originating outside (for example, connections from your local workstation).
We highly recommend the
Redirect connection policy over the
Proxy connection policy for the lowest latency and highest throughput. However, you will need to meet the additional requirements for allowing network traffic as outlined above. If the client is an Azure Virtual Machine you can accomplish this using Network Security Groups (NSG) with service tags. If the client is connecting from a workstation on-premises then you may need to work with your network admin to allow network traffic through your corporate firewall.
Connectivity from within Azure
If you are connecting from within Azure your connections have a connection policy of
Redirect by default. A policy of
Redirect means that after the TCP session is established to Azure SQL Database, the client session is then redirected to the right database cluster with a change to the destination virtual IP from that of the Azure SQL Database gateway to that of the cluster. Thereafter, all subsequent packets flow directly to the cluster, bypassing the Azure SQL Database gateway. The following diagram illustrates this traffic flow.
Connectivity from outside of Azure
If you are connecting from outside Azure, your connections have a connection policy of
Proxy by default. A policy of
Proxy means that the TCP session is established via the Azure SQL Database gateway and all subsequent packets flow via the gateway. The following diagram illustrates this traffic flow.
Additionally open TCP ports 1434 and 14000-14999 to enable Connecting with DAC
Gateway IP addresses
The table below lists the IP Addresses of Gateways by region. To connect to SQL Database or Azure Synapse, you need to allow network traffic to and from all Gateways for the region.
Details of how traffic shall be migrated to new Gateways in specific regions are in the following article: Azure SQL Database traffic migration to newer Gateways
|Region name||Gateway IP addresses|
|Australia East||126.96.36.199, 188.8.131.52, 184.108.40.206|
|Australia South East||220.127.116.11, 18.104.22.168, 22.214.171.124|
|Brazil South||126.96.36.199, 188.8.131.52|
|Canada Central||184.108.40.206, 220.127.116.11, 18.104.22.168|
|Canada East||22.214.171.124, 126.96.36.199|
|Central US||188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124|
|China East 2||126.96.36.199|
|China North 2||188.8.131.52|
|East Asia||184.108.40.206, 220.127.116.11, 18.104.22.168|
|East US||22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206|
|East US 2||220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52|
|France Central||184.108.40.206, 220.127.116.11|
|Germany North East||18.104.22.168|
|Germany West Central||22.214.171.124, 126.96.36.199, 188.8.131.52|
|Japan East||184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199|
|Japan West||188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168|
|North Central US||22.214.171.124, 126.96.36.199, 188.8.131.52|
|North Europe||184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124|
|South Africa North||126.96.36.199, 188.8.131.52|
|South Africa West||184.108.40.206|
|South Central US||220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52|
|South East Asia||184.108.40.206, 220.127.116.11, 18.104.22.168|
|Switzerland North||22.214.171.124, 126.96.36.199|
|Switzerland West||188.8.131.52, 184.108.40.206|
|UK South||220.127.116.11, 18.104.22.168|
|West Central US||22.214.171.124, 126.96.36.199|
|West Europe||188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168|
|West US||22.214.171.124, 126.96.36.199, 188.8.131.52|
|West US 2||184.108.40.206, 220.127.116.11, 18.104.22.168|
- For information on how to change the Azure SQL Database connection policy for a server, see conn-policy.
- For information about Azure SQL Database connection behavior for clients that use ADO.NET 4.5 or a later version, see Ports beyond 1433 for ADO.NET 4.5.
- For general application development overview information, see SQL Database Application Development Overview.