Azure Vocabulary

Published in

Reaching for the Cloud

27 min readAug 12, 2020

Azure Account

Your overall account to start you Azure journey. Also your billing account which allows you see what subscriptions you have billing access to, and see invoices and payment methods.

NOTE: In a corporate set up, it’s likely that you will not have billing access to subscriptions, but will have still have ‘manage Azure resources’ access to Subscriptions.

Tenant

A Tenant refers to a single instance of Azure AD, which is a single place to manage users, groups and the permissions they hold in relation to applications published in Azure AD.

Azure AD Tenants are globally unique, and scoped using a domain that ends with ‘onmicrosoft.com’. However, customers can use a custom domain instead of the default.
When you try to manage Azure resources in a Subscription, you will always be authenticated at some point via the Azure AD Tenant associated with the Subscription.
Azure AD Tenants can be associated with multiple Subscriptions, but a Subscription can only ever be associated with a single Azure AD Tenant at any time.
Customers can choose to connect their internal AD environment to Azure AD to allow single sign-on for their staff.

Azure Subscription

When you sign up, an Azure Subscription is created by default. An Azure subscription is a logical container used to provision resources (VMs, Storage Accounts, Web Apps etc) in Azure. When you create an Azure resource like a VM, you identify the subscription it belongs to. All incurred costs of the resources contained in the Subscription will also roll-up at this level

A Subscription is only ever associated with a single Azure AD Tenant at any time, although, it is possible to grant users outside of this Tenant access.
You can also choose to change the Azure AD Tenant for a Subscription.
Subscriptions have both a display name (which you can change) and a Subscription ID (guid)
Subscriptions are not tied to an Azure Region and as a result can contain resources from any number of Regions.

Resiliency in Azure

Regions & Geographies

A Region is one or more datacenters within a specific geographic location, that are nearby and networked together with a low-latency network, grouped together to form a deployment location for workloads. You will always be asked what Region you wish to deploy a workload to.

A Geography can be used to describe a specific market defined by country borders or geopolitical boundaries(Asia, Europe).

Region Pairs — An Azure Geography typically includes two or more regions that are paired to preserve data residency and compliance requirements. This setup also provides customers with a high availability and fault-tolerant infrastructure designed to withstand complete region failure through their connection to dedicated high-capacity networking infrastructure. Each region in a Region Pair is at least 300 miles away. If a region in a pair was affected by a natural disaster, for instance, services would automatically fail over to the other region in its region pair.
There are a few special Regions that aren’t open to everyone — US Government Regions, the entire German Geography and China. In Australia, in order to access Australia Central 1 and 2 you must undergo a white listing process to gain access.
When you replicate data or services between Regions (or Availability Zones) you will pay an increased charge for either data transfer between Regions/Zones and/or duplicated hosting costs in the secondary Region/Zone. Some services such as Azure Storage and Azure SQL Database provide geo-redundant options where you pay an incremental cost to have your data replicated to the secondary Region.
Once you have deployed a service to a Region you are unable to move it — you have to re-provision it if you need the primary location to be somewhere else.

Availability Zones and Availability Sets

Availability Zones are physically separate datacenters within an Azure Region. Each Availability Zone is made up of one or more datacenters equipped with independent power, cooling, and networking. It is set up to be an isolation boundary. If one zone goes down, the others continue working. Availability Zones are connected through high-speed, private fiber-optic networks.

NOTE: Not every region has support for Availability Zones.

An Availability Set is a logical grouping of two or more VMs that help keep your application available during planned or unplanned maintenance.

Here’s an excellent infographic on Azure Resiliency these concepts.

Scalability in Azure

Azure VM Scale Sets

Azure Virtual Machine Scale Sets let you create and manage a group of identical, load balanced VMs, such that you don’t need to do any additional configuration to route requests between multiple instances of the website. Virtual Machine Scale Sets could do that work for you. Think of it as a smart load balancer that can scale out and down as needed.

Azure Batch

Azure Batch enables large-scale job scheduling and compute management with the ability to scale to tens, hundreds, or thousands of VMs — offering raw computing power or supercomputer level compute power.

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

Azure Compute Services

