☁️ 클라우드

AMI

Amazon Machine Image

AWS EC2 인스턴스의 템플릿. OS, 소프트웨어 구성 포함. 빠른 서버 복제.

📖 상세 설명

AMI(Amazon Machine Image)는 AWS EC2 인스턴스를 시작하는 데 필요한 모든 정보가 담긴 템플릿입니다. 운영체제(Amazon Linux, Ubuntu, Windows Server 등), 애플리케이션 서버, 런타임, 애플리케이션 코드, 시스템 설정 등이 하나의 이미지로 패키징되어 있어 동일한 환경의 서버를 즉시 복제할 수 있습니다.

AMI는 2006년 EC2 서비스 출시와 함께 도입되었습니다. 물리 서버 시대에는 새 서버를 구축하려면 OS 설치, 패키지 설치, 설정 등에 수시간이 걸렸지만, AMI를 사용하면 수분 내에 완전히 동일한 환경의 서버를 무한히 복제할 수 있습니다. 이것이 클라우드 네이티브 인프라의 핵심 개념인 "Immutable Infrastructure"의 기반이 됩니다.

AMI는 EBS 스냅샷을 기반으로 합니다. 루트 볼륨과 추가 볼륨의 스냅샷, 시작 권한(어떤 AWS 계정이 이 AMI를 사용할 수 있는지), 블록 디바이스 매핑(인스턴스 시작 시 연결할 볼륨 정의) 정보를 포함합니다. HVM(Hardware Virtual Machine) 가상화를 사용하며, x86_64와 ARM(Graviton) 아키텍처를 지원합니다.

실무에서 AMI는 Auto Scaling의 Launch Template에 지정되어 자동으로 동일한 서버를 확장/축소하는 데 사용됩니다. 골든 이미지(Golden AMI) 전략을 통해 보안 패치와 기본 설정이 적용된 베이스 이미지를 만들어 조직 전체에서 표준화된 서버를 운영할 수 있습니다.

💻 코드 예제

# 현재 리전의 최신 Amazon Linux 2023 AMI 찾기
aws ec2 describe-images \
  --owners amazon \
  --filters "Name=name,Values=al2023-ami-2023*-x86_64" \
            "Name=state,Values=available" \
  --query 'Images | sort_by(@, &CreationDate) | [-1].ImageId' \
  --output text

# 실행 중인 인스턴스에서 AMI 생성
aws ec2 create-image \
  --instance-id i-1234567890abcdef0 \
  --name "my-app-v1.2.3-$(date +%Y%m%d)" \
  --description "Production web server with Node.js 20" \
  --no-reboot

# AMI 생성 상태 확인
aws ec2 describe-images \
  --image-ids ami-0123456789abcdef0 \
  --query 'Images[0].State'

# AMI로 인스턴스 시작
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type t3.medium \
  --key-name my-keypair \
  --security-group-ids sg-12345678 \
  --subnet-id subnet-12345678 \
  --count 1

# 다른 리전으로 AMI 복사
aws ec2 copy-image \
  --source-region us-east-1 \
  --source-image-id ami-0123456789abcdef0 \
  --name "my-app-v1.2.3-ap-northeast-2" \
  --region ap-northeast-2

# 오래된 AMI 삭제 (deregister + snapshot 삭제)
aws ec2 deregister-image --image-id ami-old123456
aws ec2 delete-snapshot --snapshot-id snap-old123456

🗣️ 실무에서 이렇게 말하세요

💬 배포 회의에서
"이번 배포는 새 AMI로 진행합니다. Packer로 빌드한 ami-0abc123이 테스트 완료됐고, Launch Template 버전 업데이트 후 ASG에서 인스턴스 리프레시하면 무중단으로 롤아웃됩니다. 문제 생기면 이전 AMI로 롤백하면 돼요."
💬 면접에서
"골든 AMI 전략을 적용해서 보안 패치, CloudWatch Agent, SSM Agent가 사전 설치된 베이스 AMI를 만들고, 각 팀에서는 이 베이스 위에 애플리케이션만 추가하는 방식으로 운영했습니다. Packer와 CI/CD 파이프라인을 연동해서 매월 보안 패치된 새 AMI를 자동 빌드했습니다."
💬 트러블슈팅에서
"Auto Scaling에서 새 인스턴스가 시작 안 되는 건 AMI가 삭제됐거나 다른 리전에 있어서 그래요. Launch Template에 지정된 AMI ID가 현재 리전에 존재하는지 확인하고, 없으면 새 AMI로 업데이트하거나 다른 리전에서 복사해와야 합니다."

⚠️ 흔한 실수 & 주의사항

AMI에 시크릿 포함

AMI에 API 키, 비밀번호, SSH 키 등을 포함하면 안 됩니다. AMI가 공유되거나 유출되면 보안 사고로 이어집니다. 시크릿은 Secrets Manager나 Parameter Store에서 런타임에 가져오세요.

AMI 수명 주기 미관리

오래된 AMI와 연결된 EBS 스냅샷을 삭제하지 않으면 스토리지 비용이 계속 발생합니다. AMI Lifecycle Policy를 설정하거나 정기적으로 미사용 AMI를 정리하세요. 특히 Packer로 빈번하게 빌드하면 AMI가 빠르게 쌓입니다.

올바른 AMI 전략

베이스 AMI + User Data 조합으로 유연성을 확보하세요. 베이스 AMI는 OS와 공통 패키지만 포함하고, 애플리케이션 배포는 User Data나 CodeDeploy로 처리하면 AMI 빌드 빈도를 줄일 수 있습니다. Graviton(ARM) AMI는 x86 대비 최대 40% 가성비가 좋으니 검토해보세요.

🔗 관련 용어

📚 더 배우기