EC2 Image Builder 이해하기: 골든 AMI를 자동으로 만들고 관리하는 AWS 서비스

EC2를 운영하다 보면 반복되는 작업이 있습니다.

운영체제를 설치하고, 보안 패치를 적용하고, 에이전트를 설치하고, 로그 설정을 하고, 회사 표준 보안 설정을 반영한 뒤 AMI를 만들어 배포하는 일입니다. 규모가 작을 때는 수동으로도 가능하지만, 계정과 리전, 운영 환경이 늘어나면 이미지 관리 자체가 하나의 운영 부담이 됩니다.

 

이 문제를 해결하기 위한 AWS 서비스가 EC2 Image Builder입니다. EC2 Image Builder는 사용자 정의 AMI 또는 컨테이너 이미지를 자동으로 생성, 테스트, 배포, 관리할 수 있도록 도와주는 완전관리형 서비스입니다. AWS 공식 문서에서도 “customized, secure, and up-to-date server images”의 생성과 배포를 자동화하는 서비스라고 설명합니다.

 

 

EC2 Image Builder가 필요한 이유

EC2 인스턴스를 매번 새로 만들 때마다 다음 작업을 반복한다고 생각해보겠습니다.

운영체제 패치 적용, 보안 에이전트 설치, CloudWatch Agent 설정, SSM Agent 확인, 회사 표준 계정 설정, 불필요한 패키지 제거, CIS 또는 STIG 기반 하드닝, 애플리케이션 런타임 설치, 배포 전 테스트 수행.

 

이 과정을 사람이 직접 하면 다음 문제가 생깁니다.

• 첫째, 이미지마다 설정이 조금씩 달라질 수 있습니다.
• 둘째, 보안 패치가 누락될 수 있습니다.
• 셋째, 어떤 이미지가 어떤 기준으로 만들어졌는지 추적하기 어렵습니다.
• 넷째, 여러 계정과 리전에 동일한 AMI를 배포하기 어렵습니다.
• 다섯째, 오래된 AMI가 계속 남아 비용과 보안 리스크를 만듭니다.

 

EC2 Image Builder는 이런 과정을 파이프라인으로 정의합니다. 즉, “어떤 베이스 이미지를 사용할지”, “어떤 패키지와 설정을 적용할지”, “어떤 테스트를 통과해야 할지”, “어느 계정과 리전에 배포할지”를 코드와 설정으로 관리합니다.

 

EC2 Image Builder의 핵심 개념

EC2 Image Builder를 이해하려면 몇 가지 구성 요소를 알아야 합니다.

1. Image Pipeline

Image Pipeline은 이미지 빌드 자동화의 중심입니다. 파이프라인은 AMI 또는 컨테이너 이미지를 생성하기 위한 전체 흐름을 정의합니다. AWS 문서에 따르면 Image Pipeline은 이미지 레시피 또는 컨테이너 레시피와 연결되며, 이미지 빌드 수명주기의 build, validation, test 단계를 정의합니다. 또한 인프라 구성과 배포 구성을 연결할 수 있습니다.

쉽게 말하면 파이프라인은 다음 질문에 대한 답입니다.

“언제, 어떤 기준으로, 어디에서 이미지를 만들고, 어떻게 테스트한 뒤, 어디로 배포할 것인가?”

2. Image Recipe

Image Recipe는 AMI를 만들기 위한 설계도입니다. 어떤 베이스 AMI에서 시작할지, 어떤 컴포넌트를 적용할지 정의합니다. AWS 문서에 따르면 Image Recipe는 base image와 components를 정의하며, 기본적으로 하나의 레시피에는 build component와 test component를 포함해 최대 20개의 컴포넌트를 적용할 수 있습니다. 한 번 만든 레시피는 직접 수정할 수 없고, 변경하려면 새 레시피 또는 새 버전을 만들어야 합니다.

 

예를 들면 다음과 같은 레시피를 만들 수 있습니다.

Base Image: Amazon Linux 2023
Build Components:
- yum update
- nginx 설치
- CloudWatch Agent 설치
- 보안 설정 적용

Test Components:
- nginx 서비스 상태 확인
- 80 포트 응답 확인
- SSM Agent 동작 확인

 

