A dispatcher at a Cascade Regional Airlines regional hub shuts down a rarely-used reporting VM from inside the Windows guest OS instead of using the Azure portal's Stop button, then wonders why the compute charges keep appearing on the next invoice. Why does Azure keep billing for compute after this shutdown?

In Azure, 'stopped' and 'deallocated' are different states. Shutting down from inside the guest OS (or via a portal action that doesn't deallocate) leaves the VM in a stopped state where Azure still reserves the underlying compute capacity for it, so compute billing continues. Only deallocating the VM — through the portal's Stop button, the CLI's az vm deallocate, or PowerShell's equivalent — releases that reserved compute back to Azure's pool, which is what actually stops the compute meter and, as a side effect, releases any dynamic public IP address assigned to the VM. The 'billing never changes with power state' option is simply false and ignores the entire point of deallocation as a cost-saving action. The 'billing tied to disk size only' option confuses disk storage costs, which do keep accruing regardless of VM power state, with compute costs, which are what actually stopped or didn't stop here. The 'dynamic IP is what's billed' option misidentifies what's being charged — the invoice line in question is compute, and while the dynamic IP would indeed be released on deallocation, IP release isn't itself a billable line that explains ongoing compute charges. As an operational check, look at the VM's status in the portal: 'Stopped' still shows as billable, while 'Stopped (deallocated)' does not.