Understanding the budget impact of Azure Networking on your architecture

Introduction

Today’s post will be about “demystifying” the possible network costs you might incur when using Azure services. Once you understand the basics behind the billing model, you’ll soon find that you can tweak these to your advantage!

 

Cost Drivers

When looking towards the costs, there are several pricing pages you should visit to know the cost drivers of your architecture…

Though I can feel you… It’s not always easy to understand when what is triggered.

 

Updates (!)

  • 23/08 – Updated HL overview to v2.0 to include costs due to zone architecture
  • 23/08 – Source files for the drawing can be found here.

 

High Level Overview

Underneath you can find an overview of the possible cost drivers. We’ll go into depth on the individual flows in this post.

Continue reading “Understanding the budget impact of Azure Networking on your architecture”

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.

Continue reading “Azure Networking : Blueprint patterns for enterprises”

Azure ExpressRoute limits for large organizations & resellers… What are my boundaries?

The Theory
Let’s start off with some statements from the ExpressRoute FAQ

  • Can I have more than one ExpressRoute circuit in my subscription? Yes. You can have more than one ExpressRoute circuit in your subscription. The default limit on the number of dedicated circuits is set to 10. You can contact Microsoft Support to increase the limit if needed.
  • Can I have ExpressRoute circuits from different service providers? Yes. You can have ExpressRoute circuits with many service providers. Each ExpressRoute circuit will be associated with one service provider only.
  • Can I link to more than one virtual network to an ExpressRoute circuit? Yes. You can link up to 10 virtual networks to an ExpressRoute circuit.
  • I have multiple Azure subscriptions that contain virtual networks. Can I connect virtual networks that are in separate subscriptions to a single ExpressRoute circuit? Yes. You can authorize up to 10 other Azure subscriptions to use a single ExpressRoute circuit. This limit can be increased by enabling the ExpressRoute premium feature.
  • Can I have one virtual network connected to more than one ExpressRoute circuit? Yes. You can link a single virtual network with up to 4 ExpressRoute circuits. All ExpressRoute circuits must be in the same continent. They can be ordered through different service providers and in different locations.

And then we’ll check the Azure Limits page…

  • ExpressRoute dedicated circuits per subscription : 10 (default) & 25 (max)

The Summary

  • So per subscription, you can add up to 25 ExpressRoute circuits. These can be a mix of EXP or NSP connection and can be purchased from different telecom providers.
  • By default you can split up your ExpressRoute circuit between 10 VNETs (which can be located in different Subscriptions). It is possible to exceed that limit, where the maximum depends on your Azure port speed. A maximum of 100 VNETs can be configured when using a 10Gbit connection in EXP mode.

The Code

Grant a part of the circruit to “salesadmin@contoso.com” (as “masterofthenuniverse@contoso.com”)

New-AzureDedicatedCircuitLinkAuthorization -ServiceKey ‘6ed7e310-1a02-4261-915f-6ccfedc416f1’ -Description ‘SalesTeam’ -Limit 2 -MicrosoftIds ‘salesadmin@contoso.com’

Link the newly granted circuit to your VNET (as salesadmin@contoso.com)

New-AzureDedicatedCircuitLink –servicekey (Get-AzureAuthorizedDedicatedCircuit).CircuitName –VnetName ‘SalesVNET1’

Source : Sharing an ExpressRoute circuit across multiple subscriptions

In need of private network connectivity for Office 365 & Azure Services?

You are looking to use Office 365 or Azure Services, though you are wondering how you can seggregate workloads from travelling over public networks… With ExpressRoute, you are able to ensure that certain services are only accessible via your private virtual networks!

expressroute-public-and-private-peering

This possibility is possible for all Azure Services, except the following ;

  • Content Delivery Network
  • Visual Studio Online Load Testing
  • Multi-factor Authentication

So connectivity to virtual machines and cloud services deployed in virtual networks are supported over the private peering path. The same goes for Azure Websites and all other services are accessible.

When looking towards Office365, the following services are supported ;

  • Exchange Online & Exchange Online Protection
  • SharePoint Online
  • Skype for Business Online
  • Office Online
  • Azure AD & Azure AD Sync
  • Office 365 Video
  • Power BI
  • Delve
  • Project Online

The following Office 365 services are not supported ;

  • Yammer
  • Office 365 ProPlus client downloads
  • On-premises Identity Provider Sign-In
  • Office 365 (operated by 21 Vianet) service in China

(Though you can connect to these services over the internet)

Source ; ExpressRoute FAQ