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

# AMS 모드 및 애플리케이션 또는 워크로드
<a name="ams-modes-and-apps-og"></a>

새 애플리케이션 계정을 요청하거나 기존 애플리케이션 계정에서 애플리케이션을 호스팅하여 올바른 모드를 선택할 때 애플리케이션의 운영 및 거버넌스 요구 사항을 고려합니다. 각 애플리케이션 또는 워크로드에 적합한 AMS 모드 선택은 다음 요인에 따라 달라집니다.
+ 환경에서 제공할 SDLC 수명 주기 함수의 유형(예: 조정되지 않은 변경 사항이 있는 샌드박스, 자주 변경되는 UAT, 최소한의 변경 사항이 있고 규제가 엄격한 프로덕션)
+ 필요한 거버넌스 정책(OU 수준에서 SCPs를 통해 적용됨)
+ 운영 모델(운영 책임을 소유하거나 AMS에 아웃소싱하려는 경우)
+ 클라우드 운영 시간, 운영 비용 등 원하는 비즈니스 성과입니다.

**참고**  
AMS 서비스당 모드 유형에 대한 설명은 [AMS의 모드 및 계정 유형을 참조하세요](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-modes-types.html).  
다양한 모드의 실제 사용 사례는 [AMS 모드의 실제 사용 사례를 참조하세요.](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-modes-and-use-cases.html)

다음 표에는 애플리케이션 소유자가 가장 적합한 AMS 모드를 결정하는 데 도움이 되는 주요 고려 사항이 요약되어 있습니다. 애플리케이션 소유자는 특정 애플리케이션에 적용되는 모드를 완전히 이해하려면 애플리케이션 마이그레이션 전에 평가 단계를 포함해야 합니다. 예: 클라우드 네이티브 서비스 또는 서버리스 아키텍처를 기반으로 하는 애플리케이션의 경우 가장 좋은 옵션은 개발자 모드에서 빌드 및 반복을 시작하고 AMS 관리형 - SSP 모드를 사용하여 최종 코드형 인프라를 배포하는 것입니다. 이 경우 자동 배포를 위해 생성된 CloudFormation 템플릿이 AMS에서 제시한 수집 지침을 충족하는지 확인하기 위해 라이트 리팩터링이 필요할 수 있습니다. 또한 모든 IAM 권한은 최소 권한 모델을 따르도록 AMS Security의 승인을 받아야 합니다.

애플리케이션을 호스팅하도록 선택한 AMS 모드를 사용하면 원하는 클라우드 운영 모델을 구축할 수 있습니다.

**참고**  
애플리케이션을 호스팅하기 위해 선택한 다양한 AMS 모드를 기반으로 단일 AMS 관리형 랜딩 존에 둘 이상의 클라우드 운영 모델이 존재할 수 있습니다.


<table>
<thead>
  <tr><th>결정 문제</th><th>표준 CM 모드/OOD\*</th><th>AWS Service Catalog</th><th>직접 변경 모드</th><th>셀프 서비스 프로비저닝</th><th>개발자 모드</th><th>고객 관리형</th></tr>
