방향성 비즈니스 사례 생성 - AWS 권장 가이드
방향성 비즈니스 사례의 범위 수정포커스 값 동인데이터 요구 사항인프라 TCO 비교 구축운영 비용 최적화 구축전체 방향성 비즈니스 사례로 확장마이그레이션 및 현대화 프로그램 설정 추정

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

방향성 비즈니스 사례 생성

비즈니스 전반의 이해관계자는 각 단계에서 혁신을 위해 비즈니스 사례를 이해하고 구매해야 합니다.

초기 단계에서는 프로그램을 계획하고 설정하는 데 필요한 리소스를 보호할 수 있도록 마이그레이션 프로그램의 잠재적 가치를 충분히 빠르게 보여주는 것이 중요합니다. 방향성 비즈니스 사례는 조기에 수집할 수 있는 제한된 데이터로 매력적인 비즈니스 가치를 달성하는 데 합리적인 확신을 제공하도록 설계되었습니다.

프로그램이 설정되면 비즈니스 사례가 추가로 개발됩니다. 자세한 사례는 정확도를 높이고, 프로그램 가치를 보다 완벽하게 파악하고, 계획 우선 순위에 대한 통찰력을 제공합니다. 조직이 구매하는 계획된 비즈니스 성과를 정의하고 정량화하며, 프로그램 거버넌스 사무실이 프로그램을 조정하고 성과를 측정할 수 있는 기준을 설정합니다.

방향성 비즈니스 사례의 범위 수정

방향성 비즈니스 사례는 일반적으로 2~4주 이내에 빠르게 수집됩니다. 리소스를 보호하여 핵심 팀을 설정하고, 필요한 경우 AWS 파트너를 참여시키고, 최소한 우선 순위가 지정된 애플리케이션 평가, 포트폴리오 분석 및 마이그레이션 계획 단계를 완료할 수 있도록 충분한 신뢰도를 생성해야 합니다.

일반적으로 포트폴리오 마이그레이션을 지원하는 방향성 비즈니스 사례는 다음 중 하나로 생성됩니다.

  • 있는 그대로 인프라 환경과 마이그레이션 후 AWS 서비스 아키텍처 간의 간단한 총 소유 비용(TCO) 비교입니다. 비교는 지정된 워크로드 볼륨에 대한 예상 실행 속도의 차이를 보여줍니다.

  • AWS 마이그레이션 비용 대비 그대로 유지하기 위해 마이그레이션하기 위한 순 현재 가치(NPV), 투자 수익률(ROI), 회수 기간, 수정된 내부 수익률(MIRR) 및 3~5년 현금 흐름 분석을 보여주는 비즈니스 사례입니다.

방향성 비즈니스 사례 범위는 일반적으로 다음 중 하나로 제한됩니다.

  • 인프라 기술 비용 비교

  • 인프라 기술 및 운영 비용 비교

일반적으로 포트폴리오가 클수록 개발되지 않은 사례가 되어야 합니다. 이는 결과에 큰 영향을 주지 않고 더 광범위한 가정을 할 수 있기 때문입니다. 작은 포트폴리오의 경우 변경 사항이 더 큰 영향을 미치므로 더 자세히 설명해야 합니다.

먼저 기본 인프라 비용 비교를 구축합니다. 그런 다음 계속하기 전에 비교가 충분히 설득력이 있는지 확인합니다. 일반적으로 400개 이상의 서버 포트폴리오는 운영 후 3년 이내에 인프라 비용 절감만으로 AWS또는 5년 이내에 250개의 서버로 구성된 긍정적인 비즈니스 사례를 보여주지만 이는 다를 수 있습니다. 더 작은 포트폴리오의 경우 더 자세한 정보가 필요할 수 있습니다.

반대로 총 마이그레이션 범위가 약 5개의 워크로드 또는 50개의 서버 미만이 아닌 한 복원력 향상 또는 비즈니스 민첩성에서 파생된 값과 같은이 단계에서 다른 비즈니스 가치 구성 요소를 검사하는 것은 거의 유용하지 않습니다.

포커스 값 동인

