기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 플랫폼 파운데이션
<a name="platform-foundation"></a>

이 섹션에서는 온프레미스 인프라의 준비 상태 평가, AWS 랜딩 존 준비 또는 기존 랜딩 존 설계 검토, 필요한 마이그레이션 도구 식별에 중점을 둡니다. 플랫폼 구축 시 고려해야 할 일반적인 인프라, 운영 및 보안 질문을 검토합니다. 답변과 결정을 마이그레이션 원칙으로 문서화합니다. 따라서 대규모 마이그레이션에 필요한 규모와 속도를 달성할 수 있는 견고한 플랫폼이 있습니다.

이 섹션에는 다음 주제가 포함되어 있습니다.
+ [대규모 마이그레이션을 위한 랜딩 존 고려 사항](landing-zone.md)
+ [대규모 마이그레이션을 위한 온프레미스 고려 사항](on-premises.md)
+ [마이그레이션 원칙 문서화](document.md)

# 대규모 마이그레이션을 위한 랜딩 존 고려 사항
<a name="landing-zone"></a>

*랜딩 존*은 확장 가능하고 안전한 잘 설계된 AWS 환경입니다. 계정 수를 정의하고 서브넷 및 보안 그룹을 설계하는 등 랜딩 존에 대한 표준을 설정하면 견고한 기반을 구축할 수 있습니다. 이 기반을 통해 클라우드 채택 여정을 가속화하는 동시에 비즈니스 민첩성과 거버넌스를 위한 환경을 대규모로 활성화, 프로비저닝 및 운영할 수 있습니다. 랜딩 존 및 랜딩 존 구축 전략에 대한 자세한 내용은 [안전하고 확장 가능한 다중 계정 AWS 환경 설정을](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/) 참조하세요.

랜딩 존 전략에 대한 표준 비즈니스, 운영, 보안 및 규정 준수 고려 사항 외에도 대규모 마이그레이션을 용이하게 하는 방법을 고려해야 합니다. 일부 워크로드가 온프레미스에 남아 있는 경우 마이그레이션 중 및 이후에 기존 온프레미스 워크로드를 지원하도록 랜딩 존을 설계해야 합니다. 이 가이드에서는 마이그레이션 속도와 전체 마이그레이션 타임라인에 영향을 미치는 추가 랜딩 존 고려 사항을 제공합니다.

일반적으로 랜딩 존은에서 새 워크로드를 지원하도록 설계 및 배포됩니다 AWS 클라우드. 이는 조직이 많은 수의 기존 애플리케이션을 마이그레이션하기로 결정하기 AWS 전에 채택하기 때문입니다. 이 접근 방식의 이점은 대규모 마이그레이션 AWS 전에 조직이에서 귀중한 지식과 기술을 얻는 것이지만, 다양한 이해관계자 간에 충돌을 일으킬 수도 있다는 것입니다. 일부 이해 관계자는 클라우드 네이티브 기능을 활용하고 싶기 때문에 마이그레이션 중에 애플리케이션을 현대화하려고 할 수 있습니다. 그러나 대규모 마이그레이션의 일반적인 목표는 워크로드를 수정하지 않고 가능한 한 많은 애플리케이션을 마이그레이션하여 마이그레이션 속도를 극대화하고 전환을 용이하게 하는 것입니다. 그런 다음 마이그레이션이 완료된 후 이러한 애플리케이션을 현대화합니다.

대규모 마이그레이션 프로그램 프로젝트에 영향을 미칠 수 있는 랜딩 존의 몇 가지 주요 요소는 다음과 같습니다.
+ 네트워크 대역폭 가용성 및 관리
+ 워크로드 격리 및 리소스 관리를 위한 계정 전략
+ 마이그레이션된 워크로드에 대한 보안 및 관리 제어

이 섹션에서는 AWS 랜딩 존을 구축할 때 고려해야 할 인프라, 작업 및 보안 질문을 검토합니다. 또한 대규모 마이그레이션 프로젝트를 지원하기 위해 랜딩 존을 설계하고 배포하는 방법에 대한 권장 사항도 포함되어 있습니다. 이 섹션의 질문에 답하면 이러한 결정은 마이그레이션 원칙이 되며, [대규모 마이그레이션 원칙으로 결정 문서화의 지침에 따라 문서화합니다](document.md).

