[AWS] EC2 인스턴스 무중단 루트볼륨 교체 방법

EC2 Auto Scaling에 ReplaceRootVolume 전략이 추가되면서, 이제 인스턴스를 종료하지 않고 루트 EBS 볼륨만 교체하는 방식으로 OS 패치와 복구를 할 수 있게 되었습니다.

TL;DR

• 기존 방식: 인스턴스 새로 고침(Instance Refresh) 시 인스턴스를 종료(Terminate) → 새 인스턴스 생성
• 새 방식: 인스턴스는 그대로 두고 루트 EBS 볼륨만 새 AMI 기반으로 교체
• ENI, IP, 추가 EBS, 보안 그룹, IAM Role 등은 그대로 유지됩니다.

실제 동작은 다음과 같습니다.

1. 기존 인스턴스는 계속 실행 중
2. 기존 루트 볼륨 Detach
3. 지정한 AMI로 새 루트 볼륨 생성 후 Attach
4. 인스턴스 재부팅 → 헬스 체크 통과 시 성공 처리
5. 교체가 성공하면 기존 루트 볼륨은 자동 삭제

사전 확인

공식 문서와 실제 검증 글 기준으로, 최소한 아래를 확인하는 것이 좋습니다.

1. Auto Scaling 그룹이 MixedInstancesPolicy 구성인지
   • ReplaceRootVolume 전략은 MixedInstancesPolicy가 설정된 ASG에서만 지원되는 것으로 확인됩니다.
   • 기존에 단일 Launch Template/Launch Configuration만 쓰는 Standard 형식이라면, MixedInstancesPolicy로 전환해야 합니다.
2. 루트 볼륨에 “없어지면 안 되는 데이터”가 없는지
   • 루트 볼륨은 통째로 교체됩니다.
   • 로그나 애플리케이션 데이터는 별도 EBS 데이터 볼륨 / S3 / DB 등에 두는 구조가 필요합니다.
3. User Data가 다시 실행돼도 문제없는지
   • 새 루트 볼륨으로 부팅하면서 cloud-init/User Data가 다시 실행될 수 있습니다.
   • 설치 스크립트, 마이그레이션 스크립트는 idempotent하게 작성하는 것이 안전합니다.

1. MixedInstancesPolicy 기반 Auto Scaling 그룹 준비

이미 MixedInstancesPolicy를 쓰고 있다면 이 단계는 간단히 검토만 해도 됩니다.

1-1. MixedInstancesPolicy 설정

MixedInstancesPolicy는 다음 정보를 포함합니다.

• 기본 Launch Template
• Instance Type Overrides (여러 타입을 섞어서 사용)
• 온디맨드 / 스팟 비율, 가중치 등

ReplaceRootVolume 전략 예제에서도 desired-configuration 안에 MixedInstancesPolicy를 넣어서 새 AMI를 지정합니다.

1-2. 기존 ASG를 MixedInstancesPolicy로 전환

콘솔 기준 대략적인 순서는 다음과 같습니다.

1. EC2 콘솔 → Auto Scaling Groups → 대상 ASG 선택
2. Edit 버튼 클릭
3. Launch template or configuration 섹션에서
   • Launch Template를 사용 중인지 확인
4. Mixed instances policy 섹션 활성화
   • 기본 Launch Template 지정
   • 필요한 경우 Overrides에 인스턴스 타입 추가
5. 변경 사항 저장

자세한 MixedInstancesPolicy 설정은 기존 문서와 크게 다르지 않으므로, 이 글에서는 ReplaceRootVolume와 직접 관련된 부분만 다룹니다.

2. 새 루트 볼륨 소스(AMI) 준비

ReplaceRootVolume는 결국 새로운 AMI를 기준으로 루트 볼륨을 다시 생성하는 기능입니다.

패치 전략은 대략 두 가지로 나뉩니다.

