Explore Azure compute services

Overview of Azure compute services –

Azure compute is an on-demand computing service for running cloud-based applications. It
provides computing resources such as disks, processors, memory, networking, and operating
systems. The resources are available on-demand and can typically be made available in minutes
or even seconds. You pay only for the resources you use, and only for as long as you're using
them.
Azure supports a wide range of computing solutions for development and testing, running
applications, and extending your datacenter. The service supports Linux, Windows Server, SQL
Server, Oracle, IBM, and SAP. Azure also has many services that can run virtual machines (VMs).
Each service provides different options depending on your requirements. Some of the most
prominent services are:
 Azure Virtual Machines: They are software emulations of physical computers. They
include a virtual processor, memory, storage, and networking resources. VMs host an
operating system, and you can install and run software just like a physical computer.
When using a remote desktop client, you can use and control the VM as if you were
sitting in front of it.
With Azure Virtual Machines, you can create and use VMs in the cloud. Virtual Machines
provides infrastructure as a service (IaaS) and can be used in different ways. When you
need total control over an operating system and environment, VMs are an ideal choice.
Just like a physical computer, you can customize all the software running on the VM.
This ability is helpful when you're running custom software or custom hosting
configurations.
 Azure Virtual Machine Scale Sets: They are an Azure compute resource that you can use
to deploy and manage a set of identical VMs. With all VMs configured the same, virtual
machine scale sets are designed to support true auto scale. No pre-provisioning of VMs
is required. For this reason, it's easier to build large-scale services targeting big
compute, big data, and containerized workloads. As demand goes up, more VM
instances can be added. As demand goes down, VM instances can be removed. The
process can be manual, automated, or a combination of both.
 Azure Containers and Kubernetes: They are Azure compute resources that you can use
to deploy and manage containers. Containers are lightweight, virtualized application
environments. They're designed to be quickly created, scaled out, and stopped
dynamically. You can run multiple instances of a containerized application on a single
host machine.
 Azure App Service: With Azure App Service, you can quickly build, deploy, and scale
enterprise-grade web, mobile, and API apps running on any platform. You can meet
rigorous performance, scalability, security, and compliance requirements while using a
fully managed platform to perform infrastructure maintenance. App Service is a
platform as a service (PaaS) offering.
 Azure Functions (or serverless computing): They are ideal when you're concerned only
about the code running your service and not the underlying platform or infrastructure.
They're commonly used when you need to perform work in response to an event (often
 via a REST request), timer, or message from another Azure service, and when that work
can be completed quickly, within seconds or less.
Decide when to use Azure Virtual Machines –
With Azure Virtual Machines, you can create and use VMs in the cloud. VMs provide
infrastructure as a service (IaaS) in the form of a virtualized server and can be used in many
ways. Just like a physical computer, you can customize all of the software running on the VM.
VMs are an ideal choice when you need:
 Total control over the operating system (OS).
 The ability to run custom software.
 To use custom hosting configurations.
An Azure VM gives you the flexibility of virtualization without having to buy and maintain the
physical hardware that runs the VM. You still need to configure, update, and maintain the
software that runs on the VM.
You can create and provision a VM in minutes when you select a preconfigured VM image.
Selecting an image is one of the most important decisions you'll make when you create a VM.
An image is a template used to create a VM. These templates already include an OS and often
other software, like development tools or web hosting environments.
Examples of when to use VMs –
 During testing and development. VMs provide a quick and easy way to create different
OS and application configurations. Test and development personnel can then easily
delete the VMs when they no longer need them.
 When running applications in the cloud. The ability to run certain applications in the
public cloud as opposed to creating a traditional infrastructure to run them can provide
substantial economic benefits. For example, an application might need to handle
fluctuations in demand. Shutting down VMs when you don't need them or quickly
starting them up to meet a sudden increase in demand means you pay only for the
resources you use.
 When extending your datacenter to the cloud. An organization can extend the
capabilities of its own on-premises network by creating a virtual network in Azure and
adding VMs to that virtual network. Applications like SharePoint can then run on an
Azure VM instead of running locally. This arrangement makes it easier or less expensive
to deploy than in an on-premises environment.
 During disaster recovery. As with running certain types of applications in the cloud and
extending an on-premises network to the cloud, you can get significant cost savings by
using an IaaS-based approach to disaster recovery. If a primary datacenter fails, you can
create VMs running on Azure to run your critical applications and then shut them down
when the primary datacenter becomes operational again.
Move to the cloud with VMs –
VMs are also an excellent choice when you move from a physical server to the cloud (also
known as lift and shift). You can create an image of the physical server and host it within a VM
with little or no changes. Just like a physical on-premises server, you must maintain the VM.
You update the installed OS and the software it runs.
Scale VMs in Azure –
You can run single VMs for testing, development, or minor tasks. Or you can group VMs
together to provide high availability, scalability, and redundancy. No matter what your uptime
requirements are, Azure has several features that can meet them. These features include:
 Virtual machine scale sets: Virtual machine scale sets let you create and manage a
group of identical, load balanced VMs. Scale sets allow you to centrally manage,
configure, and update a large number of VMs in minutes to provide highly available
applications. The number of VM instances can automatically increase or decrease in
response to demand or a defined schedule. With virtual machine scale sets, you can
build large-scale services for areas such as compute, big data, and container workloads.
 Azure Batch: Azure Batch enables large-scale parallel and high-performance computing