## 인프라 고려 사항
<a name="infrastructure"></a>


| 고려한 적이 있나요? | 설명 | 작업 | 
| --- | --- | --- | 
|  일일 및 주당 얼마나 많은 데이터를 마이그레이션할 예정입니까?  |  원하는 마이그레이션 속도에 따라 네트워크 연결 유형과 네트워크 처리량 요구 사항이 결정됩니다. 또한 파도 계획 선택 기준에도 영향을 미칠 수 있습니다.  |  포트폴리오 평가를 완료한 후 클라우드에서 마이그레이션된 모든 리소스에 필요한 총 스토리지 양을 결정합니다. 이 값을 사용하여 현재 네트워크 대역폭을 사용하여 데이터를 마이그레이션하는 데 필요한 시간을 계산합니다. 마이그레이션 기간에 맞게 대역폭을 늘려야 하거나 AWS Snow Family 솔루션과 같은 대안을 사용해야 할 수 있습니다. [파운데이션 플레이북 템플릿](samples/foundation-playbook-templates.zip)에서 *데이터 복제 계산기*(Microsoft Excel 형식)를 사용하여 각 마이그레이션 웨이브에 필요한 대역폭을 계산할 수 있습니다.  | 
|  각 파도에서 소스 서버의 평균 쓰기 속도는 얼마입니까?  |  복제된 데이터를 전송하는 데 필요한 대역폭은 참여 소스 서버의 쓰기 속도를 기반으로 합니다. 서버 복제에 필요한 대역폭의 양은 소스 서버의 평균 쓰기 속도에 최대 파도의 서버 수를 곱한 값입니다.  |  포트폴리오 평가 중에 각 서버에서 별로 수행한 평균 데이터 쓰기 수를 결정해야 합니다. [파운데이션 플레이북 템플릿](samples/foundation-playbook-templates.zip)에서 *데이터 복제 계산기*(Microsoft Excel 형식)를 사용하여 마이그레이션 트래픽에 필요한 대역폭을 이해할 수 있습니다. 마이그레이션 트래픽에 필요한 대역폭은 일반적인 비즈니스 활동에 사용되는 대역폭에 추가됩니다. 마이그레이션이 완료되면 마이그레이션 활동을 지원하는 추가 대역폭이 더 이상 필요하지 않습니다.  | 
|  추가 네트워크 활동 또는 기존 인프라가 복제 속도를 제한하거나 줄일 수 있습니까?  |  네트워크 대역폭이 다른 비즈니스 기능도 지원하는 경우 이러한 활동은 마이그레이션 중에 서버를 복제하는 데 사용할 수 있는 대역폭의 양을 줄일 수 있습니다.  |  프로젝트 수명 주기 초기에는 모든 비즈니스 활동을 지원하는 데 필요한 네트워크 대역폭을 신중하게 평가하고 계산합니다. 온프레미스 파일 공유를의 데이터와 동기화하는 등 일반적인 비즈니스 활동, 서버 복제 및 새로운 마이그레이션 관련 활동에 필요한 대역폭을 고려합니다 AWS. 공급자가 네트워크 용량을 늘리는 데 긴 리드 타임이 있을 수 있으며 기존 온프레미스 인프라를 업그레이드해야 할 수 있습니다. 네트워크 인프라를 업그레이드한 결과로 추가 업그레이드가 필요한지 여부를 고려합니다. 프로젝트 초기에 대역폭 요구 사항을 평가하면 필요한 사항을 변경할 수 있습니다.  | 
|  현재 AWS 서브넷 전략이 온프레미스 워크로드 마이그레이션을 위한 IP 주소 지정 요구 사항을 충족합니까?  |  서버 수와 워크로드 격리 요구 사항은 랜딩 존의 서브넷 전략을 결정합니다. 대규모 마이그레이션에는 예상보다 더 큰 서브넷이 필요할 수 있습니다. 대규모 마이그레이션에서는 온프레미스 인프라의 설정과 유사한 서브넷의 워크로드를 그룹화합니다. 마이그레이션을 간소화하기 위해 처음에는 더 크고 평평한 서브넷 설계가 선호되며, 현대화 중에 필요에 따라 서브넷을 다시 설계합니다.  |  포트폴리오 평가에 인프라 인벤토리에 대한 충분한 정보가 있는 경우 온프레미스 네트워크 구조를 평가하고 가능한 한 빨리 랜딩 존 설계에 통합합니다.  | 
|  병렬로 복제하고 마이그레이션할 서버는 몇 개입니까?  |  가장 큰 마이그레이션 파도의 크기는 서브넷 요구 사항 및 [AWS 서비스 할당량에 영향을 미칩니다](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).  |  상위 수준 마이그레이션 계획을 검토하고 이를 사용하여 서브넷을 설계합니다. 예를 들어, 200개의 서버를 하나의 서브넷으로 마이그레이션할 계획이 있는 경우 해당 서브넷의 Classless Inter-Domain Routing(CIDR) 범위에는 목표 서버 수를 지원하기에 충분한 IP 주소가 있어야 합니다. 또한 필요에 따라 각 대상 계정의 AWS 서비스 할당량을 늘립니다.  | 
|  마이그레이션 리소스에 대한 보안 그룹 전략을 식별했습니까?  |  보안 그룹은 AWS 리소스의 인바운드 및 아웃바운드 트래픽을 관리하는 데 사용됩니다. 마이그레이션이 지연되지 않도록 보안 그룹을 조기에 설계하는 것이 중요합니다.  |  애플리케이션 우선 순위 지정을 위한 실행서에서 마이그레이션 전략을 검토한 다음 마이그레이션 전략을 기반으로 보안 그룹을 설계합니다. 예를 들어 마이그레이션 전략이 대부분의 워크로드를 리호스팅하는 경우 네트워크를 리팩터링하고 애플리케이션별 보안 그룹을 적용하는 대신 마이그레이션 전환을 지원하는 임시 일반 보안 그룹을 고려하세요.  | 
|  사용 중인 로드 밸런서가 있습니까?  |  일반적으로 로드 밸런서를 사용하여 환경에서 서버를 마이그레이션할 때는 로드 밸런서의 구성을 평가한 다음 로드 밸런서를 마이그레이션해야 합니다. 로드 밸런서의 마이그레이션 옵션에는 Elastic Load Balancing(ELB) 또는 파트너 어플라이언스 기반 솔루션 사용이 포함됩니다.  |  사용자 지정 구성을 고려하려면 검색 단계 초기에 로드 밸런서 평가를 시작해야 합니다. 대부분의 환경에서 로드 밸런서 구성은 상당히 표준이지만, 일부는 ELB로 마이그레이션할 수 있는지 아니면 파트너 어플라이언스 기반 솔루션으로 마이그레이션할 수 있는지 결정하는 복잡한 로직이 있을 수 있습니다.  | 
|  서버가 소스 IP 주소를 유지해야 합니까?  |  서버를 클라우드로 마이그레이션하는 가장 안전하고 쉬운 방법은 마이그레이션된 인스턴스에 새 IP 주소를 할당하는 것입니다. 경우에 따라 소스 서버와 동일한 IP 주소를 유지해야 할 수 있습니다. 예를 들어 레거시 애플리케이션에 하드코딩된 IP 주소가 있을 수 있으며,이 주소는 아무도 변경 방법을 모를 수 있습니다.  |  소스 IP 주소를 유지하면 웨이브 계획 시 이동 그룹을 구성하는 방식에 영향을 미칩니다. 가장 일반적인 접근 방식은 전체 서브넷을 단일 이동 그룹 AWS 으로 마이그레이션하는 것입니다. 이렇게 하면 네트워크 수준에서 라우팅 및 전환이 간단해지기 때문입니다. 다음은 IP 주소를 유지하기 위한 주요 작업입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/large-migration-foundation-playbook/landing-zone.html)  | 
|  소스와 간에 허용되는 지연 시간은 얼마입니까 AWS?  |  VPN 링크를 빠르게 설정한 다음를 사용하여 설정된 직접 연결로 전환할 수 있으므로 VPN 링크로 마이그레이션을 시작하는 것이 일반적입니다 AWS Direct Connect. VPN 링크는 일반적으로 지연 시간이 더 길고 가변적이므로 데이터 처리량과 더 중요한 것은 애플리케이션 응답 시간에 영향을 미칩니다.  |  지연 시간이 길거나 가변적인 연결 유형을 사용하는 경우 각 애플리케이션의 요구 사항을 검토하고 그에 따라 마이그레이션 웨이브를 계획합니다. 대체 연결 유형을 사용할 수 있는 경우 지연 시간이 짧은 연결이 필요한 애플리케이션을 이후 웨이브에 배치할 계획입니다.  | 

