Hi, I'm Somesh,
and I'm an engineering manager,
in Azure Networking team.
And today,
I'm going to talk about,
how to optimize connectivity,
for Azure services over the internet.
We use this same network,
to run some of the largest SaaS services on the internet.
From Microsoft Office,
to Microsoft Teams.
They are built on this network,
to deliver content to the end user.
But we also understand,
there are workloads,
which are not latency sensitive,
and deliver large amount of traffic.
One example of such traffic,
is replication.
For such workloads,
we are giving cost optimized solutions,
with routing preference.
Routing preference uses the internet,
to deliver content to the end users.
Along with the connectivity,
there are a number of services,
we have deployed in the edge.
Let's dive into Microsoft's global network.
As you can see,
Microsoft's network is one of the biggest in the world.
Talking about the scale number,
Microsoft's global network,
connects more than 60 Azure regions,
across five continents.
Microsoft has more than 200 Express Route partners,
providing private network connectivity,
from on-premises to the cloud.
We also have more than 20,000 peering connections,
to serve the traffic over the internet,
to the end user.
More than 175,000 miles of fiber,
connects this regions,
and the edges to the Microsoft global network.
We built this network over last 20 years,
and we operate this network using software systems,
to react to failures as fast as possible.
Microsoft global network is,
the best performing global network,
on the planet.
A network,
which is secure,
and scales for your infrastructure.
Today,
we have over 19O edge POPs,
connecting the users within 25 milliseconds,
to the Microsoft network.
We are always expanding our edge network,
and deploying our edge POPs closest to the user.
Traffic runs on Microsoft's global network,
closest to the user using cold potato routing.
Talking about inter-region latency,
Azure inter-region latency,
is the best amongst all cloud providers.
All Azure traffic between Azure regions,
is encrypted using layer two encryption.
All the traffic,
leaving Microsoft's physical security boundary is encrypted.
Traffic between Azure regions,
remains within Microsoft's global network.
And we have Azure zonal architecture,
to provide high availability and disaster recovery.
Now let's talk about routing preference.
Routing preference is a service,
which provides cost optimized, egress options to the users.
If you look at Microsoft network,
by default,
we do cold potato routing.
Traffic from Azure region,
to the edge sites,
remain within Microsoft's network,
and we deliver the traffic closest,
to the user.
This gives the best performance and reliability.
However,
we do have some workloads,
which are not latency sensitive,
and want to optimize the cost.
So for that,
we have routing preference,
internet option,
which uses the internet,
to deliver the traffic to the end user.
As you can see in the picture,
traffic exits Microsoft network,
closest to the hosted service region.
We have two different routing options,
to deliver traffic,
from the Microsoft network.
Routing preference,
is currently supported,
for both Azure public IP,
and Azure storage account.
To enable routing preferences,
for Azure public IP,
You can select internet option,
when creating public IP.
Please note,
that you cannot modify this routing options,
on your existing public IP resource.
You can associate this public IP,
with your virtual machine.
Virtual machine scale set,
load balancer,
Kubernetes services,
or application gateway.
Inside the storage account,
you can enable the internet routing option,
in the networking tab.
Users can access same storage accounts,
over two different networks,
using two different URLs.
When we designed the routing preference,
we did not limit the users,
to have single routing option.
Routing preference gives the ability,
to have both routing choices,
on the same Azure resource.
Whether it's storage account,
or public IP on a virtual machine,
users can enable both routing choices on Azure resources.
This is a unique feature in Azure,
to have same resource,
accessed over two different networks.
You can use this feature,
to enable high availability,
for your resources.
And now I'm going to demo,
how to enable this routing options,
for the storage account or public IP,
and show you the performance measurement,
over two different networks.
-: Here I am,
in the Azure portal,
and now I'll show you,
how to enable internet routing option,
for your storage account.
To enable internet routing option,
for a storage account,
select networking tab,
and then you can see,
routing preference option.
By default,
Microsoft network routing,
is enabled on the storage account.
But you can override,
the default option,
to internet routing,
by selecting this radio button.
In addition,
you can keep Microsoft network routing,
as default routing option,
and publish internet routing endpoints,
by checking this checkbox.
These options are designed,
to make sure customers can access same storage account,
over the internet,
and the Microsoft network.
Now, if you select the end point tab,
you can see both end points,
for different routing option.
Internet routing option,
has different endpoint,
and different URL,
for the same blog service.
Now I'm going to quickly demonstrate,
how you can access,
same storage account,
over two different networks,
and see the performance difference.
In my storage account,
I have demo container.
And inside the demo container,
I have demo.html.
I also have one minute countdown file,
which I'm going to download,
using two different end points.
So let's just see the content for demo.html.
As you can see,
the HTML is downloading same countdown file,
over to different end points.
And I have a pause button,
just to see the performance difference.
So let's start download this file.
Countdown will start soon,
and as you can see,
same file is getting downloaded,
over two different networks.
Let's go ahead,
and pause the video,
and see the time difference.
And now you can see,
the Microsoft network is slightly better,
over the internet.
But what about Azure virtual machine?
Now, let me quickly jump,
into my Azure virtual machine scale set,
which I have created for this demo.
My scale set has one virtual machine instance,
and it has two virtual network interfaces.
Both this virtual network interfaces,
have instance level public IP addresses assigned,
but with different routing option.
NIC test one,
is using internet routing option,
and NIC test two,
is using the Microsoft network.
You can access the same virtual machine or scale set,
with two different IPs,
over two different virtual network interfaces.
And last,
as you can see in Azure portal,
how you create the public IP address,
with different routing options.
-: One of the use case for routing preference is,
to deliver traffic via CDN providers to the internet.
For this,
we have introduced routing preference unlimited,
also known as CDN Interconnect.
Azure users can host the content in Azure storage,
and use CDN providers,
to deliver traffic to the end user.
Microsoft has direct interconnect with the CDN provider,
and there is no egress costs,
to the Azure user,
for the traffic delivered via this direct interconnect.
Now let's switch gears,
and talk about cold potato routing,
to deliver traffic optimally across public internet,
from Microsoft Cloud.
We recently introduced Azure Peering Service.
Azure Peering Service is a partnership,
with the service provider,
to deliver the traffic closest to the user.
The service provider,
has local and geo peering redundancy,
and the capacity,
to deliver the traffic to the user.
Microsoft also optimizes,
the routing inside the Microsoft network,
to deliver traffic closest to the user.
In addition to optimizing routing,
peering service also provides telemetry platform,
for the users.
Azure users can see telemetry about latency,
BGP routing,
and performance degradation events,
using the Azure portal.
Behind the scenes,
we have a service called RADAR,
which stands for,
Route Anomalies Detection and Auto Remediation.
RADAR processes,
20 million routes every hour,
to detect real-time hijack.
Now let's go deep on,
how we achieve high reliability,
using local and geo redundant connection.
As you can see in the picture,
service provider has redundant connections,
with Microsoft in different geographies.
Traffic is delivered on the shortest path,
if the shortest path is available.
But when the shortest path goes down,
traffic is delivered via same provider,
in different geography to the user.
In this way,
traffic to the user remains in the provider network,
and does not cross provider boundary.
We're also enhancing peering service,
for communication services,
using the same principles,
of local and geo redundant connections.
This is to ensure,
Microsoft can deliver voice traffic reliably,
to the end user.
To deliver this traffic reliably,
Microsoft has set up connections,
with voice providers,
using Bidirectional Failover Detection,
or BFD.
We also provide end-to-end quality of service,
on voice traffic,
so that it can be prioritized,
over all other traffic.
We offer same cold potato routing,
and telemetry platform,
for the providers to see and optimize the traffic.
And with that,
I'll complete my talk today,
on how you can optimize connectivity,
for your Azure services over the internet.
At Microsoft,
we are building one of the largest global networks,
in the world.
And we want to use this,
to deliver traffic over the internet reliably.
Thank you.