Lastly,
let's turn our attention to the Azure networking subsystem and
how we connect to our Azure virtual machines.
Here's a Lucidchart diagram that I created.
It's pretty overwhelming at first,
and we're just going to look at a subset of items that you see here,
okay?
So don't freak out seeing NAT gateways and peerings.
Microsoft has a separate associate‑level certification for the Azure
Network Engineer job role; it's the AZ‑700 exam,
specifically.
But for our purposes,
we just need to know the basics about Azure virtual machine networking.
Now the software data center that we put our virtual machines
into in Azure is called the Virtual Network.
And although these VNets support both Internet Protocol version 4 and 6,
the Microsoft exams tend to ignore v6.
We're just concerned with IPv4 here, okay?
And you've got yourself one or more overall address ranges,
and Azure takes care of dynamically distributing those private,
non‑routable IP addresses using Dynamic Host Configuration Protocol.
It's an important point that your virtual networks,
although they exist in the internet and are internet‑adjacent,
those VMs that you deploy in a VNet,
unless you have some ingress from the internet configured,
they are inaccessible from the internet.
That's an important point.
These VNets are secure isolation boundaries for your VMs.
Now notice that the VMs have a little network interface card icon on them.
This is to denote that your networking in Azure VMs is done
separately from the virtual machine configuration.
That is, there's a virtual network interface that you associate with the VM,
and that is where you configure your IP addressing.
The main software firewall used in Azure virtual networks
is called the network security group.
This is simply an OSI layer for access list where you use ports,
protocols, and IP addresses to construct,
allow, and block rules that govern both inbound,
that's ingress, and outbound, egress, network traffic.
We've got a hybrid cloud shown here, and again,
I don't need to get into the weeds of the various parts and pieces,
but there's a couple ways, actually,
that you can extend your on‑premises environment,
and by extension,
you can extend your on‑premises IP infrastructure
into your Azure Virtual Network.
One of those is what you see here,
what's called a site‑to‑site virtual private network,
or VPN, that traverses the internet.
It's an IPsec IKE2 tunnel.
The other way to go is to use WAN technologies.
This is what's called Microsoft ExpressRoute.
Peerings, I'll just highlight this, allow you,
in a cost‑effective way,
to link or create a routing path between virtual networks.
So you might have a hub VNet where you've got a VPN to on‑prem,
you might have an Azure firewall, and these things can get pretty expensive,
and you don't want to deploy these to all of your VNets,
yet you still want to have transitive routing among those VNets.
This is where peerings can really shine.
Some various ways to establish network connectivity to an Azure VM,
if it's Windows Server,
you may want a desktop, so you can do Remote Desktop Protocol,
if it's Linux, you would not do a desktop typically,
you'd use SSH, but either way,
you could affix a public internet‑accessible IP address to the VM.
It's called an instance‑specific public IP.
I would recommend against that because I can guarantee you that
if you put a public IP address on your VM,
you're going to see alerts in Microsoft Defender for Cloud within
24 hours of people trying to brute force you.
You really only want that public IP address directly on the VM if you're
looking to host inbound internet access to that VM.
There's far better options that I'll show you.
Another thing we could do is RDP or SSH over a hybrid connection,
like site‑to‑site VPN or ExpressRoute.
There we're connecting using private, non‑internet routable IP addresses.
The Azure Bastion represents a nice way to keep your VMs off the internet,
but still be able to get an RDP desktop or an SSH
connection to those virtual machines.
The Serial Console represents a sort of backdoor into your virtual machine.
This can be really handy if you need to gain emergency access to a
machine that somehow is inaccessible via other means.
Programmatically and through scripts you could use Azure PowerShell commands
or Azure CLI statements in a Bash script to work with VMs,
including connecting to them.
And there's others, but lastly,
there's the fundamental Azure Resource Manager REST API.
You could use a tool like Postman.
Now I don't know if you can invoke a desktop that way,
but at the least,
you could send commands to that virtual machine directly using HTTP and the ARM REST API endpoints.