Azure : What do I put in front of my (web) application?

Introduction

In almost every design session, the following question pops up…

“What do I put in front of my web application to secure it?”

Today we will take a look at the different options at hand. Or better said … What is the difference between the following services?

Azure CDN vs Azure Front Door versus Azure Application Gateway (WAF) vs Azure Traffic Manager

 

TL;DR

If you do not want to go through the entire post, here is a brief summary of the different options ;

My gut feeling tells me this will already help out like a lot! 😉

 

Web Application Firewall (WAF) : Azure Front Door vs Azure Application Gateway

Both Azure Front Door and Azure Application Gateway state that they can be configured to act as a Web Application Firewall. They key difference here is that the Azure Application Gateway can do a “detection only”-mode and that it supports CRS 2.2.9, 3.0, and 3.1. This means that there are out-of-the-box rules that provide a baseline security against most of the top-10 vulnerabilities that Open Web Application Security Project (OWASP) identifies. With Azure Front Door, you need to configure the rules yourself to your liking.

In terms of networking, there also is a very important difference between both. An Azure Application Gateway can be deployed (injected) in(to) an Azure VNET (Virtual Network). By doing so, the traffic between this gateway and your internal backend will flow through a private network. With Azure Front Door, your backend is always based on a public endpoint. Though you can harden / lock down the connectivity between Azure Front Door and your application by restricting the ingress of the traffic.

 

Geographic Redundancy : Azure Front Door vs Azure Traffic Manager

If you want to publish your webapp across regions, then you can leverage Azure Front Door or Azure Traffic Manager to do so. The most important thing to know is that Azure Traffic Manager is DNS based and serves as a redirection mechanism. Azure Front Door will serve as an entrypoint (think reverse proxy). So when using Traffic Manager, you will typically look at another reverse proxy / WAF (like Azure Application Gateway) to cover the need for the secure entrypoint for your application. Next to that, the Azure Traffic Manager is more feature rich in terms of the routing mechanisms, though Azure Front Door (just like Azure Application Gateway) have the advantage of working at layer 7 (Reference : OSI Model), thus also do header/path based routing.

 

Caching Content : Azure CDN vs Azure FrontDoor

The first thing to realize is what the intent was of both solutions?

• Azure CDN is a Content Delivery Network and was designed to delivery content. Think in terms of media files (“video”) for instance.
• Azure Front Door was built as a scalable entry point for applications (like Office 365)

Both will do caching (check the links above), though they differ in the sweet spots. Azure Front Door will cache files up to 8MB (as a side trait), where you should think that this is mainly done to optimize the delivery of your “web app”. Azure CDN its core function is caching… It was built to ensure that your files would be distributed world wide and delivered from a local pop.

The funky thing here, is that (if you ignore the Verizon and Akamai flavors of Azure CDN) both Azure CDN and Azure Front Door share the same POPs! Though the caching mechanics of both work differently.

 

DDOS

All services will have DDOS protection (“Basic”), as this is native to any Azure service! It is a key component of the Microsoft backbone actually. Though you can augment the services that reside in your VNET with the “Standard” protection. That being said, do know that the Azure Application Gateway does not scale as dynamic as the other services mentioned here (Azure Front Door and Azure Traffic Manager). So this could become a bottleneck for your design.

 

Closing Thoughts

With more than 100 services in Azure, you are bound to have services that overlap in terms of capabilities. I do hope this post provides you with some guidance towards a the external facing endpoints of your application! The above things are the recurring patterns I see in discussions with the organizations I talk to when deploying web applications on Azure.

Leveraging Azure Tags and Azure Graph for deploying to your Blue/Green environments

Introduction

For this post I am assuming you are pretty familiar with the concept of deployment strategies (if not check out this post by Etienne). Now these are typically seen from an application deployment level, where platforms (like for instance Kubernetes) typically have out-of-the box mechanisms in place to do this. Now what if you would want to do this on an “infrastructure level”, like for instance the Kubernetes version of Azure Kubernetes Service. We could do an in-place upgrade, which will carefully cordon and drain the nodes. Though what if things go bad? We could do a Canary, Blue/Green, A/B, Shadow, … on cluster level too? Though how would we tackle the infrastructure point of view of this? That is the base for today’s post!

 