## 작업 고려 사항
<a name="operations"></a>


| 고려한 적이 있나요? | 설명 | 작업 | 
| --- | --- | --- | 
|  랜딩 존에 대한 AWS 계정 전략을 식별했습니까?  |  AWS 잘 설계된 환경의 모범 사례에서는 리소스와 워크로드를 여러 AWS 계정으로 분리하는 것이 좋습니다. AWS 계정을 격리된 리소스 컨테이너로 생각할 수 있습니다. 계정은 워크로드 분류를 제공하고 재해 발생 시 영향 범위를 줄일 수 있습니다.  |  애플리케이션 우선 순위 지정을 위한 실행서에서 선택한 마이그레이션 전략을 검토하고 이를 사용하여 계정 전략을 결정합니다. 예를 들어 가능한 한 빨리 마이그레이션하고 리호스팅이 가장 일반적인 마이그레이션 전략인 경우 더 적은 수의 계정을 관리하기가 더 쉽습니다. 그러나 마이그레이션 전략에서 애플리케이션을 현대화해야 하고 규정 준수를 위해 사업부를 분리해야 하는 경우 계정 전략에 각 사업부에 대해 하나 이상의 계정을 포함해야 합니다.  | 
|  마이그레이션 중에 모니터링 도구를 전환해야 합니까? 그렇다면 마이그레이션 프로세스의 일부입니까, 아니면 마이그레이션 전이나 후에 발생합니까?  |  모니터링 도구는 클라우드 운영에 매우 중요합니다. 호환성 또는 라이선스 이유로 기존 도구가 클라우드에서 작동하지 않을 수 있습니다. 설계의 일환으로에서 워크로드에 사용할 모니터링 도구를 결정해야 합니다 AWS 클라우드.  |  마이그레이션을 시작하기 전에 모니터링 도구를 선택합니다. 마이그레이션 팀에 마이그레이션 패턴에 모니터링 설정 지침이 포함되어 있는지 확인합니다. 필요에 따라 모니터링 도구를 대체하거나 재사용하는 자동화 스크립트를 구축하는 것이 좋습니다.  | 
|  애플리케이션 소유자를 식별했으며 클라우드에서 제대로 작동하기 위해 애플리케이션에 적용해야 하는 변경 사항을 알고 있습니까?  |  대규모 마이그레이션은 단순한 인프라 프로젝트가 아닌 혁신입니다. 마이그레이션을 지원하기 위해 애플리케이션 소유자를 조기에 포함합니다. 예를 들어 애플리케이션 소유자는 웨이브 계획을 검증하고, 테스트 계획을 생성하고, 전환에 참여합니다.  |  프로젝트 관리 사무실 및 Cloud Enablement Engine 팀과 협력하여 애플리케이션 팀 리더와 협력하고 모든 애플리케이션 팀에서 커뮤니케이션이 명확하게 이루어지도록 합니다. 커뮤니케이션 및 프로젝트 투명성에 대한 자세한 내용은 [AWS 대규모 마이그레이션을 위한 프로젝트 거버넌스 플레이북을 참조하세요](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/).  | 
|  백업 및 복구 솔루션을 선택했으며 마이그레이션된 워크로드에서 작동하나요?  |  백업 및 복구 도구는 클라우드 운영에 매우 중요합니다. 호환성 또는 라이선스 이유로 기존 도구가 클라우드에서 작동하지 않을 수 있습니다. 설계의 일환으로에서 워크로드에 사용할 백업 및 복구 도구를 결정해야 합니다 AWS 클라우드.  |  마이그레이션을 시작하기 전에 백업 및 복구 도구를 선택합니다. 마이그레이션 팀이 마이그레이션 패턴에서 백업 및 복구를 설정하기 위한 지침을 통합해야 합니다. 필요에 따라 백업 및 복구 도구를 대체하거나 재사용하는 자동화 스크립트를 구축하는 것이 좋습니다.  | 
|  모든 공유 서비스를 식별하고 랜딩 존에 배포했습니까?  |  *공유 서비스는* 이메일, Active Directory 또는 공유 데이터베이스 환경과 같은 여러 애플리케이션을 지원하는 서비스입니다. 마이그레이션된 애플리케이션이 예상대로 작동하도록 마이그레이션하기 전에 일반적으로 클라우드에 공유 서비스를 배포해야 합니다.  |  랜딩 존 설계를 완료하기 전에 인프라 팀 및 애플리케이션 팀 리더와 심층 분석 일정을 잡습니다. 마이그레이션을 시작하기 전에 클라우드에 배포해야 하는 공유 서비스 목록을 검토하고 확인합니다. 가장 일반적인 공유 서비스는 Active Directory, 네트워크 디바이스, 도메인 이름 시스템(DNS) 및 인프라 소프트웨어입니다.  | 
|  대상 AWS 리전 및 계정의 AWS 서비스 할당량을 검토했습니까?  |  모든 AWS 서비스에는 서비스 할당량이 있습니다. 이러한 할당량 중 일부는 증가할 수 있습니다. 전환 전에 할당량을 검토하는 것이 중요합니다. 리소스가 충분하지 않으면 전환이 실패할 수 있습니다.  |  마이그레이션 계획을 검토합니다. 서비스 할당량을 늘려야 하는 대상 계정의 경우 증가를 요청합니다. 자세한 내용과 지침은 [AWS 서비스 할당량을 참조하세요](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).  | 
|   AWS 지원 플랜을 업그레이드해야 합니까?  |  AWS 엔터프라이즈 지원 플랜은 24/7 전화 지원과 다른 플랜보다 빠른 응답 시간을 제공합니다. 전환 기간은 일반적으로 매우 짧기 때문에 전환 문제를 해결하는 데 도움이 되는 숙련된 엔지니어에게 액세스하는 것이 대규모 마이그레이션의 성공에 중요할 수 있습니다.  |   AWS 계정 팀에 문의하여 다양한 지원 옵션을 논의하고 대규모 마이그레이션 프로젝트에 적합한 지원 계획을 선택합니다.  | 
|  대규모 마이그레이션 계획에 대해 AWS 기술 계정 관리자(TAM)에게 알렸나요?  |   AWS Enterprise On-Ramp 지원 팀은 선제적 프로그램, 예방 프로그램 및 AWS 주제 전문가에 대한 액세스를 조정하는 기술 계정 관리자(TAMs) 풀을 할당합니다. TAMs 필요에 따라 지원 리소스의 가용성을 예약할 수 있습니다.  |   AWS 기술 계정 관리자에게 예정된 대규모 마이그레이션 프로젝트를 알리고 마이그레이션 계획을 공유합니다. TAMs 필요할 때 AWS 지원 리소스를 사용할 수 있도록 합니다. 예를 들어 TAMs 전환 중에 지원 엔지니어를 예약할 수 있으며, 엔지니어는 기술 문제를 완화하고 전환을 간소화하는 데 도움이 될 수 있습니다.  | 

