기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
AMS 모드의 실제 사용 사례
이를 검토하여 AMS 모드를 사용하는 방법을 결정합니다.
-
사용 사례 1, 시간에 민감한 데이터 센터 종료와 함께 비용을 절감하기 위한 비즈니스 요구 사항: 데이터 센터 종료와 같은 매력적인 비즈니스 이벤트가 있는 기업은 클라우드에서 온프레미스 애플리케이션을 다시 호스팅하는 데 관심이 있습니다. 대부분의 온프레미스 인벤토리는 운영 체제 버전이 혼합된 Windows 및 Linux 서버로 구성됩니다. 이를 통해 고객은 클라우드로 전환하여 애플리케이션의 기술 및 보안 태세를 개선하는 비용 절감을 활용하고자 합니다. 고객은 빠르게 움직이고 싶지만 아직 사내 클라우드 운영 전문 지식이 구축되어 있지 않습니다. 고객은 리팩터링의 균형을 찾아야 합니다. 리팩터링이 너무 많으면 촉박한 타임라인에 비해 위험할 수 있습니다. 그러나 OS 버전 업데이트 및 데이터베이스 최적화와 같은 일부 리팩터링을 통해 애플리케이션은 다음 수준의 성능을 달성할 수 있습니다. 이 예제에서 고객은 AMS 관리형 RFC 모드를 선택하여 대부분의 애플리케이션을 다시 호스팅할 수 있습니다. AMS는 인프라 운영을 제공하는 동시에 고객 운영 팀에 클라우드에서 안전하게 운영하는 모범 사례를 안내합니다.
AMS 관리형 AWS Service Catalog 및 AMS 관리형 Direct Change 모드는 고객에게 동일한 비즈니스 성과와 목표를 달성하면서 유연성을 높입니다. 또한 고객은 AMS Operations On Demand(OOD) 오퍼링을 사용하여 전용 AMS 운영 엔지니어가 변경 요청(RFCs.
차별화되지 않은 인프라 운영 작업(패치, 백업, 계정 관리 등)을 AMS로 오프로드하는 동안 고객은 애플리케이션을 최적화하는 데 계속 집중하고 클라우드 운영에서 내부 팀을 확장할 수 있습니다. AMS는 고객에게 비용 절감에 대한 월별 보고서를 제공하고 리소스 최적화에 대한 권장 사항을 제시합니다. 이 사용 사례에서는 Windows 2003 및 2008과 같은 레거시 OS 버전에서 호스팅된 end-of-life 애플리케이션이 있고 고객이 리팩터링하지 않기로 결정한 경우 해당 애플리케이션을 AMS로 마이그레이션하고 고객 관리형 모드를 활용하는 계정에서 호스팅할 수도 있습니다.
사용 사례 2, 보안 AMS 경계 내에서 Lambda, Glue, Athena로 데이터 레이크 구축: 기업은 AMS의 여러 애플리케이션에 대한 보고 요구 사항을 충족하기 위해 Data Lake를 설정하려고 합니다. 고객은 S3 버킷을 사용하여 데이터 세트를 저장하고 AWS Athena를 사용하여 각 보고서의 데이터 세트를 쿼리하려고 합니다. S3와 AWS Athena는 별도의 AMS 관리형 계정에 배포됩니다. S3가 있는 계정에는 데이터 수집 파이프라인을 빌드하기 위한 Glue, Lambda 및 Step Functions와 같은 다른 서비스도 있습니다. 이 경우 Glue, Lambda, Athena 및 Step Functions는 셀프 서비스 프로비저닝(SSP) 서비스로 간주됩니다. 또한 고객은 임시 도구/스크립팅 서버 역할을 하는 계정에 EC2 인스턴스를 배포했습니다. 고객은 먼저 AMS 관리형 계정에서 SSP 서비스를 활성화하도록 AMS에 요청합니다. AMS는 역할이 고객의 연동 솔루션에 온보딩되면 고객이 수임할 수 있는 각 서비스에 대해 IAM 역할을 프로비저닝합니다. 간편한 관리를 위해 고객은 별도의 IAM 역할에 대한 정책을 하나의 사용자 지정 역할로 결합하여 AWS 서비스 간에 작업할 때 역할을 전환할 필요성을 줄일 수도 있습니다. 계정에서 역할이 활성화되면 고객은 요구 사항에 따라 서비스를 구성할 수 있습니다. 그러나 고객은 AMS 변경 관리 시스템과 협력하여 사용 사례에 따라 추가 권한을 요청해야 합니다.
예를 들어 Glue 크롤러에 액세스하려면 Glue에 추가 권한이 필요합니다. Lambda에 대한 이벤트 소스를 생성하려면 추가 권한도 필요합니다. 고객은 AMS와 협력하여 Athena가 S3 버킷을 쿼리할 수 있도록 교차 계정 액세스를 허용하도록 IAM 역할을 업데이트합니다. Lambda가 Step Functions 서비스를 호출하고 Glue가 모든 S3 버킷을 읽고 쓸 수 있도록 AMS 변경 관리를 통해 서비스 역할 또는 서비스 연결 역할을 업데이트해야 합니다. AMS는 고객과 협력하여 최소 권한 액세스 모델을 따르고 요청된 IAM 변경 사항이 지나치게 허용적이지 않고 불필요한 위험에 노출되지 않도록 합니다. 고객의 데이터 레이크 팀은 고객의 아키텍처와 관련된 서비스에 필요한 모든 IAM 권한을 계획하고 AMS에 이를 활성화하도록 요청합니다. 이는 모든 IAM 변경 사항이 수동으로 처리되고 AMS 보안 팀의 검토를 받기 때문입니다. 이러한 요청을 처리하는 데 걸리는 시간은 애플리케이션 배포 일정에서 고려해야 합니다.
SSP 서비스가 계정에서 작동하므로 고객은 AMS 인시던트 관리 및 서비스 요청을 통해 지원을 요청하고 문제를 보고할 수 있습니다. 그러나 AMS는 Lambda에 대한 성능 및 동시성 지표 또는 Glue에 대한 작업 지표를 적극적으로 모니터링하지 않습니다. SSP 서비스에 대해 적절한 로깅 및 모니터링이 활성화되었는지 확인하는 것은 고객의 책임입니다. 계정의 EC2 인스턴스 및 S3 버킷은 AMS에서 완전히 관리됩니다.
사용 사례 3, AMS에서 CICD 배포 파이프라인의 빠르고 유연한 설정: 고객이 AMS의 모든 애플리케이션 계정에 코드 파이프라인을 배포하기 위해 Jenkins 기반 CICD 파이프라인을 설정하려고 합니다. 고객은 AMS 관리형 Direct Change 모드(DCM) 또는 AMS 관리형 개발자 모드에서이 CICD 파이프라인을 호스팅하는 것이 가장 적합할 수 있습니다. 이는 아티팩트 리포지토리를 호스팅하는 CloudFormation 및 S3 버킷에 액세스할 수 있는 원하는 IAM 권한과 함께 EC2에 필요한 사용자 지정 구성으로 Jenkins 서버를 유연하게 설정할 수 있기 때문입니다. AMS 관리형 RFC 모드에서도이 작업을 수행할 수 있지만 고객 팀은 IAM 역할에 대해 여러 개의 수동 RFCs를 생성하여 AMS에서 수동으로 검토하는 최소 허용 권한 세트를 반복해야 합니다. DCM을 사용하면 AMS 관리형 RFCs 대한 수동 RFC를 여러 개 생성할 필요 없이 AWS에서 운영 목표를 달성하여 AMS에서 수동으로 검토하는 최소 허용 권한 세트를 반복할 수 있습니다. AMS 프로세스와 도구를 늘리려면 고객 측 교육뿐만 아니라 시간이 걸립니다. 개발자 모드에서 고객은 "개발자 역할"로 시작하여 네이티브 AWS APIs. 이 파이프라인을 설정하는 가장 빠르고 유연한 방법은 AMS Managed-Developer 모드를 사용하는 것입니다. 개발자 모드는 운영 통합을 손상시키면서 가장 빠르고 쉬운 방법을 제공하는 반면, DCM은 덜 유연하지만 RFC 모드와 동일한 수준의 운영 지원을 제공합니다.
사용 사례 4, AMS 기반 내의 맞춤형 운영 모델: 고객이 기한 기반 데이터 센터 종료를 보고 있으며, 애플리케이션 운영 및 인프라 운영을 포함한 타사 MSP가 엔터프라이즈 애플리케이션 중 하나를 완전히 관리합니다. AMS에서 운영할 수 있도록 고객이 일정에이 애플리케이션을 리팩터링할 시간이 없다고 가정하면 고객 관리형 모드가 적절한 옵션입니다. 고객은 AMS 관리형 랜딩 존의 자동 및 빠른 설정을 활용할 수 있습니다. 중앙 집중식 네트워킹 계정을 통해 계정 벤딩 및 연결을 제어하는 중앙 집중식 계정 관리를 활용할 수 있습니다. 또한 AMS Payer 계정을 통해 모든 고객 관리형 계정에 대한 요금을 통합하여 결제를 간소화합니다. 고객은 AMS 관리형 계정에 사용되는 표준 액세스 관리와 별도로 MSP를 사용하여 맞춤형 액세스 관리 모델을 유연하게 설정할 수 있습니다. 이렇게 하면 고객 관리형 모드를 사용하여 온프레미스 환경을 비우는 비즈니스 요구 사항을 충족하면서 AMS 관리형 환경을 설정할 수 있습니다. 이 경우 고객이 클라우드로 마이그레이션하는 Windows 기반 애플리케이션도 보유하고 있고 이를 고객 관리형 계정으로 이동하기로 선택한 경우 고객은 클라우드 운영 모델을 생성할 책임이 있습니다. 이는 기존 IT 프로세스를 혁신하고 인력을 교육하는 고객의 능력에 따라 복잡하고 비용이 많이 들고 시간이 많이 걸릴 수 있습니다. 고객은 이러한 워크로드를 AMS 관리형 계정으로 "리프트 앤 시프트"하여 시간과 비용을 절약하고 인프라 작업을 AMS로 오프로드할 수 있습니다.
참고
고객은 RFC 또는 SSP 모드의 거버넌스 프레임워크와 개발자 모드 간에 애플리케이션 계정을 이동해야 할 때가 있습니다. 예를 들어 고객은 초기 리프트 앤 시프트 마이그레이션의 일부로 AMS 관리형 모드에서 애플리케이션을 호스팅할 수 있지만, 초과 근무 시 애플리케이션을 다시 작성하여 클라우드 네이티브 AWS 서비스에 최적화하려고 합니다. 사전 프로덕션 계정의 모드를 AMS 관리형 RFC에서 AMS 관리형 개발자 모드로 변경하여 인프라를 프로비저닝할 수 있는 유연성과 민첩성을 제공할 수 있습니다. 그러나 "개발자 역할"을 사용하여 인프라 프로비저닝을 변경한 후에는 동일한 인프라를 AMS 관리형 RFC 모드로 다시 이동할 수 없습니다. 이는 AMS가 AMS 변경 관리 시스템 외부에서 프로비저닝된 인프라의 운영을 보장할 수 없기 때문입니다. 고객은 AMS 관리형 RFC 모드를 제공하는 새 애플리케이션 계정을 생성한 다음 AMS 관리형 계정으로 수집된 CloudFormation 템플릿 또는 사용자 지정 AMIs를 통해 "최적화된" 인프라 구성을 다시 배포해야 할 수 있습니다. 이는 프로덕션 준비 구성을 배포하는 깔끔한 방법입니다. 배포되면 애플리케이션은 규범적 AMS 거버넌스 및 운영의 적용을 받습니다. 고객 관리형 모드와 AMS 관리형 모드 간 전환 모드에도 동일하게 적용됩니다.