목차 Abstract... 3 Introduction... 3 Scope of AWS Resources... 3 AWS IAM and Security Considerations... 4 Compute & Networking... 5 Migrating Amazon EC2

Size: px

Start display at page:

Download "목차 Abstract... 3 Introduction... 3 Scope of AWS Resources... 3 AWS IAM and Security Considerations... 4 Compute & Networking... 5 Migrating Amazon EC2"

병욱 온
8 years ago
Views:

1 새 리전으로 AWS 리소스 마이그레이션 2013년 3월 Simon Elisha, James Bromberger 및 Peter Stanski (본 문서의 최신 버전을 보려면 < 참조하십시오.)

2 목차 Abstract... 3 Introduction... 3 Scope of AWS Resources... 3 AWS IAM and Security Considerations... 4 Compute & Networking... 5 Migrating Amazon EC2 Instances... 5 SSH Keys... 5 Security Groups... 6 Amazon Machine Images... 7 Amazon Elastic Block Store Volumes... 8 Elastic IP Addresses... 9 Elastic Load Balancing Launch Configurations and Auto Scaling Groups Reserved Instances Considerations Migrating Amazon Virtual Private Clouds Migrating AWS Direct Connect Links Using Amazon Route 53 to Aid the Migration Process Storage & CDN Migrating Amazon Simple Storage Service Buckets Virtual Hosting with Amazon S3 Buckets Move Objects By Using the AWS Management Console Moving Objects By Using Third Party Tools Copying Using the API/SDK Migrating Amazon CloudFront Distributions Migrating Amazon Glacier Storage Strategy 1: Online transfer Strategy 2: Offline transfer Database Migrating Amazon RDS Services Database Security Groups Database Instances and Data Migrating Amazon DynamoDB Migrating Amazon SimpleDB Migrating Amazon ElastiCache Application Services Migrating Amazon Simple Queue Service Queues Migrating Amazon Simple Notification Service Topics Deployment & Management Migrating with AWS CloudFormation Capturing Environments by Using CloudFormer API Implications... 25

3 Updating Customer Scripts and Programs Important Considerations Closing Remarks 요약 이 문서는 기존 리소스를 새로운 AWS 리전으로 마이그레이션하려는 숙련된 Amazon Web Services 고객을 위해 작성되었습니다. 고객은 다양한 이유로 마이그레이션이 필요할 수 있습니다. 특히 새로운 리전이 사용자 기반에 더 가까운 경우 고객은 다양한 서비스를 지리적으로 사용자에게 더 가까운 곳에 두고자 할 수 있습니다. 이 문서는 "단계별" 또는 "확정적" 가이드로 계획되지 않았으며, 그보다는 고객에게 새로운 리전에 필요할 수 있는 다양한 서비스를 마이그레이션하기 위한 여러 가지 옵션과 방법을 제공합니다. 소개 Amazon Web Services는 현재 전 세계 수많은 리전에서 운영하면서 190여 개 국가에서 고객에게 서비스하고 있습니다. 수많은 AWS 서비스에 대해 서비스를 제공할 지리적 리전을 선택할 수 있습니다. 리전은 개별 지리적 영역(미국, 유럽, 아시아 태평양, 남아메리카 등)에 분산적으로 배치되어 있으며 복수의 가용 영역을 가지고 있습니다. 개별 가용 영역을 사용하면 단일 위치의 오류로부터 애플리케이션을 한층 더 보호할 수 있습니다. 개별 AWS 리전을 사용하면 특정 고객과 더 가까운 곳에서 애플리케이션을 설계하여 지연 시간을 줄이고 처리량을 높일 수 있습니다. AWS는 애플리케이션의 내결함성과 안정성을 향상할 수 있도록 리전을 서로 격리되도록 설계했습니다. AWS 리소스 범위 대부분의 AWS 서비스가 리전과 독립적인 방식으로 운영되지만, 다음 서비스는 모든 리전에 걸쳐 운영되며 마이그레이션이 필요 없습니다. AWS Identity and Access Management(IAM) AWS Management Console Amazon CloudWatch 또한 API 엔드포인트를 사용하여 모든 서비스에 액세스할 수 있으므로 애플리케이션에 따라 아키텍처의 모든 구성 요소를 새로운 리전으로 반드시 마이그레이션할 필요는 없습니다. 예를 들어, Amazon Elastic Compute

4 Cloud(Amazon EC2) 인스턴스를 마이그레이션하면서 기존 Amazon Simple Storage Service(Amazon S3) 및 Amazon CloudFront 구성을 그대로 유지할 수 있습니다. 특정 리전별로 업데이트된 사용 가능한 AWS 제품 및 서비스 목록은 AWS 웹 사이트 글로벌 인프라 섹션 1 에서 사용할 수 있습니다. 새 리전으로 마이그레이션하기 전에 AWS 제품 및 서비스를 즉시 사용할 수 있는지 확인하는 것이 좋습니다. AWS IAM 및 보안 고려 사항 AWS Identity and Access Management(IAM)를 통해 사용자의 AWS 서비스와 리소스에 대한 액세스를 안전하게 통제할 수 있습니다. IAM 사용자는 특정 리전이 아닌 AWS 계정 범위 내에서 생성되고 관리되므로 사용자 또는 그룹의 마이그레이션은 필요 없습니다. 새로운 리전으로 마이그레이션할 때는 IAM 사용자에 대해 정의된 정책 제한 사항에 주의해야 합니다. 예를 들어, Amazon 리소스 이름(ARN)은 특정 리전으로 제한될 수 있습니다. 자세한 내용은 IAM 사용 설명서의 IAM 엔터티에 대한 식별자 2 섹션을 참조하십시오. IAM은 고객이 특정 정책을 추가하여 사용자가 AWS 리소스에 액세스하는 방법을 제어할 수 있는 핵심 보안 서비스입니다. 일부 정책은 액세스 시간(시간대 차이로 인해 고려해야 할 수 있음), 새로운 발원 IP 주소 사용, SSL 연결을 사용해야 하는지 여부, 사용자를 인증하는 방법, 멀티 팩터 인증(MFA) 디바이스를 사용해야 하는지 여부 등에 영향을 미칠 수 있습니다. AWS Identity and Access Management(IAM)는 보안을 강화하기 때문에 리전 마이그레이션을 수행하기 전에 보안 구성 정책, 절차 및 실행을 세심하게 검토하는 것이 좋습니다