1. 새 AMI 빌드 후 교체
   • 기존 인스턴스(또는 빌드용 인스턴스)에서 OS 패치, 에이전트 업데이트, 설정 변경
   • 이미지 생성(Create Image)으로 새 AMI 생성
2. 기존 루트 스냅샷에서 복구용 AMI 또는 스냅샷 구성
   • 루트 파일 시스템 손상 시, “정상 상태였던 시점” 스냅샷이나 AMI를 루트 볼륨 소스로 사용

어떤 방식을 쓰든, 최종적으로는 ImageId(AMI ID)가 하나 나온다고 보면 됩니다.

3. 콘솔에서 ReplaceRootVolume 인스턴스 새로 고침 실행

AWS 공식 문서는 콘솔에서 인스턴스 새로 고침을 시작하는 방법을 별도 문서로 정리하고 있습니다.

ReplaceRootVolume 전략을 쓰는 경우, 흐름 자체는 기존과 비슷하지만 전략(Strategy) 선택 부분이 추가됩니다.

3-1. Auto Scaling 그룹에서 Instance Refresh 진입

1. EC2 콘솔 → Auto Scaling Groups
2. 대상 ASG 체크
3. 하단 탭에서 Instance refresh 선택
4. Start instance refresh 버튼 클릭

여기까지는 기존 Rolling 방식의 Instance Refresh와 동일합니다.

3-2. 전략(Strategy)에서 ReplaceRootVolume 선택

인스턴스 새로 고침 설정 화면에서, AWS 발표 기준으로 Strategy 또는 이에 해당하는 항목에 다음과 같은 옵션이 존재합니다.

• Rolling (기존 방식: 인스턴스 교체)
• ReplaceRootVolume (루트 볼륨만 교체)

여기서 ReplaceRootVolume을 선택하면 이후 인스턴스 교체 동작이 Terminate & Launch가 아닌 “루트 볼륨 교체 + 재부팅” 방식으로 수행됩니다.

콘솔 UI의 라벨은 시점에 따라 조금 바뀔 수 있기 때문에, 실제 화면에서 “root volume”, “ReplaceRootVolume” 같은 키워드가 있는 옵션을 확인하고 선택하는 쪽이 안전합니다.

3-3. Desired configuration(원하는 구성)에서 새 AMI 지정

ReplaceRootVolume 전략이더라도, “어떤 이미지로 갱신할지”는 여전히 Launch Template 또는 MixedInstancesPolicy의 AMI로 결정됩니다.

콘솔에서는 보통 다음과 같이 진행합니다.

1. Desired configuration / 시작 템플릿 업데이트(Update launch template) 체크
2. 새 버전 Launch Template를 선택하거나, MixedInstancesPolicy의 Overrides에 새 AMI (ImageId)가 반영된 구성을 선택
3. 설정 저장

핵심은 “Instance Refresh 시점에 바라볼 새 AMI”를 여기에 반영하는 것입니다.

3-4. 가용성(Availability) 및 새로 고침 설정

이 부분은 기존 Instance Refresh와 동일하게 설정하면 됩니다.

대표적으로 다음 항목을 조정합니다.

• Min/Max healthy percentage
  • 한 번에 몇 %까지 교체할지
• Instance warmup
  • 새 루트 볼륨으로 부팅된 인스턴스를 “정상”으로 보게 될 때까지 기다리는 시간
• Skip matching
  • 이미 새 AMI를 쓰는 인스턴스는 건너뛸지 여부
• CloudWatch Alarm / Auto rollback
  • 헬스 체크 실패 시 자동 롤백할지

설정 검토 후 Start instance refresh를 누르면 ReplaceRootVolume 전략으로 인스턴스 새로 고침이 시작됩니다.

4. AWS CLI로 ReplaceRootVolume 실행하기

콘솔 대신 자동화를 위해 CLI를 쓰고 싶다면 aws autoscaling start-instance-refresh를 사용합니다.

 

