여러 AWS 계정 및 지역을 위한 패치 솔루션 설계 - AWS 규범적 지침
자동화된 프로세스아키텍처 고려 사항 및 제한

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

여러 AWS 계정 및 지역을 위한 패치 솔루션 설계

자동 패치 솔루션을 확장하여 여러 AWS 계정과 AWS 지역에 걸친 서버를 지원할 수 있습니다. 확장 솔루션에는 공유 서비스 계정의 AWS CloudFormation StackSets를 통해 각 AWS 계정의 패치 자동화 솔루션을 설정하고 공유 서비스 계정을 사용하여 계정 간에 리소스 데이터 동기화를 구성하는 작업이 포함됩니다.

자동화된 프로세스

다음 다이어그램은 이 시나리오의 아키텍처를 보여줍니다. 이 아키텍처에는 AWS CloudFormation StackSets와 AWS 공유 서비스 계정이 포함됩니다.

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

워크플로우는 이전 섹션에서 설명한 프로세스와 비슷하지만, 단계 번호가 다이어그램의 콜아웃과 일치하는 다음과 같은 추가 단계가 포함됩니다:

  1. 공유 서비스 계정에서 AWS CloudFormation 스택 세트는 시스템 매니저 인벤토리를 통해 리소스 데이터 동기화를 위한 S3 버킷을 구성하는 데 사용됩니다.

  2. CloudFormation 스택 세트는 automate-patch Lambda 함수로 스택을 생성하고, 패치 기준선을 설정하고, 애플리케이션 계정에 시스템 매니저 인벤토리 리소스 데이터 동기화를 설정하여 공유 서비스 계정의 리소스를 동기화합니다.

  3. 애플리케이션 계정의 리소스 정보는 공유 서비스 계정의 리소스 정보와 동기화됩니다.

  4. Amazon QuickSight는 동기화된 리소스 정보에 대한 Amazon Athena 데이터 세트를 사용하여 패치 규정 준수 보고서를 생성합니다.

아키텍처 고려 사항 및 제한

계정당 유지보수 윈도우 할당량

앞 섹션에서 보여주고 설명한 아키텍처는 각 패치 그룹에 대한 유지보수 윈도우을 생성합니다. 하지만 AWS 계정당 유지보수 윈도우의 할당량은 50개입니다 (서비스 할당량 증가를 요청하지 않은 경우). 단일 AWS 계정의 패치 그룹 수가 50개를 초과할 것으로 예상되는 경우 이 아키텍처는 요구 사항에 맞게 확장되지 않습니다.

서비스 할당량 증가가 요구 사항에 충분하지 않은 경우 사전 정의된 유지보수 윈도우을 사용하는 것과 CloudWatch Events를 사용하는 두 가지 방법으로 이 문제를 관리할 수 있습니다. 각 접근 방식의 장점 및 단점.

옵션 1. 사전 정의된 유지보수 윈도우를 사용하세요

  • 다양한 타임 윈도우 (예: 계정당 15~20개의 유유지보수 윈도우) 이 있는 유지보수 윈도우 목록을 정의합니다.

  • 애플리케이션 팀은 사전 정의된 목록에서 자신에게 적합한 유지보수 윈도우를 선택하고 그에 따라 인스턴스에 태그를 지정합니다.

  • 새 유지보수 윈도우를 생성하는 대신 선택한 유지보수 윈도우에 패치 그룹을 매핑하도록 자동 패치 솔루션을 업데이트하세요.

장점:

  • 간소화된 관리.

단점:

  • 사용자 지정 유지보수 윈도우을 정의하기 위한 유연성이 떨어집니다.

  • 여러 패치 그룹이 유지보수 윈도우과 패치 작업을 공유하는 경우 특정 패치 그룹의 특정 패치 작업을 취소하려면 추가 수동 작업이 필요합니다.

옵션 2. 유지보수 윈도우를 사용하는 대신 CloudWatch Events를 사용하여 패치 작업을 트리거할 수 있습니다

  • 유지보수 윈도우를 생성하는 대신 CloudWatch Events를 사용하여 일정과 패치 그룹을 기반으로 패치 작업을 트리거하세요.

  • 이 시나리오에서 각 패치 그룹은 유지보수 윈도우 대신 CloudWatch Events 이벤트와 연결됩니다.

  • 자동 패치 솔루션을 업데이트하여 유지보수 윈도우 대신 이벤트를 생성하세요.

장점:

  • 확장 가능 디자인.

  • 사용자 지정 유지보수 윈도우를 유연하게 정의할 수 있습니다.

단점:

  • 유지보수 윈도우에는 CloudWatch Events에서 사용할 수 없는 추가 기능(예: 기간 및 마감 시간)을 제공합니다.

기타 고려 사항

  • 이 섹션에 설명된 자동 패치 솔루션은 종료된 EC2 인스턴스를 지원하지 않습니다.

  • 이 프로세스는 퍼블릭 서브넷의 EC2 인스턴스를 지원합니다. 프라이빗 서브넷의 인스턴스에 패치를 적용하려면 윈도우 서버 업데이트 서비스와 (WSUS) 같은 로컬 패치 리포지토리를 배포해야 합니다.

  • 필요한 일정에 따라 패치 그룹과 유지보수 윈도우가 업데이트되도록 Lambda 함수 실행 빈도를 조정해야 합니다.