5 컴퓨팅 및 네트워킹 Amazon EC2 인스턴스 마이그레이션 Amazon EC2는 클라우드에서 컴퓨팅 파워를 자유 자재로 변경할 수 있는 웹 서비스입니다. 개발자가 웹 규모의 컴퓨팅 작업을 더욱 쉽게 수행할 수 있도록 설계되었습니다. 인스턴스 마이그레이션은 데이터와 이미지를 복사하고 보안 그룹과 SSH 키가 있는지 확인한 다음 새로운 인스턴스를 다시 시작하는 작업입니다. SSH 키 Amazon Web Services는 고객이 생성한 사용자 SSH 프라이빗 키를 보관하지 않습니다. 이 퍼블릭 키는 Amazon EC2 인스턴스가 실행 중일 때 사용할 수 있습니다(Linux 운영 체제에서는 일반적으로 이 키가 해당 사용자의 ~/.ssh/authorized_keys 파일에 복사됨). 그림 1 AWS Management Console의 키 쌍 사용자는 API, SDK, 명령줄 또는 콘솔에서 각 키의 지문을 검색할 수 있습니다. SSH 퍼블릭 키는 리전별로만 저장되며, AWS는 구성된 고객 SSH 키를 리전 간에 복사하거나 동기화하지 않습니다. 리전별로 개별 SSH 키를 사용할지 또는 여러 리전에 동일한 SSH 키를 사용할지 결정하는 것은 고객에게 달려 있습니다. 참고: 원본 리전에서 기존 Linux 인스턴스에 로그온하여 퍼블릭 키를 얻은 다음(~/.ssh/authorized_keys에서 얻음) 이 키를 대상 리전으로 가져올 수 있습니다. Auto Scaling 시작 구성 및 AWS CloudFormation 템플릿은 키 쌍 이름을 사용하는 SSH 키를 참조할 수 있습니다. 이 경우 사용자는 새로운 리전에서 사용 가능한 키를 사용하도록 Auto Scaling 시작 구성 또는 AWS CloudFormation 템플릿을 업데이트하거나 동일한 키 쌍 이름의 퍼블릭 키를 새로운 리전에 배포해야 합니다.

6 자세한 내용은 AWS 보안 자격 증명 정보 3 를 참조하십시오. 보안 그룹 Amazon EC2의 보안 그룹은 수신(또는 VPC의 경우 수신 및 송신) 트래픽을 Amazon EC2 인스턴스로 제한합니다. 보안 그룹의 각 규칙은 CIDR 표기법 IPv4 주소 범위(a.b.c.d/x) 또는 보안 그룹 식별자(sg-XXXXXXXX)를 사용하여 원본(또는 VPC에서는 대상)을 참조할 수 있습니다. 그림 2 AWS Management Console에서 보안 그룹 구성 각 보안 그룹은 한 리전 범위 내에서만 존재할 수 있습니다. 동일한 이름이 여러 리전에 존재할 수 있지만, 통과가 허용되는 트래픽에 대한 정의가 다릅니다. 시작되는 각 인스턴스는 보안 그룹의 구성원이어야 합니다. 호스트가 Auto Scaling 시작 구성 또는 AWS CloudFormation 템플릿의 일부로 시작되는 경우 필수 보안 그룹이 있어야 합니다(AWS CloudFormation 템플릿은 보안 그룹이 템플릿의 일부로 생성되도록 정의할 수 있음). 구성된 보안 그룹을 검토하여 필요한 수준의 네트워크 액세스 제한이 설정되어 있는지 확인해야 합니다. 명령줄 도구를 사용하여 기존 보안 그룹 정의의 사본을 내보내려면 다음 명령을 사용하십시오. ec2-describe-group H - region <sourceregionname> > security_groups.txt 3

7 자세한 내용은 Amazon EC2 사용 설명서의 보안 그룹 섹션 4 을 참조하십시오. Amazon 머신 이미지 Amazon 머신 이미지(AMI)는 Amazon EC2 환경 내에서 가상 머신(인스턴스)을 생성하는 데 사용되는 특수한 유형의 사전 구성된 운영 체제 이미지입니다. 각 AMI에는 "ami-xxxxxxxx" 형식의 식별자가 할당됩니다. 여기서 'X'는 16진수 값(0-9, A-F)입니다. 그림 3 AWS Management Console의 AMI 각 AMI는 리전별로 고유하며 AMI를 여러 리전에 걸쳐 사용할 수 없습니다. 하지만 AMI의 동일한 콘텐츠를 다른 리전(예, Amazon Linux 또는 Windows Server 2008 R2)에서 사용할 수 있으며 각 리전에는 이 데이터 사본에 대한 고유의 AMI ID가 있습니다. 실행 중인 인스턴스에서 고유의 AMI를 만들고 추가 인스턴스를 시작하기 위한 시작점으로 이 AMI를 사용할 수 있습니다. 사용자가 만든 이 AMI에는 리전 내에서 고유한 AMI ID가 할당됩니다. AMI ID는 Auto Scaling 시작 구성 및 AWS CloudFormation 템플릿 내에서 사용됩니다. Auto Scaling 또는 AWS CloudFormation을 사용할 계획인 경우 대상 리전에 있는 것과 일치하도록 AMI ID 참조를 업데이트해야 합니다. 리전 간 AMI 마이그레이션은 EC2 AMI 복사 기능 5 을 사용하여 지원됩니다. EC2 AMI 복사를 사용하면 AWS Management Console, Amazon EC2 CLI 또는 Amazon EC2 API에서 AMI를 원하는 만큼 많은 리전으로 복사할 수 있습니다. EC2 AMI 복사는 Amazon EBS 지원 AMI와 인스턴스 스토어 지원 AMI에 사용할 수 있으며 운영 체제와 무관합니다

8 AMI를 복사할 때마다 고유의 AMI ID가 있는 새로운 AMI가 생성됩니다. 복사 도중이나 이후에 원본 AMI에 수행한 변경 사항은 AMI 복사 프로세스의 일부로 새로운 AMI에 전파되지 않으며, 원본 AMI에 대한 변경 사항을 복사하려면 새로운 AMI를 대상 리전으로 다시 복사해야 합니다. 참고: 원본 AMI에 적용된 권한과 사용자 정의 태그는 AMI 복사 프로세스의 일부로 새로운 AMI에 복사되지 않습니다. 복사가 완료된 후 권한과 사용자 정의 태그를 새로운 AMI에 적용할 수 있습니다. Amazon Elastic Block Store 볼륨 Amazon Elastic Block Store(Amazon EBS)는 인스턴스에 제공될 수 있는 블록 스토리지 볼륨입니다. Amazon EBS 볼륨은 NTFS, vfat, ext4, xfs 등과 같은 특정 파일 시스템 형식으로 포맷할 수 있습니다. Amazon EBS 볼륨은 운영 체제 부트 볼륨을 포함하거나 추가 데이터 드라이브(Windows) 또는 마운트 지점(Linux)으로 사용할 수 있습니다. 리전 간 Amazon EBS 스냅샷 복사 기능 6 을 사용하여 Amazon EBS 볼륨을 마이그레이션할 수 있습니다. 이 방법으로 콘솔, API 호출 또는 명령줄을 사용하여 Amazon EBS 볼륨의 스냅샷을 리전 간에 복사할 수 있습니다. 이 기능의 주요 기능은 다음과 같습니다. AWS Management Console에는 진행 중에 스냅샷 복사 진행률이 표시되며, 여기서 완료 비율을 확인할 수 있습니다. 여러 스냅샷을 선택하고 동일한 리전에 복사하거나 스냅샷을 여러 리전에 병렬로 복사하여 여러 스냅샷 복사 명령을 동시에 시작할 수 있습니다. 진행 중 복사는 관련 Amazon EBS 볼륨의 성능에 영향을 미치지 않습니다. 콘솔 기반 인터페이스는 푸시 기반이므로, 원본 리전에 로그인하고 스냅샷을 어디로 복사할지를 콘솔에 알립니다. 반대로 API와 명령줄은 풀 기반이며 대상 리전 내에서 실행해야 합니다. 외부 도구를 사용하거나 구성을 수행할 필요 없이 전체 프로세스가 수행됩니다. 고급 마이그레이션 프로세스: 마이그레이션할 관련 Amazon EBS 볼륨을 식별합니다(식별에 도움이 되는 태그 지정 사용을 선택할 수 있음). 애플리케이션 실행 중에 복사할 수 있는 볼륨과 중단(애플리케이션 종료)이 필요한 볼륨을 식별합니다. Amazon EBS 스냅샷 복사는 볼륨 자체에 액세스하지 않고 기본 볼륨의 스냅샷에 액세스합니다. 따라서 6