인프라 기술 TCO 비교는 있는 그대로 인프라 비용의 모델을 동등한 성능과 가용성으로 워크로드를 실행하는 데 필요한 재료 AWS 서비스 표의 기본 모델과 비교합니다. 많은 최적화를 수행할 수 있습니다. 그러나이 단계에서는 다음 목록에 중점을 둡니다. 평가하기가 더 쉽고 일반적으로 약 30%의 TCO 절감을 달성하므로 앞으로 진행하기에 충분하기 때문입니다.

  • 컴퓨팅 탄력성 - 8x5(24% 사용), 10x5(30%) 또는 10x6(36%)을 실행하는 개발 또는 UAT 서버, 2%로 실행되는 재해 복구(DR) 서버와 같이 사용량이 100%가 아닌 서버를 사용 시에만 청구되는 온디맨드 서비스에 매핑합니다.

  • 절감형 플랜으로 조달 - 비용을 최대 75% 절감할 수 있는 적절한 절감형 플랜으로 사용량이 많은(36% 초과) 프로덕션 서버 및 기타 서버를 조달할 계획을 세우세요. 옵션에는 1년 약정과 3년 약정이 포함되며, 할인을 강화하기 위해 선결제 금액이 다릅니다.

  • 좀비 제거 - CPU 사용률이 2% 미만이며 더 이상 필요하지 않음을 확인할 수 있는 서버를 식별하고 비용 분석에서 제거합니다.

  • 컴퓨팅 적정 크기 조정 - CPU 및 메모리 사용률 시계열 데이터를 사용하여 각 서버에 필요한 컴퓨팅 성능과 메모리를 평가합니다. 그런 다음 적합한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 선택합니다.

  • 관계형 데이터베이스 관리 시스템(RDBMS) 라이선스 적정 크기 조정 - 데이터베이스 서버의 컴퓨팅 적정 크기 조정 후 RDBMS 라이선스 요구 사항을 재평가하고, 기존 보유 라이선스 사용(BYOL)과에서 라이선스 조달을 비교하고 AWS, Amazon Relational Database Service(Amazon RDS)가 비용 절감을 늘릴 수 있는 가능성을 살펴봅니다.

  • 스토리지 - 필요한 총 스토리지 볼륨의 크기를 적절하게 조정하고 포트폴리오 전반의 초당 입/출력 작업(IOPS) 요구 사항을 식별합니다. SLAs와 비용이 서로 다른 객체 스토리지로 이동할 수 있는 양을 결정합니다.

데이터 요구 사항

초기 평가 데이터 요구 사항 이해의 표에는 방향성 비즈니스 사례의 각 부분을 구축하는 데 필요한 데이터와 필수인지 선택 사항인지가 나와 있습니다.

사례를 구축하려면 초기 계획 데이터의 인프라 하위 집합과 비용 데이터가 필요합니다. 포함할 인프라를 식별하는 방법은 비즈니스 목표에 따라 결정됩니다.

  • 프로그램의 목표가 특정 애플리케이션을 마이그레이션하고 현대화하는 것이라면 공유된 인프라를 고려하여 애플리케이션에 필요한 것을 기반으로 인프라 포트폴리오를 구축합니다.

  • 임대가 만료될 예정인 데이터 센터에서 마이그레이션하는 등 프로그램의 목표가 인프라 중심인 경우 인프라 TCO 비교에 애플리케이션 매핑이 필요하지 않습니다.

선택 사항으로 표시된 데이터(예: 서버의 CPU 및 메모리 최대 사용률)는 일반적으로 표준 벤치마크 값으로 대체할 수 있습니다. AWS 파트너 또는 AWS 전문 서비스와 이에 대해 논의할 수 있습니다. 또는 포트폴리오의 일부에서 사용할 수 있는 데이터 포인트(예: 하이퍼바이저에서 수집한 데이터)에서 값을 추정할 수 있습니다. 포트폴리오가 클수록 더 정확합니다.

인프라 TCO 비교 구축

도구는 인프라 TCO 비교를 구성하는 데 매우 중요합니다. AWS 전문 서비스 또는 AWS 파트너는 특히 광범위한 마이그레이션 프로세스를 지원하기 위해 참여하려는 경우 모든 유형의 방향성 사례에 도움을 제공할 수 있습니다.