(HPC) batch jobs with the ability to scale to tens, hundreds, or thousands of VMs. When
you're ready to run a job, Batch does the following:
 Starts a pool of compute VMs for you.
 Installs applications and staging data.
 Runs jobs with as many tasks as you have.
 Identifies failures.
 Requeues work.
 Scales down the pool as work completes.
There might be situations in which you need raw computing power or supercomputer-
level compute power. Azure provides these capabilities.
Decide when to use Azure App Service –
App Service enables you to build and host web apps, background jobs, mobile back-ends, and
RESTful APIs in the programming language of your choice without managing infrastructure. It
offers automatic scaling and high availability. App Service supports Windows and Linux and
enables automated deployments from GitHub, Azure DevOps, or any GIT repo to support a
continuous deployment model. This platform as a service (PaaS) environment allows you to
focus on the website and API logic while Azure handles the infrastructure to run and scale your
web applications.
App Service handles most of the infrastructure decisions you deal with in hosting web-
accessible apps:
 Deployment and management are integrated into the platform.
 Endpoints can be secured.
 Sites can be scaled quickly to handle high traffic loads.
 The built-in load balancing and traffic manager provide high availability.
Azure App Service costs –
You pay for the Azure compute resources your app uses while it processes requests based on
the App Service plan you choose. The App Service plan determines how much hardware is
devoted to your host. For example, the plan determines whether it's dedicated or shared
hardware and how much memory is reserved for it. There's even a free tier you can use to host
small, low-traffic sites.
Types of app services –
With App Service, you can host most common app service styles like:
  Web apps: App Service includes full support for hosting web apps by using ASP.NET,
ASP.NET Core, Java, Ruby, Node.js, PHP, or Python. You can choose either Windows or
Linux as the host operating system.
 API apps: Much like hosting a website, you can build REST-based web APIs by using your
choice of language and framework. You get full Swagger support and the ability to
package and publish your API in Azure Marketplace. The produced apps can be
consumed from any HTTP- or HTTPS-based client.
 WebJobs: You can use the WebJobs feature to run a program (.exe, Java, PHP, Python,
or Node.js) or script (.cmd, .bat, PowerShell, or Bash) in the same context as a web app,
API app, or mobile app. They can be scheduled or run by a trigger. WebJobs are often
used to run background tasks as part of your application logic.
 Mobile apps: Use the Mobile Apps feature of App Service to quickly build a back end for
iOS and Android apps. With just a few clicks in the Azure portal, you can:
 Store mobile app data in a cloud-based SQL database.
 Authenticate customers against common social providers, such as MSA, Google,
Twitter, and Facebook.
 Send push notifications.
 Execute custom back-end logic in C# or Node.js.
On the mobile app side, there's SDK support for native iOS and Android, Xamarin, and
React native apps.
All of these app styles are hosted in the same infrastructure and share these benefits. This
flexibility makes App Service the ideal choice to host web-oriented applications.
Decide when to use Azure Container Instances or Azure Kubernetes Service –
Containers are a virtualization environment. Much like running multiple virtual machines on a
single physical host, you can run multiple containers on a single physical or virtual host. Unlike
virtual machines, you don't manage the operating system for a container. Virtual machines
appear to be an instance of an operating system that you can connect to and manage, but
containers are lightweight and designed to be created, scaled out, and stopped dynamically.
While it's possible to create and deploy virtual machines as application demand increases,
containers are designed to allow you to respond to changes on demand. With containers, you
can quickly restart in case of a crash or hardware interruption. One of the most popular
container engines is Docker, which is supported by Azure.
Manage containers –
Containers are managed through a container orchestrator, which can start, stop, and scale out
application instances as needed. There are two ways to manage both Docker and Microsoft-
based containers in Azure:
 Azure Container Instances: It offers the fastest and simplest way to run a container in
Azure without having to manage any virtual machines or adopt any additional services.
It's a platform as a service (PaaS) offering that allows you to upload your containers,
which it runs for you.
 Azure Kubernetes Service (AKS): The task of automating, managing, and interacting
with a large number of containers is known as orchestration. Azure Kubernetes Service
is a complete orchestration service for containers with distributed architectures and
large volumes of containers.
Use containers in your solutions –
Containers are often used to create solutions by using a microservice architecture. This
architecture is where you break solutions into smaller, independent pieces. For example, you
might split a website into a container hosting your front end, another hosting your back end,
and a third for storage. This split allows you to separate portions of your app into logical
sections that can be maintained, scaled, or updated independently.
Imagine your website back-end has reached capacity but the front end and storage aren't being
stressed. You could:
 Scale the back end separately to improve performance.
 Decide to use a different storage service.
 Replace the storage container without affecting the rest of the application.
Decide when to use Azure Functions –
Serverless computing is the abstraction of servers, infrastructure, and operating systems. With
serverless computing, Azure takes care of managing the server infrastructure and the allocation
and deallocation of resources based on demand. Infrastructure isn't your responsibility. Scaling
and performance are handled automatically. You're billed only for the exact resources you use.
There's no need to even reserve capacity. Serverless computing includes:
 Abstraction of servers: Serverless computing abstracts the servers you run on. You
never explicitly reserve server instances. The platform manages that for you. Each
function execution can run on a different compute instance. This execution context is
transparent to the code. With serverless architecture, you deploy your code, which then
runs with high availability.
 Event-driven scale: Serverless computing is an excellent fit for workloads that respond
