When deploying services in Azure, the connection to those services is important. Some services might require public access, while for other services you want to have a more private connection.. this post goes into the different options.. and what to take into account when connecting to services deployed in Azure..

Within Azure there is a difference between IaaS based Virtual Networks and other public services. By default, IaaS based services, such as Virtual Machines are completely isolated from external access, unless they are given a Public IP address or a VPN Gateway is added to the Virtual Network.

Platform-as-a-Service instances (such as storage, SQL, Web Apps, … ) use public access methods. When we state public access, it is actually implied that the IP addresses given to these services are published in the Microsoft Network Edge as described later in this document. PaaS services use a “public access point” that is used to connect to the service. In many cases, this Public access point is based on a fully routable internet domain name such as *.azurewebsites.net. Access to these services is, in many cases, controllable through an Access Control List. This ACL defines the source IP address(es) that can connect to the (public) Azure service.

Routing Architecture

The following picture shows the connection options for the services.

The front-end connection to any service in Azure is through the Edge network. This is a set of core-routers that hold the Azure IP address spaces allocated for a particular region. A list of address spaces can be found: https://www.microsoft.com/en-us/download/details.aspx?id=41653

When connecting between Azure services that have an address in this address space, the routing is through the Edge network or on a lower level inside the datacenter. Even though the IP address ranges are implied to be “public” IP addresses, the principals of IP routing still apply, as per the picture below:

The picture shows that for Subnet A to reach Subnet B, it can go through the router in the middle. The traffic is routed directly from source to destination without reaching the internet based interface. Only if traffic from A does not match any other subnet known in the routing table, the default route (3) will be chosen and will send the packets towards an upstream router on the internet.

As such; the traffic that is sent from one service in Azure to another service in Azure, will remain within Microsoft Boundaries and will not be sent to public routers.

Connections to Azure hosted services can be based on multiple architectures. As shown in the picture above, access to PaaS services is based on public internet access (yellow lines). Access to these services is based on regular internet traffic, routed through Internet Service Providers (ISP’s). There is no SLA on bandwidth or response times for regular internet published services.

IaaS VM’s can either have a public IP address exposed to the internet, or can be reached via VPN technologies. When choosing VPN technologies a VPN Gateway is added to the virtual network when the connection from the source is terminated. Azure supports Point-to-Site as well as Site-to-Site VPN’s. P2S implies that the source computer has a client installed that “dials” out to the Azure VPN Gateway to create a connection. A private IP address is allocated for the dialed in client to ensure the client can route traffic to the virtual network.

When selecting a S2S VPN, a device on-premises makes a connection to the Azure VPN gateway and routes a larger subnet over the VPN connection. For example, a local subnet of 172.16.0.0/24 can be fully made accessible to an Azure subnet of 192.168.0.0/24. Given the VPN device on-premises takes care of the connection, computers that access Azure resources do not receive an additional IP address, but regular routing is used.

VNET’s can also use VNET peering to connect to each other. This means that without creating a VPN connection between VNET’s, the entire address space of each VNET will become fully routable in the other VNET.

Express Route connections can be used to connect IaaS (and PaaS) services to the customer network without using “public” internet. ExpressRoute uses SLA backed connections to the Microsoft Edge router(s). Each ER circuit is terminated in the Microsoft Edge routers. From there, a connection can be made from a VNET based Gateway towards the Edge router to connect to the ER circuit. Multiple connections are supported, so multiple VNET’s can connect to the same ER circuit. It is possible to terminate the ER circuit in multiple Edge locations (America’s, Europe, Asia). This allows the ER circuit to achieve better performance (lower latency from certain regions) as well as failover capabilities (although each ER connection is already redundant).

ER is available in multiple modes. It can be used solely for IaaS based connections, only routing private address spaces defined in the customers subnets (in IaaS and on-premises). This mode is called Private Mode. It is also possible to also include the entire Address Space for a particular region in an ER circuit. This implies that ALL addresses (Azure public and IaaS private defined) are routed through the ER circuit. This mode is called Public Mode. Both modes then also have a premium and standard offering. In the standard offering the ER circuit can only be used by the same region the ER circuit is terminated at. In Premium Mode, it is possible to connect to any region (and thus in public mode it includes ALL Azure Public IP addresses).

When accessing services from one Azure region to another Azure region on their public IP address, the connection is via the Microsoft backbone network. Traffic does not traverse out to “public” internet and back-in, instead the connection is direct.

Connecting to PaaS services

As we have seen in the previous chapter, it depends on the connection used for the service as well as the type of service. IaaS VM’s can be reached via a VPN tunnel, a VNET peering (from another VM in Azure IaaS) or directly via a Public IP address.

When using that public IP address, like PaaS services, the ER type (if any) from on-premises determines the actual path. In ER-Public Mode the connection to these services will be through the ER circuit. In ER-Private or no ER at all, access to these services is via public Internet. However, if the source is an IaaS based VM, access to these services is within the Azure IP routing domain and thus it does not go beyond the Microsoft Edge.

In the picture below, it is visualised how an IaaS based VM would copy data to/from an Azure storage account. Locally the data is routed by the Edge towards the storage tier and redirected to the storage IP address if it is within the same region. When copying to another region, a direct connection between the Edge routers is established and the data is copied from/to the Storage Account in the other region.

Conclusion

We’ve described the different methods for connecting to Azure services and hopefully made it clear that service to service connections are handled by the Microsoft backbone network. Note that this backbone network not only applies to Azure, but also to other Microsoft services such as Office 365. That is why Azure based Citrix workstations make sense in some cases, certainly where a lot of cloud services being accessed from the workstation/users.