최근 업데이트 기준으로, CLI는 --strategy 옵션에 ReplaceRootVolume 값을 받을 수 있으며, 실제 검증 글에서도 이 값을 사용해 성공적으로 동작한 예제가 소개되어 있습니다.

4-1. 기본 CLI 형태

aws autoscaling start-instance-refresh \ --auto-scaling-group-name <ASG 이름> \ --strategy ReplaceRootVolume \ --desired-configuration '{ "MixedInstancesPolicy": { "LaunchTemplate": { "LaunchTemplateSpecification": { "LaunchTemplateId": "", "Version": "2" }, "Overrides": [ { "InstanceType": "t3.medium", "ImageId": "ami-0123456789abcdef0" } ] } } }' \ --preferences '{ "MinHealthyPercentage": 50, "InstanceWarmup": 300 }' \ --region ap-southeast-1

 

위 예시는 다음을 가정합니다.

• MixedInstancesPolicy가 설정된 ASG
• Launch Template v2에 새 OS 설정 반영
• Overrides에서 ImageId로 새 AMI 지정
• 전체 인스턴스의 50% 이상을 항상 정상 상태로 유지
• 새 루트 볼륨으로 부팅 후 300초 동안 워밍업

--desired-configuration 구조는 기존 Instance Refresh와 동일하지만, 전략만 ReplaceRootVolume으로 바뀐다고 보면 됩니다.

4-2. 진행 상태 확인

• 진행 중/완료 상태는 DescribeInstanceRefreshes API 또는 콘솔의 Instance refresh 탭에서 확인할 수 있습니다.

루트 볼륨 교체 과정에서 실패한 인스턴스는 Auto Scaling이 비정상으로 표시 후 종료 및 재생성할 수 있으므로, 헬스 체크 실패/롤백 정책을 어떻게 가져갈지 사전에 정해두는 것이 좋습니다.

5. 운영 시 체크해야 할 포인트

ReplaceRootVolume 전략을 운영에 넣기 전에, 아래 항목들은 한번씩 점검하는 편이 안전합니다.

1. 루트 볼륨 데이터 소멸
   • 애플리케이션 로그, 로컬 캐시 등을 루트 볼륨에만 두고 있다면 교체 후 모두 사라집니다.
   • 필요한 것들은 별도 데이터 볼륨이나 외부 스토리지로 빼 두는 설계가 필요합니다.
2. User Data / 초기화 스크립트
   • 재실행 시 중복 설치, 중복 계정 생성 같은 문제가 없는지 확인해야 합니다.
   • 가능하면 “이미 설치되어 있으면 스킵” 패턴으로 작성하는 것이 안전합니다.
3. 롤백 전략
   • 새 AMI에 문제가 있을 수 있으므로:
     • Auto rollback 옵션 활성화
     • 문제가 확인되면 이전 AMI로 다시 Instance Refresh를 돌릴 수 있도록 템플릿/구성을 남겨두는 것이 좋습니다.

 

정리

ReplaceRootVolume 전략은 Auto Scaling 그룹에 대해 “인스턴스 ID와 네트워크 아이덴티티는 그대로 두고 OS만 갈아끼우는” 패턴을 공식 기능으로 제공해 줍니다.

• MixedInstancesPolicy 기반 ASG 구성
• 새 AMI 준비
• 콘솔/CLI에서 Instance Refresh를 ReplaceRootVolume 전략으로 실행

이 세 단계만 정리해 두면, 패치나 OS 업데이트, 루트 볼륨 손상 복구까지 같은 흐름으로 처리할 수 있습니다.

CLI나 콘솔의 세부 UI/옵션 이름은 시점에 따라 조금씩 바뀔 수 있기 때문에, 실제 적용 전에 한 번은 소규모 테스트용 ASG에서 돌려보고, 헬스 체크/롤백/모니터링이 원하는 대로 작동하는지 확인하고 운영 그룹에 적용하시는 편이 안전합니다.