to incoming events. Events include triggers by: Timers, for example, if a function needs
to run every day at 10:00 AM UTC, HTTP, for example, API and webhook scenarios,
Queues, for example, with order processing and much more.
Instead of writing an entire application, the developer authors a function, which
contains both code and metadata about its triggers and bindings. The platform
automatically schedules the function to run and scales the number of compute
instances based on the rate of incoming events. Triggers define how a function is
invoked. Bindings provide a declarative way to connect to services from within the code.
 Micro-billing: Traditional computing bills for a block of time like paying a monthly or
annual rate for website hosting. This method of billing is convenient but isn't always cost
effective. Even if a customer's website gets only one hit a day, they still pay for a full
day's worth of availability. With serverless computing, they pay only for the time their
code runs. If no active function executions occur, they're not charged. For example, if
the code runs once a day for two minutes, they're charged for one execution and two
minutes of computing time.
Azure has two implementations of serverless compute:
 Azure Functions: Functions can execute code in almost any modern language. Functions
can be either stateless or stateful. When they're stateless (the default), they behave as if
they're restarted every time they respond to an event. When they're stateful (called
Durable Functions), a context is passed through the function to track prior activity.
 Functions are a key component of serverless computing. They're also a general compute
platform for running any type of code. If the needs of the developer's app change, you
can deploy the project in an environment that isn't serverless. This flexibility allows you
to manage scaling, run on virtual networks, and even completely isolate the functions.
 Azure Logic Apps: Logic apps are designed in a web-based designer and can execute
logic triggered by Azure services without writing any code. Logic apps are similar to
functions. Both enable you to trigger logic based on an event. Where functions execute
code, logic apps execute workflows that are designed to automate business scenarios
and are built from predefined logic blocks.
Every Azure logic app workflow starts with a trigger, which fires when a specific event
happens or when newly available data meets specific criteria. Many triggers include
basic scheduling capabilities, so developers can specify how regularly their workloads
will run. Each time the trigger fires, the Logic Apps engine creates a logic app instance
that runs the actions in the workflow. These actions can also include data conversions
and flow controls, such as conditional statements, switch statements, loops, and
branching.
You create logic app workflows by using a visual designer on the Azure portal or in
Visual Studio. The workflows are persisted as a JSON file with a known workflow
schema.
Azure provides more than 200 different connectors and processing blocks to interact
with different services. These resources include the most popular enterprise apps. You
can also build custom connectors and workflow steps if the service you need to interact
with isn't covered. You then use the visual designer to link connectors and blocks
together. You pass data through the workflow to do custom processing, often all
without writing any code.
Functions vs. Logic Apps –
Functions and Logic Apps can both create complex orchestrations. An orchestration is a
collection of functions or steps that are executed to accomplish a complex task. You can mix
and match services when you build an orchestration, calling functions from logic apps and
calling logic apps from functions. Here are some common differences between the two:
Functions Logic Apps
Normally stateless, but Durable
State Stateful.
Functions provide state.
Development Code-first (imperative). Designer-first (declarative).
About a dozen built-in binding Large collection of connectors.
Connectivity types. Write code for custom Enterprise Integration Pack for B2B
bindings. scenarios. Build custom connectors.
Each activity is an Azure function. Large collection of ready-made
Actions
Write code for activity functions. actions.
Monitoring Azure Application Insights. Azure portal, Log Analytics.
Azure portal, REST API, PowerShell,
Management REST API, Visual Studio.
Visual Studio.
Execution Can run locally or in the cloud. Runs only in the cloud.
 Context
Decide when to use Azure Virtual Desktop –
Azure Virtual Desktop is a desktop and application virtualization service that runs on the cloud.
It enables your users to use a cloud-hosted version of Windows from any location. Azure Virtual
Desktop works across devices like Windows, Mac, iOS, Android, and Linux. It works with apps
that you can use to access remote desktops and apps. You can also use most modern browsers
to access Azure Virtual Desktop-hosted experiences.
Why should you use Azure Virtual Desktop? –
 Provide the best user experience: Users have the freedom to connect to Azure Virtual
Desktop with any device over the internet. They use Azure Virtual Desktop client to
connect to their published Windows desktop and applications. This client could either
be a native application on the device or the Azure Virtual Desktop HTML5 web client.
You can make sure your session host virtual machines (VMs) run near apps and services
that connect to your datacenter or the cloud. This way your users stay productive and
don't encounter long load times.
User sign-in to Azure Virtual Desktop is fast because user profiles are containerized by
using FSLogix. At sign-in, the user profile container is dynamically attached to the
computing environment. The user profile is immediately available and appears in the
system exactly like a native user profile.
You can provide individual ownership through personal (persistent) desktops. For
example, you might want to provide personal remote desktops for members of an
engineering team. Then they can add or remove programs without impacting other
users on that remote desktop.
 Enhance Security: Azure Virtual Desktop provides centralized security management for
users' desktops with Azure Active Directory (Azure AD). You can enable multifactor
authentication to secure user sign-ins. You can also secure access to data by assigning
granular role-based access controls (RBACs) to users.
With Azure Virtual Desktop, the data and apps are separated from the local hardware.
Azure Virtual Desktop runs them instead on a remote server. The risk of confidential
data being left on a personal device is reduced.
User sessions are isolated in both single and multi-session environments.
Azure Virtual Desktop also improves security by using reverse connect technology. This
connection type is more secure than the Remote Desktop Protocol. We don't open
inbound ports to the session host VMs.
Key features of Azure Virtual Desktop –
 Simplified management: Azure Virtual Desktop is an Azure service, so it will be familiar
