[MUSIC]
>> Hello, everyone. My name is Narayan Annamalai.
I lead the Product Group for Azure Software Defined Networking.
Today, I'm going to talk to you about advanced VNet concepts.
For our agenda, what I'll do is I'll start with an overview,
then we'll look at some of the new abilities that we
have in the platform, recent abilities,
and we'll talk about more of the advanced architectures,
the do's and don'ts,
and we'll close there.
Now for many of you,
this would be familiar concepts,
but I just want to do a quick refresh for
someone who may not be that familiar.
A VNet or Virtual Network is
the logical isolation of public Cloud for customer.
It's a regional concept,
so by creating a virtual network,
you bring your IP address space into the Cloud.
This virtual network in Azure now supports
an IPv4 address space and an IPv6 address space,
so you could bring
your own v6 private space into the Cloud and put it on the VNet.
You start with subnetting your network so you create subnets.
In each of these subnets or dual stack,
which is once you
launch your computer sources inside these subnets,
they can have an IPv4 private address and
an IPv6 private address
from the address range that you gave to the subnet.
You can deploy not just your VMs or Kubernetes clusters,
but you can also deploy
other Azure services that
support being deployed inside a virtual network.
You see me talk a lot today about
bringing these Azure services into the VNet.
There's a couple of different ways we do that.
One of it is deploying them right inside your VNet itself.
These are mostly offered for services that are more dedicated,
like for example, SQL Managed Instance.
SQL Managed Instance is a fully managed service,
but it is deployed inside your virtual network,
just for your purposes.
We also have shared Azure services, and we'll talk about them.
Once you deploy resources into the subnets,
you have the ability to create
a security group, and a routing table.
We'll look at those in a bit,
but at a high level,
a security group is going to cover who gets to talk to the subnet,
both inbound and outbound.
A route table is going to determine
how the packets are getting routed when they leave the subnet,
and you have ways to customize that.
Azure gives you a default
setting for both security group and for route table,
and the customers have the ability to
go customize that and change it.
Azure also provides a default gateway
which gives connectivity to the Internet.
When you deploy the resources into Azure even without spinning up
or assigning a public IP address or even
before you assign a load balancer to it,
there is default connectivity to the Internet,
provide availability for the gateway.
Of course, you can always configure your route table.
Low security would deny that and say block Internet,
but it's a default availability, it's already there.
In addition to that, there's also a network load balancer,
which gets connectivity from
the Internet into the computer resources.
They're then used for load balancing internet traffic,
but you could also use this channel for going out to the Internet.
Load balancer behaves more like a dual-purpose,
both inbound from Internet,
as well as outbound to the Internet.
Then you obviously have on-premises.
You connect the on-premise to the VNet
using our access route or VPN gateways.
There's a managed service called
Virtual Network Gateway that makes these connections possible.
Once you expand your footprint in Azure,
you would create more VNets,
and you can connect these VNets in
a wired VNet peer when we look at that also in a bit.
Now, for the past services which I talked about,
which are shared services,
which are outside your virtual network.
We said things like keyword,
even tops that you will consume that are not inside your VNet.
We had something called service endpoints,
which provided an optimized route to these services,
and then the ability to lock these services down to
only allow the VNet to talk to it.
But recently, we also have private endpoints,
and private endpoints are similar to the concept of when
which the past resource gets mapped into the virtual network.
It does have a favorite IP address.
We'll look at that also in a minute.
This is just a summary
of what we had in about I would say in the last six months,
and then before six months, this is what we had,
and this is how things worked with the virtual network platform.
Now, let's look a little bit deeper into
the next topic, which is micro-segmentation.
How can you do micro segmentation in a VNet?
I talked about this network security group briefly.
What we also have along with network security group
is something called application security group.
These are concepts or grouping mechanism by which you can tag
workloads and give it a friendly name like
a web or an app or a database as I've shown over here.
This could go across subnets.
You don't have to really,
only group things in the same subnet.
You can just group any VM resources in
your VNet and tag it with a workload name.
Once you have that, you can use that in the security group itself.
It becomes easier to have
your network security group rules defined.
Where you can say on the web VMs,
allow internet to talk to you on port 443 or allow
only Db to talk or app to talk to the Db in port 1433.
You can have these kind of rules,
and it can just create the security group once and
then associate that with any supplement that you may have.
The rules would apply based on
the workloads that are present in the subnets.
It's a really easy way to
architect your network security group rules is ASG,
our application security groups.
Additionally, we also have something called as service tags.
These are IP blocks or IP
tags that represent Azure Services like Storage or SQL.
You could allow numerous traffic from
your VNet to these Azure services by
using these tags in your NSGs.
The last six months or so,
we have added a number of tags.
Our goal here is to actually have
all Azure services be available to you as tags.
Next, I want to talk to you a little bit about routing.
Like I said, there's default routes that's available for you in
the VNet that connects all the resources in the VNet,
and also has a route to the Internet.
But by putting a route table in the subnet,
you can take control of how routing actually works.
In Azure VNet, we give the ability to direct
any packet in the VNet to go through
an appliance or firewall, if you will.
Even within the same VNet,
if you go from one subnet to the other subnet,
you could put a route table entry over there and say,
send this traffic via an NVA.
These NVAs could live either locally in a VNet,
or they could be in some other VNet, like a VNet peer.
But then you have the ability to
redirect any traffic from the VNet through these NVAs.
In the future, we are also
planning to support service tags in these UDRs.
Where which we can say,
regular traffic goes via the default gateway,
but if it's traffic that is going to the storage service,
then I want to send it via the firewall so
you can do more inspection just
for specific traffic that is going to specific services.
That's something that we are looking to enable in the future.
That's now the routing abilities that you have.
Next, let's look at VNet to Internet.
We talked about a couple of different options.
One is a default gateway.
Another, I told about the load balancer
where you could assign a public IP address to the load balancer,
which will behave like an ingress point,
and the VMs behind this load balancer,
which are called as back-end VMs,
could use the load balancer to also go onto the Internet.
Load balancer are going to doubles up both as
an ingress point as well as an egress point.
But that could only be used
with back-ends that's behind the load balancer.
The newest service that we have
launched is called as the NAT Service.
Now, this is a fully managed service that
is fully run by the Azure,
which you can attach to a subnet or to the entire VNet.
By doing this, all of your traffic from the VNet
will then go through the NAT service to the Internet.
The NAT service itself will support
one public IP address or
a prefix of public IPs that you can give it,
so it will use one of these public IPs to go out.
The big benefit by using
a NAT service is, number one, it is managed.
You don't have to worry about having
enough ports for going to the Internet.
If you really have a scale-out
scenario wherein there could be lot of
packets that's leaving your VNet to go into the Internet,
you don't have to worry about the scale of it.
You could just attach this VNet to the NAT service,
and give the NAT service IP addresses to use, and that's it.
Each IP address can give you 64,000 connections to the Internet.
You could scale or you could even give
it a prefix of IP addresses to use,
so the NAT service can actually draw into that deflect wire.
This fully-managed way of connecting to the Internet
is very scalable and makes it easier for customers.
This service is actually right now in general availability
across all our regions.
So next, I want to talk about bringing services into the VNet.
We talked about service endpoints,
which is something that we always had.
But of late, Private Link is a new service by which
Azure PaaS Services are the ones that
typically are not inside your VNet,
they are outside, could be mapped inside your virtual network.
So typically, a good example is Azure Storage,
Cosmos DB, SQL database,
it's a shared from Azure then into PaaS services.
When you create the account,
you get a CDN that is also a public IP address,
so typically you have to leave
your VNet to go and access these accounts.
But with Private Link,
what you're doing is you're doing a mapping
of these resources into your VNet.
So there is, what we call as a Private Endpoint.
A Private Endpoint sits inside your VNet.
Think of it more like
a network interface card that you attach to a VM.
But instead, this neck is attached to the PaaS resource.
Any traffic that you send to
this Private Endpoint stays within your VNet, is fully private.
Azure is the end platform that will take
care of routing it to the right service.
By enabling Private Link or Private Endpoint,
you're locking down your PaaS resource
also to only receive traffic from the Private Endpoint.
So anything from Internet is all cut out.
So the PaaS resource system becomes more secure,
it becomes more secluded,
it becomes private just to your VNet.
So this is the concept that we had.
Another thing that we also did with this that's unique
is inbuilt data exfiltration protection.
So with an Azure Private link,
what is getting mapped into your VNet is
just the PaaS resource that you chose,
it's not the entire service.
So if there are other accounts in your SQL database,
the VNet doesn't get to talk to those.
The VNet only gets to talk to
the ones that are privately link to it,
or privately mapped to it through the Private Endpoints.
That way, it protects the VNet from extrapolating data out of it.
Now, we launched this service I think
about maybe eight months ago or something.
We had support only for three services,
that was storage, Cosmos DB, and SQL.
Now, in the last six months,
we have added support for almost 36 services.
Now, for Private Link, many of them are in general availability,
some of them are in preview.
But the goal is that
all Azure PaaS services will support Private Link so that we can
complete the scenario where we can have
all services privately available to you in your VNet.
Private Link is great,
but we want to extend that use of it also to your own services.
So let's say you have a service that you want to
share with multiple VNets,
then you can put this service behind
the Standard Load Balancer and
enable Private Link for that service.
So the Azure SDN platform then will have
an in-built NAT functionality for the service,
and it'll allow the service to be connected
from consuming VNets via a Private Endpoint.
So exactly the same concept.
So each consuming VNet can create
a Private Endpoint and then map
it back to this Private Link service,
and the traffic will be completely private to both these VNets.
The big benefit over here is you could connect VNets with
overlapping IPs to the shared service privately.
I mean, if you had to use VNet peering,
then with overlapping IP addresses,
it wouldn't have been possible for you.
But now with Private Link,
since each of these Private Endpoints
are local to the individual VNets,
overlapping IPs is not a problem.
So when the traffic comes over to the server side,
it'll be enacted by an in-built NAT on
the private link service to make the connections unique.
So this is a good ability that
is out there that could be used for your own services.
We have a number of our marketplace vendors who are building
support for their offering in Azure over Private Link service.
Snowflake is one example.
So you can use these,
the third parties services also,
you can consume them via Private Link.
Of late, we also have support for
TCP Proxy V2 that you
can send information about the source to the Private Link service,
which is basically both the IP address
of the client as well as their private link id,
which enables you to do filtering on the other side.
Moving on to the next topic,
the VNet peering itself.
I want to show you some ways to actually do scale out.
Because if you talk to a customer if
they handle like tens of hundreds of virtual networks,
it's not possible for them,
from management standpoint to have extra gateway
on all of these VNets or to have a firewall over these VNets,
and even Private Endpoint for that matter.
The recommended architecture if you're scaling
out is to have one central VNet.
Think of it more like a transit VNet where you can put
these common Private Endpoints over there,
or your NVA, or firewalls over there,
definitely the gateway, extra source gateway on the transit VNet.
Then from your other VNets that
appear to this transit VNet, enable transit.
It's just a simple flag that is
there on every VNet peering connection.
By enabling transit, then
those Client VNets are able to
use the services that is available in the transit VNet.
So these Client VNets can just use
the expressed door gateway that is
available in the transit VNet to go to on-prem,
or they could use the Private Endpoints that is
available over here to connect privately to the PaaS services.
So as an organization that if
you have more than a few PaaS resources,
instead of creating a Private Endpoint on each VNet,
you could just create this all Private Endpoints in one place,
and you put them in the transit VNet.
Then that makes it available
to all the VNets that are peered to it,
if you enable transit as a functionality.
There is no extra cost for this.
It's just an endpoint platform feature that enables you to
share resources across this for your VNets.
So that's it.
It's a good way to use any shared service and to scale,
and makes the management a little bit easier.
With that, one other last topic I want to
also cover is the network load balancing.
So network load balancing, I showed you in the first slide,
was just in a VNet.
So it's more regional,
and there is a public IP address on the Load Balancer.
What we have done now,
it's actually a preview feature,
is cross region load balancing.
So we are introducing
another layer called a Global Load Balancing layer,
which you could just create as an Azure Resource.
That can point to the Regional Load Balancers.
So the big benefit is that the users that are going to be
sent to the closest node destination
from where they're actually connecting,
they'll be directed to one of
these Regional Load Balancers
that are closer to where they're connecting from.
But the big benefit is if one of
the regions is not available, they're down,
then the traffic is automatically routed to
the other region where the service is still available.
But the big benefit here is
the IP address the client uses to connect never changes.
So they still use
the same IP address that is provided by the Global Load Balancer,
which is just the Global Anycast IP address. That never changes.
They're always going to be using the same IP address.
But they'll be directed to the Load Balancer in
the right region based on proximity as well as availability.
So this gives them a great way of
fast failover because there is no DNS cache, and normally,
gets direct network level of connection using IP addresses,
and it makes scaling out in Azure that much easier.
So that brings us to the end of the presentation.
So all that I really wanted to do was
to give you a quick refresher of
the virtual network platform and
point you to some of the new availabilities that we have,
and some of the architectural techniques and tips.
I hope that was useful,
and thanks for watching. Thank you.
[MUSIC]