9 전체적으로 최신 데이터가 복사되도록 보장하기 위해 복사 프로세스 중에 애플리케이션을 종료해야 할 수 있습니다. 필요한 Amazon EBS 스냅샷을 만들고 "완료" 상태가 될 때까지 기다립니다. 콘솔, API 또는 CLI를 사용하여 Amazon EBS 스냅샷 복사를 시작합니다. 적절한 스냅샷을 선택하고 "스냅샷에서 볼륨 생성" 기능을 사용하여 대상 리전에 새로운 Amazon EBS 볼륨을 만듭니다. 볼륨 및 스냅샷 Amazon EBS 볼륨은 현재 1GB부터 최대 1TB 크기일 수 있으며, 디스크 관리 도구(Logical Volume Manager(LVM) 또는 Windows 디스크 관리자)와 함께 사용하여 여러 블록 디바이스 간에 스팬/스트라이프할 수 있습니다. 여러 Amazon EBS 볼륨을 함께 스트라이프하여 더 높은 성능의 인스턴스를 애플리케이션에 제공할 수 있습니다. 특히 RAID 1 스트라이프에서 사용되거나 LVM 볼륨 그룹에 속한 여러 볼륨이 있는 경우 항상 사용하는 볼륨은 스냅샷 촬영에서 이익을 얻을 수 있습니다. 프로비저닝된 IOPS 볼륨은 Amazon EBS 성능을 향상하는 또 한 가지 방법입니다. 이 볼륨은 I/O 집중적인 워크로드(예: 데이터베이스)에 예측 가능하고 우수한 성능을 제공하도록 설계되었습니다. Amazon EC2 인스턴스에서 Amazon EBS 볼륨에 프로비저닝된 IOPS를 완전히 사용하도록 일부 Amazon EC2 인스턴스 유형을 "EBS 최적화" 인스턴스로 시작할 수 있습니다. 리전 마이그레이션을 수행하기 전에 대상 리전의 가용 영역이 이러한 인스턴스를 지원하는지 확인하는 것이 좋습니다. 자세한 내용은 Amazon EC2 사용 설명서의 EBS 성능 향상 7 을 참조하십시오. 탄력적 IP 주소 탄력적 IP 주소는 지정된 리전의 주소 풀에서 계정에 할당됩니다. 따라서 탄력적 IP 주소는 리전 간에 마이그레이션할 수 없습니다. 권장 사항은 이 탄력적 IP 주소를 가리키는 DNS에서 TTL(Time-To-Live) 값을 업데이트하고 이 값을 DNS 캐시 만료 시 허용 가능한 지연 시간에 해당하는 양, 예를 들면 300초(5분) 이하로 줄이는 것입니다. DNS TTL을 7

10 감소시키면 결과적으로 DNS 요청이 증가하고 현재 DNS 서비스에 대한 부하가 증가하여 DNS 서비스 제공자가 부과하는 요금에 영향이 있을 수 있습니다. DNS 변경은 TTL 수정에 대한 단계별 접근 방식을 선택하여 더욱 최적으로 수행할 수 있습니다. 예를 들면 다음과 같습니다. IP 주소를 가리킴)의 현재 TTL은 86400(1일)입니다. TTL을 300초(5분)로 수정하고 2일의 시간 동안 작업을 예약합니다. 이 기간 중 DNS 트래픽 증가를 모니터링합니다. 예약된 작업의 시작일에 TTL을 더 줄이고, 나중에 DNS 인프라의 부하에 따라 선택적으로 TTL을 더 줄입니다(예: 10초). 마지막 변경 후 10분이 지나면 새로운 리전의 새로운 탄력적 IP 주소를 가리키도록 A 레코드를 업데이트합니다. 잠시 후 트래픽이 적절하게 서비스되고 있는지 확인하고 TTL을 다시 5분(300초)으로 증가시킵니다. 작업 기간이 한 번 더 지난 후, TTL을 정상 수준으로 되돌립니다. Elastic Load Balancing Elastic Load Balancing은 수신되는 애플리케이션 트래픽을 여러 Amazon EC2 인스턴스에 자동으로 배포합니다. Elastic Load Balancing은 새로운 리전으로 마이그레이션할 수 없습니다. 그 대신, 서비스 그룹 내에서 원하는 가용 영역을 포괄하는 새로운 Amazon EC2인스턴스 세트를 포함하여 대상 리전에서 새로운 Elastic Load Balancing 서비스를 시작해야 합니다. 리전 마이그레이션을 수행하기 전에 원본 및 대상 리전 가용 영역을 검토하여 일치하는 영역 수준이 있는지 확인하는 것이 좋습니다. 추가 가용 영역을 검색하는 시나리오에서는 애플리케이션 로드 밸런싱 및 확장성을 수정해야 할 수 있습니다. 이 경우 Auto Scaling 그룹 구성에 사용되는 CloudWatch 경보 및 임계값에 대한 추가 평가도 필요할 수 있습니다. 또한 기존 Elastic Load Balancing 서비스의 관련 SSL 인증서를 새로운 Elastic Load Balancing 서비스에 추가해야 하며, Amazon EC2 인스턴스 상태 테스트를 확인하기 위해 상태 확인 조건도 추가해야 합니다.