## 보안 고려 사항
<a name="security"></a>


| 고려한 적이 있습니까? | 설명 | 작업 | 
| --- | --- | --- | 
|  액세스 관리를 위한 AWS Identity and Access Management (IAM) 역할 및 정책을 식별했습니까?  |  대규모 마이그레이션 프로젝트의 모든 구성원에 대한 자격 증명 및 액세스를 관리합니다. 마이그레이션된 리소스에 IAM 역할을 연결하고 액세스 정책을 정의하면 클라우드에서 마이그레이션된 리소스에 액세스할 수 있는 사용자를 제어할 수 있습니다.  |  마이그레이션 팀과 협력하여 역할과 책임을 식별합니다. 어떤 역할이 어떤 AWS 계정에 액세스할 수 있는지 결정하고 각 역할에 있는 액세스 수준을 식별합니다. 보안 팀과 협력하여 각 대상 AWS 리소스에 대해 IAM 역할이 올바른지 확인합니다.  | 
|  워크로드에 대한 규정 준수 요구 사항이 있나요?  |  워크로드에는 HIPAA(Health Insurance Portability and Accountability Act) 또는 PCI DSS(결제 카드 산업 데이터 보안 표준)와 같은 규정 준수 요구 사항이 다를 수 있습니다. 마이그레이션 전에 이러한 요구 사항을 식별하고 이를 충족하는 방법을 계획해야 합니다.  |  규정 준수 팀 및 포트폴리오 팀과 협력하여 각 애플리케이션의 규정 준수 요구 사항을 식별하고 그에 따라 대상 AWS 계정을 설계합니다. 예를 들어 일부 워크로드를 AWS GovCloud (US) 특정 리전으로 마이그레이션해야 할 AWS 수 있습니다. 애플리케이션 우선 순위 지정 및 웨이브 계획 프로세스의 뒷부분에서이 정보를 사용할 수 있도록 각 애플리케이션에 대한 규정 준수 요구 사항을 문서화하는 것이 좋습니다.  | 
|  보안 팀이 마이그레이션 중에 사용하려는 도구 또는 서비스를 검토하고 승인해야 합니까?  |  로 대규모 마이그레이션 프로젝트는 AWS Application Migration Service AWS Database Migration Service (AWS DMS) AWS DataSync및 포트폴리오 검색 도구(예: Flexera One)와 같은 많은 서비스를 AWS 클라우드 사용합니다. 일부 조직에서는 사용 전에 모든 새 도구 및 서비스를 승인해야 합니다.  |  마이그레이션 팀과 협력하여 마이그레이션에 사용할 것으로 예상되는 모든 도구, 서비스 및 애플리케이션을 식별합니다. 마이그레이션이 시작되기 전에 보안 팀과 협력하여 회사 정책을 검토하고 이에 따라 이러한 도구를 승인합니다.  | 