to Azure administrators. You use Azure AD and RBACs to manage access to resources.
With Azure, you also get tools to automate VM deployments, manage VM updates, and
provide disaster recovery. As with other Azure services, Azure Virtual Desktop uses
Azure Monitor for monitoring and alerts. This standardization lets admins identify issues
through a single interface.
 Performance management: Azure Virtual Desktop gives you options to load balance
users on your VM host pools. Host pools are collections of VMs with the same
 configuration assigned to multiple users. For the best performance, you can configure
load balancing to occur as users sign in (breadth mode). With breadth mode, users are
sequentially allocated across the host pool for your workload. To save costs, you can
configure your VMs for depth mode load balancing where users are fully allocated on
one VM before moving to the next. Azure Virtual Desktop provides tools to
automatically provision additional VMs when incoming demand exceeds a specified
threshold.
 Multi-session Windows 10 deployment: Azure Virtual Desktop lets you use Windows 10
Enterprise multi-session, the only Windows client-based operating system that enables
multiple concurrent users on a single VM. Azure Virtual Desktop also provides a more
consistent experience with broader application support compared to Windows Server-
based operating systems.
Reduce costs with Azure Virtual Desktop –
 Bring your own licenses: Azure Virtual Desktop is available to you at no additional cost if
you have an eligible Microsoft 365 license. Just pay for the Azure resources used by
Azure Virtual Desktop.
 Bring your eligible Windows or Microsoft 365 license to get Windows 10
Enterprise and Windows 7 Enterprise desktops and apps at no additional cost.
 If you're an eligible Microsoft Remote Desktop Services Client Access License
customer, Windows Server Remote Desktop Services desktops and apps are
available at no additional cost.
 Save on compute costs: Buy one-year or three-year Azure Reserved Virtual Machine
Instances to save you up to 72 percent versus pay-as-you-go pricing. You can pay for a
reservation up front or monthly. Reservations provide a billing discount and don't affect
the runtime state of your resources.

Explore Azure networking services

Azure virtual networking –
Azure virtual networks enable Azure resources, such as VMs, web apps, and databases, to
communicate with each other, with users on the internet, and with your on-premises client
computers. You can think of an Azure network as a set of resources that links other Azure
resources. Azure virtual networks provide the following key networking capabilities:
 Isolation and segmentation: Virtual Network allow you to create multiple isolated
virtual networks. When you set up a virtual network, you define a private IP address
space by using either public or private IP address ranges. You can divide that IP address
space into subnets and allocate part of the defined address space to each named
subnet.
 For name resolution, you can use the name resolution service that's built into Azure.
You also can configure the virtual network to use either an internal or an external DNS
server.
 Internet communications: A VM in Azure can connect to the internet by default. You
can enable incoming connections from the internet by defining a public IP address or a
public load balancer. For VM management, you can connect via the Azure CLI, Remote
Desktop Protocol, or Secure Shell.
 Communicate between Azure resources: You'll want to enable Azure resources to
communicate securely with each other. You can do that in one of two ways:
 Virtual networks can connect not only VMs but other Azure resources, such as
the App Service Environment for Power Apps, Azure Kubernetes Service, and
Azure virtual machine scale sets.
 Service endpoints You can use service endpoints to connect to other Azure
resource types, such as Azure SQL databases and storage accounts. This
approach enables you to link multiple Azure resources to virtual networks to
improve security and provide optimal routing between resources.
 Communicate with on-premises resources: Azure virtual networks enable you to link
resources together in your on-premises environment and within your Azure
subscription. In effect, you can create a network that spans both your local and cloud
environments. There are three mechanisms for you to achieve this connectivity:
 Point-to-site virtual private networks – The typical approach to a virtual private
network (VPN) connection is from a computer outside your organization, back
into your corporate network. In this case, the client computer initiates an
encrypted VPN connection to connect that computer to the Azure virtual
network.
 Site-to-site virtual private networks – A site-to-site VPN links your on-premises
VPN device or gateway to the Azure VPN gateway in a virtual network. In effect,
the devices in Azure can appear as being on the local network. The connection is
encrypted and works over the internet.
 Azure ExpressRoute – For environments where you need greater bandwidth and
even higher levels of security, Azure ExpressRoute is the best approach.
ExpressRoute provides dedicated private connectivity to Azure that doesn't
travel over the internet.
 Route network traffic: By default, Azure routes traffic between subnets on any
connected virtual networks, on-premises networks, and the internet. You also can
control routing and override those settings, as follows:
 Route tables – A route table allows you to define rules about how traffic should
be directed. You can create custom route tables that control how packets are
routed between subnets.
 Border Gateway Protocol (BGP) works with Azure VPN gateways or ExpressRoute
to propagate on-premises BGP routes to Azure virtual networks.
 Filter network traffic: Azure virtual networks enable you to filter traffic between
subnets by using the following approaches:
  Network security groups – A network security group is an Azure resource that
can contain multiple inbound and outbound security rules. You can define these
rules to allow or block traffic, based on factors such as source and destination IP
address, port, and protocol.
 Network virtual appliances – A network virtual appliance is a specialized VM that
