Network Security Group (NSG) vs Application Security Group

Network Security Group	Application Security Group
Description	A network security group is used to enforce and control network traffic.	An application security group is an object reference within an NSG.
Features	Controls the inbound and outbound traffic at the subnet level.	Controls the inbound and outbound traffic at the network interface level.
Rules	Rules are applied to all resources in the associated subnet.	Rules are applied to all ASGs in the same virtual network.
Direction	Has separate rules for inbound and outbound traffic.	Has separate rules for inbound and outbound traffic.
Limits	NSG has a limit of 1000 rules.	ASGs that can be specified within all security rules of an NSG have a limit of 100 rules.
Action	Supports ALLOW and DENY rules.	Supports ALLOW and DENY rules.
Constraints	You are not allowed to specify multiple IP addresses and IP address ranges in the NSG created by the classic deployment model.	You are not allowed to specify multiple ASGs in the source or destination.

Azure Load Balancer vs Application Gateway vs Traffic Manager vs Front Door

Load Balancer	Application Gateway	Traffic Manager	Front Door
Service	Network load balancer.	Web traffic load balancer.	DNS-based traffic load balancer.	Global application delivery
Network Protocols	Layer 4 (TCP or UDP)	Layer 7 (HTTP/HTTPS)	Layer 7 (DNS)	Layer 7 (HTTP/HTTPS)
Type	Internal and Public	Standard and WAF	–	Standard and Premium
Routing	Hash-based, Source IP affinity	Path-based	Performance, Weighted, Priority, Geographic, MultiValue, Subnet	Latency, Priority, Weighted, Session Affinity
Global/Regional Service	Global	Regional	Global	Global
Recommended Traffic	Non-HTTP(S)	HTTP(S)	Non-HTTP(S)	HTTP(S)
Endpoints	NIC (VM/VMSS), IP address	IP address/FQDN, Virtual machine/VMSS, App services	Cloud service, App service/slot, Public IP address	App service, Cloud service, Storage, Application Gateway, API Management, Public IP address, Traffic Manager, Custom Host
Endpoint Monitoring	Health probes	Health probes	HTTP/HTTPS GET requests	Health probes
Redundancy	Zone redundant and Zonal	Zone redundant	Resilient to regional failures	Resilient to regional failures
SSL/TLS Termination	–	Supported	–	Supported
Web Application Firewall	–	Supported	–	Supported
Sticky Sessions	Supported	Supported	–	Supported
VNet Peering	Supported	Supported	–	–
SKU	Basic and Standard	Standard and WAF (v1 & v2)	–	Standard and Premium
Pricing	Standard Load Balancer – charged based on the number of rules and processed data.	Charged based on Application Gateway type, processed data, outbound data transfers, and SKU.	Charged per DNS queries, health checks, measurements, and processed data points.	Charged based on outbound/inbound data transfers, and incoming requests from client to Front Door POPs.

Locally Redundant Storage (LRS) vs Zone-Redundant Storage (ZRS)

 

Locally-Redundant Storage (LRS)	Zone Redundant Storage (ZRS)	Geo-redundant storage (GRS)
Replication	Replicates your data 3 times within a single physical location synchronously in the primary region.	Replicates your data across 3 Azure Availability Zones synchronously in the primary region	Replicates your data in your storage account to a secondary region
Redundancy	Low	Moderate	High
Cost	Provides the least expensive replication option	Costs more than LRS but provides higher availability	Costs more than ZRS but provides availability in the event of regional outages
Percent durability of objects over a given year	At least 99.999999999% (11 9’s)	At least 99.9999999999% (12 9’s)	At least 99.99999999999999% (16 9’s)
Availability SLA for read requests	At least 99.9% (99% for cool access tier)	At least 99.9% (99% for cool access tier)	At least 99.9% (99% for cool access tier) for GRS  At least 99.99% (99.9% for cool access tier) for RA-GRS
Availability SLA for write requests	At least 99.9% (99% for cool access tier)	At least 99.9% (99% for cool access tier)	At least 99.9% (99% for cool access tier)
Available if a node went down within a data center?	Yes	Yes	Yes
Available if the entire data center (zonal or non-zonal) went down?	No	Yes	Yes
Available on region-wide outage in the primary region?	No	No	Yes
Has read access to the secondary region if the primary region is unavailable?	No	No	Yes
Supported storage account types	General-purpose v2 General-purpose v1 Block blob storage Blob storage File storage	General-purpose v2 Block blob storage File storage	General-purpose v2 General-purpose v1 Blob storage