11 시작 구성 및 Auto Scaling 그룹 Auto Scaling을 사용하면 사용자가 정의하는 조건에 따라 Amazon EC2 용량을 자동으로 확장하거나 축소할 수 있습니다. 다음 명령을 사용하여 현재 Auto Scaling 및 시작 구성 정의를 캡처합니다. Auto Scaling은 현재 AWS Management Console을 사용하여 구성할 수 없지만, 다른 타사 관리 도구가 이 작업을 지원합니다. as-describe-auto-scaling-groups H - region <sourceregionname> > autoscale_groups.txt as-describe-launch-configs H -region <sourceregionname> > launch_configs.txt 이렇게 추출된 Auto Scaling 그룹과 시작 구성 설정은 원본 리전에 있는 AMI, 보안 그룹, SSH 키 쌍을 참조합니다. 이러한 항목을 대상 리전으로 마이그레이션하는 방법은 위의 섹션을 참조하십시오. 그런 다음 대상 리전에서 새로운 AMI ID와 보안 그룹을 사용하여 새로운 Auto Scaling 그룹과 시작 구성을 만듭니다. Auto Scaling 그룹과 시작 조건에 대한 자세한 내용은 Auto Scaling 사용 설명서의 Auto Scaling의 기본 시나리오를 참조하십시오. 8 예약 인스턴스 고려 사항 많은 고객은 Amazon EC2, Amazon Relational Database Service(Amazon RDS) 및 Amazon ElasticCache에 대한 예약 인스턴스를 대폭 할인된 요금으로 이용합니다. 예약 인스턴스(또는 예약 캐시 노드)는 1년 또는 3년 기간 동안 특정 리전에 설정된 가용 영역 내의 특정 인스턴스 유형(크기)에 할당됩니다. 예약 인스턴스는 Light, Medium 및 Heavy라는 세 가지 사용률 수준으로 구매할 수 있습니다. 선결제 비용과 시간당 요금은 이러한 사용률 수준과 지리적 리전에 따라 다릅니다. Light 및 Medium 사용률 예약 인스턴스도 인스턴스가 실행 상태에 있는 시간 동안 인스턴스 시간별로 결제됩니다. 인스턴스가 실행 중이 아닌 경우 사용 요금이 없습니다. 인스턴스 시간을 일부만 사용해도 전체 시간으로 결제됩니다. Heavy 사용률 예약 인스턴스는 온디맨드 인스턴스를 통해 최대한의 절약을 제공하며 전체 기간 중 시간당으로 결제됩니다(시간 중 사용 여부와 상관 없이 시간당 요금이 고객에게 결제됩니다). 예약 인스턴스를 구매한 경우 인스턴스를 다른 리전으로 마이그레이션하려면 먼저 예약 인스턴스 Marketplace에서 판매하는 것이 좋습니다. 판매되는 즉시 결제가 새로운 구매자로 전환되며 고객은 예약 인스턴스에 대해 더 이상 결제되지 않습니다. 구매자가 기간의 나머지 부분을 계속 지불합니다. 온디맨드 8

12 인스턴스를 통해 비용을 절약하려면 예약 인스턴스 Marketplace에서 마이그레이션할 리전에 대해 더 짧은 기간 동안 예약 인스턴스를 구매하거나 AWS에서 직접 구매할 수 있습니다. 예약 인스턴스 Marketplace에서는 결제를 새 리전으로 쉽게 "마이그레이션"할 수 있습니다. 예약 인스턴스를 구입 및 판매하는 방법에 대해 더 자세히 알아보려면 예약 인스턴스 구입 방법 및 예약 인스턴스 Marketplace 페이지를 참조하십시오. 9 새 리전으로 마이그레이션하기 전에 예약 인스턴스 구매 및 판매에 앞서서 비용 영향을 세심하게 평가하는 것이 좋습니다. Amazon 가상 프라이빗 클라우드 마이그레이션 Amazon Virtual Private Cloud(Amazon VPC)를 사용하면 고객이 정의하는 가상 네트워크에서 AWS 리소스를 시작할 수 있는 Amazon Web Services(AWS) 클라우드의 프라이빗 격리 섹션을 프로비저닝할 수 있습니다. Amazon Virtual Private Cloud(Amazon VPC)는 리전별로 존재하지만, 해당 리전 내의 여러 가용 영역에서 사용할 수 있습니다. 이 기능은 새로운 리전으로 이동하거나 마이그레이션할 수 없습니다. 하지만 새로운 대상 리전에서 새로운 VPC를 만들 수 있으며 동일한 IP 주소 범위를 기존 VPC로 사용할 수 있습니다. 리전 마이그레이션 중에도 라우팅이 계속 작동하도록 사용 중인 IP 주소 범위를 고려해야 합니다. 고객 게이트웨이에서 관리 작업을 정확하게 수행하고 중복 범위에 동시에 액세스하지 않는 한, 새로운 리전에서 동일한 내부 IP 주소 범위를 사용하여 중복 VPC를 만들 수도 있습니다. AWS Direct Connect 링크 마이그레이션 AWS Direct Connect는 물리적 인프라를 AWS 서비스에 연결하는 서비스입니다. AWS Direct Connect 로케이션 시설에서 하나 이상의 광섬유 연결이 프로비저닝됩니다. 새로운 리전에서 새로운 링크를 프로비저닝하려면 새로운 AWS Direct Connect 서비스를 요청하고 테일 회로를 인프라에 프로비저닝해야 합니다. AWS DirectConnect 요금은 지리적 위치에 따라 다릅니다. 더 이상 필요하지 않을 때는 언제든지 기존 연결을 종료할 수 있습니다. AWS는 각 지리적 리전에서 다양한 피어링 파트너와 협력하고 있습니다. 서비스 프로비저닝에 도움이 될 수 있는 업데이트된 AWS Direct Connect Amazon 파트너 목록을 살펴볼 수 있습니다. 9

13 마이그레이션 프로세스에 도움이 되는 Amazon Route 53 사용 Amazon Route 53는 전 세계 모든 AWS 리전과 엣지 로케이션에서 사용할 수 있는 가용성 높은 DNS 서비스입니다. DNS는 단일 전환을 통해 또는 점진적으로 트래픽을 라우팅하여 한 위치에서 다른 위치로 안정적으로 마이그레이션하는 데 도움이 될 수 있으므로 마이그레이션을 관리할 때 매우 효과적일 수 있습니다. 대상 리전에서 한 애플리케이션의 사본에 대한 새로운 DNS 레코드를 추가하여 a) 애플리케이션에 대한 액세스를 테스트할 수 있으며 b) 새로운 사이트/리전으로 전환할 시간을 선택할 수 있습니다. 한 접근 방식은 가중 리소스 레코드 세트 기능을 사용하는 것입니다. 이 기능을 사용하면 고객은 동일한 DNS 이름을 사용할 때 각 특정 주소로 라우팅되는 트래픽 비율을 확인할 수 있습니다. 예를 들어 모든 트래픽을 기존 리전으로 라우팅하고 새로운 리전으로는 아무것도 라우팅하지 않으려는 경우 다음 구성을 사용할 수 있습니다. CNAME elbname.sourceregion.com CNAME elbname.destinationregion.com 0 마이그레이션을 수행할 때가 되면 이 레코드에 대한 가중이 다음과 같이 대칭 이동합니다. CNAME elbname.sourceregion.com 0 CNAME elbname.destinationregion.com 100 그러면 모든 새로운 DNS 요청이 새로운 리전으로 확인됩니다. 참고: 일부 클라이언트는 DNS 확인을 캐시했거나 긴 TTL이 있거나 TTL 업데이트가 완료되지 않은 경우 기존 주소를 계속 사용할 수 있습니다.