Virtual machines — Deploy and manage VMs inside an Azure virtual network.
Azure App Service — A managed service for hosting web apps, mobile app back ends, RESTful APIs, or automated business processes.
Functions — A managed FaaS
Azure Batch (see above) — A managed service for running large-scale parallel and high-performance computing (HPC) applications
Azure Container Instances — The fastest and simplest way to run a container in Azure, without having to provision any virtual machines and without having to adopt a higher-level service.
Azure Kubernetes Service (AKS) — A managed Kubernetes service for running containerized applications
Service Fabric — A distributed systems platform that can run in many environments, including Azure or on premises.

Also see: Azure Compute Services Decision Tree

Containers in Azure

Azure Container Instances (ACI)

Azure Container Instances (ACI) offers the fastest and simplest way to run a container in Azure. You don’t have to manage any virtual machines or configure any additional services. It is a PaaS offering that allows you to upload your containers and execute them directly with automatic elastic scale.

Azure Kubernetes Service (AKS)

The task of automating, managing, and interacting with a large number of containers is known as orchestration. Azure Kubernetes Service (AKS) is a complete orchestration service for containers with distributed architectures designed to support multiple containers.

Migrating apps to containers

Convert an existing application to one or more containers and then publish one or more container images to the Azure Container Registry.
Using the Azure portal or the command line, deploy the containers to an AKS cluster.
Control access to access to AKS resources using Azure AD
Access SLA-backed Azure services, such as Azure Database for MySQL via Open Service Broker for Azure (OSBA)
Optionally, AKS is deployed within a virtual network

Azure App Service

An HTTP-based service is a platform as a service (PaaS) that enables you to build and host many types of web-based solutions including web apps, RESTful apis, and mobile backends, without managing infrastructure, allowing you to focus on the website/API logic while Azure handles the infrastructure to run and scale your web applications.

Features

Includes full support for hosting web apps or Apis using ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python. OS: Windows or Linux
API features — includes CORS support for RESTful APIs, and Swagger Use Swagger to generate cross-platform client SDKs
Mobile features — simplifies mobile app scenarios by enabling authentication, offline data sync, push notifications.
WebJobs — These allows you to run a program (.exe) or script (.cmd, .bat) in the same context as the web/API app. WebJobs are often used to run background tasks as part of your application logic. They can be scheduled, or run by a trigger.
Security — endpoints can be secured with Active Directory, Single Sign-On, and OAuth
Integration with virtual networks and ability to run in an isolated and dedicated App Service environment
Authentication — Authenticate customers against common social providers such as MSA, Google, Twitter, and Facebook
Deployment and management are integrated into the platform
Deployment Slots — help reduce downtime and risks for app updates
Scalability — Sites can be scaled quickly to handle high traffic loads
High Availability — built-in load balancing and traffic manager provide high availability

NOTE: Even as Web App and API App are listed as a separate offerings on Azure portal, there is no difference under the hood; they’re the same thing i.e. App Service. The only difference is which icon/name you want that app to be flagged with.

App Service costs

Per-second billing

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, whether it’s dedicated or shared hardware, and how much memory is reserved for it. There is even a free tier you can use to host small, low-traffic sites.

Serverless Computing

Azure has two implementations of serverless compute:

Azure Functions, which can execute code in almost any modern language.
Azure Logic Apps, which are designed in a web-based designer and can execute logic triggered by Azure services without writing any code

Micro-Billing

You incur costs only for the time computing resources are used while your functions / logic apps run. With functions, Azure runs your code when it’s triggered and automatically deallocates resources when the function is finished.

Azure Functions

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.

Azure Functions scale automatically based on demand, so they’re a solid choice when demand is variable.

Azure Functions can be either stateless (the default), where they behave as if they’re restarted every time they respond to an event, or stateful (called “Durable Functions”), where a context is passed through the function to track prior activity.

The WebJobs SDK runtime, a framework that simplifies the task of writing background processing code that runs in Microsoft Azure, is the foundation of Azure Functions.

Azure Logic Apps

Where Functions execute code, Logic Apps execute workflows designed to automate business scenarios and built from predefined logic blocks. Every 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 include data conversions and flow controls, such as conditional statements, switch statements, loops, and branching etc.

You create Logic App workflows 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 over 200 different connectors and processing blocks to interact with different services.
You then use the visual designer to link connectors and blocks together, passing data through the workflow to do custom processing — often all without writing any code.

Azure Functions vs Logic Apps

Similarities

Both offer consumption plan pricing — pay for what you use
Auto-scaling
Event-driven

Differences

Courtesy Adam Marczak’s answer on StackOverflow