# 대규모 마이그레이션을 위한 온프레미스 고려 사항
<a name="on-premises"></a>

비즈니스 운영을 지원하는 온프레미스 인프라도 대규모 마이그레이션에 대비해야 합니다. 현재 인프라를 준비하면 대규모 마이그레이션이 비즈니스 운영 및 애플리케이션 사용자에게 미치는 영향을 줄일 수 있습니다.

이 섹션에서는 대규모 마이그레이션을 위해 온프레미스 인프라를 준비할 때 고려해야 할 인프라, 작업 및 보안 질문을 검토합니다. 이 섹션의 질문에 답하면 이러한 결정은 *마이그레이션 원칙*이 되며, [대규모 마이그레이션 원칙으로 결정 문서화의 지침에 따라 문서화합니다](document.md).

## 인프라 고려 사항
<a name="on-premises-infra"></a>


| 고려한 적이 있습니까? | 설명 | 작업 | 
| --- | --- | --- | 
|  대상 AWS 계정과 주고받는 트래픽을 지원하도록 온프레미스 DNS 및 라우터를 설계했습니까?  |  서버와 대상 AWS 계정이 많기 때문에 마이그레이션 전략과 규모를 지원하도록 다양한 네트워킹 구성 요소가 올바르게 구성되었는지 확인하는 것이 중요합니다.  |  라우팅 테이블의 설계를 검토하고 AWS 계정과 온프레미스 데이터 센터 간에 올바른 경로가 있는지 확인합니다. 또한 DNS 서버가 온프레미스 서버와 AWS 리소스 모두에서 DNS 쿼리를 지원할 수 있는지 확인합니다.  | 
|  마이그레이션 팀은 온프레미스와 AWS 환경 모두에 어떻게 액세스하나요?  |  마이그레이션 팀은 소스 및 대상 서버에 액세스하여 소스 서버에 복제 에이전트를 설치하거나 대상 서버에 이전 소프트웨어를 제거하는 등 마이그레이션 활동을 수행해야 합니다.  |  기존 인증 및 권한 부여 메커니즘을 검토하고 액세스 권한을 부여하는 전략을 수립합니다. Active Directory 그룹, IAM 역할 및 Security Assertion Markup Language 2.0(SAML 2.0) 페더레이션을 사용하여 AWS 계정에 대한 Single Sign-On을 허용할 수 있습니다. Active Directory에 인증 문제가 있는 경우 로컬 관리자 사용자를 생성하는 것이 좋습니다.  | 
|  현재 네트워크 구성에 마이그레이션 중에 데이터 처리량을 늦출 수 있는 알려진 혼잡 지점이 있습니까?  |  대규모 마이그레이션에는 온프레미스 데이터 센터에서 클라우드로 데이터를 복제하는 데 많은 대역폭이 필요합니다. 기존 혼잡 지점 또는 제한 사항을 이해하면 마이그레이션을 더 잘 계획하는 데 도움이 됩니다.  |  네트워킹 팀과 함께 네트워크 구성을 검토하여 소스 시스템에서 대상 AWS 계정으로의 네트워크 경로를 더 잘 이해합니다. 마이그레이션 워크로드와 프로덕션 워크로드 간에 공유되는 연결과 같은 잠재적 혼잡 지점을 식별합니다.  | 

