Azure - Web to SQL with local (Azure) IP

Question

In a typical web app environment, the SQL server and Web App server are on the same network and the web app connects to the SQL server using a local IP. This, of course, helps performance as requests dont need to go out to the internet and come back, all the communication can be done in the local network. An added benefit is being able to completely restrict the SQL server to internal traffic only.

How can the same be accomplished with an Azure Web and SQL server? Im assuming that being in the same geographical area is an obvious requirement (or not?). Is it as simple as finding out the SQL servers local IP and opening the firewall to the web server? Are all azure resources in a geographical location part of the same network? Do I need to create a VLAN of some sort? Sorry....probably trivial questions, but not knowing the physical architecture of Azure creates confusion for me..

Answer 1

So for the SQL part (talking about PaaS), you would need to Allow access to Azure Services. That would allow your WebApp to access it. I'm pretty sure that even if the services are in the same region they won't talk internally (I might be wrong on this one). They 100% talk through the internet if they are in different regions.

If you are talking about SQL in a VM on Azure, you can create a VNet integration between WebApp and your VNet (where the VM resides) that would allow the traffic to flow internally. That would allow them to talk internally even across Azure region, but you would have to create additional VNet and create site-to-site VPN between VNets.

Answer 2

There is no such thing as a direct local connection for Azure SQL DB. You cannot place either in a virtual network (though a Web App can be connected to a VNET).

The firewall option in Azure SQL that allows traffic from your Web App allows traffic from any Azure subscription by the way. Azure can surely detect malicious attempts to break into Azure SQL and block them if they occur, but your main line of defense is your password. And auditing helps too of course.

Answer 3

It sounds like you're coming from the world of on-premises infrastructure.

In Azure, I think you'll want to look into setting up a simple Virtual Network. You gain access to the same "physical" network building blocks including routing tables, subnets, firewalls, gateways, ACLs, etc. You can keep things very basic, but you have the flexibility to introduce these features as-needed in the future.

Once your network is stood up, it's simple to add servers across your subnets.

Of course, all of this networking is entirely virtualized. You have the choice of keeping your network's subnet in the same region. I presume Azure's networking algorithms are intelligent enough to choose physical servers that are relatively close to each other when you add your two servers to the same subnet.