If what you’re trying to accomplish can be accomplished using an Azure Function just as easily, then prefer Functions over Logic Apps. The biggest reason to consider Logic Apps is the integration it offers via its 200+ connectors to other apis and services. If you don’t have that need, you’re better off with an Azure Function

With Logic Apps, unlike Functions,

It’s hard to compare diffs via Pull Requests for Logic Apps since its code is a json file representing everything you see in the designer.
Debugging is not possible
It is impossible to swarm
You’re vendor locked
Testing is a pain
do not support deployment slots

Also see

Azure Data Storage Options

Benefits of cloud storage

Automated backup and recovery — mitigate risk of losing data in case of unforeseen failure or interruption
Replication across the globe — protect against any planned or unplanned event
Support for data analytics
Encryption capabilities
Multiple data types — video, text, blobs, relational and nosql data
Data storage on virtual disks — up to 32 TB
Storage tiers — to prioritize access based on frequency of usage

Types of data

Structured data — relational data — schema based
Semi-structured data — don’t fit into tables, rows and columns. Instead, they use tags or keys to organize and provide a hierarchy for the data. Aka NoSql data
Unstructured data — The lack of structure means no restrictions on the kind of data it can hold. Ex: blob storage can hold pdf, images, videos etc

Storage Options in Azure

Azure SQL Database — relational database as a service (DaaS) based on the latest stable version of the Microsoft SQL Server database engine. DaaS means you won’t need to worry about managing the infrastructure behind the databases. Use Azure Database Migration Service to migrate existing SQL Server dbs with minimal downtime.

Azure Cosmos Db — a globally distributed database service, that supports schema-less data, lets you build highly responsive and Always On applications to support constantly changing data i.e. to store data that is updated and maintained by users around the world

Azure Blob Storage — Unstructured. Apps work with blobs in much the same way as reading/writing data from files on disk.

Blobs are highly scalable. Common use cases: Supporting thousands of simultaneous uploads, streaming large audio/video files directly to user’s browser, constantly growing log files, storing data for backup, data recovery, and archiving. It has the ability to store up to 8 TB of data for virtual machines.

Azure offers 3 storage tiers for blob object storage:

Hot — optimized for storing data that is accessed frequently.
Cool — optimized for data that are infrequently accessed and stored for at least 30 days.
Archive — for data that are rarely accessed and stored for at least 180 days with flexible latency requirements.

Azure Data Lake Storage — Data Lake is a large repository storing both structured and unstructured data. Data Lakes allow you to perform analytics on your data usage and prepare reports. Azure Data Lake Storage combines the scalability and cost benefits of object storage with the reliability and performance of the Big Data file system capabilities.

Azure Files — fully managed file shares in the cloud that are accessible via the industry standard Server Message Block (SMB) protocol. Azure file shares can be mounted concurrently by cloud or on-premises deployments of Windows, Linux, and macOS. Any number of Azure virtual machines or roles can mount and access the file storage share simultaneously.

Azure Queues — A service for storing large numbers of messages that can be accessed from anywhere in the world. Azure Queue Storage allow application components to be decoupled by providing asynchronous message queueing for communication and thus allowing them to be scaled independently. You can use queue storage to:

Create a backlog of work and to pass messages between different Azure web servers.
Distribute load among different web servers/infrastructure and to manage bursts of traffic.
Build resilience against component failure when multiple users access your data at the same time

Disk Storage — Disk storage provides disks for virtual machines, applications, and other services to store data persistently and access from an attached virtual hard disk. The disks can be managed or unmanaged by Azure. Typical scenarios for using disk storage are if you want to lift and shift applications that read and write data to persistent disks, or if you are storing data that is not required to be accessed from outside the virtual machine to which the disk is attached.

Disks come in many different sizes and performance levels, from solid-state drives (SSDs) to traditional spinning hard disk drives (HDDs), with varying performance abilities.

When working with VMs, you can use standard SSD and HDD disks for less critical workloads, and premium SSD disks for mission-critical production applications. Azure Disks have consistently delivered enterprise-grade durability, with an industry-leading ZERO% annualized failure rate.

Encryption for storage services

Azure Storage Service Encryption (SSE) for data at rest helps you secure your data to meet the organization’s security and regulatory compliance. It encrypts the data before storing it and decrypts the data before returning it. The encryption and decryption are transparent to the user.
Client-side encryption is where the data is already encrypted by the client libraries. Azure stores the data in the encrypted state at rest, which is then decrypted during retrieval.