## 작업 고려 사항
<a name="on-premises-ops"></a>


| 고려한 적이 있습니까? | 설명 | 작업 | 
| --- | --- | --- | 
|  마이그레이션에 영향을 미칠 수 있는 *변경 동결*이라고도 하는 예약된 차단 일수가 있습니까?  |  마이그레이션 중 변경 중지로 인해 중요한 리소스와 시간이 진행 중인 마이그레이션 프로젝트에서 벗어날 수 있습니다.  |  운영 팀과 함께 변경 관리 프로세스를 검토하고 전환 기간을 계획할 때 차단된 일수를 고려합니다.  | 
|  마이그레이션을 위해 변경 일수를 예약했습니까?  |  변경 관리 프로세스는 복잡할 수 있으며 일부 조직에서는 특정 유지 관리 기간에만 변경을 허용합니다.  |  변경 관리 프로세스에 따라 변경 사항을 최소 5회 이상 미리 예약합니다. 이렇게 하면 지연을 방지하는 데 도움이 됩니다.  | 
|  마이그레이션 범위에 있는 모든 서버가 최근에 재부팅되었습니까?  |  시스템 변경 또는 제거된 패치는 마이그레이션 중에 문제를 일으킬 수 있으며, 이로 인해 긴 전환 기간이 필요하거나 서버를 롤백해야 합니다. 마이그레이션하기 전에 대상 측에서 서버가 최근에 재부팅되었는지 확인하는 것이 가장 좋습니다.  |  마지막 서버 재부팅 날짜를 검토합니다. 지난 90일 이내에 서버를 다시 시작하지 않은 경우 서버를 마이그레이션하기 전에 다시 시작을 예약하세요.  | 
|  재해 복구 및 비즈니스 연속성 계획은 현재 어떻게 작동하며, 이는 랜딩 존 설계에 반영되었습니까?  |  재해 복구 및 비즈니스 연속성 계획은 애플리케이션의 복구 시간 목표(RTO) 및 복구 시점 목표(RPO)를 충족하는 데 중요한 구성 요소입니다. 전환 기간 동안 이러한 계획이 온프레미스와 AWS 워크로드 모두에 적용되는지 확인해야 합니다.  |  기존 재해 복구 및 비즈니스 연속성 계획을 검토하고 계획이 대상 AWS 계정에 적합한지 확인합니다. 그렇지 않은 경우 워크로드를 로 이동하기 전에 새 계획을 설계합니다 AWS 클라우드.  | 

