☁️ 클라우드

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로 업데이트하거나 다른 리전에서 복사해와야 합니다."

이 주제로 모의면접 보기 → WIA SOOM AI 면접 · 무료로 시작

⚠️ 흔한 실수 & 주의사항

❌
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% 가성비가 좋으니 검토해보세요.

🔗 관련 용어

📚 더 배우기