can be compared to a hardened network appliance. A network virtual appliance
carries out a particular network function, such as running a firewall or
performing wide area network (WAN) optimization.
 Connect virtual networks: You can link virtual networks together by using virtual
network peering. Peering enables resources in each virtual network to communicate
with each other. These virtual networks can be in separate regions, which allows you to
create a global interconnected network through Azure.
UDR is user-defined Routing. UDR is a significant update to Azure’s Virtual Networks as
this allows network admins to control the routing tables between subnets within a
VNet, as well as between VNets, thereby allowing for greater control over network
traffic flow.

Azure Virtual Network settings –

When you create an Azure virtual network, you configure a number of basic settings and
advanced settings. You'll configure the following settings for a basic virtual network:
 Network name: The network name must be unique in your subscription, but it doesn't
need to be globally unique. Make the name a descriptive one that's easy to remember
and identified from other virtual networks.
 Address space: When you set up a virtual network, you define the internal address
space in Classless Interdomain Routing (CIDR) format. This address space needs to be
unique within your subscription and any other networks that you connect to. Let's
assume you choose an address space of 10.0.0.0/24 for your first virtual network. The
addresses defined in this address space range from 10.0.0.1 to 10.0.0.254. You then
create a second virtual network and choose an address space of 10.0.0.0/8. The
addresses in this address space range from 10.0.0.1 to 10.255.255.254. Some of the
addresses overlap and can't be used for the two virtual networks. But you can use
10.0.0.0/16, with addresses that range from 10.0.0.1 to 10.0.255.254, and 10.1.0.0/16,
with addresses that range from 10.1.0.1 to 10.1.255.254. You can assign these address
spaces to your virtual networks because there's no address overlap. You can add
address spaces after you create the virtual network.
  Subscription: This option only applies if you have multiple subscriptions to choose from.
 Resource group: Like any other Azure resource, a virtual network needs to exist in a
resource group. You can either select an existing resource group or create a new one.
 Location: Select the location where you want the virtual network to exist.
 Subnet: Within each virtual network address range, you can create one or more subnets
that partition the virtual network's address space. Routing between subnets will then
depend on the default traffic routes. You also can define custom routes. Alternatively,
you can define one subnet that encompasses all the virtual networks' address ranges.
Subnet names must begin with a letter or number and end with a letter, number, or
underscore. They may contain only letters, numbers, underscores, periods, or hyphens.
 DDoS protection: You can select either Basic or Standard DDoS protection. Standard
DDoS protection is a premium service.
 Service endpoints: Here, you enable service endpoints. Then you select from the list
which Azure service endpoints you want to enable. Options include Azure Cosmos DB,
Azure Service Bus, Azure Key Vault, and so on.
After you've configured these settings, select Create.
Define additional settings –
After you create a virtual network, you can then define further settings. These include:
 Network security group: Network security groups have security rules that enable you to
filter the type of network traffic that can flow in and out of virtual network subnets and
network interfaces. You create the network security group separately. Then you
associate it with the virtual network.
 Route table: Azure automatically creates a route table for each subnet within an Azure
virtual network and adds system default routes to the table. You can add custom route
tables to modify traffic between virtual networks.
You can also amend the service endpoints.
Configure virtual networks –
After you've created a virtual network, you can change any further settings on the Virtual
network pane in the Azure portal. Alternatively, you can use PowerShell commands or
commands in Cloud Shell to make changes. You can then review and change settings in further
subpanel. These settings include:
 Address spaces: You can add additional address spaces to the initial definition.
 Connected devices: Use the virtual network to connect machines.
 Subnets: You can add additional subnets.
 Peerings: Link virtual networks in peering arrangements.
You can also monitor and troubleshoot virtual networks. Or you can create an automation
script to generate the current virtual network.
Virtual networks are powerful and highly configurable mechanisms for connecting entities in
Azure. You can connect Azure resources to one another or to resources you have on-premises.
You can isolate, filter, and route your network traffic. Azure allows you to increase security
where you feel you need it.
Azure VPN Gateway fundamentals –
VPNs use an encrypted tunnel within another network. They're typically deployed to connect
two or more trusted private networks to one another over an untrusted network (typically the
public internet). Traffic is encrypted while traveling over the untrusted network to prevent
eavesdropping or other attacks.
VPN gateways –
A VPN gateway is a type of virtual network gateway. Azure VPN Gateway instances are
deployed in Azure Virtual Network instances and enable the following connectivity:
 Connect on-premises datacenters to virtual networks through a site-to-site connection.
 Connect individual devices to virtual networks through a point-to-site connection.
 Connect virtual networks to other virtual networks through a network-to-network
connection.
All transferred data is encrypted in a private tunnel as it crosses the internet. You can deploy
only one VPN gateway in each virtual network, but you can use one gateway to connect to
multiple locations, which includes other virtual networks or on-premises datacenters.
When you deploy a VPN gateway, you specify the VPN type: either policy-based or route-
based. The main difference between these two types of VPNs is how traffic to be encrypted is
specified. In Azure, both types of VPN gateways use a pre-shared key as the only method of
authentication. Both types also rely on Internet Key Exchange (IKE) in either version 1 or version
2 and Internet Protocol Security (IPSec). IKE is used to set up a security association (an
agreement of the encryption) between two endpoints. This association is then passed to the
IPSec suite, which encrypts and decrypts data packets encapsulated in the VPN tunnel.
Policy-based VPNs –
Policy-based VPN gateways specify statically the IP address of packets that should be encrypted
through each tunnel. This type of device evaluates every data packet against those sets of IP
addresses to choose the tunnel where that packet is going to be sent through. Key features of
policy-based VPN gateways in Azure include:
 Support for IKEv1 only.
 Use of static routing, where combinations of address prefixes from both networks