## 보안 고려 사항
<a name="on-premises-security"></a>


| 고려한 적이 있나요? | 설명 | 작업 | 
| --- | --- | --- | 
|  대규모 마이그레이션을 지원하는 방화벽 규칙을 생성했습니까?  |  조직의 프로세스에 따라 방화벽 구성에 대한 변경 요청을 완료하는 데 시간이 오래 걸릴 수 있습니다.  |  보안 팀과 함께 기존 방화벽 변경 프로세스를 검토하고 그에 따라 대규모 마이그레이션 방화벽 변경 전략을 설계합니다. 대규모 마이그레이션 프로젝트를 위한 사용자 지정 프로세스를 설계하거나 프로젝트 초기에 변경 사항을 제출해야 할 수 있습니다. AWS 가상 프라이빗 클라우드(VPC)를 데이터 센터의 확장으로 사용하는 것을 고려하고 너무 복잡한 방화벽 규칙을 구축하지 않는 것이 좋습니다. 이로 인해 대규모 마이그레이션이 크게 지연될 수 있습니다.  | 
|  환경에서 Active Directory를 AWS 설정했습니까?  |  Active Directory는 인증 및 권한 부여에 사용됩니다. 대상 계정 워크로드가 인증 및 권한 부여를 위해 도메인 컨트롤러에 연결할 수 있는지 확인해야 합니다. 대상 VPC에 새 도메인 컨트롤러를 추가하거나 AWS 워크로드가 온프레미스 도메인 컨트롤러에 연결되도록 허용할 수 있습니다.  |  보안 및 인프라 팀과 함께 Active Directory 설계를 검토합니다. 대상 AWS 계정에 올바른 도메인 컨트롤러에 연결되어 있는지 확인합니다. 의 워크로드가 가장 가까운 도메인 컨트롤러에 연결할 수 있도록 대상 AWS 서브넷 CIDR 블록 AWS 이 올바른 Active Directory 사이트에 있는지 확인합니다.  | 
|  타사 연결 및 애플리케이션 상호 종속성을 식별했습니까?  |  타사 연결 및 애플리케이션 상호 종속성을 사용하려면 방화벽 규칙, 네트워크 액세스 제어 목록 및 보안 그룹을 수정해야 합니다.  |  애플리케이션 소유자와의 심층 분석 세션 중에 각 애플리케이션의 외부 종속성을 검토합니다. 서드 파티 종속성 요구 사항에 따라 방화벽 규칙 및 네트워크 액세스 제어 목록을 수정하고 그에 따라 보안 그룹을 변경하는 요청을 제출합니다.  | 
|  온프레미스 환경에 CyberArk와 같은 시스템에서 실행되는 액세스 및 프로세스를 제어하는 추가 보안 도구가 있습니까?  |  마이그레이션 도구가 랜딩 존에서 작동하도록 허용하려면 이러한 보안 도구를 평가하고 업데이트해야 할 수 있습니다 AWS .  |  소스 환경에서 액세스 정책을 검토합니다. 액세스 정책에서 보안 도구를 사용하는 경우에서 도구가 작동하는지 확인한 AWS 클라우드다음 마이그레이션 팀이 소스 환경과 대상 환경 모두에 액세스할 수 있는지 확인합니다. 변경이 필요한 경우 마이그레이션 런북에 다음 단계를 추가합니다.  | 

