Inquiry: Retaining Azure Configurations without Active Resource Charges

Question

Inquiry: Retaining Azure Configurations without Active Resource Charges

kapil koujalagi 0

Hi Team,

I frequently use Azure for research and knowledge-building trials. To support my learning, I need to retain specific configurations and settings for future reference even after I have finished using the primary resources.

Recently, I deleted my VM resources but continued to incur charges for associated components like the NAT Gateway.

Could you provide a step-by-step guide on how to preserve infrastructure configurations (such as networking and security settings) without incurring ongoing subscription costs once the compute resources are released? I am looking for the most cost-effective way to "pause" or store these setups for later use.

Thanks in advance,

Kapil

Bharath Y P 8,840 Reputation points Microsoft External Staff Moderator

2026-05-15T23:46:01.7633333+00:00
Hello Kapil, sounds like you want to keep your networking/security “blueprint” on hand but stop all billing once the heavy stuff (VMs, gateways, disks, etc.) is gone. Here’s a pattern I’ve seen folks use—it’s both cost-effective and gives you a fully reproducible setup for later:

Export your infra as code • In the Azure Portal, go to your Resource Group • Click “Export template” and download the ARM JSON • (Or use the CLI:
az group export \ --name MyResourceGroup \ --output json > azuredeploy.json ```) • This captures your VNet, NSGs, subnets, NAT Gateway settings, etc.

Store that JSON (or translate into Terraform/HCL) in your own Git repo • Now you’ve got a source-controlled “snapshot” of exactly how your network+security is wired.

Tear down everything that incurs charges • Delete your VM, disks (unless you need a data snapshot), public IPs, Load Balancers, NAT Gateways, etc. • Verify via Cost Analysis (Portal → Subscriptions → Cost analysis) that no resources remain billing. • Reminder: anything “Stopped (Deallocated)” still bills for disks, IPs, NAT Gateway. Full deletion is the only way to zero-out.

Restore later with one click • When you want to pick back up, simply go to “Deploy a custom template” in the portal (or az deployment group create --template-file azuredeploy.json) and choose your stored template. • All your network, NSG rules, route tables and even managed identities spin up exactly as before—no manual clicking required.

Optional extras

• If you only need disk data, you can snapshot or back up disks instead of deleting them. Snapshots live in cool-off tiers and incur just a few cents per month.

• Consider Azure Blueprints if you need to bundle policies, role assignments and RBAC along with your network.

Hope this helps you “pause” your environment without paying for unused services—just keep your ARM/Terraform definitions safe and hit deploy whenever you need to pick up where you left off.

—Reference docs:

• ST – I’m still getting charged for a canceled service:

https://learn.microsoft.com/azure/cost-management-billing/manage/cancel-azure-subscription

• Plan to manage Azure costs (delete all resources to avoid charges):

https://learn.microsoft.com/azure/cost-management-billing/understand/plan-manage-costs#prevent-unwanted-charges

2 answers

Your answer

Answer 1

kagiyama yutaka 2,590

I think u just save the rg as an ARM/Bicep template and remove only the paid stuff (VMs, disks, NAT gw, load balancer, public IP, ACR, Key Vault, Storage, Insights), keep the free vnet/nsg, and the whole setup stays at zero cost until u redeploy it.

0 comments

Answer 2

To retain Azure configurations for learning while avoiding ongoing charges, focus on two principles:

Ensure all billable compute/network resources are stopped or deleted.
Persist only the minimal, non-running artifacts (templates, scripts, documentation) outside of active Azure resources.

Key cost behaviors to keep in mind

Virtual machines (VMs)
- A VM in Stopped state (shut down from inside the OS) still reserves compute and incurs compute charges.
- A VM in Deallocated state (stopped from Azure portal/CLI/PowerShell) releases compute; no compute charges accrue.
- Disks, networks, and some other attached resources can still incur charges even after the VM is deleted.
- In the Azure portal, using Stop on the VM deallocates it. Shutting down from inside the OS only stops it and continues billing.
Disks and storage
- Managed disks (OS and data disks) continue to incur storage charges even if the VM is deleted, unless the disk itself is deleted.
- For VMs, by default the OS disk is deleted with the VM, but it can be configured to be retained; retained disks continue to accrue costs.
Networking and load balancing
- Virtual networks (VNets) are billed per subscription and per region.
- Load balancers are billable; for example, in Azure Machine Learning and Foundry scenarios, each compute instance or cluster can have a load balancer that continues to accrue daily cost until the compute resource is deleted.
- NAT gateways and similar networking components behave like other billable network resources: if left deployed, they continue to incur charges even after VMs are removed.
Platform services around compute
- For services like Azure Machine Learning or Foundry hubs, associated resources such as Azure Container Registry, Blob Storage, Key Vault, and Azure Monitor/Application Insights continue to accrue costs after the main workspace/hub is deleted, unless explicitly deleted.

Cost‑effective patterns to “pause” or preserve configurations

Use deallocation when temporarily pausing VMs
- For short-term pauses (hours to a few days) where the VM must remain intact:
  - Stop the VM from the Azure portal (or CLI/PowerShell) so it is Deallocated, not just Stopped.
  - This avoids compute charges while preserving the VM configuration and attached disks.
- Remember that disks and some network resources still incur storage/network charges.
Export infrastructure as code before deletion
- Before deleting billable resources (VMs, NAT gateways, load balancers, VNets):
  - Export the configuration as templates or scripts so it can be recreated later without keeping the resources running.
- Practical approaches:
  - Export ARM/Bicep templates for resource groups or specific resources.
  - Capture network and security configuration (VNets, subnets, NSGs, route tables, NAT gateways) into templates.
- After exporting, delete the actual resources (VMs, NAT gateways, load balancers, etc.) so they no longer incur charges.
Minimize what remains in Azure
- To avoid surprises like NAT Gateway charges after VM deletion:
  - After deleting VMs, review the resource group for:
    - Load balancers
    - NAT gateways
    - Public IPs
    - Virtual networks
    - Managed disks
  - Delete any components that are not strictly needed.
- If the goal is purely educational reference, keep only:
  - Templates (stored in source control or storage)
  - Documentation/notes
  - Possibly a minimal storage account for templates (if not stored outside Azure)
Be aware of “hidden” or dependent resources
- For Azure Machine Learning workspaces:
  - VMs, load balancers, VNets, and bandwidth can accrue costs before workspace deletion.
  - After workspace deletion, dependent resources like Azure Container Registry, Blob Storage, Key Vault, and Application Insights can remain and continue to incur charges until deleted.
- For Foundry hubs (classic):
  - Before hub deletion, VMs, load balancers, VNets, and bandwidth can accrue costs.
  - After hub deletion, Azure Container Registry, Blob Storage, Key Vault, and Application Insights (if enabled) remain and must be deleted to stop charges.
Use cost management practices alongside configuration preservation
- Implement policies and governance to avoid accidentally creating expensive resources:
  - Use “Allowed virtual machine SKUs” policies to restrict VM sizes to cost‑appropriate options.
  - Use policies to restrict public IPs on network interfaces to reduce unnecessary network and bandwidth costs.
  - Audit resources that incur costs even after VM deletion (for example, disks, VNets, load balancers) so they can be cleaned up.
- For recurring learning environments, consider:
  - Standardized templates that deploy only what is needed.
  - Scripts to deploy and tear down entire environments quickly.
When in doubt, fully delete and rely on templates
- For long-term “paused” learning environments where cost must be near zero:
  - Export all configurations as code.
  - Delete:
    - VMs (ensuring OS/data disks are deleted unless explicitly needed)
    - NAT gateways and load balancers
    - VNets and public IPs if not required for other workloads
    - Dependent resources such as Container Registry, Blob Storage, Key Vault, and Application Insights that are dedicated to the lab.
  - Recreate the environment from templates when needed.

This pattern preserves the design and configuration while ensuring that no active compute or networking resources remain to generate charges.

References:

Share via

Inquiry: Retaining Azure Configurations without Active Resource Charges

2 answers

Your answer