The three objects
A policy is the unit of intent. It answers how something is protected: how often a backup runs, how long it is kept, and which storage tier it lands in. A policy knows nothing about which resources it covers. A protection group is the binding. It connects one policy to a set of resources, either named explicitly or matched by rule. A group is where “this policy” meets “these resources”. A protection rule matches for you. Instead of listing resources, a rule describes the resources that should be enrolled — by AWS account, region, tag, or name — and the group picks up everything that matches, including resources that appear later.Why the separation matters
Because matching is declarative, protection scales without per-resource work. An account that gains a hundred new buckets tomorrow needs no new configuration: if the buckets match a rule, they are protected, and if they stop matching, they leave the group. This is also why the model has two failure modes worth knowing. A rule that is too broad protects things you did not intend; a rule that is too narrow silently misses things you did. Both are configuration questions, not product limitations — which is why the pattern of a rule matters more than its individual conditions.Matching by tag or name
Rules match on tags and on names. Name conditions come in three forms: an exact match, a list of accepted names, and a case-insensitive substring match. For EC2 instances and EBS volumes the name is taken from the AWSName tag, so resources without that tag have no name to match.
Names are useful where tags are inconsistent — teams that follow a naming convention, or resource
types where the name is already the natural identifier. Tags remain the better choice where
ownership or environment is what you are actually describing.
Precedence
When more than one thing applies to a resource, the more specific wins: a policy assigned directly to a resource overrides the policy that a matching rule would have applied. That gives you a way to carve out an exception without dismantling the rule that covers everything else.Where the model has edges
Membership can change without you asking it to. Moving a protection group to a different organisational unit deletes that group’s rule, because the rule was written against the previous scope and would otherwise re-evaluate against a wider one. Resources you added by hand stay in the group; resources the rule had added automatically leave it. Existing backups are unaffected and remain restorable until their retention expires. That is a deliberate trade: a stale rule that suddenly matches more than intended is worse than a rule that disappears and must be re-created knowingly.Where to go next
- Backup policies — define the frequency, retention and tier.
- Protection groups — bind a policy to resources.
- Protection rules — enrol resources automatically.
- Storage tiers — choose where backups are kept.
- Protect a resource — the same model through the API.