Replication for storage availability

A replication type is set up when you create a storage account. The replication feature ensures that your data is durable and always available. Azure provides regional and geographic replications to protect your data against natural disasters and other local disasters like fire or flooding.

Azure Networking

Azure provides many different ways to host your web applications — from fully pre-configured environments that host your code (PaaS), to VMs that you configure, customize, and manage (IaaS).

Virtual Network

A vNet is a logically isolated network in Azure. A vNet allows Azure resources to securely communicate with each other, the internet and on-premise networks. A vNet is scoped to a single region, however, multiple vNets from different regions can be connected together using vNet Peering.

Subnets

vNets can be segmented into one or more subnets. Subnets allow you to organize and secure your resources in discrete sections.

Example use case: If you have a VM that hosts your web-tier then it would have both a public IP as well as a private IP. However, VMs that host your app and data tiers and which don’t need to be exposed to the internet can have just private IPs.

VPN Gateways

It is also possible to have some tiers in the cloud and other tiers in your on-premise network by using a VPN Gateway, which provides communication between Azure virtual Network and on-premises networks over the internet.

Network Security Group (NSG)

A network security group allows or denies inbound network traffic to your Azure resources. Think of a network security group as a cloud-level firewall for your network.

Scale with Azure Load Balancer

How do you ensure your service is still available when you need to do weekly maintenance? And if you your site reaches users all over the world, there’s no good time to take down your systems for maintenance.
How do you avoid running into performance issues stemming from a spike when too many users connect at the same time?

Azure Load Balancer is a load balancer service from Microsoft whereby there’s no infrastructure or software for you to maintain. You simply define the forwarding rules based on the source IP and port to a set of destination IP/ports. In contrast, if you manually configured a typical load balancer, you would be responsible if the load-balancer went down or needed some sort of routine maintenance.

Load Balancer

supports inbound and outbound scenarios,
provides low latency and high throughput, and
scales up to millions of flows for all Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) applications.

You can use Load Balancer with

incoming internet traffic
internal traffic across Azure services
port forwarding for specific traffic, or
outbound connectivity for VMs in your virtual network

Azure Application Gateway

If all your traffic is HTTP, a potentially better option is to use Azure Application Gateway. Application Gateway is a load balancer designed for web applications. It uses Azure Load Balancer at the transport level (TCP) and applies sophisticated URL-based routing rules to make decisions for routing traffic. This type of routing is known as application layer (OSI layer 7) load balancing since it understands the structure of the HTTP message.

Benefits of using Azure Application Gateway over a simple load balancer:

Cookie affinity — Useful when you want to keep a user session on the same backend server.
SSL termination — Application Gateway can manage your SSL certificates and pass unencrypted traffic to the backend servers to avoid encryption/decryption overhead. It also supports full end-to-end encryption for applications that require that.
Web application firewall — Application gateway supports a sophisticated firewall — Web Application Firewall (WAF) which is a network security firewall solution that protects web applications from HTTP/S-based security vulnerabilities. Some of the most common types of attacks which are targeted at web servers include: SQL injection attacks, cross-site scripting (XSS) attacks, and DDoS attacks. Also, included is detailed monitoring and logging to detect malicious attacks against your network infrastructure.
URL rule-based routing — Application Gateway allows you to route traffic based on URL patterns, source IP address and port to destination IP address and port. This is helpful when setting up a content delivery network.
Rewrite HTTP headers — You can add or remove information from the inbound and outbound HTTP headers of each request to enable important security scenarios, or scrub sensitive information such as server names.

Azure DNS

DNS, or Domain Name System, is a way to map user-friendly names to their IP addresses. You can think of DNS as the phonebook of the internet.

For example, your domain name, contoso.com, might map to the IP address of the load balancer at the web tier, 40.65.106.192.

You can bring your own DNS server or use Azure DNS, a hosting service for DNS domains that runs on Azure infrastructure.

Reduce latency with Azure Traffic Manager

How can you make your site, which is located in the United States, load faster for users located in Europe or Asia?

One solution is to scale out to different regions by providing exact copies of your service in more than one region.

Notice the DNS name for each. How can you connect users to the service that’s closest geographically, but under the contoso.com domain?

You can use Azure Traffic Manager to route users to the closest globally distributed endpoint

