Blog Post

Azure Database Support Blog
4 MIN READ

Azure SQL Database idle sessions are killed after about 30 minutes when "Proxy" connection policy

hugo_sql's avatar
hugo_sql
Icon for Microsoft rankMicrosoft
Sep 29, 2022

When we connect to our Azure SQL Databases or Azure SQL Managed Instances databases using the "Proxy" connection policy and the session is still open without any activity, the Azure SQL Gateway will kill the session after being idle for more than 30 minutes.

 

When we use the connection policy "Redirect" the Gateway won't kill the idle sessions after about 30 minutes.

 

In Azure SQL we have two connections policies:

Azure SQL Database connectivity architecture - Azure SQL Database and Azure Synapse Analytics | Microsoft Docs

  1. Proxy: the default option when you connect from on-premises without any ExpressRoute or Site-to-Site VPN. This policy requires port 1433 to open to connect to the Azure SQL  Database gateway.

  2. Redirect: the default option when you connect within Azure or from On-premises if you have implemented an ExpressRoute or Site-to-Site VPN. This policy requires ports 1433 to connect to the Azure SQL  Database gateway and 11000 to 11999 to establish connections directly to the node hosting the database. If you are connecting through a Private Endpoint Connection (Private Link), the port range is 1433 to 65535.


     

With this information, we have six different scenarios:

 

 

WITHIN AZURE:
Connection Policy: PROXY The session will be killed by the Azure SQL Gateway after about 30 minutes of being inactive (idle).
Connection Policy: REDIRECT The session won't be killed by the Azure SQL Gateway.
Connection Policy: DEFAULT (REDIRECT) The session won't be killed by the Azure SQL Gateway.
FROM ON-PREMISES (No VPN/ExpressRoute):
Connection Policy: PROXY The session will be killed after about 30 minutes of being inactive (idle).
Connection Policy: REDIRECT The session won't be killed by the Azure SQL Gateway.
Connection Policy: DEFAULT (PROXY) The session will be killed after about 30 minutes of being inactive.

 

In addition to these scenarios, we need to consider another variable "Private Links" (Private Endpoint Connections). If a "Private endpoint connection" is enabled on our Azure SQL Server, the default connection policy within Azure, Site-to-Site VPN, and ExpressRoute is set to "Proxy", so all sessions will be killed after approximately 30 minutes of being inactive (idle). However, you have the option to select the "Redirect" to force this connection policy. In the "Private EndPoint Connection (Private Link)" + "Redirect" scenario the port range is 1433 to 65535.

When you connect from on-premises without Site-to-Site VPN and ExpressRoute you can force it to use "Redirect", and the connections will be handled directly by the node that hosts the database, and then your session won't be killed by the Azure SQL Gateway.

These scenarios are easy to test.

You can open a Command Prompt (cmd) and run the following command on your Azure SQL Server:

 

And then monitor the idle session on your SSMS for example:

 

-- Run this script in your user database

DECLARE program varchar(20) = '';
DECLARE @msg varchar(50) = '';
DECLARE @session int = 57; -- type the correct spid

Set program = (SELECT [program_name]
FROM sys.dm_exec_sessions
WHERE session_id=@session and program_name='SQLCMD');

WHILE program is not null

BEGIN
Set program = ( SELECT [program_name]
FROM sys.dm_exec_sessions
WHERE session_id=@session and program_name='SQLCMD'
);

SELECT @msg = program + ' ' + convert(varchar(20),getdate());
RAISERROR(@msg,10,1) WITH NOWAIT

-- Wait for 1 minute
WAITFOR DELAY '00:01:00';
END

 

print '*** END TIME: ' + convert(varchar(20),getdate());
SELECT [program_name],session_id, DATEDIFF(minute,last_request_start_time,GETDATE()) [idle_minutes], last_request_start_time
FROM sys.dm_exec_sessions
WHERE session_id=@session and program_name='SQLCMD'

 

 

