Patching solution design for multiple AWS accounts and Regions - AWS Prescriptive Guidance

Patching solution design for multiple AWS accounts and Regions

You can extend the automated patching solution to support servers that span multiple AWS accounts and multiple AWS Regions. The extended solution involves setting up the patch automation solution in each AWS account through AWS CloudFormation StackSets in a shared services account, and configuring a resource data sync across the accounts with the shared services account.

Automated process

The following diagram illustrates the architecture for this scenario. This architecture includes AWS CloudFormation StackSets and an AWS shared service account.


          Reference architecture and workflow for patching mutable EC2 instances that
            span multiple AWS accounts and AWS Regions

The workflow is similar to the process described in the previous section, but involves the following additional steps, where the step numbers match the callouts in the diagram:

  1. In the shared services account, an AWS CloudFormation stack set is used to configure the S3 bucket for resource data sync through Systems Manager Inventory.

  2. The CloudFormation stack set creates the stack with the automate-patch Lambda function, sets up the patch baselines, and sets up Systems Manager Inventory resource data sync on the application accounts, to synchronize resources in the shared services account.

  3. The resource information in the application accounts is synchronized with the resource information in the shared services account.

  4. Amazon QuickSight generates patch compliance reports, using the Amazon Athena dataset for the synchronized resource information.

Architectural considerations and limitations

Maintenance window quotas per account

The architecture illustrated and described in the previous section creates a maintenance window for each patch group. However, the quota for the number of maintenance windows per AWS account is 50 (assuming that you haven’t requested a service quota increase). If you expect the number of patch groups to exceed 50 groups in a single AWS account, this architecture won’t scale to meet your requirements.

If a service quota increase isn’t sufficient for your needs, there are two options for managing this challenge: using predefined maintenance windows and using CloudWatch Events. Here are the advantages and disadvantages of each approach.

Option 1. Use predefined maintenance windows

  • Define a list of maintenance windows with various time windows (for example, 15 to 20 maintenance windows per account).

  • The application teams choose the maintenance windows that suit them from the predefined list and tag the instances accordingly.

  • Update the automated patching solution to map the patch groups to the selected maintenance windows instead of creating new maintenance windows.

Pros:

  • Simplified management.

Cons:

  • Less flexibility for defining custom maintenance windows.

  • When multiple patch groups share maintenance windows and patch tasks, canceling a specific patch task for a specific patch group requires additional manual effort.

Option 2. Use CloudWatch Events to trigger patch tasks instead of using maintenance windows

  • Instead of creating maintenance windows, use CloudWatch Events to trigger patch tasks based on the schedule and the patch groups.

  • In this scenario, each patch group is associated with a CloudWatch Events event instead of a maintenance window.

  • Update the automated patching solution to create events instead of maintenance windows.

Pros:

  • Scalable design.

  • Provides flexibility for defining custom maintenance windows.

Cons:

  • Maintenance windows provide additional functionality (such as duration and cutoff times) that aren’t available with CloudWatch Events.

Other considerations

  • The automated patching solution described in this section doesn’t support EC2 instances that are shut down.

  • This process supports EC2 instances in public subnets. To patch instances in private subnets, you must deploy a local patch repository like Windows Server Update Services (WSUS).

  • You must adjust the frequency for running the Lambda function so patch groups and maintenance windows are updated according to your required schedule.