14 그림 5 편리한 리전 마이그레이션을 위한 Amazon Route 53 사용 애플리케이션이 이중 리전 작업 모델을 지원하는 한 다양한 가중을 사용하여 점진적 전환을 수행할 수도 있습니다. 자세한 내용은 Amazon Route 53 사용 설명서의 가중 레코드 세트 생성 10 을 참조하십시오. 10

15 스토리지 및 CDN Amazon Simple Storage Service 버킷 마이그레이션 Amazon S3는 언제든지 웹 상의 어디서나 용량에 관계없이 데이터를 저장하고 검색하는 데 사용할 수 있는 단순한 웹 서비스 인터페이스를 제공합니다. Amazon Simple Storage Service(Amazon S3) 버킷은 실제로 단일 AWS 리전 내에 상주합니다. 다른 원격 리전에서 액세스할 때 액세스는 네트워크 지연 시간의 영향을 받습니다. 지연 시간이 발생할 수 있으므로 Amazon S3 버킷에 대한 참조와 이 버킷의 지리적 배포를 세심하게 관리해야 합니다. Amazon S3 버킷을 마이그레이션하려면 새로운 대상 리전에서 새로운 Amazon S3 버킷을 생성한 다음 데이터를 이 버킷에 복사합니다. 새로운 버킷에는 범용 고유 이름이 필요합니다 Amazon S3 버킷 이름 지정 규칙에 대한 자세한 내용은 Amazon S3 사용 설명서의 버킷 제한 사항을 참조하십시오. 11 Amazon S3 버킷을 사용한 가상 호스팅 Amazon S3의 정적 웹 사이트 호스팅 기능을 통해 웹 사이트를 호스팅할 수 있습니다. 자세한 내용은 Amazon S3 사용 설명서의 웹 사이트 호스팅 12 을 참조하십시오. 단순성과 사용자 친화성을 위해 고객은 Amazon S3에 호스팅된 웹 콘텐츠에 DNS CNAME 별칭을 사용합니다. 예를 들면 같은 URL을 사용합니다. CNAME 별칭을 통해 구체적인 Amazon S3 URL 엔드포인트는 웹 브라우저에서 추상화됩니다. 자세한 내용은 Amazon S3 사용 설명서의 가상 호스팅 13 을 참조하십시오. 이전에 정적 웹 사이트로 사용된 Amazon S3 버킷을 새로운 AWS 리전으로 마이그레이션한 경우(새로운 버킷 이름 사용) DNS 레코드 내의 CNAME 별칭(예: Amazon Route 53)을 기존 버킷 이름에서 새 이름으로 변경하면 동일한 사용자 친화적 이름을 사용하여 이 버킷에 계속 액세스할 수 있습니다

16 AWS Management Console을 사용하여 객체 이동 AWS Management Console에는 Amazon S3 버킷 간에 여러 객체를 복사하거나 이동할 수 있는 기능이 있습니다. 객체를 하나 이상 수동으로 선택하고 팝업 메뉴에서 잘라내기 또는 복사를 선택하여 이 항목은 대상 Amazon S3 버킷으로 붙여 넣거나 이동할 수 있습니다. 대상 버킷은 동일한 리전 또는 다른 지리적 리전에 상주할 수 있습니다. 그림 4 AWS Management Console을 사용하여 Amazon S3 객체에 대한 권한 설정 타사 도구를 사용하여 객체 이동 버킷 간에 Amazon S3 객체를 복사하거나 이동하려면 다양한 타사 도구를 사용할 수 있습니다. AWS 기술 파트너 페이지에서 스토리지 검색 구체화를 사용하여 AWS 파트너 제품을 확인할 수 있습니다 14. API/SDK를 사용한 복사 Amazon SDK API를 통해 버킷 간에 Amazon S3 객체를 프로그래밍 방식으로 복사/이동할 수 있습니다. Amazon S3 객체 수준 작업에 대한 자세한 내용은 Amazon S3 API 참조의 객체 작업 15 을 참조하십시오. 객체 복사 프로세스의 속도를 높이려면 PUT 객체 - 복사 작업을 사용할 수 있습니다. PUT 객체 - 복사 작업은 대상 버킷으로 복사할 수 있는 단일 작업에서 GET을 수행한 다음 PUT API 호출을 수행합니다. 자세한 내용은 Amazon S3 API 참조에서 PUT 객체 복사 16 를 참조하십시오

Amazon CloudFront 배포 마이그레이션 Amazon CloudFront는 전 세계의 수많은 AWS 엣지 로케이션에서 운영하는 콘텐츠 전송 서비스입니다(현재 35개). AWS CloudFront는 배포라는 구성 세트로 고객 데이터를 전송합니다. 각 배포에는 구성된 오리진이 하나(캐시 동작의 경우 하나 이상) 있습니다.

17 Amazon CloudFront 배포 마이그레이션 Amazon CloudFront는 전 세계의 수많은 AWS 엣지 로케이션에서 운영하는 콘텐츠 전송 서비스입니다(현재 35개). AWS CloudFront는 배포라는 구성 세트로 고객 데이터를 전송합니다. 각 배포에는 구성된 오리진이 하나(캐시 동작의 경우 하나 이상) 있습니다. 각 오리진은 Amazon S3 버킷 또는 웹 서버일 수 있습니다. 여기에는 전 세계 모든 AWS 리전의 Amazon EC2 내에서 실행되는 웹 서버도 포함됩니다. 콘솔에서 오리진을 업데이트하려면 1. Amazon EC2 인스턴스 또는 Amazon S3 버킷에 대한 본 문서의 관련 섹션을 참조하여 오리진 서버 또는 버킷을 새 리전으로 이동합니다. 2. Amazon CloudFront 콘솔에서 배포를 선택하고 배포 설정을 클릭합니다. 3. 오리진 탭을 선택합니다. 4. 편집할 오리진을 선택하고(하나만 있을 수 있음) 편집을 클릭합니다. 새로운 서버 또는 버킷 이름으로 오리진 도메인 이름을 업데이트합니다.