다음을 수행하는 데 사용할 수 있는 도구가 있습니다.

  • 인벤토리 데이터를 수집합니다.

  • 사용률 데이터를 수집합니다.

  • 정확한 그대로 인프라 비용 벤치마킹 데이터를 제공합니다.

  • 좀비 식별 및 제거.

  • 적절한 크기의 평가를 수행합니다.

  • 구매 옵션을 권장합니다.

  • 소프트웨어 라이선스 옵션을 비교합니다.

  • 간단한 그래픽 현금 흐름 분석을 생성합니다.

의 마이그레이션 평가자는 한 가지 옵션 AWS 입니다. 이러한 모든 기능을 무료 관리형 서비스로 제공합니다. AWS 계정 관리자 또는 마이그레이션 역량 파트너를 통해 또는 온라인으로 요청을 제출하여 AWS 마이그레이션 평가자를 요청할 수 있습니다. https://pages.awscloud.com/Migration-Evaluator-request.html 마이그레이션 평가자는 인프라 기술 TCO 비교를 신속하게 생성하기 위한 포인트 솔루션으로 특별히 설계되었습니다.

주요 이점:

  • 무료

  • 도구 기반 검색이 제한된 인벤토리 데이터의 에이전트 없는 검색 또는 수동 구성

  • 배포, 구성, 데이터 수집 및 기본 사례 또는 방향성 비즈니스 사례 구축을 지원하는 전용 지원

  • SaaS 작업의 편리성. 하지만 분석 엔진에 로드하기 전에 스크러빙을 지원하기 위해 고객 네트워크 내에서 데이터 수집을 완전히 실행할 수 있음

  • Microsoft 라이선스 적정 크기 조정에 대한 강력한 지원

  • 전체 데이터 내보내기 기능

주요 제한 사항:

  • x86 아키텍처 서버(Windows 및 Linux)만 평가

  • 벤치마크를 있는 그대로 구성하거나 보정하는 제한된 옵션 비용 데이터

  • 운영 비용 최적화 모델링을 지원하지 않음

  • 마이그레이션 비용 모델링을 지원하지 않음

  • TCO 비교 이상의 비즈니스 사례 구축을 직접 지원하지 않음

애플리케이션 스택 및 상호 종속성 검색과 같은 포트폴리오 검색 및 분석 기능에 상용 검색 도구를 사용하기로 결정한 경우 일반적으로 인프라 TCO 비교도 제공합니다. 포트폴리오 검색 및 평가를 위한 도구 사용에 대한 지침은 검색 도구의 필요성 평가를 참조하세요. 시장 최고의 도구의 주요 기능을 검토하고 비교하려면 검색, 계획 및 권장 마이그레이션 도구를 참조하세요.

운영 비용 최적화 구축

IT 운영 생산성 개선은 마이그레이션의 중요한 가치 기여자인 경우가 많습니다. Amazon Web Services를 통한 비즈니스 가치 창출을 위한 비즈니스 및 조직 변환 촉진 백서에 따르면 마이그레이션 후 평균적으로 마이그레이션을 통해 AWS IT 운영 직원 생산성이 62% 증가합니다. 그러나 크기 조정과 방향성 사례에 이러한 이점을 포함하는 데는 두 가지 문제가 있습니다.

첫째, 생산성 향상의 전체 범위를 평가하려면 광범위한 데이터 수집이 필요하며 자세한 비즈니스 사례에 더 적합합니다. 이 문제는 간단한 벤치마크 데이터로 보다 쉽게 평가되고 크기가 조정되지만 여전히 상당한 이점을 보이는 몇 가지 요소에 집중하여 해결할 수 있습니다.

둘째, 비용 절감의 원인으로 생산성에 집중하면 주요 고객 이해관계자와 프로그램 구성원 간에 우려와 부정성이 발생할 수 있습니다. 혜택이 실현되는 방식과 영향을 받는 사람에게 어떤 의미가 있는지 명확하게 설명해야 합니다. 이러한 문제는 팀의 역할만 개선한다는 점을 명확히 하여 피할 수 있습니다.

  • 마이그레이션 프로그램에는 내부 운영 직원을 개발하고 코드 자동화로 인프라를 구축하는 DevSecOps 팀에 합류하고 팀의 성장을 주도할 자동화를 테스트하는 등 새로운 역할로 이동하는 트랙이 포함되어 있습니다.

  • 운영 아웃소싱 계약의 크기를 조정하고 조정하여 내부 직원이 더 가치 있는 활동에 더 집중할 수 있도록 함으로써 이점을 실현할 수 있습니다.

