← Documentation
Azure
Azure Resource Parking - Supported Capabilities by Service
Exactly what Park Your Cloud (PYC) automatically starts and stops ("parks") on Azure for your subscription - VMs, VM Scale Sets, managed databases, AKS, and Container Apps - and what falls outside PYC's current scope. This reflects what PYC's Azure resource discovery and start/stop automation actually support today.
SUMMARY
| Service | PYC Supports | PYC Does Not Support |
|---|---|---|
| Virtual Machines | Start/stop (deallocate) of individual Azure VMs | VM Scale Sets, AKS node pools |
| VM Scale Sets (VMSS) | Start/stop of standalone scale sets (Uniform or Flexible) - parking deletes unprotected instances, unparking recreates them | AKS-managed / Karpenter node-pool scale sets (park the AKS cluster instead); protected instances (protectFromScaleSetActions/protectFromScaleIn) |
| Azure Database | MySQL Flexible Server, PostgreSQL Flexible Server, Azure SQL Managed Instance | Single/elastic-pool Azure SQL Database, Cosmos DB, single-server MySQL/PostgreSQL (deprecated), any other DB service |
| AKS | Cluster-level start/stop; Deployment/StatefulSet-level parking with KEDA pause/resume | Node Autoprovisioning (NAP) clusters at the cluster level; node pools/worker nodes directly; bare-HPA-only workloads |
| Container Apps | Application-level start/stop | Replica/scale configuration is not changed by start/stop - nothing to restore on start |
BY SERVICE
1
Azure Virtual Machines
Supported
■ PYC starts and stops individual Azure VMs. Parking deallocates the VM (not just an OS-level shutdown), so compute billing actually stops.
■ If a VM is only OS-stopped but still allocated, PYC deallocates it on parking to ensure billing stops; on unparking it is started normally.
■ If the VM is mid-transition (starting, stopping, deallocating, creating) when a parking action runs, PYC waits and re-checks automatically before giving up.
Not Supported
■ VMs that have been deleted are no longer tracked - PYC marks them as removed rather than acting on them.
■ VM Scale Sets and AKS node pools are not covered by this VM parking logic.
2
Azure Virtual Machine Scale Sets (VMSS)
Supported
■ PYC starts and stops standalone VM Scale Sets, in either orchestration mode (Uniform or Flexible).
■ Parking a VMSS actually deletes its unprotected instances (disks and NICs included), rather than just deallocating them, for deeper savings. Unparking recreates them.
■ If autoscale is attached to the scale set, PYC disables it before parking and re-enables it (with its capacity restored) on unparking, so it doesn't undo the park on its own.
■ If no autoscale setting is attached, unparking uses a user-supplied desired count to recreate instances. This value is always required to unpark; autoscale min and max values are required only when autoscale is attached.
■ Instances still running-but-stopped from something other than a PYC park (e.g. a customer manually deallocated one, or a Spot eviction) are explicitly started on unpark, since a deallocated instance still counts toward capacity and would otherwise be invisible to Azure's own automation.
Not Supported
■ AKS-managed or Karpenter/NAP-provisioned scale sets (node pools) are excluded entirely from discovery, and refused if targeted directly - park the AKS cluster instead.
■ Instances flagged
protectFromScaleSetActions or protectFromScaleIn are never deleted by a park - they keep running and billing, and PYC surfaces a warning rather than overriding the protection.■ Spot-priced scale sets get a warning on park/unpark: recreated instances depend on Spot capacity and pricing being available at unpark time, and creation can fail after PYC has already reported success.
3
Azure Databases
Supported
■ Azure Database for MySQL - Flexible Server: start/stop of the server.
■ Azure Database for PostgreSQL - Flexible Server: start/stop of the server.
■ Azure SQL Managed Instance: start/stop of the instance.
■ For all three, PYC waits through Starting/Stopping/Updating transitions before reporting failure, and treats Deleting/Dropping resources as removed.
Not Supported
■ Single or elastic-pool Azure SQL Database (the standalone "Azure SQL Database" service, as opposed to SQL Managed Instance) is not supported.
■ Azure Database for MySQL/PostgreSQL "Single Server" - this is a separate, older deployment option that Microsoft has deprecated. It is not supported. (This is distinct from "Flexible Server", which PYC does support, above.)
■ Cosmos DB, and any other Azure data store, is not supported for parking.
4
Azure Kubernetes Service (AKS)
Supported
■ Cluster-level start/stop - stops/starts the whole control plane and nodes via the AKS stop/start API.
■ Workload-level parking - Deployments and StatefulSets: parking scales replicas to 0, unparking restores the replica count the user specifies at start time, and an attached KEDA ScaledObject is paused/resumed around it.
■ Requires AKS-managed Microsoft Entra integration on the cluster (not the retired legacy Azure AD integration) for workload-level access - this is checked before every workload-level action.
Not Supported
■ Clusters using Node Autoprovisioning (NAP/Karpenter) cannot be stopped/started at the cluster level - Azure itself rejects it - so these clusters are excluded from cluster-level discovery. Their Deployments/StatefulSets are still discovered and parked normally at the workload level.
■ Node pools / worker nodes are never parked directly, whether backing a regular node pool or NAP - any VM or VM Scale Set carrying AKS/Karpenter-managed tags is excluded from VM and VMSS discovery. Park the AKS cluster itself instead.
■ Private clusters (no public API server endpoint) are not supported for workload-level parking. Cluster-level start/stop still works.
■ Workloads in system namespaces (kube-system, cert-manager, monitoring, keda, istio-system, and similar) are excluded from discovery.
■ Workloads scaled only by a plain Kubernetes HPA with no KEDA ScaledObject are excluded from both discovery and parking, same as EKS.
5
Azure Container Apps
Supported
■ Application-level start/stop, using the dedicated Container Apps start/stop actions.
Not Supported
■ Stopping a Container App does not change its min/max replica (scale) configuration at all - it only changes the app's running status. There is nothing for PYC to restore on start, unlike ECS/EKS/AKS workload parking.
Note
This page currently covers Azure VMs, VM Scale Sets, three managed database types (MySQL Flexible Server, PostgreSQL Flexible Server, SQL Managed Instance), AKS, and Container Apps - what PYC's Azure resource discovery and start/stop automation support today. Other Azure services (Function Apps, App Services, Cosmos DB, etc.) are out of scope until added to the platform.