AMI 갱신 계획: 현황 분석 및 우선순위 정리

들어가며

복구 이야기를 하다가 "이 서버 백업 있나요?"라는 질문을 받았다. 있다고 답하려다 멈췄다. AMI가 있긴 한데 언제 만든 것인지 몰랐기 때문이다.

백업은 있다와 없다로 나뉘지 않는다. 언제 것인가까지 답해야 쓸 수 있는 백업이다. 2년 전 AMI로 복원하면 인스턴스는 뜨지만, 그 사이의 패치와 설정 변경이 전부 사라진 서버가 뜬다. 복원에 성공하고도 서비스는 못 올리는 상태가 될 수 있다.

그래서 running 상태인 EC2 전체를 놓고 AMI 보유 현황부터 셌다.

현황 분석

running 인스턴스 36대를 기준으로 보면 이렇다.

숫자를 늘어놓고 나서야 문제가 분명해졌다. 절반은 백업이 아예 없고, 나머지 절반은 대부분 2년이 넘은 것이었다. 이 상태에서 "백업이 있다"는 말은 사실상 아무 의미가 없다.

1. AMI 갱신 필요 (기존 AMI가 오래됨)

오래된 AMI가 왜 위험한가

복원이 실패해서가 아니라, 복원에 성공해도 쓸 수 없어서 위험하다.

[이상적인 복구]
AMI 복원 → 서비스 기동 → 끝

[2년 된 AMI로 복구]
AMI 복원 → OS 패치 없음, 설정 파일 예전 버전, 설치된 패키지 구버전
        → 그 사이의 변경을 사람이 기억해서 다시 적용
        → 무엇이 바뀌었는지 아는 사람이 있어야 가능

시간이 지날수록 AMI와 실제 서버 사이의 차이가 벌어진다. 이 차이를 메우는 일이 복구 시간의 대부분을 차지하고, 그 시간은 예측할 수도 없다. 장애 상황에서 가장 곤란한 종류의 작업이다.

여기에 더해 AMI는 그 시점의 디스크 상태다. 데이터가 계속 쌓이는 서버라면 AMI만으로는 부족하고, 최신 데이터는 EBS 스냅샷에서 가져와야 한다. 둘을 조합하는 절차는 EC2 복원 가이드에 정리했다.

2. AMI 미보유 (신규 생성 필요)

증설하면서 추가된 서버가 많다. 처음 구축할 때는 AMI를 만들어 두고, 나중에 붙인 서버는 그 절차가 빠지는 패턴이 반복됐다. 백업 누락은 대개 게을러서가 아니라 절차가 구축 시점에만 있어서 생긴다.

3. AMI 생성 우선순위

전부 만들자는 계획은 실행되지 않는다. 그래서 세 기준으로 나눴다.

• 운영 여부: 운영 서버가 먼저다
• AMI 유무: 아예 없는 쪽이 오래된 쪽보다 급하다
• 데이터 보유: DB처럼 데이터가 있는 서버는 AMI만으로 부족하므로 스냅샷 정책을 함께 확인한다

긴급 (운영 서버 + AMI 없음)

높음 (운영 서버 + AMI 오래됨)

보통 (개발/QA 서버)

4. AMI 생성 방법

# 기본 AMI 생성 (재부팅 없이)
aws ec2 create-image \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --name "서버명_AMI_YYYYMMDD" \
  --description "서버 설명" \
  --no-reboot

--no-reboot 옵션은 서비스 중단 없이 AMI를 생성하지만, 파일시스템 일관성이 100% 보장되지 않는다. 완벽한 일관성이 필요하면 점검 시간에 --no-reboot 없이 생성한다.

이 선택은 결국 맞바꿈이다. 무중단으로 만든 AMI는 "대체로 쓸 수 있는" 백업이고, 재부팅하고 만든 AMI는 "확실히 쓸 수 있는" 백업이다. 운영 서버는 일단 무중단으로 만들어 두고, 정기 점검 때 재부팅 방식으로 다시 만드는 식으로 나눴다. 완벽한 백업을 기다리다가 백업이 없는 상태로 지내는 것보다 낫다.

5. AMI 네이밍 규칙

{서비스명}_{역할}_{날짜}

예시:

• [SERVICE]_COORD_01_AMI_20260416
• [PROJECT_B]_PRD_01_AMI_20260416
• [PROJECT_A]_PRD_01_AMI_20260416
• [PORTAL]_DB_01_AMI_20260416

날짜를 이름에 넣는 이유는 이번 조사에서 겪은 것 때문이다. 생성일을 확인하려고 콘솔을 한 번 더 들어가야 한다면, 급할 때는 확인하지 않고 쓰게 된다. 목록에서 바로 보이는 것과 클릭해야 보이는 것의 차이는 생각보다 크다.

6. 앞으로의 방향

수작업으로 만든 백업은 반드시 다시 오래된다. 그래서 이 계획의 끝은 자동화여야 한다.

• 운영 서버 AMI는 최소 분기 1회 갱신
• 주요 패치나 배포 후에는 AMI 재생성
• AWS Backup 또는 EventBridge + Lambda로 태그 기반 자동 생성 검토
• 보존 정책을 함께 정해 오래된 AMI와 스냅샷을 자동 정리 (비용 절감)

마지막 항목을 빼면 자동화가 곧 비용 증가로 돌아온다. AMI는 그 자체로 요금이 붙지 않지만, 연결된 EBS 스냅샷 저장 비용이 계속 쌓인다. 만드는 규칙과 지우는 규칙은 같이 만들어야 한다. 이건 S3 버킷 버전 관리에서 라이프사이클을 함께 설정한 것과 같은 이야기다.

배운 점

백업은 있다와 없다가 아니라 언제 것인가의 문제였다. 오래된 AMI로 복원하면 그 사이의 패치와 설정 변경이 전부 사라진다. 복원에 성공해도 운영에 쓸 수 없는 상태가 될 수 있다는 걸 알고 나서, 백업 현황을 볼 때 보유 여부가 아니라 경과 기간을 먼저 보게 됐다.

현황을 숫자로 만들고 나서야 우선순위가 생겼다. "백업 좀 챙겨야 하는데"는 몇 달째 같은 문장으로 남아 있었는데, 36대 중 1대만 최근 백업이 있다는 표를 만든 다음에야 작업이 시작됐다. 막연한 문제의식은 계획이 되지 못한다.

구축 시점에만 있는 절차는 반드시 빠진다. AMI가 없는 18대는 대부분 나중에 증설된 서버였다. 사람의 성실함에 기대는 절차는 언젠가 끊기기 때문에, 이 작업의 결론은 목록을 채우는 게 아니라 자동 생성으로 넘기는 것이 됐다.

만드는 규칙과 지우는 규칙은 한 세트다. 자동화만 걸고 정리를 안 하면 스냅샷 비용이 조용히 늘어난다. 같은 교훈을 S3 버킷 버전 관리에서도 확인했다.

이어 읽기

• EC2 복원 가이드: AMI + EBS 스냅샷 조합 복원: 이 백업을 실제로 사용하는 절차
• EC2 StatusCheckFailed 기반 장애 감지 및 자동 복구 알람 시스템: 백업이 필요해지는 상황
• S3 버킷 버전 관리 적용 가이드: 보호 설정과 정리 정책을 함께 세운 사례