author: rohitnayakmsft

ms.author: rohitna

ms.reviewer: wiassaf, mathoma, vanto

ms.service: sql-database

ms.subservice: connect

ms.topic: conceptual

- "sqldbrb=1"

[!INCLUDE[appliesto-sqldb-asa](../includes/appliesto-sqldb-asa.md)]

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.

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:

- 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.

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](/azure/virtual-network/network-security-groups-overview#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.

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.

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.

The table below lists the individual Gateway IP addresses and also Gateway IP address ranges per region.

Periodically, we will retire Gateways using old hardware and migrate the traffic to new Gateways as per the process outlined at [Azure SQL Database traffic migration to newer Gateways](gateway-migration.md). We strongly encourage customers to use the **Gateway IP address subnets** in order to not be impacted by this activity in a region.

| Region name | Gateway IP addresses | Gateway IP address subnets |

| --- | --- | --- |

| Canada East | 40.86.226.166, 52.242.30.154, 40.69.105.9 , 40.69.105.10 | 40.69.105.32/29|

| Central US | 13.67.215.62, 52.182.137.15, 104.208.21.1, 13.89.169.20 | 104.208.21.192/29, 13.89.168.192/29, 52.182.136.192/29 |

| China East | 139.219.130.35 | 52.130.112.136/29 |

| China North | 139.219.15.17 | 52.130.128.88/29 |

| China North 2 | 40.73.50.0 | 52.130.40.64/29 |

| East Asia | 52.175.33.150, 13.75.32.4, 13.75.32.14, 20.205.77.200, 20.205.83.224 | 13.75.32.192/29, 13.75.33.192/29 |

- For information on how to change the Azure SQL Database connection policy for a server, see [conn-policy](/cli/azure/sql/server/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](adonet-v12-develop-direct-route-ports.md).

- For general application development overview information, see [SQL Database Application Development Overview](develop-overview.md).