Traffic Manager doesn’t see the traffic that’s passed between the client and server. Rather, it directs the client web browser to a preferred endpoint. Traffic Manager can route traffic in a few different ways, such as to the endpoint with the lowest latency.

This setup could also include your on-premises deployment running in California. You can connect Traffic Manager to your own on-premises networks, enabling you to maintain your existing data center investments.

Azure Load Balancer vs Azure Traffic Manager

Azure Load Balancer distributes traffic within the same region to make your services more highly available and resilient. Traffic Manager works at the DNS level, and directs the client to a preferred endpoint. This endpoint can be to the region that’s closest to your user.

Load Balancer and Traffic Manager both help make your services more resilient, but in slightly different ways. When Load Balancer detects an unresponsive VM, it directs traffic to other VMs in the pool. Traffic Manager monitors the health of your endpoints. When Traffic Manager finds an unresponsive endpoint, it directs traffic to the next closest endpoint that is responsive.

Security, Responsibility & Trust in Azure

Cloud Security is Shared Responsibility

As computing environments move from customer-controlled datacenters to the cloud, the responsibility of security also shifts. By shifting these responsibilities to a cloud service like Azure, organizations can reduce focus on activities that aren’t core business competencies.

Moving from on-prem to IaaS means you’ve outsourced concern over protecting the physical parts of your network. In other words, when you create virtual machines (VMs) and virtual networks in Azure, understand it’s still your responsibility to patch and secure your operating systems and software, as well as configure your network to be secure.

Moving to platform as a service (PaaS) outsources several security concerns — Azure takes care of the OS and of most foundational software like RDBMS by updating everything with the latest security patches, and integrating with Azure Active Directory for access controls. With PaaS you don’t need to concerned with building whole infrastructures and subnets for your environments by hand. You can simply “point and click” within the Azure portal or run automated scripts to bring complex, secured systems up and down, and scale them as needed.

With software as a service (SaaS), you outsource almost everything. The code is controlled by the vendor but configured to be used by the customer.

Regardless of the deployment type i.e. IaaS, PaaS, or SaaS, you always retain responsibility for the following items:

Data
Endpoints
Accounts
Access management

A layered approach to security

Defense in depth is a strategy that employs a series of mechanisms to slow the advance of an attack aimed at acquiring unauthorized access to information. Each layer provides protection so that if one layer is breached, a subsequent layer is already in place to prevent further exposure.

Data — In almost all cases, attackers are after data — stored in a database, on disk inside virtual machines, on a SaaS application such as Microsoft 365, or in cloud storage.

It’s the responsibility of those storing and controlling access to data to ensure that it’s properly secured and have processes in place to ensure the confidentiality, integrity, and availability of the data.

Application

Ensure applications are secure and free of vulnerabilities.
Store sensitive application secrets in a secure storage medium.
Make security a design requirement for all application development.

Compute

Secure access to virtual machines.
Implement endpoint protection and keep systems patched and current.

Networking

Limit communication between resources.
Deny by default.
Restrict inbound internet access and limit outbound, where appropriate.
Implement secure connectivity to on-premises networks.

Perimeter

Use distributed denial of service (DDoS) protection to filter large-scale attacks before they can cause a denial of service for end users.
Use perimeter firewalls to identify and alert on malicious attacks against your network.

Identity and access

Control access to infrastructure and change control — ensure access granted is only what is needed.
Use single sign-on and multi-factor authentication.
Audit events and changes.

Physical security

Physical building security and controlling access to computing hardware within the data center is the first line of defense.

Azure Security Center

Security Center is a monitoring service that provides threat protection across all of your services both in Azure, and on-premises.

Azure Security Center is available in two tiers:

Free — This tier is limited to assessments and recommendations of Azure resources only
Standard — This tier provides a full suite of security-related services including continuous monitoring, threat detection, just-in-time access control for ports, and more. After the 30-day trial period is over, this tier is $15 per node per month.

Azure Security Center in different stages of an incident response. Below is a sample incident response process —

Detect — Review the first indication of an event investigation. For example, you can use the Security Center dashboard to review the initial verification that a high-priority security alert was raised.
Assess — Perform the initial assessment to obtain more information about the suspicious activity raised by the security alert.
Diagnose — Conduct a technical investigation and identify containment, mitigation, and workaround strategies. For example, follow the remediation steps described by Security Center in that particular security alert.