control how traffic is encrypted and decrypted through the VPN tunnel. The source and
destination of the tunneled networks are declared in the policy and don't need to be
declared in routing tables.
 Policy-based VPNs must be used in specific scenarios that require them, such as for
compatibility with legacy on-premises VPN devices.
Route-based VPNs –
If defining which IP addresses are behind each tunnel is too cumbersome, route-based
gateways can be used. With route-based gateways, IPSec tunnels are modeled as a network
interface or virtual tunnel interface. IP routing (either static routes or dynamic routing
protocols) decides which one of these tunnel interfaces to use when sending each packet.
Route-based VPNs are the preferred connection method for on-premises devices. They're more
resilient to topology changes such as the creation of new subnets. Use a route-based VPN
gateway if you need any of the following types of connectivity:
 Connections between virtual networks
 Point-to-site connections
 Multisite connections
 Coexistence with an Azure ExpressRoute gateway
Key features of route-based VPN gateways in Azure include:
  Supports IKEv2
 Uses any-to-any (wildcard) traffic selectors
 Can use dynamic routing protocols, where routing/forwarding tables direct traffic to
different IPSec tunnels. In this case, the source and destination networks aren't statically
defined as they are in policy-based VPNs or even in route-based VPNs with static
routing. Instead, data packets are encrypted based on network routing tables that are
created dynamically using routing protocols such as Border Gateway Protocol (BGP).
VPN gateway sizes –
The capabilities of your VPN gateway are determined by the SKU or size that you deploy. This
table shows the main capabilities of each available SKU.
Aggregate
Site-to-site/Network-to- Border Gateway
SKU throughput
network tunnels Protocol support
benchmark
Basic Maximum: 10 100 Mbps Not supported
VpnGw1/Az Maximum: 30 650 Mbps Supported
VpnGw2/Az Maximum: 30 1 Gbps Supported
VpnGw3/Az Maximum: 30 1.25 Gbps Supported
A Basic VPN gateway should only be used for Dev/Test workloads. In addition, it's unsupported
to migrate from Basic to the VpnGW1/2/3/Az SKUs at a later time without having to remove the
gateway and redeploy.
Deploy VPN gateways –
Before you can deploy a VPN gateway, you'll need some Azure and on-premises resources.
Required Azure resources: You'll need these Azure resources before you can deploy an
operational VPN gateway –
 Virtual network. Deploy a virtual network with enough address space for the additional
subnet that you'll need for the VPN gateway. The address space for this virtual network
must not overlap with the on-premises network that you'll be connecting to. You can
deploy only one VPN gateway within a virtual network.
 Gateway Subnet. Deploy a subnet called Gateway Subnet for the VPN gateway. Use at
least a /27 address mask to make sure you have enough IP addresses in the subnet for
future growth. You can't use this subnet for any other services.
 Public IP address. Create a Basic-SKU dynamic public IP address if you're using a non-
zone-aware gateway. This address provides a public-routable IP address as the target for
your on-premises VPN device. This IP address is dynamic, but it won't change unless you
delete and re-create the VPN gateway.
 Local network gateway. Create a local network gateway to define the on-premises
network's configuration, such as where the VPN gateway will connect and what it will
connect to. This configuration includes the on-premises VPN device's public IPv4 address
and the on-premises routable networks. This information is used by the VPN gateway to
route packets that are destined for on-premises networks through the IPSec tunnel.
 Virtual network gateway. Create the virtual network gateway to route traffic between
the virtual network and the on-premises datacenter or other virtual networks. The
virtual network gateway can be either a VPN or ExpressRoute gateway, but this unit only
 deals with VPN virtual network gateways. (You'll learn more about ExpressRoute in a
separate unit later in this module.)
 Connection. Create a connection resource to create a logical connection between the
VPN gateway and the local network gateway. You can create multiple connections.
 Connection is made to the on-premises VPN device's IPv4 address as defined by
the local network gateway.
 Connection is made from the virtual network gateway and its associated public
IP address.
The following diagram shows this combination of resources
and their relationships to help you better understand what's
required to deploy a VPN gateway:
Required on-premises resources: To connect your datacenter
to a VPN gateway, you'll need these on-premises resources:
 A VPN device that supports policy-based or route-
based VPN gateways
 A public-facing (internet-routable) IPv4 address
