Cloud services like Azure offer a lot of security features straight out of the box, especially if you’re using their platform services. But virtual infrastructures are much like physical infrastructures, connecting virtual machines with software-defined virtual networks. Thus, they need the same security and network management tools as your own data center and your own application infrastructures.
Two services are key to securing and managing Azure-hosted networks, focusing on different parts of the cloud journey.
- The Azure Firewall is for your first application, for API and web-based code that’s important to your business but not critical.
- As applications and services grow, and as businesses move more and more code from on-premises to the cloud, your needs will change and you’ll need tools to help scale your services as well as securing them. To do that, Azure Front Doorcombines security and load-balancing features, using edge services to control and direct access to globally distributed applications.
There’s no conflict between these two services. Azure Firewall gets you started, and you can use it to build out an application until traditional routing and load-balancing techniques start to fail. That’s when you add Front Door to your architecture, adding a new layer above your existing networking tools. They can stay in place as a backup to Front Door, or they can be removed once you’re happy with how Front Door operates.
Using Azure Firewall
Azure Firewall is a cloud implementation of a familiar modern firewall, one that’s ready to go as soon as you add it to your virtual network. It manages incoming and outgoing traffic to and from the public internet, as well as integrating with services like Azure VPN and ExpressRoute. This last option is perhaps one of the most important, because it helps manage your hybrid infrastructure as well, protecting traffic that links on-premises services with the cloud.
By adding a firewall to what’s ostensibly a private connection, you’re putting a cutout between two very different operating modes and two separate trust zones. On-premises systems are likely to have evolved over time, and you’re not going to lift and shift those existing infrastructures. Separating new and old infrastructures makes sense, because it lets you ensure that one network doesn’t affect the other.
Using Azure Firewall is much like using any rules-based firewall management tool: You set up inbound and outbound rules, with application and network controls. With virtual infrastructures in mind, it’s focused on protecting the Azure subnet that hosts your virtual servers and resources, controlling what resources your infrastructure can access as well as access to your systems. So, for example, if you’re using GitHub as your build pipeline, you can give your virtual servers access to GitHub to fetch application updates.
A single Azure Firewall instance can protect multiple subnets, with separate rules for each subnet. That way, you can have a customer-facing subnet as well as management subnet for your applications, one accessible from any IP address, the other limited to addresses from your Azure VPN. On-premises subnets can be managed in much the same way as Azure-hosted virtual networks.
More complex scenarios may require use of Cloud Shell, rather than the portal, using PowerShell to manage both network resources and the Azure Firewall rules.
Using Azure Front Door
Azure Front Door takes a very different approach to managing your cloud-hosted networks and services. A tool for linking distributed microservices into a single global application, it manages Azure applications that are implemented in multiple regions. Mixing routing rules and load balancing, it directs users to the region where they’ll get the best performance. That could be routing to a geographically local region, or to one that’s less busy, or even away from one that’s currently failed.
The services managed through a Front Door are treated as a pool, with routing rules handling connections from the Front Door service. You need to configure a front-end host name as well, which will is the address you give to users. The services in the pool don’t need to have fully custom domain names; they can remain on the default azurewebsites.net domain.
Routing to pool services can be handled by latency, by priority, or by traffic weighting. There’s also the option of setting session affinity rules, so that once a user session is connected to a service, all user traffic is delivered to the same service.
With support for a built-in web application firewall, there’s protection for your HTTP services. By inspecting HTTP traffic (including SSL) as it enters your application, Front Door can reduce application risks, protecting it at the edge while offering SSL acceleration services. There’s also DDoS protection, dropping attack packets at the edge of your distributed cloud applications.
While Front Door is new for users, it’s not a new service: It’s a commercialization of the existing tools that sit in front of Microsoft’s own services. By adding it to your applications you get the benefit of a set of services that have been proven across Bing, Office 365, and Xbox, only with a user experience that’s integrated in to the familiar Azure Portal.
Network management in the modern cloud
The split between the control and data planes in a software-defined network is moving much of what used to be the province of network engineers into the application space. Azure’s networking tools are part of this change, offering policy-based networking that handles both backend hybrid cloud traffic and customer-facing network services.
That’s very much a hybrid cloud approach at present, with customers using a mix of MPLS high-speed dedicated connectivity and managed VPN connections into Azure. MPLS works well when dedicated connections are needed for regulated data, while VPNs allow you to use your existing internet connections.