예, 편집을 클릭합니다. 자세한 내용은 CloudFront 개발자 안내서의 CloudFront 배포 나열, 보기 및 업데이트 17 를 참조하십시오. Amazon Glacier 스토리지 마이그레이션 Amazon Glacier는 AWS 딥 아카이브 스토리지 서비스입니다. 이 서비스는 자주 액세스하지 않는 대용량 데이터를 처리하기 위해 설계되었습니다.

18 예, 편집을 클릭합니다. 자세한 내용은 CloudFront 개발자 안내서의 CloudFront 배포 나열, 보기 및 업데이트 17 를 참조하십시오. Amazon Glacier 스토리지 마이그레이션 Amazon Glacier는 AWS 딥 아카이브 스토리지 서비스입니다. 이 서비스는 자주 액세스하지 않는 대용량 데이터를 처리하기 위해 설계되었습니다. Amazon Glacier는 현재 월별 비례 배분으로 Amazon Glacier에 있는 총 스토리지의 5%(일별 약 0.17%)에 대해 프리 티어 데이터 검색을 제공하며 이 양을 초과하는 데이터 검색에는 추가 비용을 부과합니다. Amazon Glacier에 저장된 데이터는 대개 매우 크며, 온라인 전송 대신 AWS Import/Export 서비스를 사용하여 리전 간에 데이터를 전송해야 할 수 있습니다. 전략 1: 온라인 전송 이 전략을 사용하려면 각 아카이브의 크기가 5TB 미만이어야 합니다. Amazon Glacier는 최대 40TB의 개별 아카이브까지 지원하지만, Amazon S3에는 5TB의 객체 크기 제한이 있습니다. 17

19 온라인으로 Amazon Glacier 스토리지를 전송하려면 1. Amazon Glacier에서 전체 데이터 크기를 계산하고 하루에 무료로 검색할 수 있는 크기를 알아봅니다(크기 * 0.17%). 2. Amazon Glacier 저장소에서 이 크기와 가깝게 일치하는 아카이브를 찾고 Amazon Glacier에서 Amazon Glacier 스테이징 영역으로 검색할 일정을 예약합니다. 3. 이 아카이브가 사용 가능한 경우 아카이브를 임시 Amazon S3 버킷으로 복사합니다. 선택적으로 RRS(Reduced redundancy storage) 옵션을 사용할 수 있습니다. 이 옵션을 사용하는 이유는 대상 리전에 대한 복사 프로세스가 24시간을 초과할 수도 있기 때문입니다. 검색된 Amazon Glacier 객체는 스테이징 영역에서 24시간 동안만 사용할 수 있습니다. 4. 충분한 로컬(Amazon EBS) 스토리지가 있는 대상 리전에서 마이크로 인스턴스(비용을 낮게 유지하기 위해)를 사용하여 객체(아카이브 파일)를 다운로드합니다. 5. 대상 리전에서 이 파일을 Amazon Glacier에 추가합니다. 6. 원본 리전의 임시 Amazon S3 버킷 및 원본 리전의 Amazon Glacier에서 Amazon EBS 볼륨에 대한 아카이브 파일의 임시 사본을 삭제합니다. 전략 2: 오프라인 전송 이 전략에서는 리전 간에 전송하기 위해 고객이 제공하는 스토리지 디바이스(이동식 디스크)가 필요합니다. 이 디스크의 크기는 전송되는 아카이브의 크기보다 크거나 같아야 합니다. 오프라인으로 Amazon Glacier 스토리지를 전송하려면 원본 리전의 오프라인 스토리지(디스크)로 데이터 아카이브를 전송하기 위한 AWS Import/Export 작업을 예약합니다. 작업 세부 정보를 사용하여 내보내기 위해 전송되는 디스크를 식별합니다. 내보낸 아카이브 디스크를 수신할 때까지 기다립니다. 대상 리전에서 AWS Import/Export 작업을 예약합니다. 작업 세부 정보를 사용하여 AWS Import/Export 서비스를 위해 전송되는 디스크를 식별하고 대상 리전으로 전송합니다. Amazon Glacier 리전 마이그레이션을 수행하기 전에 대상 리전과 원본 리전이 AWS Import/Export 서비스를 지원하는지 확인하는 것이 좋습니다.

20 데이터베이스 Amazon RDS 서비스 마이그레이션 Amazon Relational Database Service(Amazon RDS)는 클라우드에서 관계형 데이터베이스를 쉽게 설치, 운영 및 확장할 수 있는 웹 서비스입니다. 본 서비스는 시간 소모적인 데이터베이스 관리 작업을 처리하는 한편, 비용 효율적이고 크기를 조정할 수 있는 용량을 제공하므로, 고객사는 애플리케이션과 비즈니스에 좀 더 집중할 수 있습니다. 데이터베이스 보안 그룹 Amazon RDS에는 CIDR 표기법 IPv4 네트워크 주소 또는 Amazon EC2 보안 그룹을 사용하여 데이터베이스 서비스에 대한 액세스를 제한하는 고유의 보안 그룹 세트가 있습니다. Amazon EC2 보안 그룹과 마찬가지로 각 Amazon RDS 보안 그룹은 이름을 가지고 있으며 한 AWS 리전에 하나만 있습니다. 데이터베이스 인스턴스 및 데이터 고객은 애플리케이션에서 데이터 정지, 데이터베이스 이동 및 작업 다시 시작을 위해 가동 중지를 예약해야 할 수 있습니다. 종합적인 개요는 다음과 같습니다. 모든 트랜잭션을 중지하거나 스냅샷을 찍습니다(하지만 이 시점 후 변경이 손실되며 Amazon RDS 인스턴스에 변경을 다시 작용해야 할 수 있음). 임시 Amazon EC2 인스턴스를 사용하여 Amazon RDS의 모든 데이터를 파일에 덤프합니다. MySQL의 경우 mysqldump 도구를 사용합니다. 이 덤프를 압축해야 할 수 있습니다(bzip 또는 gzip 참조). MS SQL의 경우 SQL Server Management Studio 또는 SQL 데이터베이스 마이그레이션 마법사를 사용합니다. 참고: Amazon RDS는 Microsoft SQL Server 백업 파일 복원을 지원하지 않습니다. Oracle의 경우 Oracle Export/Import 유틸리티 또는 데이터 펌프 기능을 사용합니다( 참조). CP, FTP 또는 Rsync와 같은 표준 도구를 사용하여 이 데이터를 대상 리전의 인스턴스에 복사합니다. 새로운 Amazon RDS 보안 그룹을 사용하여 대상 리전에서 새 Amazon RDS 인스턴스를 시작합니다. 저장된 데이터를 가져옵니다. 데이터베이스가 활성이고 데이터베이스에 데이터가 있는지 확인합니다. 원본 리전에서 기존 Amazon RDS 인스턴스를 삭제합니다.