High-availability scenarios –
There are several ways to ensure you have a fault-tolerant configuration.
Active/standby: By default, VPN gateways are deployed as two instances in an active/standby
configuration, even if you only see one VPN gateway resource in Azure. When planned
maintenance or unplanned disruption affects the active instance, the standby instance
automatically assumes responsibility for connections without any user intervention.
Connections are interrupted during this failover, but they're typically restored within a few
seconds for planned maintenance and within 90 seconds for unplanned disruptions.
Active/active: With the introduction of support for the BGP routing protocol, you can also
deploy VPN gateways in an active/active configuration. In this configuration, you assign a
unique public IP address to each instance. You then create separate tunnels from the on-
premises device to each IP address. You can extend the high availability by deploying an
additional VPN device on-premises.
ExpressRoute failover: Another high-availability option is to configure a VPN gateway as a
secure failover path for ExpressRoute connections. ExpressRoute circuits have resiliency built in.
But they aren't immune to physical problems that affect the cables delivering connectivity or
outages that affect the complete ExpressRoute location. In high-availability scenarios, where
there's risk associated with an outage of an ExpressRoute circuit, you can also provision a VPN
gateway that uses the internet as an alternative method of connectivity. In this way, you can
ensure there's always a connection to the virtual networks.
Zone-redundant gateways –
In regions that support availability zones, VPN gateways and ExpressRoute gateways can be
deployed in a zone-redundant configuration. This configuration brings resiliency, scalability, and
higher availability to virtual network gateways. Deploying gateways in Azure availability zones
physically and logically separates gateways within a region while protecting your on-premises
network connectivity to Azure from zone-level failures. These gateways require different
gateway SKUs and use Standard public IP addresses instead of Basic public IP addresses.
Azure ExpressRoute fundamentals –
ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a
private connection with the help of a connectivity provider. With ExpressRoute, you can
establish connections to Microsoft cloud services, such as Microsoft Azure and Microsoft 365.
ExpressRoute connections don't go over the public Internet. This allows ExpressRoute
connections to offer more reliability, faster speeds, consistent latencies, and higher security
than typical connections over the Internet.
Throughout this unit, we'll focus on two different layers of the Open Systems Interconnection
(OSI) model:
 Layer 2 (L2): This layer is the Data Link Layer, which provides node-to-node
communication between two nodes on the same network.
 Layer 3 (L3): This layer is the Network Layer, which provides addressing and routing
between nodes on a multi-node network.
Features and benefits of ExpressRoute –
 Layer 3 connectivity between your on-premises network and the Microsoft Cloud
through a connectivity provider. Connectivity can be from an any-to-any (IPVPN)
network, a point-to-point Ethernet connection, or through a virtual cross-connection via
an Ethernet exchange.
 Connectivity to Microsoft cloud services across all regions in the geopolitical region.
ExpressRoute enables direct access to the following services in all regions: Microsoft
Office 365, Microsoft Dynamics 365, Azure compute services, such as Azure Virtual
Machines, Azure cloud services, such as Azure Cosmos DB and Azure Storage.
 Global connectivity to Microsoft services across all regions with the ExpressRoute
premium add-on (ExpressRoute Global Reach).
 Dynamic routing between your network and Microsoft via Border Gateway Protocol
(BGP).
 Built-in redundancy in every peering location for higher reliability. You can configure
multiple circuits to complement this feature. All redundant connections are configured
with Layer 3 connectivity to meet service-level agreements.
 Connection uptime SLA.
 QoS support for Skype for Business.
ExpressRoute connectivity models –
ExpressRoute supports three models that you can use to connect your on-premises network to
the Microsoft cloud:
 CloudExchange colocation: Collocated providers can normally offer both Layer 2 and
Layer 3 connections between your infrastructure, which might be located in the
colocation facility, and the Microsoft cloud. For example, if your datacenter is collocated
at a cloud exchange such as an ISP, you can request a virtual cross-connection to the
Microsoft cloud.
 Point-to-point Ethernet connection: Point-to-point connections provide Layer 2 and
Layer 3 connectivity between your on-premises site and Azure. You can connect your
offices or datacenters to Azure by using the point-to-point links. For example, if you
have an on-premises datacenter, you can use a point-to-point Ethernet link to connect
to Microsoft.
  Any-to-any connection: With any-to-any connectivity, you can integrate your wide area
network (WAN) with Azure by providing connections to your offices and datacenters.
Azure integrates with your WAN connection to provide a connection like you would
have between your datacenter and any branch offices.
With any-to-any connections, all WAN providers offer Layer 3 connectivity. For example,
if you already use Multiprotocol Label Switching to connect to your branch offices or
other sites in your organization, an ExpressRoute connection to Microsoft behaves like
any other location on your private WAN.
Security considerations –
With ExpressRoute, your data doesn't travel over the public internet, so it's not exposed to the
potential risks associated with internet communications. ExpressRoute is a private connection
from your on-premises infrastructure to your Azure infrastructure. Even if you have an
ExpressRoute connection, DNS queries, certificate revocation list checking, and Azure Content
Delivery Network requests are still sent over the public internet.
Explore Azure Storage services
To begin using Azure Storage, you first create an Azure Storage account to store your data
objects. You can create an Azure Storage account by using the Azure portal, PowerShell, or the
Azure CLI. Your storage account will contain all of your Azure Storage data objects, such as
blobs, files, and disks. Azure VMs use Azure Disk Storage to store virtual disks. However, you
can't use Azure Disk Storage to store a disk outside of a virtual machine. A storage account
provides a unique namespace for your Azure Storage data, that's accessible from anywhere in
the world over HTTP or HTTPS. Data in this account is secure, highly available, durable, and
massively scalable.
Disk storage fundamentals –
Disk Storage provides disks for Azure virtual machines. Applications and other services can
access and use these disks as needed, similar to how they would in on-premises scenarios. Disk
Storage allows data to be persistently stored and accessed from an attached virtual hard disk.
Disks come in many different sizes and performance levels, from solid-state drives (SSDs) to
traditional spinning hard disk drives (HDDs), with varying performance tiers. You can use
standard SSD and HDD disks for less critical workloads, premium SSD disks for mission-critical
production applications, and ultra-disks for data-intensive workloads such as SAP HANA, top
tier databases, and transaction-heavy workloads. Azure has consistently delivered enterprise-
grade durability for infrastructure as a service (IaaS) disks, with an industry-leading ZERO%
annualized failure rate.
Azure Blob storage fundamentals –
Azure Blob Storage is an object storage solution for the cloud. It can store massive amounts of
data, such as text or binary data. Azure Blob Storage is unstructured, meaning that there are no
restrictions on the kinds of data it can hold. Blob Storage can manage thousands of
simultaneous uploads, massive amounts of video data, constantly growing log files, and can be
reached from anywhere with an internet connection.
Blobs aren't limited to common file formats. A blob could contain gigabytes of binary data
streamed from a scientific instrument, an encrypted message for another application, or data in
a custom format for an app you're developing. One advantage of blob storage over disk storage
is that it does not require developers to think about or manage disks; data is uploaded as blobs,
and Azure takes care of the physical storage needs. Blob Storage is ideal for:
 Serving images or documents directly to a browser.
  Storing files for distributed access.
 Streaming video and audio.
 Storing data for backup and restore, disaster recovery, and archiving.
 Storing data for analysis by an on-premises or Azure-hosted service.
 Storing up to 8 TB of data for virtual machines.
