AWS AMI로 일관된 EC2 서버 환경 배포하기

AWS AMI의 구성과 유형, 생성·공유·복사 방식부터 골든 이미지, 재해 복구, 보안 관리와 컨테이너 대안까지 정리한다.

2026-08-14 · 최초 발행 2025-06-04

EC2 인스턴스를 같은 상태로 시작시키는 AMI

AMI(Amazon Machine Image)는 AWS에서 가상 서버를 띄울 때 사용하는 기본 이미지 템플릿이다. 운영체제뿐 아니라 애플리케이션 서버와 애플리케이션 구성까지 포함할 수 있으므로, 하나의 AMI에서 동일한 환경의 EC2 인스턴스를 여러 개 생성할 수 있다.

실제로 실행되는 인스턴스는 AMI의 사본이다. AMI는 리전 단위로 관리되며, 필요하면 다른 리전으로 복사할 수 있다.

이미지에 담기는 정보

AMI에는 인스턴스 부팅과 연결되는 정보가 함께 들어간다. 루트 볼륨 템플릿은 부팅에 필요한 이미지를 제공하고, 권한 정보는 어느 AWS 계정이 해당 AMI를 사용할 수 있는지 정의한다. 블록 디바이스 매핑은 인스턴스 시작 시 연결할 볼륨을 지정한다.

AMI루트 볼륨 템플릿권한 정보블록 디바이스 매핑OS애플리케이션 서버애플리케이션인스턴스 #1인스턴스 #2인스턴스 #3

어떤 AMI를 선택할지

AWS가 제공하는 AMI는 Amazon Linux, Ubuntu, Windows Server 등 기본 운영체제를 중심으로 제공되며, 보안 패치가 적용되고 AWS 환경에 맞춰져 있다.

AWS Marketplace AMI는 써드파티 벤더의 애플리케이션이나 솔루션이 사전 설치된 이미지다. 라이선스 비용이 포함될 수 있다.

커뮤니티 AMI는 사용자 커뮤니티가 공유한 특수 목적 구성을 활용할 수 있지만, 사용 전 출처 확인과 보안 검증이 필요하다.

사용자 정의 AMI는 기존 인스턴스에서 직접 생성한다. 조직의 표준 소프트웨어와 설정을 이미지로 고정해야 할 때 적합하다.

인스턴스 구성에서 이미지 발행까지

AMI는 필요한 소프트웨어와 구성을 적용한 EC2 인스턴스에서 만든다. 데이터 일관성을 위해 인스턴스를 중지하는 것이 권장되지만 필수는 아니다. 이후 콘솔, CLI 또는 API로 생성을 요청하면 AMI가 Amazon S3에 저장되고 고유 ID가 부여된다.

S3AWSInstanceUserS3AWSInstanceUser소프트웨어 설치 및 구성인스턴스 중지AMI 생성 요청인스턴스 스냅샷 생성스냅샷 저장저장 완료AMI ID 반환

생성한 이미지는 특정 AWS 계정과 공유할 수 있으며, 퍼블릭 또는 프라이빗 공유 설정을 선택할 수 있다. 조직 내부에 표준 이미지를 배포하는 경우에 유용하다.

리전 간 복사도 가능하다. 글로벌 서비스 배포나 재해 복구 전략에서 다른 리전에 이미지를 준비하는 방식으로 사용할 수 있다.

AMI 자체를 직접 수정할 수는 없다. 이미지를 기반으로 인스턴스를 시작해 변경한 뒤 새 AMI를 만들어야 한다. 설명과 공유 설정 같은 일부 속성은 직접 변경할 수 있다. 불필요한 AMI를 삭제하면 스토리지 비용을 줄일 수 있고, 연결된 스냅샷도 함께 삭제하는 편이 비용 측면에서 효율적이다. AMI 삭제는 사용 중인 인스턴스에 영향을 주지 않는다.

골든 이미지와 자동화된 운영

조직 표준 소프트웨어와 설정을 포함한 골든 이미지(Golden Image)를 기본 AMI로 두면 환경별 이미지를 일관된 방식으로 관리할 수 있다. 이는 보안 규정 준수와 패치 관리 자동화, 애플리케이션 배포 시간 단축에 연결된다.

기본 AMI개발 환경용 AMI테스트 환경용 AMI운영 환경용 AMI개발 인스턴스테스트 인스턴스운영 인스턴스

CloudFormation, Terraform 같은 인프라 as 코드(IaC)와 AMI를 연결하면 인프라 정의에 이미지 선택을 포함할 수 있다. CI/CD 파이프라인에 AMI 생성과 테스트를 넣거나, Packer 같은 도구로 이미지 생성을 자동화하는 방식도 가능하다.

운영 중에는 불필요한 AMI를 정기적으로 정리하고, 목적별 버전 관리 체계를 둬야 한다. 서비스가 여러 리전에 걸쳐 있다면 리전별 복제 전략도 함께 관리 대상이 된다.

배포와 복구에서의 활용

금융 서비스 회사 A는 기본 보안 강화 Linux AMI를 만들고, 웹 서버와 애플리케이션 서버 계층별로 이미지를 구성했다. 이를 Auto Scaling 그룹에 연결해 자동 확장과 축소를 구현했으며, 배포 시간은 75% 단축되고 보안 취약점은 30% 감소했다.

제조업체 B는 핵심 시스템의 주기적 AMI 생성을 자동화하고 다른 리전으로 복제했다. 재해가 발생하면 백업 AMI로 시스템을 복구하는 방식이며, RTO(Recovery Time Objective)는 4시간에서 30분으로 단축됐다.

이미지에 남기면 안 되는 정보

AMI를 만들기 전에는 SSH 키, 비밀번호, 토큰 같은 민감 정보를 제거해야 한다. 커뮤니티 AMI를 사용할 때는 출처를 확인하고 보안 스캔을 수행한다.

저장 데이터를 보호하려면 EBS 스냅샷 암호화를 적용할 수 있다. AMI 생성, 공유, 삭제 같은 작업은 IAM 정책으로 권한을 제한해 관리한다.

이미지 기반 배포가 맞지 않는 경우

대용량 AMI는 저장 비용을 늘리고 인스턴스 시작 시간을 지연시킬 수 있다. 이 경우 최소한의 AMI와 사용자 데이터 스크립트를 조합하는 방식을 고려할 수 있다.

AMI가 늘어날수록 업데이트를 일관되게 유지하기 어려워진다. EC2 Image Builder나 패치 관리 자동화가 대안이 될 수 있다. 더 가볍고 이식성 높은 배포 단위가 필요하다면 ECS, EKS 같은 컨테이너 서비스를 검토할 수 있다.

배포 전략AMI 기반컨테이너 기반전체 VM 일관성부팅 시간 길음가벼움/이식성빠른 배포

AMI는 표준 서버 환경, 자동 확장, 재해 복구에 사용할 수 있는 AWS의 핵심 배포 단위다. 컨테이너와 서버리스가 확산되는 환경에서도, AMI는 이들과 상호보완적으로 하이브리드 클라우드의 일관된 배포 전략을 구성하는 역할을 맡는다.

AWSAMIEC2클라우드 인프라서버 배포