고려하려는 운영 혁신을 기반으로이 비즈니스 사례 요소를 구성하는 접근 방식:

  • 기존 사내 운영 팀이 있는 경우 팀원의 역량을 높이고 예상되는 생산성 개선을 보여줍니다.

  • 또는 현재 운영 솔루션에서 AWS Managed Services (AMS) 또는 AWS 파트너의 대체 관리형 서비스로 마이그레이션합니다.

첫 번째 변환의 경우 사례에 포함될 수 있는 생산성 향상에 대한 보수적인 재무 추정치를 얻으려면 다음을 수행하는 것이 좋습니다.

  1. 특히 서버 관리 운영 생산성에 중점을 둡니다. 운영 작업의 상당한 부분이고, 더 쉽게 평가할 수 있으며, 나중에 더 쉽게 확인할 수 있습니다.

  2. 각 FTE(정규직) 직원이 관리할 수 있는 서버 수에 대한 벤치마크를 기반으로 필요한 인력 배치를 계산합니다. 온프레미스에서이 수는 약 150개의 서버입니다. 약 400 AWS개의 서버가 있습니다.

  3. 이러한 지표를 EC2 인스턴스 수와 비교하여 온프레미스 서버 수에 적용합니다.

  4. 전체 운영 팀의 혼합 비용 요율로 절약된 시간을 곱합니다.