You store blobs in containers, which helps you organize your blobs depending on your business
needs.
Azure Files fundamentals –
Azure Files offers fully managed file shares in the cloud that are accessible via the industry
standard Server Message Block and Network File System (preview) protocols. Azure file shares
can be mounted concurrently by cloud or on-premises deployments of Windows, Linux, and
macOS. Applications running in Azure virtual machines or cloud services can mount a file
storage share to access file data, just as a desktop application would mount a typical SMB
share. Any number of Azure virtual machines or roles can mount and access the file storage
share simultaneously. Typical usage scenarios would be to share files anywhere in the world,
diagnostic data, or application data sharing. Use Azure Files for the following situations:
 Many on-premises applications use file shares. Azure Files makes it easier to migrate
those applications that share data to Azure. If you mount the Azure file share to the
same drive letter that the on-premises application uses, the part of your application that
accesses the file share should work with minimal changes, if any.
 Store configuration files on a file share and access them from multiple VMs. Tools and
utilities used by multiple developers in a group can be stored on a file share, ensuring
that everybody can find them, and that they use the same version.
 Write data to a file share, and process or analyze the data later. For example, you might
want to do this with diagnostic logs, metrics, and crash dumps.
Azure Files ensures the data is encrypted at rest, and the SMB protocol ensures the data is
encrypted in transit.
One thing that distinguishes Azure Files from files on a corporate file share is that you can
access the files from anywhere in the world, by using a URL that points to the file. You can also
use Shared Access Signature (SAS) tokens to allow access to a private asset for a specific
amount of time.

What is a public endpoint?

Public endpoint for a managed instance enables data access to your managed instance from
outside the virtual network. You are able to access your managed instance from multi-tenant
Azure services like Power BI, Azure App Service, or an on-premises network.

What is a private endpoint?

A private endpoint is a network interface that uses a private IP address from your virtual
network. This network interface connects you privately and securely to a service that's powered
by Azure Private Link. By enabling a private endpoint, you're bringing the service into your
virtual network.
The service could be an Azure service such as:
Azure Storage
Azure Cosmos DB
Azure SQL Database
Your own service, using Private Link service.

Private endpoints are not available for general-purpose v1 storage accounts.

Using private endpoints for your storage account enables you to:

 Secure your storage account by configuring the storage firewall to block all connections
on the public endpoint for the storage service.
 Increase security for the virtual network (VNet), by enabling you to block exfiltration of
data from the VNet.
 Securely connect to storage accounts from on-premises networks that connect to the
VNet using VPN or ExpressRoutes with private-peering.

As you're creating private endpoints, consider the following:

 Private endpoints enable connectivity between the customers from the same:
o Virtual network
o Regionally peered virtual networks
o Globally peered virtual networks
o On-premises environments that use VPN or Express Route
o Services that are powered by Private Link
 Network connections can be initiated only by clients that are connecting to the private
endpoint. Service providers don't have a routing configuration to create connections into
service customers. Connections can be established in a single direction only.
 A read-only network interface is automatically created for the lifecycle of the private
endpoint. The interface is assigned a dynamic private IP address from the subnet that maps
to the private-link resource. The value of the private IP address remains unchanged for the
entire lifecycle of the private endpoint.
 The private endpoint must be deployed in the same region and subscription as the virtual
network.
 The private-link resource can be deployed in a different region than the one for the virtual
network and private endpoint.
 Multiple private endpoints can be created with the same private-link resource. For a single
network using a common DNS server configuration, the recommended practice is to use a
single private endpoint for a specified private-link resource. Use this practice to avoid
duplicate entries or conflicts in DNS resolution.
 Multiple private endpoints can be created on the same or different subnets within the same
virtual network. There are limits to the number of private endpoints you can create in a
subscription. For more information, see Azure limits.
 The subscription from the private-link resource must also be registered with the Microsoft
network resource provider. For more information, see Azure Resource Providers.

What is a service endpoint?

Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure
services over an optimized route over the Azure backbone network. Endpoints allow you to
secure your critical Azure service resources to only your virtual networks. Service Endpoints
enables private IP addresses in the VNet to reach the endpoint of an Azure service without
needing a public IP address on the VNet.