</thead>
<tbody>
  <tr><td colspan="7">운영 준비 상태</td></tr>
  <tr><td>로깅, 모니터링 및 이벤트 관리</td><td colspan="3">모든 관리형 인프라를 담당하는 AMS</td><td>셀프 서비스 프로비저닝 서비스(SSP)를 담당하는 고객</td><td>AMS CM 시스템 외부에서 개발자 IAM 역할을 사용하여 프로비저닝된 리소스를 담당하는 고객</td><td rowspan="8">고객 책임</td></tr>
  <tr><td>연속성 관리</td><td colspan="3">고객이 선택한 백업 계획을 실행할 AMS 책임</td><td>셀프 서비스 프로비저닝 서비스(SSP)를 담당하는 고객</td><td>AMS CM 시스템 외부에서 개발자 IAM 역할을 사용하여 프로비저닝된 리소스를 담당하는 고객</td></tr>
  <tr><td>인스턴스 수준 액세스 관리</td><td colspan="3">온프레미스 도메인과의 단방향 AD 신뢰를 통해 AMS 관리됩니다. 관리형 인프라가 AMS 도메인에 조인해야 함</td><td>해당 사항 없음</td><td>AMS CM 시스템 외부에서 개발자 IAM 역할을 사용하여 프로비저닝된 리소스를 담당하는 고객</td></tr>
  <tr><td>보안 관리 및 계정 수준 액세스 관리</td><td colspan="3">모든 관리형 계정에 대한 AMS 책임</td><td>모든 관리형 계정을 담당하는 AMS</td><td>AMS CM 시스템 외부에서 개발자 IAM 역할을 사용하여 프로비저닝된 리소스를 담당하는 고객</td></tr>
  <tr><td>패치 관리</td><td colspan="3">모든 관리형 계정에 대한 AMS 책임</td><td>셀프 서비스 프로비저닝 서비스(SSP)를 담당하는 고객</td><td>AMS CM 시스템 외부에서 개발자 IAM 역할을 사용하여 프로비저닝된 리소스를 담당하는 고객</td></tr>
  <tr><td>변경 관리</td><td colspan="3">모든 관리형 계정에 대한 AMS 책임</td><td>셀프 서비스 프로비저닝 서비스(SSP)를 담당하는 고객</td><td>AMS CM 시스템 외부에서 개발자 IAM 역할을 사용하여 프로비저닝된 리소스를 담당하는 고객</td></tr>
  <tr><td>프로비저닝 관리</td><td>AMS에서 제공되는 프로비저닝 옵션에 대한 권장 및 표준화</td><td>AMS 규범적 표준에 따라 AWS Service Catalog용 AWS 서비스 API를 직접 사용할 수 있는 유연성</td><td>AMS 규범적 표준에 따라 AWS 서비스 API를 직접 사용할 수 있는 유연성</td><td>SSP 서비스에 AWS 서비스 APIs를 직접 사용할 수 있는 유연성</td><td>프로비저닝에 AWS 서비스 API를 직접 사용할 수 있는 유연성</td></tr>
  <tr><td>인시던트 관리 및 감사</td><td colspan="4">모든 관리형 계정에 대한 AMS 책임</td><td>AMS Change Management System 외부에서 개발자 IAM 역할을 사용하여 프로비저닝된 리소스를 담당하는 고객</td></tr>
  <tr><td>GuardRails 및 공유 인프라(네트워크) 및 보안 프레임워크</td><td colspan="5">AMS Core 계정의 권장 및 표준화 활용</td><td>유연한 맞춤형 AMS Core 계정 활용</td></tr>
  <tr><td colspan="7">애플리케이션 준비 상태</td></tr>
  <tr><td>애플리케이션 리팩터링</td><td colspan="4">라이트 리팩터링 필요</td><td>라이트 리팩터링 필요(AMS Standard CM을 사용하여 프로비저닝된 경우)</td><td>리팩터링 필요 없음</td></tr>
  <tr><td>AWS 서비스 지원</td><td colspan="5">AMS에서 지원하는 것으로 제한됨</td><td>제한되지 않음</td></tr>
  <tr><td colspan="7">비즈니스 고려 사항</td></tr>
  <tr><td>운영 준비 시간</td><td colspan="3">3\~6개월</td><td colspan="2">6개월 \+ 고객 애플리케이션 운영 역량에 따라 다름</td><td>고객 인프라 및 애플리케이션 운영 역량에 따라 6\~18개월</td></tr>
  <tr><td>비용</td><td colspan="3">$$$$</td><td>$$$</td><td>$$</td><td>$</td></tr>
  <tr><td>애플리케이션 예제</td><td colspan="3">3 티어 스택이 있는 Webserver, 규정 준수 및 규제 요구 사항이 있는 앱</td><td>API Gateway를 사용하는 Webserver, ECS/EKS를 활용하는 컨테이너화된 애플리케이션</td><td>Lambda, Glue, Athena 등을 사용하는 Data Lake 애플리케이션에서 반복/최적화</td><td>샌드박스, 타사 관리형 애플리케이션과 같은 분산형 계정/애플리케이션</td></tr>
</tbody>
</table>


**\***OOD(Operations On Demand)에는 표준 CM 모드를 사용하는 고객이 전용 리소싱을 통해 변경 사항을 관리할 수 있는 기능이 있습니다. 자세한 내용은 [ 오퍼링의 온디맨드 운영 카탈로그를](https://docs.aws.amazon.com/managedservices/latest/userguide/ood-catalog.html) 참조하고 클라우드 서비스 제공 관리자(CSDM)에게 문의하세요.

**참고**  
SSP 모드와 개발자 모드 간의 가격 비교는 동일한 AWS 서비스가 프로비저닝된다고 가정합니다.

AMS 모드와 비즈니스 및 IT 목표 비교

![](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/ams-modes-choosing-dcm.png)


그림과 같이 애플리케이션에 대해 고도로 제어되고 표준화된 거버넌스 모델을 찾고 있다면 AMS 관리형 표준 변경, AWS Service Catalog 또는 직접 변경 모드가 가장 적합합니다. 운영 준비 없이 애플리케이션 혁신에 중점을 둔 맞춤형 거버넌스 모델이 필요한 경우 고객 관리형 모드를 선택합니다. 고객 관리형 모드를 사용하면 인시던트 관리, 구성 관리, 프로비저닝 관리, 보안 관리, 패치 관리 등과 같은 운영 기능을 지원하는 인력, 프로세스 및 도구를 구축할 책임이 있으므로 애플리케이션을 운영하는 데 시간이 더 오래 걸릴 수 있습니다.