Architecture at hand

For today’s post we’ll leverage the following high level architecture ;

This project leverages Terraform under the hood. Things like DNS, Traffic Manager, Key Vault, CosmosDB, etc are “statefull’ where its lifecycle is fully managed by Terraform. On the other hand, our kubernetes clusters are “stateless” from an Infrastructure-as-Code point-of-view. We deploy them via Terraform, though do not keep track of them… All the lifecycle management is done on operating on the associated tags afterwards.

 

Community-Tool-of-the-day

The drawing above was not created in Visio for once. The above was made leveraging CloudSkew, which was created by Mithun Shanbhag. Always awesome to see community contributions, which we can only applaud!

Zone Aware Azure VPN Gateway : Deployment options

Introduction

Today a quick post on Zone Aware VPN Gateways… When you currently create a VPN gateway, you’ll see the following screen ;

There are two important options to note here ;

– Availability Zone

– Active / Active

Resiliency Patterns in Azure

Introduction

Resiliency patterns in Azure is a very common / return question. Though over the course of time, I’ve noticed there is a lot of confusing around the architectural patterns involved here. This mostly comes down to the basic illusion that HA (High Availability) and DR (Disaster Recovery) are both met when doing a stretched cluster.

 

Overview of all the patterns

 

Combining Azure Traffic Manager, CloudFlare & Azure App Service for Geographic Scale!

Introduction

For today’s post, let’s take a look at an architecture example where you want to provide a geographic deployment of your webapp by using a cloudbased WAF (like Cloudflare, or Akamai, …).

 

High Level Setup

So what will we be setting up & testing today?

The user will receive a url that is powered by “Azure Traffic Manager”. That will have three endpoints ; one in Europe, one in the US and one in Asia. These endpoints will be powered Cloudflare and back by an Azure Webapp.  You’re question will probably be ; “Why use that sequence?” Because the Traffic Manager is DNS based and will do a “basic” HTTP check. If you would setup the Traffic Manager behind Cloudflare/Akamai/…, then you would see the source IPs of that service. Thus you would be unable to route the clients to the nearest location.

 

Azure Star / Any Load Balancer or … like we would like to call it “HA Ports”

Introduction

A few weeks ago the “HA Ports” (finally) saw the light (in public preview)! I’m truly excited about this one, as it had become a “unicorn” for me over the last years.

Why am I so excited about this one? This unlocks of advanced networking patterns, starting with a truly HA setup for the Network Virtual Appliances (NVAs). In the past, we needed to rely on “workarounds” that would switch the UDR to point to the surviving node. That was great for the time, but let’s be honest… It shouldn’t have been like that.

Another use case is the scenario where an application needs to connect to a certain dynamic port ranges (like with SQL). I’ve seen several deployments annoyed by this requirement, which then forced people to create a lot of rules. This can now be avoided by allowing the entire port range, and just hardening it with a “Network Security Group” or Firewall rule base.

Azure Networking : Blueprint patterns for enterprises

Introduction

When moving to the cloud, one cannot imagine this without some kind of network integration. Taking a look at “Infrastructure-as-a-Service”, there are several common patterns that are utilized by enterprises. Today we’ll discuss these patterns…

 

Update – June 2018

Despite that this post isn’t even a year old, I’ll be updating it with the new guidance that come from the introduction of the standard LB. Here we advise to use a single legged deployment.

 

Typical Network Maturity Models

Embarking on a cloud journey? You’ll typically go through the following patterns depending on your “maturity level” in working with the cloud ;

