Resource Groups: Scheduling a Whole Environment as One Unit

A resource group is a named collection of cloud resources that you manage as one unit instead of one by one. In cost work a good unit is an environment or an application tier: “staging”, “qa-payments”, “dev-cluster”. Once resources are grouped, a single schedule, a single override or a single budget can apply to all of them.

Three things called a resource group

The same phrase covers three different constructs, and mixing them up leads to wrong assumptions.

Azure resource groups are part of Azure Resource Manager. Microsoft defines a resource group as a container that holds related resources for an Azure solution; it can hold every resource of the solution or only those you want to manage as a group. Microsoft’s guidance is to put resources that share a lifecycle in the same group so they can be deployed, updated and deleted together, and the group is a scope for Azure RBAC role assignments and locks.

AWS Resource Groups are a separate service. AWS defines a resource group as a collection of AWS resources in the same AWS Region that match the group’s query, and offers two query types: tag-based (resource types plus tags) and CloudFormation stack-based. The group is regional, so a multi-region environment needs one group per region.

Scheduler resource groups are a logical layer in the scheduling tool. They can mix resources from different accounts, regions and even clouds, because they are defined inside the tool rather than in any one provider.

How ZopNight groups behave

In ZopNight a resource group has a name, a description and an optional budget, and membership is exclusive: a resource belongs to at most one group, so it has exactly one scheduling source. That rule removes a class of conflicts where two groups with different schedules both claim the same database.

A schedule attached to a group applies to every member, and a later change to that schedule propagates to all of them. A whole group can be started or stopped at once, and overrides can target a group as well as a single resource. Groups can carry their own budget, tracked against live spend, and the budgets page tracks resource-group targets alongside cloud accounts and individual resources.

Designing groups that work

• One group per environment slice that shares a timetable. If the QA database must stay up for overnight test runs but the QA web tier does not, they are two groups, not one.
• Keep production and non-production in separate groups. A group is a blast-radius boundary for schedule mistakes as much as a convenience.
• Name groups for what people search for. staging-checkout beats group-7 when someone needs to override it at 11 PM.
• Decide the start order inside the group. ZopNight starts a group in tiers (storage, then databases, then compute, then apps, reversed on stop), and you can change a resource’s tier and set a per-resource delay. The start and stop ordering guide explains how to choose delays, because the ordering spaces actions in time rather than waiting for a dependency to report healthy.
• Review members after every re-sync. New resources discovered in an account do not join a group by themselves; add them deliberately.

Where groups fit in the bigger picture

Grouping is what turns a list of resources into something you can schedule and hold to a budget. For choosing the timetable itself, see cloud scheduling best practices; for the cost case behind grouping whole environments, see non-production environment costs.