EC2を運用していると、繰り返し発生する作業があります。
それは、オペレーティングシステムをインストールし、セキュリティパッチを適用し、エージェントをインストールし、ログ設定を行い、会社の標準セキュリティ設定を反映させた後、AMIを作成して配布する作業です。規模が小さい場合は手動でも可能ですが、アカウント、リージョン、運用環境が増えるにつれて、イメージ管理自体が運用上の負担となります。
この問題を解決するためのAWSサービスがEC2 Image Builderです。EC2 Image Builderは、カスタムAMIまたはコンテナイメージを自動的に作成、テスト、配布、管理するのに役立つフルマネージドサービスです。AWSの公式ドキュメントでも、「カスタマイズされ、セキュアで、最新のサーバーイメージ」の作成と配布を自動化するサービスであると説明されています。
EC2 Image Builderが必要な理由
EC2インスタンスを毎回新しく作成するたびに、次の作業を繰り返すと考えてみましょう。
オペレーティングシステムのパッチ適用、セキュリティエージェントのインストール、CloudWatch Agentの設定、SSM Agentの確認、会社標準アカウント設定、不要なパッケージの削除、CISまたはSTIGベースのハードニング、アプリケーションランタイムのインストール、デプロイ前のテスト実行。
このプロセスを人が直接行うと、次の問題が発生します。
- 第一に、イメージごとに設定が少しずつ異なる可能性があります。
- 第二に、セキュリティパッチが漏れる可能性があります。
- 第三に、どのイメージがどのような基準で作成されたのか追跡が困難です。
- 第四に、複数のアカウントやリージョンに同じAMIを配布するのが難しいです。
- 第五に、古いAMIが残り続け、コストとセキュリティリスクを生み出します。
EC2 Image Builderは、これらのプロセスをパイプラインとして定義します。つまり、「どのベースイメージを使用するか」、「どのパッケージと設定を適用するか」、「どのテストに合格する必要があるか」、「どのアカウントとリージョンに配布するか」をコードと設定で管理します。
EC2 Image Builderの主要な概念
EC2 Image Builderを理解するには、いくつかの構成要素を知る必要があります。
1. イメージパイプライン
イメージパイプラインは、イメージビルド自動化の中心です。パイプラインは、AMIまたはコンテナイメージを作成するための全体的なフローを定義します。AWSのドキュメントによると、イメージパイプラインはイメージレシピまたはコンテナレシピと関連付けられ、イメージビルドのライフサイクルのビルド、検証、テストの各段階を定義します。また、インフラストラクチャ構成と配布構成をリンクすることもできます。
簡単に言えば、パイプラインは次の質問への答えです。
「いつ、どのような基準で、どこでイメージを作成し、どのようにテストした後、どこに配布するのか？」
2. イメージレシピ
イメージレシピは、AMIを作成するための設計図です。どのベースAMIから開始し、どのコンポーネントを適用するかを定義します。AWSのドキュメントによると、イメージレシピはベースイメージとコンポーネントを定義し、基本的に1つのレシピにはビルドコンポーネントとテストコンポーネントを含め、最大20個のコンポーネントを適用できます。一度作成したレシピは直接修正できず、変更するには新しいレシピまたは新しいバージョンを作成する必要があります。
例えば、次のようなレシピを作成できます。
Base Image: Amazon Linux 2023
Build Components:
- yum update
- nginx 설치
- CloudWatch Agent 설치
- 보안 설정 적용
Test Components:
- nginx 서비스 상태 확인
- 80 포트 응답 확인
- SSM Agent 동작 확인3. コンポーネント
コンポーネントは、実際にイメージ内で実行される作業単位です。パッケージのインストール、設定ファイルの変更、サービスの有効化、テストコマンドの実行などの役割を果たします。
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. インフラストラクチャ構成
インフラストラクチャ構成は、イメージをビルドおよびテストする際にどのEC2インスタンス環境を使用するかを定義します。
これには、IAMロール、インスタンスタイプ、VPC、サブネット、セキュリティグループ、SNS通知、ログ保存場所、障害発生時のインスタンス保持の有無などが含まれます。AWSのドキュメントでは、Image Builderがビルドおよびテストインスタンスでコンポーネントをダウンロードして実行し、CloudWatchにログをアップロードし、レシピで要求される追加タスクを実行するためにインスタンスプロファイルの権限を使用すると説明されています。
実務では、この構成が非常に重要です。例えば、社内専用のパッケージリポジトリやプライベートS3バケットからファイルを取得する必要がある場合、ビルドインスタンスは該当するネットワークと権限を持っている必要があります。
5. 配布構成
配布構成は、完成したイメージをどこに配布するかを定義します。
例えば、次のような配布が可能です。
- 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連携、起動テンプレート設定も構成できます。
EC2 Image Builderの動作フロー
EC2 Image Builderのイメージ作成プロセスは、大きく3つの段階に分けられます。
ステップ1：ビルド
ビルド段階では、ベースイメージに基づいてEC2ビルドインスタンスを実行し、そこにビルドコンポーネントを適用します。例えば、パッケージのインストール、OS設定の変更、セキュリティハードニング、エージェントのインストールなどの作業がこの段階で実行されます。
ステップ2：テスト
ビルドが完了すると、Image Builderはスナップショットまたはコンテナイメージを作成し、テスト段階に進みます。AMIワークフローでは、作成されたスナップショットからテスト用のEC2インスタンスを新しく起動し、テストコンポーネントを実行します。テストが失敗した場合、配布は行われません。AWSのドキュメントでも、Image Builderは設定されたテストがすべて成功した場合にのみイメージを配布すると説明されています。
ステップ3：配布
テストが成功すると、配布段階で最終イメージが指定されたリージョン、アカウント、組織単位に配布されます。AWSのドキュメントによると、Image Builderのイメージ作成ワークフローにはビルド、テスト、配布の各段階が含まれ、配布段階ではAMIのコピー、イメージ属性の変更、イメージ共有などの作業が実行されます。
セキュリティの観点からの利点
EC2 Image Builderの最大の利点は、「セキュリティ基準をイメージ作成段階から標準化できる」という点です。
運用中のEC2に後からセキュリティ設定を適用する方法は、漏れが生じやすいです。一方、Image Builderを使用すると、標準セキュリティ設定が反映されたAMIを先に作成し、そのAMIのみを使用してインスタンスを配布できます。
例えば、次のようなセキュリティ基準をイメージに含めることができます。
- 최신 OS 패치 적용
- 불필요한 패키지 제거
- SSH root 로그인 차단
- IMDSv2 사용 권장
- CloudWatch Agent 설치
- SSM Agent 활성화
- EDR 또는 백신 에이전트 설치
- CIS/STIG 기반 하드닝
- Inspector 기반 취약점 검증AWSのドキュメントでも、Image Builderはセキュリティ脆弱性の露出を減らすイメージを作成でき、規制産業向けの構成セットを提供し、STIG標準に準拠したイメージを作成するのに活用できると説明されています。
ただし、Image Builderを使用するからといって、すべての規制遵守が自動的に保証されるわけではありません。AWSのセキュリティベストプラクティスドキュメントでも、Image Builderパイプラインがクリーンアップスクリプトを実行してセキュリティベストプラクティスを支援するものの、ユーザーがスクリプトの一部をスキップしたり、ユーザーデータを再定義したりできるため、結果として得られるイメージが特定の規制基準を必ず満たすとは言えないと説明されています。
コスト構造
EC2 Image Builderサービス自体は、カスタムAMIまたはコンテナイメージの作成に別途費用はかかりません。ただし、イメージ作成プロセスで使用される他のAWSリソースには標準料金が課金されます。AWSのドキュメントでは、費用が発生する可能性のある項目として、EC2インスタンスの実行、S3ログ保存、Amazon Inspector検証、EBSスナップショット保存、ECRイメージ保存、ECRプッシュ/プルなどが挙げられています。
実務的にコストを削減するには、次の点に注意する必要があります。
- 빌드 인스턴스 타입을 과도하게 크게 잡지 않기
- 빌드 실패 시 인스턴스 유지 옵션을 켜두고 방치하지 않기
- 오래된 AMI와 EBS Snapshot 정리하기
- 필요 없는 리전 복사 줄이기
- 컨테이너 이미지라면 ECR lifecycle policy도 함께 관리하기ライフサイクルポリシーによる古いイメージのクリーンアップ
イメージ自動化でよく見落とされるのが「削除の自動化」です。AMIを作成し続けるだけでクリーンアップしないと、EBSスナップショットの費用が増加し続ける可能性があります。
EC2 Image Builderは、ライフサイクルポリシーを通じて古いイメージを自動的に非推奨化、無効化、削除できます。AWSのドキュメントによると、Image Builderのライフサイクル管理ポリシーは、古いイメージと関連リソースの非推奨化、無効化、削除を自動化でき、他のAWSアカウント、Organizations、OU、リージョンに配布されたリソースまで管理範囲に含めることができます。
2026年2月には、ライフサイクルポリシーにワイルドカードパターンサポートが追加されました。例えば、my-recipe-1.x.xのようなパターンを使用して複数のレシピバージョンにポリシーを適用できるため、レシピが多くなる環境での運用負担を軽減できます。
実務でよく使われる構成例
以下は、企業環境でよく使われる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일 지난 이미지는 deletePackerとの違い
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を自動的に作成するツールではありません。オペレーティングシステムのパッチ適用、セキュリティ設定、エージェントのインストール、テスト、配布、ライフサイクル管理を1つの標準パイプラインにまとめるイメージ管理自動化サービスです。
クラウド運用において重要なのは、「インスタンスを早く作成すること」ではなく、「常に同じ基準で安全に作成すること」です。EC2 Image Builderは、この基準をコードとパイプラインで管理することを可能にします。特にセキュリティ基準が重要な組織、複数のアカウントやリージョンを運用する組織、繰り返しAMI作成作業が多い組織であれば、十分に検討する価値があります。
コメントを残す