21 Amazon RDS 데이터베이스 서비스로 데이터 가져오기에 대한 자세한 내용은 Amazon RDS 사용 설명서의 DB 인스턴스로 데이터 가져오기를 참조하십시오. 18 Amazon DynamoDB 마이그레이션 Amazon DynamoDB는 완벽하게 관리되는 NoSQL 데이터베이스 서비스로서 원활한 확장성과 함께 빠르고 예측 가능한 성능을 제공합니다. DynamoDB는 동일한 리전 내에서 가용 영역 간에 데이터를 복제하지만 리전 간에는 기본적으로 데이터를 복제하지 않습니다. 하지만 Amazon Elastic MapReduce(EMR)를 사용하여 이 기능을 수행할 수 있습니다. 참고: 참조되는 DynamoDB 테이블은 원본 리전과 대상 리전에 모두 있어야 합니다. Amazon EMR 사용에 대한 자세한 내용은 Amazon DynamoDB 사용 설명서의 DynamoDB용 Amazon EMR 19 을 참조하십시오. 특정 가져오기/내보내기 지침에 대한 자세한 내용은 Amazon DynamoDB 사용 설명서의 EMR Hive 명령 20 을 참조하십시오. 타사 솔루션도 사용할 수 있습니다. 이 솔루션은 백업/복원을 자동으로 관리할 수 있으며 대체 리전으로 복원할 수 있습니다. 타사 솔루션을 사용할 때는 마이그레이션 수행 수 삭제되는 특별 보안 IAM 사용자 자격 증명만 공유하는 것이 좋습니다. Amazon SimpleDB 마이그레이션 Amazon SimpleDB는 데이터베이스 관리 작업 부담을 덜어주는 가용성 높고 유연한 비관계형 데이터 스토리지입니다. 개발자는 웹 서비스 요청을 통해 데이터 항목을 저장하고 쿼리하며 이후 나머지 부분은 Amazon SimpleDB가 처리합니다. AWS 리전 간에 Amazon SimpleDB 데이터를 복사하려면 한 리전의 Amazon SimpleDB 도메인에서 데이터를 추출하여 다른 리전의 적절한 대상에 복사하는 특정한 작업 또는 스크립트를 생성해야 합니다. 이 작업은 Amazon EC2 인스턴스에 호스팅되며 고객의 목적과 전문성에 적합한 관련 SDK를 사용합니다

22 마이그레이션 접근 방식에는 다음이 포함됩니다. 새 도메인과 기존 도메인에 동시 연결을 설정하고, 기존 도메인에서 데이터를 쿼리한 다음, 데이터를 새 도메인에 입력합니다. 기존 도메인에서 데이터를 추출하고 파일(또는 파일 세트)에 저장한 다음 해당 정보를 새 도메인에 입력합니다. API 호출 BatchPutAttribute를 사용하여 성능을 향상하고 수행되는 API 호출 수를 줄이는 것이 좋습니다. 필요에 맞는 타사 솔루션도 사용할 수 있습니다. 타사 솔루션을 사용할 때는 마이그레이션 수행 수 삭제되는 특별 보안 IAM 사용자 자격 증명만 공유하는 것이 좋습니다. Amazon ElastiCache 마이그레이션 Amazon ElastiCache는 클라우드의 인 메모리 캐시를 손쉽게 배포, 작동 및 조정할 수 있는 웹 서비스입니다. 현재는 안에 있는 모든 키를 개별적으로 알지 못하면 Amazon ElastiCache를 열거할 수 없습니다. 권장 접근 방식은 새로운 Amazon ElasticCache 클러스터를 시작하고 이 클러스터에서 애플리케이션 사용을 통해 자동으로 입력을 시작하는 것입니다. 애플리케이션 서비스 Amazon Simple Queue Service 대기열 마이그레이션 Amazon Simple Queue Service(Amazon SQS)는 컴퓨터 간에 주고받는 메시지를 저장하기 위한 안정적이고 확장 가능한 호스팅 대기열을 제공합니다. Amazon SQS 대기열은 리전별로 존재합니다. 대기열의 데이터를 마이그레이션하려면 원본 리전에서 대기열을 꺼내서 대상 리전의 새 대기열에 삽입해야 합니다. 대기열을 마이그레이션할 때는 메시지를 계속해서 대략적인 순서대로 처리해야 하는지를 알아야 합니다. 순서가 중요하지 않은 경우: 1. 대상 리전에서 새 대기열을 생성합니다.

23 2. 대상 리전의 새 대기열에 쓰기 위해 메시지를 대기열에 넣는 애플리케이션을 구성합니다. 3. 대상 리전의 새 대기열에서 읽기 위해 Amazon SQS 대기열에서 메시지를 읽는 애플리케이션을 구성합니다. 4. 기존 대기열에서 반복적으로 읽는 스크립트를 작성하고 새 대기열에 제출합니다. 5. 원본 리전의 기존 대기열이 비어 있는 경우 해당 대기열을 삭제합니다. 순서가 중요한 경우: 대상 리전에서 새 대기열을 생성합니다. 대상 리전에 추가 새 임시 대기열을 생성합니다. 대상 리전의 새 대기열에 쓰기 위해 메시지를 대기열에 넣는 애플리케이션을 구성합니다. 대상 리전의 새 임시 대기열에서 읽기 위해 SQS 대기열에서 메시지를 읽는 애플리케이션을 구성합니다. 기존 대기열에서 반복적으로 읽는 스크립트를 작성하고 새 임시 대기열에 제출합니다. 원본 리전의 기존 대기열이 비어 있는 경우 해당 대기열을 삭제합니다. 임시 대기열이 비어 있는 경우 새 대기열에서 읽도록 애플리케이션을 다시 구성하고 임시 대기열을 삭제합니다. Amazon Simple Notification Service 항목 마이그레이션 Amazon Simple Notification Service(Amazon SNS)는 클라우드에서 알림을 쉽게 설정, 운영, 전송할 수 있도록 지원하는 웹 서비스입니다. Amazon SNS 항목은 리전별로 존재합니다. 이 항목은 AWS Management Console을 통해 수동으로 또는 명령줄 도구나 직접적인 API 호출을 사용하여 프로그래밍 방식으로 대상 리전에서 다시 생성할 수 있습니다. 지정된 리전에서 현재 Amazon SNS 항목을 나열하려면 다음 명령을 사용합니다. sns-list-topics --region <sourceregionname> Amazon Simple Notification Service 명령줄 도구에 대한 자세한 내용은 참조하십시오.

