Have you realised the changes Microsoft have made to the firewall and networking section of Azure SQL Database? I found this quite stealthy and took me by surprise. I did encounter an edge case scenario where it lead to issues once I made some tweaks but that was a rare thing.
Here are the updated sections.
Ok, lets step through each area.
First one is easy to understand, most ( not all ) your solutions will probably not need the database to be publicly available. So you will probably want to set this to Deny mode and this will then tell Azure SQL DB to go via the virtual network endpoints.
Minimal TLS version? Well What I will say about this one is be careful, any login attempts from clients using TLS version less than the Minimal TLS Version stated here within the server setting will be rejected.
Connection policy – not sure why we have the power to change modes here but I have left mine as default. what do they mean?
Redirect (recommended): Clients establish connections directly to the node hosting the database, leading to reduced latency and improved throughput.
Proxy: In this mode, all connections are proxied via the Azure SQL Database gateways, leading to increased latency and reduced throughput.
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
What does Microsoft say? They ” highly recommend the
Redirect connection policy over the
Proxy connection policy for the lowest latency and highest throughput”. Fine, that does make sense.
The last element is the Allow Azure services option. I tend leave this on but you can be more granular if you like. For example, I have hooked up Azure Logic Apps to Azure SQL DB in the past with this setting off and the app failed. When it failed it told me the IP address that I needed to whitelist to get it work, the same theory applies to other Azure services ( from past experience) so its up to you. Production I tend to be more defensive.