• Input Data: Base AMI, Amazon S3(이미지 파이프라인 에셋), AWS Parameter Store 등 입력 데이터 소스
• Configuration: config-vred-.json, build-vred-.yaml, test-vred-.yaml 세 가지 설정 파일로 파이프라인을 정의
• AWS CDK: cdk deploy 명령 한 번으로 모든 인프라를 배포
• AWS Deployment Infrastructure: AWS CloudFormation이 AWS Systems Manager, Amazon S3(VRED 인스톨러 + 스크립트), Amazon IAM을 조합하여 Amazon EC2 Image Builder를 구동
• Output Image: 최종 결과물로 vred- Golden AMI가 생성됨

Golde AMI 파이프라인

  [Trigger] → Build Image Builder → Validate CVE 스캔 → 승인 대기
               → (승인) → SSM Parameter 갱신 → EKS 반영
               → (거부/실패) → AMI 폐기 → 정기 재스캔

1. Trigger

• Schedule Trigger: GitHub Actions cron 표현식(0 2 * * 1)으로 매주 월요일 02:00에 자동 실행된다. 주기적인 OS 패치 및 보안 업데이트를 자동으로 반영하기 위한 설계다.
  - Manual Trigger (workflow_dispatch): GitHub Actions UI 또는 API를 통해 수동으로 즉시 실행한다. VRED 신규 버전 릴리스, 긴급 보안 패치 등 비정기적 이벤트에 대응하기 위해 필요하다.
  

2. Self-hosted Runner (Private Subnet)

Self-hosted Runner는 GitHub Actions의 Job 실행 환경으로, GitHub이 제공하는 공용 Runner 대신 AWS Private Subnet 내의 EC2 인스턴스에서 동작한다.

• GitHub Actions Workflow의 모든 Job을 실행하는 주체
  AWS CLI를 통해 AWS 서비스(EC2 Image Builder, Parameter Store, Lambda 등)와 직접 통신한다.
• Private Subnet에 위치하므로 인터넷을 통한 직접 접근이 차단되어 있으며, IAM Role을 통해 필요한 AWS 리소스에만 접근

구성 시 고려 사항

• 네트워크: Private Subnet에 위치하므로 GitHub과의 통신을 위해 NAT Gateway 또는 VPC Endpoint(GitHub용)가 필요
• IAM Role: Runner EC2 인스턴스에 부여하는 IAM Role은 Image Builder 실행, SSM Parameter 쓰기, Lambda 호출, Inspector 결과 조회 등에 필요한 최소 권한만 포함
• Runner 등록: GitHub Repository 또는 Organization 수준에서 Runner를 등록하며, runs-on: self-hosted 레이블로 워크플로우와 연결
• 가용성: Runner 인스턴스 장애 시 파이프라인 전체가 중단되므로, Auto Scaling Group으로 Runner 인스턴스를 관리하거나 최소 2대 이상 운용 권장

3. Job: Build Image Builder 실행

요청된 VRED 버전 및 OS 설정을 기반으로 EC2 Image Builder 파이프라인을 실행하여 새로운 AMI를 빌드

• Image Builder 파이프라인 실행
• 빌드 완료 대기 폴링

EC2 Image Builder 내부 동작

• Base Image 선택: AWS Parameter Store에서 최신 Windows Server 2022 Base AMI ID를 조회하거나, 직접 지정된 AMI ID를 사용한다.

• Build Component 실행:

  • S3에서 VRED 인스톨러 및 PowerShell 스크립트를 다운로드
  • 압축 해제 후 VRED Core를 자동 설치
  • SSM Agent, CloudWatch Agent 등 자동화에 필요한 에이전트를 설치하고 구성
  • Python 헬퍼 라이브러리 등 런타임 의존성을 미리 배치

• Test Component 실행:

  • VRED Core 프로세스 구동 가능 여부를 확인
  • 설치 경로, 레지스트리 키 등 필수 항목의 존재 여부를 검증
  • 검증 실패 시 빌드가 중단되고 Job이 FAIL 상태가 됨

• AMI 생성: 모든 단계가 성공하면 신규 AMI ID가 생성되고 지정된 Region 및 Account로 배포

• 출력: 생성된 AMI ID를 GitHub Actions 출력 변수(GITHUB_OUTPUT)로 전달하여 후속 Job에서 참조

Job: Validate Inspector CVE 스캔

