[AWS to AHV 마이그레이션] #2 Nutanix Move용 IAM 사용자·정책·액세스 키 생성
AWS EC2 → Nutanix AHV 마이그레이션 시리즈 2편입니다. 1편에서 소스가 될 Windows Server 2022 인스턴스를 만들었으니, 이번에는 Nutanix Move가 그 인스턴스를 읽어갈 수 있도록 AWS 쪽에 문을 열어줄 차례입니다. Move는 AWS에 로그인하는 게 아니라 액세스 키로 API를 호출하기 때문에, 전용 IAM 사용자와 그 사용자가 뭘 할 수 있는지 정의한 권한 정책, 그리고 액세스 키 이 세 가지가 필요합니다.
- #1 EC2 Windows 인스턴스 생성
- #2 Nutanix Move용 IAM 사용자·정책·액세스 키 생성 ← 현재 글
- #3 Nutanix Move 어플라이언스 배포
- #4 Move 환경 등록 → Migration Plan → 컷오버
- #5 컷오버 후 Windows 부팅 실패 — VirtIO 드라이버 수동 설치
이 글에서 놓치면 안 되는 건 딱 두 가지입니다.
- 권한 정책은 AWS 관리형 정책을 갖다 붙이지 말고, 아래에 있는 Move 전용 JSON을 통째로 넣을 것
- 액세스 키 만들 때 사용 사례는 「AWS 외부에서 실행되는 애플리케이션」 을 고를 것
작업순서
- IAM 사용자 생성 — 이름만 정하고 콘솔 액세스는 주지 않음
- 권한 정책 생성 — JSON 편집기에 Move 전용 정책 입력
- 정책을 사용자에 직접 연결
- 액세스 키 생성 — 사용 사례 선택 후 키 확보
1. IAM 사용자 생성
- IAM 콘솔 › IAM 사용자 › 사용자 생성
- 사용자 이름 입력. 저는
Move_IAM으로 했습니다. 나중에 키 목록만 봐도 용도가 보이도록 이름에 용도를 넣는 걸 추천합니다. - AWS Management Console에 대한 사용자 액세스 권한 제공은 체크하지 않습니다. Move는 액세스 키만 쓰지 콘솔에 로그인할 일이 없습니다.
- 다음
IAM은 글로벌 서비스라 상단에 표시되는 리전은 신경 쓰지 않아도 됩니다. 서울 리전으로 되어 있든 버지니아로 되어 있든 결과는 같습니다.
2. 권한 정책 생성
- 권한 옵션에서 직접 정책 연결 선택
- 권한 정책 목록 오른쪽 정책 생성 클릭 → 정책 편집기가 새 탭으로 열립니다
- 지금 보고 있던 사용자 생성 탭은 닫지 마세요. 정책 만들고 다시 돌아옵니다.
목록에 1,500개가 넘는 AWS 관리형 정책이 있는데 왜 굳이 새로 만드냐면, Move가 필요로 하는 조합에 딱 맞는 게 없기 때문입니다. EC2 조회·스냅샷은 물론이고 EBS 블록 단위 읽기(ebs:ListChangedBlocks 같은 것), SSM 명령 전송, IAM 정책 시뮬레이션까지 섞여 있습니다. 그렇다고 AdministratorAccess를 주는 건 마이그레이션용 키 하나가 계정 전체를 쥐는 꼴이라 피해야 하고요.
- 정책 편집기 오른쪽 위 시각적 / JSON 토글에서 JSON 선택
- 기본으로 들어 있는 내용을 전부 지우고 아래 JSON을 그대로 붙여넣기
- 편집기 하단 검사 결과에서 오류: 0 확인. 경고나 추천은 나와도 진행에 문제 없습니다.
- 다음
코드 (언어: JSON)
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “VisualEditor0”,
“Effect”: “Allow”,
“Action”: [
“iam:SimulatePrincipalPolicy”,
“iam:GetUser”,
“ec2:Describe“,
“ssm:DescribeInstanceInformation”,
“ssm:SendCommand”,
“ssm:GetCommandInvocation”,
“ec2:CreateSnapshots”,
“ec2:DeleteSnapshot”,
“ec2:StopInstances”,
“ec2:StartInstances”,
“ec2:CreateTags”,
“ec2:DeleteTags”,
“ebs:ListSnapshotBlocks”,
“ebs:ListChangedBlocks”,
“ebs:GetSnapshotBlock”,
“ec2:KeyPair“,
“ec2:RunInstances”,
“ec2:TerminateInstances”,
“ec2:CreateSecurityGroup”,
“ec2:AuthorizeSecurityGroupEgress”,
“ec2:AuthorizeSecurityGroupIngress”,
“ec2:CreateVolume”,
“ec2:DeleteVolume”,
“ec2:AttachVolume”,
“ec2:DetachVolume”,
“ec2:ModifyInstanceAttribute”,
“ebs:StartSnapshot”,
“ebs:PutSnapshotBlock”,
“ebs:CompleteSnapshot”,
“ec2:RegisterImage”,
“ec2:DeregisterImage”
],
“Resource”: “*”
}
]
}
시각적 편집기로 서비스를 하나씩 골라서 만들면 EBS 블록 API 같은 게 빠지기 쉽습니다. 실제로 권한이 하나라도 빠지면 Move에서 인벤토리는 보이는데 스냅샷 단계에서 막히는 식으로, 어디서 막혔는지 찾기 귀찮은 형태로 실패합니다. JSON 전문을 통째로 넣는 게 제일 안전합니다.
| 서비스 | 허용 범위 |
|---|---|
| IAM | 읽기 — 정책 시뮬레이션, 사용자 조회 |
| EC2 | 인벤토리 조회(Describe), 인스턴스 시작/중지/실행/종료, 태그, 키 페어, 보안 그룹, 볼륨, AMI 등록/해제 |
| Elastic Block Store | 스냅샷 블록 나열/읽기/쓰기 |
| Systems Manager | SSM 명령 전송·결과 조회 |
3. 정책을 사용자에 연결
- 아까 열어둔 사용자 생성 탭으로 돌아가서 권한 정책 목록의 새로고침(↻) 클릭
- 검색창에 정책 이름 입력 → 유형이 고객 관리형인 정책 체크
- 권한 경계 설정은 건드리지 않고 다음
- 검토 화면에서 권한 요약에 정책 1개 확인 → 사용자 생성
생성 후 사용자 상세 화면에 들어가면 권한 탭에 정책이 「직접」 연결 방식으로 1건 보이고, 콘솔 액세스는 비활성화됨으로 표시됩니다. 이게 정상입니다.
4. 액세스 키 생성
- IAM 사용자 › 방금 만든 사용자 클릭
- 요약 영역 오른쪽 액세스 키 1 아래 액세스 키 만들기 클릭 (보안 자격 증명 탭에서도 같은 버튼이 있습니다)
여기가 이 글의 두 번째 핵심입니다. 사용 사례 선택 화면에서 AWS 외부에서 실행되는 애플리케이션을 고릅니다. Move 어플라이언스는 온프레미스 Nutanix 클러스터 위에서 돌아가는 외부 워크로드이니 이게 맞는 항목입니다. CLI, 로컬 코드, 서드 파티 서비스 같은 건 고르지 마세요.
아래에 노란 박스로 IAM Roles Anywhere를 쓰라는 권장 대안이 뜨는데, 장기 자격 증명 대신 임시 자격 증명을 쓰라는 AWS의 일반 권고입니다. Move는 액세스 키 / 비밀 키 입력 방식으로 AWS 소스를 등록하기 때문에 여기서는 적용하지 않고 다음으로 넘어갑니다.
- 설명 태그(선택)에 용도를 적고 액세스 키 만들기. 저는
Nutanix_Move로 넣었습니다. - 액세스 키 ID와 비밀 액세스 키가 표시됩니다. 표시로 확인하거나 .csv 파일 다운로드로 바로 저장하세요.
- 완료
비밀 액세스 키는 이 화면을 벗어나면 다시 볼 수 없습니다. 잃어버리면 새 키를 만들고 기존 키를 비활성화하는 것 말고는 방법이 없습니다. 메일이나 메신저, 문서에 평문으로 남기지 말고, 마이그레이션이 끝나면 키를 비활성화하거나 삭제하세요.
정리
- 콘솔 액세스 없는 IAM 사용자 1개
- Move 전용 JSON으로 만든 고객 관리형 정책 1개 (허용 서비스 4개), 사용자에 직접 연결
- 사용 사례 「AWS 외부에서 실행되는 애플리케이션」으로 만든 액세스 키 1쌍
이 액세스 키 ID와 비밀 액세스 키는 4편에서 Move 콘솔에 AWS 소스 환경을 등록할 때 입력합니다. 다음 편에서는 그 전에 Nutanix 쪽에 Move 어플라이언스를 배포합니다.
단락 (이전/다음 링크)
← 이전 글: #1 EC2 Windows 인스턴스 생성 | 다음 글: #3 Nutanix Move 어플라이언스 배포 →