Pause Step Roster: Which Cloud Services Can Be Paused

In ZopNight, the pause step roster is the set of resource types that the remediation workflow’s pause step supports. A pause is a different lever from a start/stop schedule. Scheduling is for resources that should follow a daily or weekly cadence. Pausing is a one-off remediation for an analytics or ML service that is running and billing while nobody uses it.

What is on the roster

The roster currently covers:

Each pauser is registered by provider and resource type, so a new service joins the roster by adding a pauser rather than changing the workflow. Function Apps and Cognitive Services are on the roster, but their idle findings are advisory today, so ZopNight does not offer a one-click pause for them.

What a pause keeps and what it stops

The provider decides what stops billing, and it is rarely everything:

• Synapse dedicated SQL pool. Microsoft states that while the pool is paused you are not charged for compute, but you continue to be charged for storage. Pausing overnight and at weekends and resuming during the day is the pattern Microsoft itself describes.
• Azure Machine Learning. Compute instances can be scheduled to shut down on inactivity, and for compute clusters Microsoft’s guidance is to set the minimum node count to 0 so the cluster releases nodes when idle.
• Databricks clusters. Stopping a Databricks cluster terminates it. Databricks keeps a terminated all-purpose compute’s configuration for 30 days, after which it is permanently deleted unless an administrator pins it. If a paused cluster may stay down for more than a month, pin it first.
• Cognitive Services. ZopNight’s pause turns off public network access, so the account stops serving internet traffic. The account, its keys and any provisioned or commitment charges remain, so this pause cuts usage, not the standing bill.
• Data Factory. ZopNight stops every active trigger, so no scheduled pipeline runs start. Restore restarts the same set of triggers.
• Dataproc. ZopNight’s Dataproc pause deletes the cluster and always needs admin approval. The restore step returns unsupported, so plan to recreate the cluster from its definition rather than resume it.

Storage, logs, and anything provisioned alongside the compute, such as a workspace or a storage account, keep billing through all of these.

How the pause runs

The pause is one cloud action inside the standard remediation workflow: a precondition check, an approval step where the operation requires one, the pause itself, and validation. Database engines are deliberately absent. The pause template’s allowlist excludes RDS, Aurora, Cloud SQL, ElastiCache, Azure SQL, and PostgreSQL and MySQL types, so an idle database is never paused by remediation. Pausing changes the resource, so the account must be connected with read and write access.

Choosing between pause and schedule

• If the service is idle on a predictable cadence, a schedule fits better. Databricks SQL warehouses and all-purpose clusters can be put on an off-hours schedule, and Synapse SQL pools are on the start/stop list.
• If the service is idle because a project ended or a job finished, a pause is the right one-off action.
• If the pause is terminal, as with Dataproc here, treat it as a delete with extra steps and confirm the cluster can be recreated.

The workflow the pause runs inside is covered in auto-remediation explained; for the Databricks side specifically, see Databricks cost optimization and the step-by-step guide to pausing Synapse and Databricks.