Inbound vs outbound traffic in Azure. What you need to know?

As many companies have moved their database and sensitive information to the cloud, it is important to have a solid understanding of how data flows in and out of your cloud environment. In Microsoft Azure, managing inbound and outbound traffic is an important aspect of ensuring optimal performance, security, and cost-effectiveness.

Managing inbound and outbound traffic in Azure is crucial for ensuring the security and performance of your applications and services. Inbound traffic refers to the data coming into your Azure resources from the internet or other networks. In contrast, outbound traffic refers to the data leaving your Azure resources and heading toward other networks.

Let’s begin.

What is Inbound Traffic?

Inbound traffic refers to the data that is coming into an Azure resource, such as a virtual machine, from outside of the Azure network. This traffic can come from the internet, other networks, or other Azure resources. Inbound traffic is subject to network security rules and will restrict or allow based on various criteria such as source IP address, port number, protocol, and more. It is important to properly configure inbound traffic rules to ensure the security and performance of your Azure resources.

When inbound traffic arrives at the Azure network, it is first intercepted by the Azure Network Security Group (NSG). The NSG is responsible for enforcing network security policies, such as allowing or denying access based on IP address, protocol, port, and other criteria.

For example, you have a virtual machine running that is hosting a website. When someone visits the website, their browser sends a request to the virtual machine asking for the webpage. This request is inbound traffic to the virtual machine because it is coming from outside of the Azure network.

What is Outbound Traffic?

Outbound traffic refers to the data that is leaving an Azure resource, such as a virtual machine, and heading outside of the Azure network. Outbound traffic originates from inside the network and it is intended for services located on the internet or outside the network. While firewalls will primarily block the incoming traffic from entering a network, and can also prevent external connections from receiving outgoing traffic.

When an Azure resource generates outbound traffic, it is first intercepted by the Azure virtual network interface card (NIC). The NIC then applies any network security policies that are associated with the resource, such as allowing or denying access based on IP address, protocol, port, and other criteria.

For example, you have a virtual machine running that is hosting a website. When the virtual machine sends the webpage to a visitor’s browser, that data is outbound traffic from the virtual machine because it is leaving the Azure network.

Inbound and Outbound firewall rules

Inbound firewall rules protect a network by blocking unauthorized traffic from the internet or other network segments. This includes disallowed connections, malware, and denial-of-service attacks. Inbound firewall rules allow you to control what traffic is allowed or blocked from entering your network. By blocking unauthorized traffic, you can protect your network from attacks and data breaches.

Outbound firewall rules allow you to control what traffic is allowed or blocked from leaving your network. Firewall rules protect the network by blocking potentially harmful outgoing traffic, like requests to questionable websites, VPN connections, and email services such as Post Office Protocol version 3, Internet Message Access Protocol, and Simple Mail Transfer Protocol. By blocking unauthorized traffic, you can prevent data exfiltration and protect sensitive information from being stolen.

To ensure network security, it is essential to not only configure inbound and outbound firewall rules but also monitor the system for any anomalies. Even the most secure firewalls have their limitations. Without internal resources such as security expertise and product training, outsourcing to a managed security service provider (MSSP) is a good option. MSSPs provide dedicated resources to monitor network security 24/7, making it the best way to minimize associated risks.

Methods to Manage Inbound and Outbound Traffic

Managing inbound and Outbound traffic helps to ensure that your resources are accessible only to authorized users and applications and will block all the other traffic that can harm your network. This is important in the case of distributed denial-of-service (DDoS) attacks, which can cause severe disruption and downtime to your applications and services.

There are many methods to manage Inbound traffic such as Access restriction, Internal Load Balancer, Private IP of inbound traffic on an Application gateway with a service endpoint, etc. But here I will explain to you the two most important methods, which are:

1. Service Endpoint: Allows Azure services to access resources in a virtual network over a private endpoint, reducing exposure to the internet.
2. Private Endpoint: Enables secure access to Azure services over a private connection, eliminating the need for public IP addresses and firewall rules.

Similarly, there are several methods to manage Outbound traffic such as Gateway-required virtual network integration, virtual network peering, Network security groups, etc. Here I will explain to you the 2 important methods, which are:

1. Hybrid Connection: Provides a secure and easy-to-configure way to access resources hosted in an on-premises network from Azure services.
2. Virtual Network Integration: Connects Azure resources to a virtual network using either a VPN or ExpressRoute connection, providing secure and fast access to on-premises resources.

Service Endpoint

By default, Azure services are all designed for direct internet access. All Azure resources have public IP addresses, including PaaS services, such as Azure SQL Database and Azure Storage. Because these services are exposed to the internet, anyone can potentially access your Azure services.

Service Endpoints can connect certain PaaS services directly to your private address space in Azure, so they act like they’re on the same virtual network. Use your private address space to access the PaaS services directly. Adding Service Endpoints doesn’t remove the public endpoint. It simply provides a redirection of traffic.

Service Endpoint provides a secured and direct connection to Azure services over an optimized route over the Azure backbone network. The Service endpoint will secure your important azure service resources only to your virtual network. The service endpoint will enable a private IP address in the VNet to reach the endpoint of an azure service without requiring public IP address.