3. Component

Component는 실제로 이미지 안에서 실행되는 작업 단위입니다. 패키지를 설치하거나, 설정 파일을 수정하거나, 서비스를 활성화하거나, 테스트 명령을 실행하는 역할을 합니다.

 

Image Builder의 컴포넌트는 YAML 또는 JSON 문서로 작성할 수 있으며, AWS Task Orchestrator and Executor, 즉 AWSTOE를 사용해 실행됩니다. AWS 문서에 따르면 AWSTOE는 복잡한 워크플로를 오케스트레이션하고, 시스템 구성을 변경하고, YAML 기반 스크립트 컴포넌트로 시스템을 테스트하는 데 사용됩니다.

 

간단한 예시는 다음과 같습니다.

name: InstallNginx
description: Install and enable nginx
schemaVersion: 1.0

phases:
  - name: build
    steps:
      - name: InstallNginx
        action: ExecuteBash
        inputs:
          commands:
            - sudo dnf update -y
            - sudo dnf install -y nginx
            - sudo systemctl enable nginx

  - name: validate
    steps:
      - name: ValidateNginx
        action: ExecuteBash
        inputs:
          commands:
            - nginx -v

  - name: test
    steps:
      - name: TestNginxService
        action: ExecuteBash
        inputs:
          commands:
            - sudo systemctl start nginx
            - systemctl is-active nginx

 

이 컴포넌트는 Amazon Linux 2023 기준으로 nginx를 설치하고, 설치 여부를 검증하고, 서비스 실행 상태를 테스트하는 예시입니다.

 

4. Infrastructure Configuration

Infrastructure Configuration은 이미지를 빌드하고 테스트할 때 어떤 EC2 인스턴스 환경을 사용할지 정의합니다.

 

여기에는 IAM role, instance type, VPC, subnet, security group, SNS 알림, 로그 저장 위치, 장애 발생 시 인스턴스 유지 여부 등이 포함됩니다. AWS 문서에서는 Image Builder가 빌드 및 테스트 인스턴스에서 컴포넌트를 다운로드하고 실행하며, CloudWatch에 로그를 업로드하고, 레시피에서 요구하는 추가 작업을 수행하기 위해 instance profile 권한을 사용한다고 설명합니다.

 

실무에서는 이 구성이 상당히 중요합니다. 예를 들어 사내 전용 패키지 저장소나 프라이빗 S3 버킷에서 파일을 가져와야 한다면, 빌드 인스턴스가 해당 네트워크와 권한을 가져야 합니다.

5. Distribution Configuration

Distribution Configuration은 완성된 이미지를 어디로 배포할지 정의합니다.

예를 들어 다음과 같은 배포가 가능합니다.

- us-east-1 리전에 AMI 생성
- ap-northeast-2 리전으로 AMI 복사
- 운영 계정에 AMI 공유
- 특정 AWS Organizations OU에 공유
- KMS 키로 AMI 암호화
- Launch Template과 연결

 

AWS 문서에 따르면 Image Builder 파이프라인에서는 AMI 또는 컨테이너 이미지를 배포할 AWS 리전을 지정할 수 있고, AMI의 경우 KMS 키 암호화, AWS 계정 및 Organizations 공유, License Manager 연결, Launch Template 설정도 구성할 수 있습니다.

EC2 Image Builder의 동작 흐름

EC2 Image Builder의 이미지 생성 과정은 크게 세 단계로 볼 수 있습니다.

1단계: Build

Build 단계에서는 베이스 이미지를 기반으로 EC2 빌드 인스턴스를 실행하고, 여기에 build component를 적용합니다. 예를 들어 패키지 설치, OS 설정 변경, 보안 하드닝, 에이전트 설치 같은 작업이 이 단계에서 수행됩니다.

2단계: Test

Build가 끝나면 Image Builder는 스냅샷 또는 컨테이너 이미지를 만들고, 테스트 단계로 넘어갑니다. AMI 워크플로에서는 생성된 스냅샷에서 테스트용 EC2 인스턴스를 새로 실행한 뒤 test component를 수행합니다. 테스트가 실패하면 배포하지 않습니다. AWS 문서에서도 Image Builder는 구성된 테스트가 모두 성공한 경우에만 이미지를 배포한다고 설명합니다.