Using Security Center recommendations to enhance security

A security policy defines the set of controls that are recommended for resources within that specified subscription or resource group. You can reduce the chances of a significant security event by configuring a security policy, and then implementing the recommendations provided by Azure Security Center.

Identity and Access

Authentication

Authentication is the process of establishing the identity of a person or service looking to access a resource. i.e. establishes if they are who they say they are.

It involves the act of challenging a party for legitimate credentials, and provides the basis for creating a security principal for identity and access control use.

Authorization

Authorization is the process of establishing what level of access an authenticated person or service has. It specifies what data they’re allowed to access and what they can do with it.

Azure provides services to manage both authentication and authorization through Azure Active Directory (Azure AD).

Azure Active Directory

Azure AD (AAD) is a cloud-based Identity and Application Management (IAM) system. As an Identity server, AAD provides a single place to store information about digital identities. Azure AD also performs an Application Management function by allowing applications to be ‘registered’ with it, enabling them to delegate their Identity and Access Management functions to Azure AD. Once registered with AAD, applications can be configured for various things such as authentication and authorization for users, services as well as hardware.

AAD can be used stand-alone or be synchronized with your existing on-premises Active Directory. This means that all your applications, whether on-premises, in the cloud (including Microsoft 365), or even mobile can share the same credentials.

Azure AD provides services such as:

Authentication — This includes verifying identity to access applications and resources, and providing functionality such as self-service password reset, multi-factor authentication (MFA), a custom banned password list, and smart lockout services.
Single-Sign-On (SSO) — SSO enables users to remember only one ID and one password to access multiple applications. A single identity is tied to a user, simplifying the security model.
Application management — You can manage your cloud and on-premises apps using Azure AD Application Proxy, SSO, the My apps portal (also referred to as Access panel), and SaaS apps.
Business to business (B2B) identity services — Manage your guest users and external partners while maintaining control over your own corporate data
Business-to-Customer (B2C) identity services — Customize and control how users sign up, sign in, and manage their profiles when using your apps with services.
Device Management — Manage how your cloud or on-premises devices access your corporate data.

Multi-Factor Authentication

MFA should be used for users in the Global Administrator role in Azure AD, because these are highly sensitive accounts.

Providing Identity to Services

It’s usually valuable for services to have identities. Often, and against best practices, credential information is embedded in configuration files. With no security around these configuration files, anyone with access to the systems or repositories can access these credentials and risk exposure.

Azure AD addresses this problem through two methods: service principals and managed identities for Azure services.

Service Principals

To understand service principals, it’s useful to first understand the words Identity and Principal.

Identity — An Identity is just an entity that can be authenticated. Obviously, this includes users with a user name and password, but it can also include applications or other servers, which might authenticate with secret keys or certificates.

Principal — A Principal is an identity acting with certain roles or claims. Usually, it is not useful to consider identity and principal separately, but think of using ‘sudo’ on a Bash prompt in Linux or on Windows using “run as Administrator.” In both those cases, you are still logged in as the same identity as before, but you’ve changed the role under which you are executing. Groups are often also considered principals because they can have rights assigned.

A Service Principal, therefore, is an identity that is used by a service or application, and which can be assigned roles (just like other identities).

Service Principals & Azure AD Applications

Both people and services authenticate via a security principal to connect to the Azure resources in a subscription; for a person, it’s called a user principal, and for a service, it’s called a service principal. For a service to connect to resources in a subscription, it needs an associated service principal within that subscription’s tenant. The security principals are given roles (read as permissions) within the associated tenant, which define what a service/user is allowed to access.

In AAD, each service is represented by an AAD Application.

There is no way to directly create a service principal using the Azure portal. When you register an application through the Azure portal, an application object and service principal are automatically created in your home directory or tenant.
If you register/create an application using the Azure PowerShell, Azure CLI, Microsoft Graph APIs, creating the service principal object is a separate step.

If the service only ever needs to access resources within its own subscription then its AAD application will have just one associated service principal — in the service’s home tenant.

However, applications sometimes need access to resources within other AAD tenants, and in each of these other tenants it will need a different service principal. There will only ever be 1 AAD application per app. There can, however, be multiple service principals for the AAD App i.e. one service principal per tenant that the app needs access to.

Azure AD Application

When you register your application with Azure AD, you are essentially creating an identity configuration for your application that allows it to integrate with Azure AD.