Azure Blob vs Disk vs File Storage

 

Blob Storage	Disk Storage	File Storage
Type of storage	Object storage to store all types of data formats.	Block storage for virtual machines.	File system across multiple machines.
Max Storage Size	Same as maximum storage account capacity	65,536 GiB for ultra disk 32,767 GiB for standard and premium drives	Scale up to 100 TiB
Max File Size	190.7 TiB for block blob 195 GiB for append blob 8 TiB for page blob	Equivalent to the maximum size of your volumes	4 TiB for a single file
Performance (Throughput)	500 requests per second for a single blob	Up to 2000 MBps per disk.	6,204 MiB/s for egress 4,136 MiB/s for ingress
Data Accessing	Objects can be accessed via HTTP/HTTPs.	A single virtual machine in a single AZ.	Share your files either on-premises or in the cloud.
Encryption Methods	Encrypt your data using Azure SSE (256-bit AES)	SSE by storage service and ADE for OS and data disks.	Encrypt your data using Azure SSE (256-bit AES)
Backup and Restoration	Versioning, snapshots and object replication	You can back up your managed disks at any point in time using snapshots.	Uses file share snapshots
Pricing	You are billed based on the stored data per month, operations performed, data transfer, and redundancy.	You pay for the disk size, snapshots, and number of transactions.	You pay for the provisioned GiB per month and the number of servers connected to the cloud endpoint.
Use Cases	Static website, media and log files, backups, analytics workloads	Boot volumes and transaction-intensive workloads	Central location of your files, monitoring logs and applications

Azure Scale Set vs Availability Set

 

Availability Set	Scale Set
Description	A group of discrete virtual machines spread across fault domains.	A group of identically configured virtual machines spread across fault domains.
Workloads	Use Availability Set for predictable workloads.	Use Scale Set for unpredictable workloads (autoscale).
Domain default	Has 3 fault domains and 5 update domains by default	Has 5 fault domains and 5 update domains by default
Configuration	Virtual machines are created from different images and configurations.	Virtual machines are created from the same image and configuration.
Distribution	Virtual machines are automatically distributed within a data center.	Virtual machine scale sets can be distributed within a single datacenter or across multiple data centers.
Number of VMs	You can only add a virtual machine to the availability set when it is created.	Scale sets can increase the number of virtual machines based on demand.
Pricing	Availability set has no additional charge. You only pay for the computing resources.	Scale sets have no additional charge. You only pay for the computing resources.

Azure Functions vs Logic Apps vs Event Grid

 

Functions	Logic Apps	Event Grid
Service	Serverless Compute	Serverless Workflows	Serverless Events
Description	Run a small piece of code to do a task	Automate your workflows without writing a single line of code.	Route custom events to different endpoints.
Features	Serverless applications Choice of language Bring your own dependencies Integrated security Flexible development tools Stateful serverless architecture	Built-in and managed connectors Control your workflows Manage or manipulate data App, data and system integration Enterprise application integration B2B communication in the cloud or on-premises	Advanced filtering Fan-out to multiple endpoints  Supports high-volume workloads Built-in Events Custom Events
Development	Code-first	Designer-first	Event Source and Handlers
Use case	Big data processing, serverless messaging	Connect legacy, modern, and cutting-edge systems with pre-built connectors.	Serverless application architectures, Ops Automation, and Application integration
Pricing	You are only charged for the time you run your code.	You are charged for the execution of triggers, action, and connectors.	You are charged for each operation, such as ingress events, advanced matches, delivery attempts, and management calls.

Azure Container Instances (ACI) vs Azure Kubernetes Service (AKS)

 

ACI	AKS
Description	Run containers without managing servers.	Orchestrate and manage multiple container images and applications.
Deployment	For event-driven applications, quickly deploy from your container development pipelines, run data processing, and build jobs.	Uses clusters and pods to scale and deploy applications.
Web Apps (Monolithic)	Yes	Yes
N-Tier Apps (Services)	Yes	Yes
Cloud-Native (Microservices)	Yes	Yes, recommended for Linux containers
Batch/Jobs (Background tasks)	Yes	Yes
Use cases	Dev/Test scenarios Task automation CI/CD agents Small/scale batch processing Simple web apps	Containers and application configuration portability Enables you to select the number of hosts, size, and orchestrator tools Transfer container workloads to the cloud without changing your current management practices.
Major Difference	You should use AKS if you need full container orchestration, such as service discovery across multiple containers, automatic scaling, and coordinated application upgrades.