Azure Monitor

Azure Monitor is the observability platform for everything in Azure. Before it, different services had separate monitoring tools. VMs had Log Analytics, App Service had Application Insights, Activity Log was separate. Azure Monitor is the umbrella that consolidates everything. Two fundamental types of monitoring data. Metrics are numerical measurements collected at regular intervals. CPU percentage, memory usage, requests per second. Every Azure resource generates metrics automatically without configuration. Available within one minute. Stored for 93 days. Use for dashboards, autoscale triggers, and threshold alerts. Logs are structured records capturing events, operations, and errors. An HTTP 500 error with stack trace. A failed authentication with username and IP. An NSG rule allowing or blocking a connection. Critical difference from metrics: logs are NOT collected automatically for most resources. You must configure Diagnostic Settings on each resource to route its logs somewhere. Without Diagnostic Settings, those logs are generated and immediately discarded. This causes real-world incidents constantly. An organisation gets compromised, investigations begin, and they discover Key Vault access logs were never enabled. All evidence of what data was accessed is gone. Enable Diagnostic Settings on critical resources before you need the logs, not after. Log Analytics Workspace is where logs go. It is a queryable database using Kusto Query Language, KQL. Simple query: show me all failed sign-ins in the last hour. Complex query: which VMs had CPU above 80% for more than 10 minutes in the last 24 hours. Alerts fire when conditions you define are met. Alert rule has three parts: scope is what resource to watch, condition is what signal and threshold triggers it, and action group is what to do when it fires. Action groups can send email, SMS, call webhooks, trigger Logic Apps or Functions, or create ITSM tickets. Action Groups are reusable. One action group attached to 20 different alert rules. When any fires, the same team gets notified. Activity Log captures all control-plane operations, who created, modified, or deleted resources, retained for 90 days automatically.. Remember: Metrics are automatic, numerical, 93-day retention, near-realtime. Logs need Diagnostic Settings, stored in Log Analytics, queried with KQL. Alerts need scope, condition, and action group. Action Groups are reusable.

Metrics vs Logs — Key Difference

Log Analytics Workspace

Alerts & Action Groups

Diagnostic Settings

Azure Backup protects you from data loss, not from infrastructure failure. If someone accidentally deletes a file, ransomware encrypts data, or a developer drops the wrong database table, backup saves you. Backup is not your disaster recovery strategy for infrastructure outages. The structure: everything starts with a vault. For backing up VMs and SQL databases, use a Recovery Services Vault. For newer workloads like managed disks, blobs, and AKS, use a Backup Vault. The vault must be in the same region as the resources you are protecting. You cannot back up an East US VM to a West US vault. For VM backup the experience is simple. No agent installation required for Azure VMs. The backup extension installs automatically. Azure takes an application-consistent snapshot of all the VM's managed disks, transfers incremental changes to the vault, and creates a recovery point. Backup policies define schedule and retention. Take daily backups retained for 30 days, weekly retained for a year, monthly for five years, and yearly for ten years, all in one policy. Restore options give flexibility. Restore the entire VM, replacing the existing VM or creating a new one alongside it. Restore individual files by mounting the backup disk as a file share and copying only what you need. Soft delete is a safety feature enabled by default. When you delete a VM's backup, Azure does not immediately purge the data. It holds it in soft-deleted state for 14 days. During that window you can undo the deletion and recover everything. After 14 days the data is permanently gone. This protects against accidental deletion and against ransomware attackers who try to delete your backups. Never disable soft delete on production vaults. Vault redundancy: GRS replicates backup data to a paired region, surviving a complete regional outage. Default and recommended. LRS keeps backup data local, cheaper but no regional redundancy.. Remember: Backup protects against data loss not infrastructure failure. Recovery Services Vault for VMs and SQL. Vault must be in same region as protected resources. Soft delete retains deleted backup data for 14 days. Never disable it.

Recovery Services Vault vs Backup Vault

VM Backup — How It Works

Backup Policies & Retention