그런 다음 결과가 다음 표에 제공된 역할별 평균 생산성 향상을 크게 초과하지 않는지 확인하여 두 접근 방식 중 하나로 결과를 확인할 수 있습니다(IDC 백서 비즈니스 촉진 및 Amazon Web Services를 통한 비즈니스 가치 창출을 위한 조직 변환에서 가져온 데이터.

역할

효율성 향상

IT 인프라 관리

62%

IT 지원

59%

애플리케이션 관리

43%

데이터베이스 관리

19%

애플리케이션 개발

25%

두 번째 변환의 경우 범위 내 포트폴리오의 현재 총 운영 및 지원 비용을 고려 중인 관리형 서비스의 비용과 직접 비교하여 운영 비용 절감을 추가할 수 있습니다.

관리형 서비스의 비용을 얻으려면 AWS 계정 관리자 또는 AWS Managed Services 파트너에게 제안된 자재 AWS 명세서, 서비스 수준 선택(Plus 또는 Premium), AMS 패키지(AMS Accelerate 또는 AMS Advanced)를 제공합니다. 이렇게 하면 변환된 솔루션의 구성AWS 서비스 요소인에 대한 관리형 서비스의 총 비용이 제공됩니다. 마찬가지로 자체 파라미터를 기반으로 자체 관리형 서비스 패키지를 제공하는 AWS 파트너로부터 요금을 받을 수 있습니다.

전체 방향성 비즈니스 사례로 확장

일반적으로 전체 방향성 비즈니스 사례를 수집하려면 IT 생산성 요소를 사용하거나 사용하지 않고 TCO 비교를 구축하고 모든 마이그레이션 및 현대화 비용을 추정합니다. 그런 다음 migrate-and-modernize 시나리오 쌍과 t-migrate-and-modernize하지 않는 시나리오를 다루는 현금 흐름을 생성합니다.

가장 기본적인 사례는 단일 시나리오 쌍을 준비하는 것입니다. 여기서 t-migrate-and-modernize 않음 시나리오는 현재 상황이고 migrate-and-modernize 시나리오는 다음과 같은 특성을 갖습니다.

  • 트랜잭션 볼륨, 컴퓨팅 또는 네트워킹 용량의 증가 또는 감소 없음

  • 스토리지 요구 사항의 안정적인 소량 증가

  • 기존 시스템의 기능과 일치하는 Quality-of-service 기능(예: 가용성, 내구성, 처리량 및 성능)

매우 작은 포트폴리오를 제외한 모든 포트폴리오의 경우 방향성 사례를 잘 구축하는 목표에 적합합니다. 앞으로 나아갈 수 있는 권한을 얻기에 충분한 가치를 빠르게 보여줍니다.

소규모 포트폴리오의 경우 다음과 같이 클라우드 migrate-and-modernize와 마이그레이션 t-migrate-and-modernize 금지 시나리오 쌍을 추가하는 것이 유용할 수 있습니다.

  • 성장이 예상되는 워크로드 전반에서 중간 및 대용량 성장 요구 사항의 혼합

  • 고가용성, DR, 내결함성 등 향상된 복원력 포함

  • 엣지 컴퓨팅, 콘텐츠 전송 네트워크(CDN), 다중 리전 데이터베이스 복제를 통해 글로벌 성능을 개선했습니다.

  • 프로그램의 비즈니스 우선 순위를 설정한 기타 특정 개선 서비스 품질

이러한 시나리오의 경우 현재 클라우드가 아닌 인프라 아키텍처를 업그레이드하여 새 사양과 일치하도록 하는 데 따른 비용 및 현금 흐름 영향이 정확하게 추정되어야 합니다. 이 견적을 얻는 가장 직접적인 방법은 시스템 통합자에게 인용을 요청하는 것일 수 있습니다. 특히 마이그레이션 역량이 있는 AWS 컨설팅 파트너인 경우 migrate-and-modernize 시나리오와 t-migrate-and-modernize 시나리오를 모두 지원할 수 있습니다.

각 시나리오 쌍에 대해 다음으로 구성된 사례를 수집합니다.

  • t-migrate-and-modernize 않음 시나리오의 비용입니다. 가장 기본적인 경우에는 다음과 같습니다.

    • 현재 인프라 구성의 비즈니스 사례 기간 동안 총 소유 비용

    • 컴퓨팅, 스토리지 및 네트워크 트래픽 소비의 주기적 증가

  • 다음을 포함한 migrate-and-modernize 시나리오의 비용:

    • 세부 검색, 마이그레이션 계획, 세부 비즈니스 사례 개발, 핵심 팀 구축 및 기술 향상, 아직 없는 경우 랜딩 존 설정, 마이그레이션된 워크로드에 대한 보안 관리 및 운영 통합 설정 등 프로그램 설정

    • 워크로드 마이그레이션 및 현대화 비용

    • 네트워크 연결, AWS Snowball Edge 및와 같은 데이터 마이그레이션 서비스AWS DataSync, 마이그레이션 프로세스 자체에 필요한 아키텍처의 AWS 유틸리티 비용을 포함한 마이그레이션 인프라 비용(예: 테스트용)

    • 웨이브가 가동됨에 따라 마이그레이션 과정에서 AWS 유틸리티 비용 증가 및 AWS 기반 서비스로 대체되고 폐기될 때 기존 인프라 비용 감소

  • 모든 스트랜드 자산의 폐기 비용 및 상각

마이그레이션 및 현대화 프로그램 설정 추정

성공을 위한 프로그램을 설정하려면 일련의 기본 활동을 실행하여 기준 기능을 구축하고 이전에이 작업을 수행하지 않은 경우 세부 계획을 수립해야 할 수 있습니다. 이러한 기본 활동에는 다음이 포함됩니다.

  1. 포트폴리오 분석 및 마이그레이션 계획 섹션에 설명된 대로 자세한 포트폴리오 검색, 마이그레이션 계획 및 자세한 비즈니스 사례 개발을 수행하고 사용된 검색 도구의 비용을 문서화합니다.

  2. 교육 및 고용을 통해 클라우드 비즈니스 및 기술 핵심 팀을 구축하고 사내 기술을 개발합니다. 교육이 필요한 IT 조직의 구성원을 식별하고 각 개인에 대한 교육 예산을 할당합니다.

  3. 랜딩 존을 설정하고 필요한 비용, 운영 및 보안 거버넌스 기능을 지원하도록 구성합니다.

AWS 컨설팅 파트너는 항목 1과 3에 대한 견적을 제공하는 데 도움을 줄 수 있습니다.

마이그레이션 및 현대화 비용 추정

방향성 비즈니스 사례의 목표를 충족하고 다음 단계로 진행할 수 있는 상업적 잠재력만 보여주려면 마이그레이션 및 현대화 비용 추정을 가능한 한 기본으로 유지합니다.

이를 위해 다음 마이그레이션 전략에 속하는 애플리케이션에 집중하여 방향성 비즈니스 사례를 준비하는 것이 좋습니다.

  • 만료

  • 보관

  • 재배치하다

  • 리호스팅

  • 리플랫포밍

  • 재구매

일반적으로 워크로드의 약 70%를 리호스팅, 재배치 또는 리플랫포밍할 수 있으며, 또 다른 5%는 사용 중지할 수 있습니다. 마이그레이션 전략을 통해 애플리케이션을 평가하면 일반적으로 비용 절감 사례의 핵심이 해결됩니다.

리팩터링 또는 리아키텍팅 비용을 추정하는 것은 복잡할 수 있습니다. 방향성 비즈니스 사례를 준비하는 데 주어진 기간 내에 이를 시도하는 것은 실용적이지 않습니다. 앞서 마이그레이션을 위한 R 유형 결정에서 설명한 대로 마이그레이션 및 현대화의 첫 번째 단계에 리호스팅, 재배치 또는 리플랫포밍 전략을 사용하는 것이 좋습니다. 이러한 R 전략은 초기 회수를 가속화하고 구현 위험을 줄이며 단기적으로 비즈니스 사례를 개선할 가능성이 높습니다. 또한 애플리케이션 팀이 AWS 환경 내에서 실행 중인 애플리케이션을 그렇지 않은 애플리케이션보다 실제로 더 쉽게 현대화할 수 있습니다. 세부 비즈니스 사례를 준비할 때 특정 애플리케이션을 리팩터링(리아키텍처링)하기 위한 추정치를 추가하는 것이 가장 좋습니다.

전략별 마이그레이션 작업 추정

마이그레이션마다 다릅니다. 예산 또는 계획을 약정하기 전에 프로젝트를 책임질 팀의 마이그레이션 활동에 대한 워크로드 추정치를 시드합니다. 이는 사내 애플리케이션 팀, AWS 전문 서비스 또는 AWS 파트너 조직 등입니다.

방향성 사례를 구축하는 데 도움이 되도록 다음 표에는 다양한 처리에 대한 표시 작업 범위가 나와 있습니다. 이러한 범위는 medium-to-large 포트폴리오가 마이그레이션되고 있으며 마이그레이션 팀이 훈련되고 경험이 있다고 가정합니다. 소규모 포트폴리오의 경우 방향성 사례에도 마이그레이션을 담당하는 팀이 견적을 준비하도록 하는 것이 가장 좋습니다.

마이그레이션 전략 추정 프로세스 요소 사람 시간 사람 시간
Retain Do nothing, with no cost, no benefits, and no reduction in technology debt.

–

–

–
Retire Estimate decommissioning the hardware equipment used, if any.

–

–

–
Relocate Estimate copying the workload within VMware using VMware tools. This includes copying the data, smoke testing to verify, and any hardware decommissioning. The effort to relocate VMs is typically less than for low-complexity rehost patterns.

–

–

–
Rehost Estimate copying the workload and data with an image copy, smoke testing, high availability (HA) and disaster recovery (DR) testing where appropriate for production servers, and any hardware decommissioning. The best practice is to use tools such as AWS Application Migration Service. Divide workloads into low, medium, and high complexity, based on factors such as whether a database or other infrastructure software is running, database complexity, whether clustered, integration complexity, and data volumes. Effort per app per server Migration HA/DR test
Low 10–14 3–5
Medium 16–24 4–6
High 26–38 8–12
Replatform For replatform migrations that include upgrades to operating system or RDBMS version, take the estimate for a rehost, and add time to run a rebuild and smoke test on the new platform.If the replatform includes changing the technology of the platform, estimate additional time for the use of the conversion tools, such as AWS Schema Conversion Tool and AWS Database Migration Service, and a more complete application test. An example of changing the technology is migrating away from a proprietary commercial database to an open source replacement. Effort per app per server Version up Technology change
Low Add 1–3 Add 10–15
Medium Add 2–5 Add 20–30
High Add 4–8 Add 40–60
Repurchase Estimate data extraction, transformation, and uploading into the newly purchased SaaS service replacement, and any hardware decommissioning.

–

–

–

마이그레이션 인프라 비용 추정

마이그레이션 과정에서 사용할 인프라에 대한 추정치를 포함합니다. 일반적으로 이러한 추정치는 다음과 같습니다.

  • 현재 환경에서 로 워크로드 및 데이터 마이그레이션을 위한 연결 및 데이터 교환 서비스 예산 AWS

  • 마이그레이션, 테스트 및 전환 프로세스 중에 마이그레이션된 워크로드를 호스팅하는 데 필요한 AWS 서비스 (특히 컴퓨팅 및 스토리지) 예산

  • 각 마이그레이션 웨이브가 완료될 때 AWS 유틸리티 비용 증가

  • 마이그레이션된 워크로드를 더 이상 실행하지 않을 기존 인프라의 폐기 비용

데이터 교환의 경우 총 데이터 볼륨을 검사하고 네트워킹 사용 가능성을 평가합니다. 마이그레이션 후 운영상 사용할 수 있도록 AWS VPN에서 WAN의 특정 지점 AWS 으로 또는 AWS Direct Connect 링크를 미리 프로비저닝한 경우 해당 리소스를 서비스 할당량까지 사용할 수 있습니다.

네트워크 용량이 충분하지 않은 경우 가상 프라이빗 네트워크(VPN)를 사용하여 인터넷 대역폭을 단기적으로 늘리는 것이 비용 효율적인 솔루션인 경우가 많습니다. 그렇지 않은 경우 AWS Snowball Edge 및와 같은 AWS 미디어 교환 디바이스는 대부분 솔루션을 AWS Snowball Edge 제공합니다 AWS 리전. 또한 대용량 데이터 마이그레이션의 경우에 대한 예산을 포함AWS DataSync시켜 안정성을 개선하고 사용된 미디어에 관계없이 전송을 가속화할 수 있습니다.

비즈니스 사례의 현금 흐름 분석 요소에는 AWS 서비스 증가 및 기존 인프라 감소 모델링이 중요합니다. 이 단계에서는 비용이 발생하는 시기를 정확히 결정할 웨이브 플랜이 없을 것입니다. 다음과 같이 하는 것이 좋습니다:

  • 마이그레이션에 대한 비용을 AWS 일정한 속도로 높입니다.

  • 동일한 기간 동안 일정한 속도로 서비스 해제하려는 기존 인프라의 비용을 줄입니다.

기존 인프라가 축소되기 1~2개월 전에 AWS 비용이 증가합니다. 이렇게 하면 각 웨이브에 대해 마이그레이션을 수행할 수 있는 1개월의 AWS 유틸리티 사용량이 제공됩니다. 여기에는 테스트 시간과 교체된 인프라에서 비용 발생을 중지하는 데 필요한 서비스 해제 작업을 완료하는 추가 시간이 포함됩니다.

폐기 비용 추정

재배포할 수 없는 장비를 폐기하고 합법적이고 환경 친화적인 방식으로 폐기하면 약간의 비용이 발생할 수 있습니다. 그러나 방향성 비즈니스 사례의 경우 일반적으로 대체된 자산의 나머지 책 가치를 상각하는 비용이 유일한 금액입니다.

방향성 비즈니스 사례의 경우 다음을 수행하는 것이 좋습니다.

  • 자산 목록을 검토합니다.

  • 폐기할 항목을 식별합니다.

  • 상각을 줄이려면 디바이스를 전환할 기회를 검토하여 목록에 있는 최신 디바이스를 사용하여 더 오래되고 사용 중단된 자산을 교체할 수 있도록 합니다.

  • 해당 시점에 폐기될 자산의 장래 책 값을 평가합니다.

  • 이를 폐기의 마이그레이션 비용으로 포함합니다.

전체 방향성 비즈니스 사례 수집 및 조정

각 시나리오 쌍에 대한 전체 비용 세트를 준비한 후 각 시나리오에 대해 할인된 현금 흐름 명세서를 작성하고 그래프로 표시합니다. 하드웨어 새로 고침 주기와 동일한 기간 동안 방향성 비즈니스 사례를 구축하는 것이 좋습니다. 서버, 스토리지 및 네트워크 디바이스의 경우 일반적으로 5년입니다. 하드웨어 새로 고침 주기와 동일한 기간을 사용하는 경우 정확히 한 번의 새로 고침 비용이 각 시나리오의 있는 그대로 비용에 포함됩니다.

그런 다음 프로그램의 다음 단계로 진행하기 위한 승인을 받는 데 필요한 주요 재무 지표를 계산합니다. 일반적으로 다음을 포함합니다.

  • 평가된 비용 절감 및 생산성 향상의 절대값을 측정하기 위한 순 현재 가치(NPV)

  • 반환이 충분히 빠른지 확인하기 위한 월별 회수 기간

  • 프로세스가 기간 동안 충분한 비용을 소비하고 있는지 확인하기 위한 최종 실행률 비교

  • 조직이 우선시할 수 있는 다른 자본 수요에 비해 프로그램의 상대적 재무 성과를 평가하기 위한 투자 수익률(ROI) 및 수정된 투자 수익률(MIRR)

다음 예제와 같이 사례의 첫 번째 반복을 사용하여 예상 재무 성과가 개선이 이루어져야 함을 의미하는지 확인합니다.

  • 회수 속도가 너무 느리면 다음과 같이 마이그레이션 비용을 가속화하고 줄이는 옵션을 고려하세요.

    • AWS 파트너 또는 AWS 전문 서비스를 사용하여 사용 가능한 리소스를 확장하고 더 기본적인 패턴으로 워크로드 마이그레이션을 추가로 병렬화할 수 있습니다.

    • VMware에서 실행 중인 워크로드의 경우 최소한 초기 단계에서 재배치 전략을 리호스팅 또는 리플랫포밍 전략과 비교합니다. 재배치 전략을 사용하면 마이그레이션 비용을 줄이고 마이그레이션 속도를 높일 수 있습니다.

    • 기술적으로 가능한 경우 초기 비즈니스 사례 범위를 벗어나 더 복잡한 리플랫포밍 또는 리팩터링(리아키텍트) 전략이 필요한 워크로드를 미래 단계로 푸시합니다.

  • ROI와 MIRR이 너무 낮으면 다음을 고려하세요.

    • 고려 중인 시나리오가 너무 보수적입니까? 가장 가능성이 높은 용량 증가 및 탄력성 요구 사항을 반영하는 시나리오가 있습니까? 목표 내에서 서비스 품질 증가를 포함한 비용을 비교하는 시나리오가 있습니까?

    • 현재 사용률이 낮거나 비용이 많이 드는 재해 복구(DR) 요구 사항이 있는 워크로드와 같이 더 큰 수익을 낼 워크로드에 초점을 맞추기 위해 첫 번째 단계에서 마이그레이션할 애플리케이션 포트폴리오의 범위를 세분화할 수 있습니까?

    • 애플리케이션 포트폴리오의 범위를 구체화하여 처음에 덜 상업적으로 달성되는 특정 워크로드를 제외할 수 있습니까? 예를 들어 퍼블릭 클라우드 인프라에 배포하는 조건이 다르기 때문에 타사 소프트웨어 라이선스가 더 비싼 워크로드를 연기할 수 있나요?

  • 최종 실행률 비교가 예상 목표를 충족하지 않는 경우 다음을 살펴봅니다.

    • 먼저 다른 지표가 기대치를 충족하는지 확인합니다. 방향성 비즈니스 사례는 주로 마이그레이션 준비의 다음 단계를 시작하는 것을 정당화할 수 있는 충분한 재정적 기회가 있음을 보여주는 것입니다.

    • 마이그레이션의 초기 단계 AWS 이후에에서 비용 성능을 계속 개선할 수 있는 기회 목록을 식별합니다.

세부 비즈니스 사례를 준비할 때 기회 목록에 대한 평가를 포함합니다. 또한 사례의 지속적인 유지 관리와 마이그레이션 완료 후 month-to-month 비용 최적화 프로세스에 기회 평가를 포함시킵니다.