在运营 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. 镜像管道 (Image Pipeline)
镜像管道是镜像构建自动化的核心。管道定义了创建 AMI 或容器镜像的整个流程。根据 AWS 文档，镜像管道与镜像配方或容器配方关联，并定义了镜像构建生命周期的构建 (build)、验证 (validation) 和测试 (test) 阶段。它还可以连接基础设施配置和分发配置。
简单来说，管道回答了以下问题：
“何时、依据何种标准、在哪里创建镜像，如何测试，然后分发到哪里？”
2. 镜像配方 (Image Recipe)
镜像配方是创建 AMI 的蓝图。它定义了从哪个基础 AMI 开始，以及应用哪些组件。根据 AWS 文档，镜像配方定义了基础镜像和组件，并且一个配方通常可以应用最多 20 个组件，包括构建组件和测试组件。一旦创建，配方不能直接修改；要进行更改，必须创建新的配方或新版本。
例如，您可以创建如下配方：Base Image: Amazon Linux 2023
Build Components:
- yum update
- nginx 설치
- CloudWatch Agent 설치
- 보안 설정 적용
Test Components:
- nginx 서비스 상태 확인
- 80 포트 응답 확인
- SSM Agent 동작 확인3. 组件 (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)
基础设施配置定义了在构建和测试镜像时使用哪种 EC2 实例环境。
这包括 IAM 角色、实例类型、VPC、子网、安全组、SNS 通知、日志存储位置以及故障时是否保留实例等。AWS 文档解释说，Image Builder 使用实例配置文件权限在构建和测试实例上下载并运行组件，将日志上传到 CloudWatch，并执行配方所需的额外任务。
在实际操作中，此配置非常重要。例如，如果需要从公司内部的私有软件包存储库或私有 S3 存储桶中获取文件，则构建实例必须具有相应的网络访问权限和权限。
5. 分发配置 (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 账户和组织共享、License Manager 连接以及启动模板设置。
EC2 Image Builder 的操作流程
EC2 Image Builder 的镜像创建过程大致可分为三个阶段。
阶段 1：构建 (Build)
在构建阶段，Image Builder 会基于基础镜像启动一个 EC2 构建实例，并向其应用构建组件。例如，软件包安装、操作系统设置更改、安全加固和代理安装等任务都在此阶段执行。
阶段 2：测试 (Test)
构建完成后，Image Builder 会创建快照或容器镜像，并进入测试阶段。在 AMI 工作流中，会从创建的快照启动一个新的 EC2 测试实例，然后执行测试组件。如果测试失败，则不会分发。AWS 文档也说明，Image Builder 仅在所有配置的测试都成功时才分发镜像。
阶段 3：分发 (Distribution)
如果测试成功，分发阶段会将最终镜像部署到指定的区域、账户和组织单位。根据 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 可以通过生命周期策略自动弃用 (deprecate)、禁用 (disable) 和删除 (delete) 旧镜像。根据 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일 지난 이미지는 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 的组织，它尤其值得考虑。
发表回复