[AWS] AWS KMS 키 공유 없이 리전 간 암호화된 EC2 인스턴스 마이그레이션 방법

 

AWS 블로그 Migrate encrypted Amazon EC2 instances across AWS Regions without sharing AWS KMS keys를 번역 및 가공하여 작성했습니다.

개요

AWS는 전 세계 인프라를 분리된 리전으로 설계하여 애플리케이션에 대해 높은 내결함성과 안정성을 제공하고 있다.

 

리전들은 각기 독립적인 네트워크 및 보안 경계를 가지며, 이를 파티션이라는 단위로 조직되어 있다.

 

비즈니스가 발전함에 따라, 리전 간 워크로드 마이그레이션이 필요할 수 있다.

 

암호화된 자원을 다룰 때는 리전 간 마이그레이션이 특히 주의가 필요하다.

예를 들어, Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 그에 연결된 암호화된 Amazon Block Storage(Amazon EBS) 볼륨을 동일한 계정 또는 다른 계정의 리전으로 이동할 때 다음과 같은 문제가 있습니다.

AWS Key Management Service(AWS KMS)키는 리전별로 존재하며, 리전 간 공유할 수 없다는 점이다. 

 

동일한 계정인 겨우 AWS KMS를 다중 리전 키를 생성하여 마이그레이션 할 대상 리전에 새 복제본 키 생성을 통해 키를 공유할 수 있으며 간단하게 스냅샷으로 리전 간 복제가 가능하다. 

 

본 포스팅에서는 AWS KMS 키를 공유하지 않고 암호화된 EC2 인스턴스를 리전 간에 안전하게 마이그레이션하는 단계별 접근 방법을 소개합니다.

 

솔루션 개요

다음 그림은 EC2 인스턴스를 서로 다른 계정의 서로 다른 리전으로 KMS 키를 공유하지 않고 마이그레이션하는 아키텍처입니다.

그림 1: 두 계정 간 EC2 마이그레이션 설계

 

사전 준비

다음 사전 준비가 필요합니다.

- 원본 리전(Account A)과 대상 리전(Account B) 각각에 S3 버킷을 생성합니다.

- 대상 계정의 Amazon S3 버킷에 다음 버킷 정책을 구성하여 서로 다른 계정 간 Amazon Machine Image(AMI) 파일을 복사할 수 있도록 구성합니다. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:sts::1234567891:assumed-role/<rolename>"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::<target-bucket-name>/*"
        }
    ]
}

Principal에는 CloudShell을 사용할거기 때문에 CloudShell을 열어 aws sts get-caller-identity를 입력하여 내 현재 arn을 응답받을 수 있다. 

구현 단계

이제 위의 구조를 기반으로 소스 계정(Account A) 인스턴스를 대상 계정Account B)로 이동하는 과정을 구현합니다.

1.  동일 계정 또는 다른 계정의 다른 리전으로 이동하려는 서버의 AMI를 생성

     a.서버 선택

     b. 작업, 이미지 및 템플릿 그리고 이미지 생성 선택

그림2: AMI 생성 단계

     c. 세부 정보를 입력하고 Create Image 를 선택합니다.

그림 3: AMI 생성 속성 확인

2. AMI 상태를 확인하려면 왼쪽 메뉴에서 AMI ID를 선택하거나 AMI 항목 아래를 선택한 후 상태가 사용 가능으로 표시될 때까지 기다린다. 

그림4: AMI 사용 가능 상태

 

3. AWS 관리 콘솔에서 AWS CloudShell을 사용하여 다음 명령어를 실행 시킨다.

aws ec2 create-store-image-task --image-id ami-xxxxxxxxx –bucket <bucket_name>

그림 5: 바이너리 파일 생성 요청

4. 다음 명령어를 사용하여 작업 상태를 확인하고 완료되었는지 확인할 수 있습니다.

그림 6: 바이너리 파일 생성 확인

5. S3 버킷에서 AMI 바이너리 파일을 확인할 수 있습니다.

그림 7: S3 내 바이너리 파일 확인

6. 소스 계정의 CloudShell에서 다음 명령어를 사용하여 AMI 바이너리를 대상 S3 버킷으로 복사합니다.

aws s3 cp s3://<source_bucket>/ami-000xxxxxxxxx.bin s3://<target_bucket>/

 

만약 실패하는 경우 대상 계정(Account B)의 S3 버킷 정책을 확인

 

7. 복사 작업이 완료되면 대상 계정(AccountB)의 S3 버킷에서 .bin의 파일이 복사되었는지 확인

그림 8: 대상 계정에 복사된 바이너리 파일 확인

 

8. 대상 계정의 CloudShell에서 다음 명령을 실행하여 .bin 파일을 대상 계정의 AMI로 복원

aws ec2 create-restore-image-task --object-key ami-xxxx.bin --bucket <target_bucket> --name "<AMI_name>"\

 

그림 9: CloudShell에서 AMI 생성 명령어 실행

9. 대상 EC2 섹션에서 AMI 사용 가능 여부를 확인하십시오. 소스 리전 정보와 함께 새로운 AMI ID를 확인

그림 10: 대상 계정에서 생성된 AMI

10. 대상 리전에서 마이그레이션된 AMI를 사용하여 인스턴스를 시작

그림 11: 대상 계정에서 EC2 인스턴스 실행 확인

제한 사항

• AMI를 S3에 저장하려면, 해당 AMI와 스냅샷을 AWS 계정이 직접 소유하고 있거나, 또는 AMI와 스냅샷이 직접 해당 계정에 공유되어 있어야 합니다.
• 단순히 공개(Publicly shared) 되어 있는 AMI는 저장할 수 없습니다.
• Amazon EBS 기반 AMI만 이 API를 사용해 저장할 수 있습니다.
• Paravirtual (PV) AMI는 지원되지 않습니다.
• 저장 가능한 AMI의 크기는 압축 전 기준 최대 5,000GB로 제한됩니다.
• AMI 저장 작업(store image request)에 대한 제한: 동시에 진행 중인 스냅샷 데이터 작업은 최대 1,200GB까지 가능합니다.
• AMI 복원 작업(restore image request)에 대한 제한: 동시에 진행 중인 복원 데이터 작업은 최대 600GB까지 가능합니다.
• 저장 작업이 진행되는 동안 관련된 스냅샷이 삭제되면 안 되며, 해당 작업을 수행하는 IAM 주체(IAM principal)가 스냅샷에 대한 접근 권한을 유지해야 합니다. 그렇지 않으면 저장 작업은 실패합니다.
• 동일한 S3 버킷 내에 AMI를 여러 개 복사 생성할 수 없습니다.
• S3에 저장된 AMI는 원래의 AMI ID로 복원할 수 없습니다. 이를 해결하려면 AMI 별칭(Alias) 기능을 사용할 수 있습니다.
• 현재 AMI 저장(Store) 및 복원(Restore) API는 AWS CLI, AWS SDK, Amazon EC2 API를 통해서만 지원됩니다. EC2 콘솔에서는 사용할 수 없습니다.