# 마이그레이션 원칙 문서화
<a name="document"></a>

랜딩 존과 온프레미스 고려 사항을 검토한 후 답변과 결정을 기록해야 합니다. 이는 프로젝트의 나머지 부분을 안내하는 마이그레이션 원칙이 됩니다.

다음을 수행합니다.

1. [파운데이션 플레이북 템플릿](samples/foundation-playbook-templates.zip)에서 *마이그레이션 원칙 템플릿*(Microsoft Word 형식)을 엽니다.

1. 이 가이드의 [대규모 마이그레이션을 위한 랜딩 존 고려 사항](landing-zone.md)과 대규모 마이그레이션을 [위한 온프레미스 고려](on-premises.md) 사항 섹션에서 인프라, 운영 및 보안 고려 사항을 검토하고 권장 팀과 질문에 대해 논의합니다.

1. 마이그레이션 원칙 문서에 인프라, 운영 및 보안 결정을 문서화합니다. 이러한 결정을 기록하는 방법에 대한 예는 다음 표를 참조하세요.

1. 사용 사례에 필요한 경우 새 범주, 항목 및 원칙을 추가합니다. 예를 들어 포트폴리오 평가 또는 프로젝트 관리 결정을 위한 마이그레이션 원칙을 기록할 수 있습니다.

다음은이 가이드의 일부 질문에 결정을 기록하는 방법의 예입니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/large-migration-foundation-playbook/document.html)