Use virtual network Service Endpoints to extend your private address space in Azure by providing a direct connection to your Azure services. Service Endpoints let you secure your Azure resources to only your virtual network. Service traffic will remain on the Azure backbone and doesn’t go out to the internet.

Service Endpoints will provide the following benefits:

1. Provide improved security, and optimal routing and simplifies setup for securing Azure service resources to your virtual network.
2. You can add a virtual network rule to secure your resources, can remove public internet access from the resources, and can allow traffic only from your virtual network.
3. You don’t need public IP addresses or NAT or gateway devices to set up the service endpoints.
4. Service endpoint will allow you to audit and monitor your outbound internet traffic from your virtual network, through forced tunneling, without any impact on service traffic.

However, service endpoints have some limitations, that is:

1. Service endpoints are only available for virtual network that is deployed using the Azure resources manager deployment model.
2. It is only applied to Azure service traffic within the same virtual network region.
3. The endpoints cannot be used for traffic from your on-premise service to Azure services.

Private Endpoint

A private endpoint is a network interface that connects Azure resources privately and securely to a virtual network. This will allow you to access your resources over an Azure private link. A private endpoint creates a private IP address within your virtual network and uses it to access the resources. This helps to secure your resources by ensuring that traffic to and from the resource is isolated to the virtual network.

By utilizing a private endpoint for your application, you can achieve several benefits such as:

1. Disable public network access which will enhance security by minimizing public exposure.
2. Securely connect your application from on-premises networks through the use of VPN or ExpressRoute.
3. Avoid any data exfiltration from your virtual network.

Let’s understand how exactly a private endpoint works.

Let’s say you have an application that communicates with a database hosted on Azure SQL database. By default, this communication will work through the internet which can increase the security risks such as exposing sensitive data to an unauthorized user.

Now, to secure this communication, we will create a private endpoint between the application and Azure SQL Database. The Private endpoint will create a private IP address within your Virtual Network to connect to the Azure database via a private link. Once you set up the private endpoint, it will route traffic from the application and Azure SQL database through your virtual network, but not from the internet.

You can also restrict the access of unauthorized users to the private endpoint by providing an additional layer of security such as Network Security Group (NSG) which allows traffic only from specific resources.

A public IP address can still exist for the target resource alongside the private endpoint. The public IP is no longer used by the client application. The firewall can now disallow any access to that public IP address, making it accessible only over private endpoints. Connections to a SQL server without a private endpoint from the VNet will still originate from a public IP address. This flow is represented by the blue arrow in the above diagram.

Private link

For the private endpoint (Network interface having a private IP address in your VNet) to work a Private link will be required. This private link will ensure that the traffic coming from the private endpoint goes via the Private link and reaches to SQL server (as depicted in the below diagram).

Traffic between your virtual network and the service (in this case Azure SQL Database) travels the Microsoft backbone network. Exposing your service to the public internet is no longer necessary. You can create your private link service in your virtual network and deliver it to your customers. Setup and consumption using Azure Private Link are consistent across Azure PaaS, customer-owned, and shared partner services.

The private link allows you to access services without using the internet which means you can protect your services from potential security risks. You can also create your private link services within your virtual network which makes it easier for your customers to access your services.

Private Endpoint vs Service Endpoint

Both features (private endpoint and Service Endpoint) are used for more granular control over the firewall on the target service.

Both approaches overcome the problem of Source Network Address Translation port exhaustion. You may find exhaustion when you’re tunneling traffic through a Network Virtual Appliance (NVA) or service with SNAT port limitations. When you use service endpoints or private endpoints, the traffic takes an optimized path directly to the target service. Both approaches can benefit bandwidth-intensive applications since both latency and cost are reduced.

Even though both private endpoint and service endpoint look similar but there is a subtle difference between them.

In both cases, you can ensure that traffic into the target service passes through a network firewall or NVA. This procedure is different for both approaches. When using service endpoints, you should configure the service endpoint on the firewall subnet rather than the subnet where the source service is deployed. When using a private endpoint you put a User Defined Route (UDR) for the private endpoint’s IP address on the source subnet. Not in the subnet of the private endpoint.

The Private endpoint was setup by implementing the User Defined Routes in the Azure Firewall Subnet.

A service endpoint remains a publicly routable IP address. A private endpoint is a private IP in the address space of the virtual network where the private endpoint is configured.

Private Endpoints grant network access to specific resources behind a given service providing granular segmentation. Traffic can reach the service resource from on-premises without using public endpoints.

Here are the other differences:

PRIVATE ENDPOINT	SERVICE ENDPOINT
A private endpoint is a network interface that connects Azure resources privately and securely to a virtual network.	Service Endpoint is a network interface that provides a secured and direct connection to Azure services over an optimized route over the Azure backbone network.
Private Endpoints have access control at the resource level.	Service Endpoints have access control at the Virtual Network level.
It supports specific services like Azure Cosmos DB, Azure SQL DB and Azure Storage Account.But the support is only limited to specific set of services.	It supports gamut of services like Azure Key Vault, Azure Service Bus etc.
It requires additional efforts to set up and maintain	It is simple to set up and does not require any additional efforts
You can access the service without using any public address.	You cannot access the service without any public IP address. Remember public IP still remains active.We saw it above.
NSG configuration is not required to access the services.	NSG configuration is required to access the services using the service tags
DNS configuration is required.	DNS configuration is not required
The Private endpoint can disable its public IP address.	The Service endpoint cannot disable its public IP address.
You can easily restrict the traffic coming from Virtual Private Network or ExpressRoute.so it can be used for on-premise traffic as well.	You cannot restrict the traffic coming from Virtual Private Network or ExpressRoute.
Provided solutions are costly. For example, to use the private link you have to bare the cost.	Does not have any impact on the cost of the solution
There are limited private endpoints.	There are unlimited service endpoints in the virtual network. But, Azure services have limited subnets used for securing the resources.

Hybrid Connections

Hybrid connections are used to securely and reliably connect on-premises resources to the cloud. In Inbound traffic, a hybrid connection enables outside resources to connect to the resources hosted in Azure. Hybrid connections use a relay agent that provides security and reliability to the communication channel for incoming traffic.

In outbound traffic, a hybrid connection allows your cloud application to make outbound calls to specific TCP endpoints that are located outside of the cloud. These endpoint resources can be on-premises, on a virtual network, or anywhere that allows outbound traffic to Azure on port 443. To use the feature, you need to install a relay agent called Hybrid Connection Manager on a Windows Server 2012 or newer host. Hybrid Connection Manager needs to be able to reach Azure Relay at port 443.

Suppose your company has a legacy application hosted on-premises and wants to access data stored in the Azure database. The company intends to move the database to the cloud for better scalability and cost efficiency but wants to connect the application to the Azure database.

For this, your company will use hybrid connections. Now, your company will set up a hybrid connection in outbound traffic which will allow the application to make outbound calls to the database on port 1433 through the relay agent.

You can use a Hybrid connection for development or production environments for your applications, and accessing web services or databases. Other features are:

1. You can use it to access resources in private networks that are not connected to Azure with a VPN.
2. Helps to migrate on-premises apps to App Service without moving supporting database.
3. It will provide secured access to a single host and port per hybrid connection.
4. It also performs development in App Service that allows the apps to easily use on-premises resources.

But, a hybrid connection also comes with some limitations, which are

1. It is not suitable for the situation that creates many connections.
2. Setting up hybrid cloud architecture can be complex, and require expertise in both on-premises and cloud technologies.

Virtual network integration

App Service virtual network integration enables your app to make outbound requests into an Azure virtual network. This allows the app to access resources in the virtual network securely, and vice versa.

Apps in App Service are hosted on worker roles. Virtual Network Integration works by mounting virtual interfaces to the worker roles with addresses in the delegated subnet. Through the IP address of your virtual network, it can access most things through your virtual network.

In the below diagram Virtual Network Integration enabled the App so App’s backend is kept in the delegated subnet which calls Azure Storage via Service Endpoint.

When you enable virtual network integration, the web app is assigned an IP address from the virtual network’s address’s address space which allows it to communicate with the resources within the network. This IP address can be used for both inbound and outbound traffic.

Virtual network integration gives your app access to resources in your virtual network, but it doesn’t grant inbound private access to your app from the virtual network. Private site access refers to making an app accessible only from a private network, such as from within an Azure virtual network.This is important point to remember that the Virtual network integration is used only to make outbound calls from your app into your virtual network.

Outbound traffic is routed through the VNet routing table to the destination resource from the Web App. The Web App sends the traffic to the IP address of the resource within the VNet, and the routing table determines how to route the traffic to the appropriate subnet and network gateway.

When all traffic routing is enabled, all outbound traffic is sent into your virtual network. If all traffic routing is not enabled, only private traffic of the VNet and the service endpoints configured on the integration subnet are sent into the virtual network.

The Inbound traffic is routed through the Azure load balancer to the web app. The load balancer is configured to route traffic to the IP address assigned to the web app in the VNet. Once the traffic has been routed to the correct instance of the Web App, the Web App can access any resources within the VNet.

You can use Virtual Network Integration to:

1. Access resources in the resource manager virtual network in the same region.
2. Access resources that are accessible across VPN connections.
3. Secure all outbound traffic.
4. Access secured resources with a service endpoint.

Benefits of using Virtual Network Integration:

1. VNet provides a safe environment for your application.
2. You can connect to the public Internet with the help of a subnet in a virtual private network.
3. It is easy to route traffic from your resources.
4. With the help of VNet, you can create complicated network topologies.

Conclusion

This article has provided you with a comprehensive overview of inbound and outbound traffic in Azure. Learn different methods to manage the inbound and outbound traffic such as Service Endpoint, Private Endpoint, Hybrid Connections and Virtual Network Integration. Hence, by implementing effective inbound and outbound traffic management strategies, you can protect your resources from unauthorized access and reduce the risk of security breaches. Azure provides a range of tools and services, such as Network Security Groups (NSGs), Azure Firewall, and Azure Traffic Manager, to help you manage your inbound and outbound traffic effectively.