3단계: Distribution

테스트가 성공하면 Distribution 단계에서 최종 이미지를 지정된 리전, 계정, 조직 단위로 배포합니다. AWS 문서에 따르면 Image Builder의 이미지 생성 워크플로는 build, test, distribution 단계를 포함하며, distribution 단계에서는 AMI copy, image attribute modification, image sharing 같은 작업이 수행됩니다.

 

보안 관점에서의 장점

EC2 Image Builder의 가장 큰 장점은 “보안 기준을 이미지 생성 단계에서부터 표준화할 수 있다”는 점입니다.

운영 중인 EC2에 나중에 보안 설정을 적용하는 방식은 누락이 생기기 쉽습니다. 반면 Image Builder를 사용하면 표준 보안 설정이 반영된 AMI를 먼저 만들고, 그 AMI만 사용해 인스턴스를 배포할 수 있습니다.

 

예를 들어 다음과 같은 보안 기준을 이미지에 포함할 수 있습니다.

- 최신 OS 패치 적용
- 불필요한 패키지 제거
- SSH root 로그인 차단
- IMDSv2 사용 권장
- CloudWatch Agent 설치
- SSM Agent 활성화
- EDR 또는 백신 에이전트 설치
- CIS/STIG 기반 하드닝
- Inspector 기반 취약점 검증

 

AWS 문서에서도 Image Builder는 보안 취약점 노출을 줄이는 이미지를 만들 수 있고, 규제 산업을 위한 설정 모음을 제공하며, STIG 표준에 맞는 compliant image를 만드는 데 활용할 수 있다고 설명합니다.

 

다만 Image Builder를 사용한다고 자동으로 모든 규정 준수가 보장되는 것은 아닙니다. AWS 보안 모범 사례 문서에서도 Image Builder 파이프라인이 정리 스크립트를 실행해 보안 모범 사례를 돕지만, 사용자가 스크립트 일부를 건너뛰거나 user data를 재정의할 수 있기 때문에 결과 이미지가 특정 규제 기준을 반드시 만족한다고 볼 수는 없다고 설명합니다.

 

비용 구조

EC2 Image Builder 서비스 자체는 사용자 정의 AMI 또는 컨테이너 이미지를 생성하는 데 별도 비용이 없습니다. 다만 이미지 생성 과정에서 사용되는 다른 AWS 리소스에는 표준 요금이 부과됩니다. AWS 문서에서는 비용이 발생할 수 있는 항목으로 EC2 인스턴스 실행, S3 로그 저장, Amazon Inspector 검증, EBS Snapshot 저장, ECR 이미지 저장, ECR push/pull 등을 언급합니다.

실무적으로 비용을 줄이려면 다음을 신경 써야 합니다.

- 빌드 인스턴스 타입을 과도하게 크게 잡지 않기
- 빌드 실패 시 인스턴스 유지 옵션을 켜두고 방치하지 않기
- 오래된 AMI와 EBS Snapshot 정리하기
- 필요 없는 리전 복사 줄이기
- 컨테이너 이미지라면 ECR lifecycle policy도 함께 관리하기

 

Lifecycle Policy로 오래된 이미지 정리하기

이미지 자동화에서 자주 놓치는 부분이 “삭제 자동화”입니다. AMI를 계속 만들기만 하고 정리하지 않으면 EBS Snapshot 비용이 계속 증가할 수 있습니다.

 

EC2 Image Builder는 Lifecycle Policy를 통해 오래된 이미지를 자동으로 deprecate, disable, delete할 수 있습니다. AWS 문서에 따르면 Image Builder lifecycle management policy는 오래된 이미지와 관련 리소스의 deprecating, disabling, deleting을 자동화할 수 있으며, 다른 AWS 계정, Organizations, OU, 리전에 배포된 리소스까지 관리 범위에 포함할 수 있습니다.

 

2026년 2월에는 lifecycle policy에 wildcard pattern 지원이 추가되었습니다. 예를 들어 my-recipe-1.x.x 같은 패턴을 사용해 여러 recipe 버전에 정책을 적용할 수 있어, 레시피가 많아지는 환경에서 운영 부담을 줄일 수 있습니다.

 