빌드된 AMI에 포함된 OS 패키지 및 소프트웨어의 취약점(CVE)을 자동으로 검사하고, 기준을 통과한 경우에만 다음 단계로 진행

• Image Builder가 AMI를 빌드하는 과정 또는 빌드 완료 직후 Inspector v2가 해당 AMI를 자동으로 스캔
• 스캔 대상은 OS 수준의 패키지(Windows Update 누락 항목 포함)와 설치된 소프트웨어의 알려진 CVE 목록

고려 사항

1. AMI 빌드와 런타임 구성의 분리

EC2 기동 시 소프트웨어를 설치하는 방식(user data 스크립트)은 기동 시간을 크게 늘린다. 소프트웨어 설치처럼 변경 빈도가 낮은 작업은 AMI 빌드 단계에서 처리하고, 세션 ID나 씬 파일 경로처럼 런타임에 결정되는 값만 기동 후 처리하도록 역할을 명확히 나눠야 한다.
이 구조가 확립되어야 "AMI는 한 번 빌드, 인스턴스는 빠르게 기동"이라는 목표를 달성할 수 있다.

2. 버전 관리와 파라미터화

VRED 버전, OS 버전, 의존 라이브러리 버전을 모두 파라미터로 관리해야 한다. 이미지 1에서 보듯 설정 파일명에 태그를 사용하는 방식이 실질적인 버전 추적을 가능하게 한다.
버전별 AMI ID를 DynamoDB 같은 데이터 스토어에 등록해두면, 워크플로우에서 요청받은 버전에 해당하는 AMI를 동적으로 조회하여 인스턴스를 기동할 수 있다.

3. 빌드-테스트 단계의 자동화

Build Component에서 설치를 수행한 후, Test Component에서 설치 성공 여부를 자동으로 검증하는 구조를 갖추어야 한다. 검증 없이 생성된 AMI는 런타임에서야 문제가 드러나 디버깅 비용이 크게 증가한다.
테스트 컴포넌트는 단순한 프로세스 존재 여부 확인 수준을 넘어, 실제 API 호출이나 기능 동작 여부까지 검증하는 것이 이상적이다.

4. 인프라를 코드로 관리(IaC)

AWS CDK를 사용하면 파이프라인 구성 요소(Image Recipe, Distribution 설정, Infrastructure 정의)를 코드로 버전 관리할 수 있다. 이를 통해 파이프라인 자체의 변경 이력을 추적하고, PR 기반의 리뷰 프로세스를 적용할 수 있다.
CloudFormation 단독 사용 대비 CDK는 추상화 수준이 높아 반복되는 설정을 재사용 가능한 구성 요소로 캡슐화하기 용이하다.

5. 자산 저장소의 역할 분리

S3에 저장되는 에셋을 용도별로 분리해야 한다. 이미지 파이프라인에서 사용하는 VRED 인스톨러 및 스크립트(빌드용)와, 런타임에 VRED가 로드하는 씬 파일(운영용)은 서로 다른 버킷 또는 prefix로 관리하는 것이 보안 및 운영 측면에서 바람직하다.
AWS Parameter Store는 빌드 시점의 설정값(Base AMI ID, 버전 정보 등)을 중앙에서 관리하는 용도로 활용한다.

6. 보안 설계

IAM Role은 Image Builder 파이프라인이 S3에서 에셋을 내려받고 Systems Manager와 통신하는 데 필요한 최소 권한만 부여해야 한다.
세션 패스워드처럼 민감한 런타임 정보는 AMI에 포함시키지 않고 Secrets Manager에서 동적으로 조회하는 방식을 채택해야 한다.

7. 파이프라인 트리거 전략

VRED 신규 버전 출시, OS 보안 패치 등 외부 이벤트가 발생했을 때 파이프라인이 자동으로 실행되도록 EventBridge 등을 연동하는 방안을 검토해야 한다.
수동 트리거만 허용하면 운영 중 보안 취약점이 있는 구버전 AMI가 장기간 사용될 위험이 있다.

8. 서비스와의 통합을 고려한 AMI 설계

Golden AMI는 단순히 소프트웨어를 설치하는 것으로 끝나지 않는다. 이미지 4의 prep-node 단계에서 보듯, SSM Agent가 정상 동작하고 Python 헬퍼 라이브러리가 올바른 위치에 배치되어 있어야 워크플로우 자동화가 원활하게 이루어진다. AMI 설계 초기부터 이후 자동화 단계에서 필요한 의존성을 모두 포함시켜야 한다.