Outcome
By the end of this lesson, you will be able to explain why groups exist and decide when to use a group over per-resource attachment.
| Prerequisites | M1.3 (schedules) |
| Time | 10 minutes |
1. Concept
A resource group is a named bundle of resources.
Attach a schedule to the group, or a budget, or a set of notifications, and everything in the group gets it. Add a resource to the group later and it gets it too, with nothing else to do. Take one out and it stops.
That is the whole idea, and it exists to solve one problem: your estate keeps changing and your schedules do not.
The problem groups solve
WITHOUT GROUPS: per-resource attachment
Day 1: Team creates 23 dev resources. Each is attached to schedule A.Day 8: Team provisions 3 new dev resources. They are NOT on the schedule. Someone has to remember to attach them.Day 16: Team retires 4 old dev resources. The schedule still references them. (Harmless but messy.)Day 30: Membership drift: only ~70% of dev resources are on the schedule. Schedule effectiveness degrades silently.WITH GROUPS
Day 1: Team creates the "dev" group, adds 23 resources, attaches schedule A.Day 8: Team provisions 3 new dev resources. Adds them to the "dev" group. Schedule automatically applies.Day 16: Team retires 4 old dev resources. Removes from group. Schedule automatically excludes them.Day 30: 100% of dev resources are on the schedule, because group membership is the single source of truth.The list of resources changed every week. The group did not, and the schedule attached to it never had to.
What can be attached to a group
ATTACHMENT TYPE BEHAVIOR─────────────────────────────────────────────────────────────────Schedule Every member follows the group's scheduleBudget The group has a budget, spend computed across membersNotification rules Notifications fire on group eventsSequenced execution Group-level ordering of start/stop (covered L4)A single group can carry all four attachments simultaneously. Adding a resource to the group means it inherits all four.
Exclusive membership
A resource can be in at most one group at a time. The exclusivity rule from M1.3 L5 extends to groups: one schedule per resource AND one group per resource.
Why exclusive: two groups can have conflicting attached schedules. Group A says “stop at 8 PM”; Group B says “stop at 10 PM.” If a resource were in both groups, which schedule wins? Resolving the conflict requires precedence rules or per-resource overrides, both of which add complexity. The simpler model: one group, explicit choice.
Adding a resource that is already in another group is rejected with the message “resource already belongs to a group”. There is no move action: remove it from the old group first, then add it to the new one. Silent migration is not possible.
One confirmation does exist. If the resource you add has its own schedule attachment or an active override, ZopNight asks you to confirm, then removes that schedule attachment and override, because a group member takes its schedule from the group.
Groups vs per-resource attachment: when to use which
SCENARIO USE─────────────────────────────────────────────────────────────Stable membership over months GroupGrowing or shrinking environment Group (definitely)A single resource needing its own hours Per-resourceCross-team shared infrastructure Per-resource (no obvious group)A pilot of 3 resources before scaling up Per-resource → migrate to groupA team's entire dev environment GroupFor most production deployments, groups are the right scaling pattern. Individual resource attachment is for the long tail.
Anti-pattern: too many tiny groups
A common mistake is one group per resource, which defeats the point. The right size:
GOOD GROUPS ANTI-PATTERN─────────────────────────────────────────────────────dev-platform group-for-i-0abcstaging-services group-for-i-0defprod-shared-infra group-for-i-0ghiml-training-experiments group-for-each-resource
5-20 resources per group 1 resource per groupGroup size guidance: typical 5-50 members per group, 100+ acceptable for very large estates. Below 5, the abstraction adds overhead without scaling benefit.
Anti-pattern: too few mega-groups
The opposite mistake: one “all-non-prod” group with 500 resources. Defeats the purpose differently: the group becomes too coarse to attach different schedules or budgets across what should be sub-environments.
GOOD ANTI-PATTERN─────────────────────────────────────────────────────dev (Group)staging (Group) all-non-prod (Group, 500 members)test-ephemeral (Group)
3 groups, each scheduled 1 group, can only have one scheduleslightly differently for everythingGroup at the level where everything inside shares the same hours or the same budget. Below that level, splitting buys nothing. Above it, splitting buys flexibility.
Group naming convention
GOOD NAMES BAD NAMES─────────────────────────────────────────────────────dev-platform-eu group1staging-services jane-test-groupprod-shared-infra miscml-training-experiments-aws new-group-2026-05
Descriptive, hierarchical Sequential or person-namedIncludes environment + scope Lacks contextGroup names appear in notifications, audit logs, and the UI. Treat them like database table names: descriptive enough that a future engineer reading them understands the purpose.
2. Demo
A team’s group strategy:
ORG: zopcloud-saas-prodCLOUD ACCOUNTS: 12 (3 AWS, 4 GCP, 5 Azure)
GROUP STRATEGY─────────────────────────────────────────────────────────GROUPS: MEMBERS SCHEDULE dev-platform-aws 34 business-hours-pt staging-platform-aws 28 business-hours-pt dev-services-gcp 47 business-hours-eu staging-services-gcp 31 business-hours-eu test-ephemeral-aws 14 aggressive-weekend ml-training-prod-aws 8 (no schedule) prod-shared-infra 52 (no schedule)
TOTAL: 7 groups, 214 resources across 12 cloud accounts.
NOTE: prod-shared-infra is a group for budgets + notifications, not for scheduling. It has no schedule attached.
NEW RESOURCE FLOW Engineer provisions dev-platform resource in AWS: → Resource discovered in 6h (or via manual refresh). → Engineer adds to "dev-platform-aws" group. → Resource inherits the business-hours-pt schedule. → Resource shows up in the dev-platform-aws budget tracking.
Engineer time per new resource: ~30 seconds.Without groups, the same workflow would require attaching the schedule + the budget + the notification rule individually per resource. Five times the click work.
3. Hands-on (6 min)
For your own estate:
1. Pick one logical group of resources you'd want to manage together (e.g., "all dev EC2 in us-east-1," or "all GCP staging databases").2. Count how many resources fit. Aim for 5-50.3. Identify what attachments this group would carry: - A schedule? Which one? - A budget? At what dollar amount? - Notification rules?4. Sketch the group name (follow the descriptive convention).5. (Optional, if you have a sandbox) Create the group, add the resources, attach the schedule, and observe.
You do not have to create the group right now: the exercise isabout practicing group design. The mechanics are in L2.4. Knowledge check
Q1
A team retires 4 old dev resources without removing them from their group. The likely consequence:
A. The resources are removed from discovery (since they don’t exist in the cloud anymore)
B. The group breaks
C. The schedule keeps firing errors forever against all those retired resources
D. The group must be recreated
Show answer
Correct: A. Discovery is the source of truth. When a resource no longer exists in the cloud, it is removed from the resource table, and its group membership is removed with it. No manual cleanup needed.
Q2
A team creates 250 groups, one per resource. Most accurate diagnosis:
A. Excellent organization right across the whole estate
B. Improves performance
C. Anti-pattern: groups are not for single resources
D. Required for security
Show answer
Correct: C. Groups exist to manage many resources at once; the right size is 5 to 50 members. A single-resource group is just an awkward per-resource attachment with extra overhead.
Q3
A team wants to attach two schedules to one group (“weekday schedule” + “weekend schedule”). The defensible answer is:
A. Yes, one group can carry many schedules
B. Create two groups with all the same resources
C. Use overrides
D. No: a group can have at most one schedule attached
Show answer
Correct: D. One group, one schedule, just like one resource, one schedule. Put both patterns in one schedule (weekday and weekend crons together) and attach that to the group. Allowing several schedules per group would bring back the conflicts that exclusive membership avoids.
5. Apply
Groups are managed in:
- Resource Groups page: create, list, manage
- Resource detail panel: see which group a resource is in
- Schedule detail page: attach a group instead of individual resources
For the create + manage mechanics, continue to L2.
Related lessons
- L2: Creating and managing groups (next)
- L4: Sequenced execution
- M1.3 L5: Attaching resources and groups
Glossary terms touched
Resource group · Exclusive membership · Group attachment