24 배포 및 관리 AWS CloudFormation을 통한 마이그레이션 개발자와 시스템 관리자는 AWS CloudFormation을 통해 쉽게 관련 AWS 리소스 모음을 생성 및 관리하고 순서에 따라 예측 가능한 방식으로 프로비저닝하고 업데이트할 수 있습니다. AWS CloudFormation의 샘플 템플릿을 사용하거나 자신의 템플릿을 생성하여, 애플리케이션 실행에 필요한 AWS 리소스는 물론 기타 관련 종속성 또는 런타임 파라미터에 대해 기술할 수 있습니다. 자세한 내용은 참조하십시오. 많은 고객이 단일 AWS 리전 내에서 개발, 테스트 및 다중 생산 환경을 생성하기 위해 AWS CloudFormation을 사용하지만, 이 동일한 템플릿을 다른 리전에 재사용할 수 있습니다. 다른 리전에서 해당 템플릿을 약간 수정한 후 사용하여 재해 복구 및 리전 마이그레이션 시나리오를 처리할 수 있습니다. 일반적으로, 아래와 같이 리전 간에 다른 리전별 정보(예: AMI의 고유 ID)를 대체하기 위한 매핑 선언을 변경하여 AWS CloudFormation 템플릿을 즉시 사용할 수 있습니다. "Mappings" : { "RegionMap" : { "us-east-1" : { "AMI" : "ami-97ed27fe" }, "us-west-1" : { "AMI" : "ami-59c39c1c" }, "us-west-2" : { "AMI" : "ami-9e901dae" }, "eu-west-1" : { "AMI" : "ami-87cef2f3" }, "ap-southeast-1" : { "AMI" : "ami-c44e0b96" }, "ap-northeast-1" : { "AMI" : "ami-688a3d69" }, "sa-east-1" : { "AMI" : "ami-4e37e853" } } } 매핑 선언에 대한 자세한 내용은 AWS CloudFormation 사용 설명서의 매핑 선언을 참조하십시오.

25 CloudFormer를 사용하여 환경 캡처 CloudFormer은 고객이 기존 AWS 리소스에서 AWS CloudFormation 템플릿을 만들 수 있는 프로토타입 도구입니다. 기존 프로세스와 도구를 사용하여 애플리케이션 리소스를 프로비저닝하고 구성합니다. AWS 리전 내의 환경에서 이러한 리소스가 프로비저닝된 후 CloudFormer 도구는 리소스 구성의 "스냅샷"을 찍습니다. 이러한 리소스는 AWS CloudFormation 템플릿에 배치되며, AWS CloudFormation 콘솔을 통해 애플리케이션 환경의 사본을 시작할 수 있습니다. CloudFormer 도구는 템플릿을 한층 더 사용자 지정할 수 있도록 AWS CloudFormation 템플릿의 시작점을 생성합니다. 예를 들면, 다음을 수행할 수 있습니다. 시작 시간에 스택이 구성될 수 있도록 파라미터를 추가합니다. 특정 환경과 지리적 리전에 맞게 템플릿을 사용자 지정할 수 있도록 매핑을 추가합니다. 리소스 간의 속성 데이터 흐름을 위해 정적 값을 Ref 및 Fn::GetAtt 함수로 대체합니다. 여기서 한 속성의 값은 다른 리소스의 속성 값에 따라 다릅니다. 시작 시간에 Amazon EC2 인스턴스에 파라미터를 전달하기 위한 Amazon EC2 인스턴스 사용자 데이터를 입력합니다. Amazon RDS 데이터베이스 인스턴스 이름과 마스터 암호를 사용자 지정합니다. 고객 리소스 스택을 캡처하는 CloudFormer 설정에 대한 자세한 내용은 참조하십시오. 참고: CloudFormer는 현재 VPC 관련 구성 가져오기를 지원하지 않습니다. API 함축 AWS 리전에 연결하기 위해 프로그래밍 방식의 액세스가 필요한 경우 퍼블릭으로 정의한 엔드포인트를 API 서비스 요청에 사용해야 합니다. 일부 웹 서비스에서는 리전을 지정하지 않는 일반 엔드포인트를 사용할 수 있지만, 이러한 일반 엔드포인트는 실제로 서비스의 특정 리전별 엔드포인트로 확인됩니다. 현재 리전 및 서비스 엔드포인트 URL의 신뢰할 수 있는 목록에 대한 자세한 내용은 참조하십시오.

26 고객 스크립트 및 프로그램 업데이트 적절한 리전별 엔드포인트와 통신하도록 보장하기 위해 AWS API와 상호 작용하는 자체 개발 스크립트와 프로그램을 업데이트해야 할 수 있습니다(직접적으로 또는 SDK나 명령줄 도구 중 하나 사용하여 업데이트). 각 SDK에는 액세스되는 리전을 지정하기 위한 고유의 형식이 있습니다. 명령줄 도구는 일반적으로 region 파라미터를 지원합니다. 중요 고려 사항 AWS 인증서나 프라이빗 키를 디스크에 그대로 두지 마십시오. 명령 또는 환경 변수에 비밀 정보를 입력한 경우 셸 기록 파일을 지우십시오. 암호를 계정에서 활성인 상태로 두지 마십시오. 이미지에 authorized_keys 파일의 퍼블릭 SSH 키가 포함되지 않는지 확인하십시오. 이 경우 다른 사람이 의도적으로 사용하지 않더라도 다른 사람의 서버에 백도어가 생깁니다. [--region], [--kernel], [--ramdisk] 등의 옵션이 선택적이더라도 적용 가능한 경우 항상 옵션을 사용하는 것이 좋습니다. IP 주소 연결이 AMI와 연결되는지 확인합니다. 연결되는 해당 연결을 제거하고 경우 마이그레이션 후 정확한 세부 정보로 수정합니다. 마무리 인사 시스템 마이그레이션을 수행할 때는 항상 포괄적으로 계획하고 테스트하는 것이 좋습니다. 예상치 않은 결과에 대한 장애 복구 프로세스와 함께 마이그레이션의 모든 요소를 반드시 계획하고 해야 합니다. AWS에서는 비용 효과적으로 테스트할 수 있으며 마이그레이션이 성공적으로 완료될 때까지 기존 시스템 인프라를 유지할 수 있으므로 이 프로세스를 더 쉽게 진행할 수 있습니다.

27 문서 수정 2012년 11월 최초 릴리스 2012년 12월 EBS 스냅샷 복사(리전 간 복사) 추가 보류 중인 AMI 복사 표시 레거시 AMI 복사 제거 2013년 1월 S3의 DNS Zone Apex 지원에 대한 오래된 제한 사항 제거 2013년 3월 AMI 복사 기능에 대한 세부 정보 추가

Web Application Hosting in the AWS Cloud Contents 개요 가용성과 확장성이 높은 웹 호스팅은 복잡하고 비용이 많이 드는 사업이 될 수 있습니다. 전통적인 웹 확장 아키텍처는 높은 수준의 안정성을 보장하기 위해 복잡한 솔루션으로 구현

02 Web Application Hosting in the AWS Cloud www.wisen.co.kr Wisely Combine the Network platforms Web Application Hosting in the AWS Cloud Contents 개요 가용성과 확장성이 높은 웹 호스팅은 복잡하고 비용이 많이 드는 사업이 될 수 있습니다. 전통적인