1. “Island” : The first approach is typically “the island”. The VMs reside in a VNET that is not connected/integrated with any other networks, except for (maybe) the internet.
2. “Hybrid Connection” : The first step towards integration is creating a hybrid connection. Here you want to access “On Premises” resources, though the mass of the resources on Azure do not justify the investment into a “Network Virtual Appliance” (AKA Firewall). Two flavours typically arise here;
   1. “Forced Tunneling” : Here you set up a “UDR” (User Defined Route, AKA Static Route), where you force all traffic to go back to the “On Premises” network.
   2. “Azure = Internet Zone” : Here you assume that the Azure zone is does what it needs to do to protect its resources Though you’ll protect your “On Prem” zone by considering the Azure VNET as being “the bad internet”.
3. “Single VNET with DMZ” : One step beyond “forced tunneling”, is moving towards the typical DMZ-alike pattern, where you setup a HA-pair of “Network Virtual Appliances” and segregate network zones.
4. “Hub & Spoke”-model : Growing even further, you’ll have multiple subscriptions. Setting up “NVAs” on all of those can be quite expensive. In terms of governance, this also a nice model, where you can consolidate all network integration into a segregated subscription/vnet.

The advantage of these patterns is that you can evolve into another pattern without breaking anything in terms of design.

Azure : How to prepare for maintenance impacting your Virtual Machines

Introduction

A topic that’s often discussed in workshops is “Availability Sets“. And during that topic, a question/comment that pops up every time ; “Can I schedule the maintenance for my VMs, because…”. Today we’ll delve into that part.

 

Why do we need maintenance?

For some this might seem like a very odd question to pose and that is a given fact of life. Though some organisations live by the mantra “if it isn’t broke, why fix it”, and once a systems gets deployed, they’ll (try) never to touch it again…

Azure : Availability Patterns for IaaS – Can I do multiple regions?

Introduction

There are several questions that I’m often posed that relate to availability on Azure. In today’s post, we’ll take a look at the different availability patterns. Here I hope this will answer a big portion of the questions you might have about availability on Azure. The main intake for this post will relate to the “IaaS” chunk of Azure services. Concepts like Azure SQL, Webapps, etc may have a totally different approach. But then again, you are not responsible for designing (and thus do not need to worry about) the availability aspect of these services.

Azure : Traffic Manager in Classic mode vs Resource Manager

Introduction

Today I was setting up a Traffic Manager deployment in Resource Manager. I wanted a rather “simple” failover scenario where my secondary site would only take over when my primary site was down. As you might now, there are several routing methods, where “failover” is one ;

Failover: Select Failover when you have endpoints in the same or different Azure datacenters (known as regions in the Azure classic portal) and want to use a primary endpoint for all traffic, but provide backups in case the primary or the backup endpoints are unavailable.

Though I was surprised that the naming between the “classic mode” (“the old portal“) and “resource manager” (“the new portal“) were different!

 

“Classic Mode” / Service Management

So when taking a look at “classic mode”, we see three methods ;

They are described fairly in-depth on the documentation page, though in short ;

• Performance : You’ll be redirected to the closest endpoint (based on network response in ms)
• Round Robin : The load will be distributed between all nodes. Depending on the weight of a node, one might get more or less requests.
• Failover : A picking order will be in place. The highest ranking system alive will receive the requests.

 

“New Portal” / Resource Manager

When taking a look at “Resource Manager”, we’ll see (again) three methods ;

Though the naming differs… When going into the technical details, it’s more a naming thing than a technical thing. The functionalitity is (give of take) the same. Where the “Round Robin” had the option of weights (1-1000) before, this now seems a focal point. Where “Failover” was working with a list (visualizuation), you can now directly alter the “priority” (1-1000) of each endpoint.

The info when checking out the routing method from within the portal ;

• Performance: Use this method when your endpoints are deployed in different geographic locations, and you want to use the one with the lowest latency.
• Priority: Use this method when you want to select an endpoint which has highest priority and is available.
• Weighted: Use this method when you want to distribute traffic across a set of endpoints as per the weights provided.

 

TL;DR

Where the naming differs between the two stacks, the functionality remains the same ;

• Performance didn’t get renamed
• Round Robin became “weighted”
• Failover became “priority