Build SSM patch baseline configurations with approval rules, severity filters, compliance levels, and custom repositories.
Build SSM patch baseline configurations with approval rules, severity filters, compliance levels, and custom repositories.
Required Fields
NameOperatingSystemApprovalRules.PatchRulesOutput will appear here...Build an SSM patch baseline with tiered ApprovalRules (different ApproveAfterDays and ComplianceLevel per severity/classification combination), explicit ApprovedPatches and RejectedPatches overriding the rule-based auto-approval logic, and optional custom Sources for a non-default package repository. ApproveAfterDays creates a deliberate patch-testing delay, a Critical/Security patch with ApproveAfterDays: 3 isn't available for auto-approved installation until 3 days after its release, giving time to catch a bad patch reported by the broader community before your fleet installs it, but that same delay means a zero-day fix sits unapproved for those 3 days unless you also maintain an ApprovedPatches override for genuinely urgent releases.
No, ApproveAfterDays only controls when a patch becomes eligible for auto-approval under the matching rule, actual installation still depends on your patch scanning/installation schedule (via Maintenance Windows or on-demand patch operations), a patch approved on day 3 doesn't install itself, it becomes install-eligible the next time your patching process runs against instances using this baseline.
A patch not yet approved by any rule and not explicitly listed just isn't installed, it's neutral, pending. RejectedPatches with RejectedPatchesAction BLOCK is an active denial, actively preventing that specific patch from installing even if a later rule change would have otherwise approved it, appropriate when you've specifically identified a patch as problematic (causing a known regression) rather than just not-yet-vetted.
Patch classification/severity filters in different rules generally shouldn't overlap for the same patch, if they do, the behavior depends on rule evaluation order and can produce an ambiguous approval state for a patch matching multiple rules with different ApproveAfterDays values. Design PatchFilterGroup filters to be mutually exclusive across rules (as the example does, splitting by distinct severity tiers) rather than allowing overlapping classification/severity combinations.
The builder validates that Name, OperatingSystem, and ApprovalRules.PatchRules all resolve before accepting the JSON as a valid CreatePatchBaseline request, the fields SSM needs to know the baseline's target OS and its tiered approval logic; it can't verify referenced patch IDs in ApprovedPatches/RejectedPatches are valid for the target OS or that a custom source's Configuration is syntactically correct for the package manager in use, those checks happen only when patch scanning actually runs against a real instance.
ApproveAfterDays is a real security tradeoff, not just an operational delay, a genuinely urgent zero-day fix needs an ApprovedPatches override to bypass the waiting period, don't assume the baseline's normal cadence is fast enough for every critical patch.
RejectedPatches with BLOCK is the right tool for a patch known to cause a regression in your specific environment, don't rely on simply never adding it to ApprovedPatches, since a future baseline change or rule adjustment could otherwise inadvertently approve it.
A custom Sources repository needs its own maintenance and availability guarantees, if that internal mirror goes down or falls out of sync with upstream, patching for instances using this baseline silently stalls, monitor the custom repository's health independently.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.