>> Are you tired of managing
IP addresses for your Azure resources?
Now, Azure public IP prefix enables you to use
one prefix to manage all your public endpoints with predictable,
contiguous public IP addresses that don't change as you scale.
Anavi Nahar, is going to show us how
it works today, on Azure Friday.
[MUSIC].
>> Hey everyone. Donovan Brown here,
with another episode of Azure Friday.
I'm here with Anavi and we're going to learn
about public IP prefix.
So public IP prefix. Tell me what this is about.
>> Okay. So all of public IP prefix is a reserved range.
So think about how today in Azure,
let's say you have a VM scale sets,
or application gateways deployed to our load balancers.
Each time you deploy this and you want it to be public facing,
you have a public IP address.
>> Correct.
>> Think about how annoying it is to have
these individual IPs that you don't control,
and then carry forward with the list.
This one is for my load balancer,
this one is for my app gateway.
So what a prefix does is, it gives you a range.
So when you deploy these resources,
you don't have to worry about what
IP will be assigned to these resources
because it will come out of this range which is
a contiguous block of IPs.
>> Actually, I do all these personally because I
run a site out of App Service.
>> Okay.
>> I depend on a third-party API,
and the way that they give me
permission is through your IP address.
I had to go off and scavenge and
find like all. They're not contiguous.
There's these random IP address is that
Web App Service might speak out from,
that they then had to put in their database to grant me access.
What you're saying now is that, there will be
much easier if I were to use
a prefix because I would just say instead
of these five random IPs,
just go ahead and white-list this range.
>> Exactly. You can just get a /28 for example,
which is 16 public IP addresses.
>> Got it. >> So what's funny Donovan,
is the fact that you are the customer that we are trying to solve.
>> I'm looking forward to this because
it's been a pain for me to have to deal with that,
and sometimes they'll change or if you have to
re-provision a move it, is just a nightmare.
So I know this will be fantastic.
>> Awesome.
>> So how do I actually set it up?
>> Okay. Let's go into the details.
So first off, I just have a regular ARM template here.
As you can see, I have all the details put in,
but I'll spare everyone the details.
The main important point here,
is where I have this prefix defined.
>> Okay.
>> So what I went ahead and did in the portal,
I created a public IP prefix.
So it's a resource just like any other resource.
>> Okay.
>> How you deploy a VM, you just social public IP prefix,
and it'll show up exactly the same as any other Azure resource.
So what I did was, I went ahead and deployed the prefix.
Now, I have assigned the ID here in my ARM template.
So let's look at that resource really quickly.
>> Now, I noticed that you're assigning a pre-existing IP prefix,
but I could also have deployed the IP prefix as part of
that ARM template and just made it a
dependence like everything that needs to depend on that,
and then automatically assign it.
>> Exactly. Usually, it depends on function.
>> Okay. All right.
>> Yeah so that's totally fine.
I think it depends on the person style, usually an automation.
That's exactly what customers do.
>> Okay.
>> So as you can see,
I have a public IP prefix.
I'm very creative with the names.
I called it PublicIPPrefix1.
It's deployed in West Europe.
It's a /28, which is 16 IP addresses.
As you can see, 10 of the 16 were deployed.
>> Okay.
>> The next thing I did is,
I went ahead and just
deployed the template that I created that I showed you.
I deployed it in this specific resource,
with the template file that was on my OneDrive folder,
and I called it again, very creatively, VMSSWithPublicIp.Prefix.
All right. So now that I showed you
the prefix and how I deployed it,
let's go ahead and see,
did these IPs from this prefix actually go into my VM skillset?
So when I go ahead and click on my skillset,
I see that I selected 10 instances,
so I have 10 different individual instances.
So let's go ahead and look at them.
Here, you'll see all my instances are deployed 0-9 of course.
I'll click on an individual instance,
and navigate to the networking blade of that specific instance.
Once I do that, you will see that
the IP address that I'm using for it here,
the public IP address is 51.105.233.128.
Now, that probably sounds familiar to me and not everyone else.
That's probably because it's exactly from this prefix here,
which we've allocated the 10 IP addresses which is 55.105.233.128.
Another cool aspect is,
it'll show you how many IP addresses are allocated.
Of course, we made a pretty for the UI her,
e but you can also do that through API,
which is actually useful because let's say your website,
you now expanded or App Service, you mentioned, expands.
So they don't have to worry about
the prefix running out because they know,
or at least, they can set alerts when they're running
out and prepare for for their customers.
>> Very cool. This isn't in private preview or anything.
This is actually a ready to
go GA feature that people can start using?
>> Exactly. We GAd it in March.
We previewed an Ignite before that.
>> Okay.
>> But yeah, it's GA in all public regions, even national Clouds.
So if you want to deploy a prefix in China,
you can, even in the government Clouds as well.
>> Perfect. Are there any resources that
use IP addresses that does not apply to you?
>> That's a great question.
So public IP prefix today,
the IP addresses that you get are standard public IPs.
>> Okay.
>> So that means it will be supported
for a standard load balancer,
the application gateway will
choose you which uses standard public IP.
So any resource that can use standard public IPs.
In Azure, we have basic public IPs and standard public IPs.
>> Okay.
>> Standard public IPs provide zone resiliency,
so availability zones and in case a zone goes down,
your application or deployment in Azure won't go down.
>> Your IP addresses will still be the same across those zones.
>> Exactly. So we support prefix for standard public IPs.
So like I said, any resource that
uses standard public IPs should be able to leverage this.
>> Got you. So we showed how to do it in the ARM template,
which is the way, I'm a DevOps guy,
it's clearly the way I want our customers should do it.
>> Yeah.
>> But a lot of our customers aren't there yet.
They still have people that mainly go into the portal.
Is there a way to a sign
that prefix to a resource from the portal as well?
So from the portal,
what you can do with the prefix is
create a prefix and then add an IP address,
as you can see over here.
Once you add an IP address,
then it's treated just like any other IP address,
and you can select it.
>> I got you.
>> So there are few products
and we're rolling out the rest of the products
that will support it,
but in the meantime, you can just add
an IP address and use it like you regularly would.
>> Perfect. We're learning all about
public IP prefix here on Azure Friday.
[MUSIC]