SSM Change Manager and Change Calendar

AWS Systems Manager Change Manager is a service that provides a standardized, automated change management process for AWS resources. It allows organizations to create, review, approve, and implement changes in a controlled manner. Change Manager integrates with other Systems Manager capabilities, such as Run Command, Automation, and Maintenance Windows, to execute approved changes. It also integrates with Change Calendar to enforce change freezes during critical periods.

In traditional IT, change management is often manual, error-prone, and lacks auditability. Change Manager automates the change request lifecycle, ensuring that all changes follow a predefined approval workflow. It provides a central dashboard to track changes, enforce policies (e.g., required approvals, change windows), and generate audit logs. This helps organizations meet compliance requirements (e.g., SOC 2, PCI DSS) and reduce the risk of unauthorized or untested changes.

Change Manager operates through a change request template. A template defines: - Change type: e.g., automation runbook, run command, or maintenance window. - Approval workflow: e.g., single approver, multi-level approval, or self-service. - Scheduling: when the change should be executed. - Risk level: low, medium, high, or custom. - Change Calendar association: optional, to enforce change freezes.

When a user submits a change request, Change Manager: 1. Validates the request against the template. 2. Checks the associated Change Calendar (if any) to see if the requested time falls within an allowed window. 3. If the calendar denies the change, the request is rejected immediately. 4. If allowed, the request enters the approval workflow. 5. Once approved, the change is scheduled for execution (either immediately or at a specified time). 6. After execution, Change Manager logs the outcome and provides a detailed report.

To create a Change Calendar:

aws ssm create-document --name "MyChangeCalendar" --content file://calendar.json --document-type ChangeCalendar

The calendar JSON defines allowed and blocked windows:

{
  "schemaVersion": "1.0",
  "description": "Change Calendar for Black Friday freeze",
  "calendarEvents": [
    {
      "name": "BlackFridayFreeze",
      "type": "NOT_ALLOWED",
      "startTime": "2024-11-28T00:00:00Z",
      "endTime": "2024-11-30T23:59:59Z"
    }
  ]
}

To associate a calendar with a change request template:

aws ssm update-document --name "MyChangeTemplate" --content file://template.json

In the template, include:

"changeCalendar": {
  "type": "ChangeCalendar",
  "documentName": "MyChangeCalendar"
}

To submit a change request:

aws ssm start-change-request-execution --document-name "MyChangeTemplate" --parameters "{}"

To view change requests:

aws ssm list-change-requests

To get details:

aws ssm describe-change-request --change-request-id "cr-1234567890"

Change Calendar is a document of type ChangeCalendar that defines time-based rules for when changes are allowed or not allowed. It supports two event types: - ALLOWED: Changes are permitted during this window. - NOT_ALLOWED: Changes are blocked during this window.

You can create recurring events (e.g., monthly maintenance windows) or one-time events (e.g., holiday freezes). The calendar can be shared across accounts via AWS Organizations, meaning a parent account can define a calendar and share it with child accounts. When a change request is submitted, Change Manager evaluates the calendar at the scheduled execution time. If the calendar says NOT_ALLOWED, the change request is rejected. If ALLOWED, the request proceeds.

A large e-commerce company uses Change Calendar to enforce a complete change freeze during Black Friday weekend. The operations team creates a calendar with a NOT_ALLOWED event from Thursday 00:00 UTC to Sunday 23:59 UTC. This calendar is shared with all accounts in the organization via AWS Organizations. All change request templates in production accounts are associated with this calendar. During the freeze, any attempt to submit a change request (e.g., patch deployment, configuration update) is automatically rejected. This prevents accidental disruptions during peak traffic. The change freeze is enforced across hundreds of accounts without manual intervention. One common pitfall: if a team creates a new change template without associating the calendar, changes can bypass the freeze. Therefore, the company uses AWS Config rules to enforce that all change templates have the calendar associated.

A financial services company uses Change Manager to schedule monthly security patches. They create a Change Calendar with recurring ALLOWED events on the first Saturday of each month from 2:00 AM to 6:00 AM UTC. Change request templates are configured to only allow execution during these windows. The approval workflow requires two approvals: one from the security team and one from the application owner. During the month, if a critical patch is needed outside the window, a separate emergency change template is used that has no calendar association (or a separate calendar with broader windows). This ensures that routine changes are confined to maintenance windows while allowing flexibility for emergencies. The company uses CloudTrail to audit all change requests and their calendar evaluation results.

A SaaS provider has multiple engineering teams that share the same AWS accounts. To prevent conflicting changes, they use Change Calendar to define team-specific allowed windows. For example, Team A can deploy changes on Mondays and Wednesdays, Team B on Tuesdays and Thursdays. Each team has its own change template associated with a dedicated calendar. The calendars are created centrally by the change advisory board (CAB) and shared to all accounts. This prevents overlapping changes that could cause service degradation. The CAB monitors change requests and can override a calendar for emergency changes by temporarily updating the calendar to allow changes. This approach scales to dozens of teams and hundreds of changes per week. The key challenge is managing calendar updates and ensuring teams do not accidentally use the wrong template.