Microsoft Azure Essentials Fundamentals of Azure Second Edition e-optimized 5x11 pdf

6. 
It will look at the template, ignore the unchanged sections, and add the new subnet.  
7. 
After it’s finished deploying, it returns to the Resource Group blade. Select the VNet in the list of 
resources in the resource group, then click Subnets, and you see your third subnet has been 
added.  
You can also use PowerShell, the Azure CLI, or even the REST APIs to deploy a template to your Azure 
subscription. To be honest, using PowerShell is much easier than using the Azure portal to deploy 
resources using a template. 
Network Security Groups 
When you create a VM, by default it’s going to ask you to create a Network Security Group (NSG). You 
don’t have to create one. You can create your VMs in Azure and network them together without an 

---

149 
CHAPTER 5  |    Azure Virtual Networks 
 
NSG. However, if a VM has a public IP address, it is hosted on the public Internet, making it subject to 
attack. This means there is nothing protecting your VMs except the internal Windows firewall. 
Microsoft created NSGs to provide a flexible method for defining the access rules allowing traffic into 
and out of a VM in a VNet—or even an entire subnet in the VNet. When a Windows Server with a 
public IP address is created in the portal, an NSG is created that blocks all inbound Internet traffic 
except RDP on port 3389. Similarly, for a Linux VM with a public IP address, the default NSG created 
blocks all inbound traffic from the Internet except SSH on port 22. You have to specifically open any 
other ports you want open, including HTTP and HTTPS. If you do nothing, you are protected by 
default. The same set of rules can be applied to a single VM or multiple VMs. You can also apply an 
NSG to a subnet, which applies it to all of the VMs in that subnet. 
For example, let’s say you have four VMs running front-end applications. These connect to eight back-
end servers that consist of web services and database servers. You could create one NSG that says 
“allow access to/from the public Internet, and access to the back end” and apply that to all the front-
end VMs. Then, you can create another NSG that says “allow access from these four front-end servers, 
and allow access to the internal Azure services, but don’t allow access to the public Internet” and 
apply it to the back-end servers. The back-end servers will not be accessible from the public Internet.  
Note that NSGs are actually applied to a NIC attached to a VM (rather than the VM itself). If a VM has 
multiple NICs, the NSG needs to be applied separately to each NIC. 
If we later add two front-end servers to our resources, we can simply assign them to the same NSG as 
the other front-end servers and add the new servers to the allowed servers for the back end. This 
allows you to implement changes with no updates to the running VMs themselves. 
How are the rules applied? You can apply an NSG to a VM or to a subnet in a VNet. When you apply 
an NSG to a subnet, it applies it to all of the VMs in that subnet. For incoming traffic, the rules are 
applied before the traffic enters the VM. For outgoing traffic, they are applied after the traffic leaves 
the VM. This means the rules cannot be changed by a user process on the VM or even by the 
operating system because the rules are external to the VM.  
For more details about Network Security Groups, please check out 
https://azure.microsoft.com/documentation/articles/virtual-networks-nsg/
. For an example and 
instructions for setting up an NSG in the Azure portal, check out 
https://azure.microsoft.com/documentation/articles/virtual-networks-create-nsg-arm-pportal/
. 
Cross-premises connection options 
There are many cases in which you might want to connect to your infrastructure in Azure from your 
on-premises network, a customer’s site, your home network, or even a coffee shop, and you want to 
do this without compromising security. There are three options available in Azure to help you set up 
these cross-premises connections: site-to-site VPN, point-to-site VPN, and private VPN (Azure 
ExpressRoute).  
A VPN Gateway is an Azure managed service that is deployed into a VNet and provides the endpoint 
for VPN connectivity for point-to-site VPNs, site-to-site VPNs, and ExpressRoute. This gateway is the 
connection point into Azure from either the on-premises network (site-to-site) or the client machine 
(point-to-site). You’ll see how to do this when we set up a point-to-site network later in this chapter.