Each Application has the following attributes —

A Name
A Redirect URL — to the return the user to after successful authentication
An Application Id a.k.a Client Id
An Object Id
Account type — Who can use this application or access this API? Accounts in this organization (single tenant), accounts in any organization (multi-tenant), accounts in any organization (multi-tenant) + personal Microsoft Accounts, or Personal Microsoft Accounts only

An app registration in Azure AD results in an Application object — a globally unique instance of the application. All objects in Azure AD have an object ID, which you can use to identify a specific Application object when making API requests.

GET https://graph.windows.net/{tenant-id}/applications/{object-id}?api-version=1.6

An Application object is used as a template or blueprint to create one or more service principal objects. A service principal is created in every tenant where the application is used, and it inherits certain static properties from the application object.

An Application object’s objectId is only relevant in the same tenant where the app is registered, and is only ever used to identify that object.
An Application object’s applicationIdattribute is used across tenants, and on more than one object type. There are two primary uses:
1. To identify the app in various sign-in and token flows (e.g. client_id in OAuth 2.0 and OpenID Connect).
2. To uniquely identify the backing Application object of a ServicePrincipal object. (Think of the ServicePrincipal object as the “instance” of the app in a given Azure AD tenant.)

Because the Application object serves as a template for the Service Principal objects in any given tenant, the Application object itself describes three aspects of any given application —

How the service can issue tokens in order to enable access to it (i.e. the service/application)
The resources that the application might need to access, and
The actions that the application can take

Once the Application has been registered and an Application object created, you can then add secrets or certificates and scopes to make your app work.

App Registrations vs Enterprise Applications

App Registrations

Applications that are registered through Azure Portal (or programmatically) in your Azure Tenant appear in the App Registrations blade.

You can change Reply URL for these app so long as you’re an owner
You can use the Get-AzureADApplication cmdlet to list all the registered apps
For applications in App Registrations, you can configure OpenId-Connect (OpenID/OAuth) based authentication
By default, all users can create application registrations.

Enterprise Applications

The Enterprise Applications blade on the other hand are simply Service Principal objects that mirror the apps which are generally published by other companies i.e. in a different tenant. This list will also include service principals of apps registered in your home tenant. You can assign required permissions to the service principal object.

You can’t configure Reply URL for the apps that are registered in other company tenants.
You can use the Get-AzureADServicePrincipal cmdlet to list all the Enterprise Applications
For Enterprise Apps, you can configure SAML based authentication
In order to add an Application from the Azure AD app gallery as an Enterprise App, the user would need be in one of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.

The workflow is you create the App Registration (Application), say a Wiki app, in your tenant, which also creates the Enterprise Application (Service principal) in your tenant. Say some other app, registered in another tenant, has an integration with your wiki app, then when another tenant user wants to sign in to your app (the Wiki app), they grant your app the permissions it requires in their tenant and an Enterprise Application (Service Principal) is created in their tenant. This effectively mirrors your application in their tenant.
In other words, consider the application object as the global representation of your application for use across all tenants, and the service principal as the local representation for use in a specific tenant.

Managed Identities for Azure Services

The creation of service principals can be a tedious process, and there are a lot of touch points that can make maintaining them difficult. Managed identities for Azure services are much easier and will do most of the work for you.

A managed identity can be instantly created for any Azure service that supports it — and the list is constantly growing. When you create a managed identity for a service, you are creating an account on your organization’s Active Directory (a specific organization’s Active Directory instance is known as an “Active Directory Tenant”). The Azure infrastructure will automatically take care of authenticating the service and managing the account. You can then use that account like any other Azure AD account, including allowing the authenticated service secure access of other Azure resources.

Difference between

References:

https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

https://endjin.com/blog/2019/01/managing-applications-using-azure-ad-service-principals-and-managed-identities

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

Difference between "enterprise application" and "app registration" in Azure

Thanks for contributing an answer to Stack Overflow! Please be sure to answer the question. Provide details and share…

stackoverflow.com

Difference between App Registration and Enterprise Application in Azure AD

Applications that are registered through Azure Portal (or programmatically) in your Azure Tenant is App Registration…

morgantechspace.com

https://social.msdn.microsoft.com/Forums/en-US/cde6dfc0-ba30-4cd7-8b0a-7420afb3bcff/difference-between-azure-ad-app-registration-and-enterprise-application