Azure Site Recovery is your disaster recovery service, and the distinction from backup is fundamental. Backup takes snapshots at scheduled intervals. If your last backup was at midnight and primary region fails at 11:55 PM, you have lost almost 24 hours of data. Restoring from backup takes hours. Azure Site Recovery continuously replicates your VM's disk writes to a secondary region. Every write your VM makes is replicated asynchronously within seconds to a minute. If your primary region fails, you fail over to the secondary region and are running again in minutes, with data loss measured in seconds, not hours. RPO and RTO define disaster recovery quality. Recovery Point Objective is how much data you can afford to lose. ASR typically achieves under one minute RPO. Recovery Time Objective is how long it takes to restore service. With ASR and well-tested recovery plans, RTO is typically 15 to 30 minutes. Architecture: in your primary region the VM is running. ASR's mobility agent captures disk writes. These are replicated asynchronously to the secondary region. In the secondary region a replica VM exists in a non-running standby state, kept up to date with all latest data. When you trigger failover, Azure starts the replica VM. DNS or Traffic Manager switches to the secondary region. Service resumes. Three failover types. Test Failover is for DR drills. Azure starts the replica VM in an isolated network completely separate from production. You verify everything works, then clean up. Production is unaffected. Run test failovers regularly. Planned Failover is for scheduled migrations or maintenance. Azure synchronises primary and secondary and does a clean handoff with minimal or zero data loss. Unplanned Failover is for actual disasters when the primary region is down. Data loss is possible up to the RPO. After failing over you will want to fail back to the primary eventually. ASR handles re-protection and failback as a reverse replication operation.. Remember: ASR continuously replicates, backup takes periodic snapshots. RPO under one minute for ASR. Test Failover uses isolated network, does not affect production. Always test your DR. Re-protect after failover to enable failback.

Azure Update Manager is the centrally managed patch management service for Azure VMs and Arc-enabled servers. The old approach used a combination of Log Analytics Workspace and Azure Automation Account. You needed to create both services, connect them together, onboard each VM, and manage everything through the Automation Account. It worked but was complex and is now being deprecated. Azure Update Manager is the replacement. Built natively into the Azure platform. No Log Analytics Workspace required. No Automation Account required. Manage patches directly from the VM resource or from the Update Manager hub in the Azure Portal. If you see exam scenarios about update management without Log Analytics, the answer is Azure Update Manager. Patch orchestration modes. AutomaticByOS means the VM's operating system handles updates using its built-in mechanism, Windows Update for Windows, package managers for Linux. Azure has no control over when patches are applied or what reboots happen. The VM might reboot unexpectedly during business hours. AutomaticByPlatform means Azure orchestrates patching during maintenance windows you define. Azure applies patches during your low-traffic periods, your scheduled maintenance slots. You define patch on Sunday nights between 2am and 6am. Azure applies all pending updates during that window. No surprise reboots during business hours. Manual mode means nothing happens automatically. You trigger patching on-demand with full visibility into exactly what patches are being applied. Assessment is a key feature. Update Manager scans all your VMs and shows which patches are missing, what CVEs apply to your environment, and severity ratings, all without applying anything. This gives you current vulnerability posture across your entire fleet. Cross-platform support: Update Manager works for Azure VMs and also for on-premises servers and VMs in other clouds connected via Azure Arc. One pane of glass for patch compliance across your entire hybrid environment.. Remember: Update Manager replaces Log Analytics Update Management with no workspace or automation account needed. AutomaticByOS means the OS handles it without Azure control. AutomaticByPlatform means Azure applies patches in your maintenance window. Works for Azure VMs and Arc-enabled servers.

The single most important fact about Azure Cost Management: budgets send alerts only. They cannot and do not automatically stop, pause, restrict, or delete Azure resources. A budget alert fires. Azure sends you an email. That is all. Your VMs keep running. Your storage keeps accumulating. Your costs keep climbing. The budget itself has zero ability to touch your resources. Zero.. The exam scenario is always: a budget alert fires at 90% of the monthly budget, what happens to the running VMs? The correct answer is nothing. They keep running. If you want automated action when a budget threshold is hit, you must configure a budget alert to trigger an Action Group, and that Action Group calls an Azure Function or Logic App that programmatically stops or deallocates resources. The budget triggers the alert. The Action Group calls the automation. The automation takes the action. Three separate steps. The budget does only the first. Azure Cost Management does many useful things. The Cost Analysis view gives flexible filterable breakdowns of your spending. Filter by subscription, resource group, resource type, service, tag, or time period. Tags are essential for cost allocation. If every resource has CostCenter, Environment, and Project tags, your finance team can see exactly what each workload costs. Without tags, everything is one undifferentiated blob of Azure spend. Azure Advisor analyses resource utilisation and makes specific recommendations. Identify underused VMs, orphaned disks not attached to any VM but still incurring storage charges, unused public IP addresses. Reserved Instances are the most impactful cost reduction available. Commit to a 1-year or 3-year reservation for a VM and save up to 72% compared to pay-as-you-go. Ideal for stable production workloads that run 24 by 7. Azure Hybrid Benefit lets you apply existing Windows Server or SQL Server licences to Azure VMs, reducing licence cost by roughly 40%. Spot VMs use spare Azure compute capacity at up to 90% discount. The massive catch: Azure can evict Spot VMs with only 30 seconds notice. Only for interruptible batch workloads, never for production.. Remember: Budgets send alerts only, they cannot stop resources. Tags enable cost allocation. Reserved Instances save up to 72% for committed workloads. Spot VMs save 90% but can be evicted with 30 seconds notice.