실무에서 많이 쓰는 구성 예시

다음은 기업 환경에서 자주 쓰는 EC2 Image Builder 구성입니다.

1. Base Image
   - Amazon Linux 2023 또는 Windows Server 2022

2. Build Components
   - OS 최신 패치
   - CloudWatch Agent 설치
   - SSM Agent 확인
   - 보안 에이전트 설치
   - 공통 운영 스크립트 배치
   - SSH 또는 RDP 보안 설정

3. Test Components
   - 서비스 상태 확인
   - 포트 응답 확인
   - SSM 연결 확인
   - 로그 수집 확인
   - 취약점 검사 결과 확인

4. Infrastructure Configuration
   - 빌드용 private subnet
   - S3, SSM, ECR, CloudWatch 접근 권한
   - 로그 저장용 S3 bucket
   - 실패 시 인스턴스 유지 여부 선택

5. Distribution Configuration
   - 개발 계정, 운영 계정에 AMI 공유
   - 서울 리전 및 DR 리전에 AMI 복사
   - KMS 암호화 적용
   - Launch Template과 연계

6. Lifecycle Policy
   - 최신 3개 이미지만 유지
   - 90일 지난 이미지는 deprecate
   - 180일 지난 이미지는 delete

 

Packer와의 차이

EC2 Image Builder를 이야기할 때 HashiCorp Packer와 비교하는 경우가 많습니다.

 

Packer는 멀티 클라우드 이미지 빌드에 강하고, 코드 기반 이미지 빌드 자동화에 익숙한 팀에게 적합합니다. 반면 EC2 Image Builder는 AWS 네이티브 서비스와의 통합이 강합니다. AWS Organizations, RAM, Inspector, ECR, KMS, SSM, CloudWatch, SNS 등과 자연스럽게 연결할 수 있습니다.

 

따라서 AWS 중심의 운영 환경이라면 EC2 Image Builder가 관리형 서비스라는 장점이 있고, 멀티 클라우드나 복잡한 커스텀 빌드 체인이 필요하다면 Packer가 더 적합할 수 있습니다. 둘 중 하나만 써야 하는 것은 아니고, 조직의 운영 방식에 맞춰 선택하면 됩니다.

 

EC2 Image Builder를 도입하면 좋은 경우

EC2 Image Builder는 다음 상황에서 특히 유용합니다.

- 매월 정기적으로 패치된 AMI를 만들어야 하는 경우
- 개발, 검증, 운영 계정에 동일한 표준 AMI를 배포해야 하는 경우
- 보안 하드닝 기준을 이미지에 미리 반영해야 하는 경우
- 수동 AMI 생성 작업을 줄이고 싶은 경우
- 오래된 AMI와 Snapshot 정리까지 자동화하고 싶은 경우
- Auto Scaling Group, Launch Template, EKS Managed Node Group 등에 표준 AMI를 쓰고 싶은 경우

 

반대로 단발성 테스트 인스턴스 몇 대만 운영하는 환경이라면 처음부터 Image Builder를 구성하는 것이 오히려 과할 수 있습니다. 하지만 운영 계정이 여러 개이고 보안 기준이 명확한 조직이라면, 표준 AMI 파이프라인을 만드는 것이 장기적으로 훨씬 안정적입니다.

 

마무리

EC2 Image Builder는 단순히 AMI를 자동으로 만드는 도구가 아닙니다. 운영체제 패치, 보안 설정, 에이전트 설치, 테스트, 배포, 수명주기 관리를 하나의 표준 파이프라인으로 묶어주는 이미지 관리 자동화 서비스입니다.

 

클라우드 운영에서 중요한 것은 “인스턴스를 빨리 만드는 것”이 아니라 “항상 같은 기준으로 안전하게 만드는 것”입니다. EC2 Image Builder는 이 기준을 코드와 파이프라인으로 관리하게 해줍니다. 특히 보안 기준이 중요한 조직, 여러 계정과 리전을 운영하는 조직, 반복적인 AMI 생성 작업이 많은 조직이라면 충분히 검토할 가치가 있습니다.