Finally, the session was killed after 32 minutes:

 

Let's see how it works when we connect to the Azure SQL Database through a Private Endpoint Connection (Private Link)

 

I have enabled "Private Access" at the Azure SQL Server level:

 

The private IP address is 172.170.0.6

 

 

 

And then we force "Redirect" connection policy:

 

Now, we will connect from an Azure Virtual Machine (VM):

 

We will connect to the Azure SQL Server through SSMS and then run the following networking commands:

 

nslookup srv-sqldb-test.database.windows.net

 

With this command we observe that the Azure DNS (168.63.129.16) is resolving the private IP address of the Private Endpoint Connection instead of the Public IP address of the Public Endpoint.

 

netstat -ano | findstr 172.17.0.6

 

With this command we observe that the Azure VM's private IP address(172.17.0.4) is connecting to the Private Endpoint Connection's private IP address (172.17.0.6) and port 22906 from the ports range 1433 to  65535.

 

 

 

Let's run the test T-SQL code:

 

 

We are going to check if the idle spid 78 will be killed after 30 minutes without any activity:

 

 

After 30 minutes we observe that the Azure SQL Gateway doesn't kill the idle session 78:

 

 

 

What happen when we select "Default" Connection Policy at Azure SQL Server level? in this case all connections will use the "Proxy" option, therefore the Gateways will kill idle sessions after 30 minutes:

 

 

We run again the T-SQL test (idle spid = 82):

 

 

The Azure SQL Gateway killed the session after 30 minutes:

 

 

 

 




 

Updated Mar 18, 2024
Version 4.0
  • Idle connections can get killed at the TCP Layer or by the Gateway.  

    • If idle at the TCP layer, connections can be dropped by network at client side and will have nothing to do with Gateway. 
    • And if it's idle by the Gateway where TCP keepalive messages might be occurring, but not had an active query in 30 minutes, then Gateway will determine that the TDS connection is idle and terminates the connection. 

     

  • Colin_Hunter's avatar
    Colin_Hunter
    Copper Contributor

    "To these scenarios, we need to add another variable "Private Links" (Private Endpoint Connections). If we have enabled a "Private endpoint connection" on our Azure SQL Server, the only supported connection policy within Azure, Site-to-Site VPN and ExpressRoute are "Proxy", so all sessions will be killed after about 30 minutes of being inactive (idle).

    Only when you connect from on-premises without Site-to-Site VPN and ExpressRoute you can force it to use "Redirect", and the connections will be handled directly by the node that hosts the database, and then your session won't be killed by the Azure SQL Gateway."

     

    Hi,

    Can I check the comment about Private Endpoint for SQL managed instances.
    Is this saying that the only connection "type" for MI, with private endpoint, is proxy - so idle session will always be disconnected after 30mins when using Private endpoint?
    Or can an on-prem connection without site-to-site VPN/ExpressRoute be used for SQL MI with PE (and therefore use "redirect")?
    The meaning of the sentence is not clear to me

    Thanks 

  • fmantovani For #1, my bet is that they just don't want an infinite number of connections sitting there for days. You don't have to do anything, the proxy does it.

     

    For #2 there is DEFINITELY, when running Proxy, a max number of connections. There's two number to watch, the maximum number of connections, and the number of connections being opened and closed. 

     

    We had an issue recently where we had 900 open connections (which was supported - that's based on the number of cores), but login times were ~200ms (instead of 5-10ms) when we were opening and closing in large numbers - about 10k/minute, I believe. We had to move to REDIRECT to fix this. We were told the Proxy server's CPU was at 100%, which was causing the logins to take longer, which in our case meant the logins were waiting to get in, which meant we had more and more connections.

  • fmantovani's avatar
    fmantovani
    Copper Contributor

    I have 2 questions: 

    1. In what scenario I need to do so? Why is important to kill a connection after 30 minutes? 
    2. Is there a limit of session connections in Azure SQL Database? 

    Because I don't see why putting this in place.