기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # RFC 모드 RFC 모드는 AMS Advanced 운영 계획 고객의 기본 모드입니다. 여기에는 변경 또는 RFCs에 대한 요청이 있는 변경 관리 시스템과 계정에 필요한 추가 또는 변경을 요청하는 데 사용할 변경 유형 카탈로그가 포함됩니다. 이 변경 관리 시스템은 계정을 변경할 수 있는 사용자를 제한하는 데 있어 보안 수준을 제공합니다. AMS 고급 변경 유형에 대한 자세한 내용은 [AMS 변경 유형이란 무엇입니까?를 참조하세요](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html). AMS Advanced 온보딩에 대한 자세한 내용은 [AWS Managed Services 온보딩 소개를 참조하세요](https://docs.aws.amazon.com/managedservices/latest/onboardingguide/index.html). 변경 유형 예제 연습은 *AMS 고급 변경 유형 참조 분류별 변경 유형* [섹션의 관련 변경 유형에 대한 "추가 정보" 섹션을 참조하세요](https://docs.aws.amazon.com/managedservices/latest/ctref/classifications.html). **참고** RFC 모드는 이전에 "변경 관리 모드" 또는 "표준 CM 모드"라고 불렸습니다. **Topics** + [RFCs 대해 알아보기](ex-rfc-works.md) + [변경 유형이란 무엇입니까?](understanding-cts.md) + [AMS의 RFC 오류 문제 해결](rfc-troubleshoot.md) # RFCs 대해 알아보기 변경 요청 또는 RFCs는 두 가지 방식으로 작동합니다. 먼저 RFC 자체에 필요한 파라미터가 있습니다. API의 옵션은 다음과 같습니다`CreateRfc`. 둘째, RFC의 작업에 필요한 파라미터(실행 파라미터)가 있습니다. `CreateRfc` 옵션에 대한 자세한 내용은 AMS API 참조의 [CreateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html) 섹션을 참조하세요. ** 이러한 옵션은 일반적으로 RFC 생성 페이지의 **추가 구성** 영역에 나타납니다. `CreateRfc` API, `aws amscm create-rfc` CLI 또는 AMS 콘솔 RFC 생성 페이지를 사용하여 RFC를 생성하고 제출할 수 있습니다. RFC 생성에 대한 자습서는 섹션을 참조하세요[RFC 생성](ex-rfc-create-col.md). **Topics** + [RFC란 무엇인가요?](what-r-rfcs.md) + [AMS API/CLI 사용 시 인증](ex-rfc-authentication.md) + [RFC 보안 검토 이해](rfc-security.md) + [RFC 변경 유형 분류 이해](ex-rfc-csio.md) + [RFC 작업 및 활동 상태 이해](ex-rfc-action-state.md) + [RFC 상태 코드 이해](ex-rfc-status-codes.md) + [RFC 업데이트 CTs 및 CloudFormation 템플릿 드리프트 감지 이해](ex-rfc-updates-and-dd.md) + [RFCs 예약](ex-rfc-scheduling.md) + [RFCs 승인 또는 거부](ex-rfc-approvals.md) + [RFC 제한 실행 기간 요청](ex-rfc-restrict-execute.md) + [RFCs 생성, 복제, 업데이트, 찾기 및 취소](ex-rfc-use-examples.md) + [RFCs와 함께 AMS 콘솔 사용](ex-rfc-gui.md) + [일반적인 RFC 파라미터에 대해 알아보기](rfc-common-params.md) + [RFC 일일 이메일에 가입](rfc-digest.md) # RFC란 무엇인가요? 변경 요청 또는 RFC는 AMS 관리형 환경을 변경하거나 AMS에 사용자를 대신하여 변경하도록 요청하는 방법입니다. RFC를 생성하려면 AMS 변경 유형 중에서 선택하고 RFC 파라미터(예: 일정)를 선택한 다음 AMS 콘솔 또는 API 명령 [CreateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html) 및 [SubmitRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_SubmitRfc.html)를 사용하여 요청을 제출합니다. RFC에는 두 가지 사양이 있습니다. 하나는 RFC 자체용이고 다른 하나는 변경 유형(CT) 파라미터용입니다. 명령줄에서 인라인 RFC 명령 또는 JSON 형식의 표준 CreateRfc 템플릿을 사용하여 생성한 CT JSON 스키마 파일(CT 파라미터 기반)과 함께 작성하고 제출할 수 있습니다. CT 이름은 CT에 대한 비공식 설명입니다. CSIO(범주, 하위 범주, 항목, 작업)는 CT에 대한 보다 공식적인 설명입니다. RFC를 생성할 때 CT ID만 지정해야 합니다. RFCs 검증과 실행이라는 두 가지 주요 단계를 거칩니다. 1. 검증 단계에서 AMS는 RFC 요청의 완전성과 정확성을 검토합니다. 또한 AMS는 보안 [기술 표준에 따라 보안](rfc-security.md#rfc-security.title) 요청을 평가합니다. AMS는 요청된 변경이 유효하고 실행 가능한지 확인합니다. 1. 실행 단계에서 AMS는 계정에서 요청된 변경 사항을 시도합니다. AMS는 자동화된 프로세스, 수동 프로세스 또는 두 프로세스의 조합을 통해 두 단계를 모두 처리합니다. 수동 프로세스는 AMS 운영 팀에서 처리합니다. 자세한 내용은 [자동 및 수동 CTs](ug-automated-or-manual.md) 단원을 참조하십시오. AMS는 요청을 처리하기 위한 세 가지 실행 모드를 제공합니다. + **(AMS 권장) 실행 모드: 자동**. 이러한 CTs는 비즈니스 성과를 달성하는 가장 빠른 방법인 RFC 검증 및 실행에 자동화를 사용합니다. + **(AMS 권장) 실행 모드: 수동 및 지정: 관리형 자동화**. 이러한 CTs RFC 검증 및 실행을 위해 자동화된 프로세스와 수동 프로세스의 조합을 활용합니다. 자동화가 요청된 변경을 실행할 수 없는 경우 RFC는 수동 처리를 위해 (자동 라우팅 또는 대체 RFC를 생성하여) AMS 운영 팀에 전송됩니다. 이러한 CTs를 제출하면 AMS 자동화로 보완된 요청을 보다 구조화하여 처리 및 실행 결과 기간을 개선할 수 있습니다. + **실행 모드: 수동 및 지정: 검토 필요**. [ct-1e1xtak34nx76 관리 \$1 기타 \$1 기타 \$1 업데이트(검토 필요)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-other-other-update-review-required.html) 또는 [ct-0xdawir96cy7k 관리 \$1 기타 \$1 기타 \$1 생성(검토 필요)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-other-other-create-review-required.html)을 통해 요청된 변경 사항. 이러한 CTs 검증 및 실행을 위한 수동 처리에 의존합니다. 이러한 CTs는 변경 요청의 수동 해석에 따라 달라집니다. AMS는 변경이 성공적으로 완료되거나(성공) 실패하면(실패) 알려줍니다. **참고** RFC 실패 문제 해결에 대한 자세한 내용은 섹션을 참조하세요[AMS의 RFC 오류 문제 해결](rfc-troubleshoot.md). 다음 그림은 사용자가 제출한 RFC의 워크플로를 보여줍니다. ![\[고객이 제출한 RFC의 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/requestForChange-v5g.png) # AMS API/CLI 사용 시 인증 AMS API/CLI를 사용하는 경우 임시 자격 증명으로 인증해야 합니다. 페더레이션 사용자를 위한 임시 보안 자격 증명을 요청하려면 [ GetFederationToken](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html), [AssumeRole](https://docs.aws.amazon.com/STS/latest/UsingSTS/sts_delegate.html), [AssumeRoleWithSAML](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithsaml) 또는 [ AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity) AWS 보안 토큰 서비스(STS) APIs. 일반적인 선택은 SAML입니다. 설정 후 호출하는 각 작업에 인수를 추가합니다. 예를 들어 `aws --profile saml amscm list-change-type-categories`입니다. SAML 2.0 프로파일의 바로 가기는를 사용하여 각 API/CLI 시작 시 프로파일 변수를 설정하는 것입니다`set AWS_DEFAULT_PROFILE=saml`(Windows의 경우 , Linux의 경우 `export AWS_DEFAULT_PROFILE=saml`). CLI 환경 변수 설정에 대한 자세한 내용은 [ AWS 명령줄 인터페이스 구성, 환경 변수를 참조하세요](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-environment). # RFC 보안 검토 이해 AWS Managed Services(AMS) 변경 관리 승인 프로세스를 통해 계정의 변경 사항에 대한 보안 검토를 수행할 수 있습니다. AMS는 AMS 기술 표준을 기준으로 모든 변경 요청(RFCs 평가합니다. 기술 표준을 벗어나 계정의 보안 태세를 저하시킬 수 있는 모든 변경 사항은 보안 검토를 거칩니다. 보안 검토 중에 AMS는 관련 위험을 강조 표시하고, 보안 위험이 높거나 매우 높은 경우 승인된 보안 담당자가 RFC를 수락하거나 거부합니다. 또한 모든 변경 사항을 평가하여 AMS의 운영 능력에 부정적인 영향을 미치는지 평가합니다. 잠재적인 부정적인 영향이 발견되면 AMS 내에서 추가 검토 및 승인이 필요합니다. ## AMS 기술 표준 AMS 기술 표준은 최소 보안 기준, 구성 및 프로세스를 정의하여 계정의 기본 보안을 설정합니다. AMS와 사용자 모두 이러한 표준을 따라야 합니다. 기술 표준을 벗어나 계정의 보안 태세를 잠재적으로 저하시킬 수 있는 모든 변경 사항은 위험 수락 프로세스를 거칩니다.이 프로세스에서는 AMS에서 관련 위험을 강조 표시하고 권한 있는 보안 담당자가 사용자 측에서 수락하거나 거부합니다. 또한 이러한 모든 변경 사항을 평가하여 AMS의 계정 운영 능력에 부정적인 영향을 미칠지 여부를 평가하고, 영향을 미칠 경우 AMS 내에서 추가 검토 및 승인이 필요한지 여부를 평가합니다. ## RFC 고객 보안 위험 관리(CSRM) 프로세스 조직의 누군가가 관리형 환경에 대한 변경을 요청하면 AMS는 변경 사항을 검토하여 해당 요청이 기술 표준을 벗어나 계정의 보안 태세를 저하시킬 수 있는지 확인합니다. 요청이 계정의 보안 태세를 저하시키는 경우 AMS는 보안 팀에 관련 위험을 알리고 변경을 실행합니다. 또는 변경으로 인해 환경에서 보안 위험이 높거나 매우 높은 경우 AMS는 위험 수락(다음 설명됨)의 형태로 보안 팀 연락처로부터 명시적 승인을 구합니다. AMS 고객 위험 수락 프로세스는 다음을 위해 설계되었습니다. + 위험을 명확하게 식별하고 올바른 소유자에게 알립니다. + 환경에 대해 식별된 위험 최소화 + 조직의 위험 프로필을 이해하는 지정된 보안 담당자로부터 승인을 받고 문서화합니다. + 식별된 위험에 대한 지속적인 운영 오버헤드 감소 ## 기술 표준 및 높거나 매우 높은 위험에 액세스하는 방법 [https://console.aws.amazon.com/artifact/](https://console.aws.amazon.com/artifact/) AMS 기술 표준 설명서를 보고서로 참조할 수 있도록 했습니다. AMS 기술 표준 설명서를 사용하여 변경 요청(RFC)을 제출하기 전에 승인된 보안 담당자의 위험 수락이 변경에 필요한지 여부를 파악합니다. 기본 **AWSManagedServicesChangeManagementRole**로 로그인한 후 **보고서** 탭 검색 창에서 "AWS Managed Services(AMS) 기술 표준" AWS Artifact 을 검색하여 기술 표준 보고서를 찾습니다. **참고** AMS 기술 표준 문서는 단일 계정 랜딩 존의 Customer\$1ReadOnly\$1Role에 액세스할 수 있습니다. 다중 계정 랜딩 존에서는 보안 관리자가 사용하는 AWSManagedServicesAdminRole과 애플리케이션 팀이 사용하는 AWSManagedServicesChangeManagementRole을 사용하여 문서에 액세스할 수 있습니다. 팀에서 사용자 지정 역할을 사용하는 경우 기타 \$1 기타 RFC를 생성하여 액세스를 요청하면 지정된 사용자 지정 역할이 업데이트됩니다. # RFC 변경 유형 분류 이해 RFC를 제출할 때 사용하는 변경 유형은 두 가지 광범위한 범주로 나뉩니다. + **배포**:이 분류는 리소스를 생성하기 위한 것입니다. + **관리**:이 분류는 리소스를 업데이트하거나 삭제하기 위한 것입니다. **관리** 범주에는 인스턴스 액세스, AMIs 암호화 또는 공유, 스택 시작, 중지, 재부팅 또는 삭제를 위한 변경 유형도 포함됩니다. # RFC 작업 및 활동 상태 이해 `RfcActionState` (API) / **활동 상태**(콘솔)는 RFC에서 사람의 개입 또는 작업 상태를 이해하는 데 도움이 됩니다. 주로 수동 RFCs에 사용되는 `RfcActionState`는 사용자 또는 AMS 작업에 필요한 작업이 있는 시기를 이해하고 AMS 작업이 RFC에서 활발하게 작업하는 시기를 확인하는 데 도움이 됩니다. 이렇게 하면 수명 주기 동안 RFC에서 수행되는 작업에 대한 투명성이 향상됩니다. `RfcActionState` (API) / **활동 상태**(콘솔) 정의: + **AwsOperatorAssigned**: AWS 운영자가 RFC에서 적극적으로 작업하고 있습니다. + **AwsActionPending**: AWS의 응답 또는 작업이 예상됩니다. + **CustomerActionPending**: 고객의 응답 또는 조치가 필요합니다. + **NoActionPending**: AWS 또는 고객의 조치가 필요하지 않습니다. + **NotApplicable**:이 상태는 AWS 운영자 또는 고객이 설정할 수 없으며이 기능이 릴리스되기 전에 생성된 RFCs에만 사용됩니다. RFC 작업 상태는 제출된 변경 유형에 수동 검토가 필요한지 여부와 일정이 **ASAP**로 설정되어 있는지 여부에 따라 달라집니다. + 지연된 일정으로 수동 변경 유형을 검토, 승인 및 시작하는 동안 RFC **ActionState**가 변경됩니다. + 예약된 수동 RFC를 제출하면 **ActionState**가 자동으로 **AwsActionPending**으로 변경되어 운영자가 RFC를 검토하고 승인해야 함을 나타냅니다. + 운영자가 RFC를 적극적으로 검토하기 시작하면 **ActionState**가 **AwsOperatorAssigned**로 변경됩니다. + 운영자가 RFC를 승인하면 RFC 상태가 예약됨으로 변경되고 **ActionState**가 자동으로 **NoActionPending**으로 변경됩니다. + RFC의 예약된 시작 시간에 도달하면 RFC 상태가 **InProgress**으로 변경되고 **ActionState**가 자동으로 **AwsActionPending**으로 변경되어 RFC 검토를 위해 연산자를 할당해야 함을 나타냅니다. + 운영자가 RFC를 적극적으로 실행하기 시작하면 **ActionState**를 **AwsOperatorAssigned**로 변경합니다. + 완료되면 연산자가 RFC를 닫습니다. 그러면 **ActionState**가 **NoActionPending**으로 자동 변경됩니다. ![\[예약이 연기된 수동 변경 유형의 검토, 승인 및 시작 중 RFC ActionState 변경 사항\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/actionStateRfc.png) **중요** 작업 상태는 사용자가 설정할 수 없습니다. RFC의 변경 사항에 따라 자동으로 설정되거나 AMS 연산자가 수동으로 설정합니다. RFC에 서신을 추가하면 **ActionState**가 자동으로 **AwsActionPending**으로 설정됩니다. RFC가 생성되면 **ActionState**가 **NoActionPending**으로 자동 설정됩니다. RFC가 제출되면 **ActionState**는 자동으로 **AwsActionPending**으로 설정됩니다. RFC가 거부됨, 취소됨 또는 성공 또는 실패 상태로 완료되면 **ActionState**가 **NoActionPending**으로 자동 재설정됩니다. 작업 상태는 자동 RFCs 모두에서 활성화되지만 수동 RFCs의 경우 대부분 통신이 필요한 RFCs 경우가 많습니다. # RFC 작업 상태 사용 사례 검토 **사용 사례: 수동 RFC 프로세스에 대한 가시성** + 수동 RFC를 제출하면 운영자가 RFC를 검토하고 승인해야 함을 나타내`AwsActionPending`기 위해 RFC 작업 상태가 로 자동 변경됩니다. 운영자가 RFC를 적극적으로 검토하기 시작하면 RFC 작업 상태가 로 변경됩니다`AwsOperatorAssigned`. + 승인 및 예약되었으며 실행을 시작할 준비가 된 수동 RFC를 생각해 보십시오. RFC 상태가 로 변경되면 `InProgress`RFC 작업 상태가 자동으로 로 변경됩니다`AwsActionPending`. 운영자가 RFC를 적극적으로 실행하기 시작`AwsOperatorAssigned`하면 다시 로 변경됩니다. + 수동 RFC가 완료되면("성공" 또는 "실패"로 닫힘) RFC 작업 상태가 로 변경`NoActionPending`되어 고객 또는 운영자의 추가 작업이 필요하지 않음을 나타냅니다. **사용 사례: RFC 대응** + 수동 RFC가 인 경우 AMS 운영자`Pending Approval`가 추가 정보를 필요로 할 수 있습니다. 연산자는 RFC에 서신을 게시하고 RFC 작업 상태를 로 변경합니다`CustomerActionPending`. 새 RFC 대응 서신을 추가하여 응답하면 RFC 작업 상태가 자동으로 로 변경됩니다`AwsActionPending`. + 자동 또는 수동 RFC가 실패하면 RFC 세부 정보에 서신을 추가하여 AMS 운영자에게 RFC가 실패한 이유를 물어볼 수 있습니다. 서신이 추가되면 RFC 작업 상태가 자동으로 로 설정됩니다`AwsActionPending`. AMS 운영자가 서신을 보기 위해 RFC를 선택하면 RFC 작업 상태가 로 변경됩니다`AwsOperatorAssigned`. 연산자가 새 RFC 대응 서신을 추가하여 응답하면 RFC 작업 상태가 고객으로부터 다른 응답이 있음을 `CustomerActionPending`나타내는 로 설정되거나 고객의 응답이 필요하지 않음을 `NoActionPending`나타내는 로 설정될 수 있습니다. # RFC 상태 코드 이해 RFC 상태 코드는 요청을 추적하는 데 도움이 됩니다. CLI 출력에서 RFC를 실행하는 동안 또는 콘솔에서 RFC 목록 페이지를 새로 고쳐 이러한 상태 코드를 관찰할 수 있습니다. 해당 RFC의 세부 정보 페이지에서 다음과 같은 RFC의 코드를 볼 수도 있습니다. ![\[RFC 상태 코드.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/guiRfcStatusCodes.png) 목록에 제출하지 않은 RFC가 표시될 수 있습니다. AMS 연산자가 내부 전용 CT를 사용하는 경우 RFC에 제출하고 RFC 목록에 표시됩니다. 자세한 내용은 [내부 전용 변경 유형](ct-internals.md) 단원을 참조하십시오. **중요** RFC 상태 변경에 대한 알림을 요청할 수 있습니다. 자세한 내용은 [RFC 상태 변경 알림을 참조하세요](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-state-change-notices.html). **RFC 상태 코드** | Success | 실패 | | --- | --- | | 편집: RFC가 생성되었지만 제출되지 않음 PendingApproval / Submitted: RFC가 제출되었으며 시스템에서 승인이 필요한지 여부를 결정하고 필요한 경우 해당 승인을 얻고 있습니다. AWS에서 승인/고객이 승인: RFC가 승인되었습니다. 자동 RFCs는 AWS의 승인을 받고 수동 RFCs는 운영자 및 경우에 따라 고객의 승인을 받습니다. 예약됨: RFC가 구문 및 요구 사항 검사를 통과했으며 실행이 예약됨 InProgress: RFC가 실행 중입니다. 여러 리소스를 프로비저닝하거나 오래 실행되는 UserData가 있는 RFCs는 실행하는 데 시간이 더 오래 걸립니다. 실행됨: RFC가 실행되었습니다. 성공/성공: RFC가 성공적으로 완료되었습니다. | 거부됨: RFCs는 일반적으로 검증에 실패하기 때문에 거부됩니다. 예를 들어 사용할 수 없는 리소스, 즉 서브넷이 지정됩니다. 취소됨: RFCs는 일반적으로 구성된 시작 시간이 경과하기 전에 검증을 통과하지 못하기 때문에 취소됩니다. 실패: RFC가 실패했습니다. 실패 이유는 출력의 StatusReason을 참조하세요. AMS 작업은 자동으로 문제 티켓을 생성하고 필요에 따라 사용자와 통신합니다. | **참고** 취소되거나 거부된 RFCs는 [UpdateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_UpdateRfc.html)를 사용하여 다시 제출할 수 있습니다. 단원을 참조하십시오[RFCs 업데이트](ex-update-rfcs.md). RFC가 필요한 모든 조건을 통과하면(예: 필요한 모든 파라미터가 지정됨) 상태가 로 변경됩니다`PendingApproval`(자동 CTs도 승인이 필요하며 구문 및 파라미터 검사가 통과하면 자동으로 발생함). 전달되지 않으면 상태가 로 변경됩니다`Rejected`. 는 거부에 대한 정보를 `StatusReason` 제공하고, `ExecutionOutput` 필드는 승인 및 완료에 대한 정보를 제공합니다. 오류 코드는 다음과 같습니다. + InvalidRfcStateException: RFC가 호출된 작업을 허용하지 않는 상태입니다. 예를 들어 RFC가 제출됨 상태로 전환된 경우 더 이상 수정할 수 없습니다. + InvalidRfcScheduleException: StartTime, EndTime 또는 TimeoutInMinutes 파라미터가 위반되었습니다. + InternalServerError: 시스템에 문제가 발생했습니다. + InvalidArgumentException: 파라미터가 잘못 지정되었습니다. 예를 들어 허용할 수 없는 값이 사용됩니다. + ResourceNotFoundException: 스택 ID와 같은 값을 찾을 수 없습니다. 변경이 승인되기 전에 예약된 요청된 시작 및 종료 시간(변경 실행 기간이라고도 함)이 발생하면 RFC 상태가 로 변경됩니다`Canceled`. 변경이 승인되면 RFC 상태가 로 변경됩니다`Scheduled`. ASAP RFCs입니다. `ExpectedExecutionDuration` 변경 실행 기간이 도착하기 전에 언제든지 예약된 변경(CLI`RequestedStartTime`에서와 함께 제출됨)을 수정하거나 취소할 수 있습니다. 예약된 변경 사항이 수정된 경우 다시 제출해야 합니다. 변경 시작 시간이 도착하고(예약 또는 ASAP) 승인이 완료되면 상태가 로 변경`InProgress`되며 수정할 수 없습니다. 지정된 변경 실행 기간 내에 변경이 완료되면 상태가 로 변경됩니다`Success`. 변경의 일부가 실패하거나 변경 실행 기간이 종료될 때 변경 사항이 계속 진행 중인 경우 상태가 로 변경됩니다`Failure`. **참고** `InProgress`, `Success`또는 상태 `Failure` 변경 중에는 RFC를 수정하거나 취소할 수 없습니다. 다음 다이어그램은 CreateRFC 호출부터 해결까지의 RFC 상태를 보여줍니다. ![\[CreateRFC 호출부터 해결까지의 RFC 상태입니다.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/RfcStateFlow2.png) # RFC 업데이트 CTs 및 CloudFormation 템플릿 드리프트 감지 이해 AMS에 프로비저닝된 리소스는 수정된 CloudFormation 템플릿을 사용합니다. 리소스에 서비스의 AWS 관리 콘솔을 통해 직접 변경된 파라미터가 있는 경우 해당 리소스의 CloudFormation 생성 레코드가 동기화되지 않습니다. 이 경우 AMS 업데이트 변경 유형을 사용하여 AMS의 리소스를 업데이트하려고 하면 AMS는 원래 리소스 구성을 참조하고 잠재적으로 변경된 파라미터를 재설정합니다. 이 재설정은 손상될 수 있으므로 추가 AMS 구성 변경이 감지되면 AMS는 업데이트 변경 유형이 있는 RFCs를 허용하지 않습니다. 업데이트 변경 유형 목록은 콘솔 필터를 사용합니다. ## 드리프트 문제 해결 FAQs AMS 드리프트 수정에 대한 질문과 답변. 드리프트 문제 해결을 시작하는 데 사용할 수 있는 두 가지 변경 유형이 있습니다. 하나는 실행 모드=수동 또는 "관리형 자동화"이고 다른 하나는 실행 모드=자동입니다. ### 드리프트 수정 지원 리소스(ct-3kinq0u4l33zf) 다음은 드리프트 수정 변경 유형(ct-3kinq0u4l33zf)에서 지원하는 리소스입니다.   리소스를 수정하려면 대신 "관리형 자동화"(ct-34sxfo53yuzah) 변경 유형을 사용합니다. ``` AWS::EC2::Instance AWS::EC2::SecurityGroup AWS::EC2::VPC AWS::EC2::Subnet AWS::EC2::NetworkInterface AWS::EC2::EIP AWS::EC2::InternetGateway AWS::EC2::NatGateway AWS::EC2::NetworkAcl AWS::EC2::RouteTable AWS::EC2::Volume AWS::AutoScaling::AutoScalingGroup AWS::AutoScaling::LaunchConfiguration AWS::AutoScaling::LifecycleHook AWS::AutoScaling::ScalingPolicy AWS::AutoScaling::ScheduledAction AWS::ElasticLoadBalancing::LoadBalancer AWS::ElasticLoadBalancingV2::Listener AWS::ElasticLoadBalancingV2::ListenerRule AWS::ElasticLoadBalancingV2::LoadBalancer AWS::CloudWatch::Alarm ``` ### 드리프트 문제 해결 변경 유형 AMS 드리프트 문제 해결 변경 유형 사용에 대한 질문과 답변입니다. 드리프트 문제 해결 기능에 지원되는 리소스 목록은 섹션을 참조하세요[드리프트 수정 지원 리소스(ct-3kinq0u4l33zf)](#drift-remeditate-faqs-sr). **중요** 드리프트 수정은 스택 템플릿 및/또는 파라미터를 수정하며, 최신 스택 템플릿 및 파라미터를 사용하도록 로컬 템플릿 리포지토리 또는 이러한 스택을 업데이트하는 자동화를 업데이트해야 합니다. 동기화 없이 이전 템플릿 및/또는 파라미터를 사용하면 기본 리소스가 손상될 수 있습니다. 관리형 자동화가 없는 자동화된 CT(ct-3kinq0u4l33zf)는 RFC당 10개의 리소스만 수정할 수 있도록 지원합니다. 나머지 리소스를 10개 배치로 수정하려면 모든 리소스가 수정될 때까지 새 RFCs 생성합니다. 어떤 드리프트 문제 해결 변경 유형을 사용해야 합니까? 다음과 같은 경우 **비관리형 자동화**, 자동 CT(ct-3kinq0u4l33zf)를 사용하는 것이 좋습니다. + 자동 CT를 사용하여 기존 스택 리소스에 대한 업데이트를 수행하려고 하면 스택이 이므로 RFC가 거부됩니다`DRIFTED`. + 과거에 Update CT를 사용했는데 스택이 DRIFTED되어 실패했습니다. 업데이트를 다시 시도할 필요가 없으며 대신 관리형 자동화, 수동, CT를 사용할 수 있습니다. 드리프트 문제 해결 **관리형 자동화** 없음, 자동화, CT(ct-3kinq0u4l33zf)에서 드리프트된 리소스 유형을 지원하지 않거나 드리프트 문제 해결 관리형 자동화, 자동화, CT가 실패하지 않는 경우에만 관리형 자동화, 수동 CT(ct-34sxfo53yuzah)를 사용하는 것이 좋습니다. 문제 해결 중에 스택에 어떤 변경 사항이 적용되나요? 수정하려면 드리프트된 속성에 따라 스택 템플릿 및/또는 파라미터를 업데이트해야 합니다. 또한 문제 해결은 문제 해결 중에 스택의 스택 정책을 업데이트하고 문제 해결이 완료되면 스택 정책을 이전 값으로 복원합니다. 스택 템플릿 및/또는 파라미터에 대해 수행된 변경 사항을 보려면 어떻게 해야 합니까? RFC에 대한 응답으로 다음 정보와 함께 변경 요약이 제공됩니다. + `ChangeSummaryJson`: 드리프트 수정의 일부로 스택 템플릿 및/또는 파라미터의 변경 요약을 포함합니다. 문제 해결은 여러 단계로 수행됩니다. 이 변경 요약은 개별 단계의 변경 사항으로 구성됩니다. 문제 해결이 성공하면 마지막 단계의 변경 사항을 확인합니다. 순서대로 실행되는 단계는 JSON의 ExecutionPlan을 참조하세요. 예를 들어 있는 경우 RestoreReferences 섹션은 항상 끝에 실행되며 수정 후 변경 사항에 대한 JSON을 포함합니다. DryRun 모드에서 문제 해결을 실행하면 스택에 이러한 변경 사항이 적용되지 않습니다. + `PreRemediationStackTemplateAndConfigurationJson`: 스택에서 수정이 트리거되기 전에 템플릿, 파라미터, 출력, StackPolicyBody를 포함한 CloudFormation 스택의 구성 스냅샷을 포함합니다. 문제 해결이 수행되면 어떻게 해야 하나요? 수정 스택을 업데이트하는 로컬 템플릿 리포지토리 또는 자동화를 RFC 요약에 제공된 최신 템플릿 및 파라미터로 업데이트해야 합니다. 이전 템플릿 및/또는 파라미터를 사용하면 스택 리소스가 더 이상 파괴적으로 변경될 수 있으므로이 작업을 수행하는 것이 매우 중요합니다. 이 문제 해결 중에 내 애플리케이션이 영향을 받나요? 해결은 CloudFormation 스택 구성에서만 수행되는 오프라인 프로세스입니다. 기본 리소스에 대한 업데이트는 수행되지 않습니다. 문제 해결 후 관리 \$1 기타 \$1 기타 RFCs 계속 사용하여 리소스에 대한 업데이트를 수행할 수 있나요? 사용 가능한 자동 CT 업데이트를 사용하여 스택 리소스에 대한 업데이트를 항상 수행하는 것이 좋습니다 CTs. 사용 가능한 업데이트 CTs가 사용 사례를 지원하지 않는 경우 관리 \$1 기타 \$1 기타 요청을 사용합니다. 수정으로 스택에 새 리소스가 생성되나요? 수정은 스택에 새 리소스를 생성하지 않습니다. 그러나 수정은 새 출력을 생성하고 스택 템플릿 [메타데이터](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/metadata-section-structure.html) 섹션을 업데이트하여 참조용으로 수정 요약을 저장합니다. 문제 해결은 항상 성공하나요? 수정을 수행하려면 템플릿 구성을 신중하게 분석하고 검증해야 합니다. 이러한 검증이 실패하는 시나리오에서는 수정 프로세스가 중지되고 스택 템플릿 또는 파라미터에 대한 변경 사항이 수행되지 않습니다. 또한 지원되는 리소스 유형에 대해서만 문제 해결을 수행할 수 있습니다. 문제 해결에 실패하면 스택 리소스에 대한 업데이트를 수행하려면 어떻게 해야 합니까? 관리 \$1 기타 \$1 기타 \$1 CT 업데이트(ct-0xdawir96cy7k)를 사용하여 변경을 요청할 수 있습니다. AMS는 이러한 시나리오를 모니터링하고 문제 해결 솔루션을 개선하기 위해 노력합니다. 지원되는 리소스 유형과 지원되지 않는 리소스 유형이 모두 있는 스택을 수정할 수 있나요? 예. 그러나 수정은 지원되는 리소스 유형이 스택에서 DRIFTED로 발견된 경우에만 수행됩니다. 지원되지 않는 리소스 유형이 DRIFTED인 경우 수정이 계속되지 않습니다. 비CFN Ingest CTs를 통해 생성된 스택에 대한 문제 해결을 요청할 수 있나요? 예. 스택 생성에 사용되는 변경 유형에 관계없이 스택에서 수정을 수행할 수 있습니다. 수정 전에 스택에 대해 수행할 변경 사항을 알 수 있나요? 예. 두 변경 유형 모두 스택이 수정될 경우 수행할 변경을 요청하는 데 사용할 수 있는 **DryRun** 옵션을 제공합니다. 그러나 최종 수정 변경 사항은 수정 시 스택에 있는 드리프트에 따라 다를 수 있습니다. # RFCs 예약 **예약** 기능을 사용하면 RFCs. **예약** 기능에서 사용할 수 있는 옵션은 다음과 같습니다. + **이 변경 사항을 최대한 빨리 실행**: AMS는 RFC가 승인되는 즉시 실행합니다. 대부분의 CTs 자동으로 승인됩니다. RFC가 특정 시간에 시작되지 않도록 하려면이 옵션을 사용합니다. + **이 변경 예약**: RFC를 실행할 날짜, 시간 및 시간대를 설정합니다. 자동 변경 유형의 경우 RFC를 제출하려는 후 최소 10분 후에 시작 시간을 요청하는 것이 가장 좋습니다. 관리형 자동화 변경 유형의 경우 RFC를 제출하려는 후 최소 24시간이 지난 시작 시간을 요청해야 합니다. 구성된 시작 시간까지 RFC가 승인되지 않으면 RFC가 거부됩니다. ## RFC 일정 설정 RFC를 예약하려면 다음 방법 중 하나를 사용합니다. **이 변경 사항을 최대한 빨리 실행합니다**. + 콘솔: 아무 작업도 수행하지 않습니다. 기본 RFC 일정을 사용합니다. + API 또는 CLI: RFC 생성 작업에서 `RequestedStartTime` 및 `RequestedEndTime` 옵션을 제거합니다. **ASAP** "관리형 자동화" RFCs는 제출 후 30일 이내에 승인되지 않은 경우 자동 거부됩니다. 이 **변경을 예약합니다.** + 콘솔: **이 변경 예약** 라디오 버튼을 선택합니다. **시작 시간** 영역이 열립니다. 수동으로 날짜를 입력하거나 일정 위젯을 사용하여 날짜를 선택합니다. ISO 8601 형식으로 표현된 시간을 UTC로 입력하고 드롭다운 목록을 사용하여 위치를 선택합니다. 기본적으로 AMS는 ISO 8601 형식 YYYYMMDDThhmmssZ 또는 YYYY-MM-DDThh:mm:ssZ를 사용하며, 두 형식 중 하나가 허용됩니다. **참고** **기본 종료 시간은** 입력한 **시작 시간**으로부터 4시간입니다. 예약된 변경의 **종료 시간을** 4시간 이상으로 설정하려면 API 또는 CLI를 사용하여 변경 사항을 실행합니다. + API 또는 CLI: RFC 생성 작업에서 `RequestedStartTime` 및 `RequestedEndTime` 파라미터 값을 제출합니다. 구성된를 전달해도 이미 시작된 자동 변경 유형에 대한 실행이 중지되지 `RequestedEndTime` 않습니다. "관리형 자동화" 변경 유형의 경우 AMS 운영 조사가 진행 중인 동안 `RequestedEndTime`에 도달하고 AMS와 통신하는 경우 확장을 요청하거나 RFC를 다시 제출하라는 메시지가 표시될 수 있습니다. **작은 정보** UTC 시간 읽기의 예는 Time-is 웹 사이트의 [UTC](https://time.is/UTC)를 참조하세요. 오후 2:20에 2016-12-05의 날짜/시간 값에 대한 ISO 8601 형식의 예: **2016-12-05T14:20:00Z** 또는 **20161205T142000Z**. 제공하는 경우... + 만`RequestedStartTime`, RFC는 예약된 것으로 간주되며 `RequestedEndTime`는 `ExecutionDurationInMinutes` 값을 사용하여 채워집니다. + 만 `RequestedEndTime`해당됩니다. InvalidArgumentException이 발생합니다. + `RequestedStartTime` 및 모두 `RequestedEndTime` 지정된 시작 시간 \$1 `ExecutionDurationInMinutes` 값으로를 `RequestedEndTime`덮어씁니다. + `RequestedStartTime` 또는 도 아닙니다. 이러한 값은 null로 `RequestedEndTime`유지되며 RFC는 ASAP RFC로 처리됩니다. **참고** 예약된 모든 RFCs 대해 지정되지 않은 종료 시간은 지정된의 시간과 제출된 변경 유형의 `ExpectedExecutionDurationInMinutes` 속성을 `RequestedStartTime` 더한 시간으로 작성됩니다. 예를 들어 `ExpectedExecutionDurationInMinutes`가 "60"(분)이고 지정된 `RequestedStartTime`가 `2016-12-05T14:20:00Z` (2016년 12월 5일 오전 4시 20분)인 경우 실제 종료 시간은 2016년 12월 5일 오전 5시 20분으로 설정됩니다. 특정 변경 유형에 `ExpectedExecutionDurationInMinutes` 대한를 찾으려면 다음 명령을 실행합니다. ``` aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}" ``` ## RFC 우선 순위 옵션 사용 `execution mode = manual` 변경 유형에서 **우선 순위** 옵션을 사용하여 AMS 작업에 요청의 긴급성을 알립니다. 의 **우선** 순위 옵션`execution mode = manual`: 수동 RFC의 우선 순위를 **높**음, **중간** 또는 **낮음**으로 지정합니다. **높**음으로 분류된 RFCs는 RFCs 서비스 수준 목표(SLOs) 및 제출 시간에 따라 **중간**으로 분류된 RFC 이전에 검토 및 승인됩니다. 우선 순위가 **낮**거나 우선 순위가 지정되지 않은 RFCs는 제출된 순서대로 처리됩니다. # RFCs 승인 또는 거부 승인 필요(수동) CTs와 함께 제출된 RFCs는 사용자 또는 AMS의 승인을 받아야 합니다. 사전 승인된 CTs 자동으로 처리됩니다. 자세한 내용은 [CT 승인 요구 사항](constrained-unconstrained-ctis.md) 단원을 참조하십시오. **참고** 수동 CTs를 사용하는 경우 ASAP **예약** 옵션(콘솔에서 **ASAP** 선택, API/CLI에서 시작 및 종료 시간 비워 두기)을 사용하는 것이 좋습니다. 이러한 CTs는 AMS 운영자가 RFC를 검사하고 승인 및 실행 전에 사용자와 통신해야 하기 때문입니다. 이러한 RFCs 예약하는 경우 최소 24시간을 허용해야 합니다. 예정된 시작 시간 전에 승인이 이루어지지 않으면 RFC가 자동으로 거부됩니다. AMS에서 승인 필요 RFC를 성공적으로 제출한 경우 사용자의 명시적 승인을 받아야 합니다. 또는 승인 필요 RFC를 제출하는 경우 AMS의 승인을 받아야 합니다. AMS가 제출한 RFC를 승인해야 하는 경우 승인을 요청하는 이메일 또는 기타 미리 결정된 통신이 전송됩니다. 통신에는 RFC ID가 포함됩니다. 통신이 전송된 후 다음 중 하나를 수행합니다. + 콘솔 승인 또는 거부: 관련 RFC에 대한 RFC 세부 정보 페이지를 사용합니다. ![\[RFC 세부 정보 페이지.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/AMS_Console-App-Rej.png) + API/CLI 승인: [ApproveRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ApproveRfc.html)는 변경 사항을 승인됨으로 표시합니다. 필요한 경우 소유자와 운영자 모두 조치를 취해야 합니다. 다음은 CLI 승인 명령의 예입니다. 다음 예제에서는 RFC\$1ID를 적절한 RFC ID로 바꿉니다. ``` aws amscm approve-rfc --rfc-id RFC_ID ``` + API/CLI 거부: [RejectRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_RejectRfc.html)는 변경 사항을 거부로 표시합니다. 다음은 CLI 거부 명령의 예입니다. 다음 예제에서는 RFC\$1ID를 적절한 RFC ID로 바꿉니다. ``` aws amscm reject-rfc --rfc-id RFC_ID --reason "no longer relevant" ``` # RFC 제한 실행 기간 요청 이전에는 블랙아웃 일수라고 했지만 특정 기간을 제한하도록 요청할 수 있습니다. 해당 시간 동안에는 변경 사항을 실행할 수 없습니다. 제한된 실행 기간을 설정하려면 [UpdateRestrictedExecutionTimes](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_UpdateRestrictedExecutionTimes.html) API 작업을 사용하고 UTC로 특정 기간을 설정합니다. 지정한 기간은 지정된 이전 기간을 재정의합니다. 지정된 제한된 실행 시간 동안 RFC를 제출하면 잘못된 RFC 일정 오류와 함께 제출이 실패합니다. 최대 200개의 제한된 기간을 지정할 수 있습니다. 기본적으로 제한된 기간은 설정되지 않습니다. 다음은 요청 명령의 예입니다(SAML 인증이 구성된 경우). ``` aws amscm --profile saml update-restricted-execution-times --restricted-execution-times="[{\"TimeRange\":{\"StartTime\":\"2018-01-01T12:00:00Z\",\"EndTime\":\"2018-01-01T12:00:01Z\"}}]" ``` RestrictedExecutionTimes 설정을 볼 수도 있습니다. [ListRestrictedExecutionTimes](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListRestrictedExecutionTimes.html) 예시 ``` aws amscm --profile saml list-restricted-execution-times ``` 지정된 제한된 실행 시간 동안 RFC를 제출하려면 **RestrictedExecutionTimesOverrideId**를 **OverrideRestrictedTimeRanges** 값으로 추가한 다음 평소와 같이 RFC를 제출합니다. 중요하거나 긴급한 RFC에만이 방법을 사용하는 것이 가장 좋습니다. 자세한 내용은 [SubmitRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_SubmitRfc.html)에 대한 API 참조를 참조하세요. # RFCs 생성, 복제, 업데이트, 찾기 및 취소 다음 예제에서는 다양한 RFC 작업을 안내합니다. **Topics** + [RFC 생성](ex-rfc-create-col.md) + [AMS 콘솔RFCs 복제(다시 생성)](ex-clone-rfcs.md) + [RFCs 업데이트](ex-update-rfcs.md) + [RFCs 찾기](ex-rfc-find-col.md) + [RFCs 취소](ex-cancel-rfcs.md) # RFC 생성 ## 콘솔을 사용하여 RFC 생성 다음은 AMS 콘솔에서 **빠른 카드**가 열리고 **변경 유형 찾아보**기가 활성화된 RFC 생성 프로세스의 첫 페이지입니다. ![\[Quick create section with options for common AWS stack operations and access management.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/quickCreate1.png) 다음은 **범주별 선택**이 활성화된 AMS 콘솔에서 RFC 생성 프로세스의 첫 번째 페이지입니다. ![\[Create RFC page with change type categorization options for managed services environment.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/guiRfcCreate1-2.png) 작동 방식: 1. **RFC 생성** 페이지로 이동합니다. AMS 콘솔의 왼쪽 탐색 창에서 **RFCs** 클릭하여 RFCs 목록 페이지를 연 다음 **RFC 생성을** 클릭합니다. 1. 기본 변경 유형 **찾아보기 보기에서 인기 있는 변경 유형**(CT)을 선택하거나 **범주별 선택** 보기에서 CT를 선택합니다. + **변경 유형별 찾아보**기: **빠른 생성** 영역에서 인기 있는 CT를 클릭하여 **RFC 실행** 페이지를 즉시 열 수 있습니다. 빠른 생성으로 이전 CT 버전을 선택할 수 없습니다. CTs 정렬하려면 **카드** 또는 **테이블** 보기에서 **모든 변경 유형** 영역을 사용합니다. 어느 보기에서든 CT를 선택한 다음 **RFC 생성을** 클릭하여 **RFC 실행** 페이지를 엽니다. 해당하는 경우 RFC **생성 버튼 옆에 이전 버전으로** 생성 옵션이 나타납니다. **** + **범주별 선택**: 범주, 하위 범주, 항목 및 작업을 선택하면 해당하는 경우 **이전 버전으로 생성** 옵션이 있는 CT 세부 정보 상자가 열립니다. **RFC 생성을** 클릭하여 **RFC 실행** 페이지를 엽니다. 1. **RFC 실행** 페이지에서 CT 이름 영역을 열어 CT 세부 정보 상자를 확인합니다. **제목**은 필수입니다(**변경 유형 찾아보**기 보기에서 CT를 선택하면 입력됨). **추가 구성** 영역을 열어 RFC에 대한 정보를 추가합니다. **실행 구성** 영역에서 사용 가능한 드롭다운 목록을 사용하거나 필요한 파라미터의 값을 입력합니다. 선택적 실행 파라미터를 구성하려면 **추가 구성** 영역을 엽니다. 1. 완료되면 **실행**을 클릭합니다. 오류가 없는 경우 **RFC가 성공적으로 생성된** 페이지에 제출된 RFC 세부 정보와 초기 **실행 출력**이 표시됩니다. 1. **실행 파라미터** 영역을 열어 제출한 구성을 확인합니다. 페이지를 새로 고쳐 RFC 실행 상태를 업데이트합니다. 선택적으로 RFC를 취소하거나 페이지 상단의 옵션을 사용하여 RFC 사본을 생성합니다. ## CLI를 사용하여 RFC 생성 작동 방식: 1. 인라인 생성(모든 RFC 및 실행 파라미터가 포함된 `create-rfc` 명령을 실행) 또는 템플릿 생성(2개의 JSON 파일을 생성, 하나는 RFC 파라미터용이고 다른 하나는 실행 파라미터용)을 사용하고 두 파일을 입력으로 사용하여 `create-rfc` 명령을 실행합니다. 두 방법 모두 여기에 설명되어 있습니다. 1. 반환된 RFC ID로 RFC: `aws amscm submit-rfc --rfc-id ID` 명령을 제출합니다. RFC: `aws amscm get-rfc --rfc-id ID` 명령을 모니터링합니다. 변경 유형 버전을 확인하려면 다음 명령을 사용합니다. ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID ``` **참고** `CreateRfc` 변경 유형에 대한 스키마의 일부인지 여부에 관계없이 모든 파라미터를 RFC와 함께 사용할 수 있습니다. 예를 들어 RFC 상태가 변경될 때 알림을 받으려면 요청의 `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"` RFC 파라미터 부분(실행 파라미터 아님)에이 줄을 추가합니다. 모든 CreateRfc 파라미터 목록은 [AMS Change Management API 참조](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html)를 참조하세요. *인라인 생성*: 인라인으로 제공된 실행 파라미터(실행 파라미터를 인라인으로 제공할 때 따옴표 이스케이프)로 RFC 생성 명령을 실행한 다음 반환된 RFC ID를 제출합니다. 예를 들어 콘텐츠를 다음과 같은 내용으로 바꿀 수 있습니다. ``` aws amscm create-rfc --change-type-id "CT_ID" --change-type-version "VERSION" --title "TITLE" --execution-parameters "{\"Description\": \"example\"}" ``` *템플릿 생성*: **참고** RFC를 생성하는이 예제에서는 Load Balancer(ELB) 스택 변경 유형을 사용합니다. 1. 관련 CT를 찾습니다. 다음 명령은 **항목** 이름에 "ELB"가 포함된 CT 분류 요약을 검색하고 범주, 항목, 작업 및 ChangeTypeID의 출력을 테이블 형식으로 생성합니다(둘 다 하위 범주는 임`Advanced stack components`). ``` aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries[?contains(Item,'ELB')].[Category,Item,Operation,ChangeTypeId]" --output table ``` ``` --------------------------------------------------------------------- | CtSummaries | +-----------+---------------------------+---------------------------+ | Deployment| Load balancer (ELB) stack | Create | ct-123h45t6uz7jl | | Management| Load balancer (ELB) stack | Update | ct-0ltm873rsebx9 | +-----------+---------------------------+---------------------------+ ``` 1. 최신 버전의 CT를 찾습니다. `ChangeTypeId` 및 `ChangeTypeVersion`:이 연습의 변경 유형 ID는 `ct-123h45t6uz7jl` (ELB 생성)입니다. 최신 버전을 확인하려면 다음 명령을 실행합니다. ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-123h45t6uz7jl ``` 1. 옵션 및 요구 사항을 알아봅니다. 다음 명령은 스키마를 CreateElbParams.json. ``` aws amscm get-change-type-version --change-type-id "ct-123h45t6uz7jl" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateElbParams.json ``` 1. 실행 파라미터 JSON 파일을 수정하고 저장합니다. 이 예제에서는 파일 이름을 CreateElbParams.json. 프로비저닝 CT의 경우 StackTemplateId는 스키마에 포함되며 실행 파라미터에 제출해야 합니다. TimeoutInMinutes의 경우 RFC가 실패하기 전에 스택을 생성하는 데 허용되는 분 수는이 설정으로 인해 RFC 실행이 지연되지 않지만 충분한 시간을 제공해야 합니다(예: "5"를 지정하지 않음). 오래 실행되는 UserData: EC2 생성 및 ASG 생성CTs의 경우 유효한 값은 "60"\$1"360"입니다. 다른 모든 프로비저닝 CTs에 허용되는 최대 "60"을 권장합니다. 스택을 생성할 VPC의 ID를 제공합니다. CLI 명령를 사용하여 VPC ID를 가져올 수 있습니다`aws amsskms list-vpc-summaries`. ``` { "Description": "ELB-Create-RFC", "VpcId": "VPC_ID", "StackTemplateId": "stm-sdhopv00000000000", "Name": "MyElbInstance", "TimeoutInMinutes": 60, "Parameters": { "ELBSubnetIds": ["SUBNET_ID"], "ELBHealthCheckHealthyThreshold": 4, "ELBHealthCheckInterval": 5, "ELBHealthCheckTarget": "HTTP:80/", "ELBHealthCheckTimeout": 60, "ELBHealthCheckUnhealthyThreshold": 5, "ELBScheme": false } } ``` 1. RFC JSON 템플릿을 CreateElbRfc.json:이라는 현재 폴더의 파일로 출력합니다. ``` aws amscm create-rfc --generate-cli-skeleton > CreateElbRfc.json ``` 1. CreateElbRfc.json 파일을 수정하고 저장합니다. 별도의 파일에서 실행 파라미터를 생성했으므로 `ExecutionParameters` 줄을 제거합니다. 예를 들어 콘텐츠를 다음과 같은 내용으로 바꿀 수 있습니다. ``` { "ChangeTypeVersion": "2.0", "ChangeTypeId": "ct-123h45t6uz7jl", "Title": "Create ELB" } ``` 1. RFC를 생성합니다. 다음 명령은 실행 파라미터 파일과 RFC 템플릿 파일을 지정합니다. ``` aws amscm create-rfc --cli-input-json file://CreateElbRfc.json --execution-parameters file://CreateElbParams.json ``` 응답에서 새 RFC의 ID를 수신하고 이를 사용하여 RFC를 제출하고 모니터링할 수 있습니다. 제출하기 전까지는 RFC가 편집 상태로 유지되고 시작되지 않습니다. ## 팁 **참고** AMS API/CLI를 사용하여 RFC JSON 파일 또는 CT 실행 파라미터 JSON 파일을 생성하지 않고도 RFC를 생성할 수 있습니다. 이렇게 하려면 `create-rfc` 명령을 사용하고 필요한 RFC 및 실행 파라미터를 명령에 추가합니다. 이를 "인라인 생성"이라고 합니다. 모든 프로비저닝 CTs 리소스에 대한 파라미터가 포함된 `Parameters` 배열이 `execution-parameters` 블록 내에 포함되어 있습니다. 파라미터에는 슬래시(\$1)로 이스케이프된 따옴표가 있어야 합니다. RFC를 생성하는 다른 문서화된 방법을 "템플릿 생성"이라고 합니다. 여기에서 RFC 파라미터에 대한 JSON 파일과 실행 파라미터에 대한 다른 JSON 파일을 생성하고 `create-rfc` 명령을 사용하여 두 파일을 제출합니다. 이러한 파일은 템플릿 역할을 할 수 있으며 향후 RFCs. 템플릿을 사용하여 RFCs를 생성할 때 명령을 사용하여 다음과 같이 명령을 실행하여 원하는 콘텐츠로 JSON 파일을 생성할 수 있습니다. 명령은 표시된 콘텐츠가 포함된 "parameters.json"이라는 파일을 생성합니다. 이러한 명령을 사용하여 RFC JSON 파일을 생성할 수도 있습니다. # AMS 콘솔RFCs 복제(다시 생성) AMS 콘솔을 사용하여 기존 RFC를 복제할 수 있습니다. AMS 콘솔을 사용하여 RFC를 복제하거나 다시 생성하려면 다음 단계를 따르세요. 1. 관련 RFC를 찾습니다. 왼쪽 탐색 창에서 **RFCs** 클릭합니다. RFCs 열립니다. 1. 복제하려는 RFC를 찾을 때까지 페이지를 스크롤합니다. **필터** 옵션을 사용하여 목록의 범위를 좁힙니다. 복제할 RFC를 선택합니다. RFC 세부 정보 페이지가 열립니다. 1. **복사본 생성을** 클릭합니다. **변경 요청 생성** 페이지가 열리고 모든 옵션이 원래 RFC에서 로 설정됩니다. 1. 원하는 대로 변경합니다. 추가 옵션을 설정하려면 **기본** 옵션을 **고급**으로 변경합니다. 모든 옵션을 설정한 후 **제출**을 선택합니다. 활성 RFC 세부 정보 페이지가 복제된 RFC의 새 RFC ID와 함께 열리고 복제된 RFC가 RFC 대시보드에 나타납니다. # RFCs 업데이트 RFC를 업데이트한 다음 제출하거나 다시 제출하여 거부되었거나 아직 제출되지 않은 RFC를 다시 제출할 수 있습니다. 지정된 RFCs`RequestedStartTime`가 제출 전에 통과했거나 지정된 TimeoutInMinutes가 RFC를 실행하기에 충분하지 않기 때문에 대부분의 RFC가 거부됩니다(TimeoutInMinutes는 성공적인 RFC를 연장하지 않으므로 Amazon EC2 또는 장기 실행 UserData가 있는 Amazon EC2 Auto Scaling 그룹의 경우 항상 "60"\$1"360"으로 설정하는 것이 좋습니다). 이 섹션에서는 CLI 버전의 `UpdateRfc` 명령을 사용하여 새 RFC 파라미터로 RFC를 업데이트하거나 문자열화된 JSON 또는 업데이트된 파라미터 파일을 사용하여 새 파라미터를 업데이트하는 방법을 설명합니다. 이 예제에서는 AMS UpdateRfc API의 CLI 버전 사용에 대해 설명합니다([RFC 업데이트](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/update-rfc.html) 참조). 일부 리소스(DNS 프라이빗 및 퍼블릭, 로드 밸런서 스택 및 스택 패치 구성)를 업데이트하기 위한 변경 유형이 있지만 RFC를 업데이트할 CT는 없습니다. 한 번에 하나의 UpdateRfc 작업을 제출하는 것이 좋습니다. 예를 들어 DNS 스택에서 여러 업데이트를 제출하면 업데이트가 DNS 업데이트를 동시에 시도하지 못할 수 있습니다. 필수 데이터: `RfcId`: 업데이트 중인 RFC입니다. 선택적 데이터: `ExecutionParameters`:와 같이 필요하지 않은 필드를 업데이트하지 않는 한 수정된 실행 파라미터를 `Description`제출하여 RFC가 거부되거나 취소되는 문제를 해결합니다. 제출된 모든 null이 아닌 값은 원래 RFC에서 해당 값을 덮어씁니다. 1. 거부되거나 취소된 관련 RFC를 찾으려면이 명령을 사용할 수 있습니다( 값을 로 대체할 수 있음`Canceled`). ``` aws amscm list-rfc-summaries --filter Attribute=RfcStatusId,Value=Rejected ``` 1. 다음 RFC 파라미터 중 하나를 수정할 수 있습니다. ``` { "Description": "string", "ExecutionParameters": "string", "ExpectedOutcome": "string", "ImplementationPlan": "string", "RequestedEndTime": "string", "RequestedStartTime": "string", "RfcId": "string", "RollbackPlan": "string", "Title": "string", "WorstCaseScenario": "string"} ``` 설명 필드를 업데이트하는 명령의 예: ``` aws amscm update-rfc --description "AMSTestNoOpsActionRequired" --rfc-id "RFC_ID" --region us-east-1 ``` ExecutionParameters VpcId 필드를 업데이트하는 명령의 예: ``` aws amscm update-rfc --execution-parameters "{\"VpcId\":\"VPC_ID\"}" --rfc-id "RFC_ID" --region us-east-1 ``` 업데이트가 포함된 실행 파라미터 파일로 RFC를 업데이트하는 예제 명령. [EC2 스택 \$1 생성](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ec2-stack-create.html)의 2단계에서 예제 실행 파라미터 파일을 참조하세요. ``` aws amscm update-rfc --execution-parameters file://CreateEc2ParamsUpdate.json --rfc-id "RFC_ID" --region us-east-1 ``` 1. 를 사용하여 RFC를 다시 제출`submit-rfc`하고 RFC를 처음 생성할 때와 동일한 RFC ID를 사용합니다. ``` aws amscm submit-rfc --rfc-id RFC_ID ``` RFC가 성공하면 명령줄에 확인 메시지나 오류 메시지가 표시되지 않습니다. 1. 요청 상태를 모니터링하고 실행 출력을 보려면 다음 명령을 실행합니다. ``` aws amscm get-rfc --rfc-id RFC_ID ``` # RFCs 찾기 ## 콘솔을 사용하여 변경 요청(RFC) 찾기 AMS 콘솔을 사용하여 RFC를 찾으려면 다음 단계를 따릅니다. **참고** 이 절차는 예약된 RFCs, 즉 **ASAP** 옵션을 사용하지 않은 RFCs에만 적용됩니다. 1. 왼쪽 탐색 창에서 **RFCs** 클릭합니다. RFCs 열립니다. 1. 목록을 스크롤하거나 **필터** 옵션을 사용하여 목록을 구체화합니다. RFC 목록은 필터 기준에 따라 변경됩니다. 1. 원하는 RFC의 제목 링크를 선택합니다. RFC ID를 포함한 정보가 포함된 해당 RFC에 대한 RFC 세부 정보 페이지가 열립니다. 1. 대시보드에 RFCs가 많은 경우 **필터** 옵션을 사용하여 RFC로 검색할 수 있습니다. + **제목**: 생성 시 RFC에 제공된 제목 줄 또는 제목(API/CLI)입니다. + **RFC ID**: RFC의 식별자입니다. + **활동 상태**: RFC 상태를 알고 있는 경우 운영자가 현재 RFC를 보고 있다는 의미의 **AwsOperatorAssigned**, RFC 실행을 진행하기 전에 AMS 운영자가 무언가를 수행해야 한다는 의미의 **AwsActionPending** 또는 RFC 실행을 진행하기 전에 조치를 취해야 한다는 의미의 **CustomerActionPending** 중에서 선택할 수 있습니다. + **상태**: RFC 상태를 알고 있는 경우 다음 중에서 선택할 수 있습니다. + **예약**됨: 예약된 RFCs. + **취소됨**: 취소된 RFCs. + **진행 중**: RFCs 진행 중입니다. + **성공**: 성공적으로 실행된 RFCs. + **거부됨**: 거부된 RFCs. + **편집**: 편집 중인 RFCs. + **Failure**: 실패한 RFCs. + **승인 보류** 중: AMS 또는 사용자가 승인할 때까지 진행할 수 없는 RFCs. 일반적으로 이는 RFC를 승인해야 함을 나타냅니다. 서비스 요청 목록에서 이에 대한 서비스 알림을 받게 됩니다. + **변경 유형**: **범주**, **하위 범주**, **항목** 및 **작업을** 선택하면 변경 유형 ID가 검색됩니다. + **요청된 시작 시간** 또는 **요청된 종료 시간**:이 필터 옵션을 사용하면 **이전** 또는 **이후**를 선택한 다음 **날짜** 및 선택적으로 **시간**(hh:mm 및 시간대)을 입력할 수 있습니다. 이 필터는 예약된 RFCs(ASAP RFCs 아님)에서만 성공적으로 작동합니다. + **상태**: **예약**됨, **취소됨**, **진행 중**, **성공**, **거부됨**, **편집** 중 또는 **실패**. + **제목**: RFC에 제공한 제목(또는 RFC가 API/CLI로 생성된 경우 제목)입니다. + **변경 유형 ID**: RFC와 함께 제출된 변경 유형의 식별자를 사용합니다. 다음 스크린샷과 같이 검색을 통해 필터를 추가할 수 있습니다. ![\[Search or filter options including Subject, RFC ID, Activity state, and various time-related fields.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/filterRfcAllOptions3.png) 1. 원하는 RFC의 제목 링크를 클릭합니다. RFC ID를 포함한 정보가 포함된 해당 RFC에 대한 RFC 세부 정보 페이지가 열립니다. ## CLI를 사용하여 변경 요청(RFC) 찾기 여러 필터를 사용하여 RFC를 찾을 수 있습니다. 변경 유형 버전을 확인하려면 다음 명령을 사용합니다. ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID ``` **참고** 변경 유형에 대한 스키마의 일부인지 여부에 관계없이 모든 RFC에서 `CreateRfc` 파라미터를 사용할 수 있습니다. 예를 들어 RFC 상태가 변경될 때 알림을 받으려면 요청의 `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"` RFC 파라미터 부분(실행 파라미터 아님)에이 줄을 추가합니다. 모든 CreateRfc 파라미터 목록은 [AMS Change Management API 참조](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html)를 참조하세요. RFC ID를 기록하지 않고 나중에 찾아야 하는 경우 AMS 변경 관리(CM) 시스템을 사용하여 이를 검색하고 필터 또는 쿼리로 결과의 범위를 좁힐 수 있습니다. 1. CM API [ListRfcSummaries](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListRfcSummaries.html) 작업에는 필터가 있습니다. 논리적 AND 작업에서 `Attribute` 및를 `Value` 결합하거나 , `Condition`및 `Attribute`를 기반으로 결과를 [필터링](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_Filter.html)할 수 있습니다`Values`. **RFC 필터링** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/ex-rfc-find-col.html) 예시: SQS와 관련된 모든 RFCs의 IDs를 찾으려면(SQS가 CT의 항목 부분에 포함된 경우) 다음 명령을 사용할 수 있습니다. ``` list-rfc-summaries --query 'RfcSummaries[?contains(Item.Name,`SQS`)].[Category.Id,Subcategory.Id,Type.Id,Item.Id,RfcId]' --output table ``` 다음과 같이 반환됩니다. ``` ---------------------------------------------------------------------------- | ListRfcSummaries | +----------+--------------------------------+-------+-------+----------------+ |Deployment| Advanced Stack Components |SQS |Create |ct-123h45t6uz7jl| |Management| Monitoring & Notification |SQS |Update |ct-123h45t6uz7jl| +----------+--------------------------------+-------+-------+----------------+ ``` 에 사용할 수 있는 또 다른 필터`list-rfc-summaries`는 자동 또는 수동 RFCs`AutomationStatusId`를 찾는 입니다. ``` aws amscm list-rfc-summaries --filter Attribute=AutomationStatusId,Value=Automated ``` 에 사용할 수 있는 또 다른 필터`list-rfc-summaries`는 `Title` (콘솔의 **제목**)입니다. ``` Attribute=Title,Value=RFC-TITLE ``` RFCs: + (제목에는 "Windows 2012" 또는 "Amazon Linux"라는 문구가 포함되어 있음) 및 + (RfcStatusId EQUALS "Success" 또는 "InProgress") AND + (20170101T000000Z <= RequestedStartTime <= 20170103T000000Z) AND (ActualEndTime <= 20170103T000000Z) ``` { "Filters": [ { "Attribute": "Title", "Values": ["Windows 2012", "Amazon Linux"], "Condition": "Contains" }, { "Attribute": "RfcStatusId", "Values": ["Success", "InProgress"], "Condition": "Equals" }, { "Attribute": "RequestedStartTime", "Values": ["20170101T000000Z", "20170103T000000Z"], "Condition": "Between" }, { "Attribute": "ActualEndTime", "Values": ["20170103T000000Z"], "Condition": "Before" } ] } ``` **참고** 고급를 통해 `Filters`AMS는 향후 릴리스에서 다음 필드를 더 이상 사용하지 않으려고 합니다. 값: 값 필드는 필터 필드의 일부입니다. 고급 기능을 지원하는 값 필드를 사용합니다. RequestedEndTimeRange: 고급 기능을 지원하는 필터 필드 내에서 RequestedEndTime 사용 RequestedStartTimeRange: 고급 기능을 지원하는 필터 필드 내에서 RequestedStartTime을 사용합니다. CLI 쿼리 사용에 대한 자세한 내용은 [ --query 옵션을 사용하여 출력을 필터링하는 방법](https://docs.aws.amazon.com/cli/latest/userguide/controlling-output.html#controlling-output-filter) 및 쿼리 언어 참조인 [JMESPath 사양을](http://jmespath.org/specification.html) 참조하세요. 1. AMS 콘솔을 사용하는 경우: **RFCs** 페이지로 이동합니다. 필요한 경우 RFC 주체를 기준으로 필터링할 수 있습니다. RFC **주체**는 RFC를 생성할 `Title` 때 RFC로 입력한 것입니다. ## 팁 **참고** 이 절차는 예약된 RFCs, 즉 **ASAP** 옵션을 사용하지 않은 RFCs에만 적용됩니다. # RFCs 취소 콘솔 또는 AMS API/CLI를 사용하여 RFC를 취소할 수 있습니다. 콘솔을 사용하여 RFC를 취소하려면 RFC 목록에서 RFC를 찾아 열고 **취소**를 클릭합니다. 필수 데이터: + `Reason`: RFC를 취소하는 이유. + `RfcId`: 취소하려는 RFC입니다. 1. 일반적으로 RFC를 제출한 직후 취소합니다(RFC ID가 유용해야 함). 그렇지 않으면 예약한 후 지정된 시작 시간 이전이 아니면 취소할 수 없습니다. RFC ID를 찾아야 하는 경우이 명령을 사용할 수 있습니다(수동으로 승인된 RFC를 `PendingApproval` `Value`로 대체할 수 있음). ``` aws amscm list-rfc-summaries --filter Attribute=RfcStatusId,Value=Scheduled ``` 1. RFC를 취소하는 명령의 예: ``` aws amscm cancel-rfc --reason "Bad Stack ID" --rfc-id "RFC_ID" --profile saml --region us-east-1 ``` # RFCs와 함께 AMS 콘솔 사용 AMS 콘솔은 RFCs를 생성하고 제출하는 데 도움이 되는 기능을 제공합니다. ## RFC 목록 페이지 사용(콘솔) AMS 콘솔 **RFCs** 목록 페이지에는 다음 옵션이 제공됩니다. + **필터를** 통한 고급 RFC 검색. 자세한 내용은 [RFCs 찾기](ex-rfc-find-col.md) 단원을 참조하세요. + RFC가 마지막으로 **수정된** 시간을 찾습니다. 이 값은 RFC 상태가 마지막으로 변경된 시간을 나타냅니다. + RFC **주체**를 사용하여 RFC 세부 정보 보기. 이 링크를 선택하면 해당 RFC의 세부 정보 페이지가 열립니다. + RFC 상태 보기. 자세한 정보는 [RFC 상태 코드 이해](ex-rfc-status-codes.md) 섹션을 참조하세요. ![\[RFC 목록 페이지.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/guiRfcListTable.png) ## RFC 빠른 생성 사용(콘솔) RFC 빠른 생성 카드 또는 목록 테이블을 사용하거나 분류별로 RFCs에 대한 변경 유형을 선택합니다. 자세한 내용은 [RFC 생성](ex-rfc-create-col.md)를 참조하세요. ## RFC 서신 및 첨부 파일 추가(콘솔) 예를 들어 "PendingApproval" 상태일 때 RFC가 제출된 후 승인되기 전에 RFC에 서신을 추가할 수 있습니다. RFC가 승인된 후('예약됨' 또는 'InProgress' 상태) 요청에 대한 변경으로 해석될 수 있으므로 서신을 추가할 수 없습니다. RFC가 완료되면("Canceled", "Rejected", "Success" 또는 "Failure" 상태) 대응이 다시 활성화됩니다. 단, RFC가 30일 이상 닫히면 대응이 비활성화됩니다. **참고** 각 서신은 5,000자로 제한됩니다. **첨부 파일에 대한 제한 사항:** + 서신당 첨부 파일은 3개뿐입니다. + RFC당 50개의 첨부 파일을 제한합니다. + 각 연결의 크기는 5MB 미만이어야 합니다. + 일반 텍스트(`.txt`), 쉼표로 구분된 값(`.csv`), JSON(`.json`) 또는 YAML()과 같은 텍스트 파일만 허용됩니다`.yaml`. YAML 형식의 경우 파일 확장명를 사용하여 파일을 첨부해야 합니다`.yaml`. **참고** XML 콘텐츠가 있는 텍스트 파일은 금지됩니다. AMS와 공유할 XML 콘텐츠가 있는 경우 서비스 요청을 사용합니다. + 파일 이름은 숫자, 문자, 공백, 대시(-), 밑줄(\$1), 점(.)만 포함하여 255자로 제한됩니다. + RFC에서 첨부 파일을 업데이트하고 삭제하는 것은 현재 지원되지 않습니다. RFC에 서신과 첨부 파일을 추가하려면 다음 단계를 따르세요. 1. AMS 콘솔의 RFC 세부 정보 페이지에서 페이지 하단의 **서신** 섹션을 찾습니다. 서신을 보내기 전에: ![\[빈 서신 섹션.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/correspondence-rfc-detail-new.png) 일부 서신을 보낸 후: ![\[회신 양식과 수신된 서신을 보여주는 서신 섹션입니다.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/correspondence-reply-form2.png) 1. 새 서신을 추가하려면 **회신** 텍스트 상자에 메시지를 입력합니다. 서신과 관련된 파일을 첨부하려면 **첨부 파일 추가**를 선택한 다음 원하는 파일을 선택합니다. ![\[설명 상자와 첨부 파일을 보여주는 서신 섹션입니다.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/correspondence-add-attachments.png) 1. 완료되면 **제출**을 선택합니다. 새 서신은 첨부된 파일에 대한 링크와 함께 RFC 세부 정보 페이지의 서신 목록에 표시됩니다. ![\[수신된 서신의 목록입니다.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/correspondence-list2.png) # RFC 이메일 알림 구성(콘솔) AMS 콘솔 **변경 요청** 생성 페이지에서는 이메일 주소를 추가하여 RFC 상태 변경 알림을 받을 수 있는 옵션을 제공합니다. ![\[이메일 주소를 추가하여 RFC 상태 변경 알림을 받습니다.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/emailNoticeOption2.png) 또한 다음과 같은 모든 변경 유형에 알림용 이메일 주소를 추가할 수 있습니다. ``` aws amscm create-rfc --change-type-id --change-type-version 1.0 --title "TITLE" --notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}" ``` 파라미터 부분이 아닌 요청의 RFC 파라미터 부분에 있는 모든 변경 유형 인라인 또는 템플릿 요청에 유사한 줄(`--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"`)을 추가합니다. # 일반적인 RFC 파라미터에 대해 알아보기 다음은 제출해야 하는 RFC 파라미터와 RFCs + 변경 유형 정보: ChangeTypeId 및 ChangeTypeVersion. 변경 유형 IDs. [https://docs.aws.amazon.com/managedservices/latest/ctref/index.html](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html) `query` 인수를 사용하여 CLI`list-change-type-classification-summaries`에서를 실행하여 결과의 범위를 좁힙니다. 예를 들어, 결과를 좁혀 `Item` 이름에 "Access"가 포함된 유형을 변경합니다. ``` aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries [?contains (Item, 'access')].[Category,Subcategory,Item,Operation,ChangeTypeId]" --output table ``` 를 실행`get-change-type-version`하고 변경 유형 ID를 지정합니다. 다음 명령은 ct-2tylseo8rxfsc의 CT 버전을 가져옵니다. ``` aws amscm get-change-type-version --change-type-id ct-2tylseo8rxfsc ``` + 제목: RFC의 이름입니다.이 이름은 AMS 콘솔 RFC 목록에서 RFC의 **주체**가 되며 `GetRfc` 명령과 필터를 사용하여 검색할 수 있습니다. `Title` + 예약: 예약된 RFC를 원하는 경우 `RequestedStartTime` 및 `RequestedEndTime` 파라미터를 포함하거나 **이 변경 예약** 콘솔 옵션을 사용해야 합니다. **ASAP** RFC(승인되는 즉시 실행됨)의 경우 CLI를 사용할 때 `RequestedStartTime` 및 `RequestedEndTime` null을 그대로 둡니다. 콘솔을 사용하는 경우 **ASAP** 옵션을 수락합니다. `RequestedStartTime`이 누락된 경우 RFC가 거부됩니다. + 프로비저닝 CTs: 실행 파라미터 또는 `Parameters`는 리소스를 프로비저닝하는 데 필요한 특정 설정입니다. CT에 따라 크게 달라집니다. + 비프로비저닝 CTs: CTs 또는 기타 \$1 기타 또는 스택 삭제와 같이 리소스를 프로비저닝하지 않는 CTs에는 최소한의 실행 파라미터가 있으며 `Parameters` 블록이 없습니다. + 또한 일부 RFCs에서는를 지정`TimeoutInMinutes`하거나 RFC가 실패하기 전에 스택을 생성하는 데 허용되는 분 수를 지정해야 합니다. 유효한 값은 장기 실행 UserData의 경우 60(분)\$1360입니다. 이 `TimeoutInMinutes` 초과되기 전에 실행을 완료할 수 없는 경우 RFC가 실패합니다. 그러나이 설정은 RFC 실행을 지연시키지 않습니다. + S3 버킷 또는 ELB와 같이 인스턴스를 생성하는 RFCs는 일반적으로 최대 7개의 태그(키/값 페어)를 추가할 수 있는 스키마를 제공합니다. 배포 \$1 고급 스택 구성 요소 \$1 태그 \$1 변경 유형 생성(ct-3cx7we852p3af)을 사용하여 RFC를 제출하여 S3 버킷에 태그를 더 추가할 수 있습니다. EC2, EFS, RDS 및 다중 계층(HA 2계층 및 HA 1계층) 스키마는 최대 50개의 태그를 허용합니다. 태그는 스키마의 `ExecutionParameters` 부분에 지정됩니다. 태그를 제공하는 것은 큰 가치가 있을 수 있습니다. 자세한 내용은 [Amazon EC2 리소스에 태그 지정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) 단원을 참조하십시오. AMS 콘솔을 사용하는 경우 태그를 추가하려면 **추가 구성** 영역을 열어야 합니다. **작은 정보** 많은 CT 스키마에는 스키마 상단에 `Description` 및 `Name` 필드가 있습니다. 이러한 필드는 스택 또는 스택 구성 요소의 이름을 지정하는 데 사용되며 생성 중인 리소스의 이름은 지정되지 않습니다. 일부 스키마는 생성 중인 리소스의 이름을 지정하는 파라미터를 제공하고 일부는 그렇지 않습니다. 예를 들어 EC2 스택 생성을 위한 CT 스키마는 EC2 인스턴스 이름을 지정하는 파라미터를 제공하지 않습니다. 이렇게 하려면 "Name" 키와 이름을 지정할 값을 사용하여 태그를 생성해야 합니다. 이러한 태그를 생성하지 않으면 EC2 인스턴스가 이름 속성 없이 EC2 콘솔에 표시됩니다. ## RFC AWS 리전 옵션 사용 AMS API 및 CLI(`amscm` 및 `amsskms`) 엔드포인트는에 있습니다`us-east-1`. SAML(Security Assertion Markup Language)과 연동하면 온보딩 시 AWS 리전을 us-east-1로 설정하는 스크립트가 제공됩니다. SAML을 사용하는 경우 명령을 실행할 때 `--region` 옵션을 지정할 필요가 없습니다. SAML이 us-east-1을 사용하도록 구성되어 있지만 계정이 해당 AWS 리전에 없는 경우 다른 AWS 명령(예: )을 실행할 때 계정 온보딩 리전을 지정해야 합니다`aws s3`. **참고** 이 가이드에 제공된 대부분의 명령 예제에는 `--region` 옵션이 포함되어 있지 않습니다. # RFC 일일 이메일에 가입 RFC 다이제스트 기능을 사용하여 지난 24시간 동안 계정의 RFC 활동을 요약하는 일일 이메일에 가입할 수 있습니다. RFC 다이제스트 기능은 계정의 RFCs. RFC 다이제스트는 응답을 보류 중인 작업을 놓칠 가능성을 줄일 수 있습니다. RFC 다이제스트 기능을 켜려면 AMS Cloud Service Delivery Manager(CSDM)에 문의하십시오. CSDM에서 구독합니다. RFC 다이제스트 이메일 목록에 포함할 이메일 주소(또는 별칭)를 최대 20개까지 요청할 수 있습니다. 현재 이메일 일정은 09:00 UTC-8에 고정됩니다. RFC 다이제스트 기능을 끄려면 요청과 함께 CSDM에 문의하세요. RFC 다이제스트를 설정하지 않고 RFCs에 대한 알림을 원하는 경우 또는 RFCs 다이제스트가 제공하는 것보다 RFC에 대한 자세한 정보를 원하는 경우 변경 관리 시스템을 사용하여 정보를 원하는 모든 개별 RFC에 대해 CloudWatch Events 알림 또는 이메일 알림을 설정합니다. RFC 알림 설정에 대한 자세한 내용은 [RFC 상태 변경 알림을 참조하세요](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-state-change-notices.html). RFC 다이제스트에 포함된 주제는 다음과 같습니다. + 고객 승인 대기 중: 승인 대기 중인 **PendingApproval** 중 상태인 RFCs를 나열합니다. + 고객 응답 대기 중: RFCs 서신에 대한 응답을 기다리고 있는 RFC를 나열합니다. + AWS 승인 또는 회신 보류 중: AMS에서 회신 또는 승인을 기다리고 있는 RFCs를 나열합니다. + 완료됨: **성공**, **실패**, **취소됨** 및 **거부됨** 상태의 RFCs를 나열합니다. 다음은 RFC 다이제스트의 예입니다. ![\[RFC 다이제스트 예제\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/RFCDigestExample.png) # 변경 유형이란 무엇입니까? 변경 유형은 AWS Managed Services(AMS)의 변경 요청(RFC)이 수행하고 변경 작업 자체와 수동 및 자동의 변경 유형을 포함하는 작업을 나타냅니다. AMS에는 다른 Amazon 웹 서비스에서 사용하지 않는 대규모 변경 유형 모음이 있습니다. 리소스 배포, 관리 또는 액세스 권한을 얻기 위해 변경 요청(RFC)을 제출할 때 이러한 변경 유형을 사용합니다. **Topics** + [자동 및 수동 CTs](ug-automated-or-manual.md) + [CT 승인 요구 사항](constrained-unconstrained-ctis.md) + [유형 버전 변경](ct-versions.md) + [변경 유형 생성](ct-creates.md) + [변경 유형 업데이트](ct-updates.md) + [내부 전용 변경 유형](ct-internals.md) + [변경 유형 스키마](ct-schemas.md) + [변경 유형에 대한 권한 관리](ct-permissions.md) + [변경 유형에서 민감한 정보 수정](ct-redaction.md) + [쿼리 옵션을 사용하여 변경 유형 찾기](ug-find-ct-ex-section.md) # 자동 및 수동 CTs 변경 유형에 대한 제약 조건은 자동 또는 수동인지 여부입니다. 이는 AMS 콘솔에서 **실행 모드**라고 하는 변경 유형 `AutomationStatusId` 속성입니다. 자동 변경 유형은 예상 결과와 실행 시간이 있으며 일반적으로 1시간 이내에 AMS 자동 시스템을 통해 실행됩니다(대부분 CT가 프로비저닝하는 리소스에 따라 다름). 수동 변경 유형은 흔하지 않지만 AMS 연산자가 실행되기 전에 RFC에서 작업해야 하므로 다르게 처리됩니다. 이는 RFC 제출자와 통신하는 것을 의미하기도 하므로 수동 변경 유형을 완료하려면 다양한 시간이 필요합니다. 예약된 모든 RFCs 대해 지정되지 않은 종료 시간은 지정된의 시간과 제출된 변경 유형의 `ExpectedExecutionDurationInMinutes` 속성을 `RequestedStartTime` 더한 시간으로 작성됩니다. 예를 들어 `ExpectedExecutionDurationInMinutes`가 "60"(분)이고 지정된 `RequestedStartTime`가 `2016-12-05T14:20:00Z` (2016년 12월 5일 오전 4시 20분)인 경우 실제 종료 시간은 2016년 12월 5일 오전 5시 20분으로 설정됩니다. 특정 변경 유형에 `ExpectedExecutionDurationInMinutes` 대한를 찾으려면 다음 명령을 실행합니다. ``` aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}" ``` **참고** **실행 모드**가 수동인 예약된 RFCs 콘솔에서 최소 24시간 후에 실행되도록 설정해야 합니다. **참고** 수동 CTs를 사용하는 경우 ASAP **예약** 옵션(콘솔에서 **ASAP** 선택, API/CLI에서 시작 및 종료 시간 비워 두기)을 사용하는 것이 좋습니다. 이러한 CTs는 AMS 운영자가 RFC를 검사하고 승인 및 실행 전에 사용자와 통신해야 하기 때문입니다. 이러한 RFCs 예약하는 경우 최소 24시간을 허용해야 합니다. 예정된 시작 시간 전에 승인이 이루어지지 않으면 RFC가 자동으로 거부됩니다. AMS는 4시간 이내에 수동 CT에 응답하는 것을 목표로 하며 가능한 한 빨리 대응하지만 RFC를 실제로 실행하는 데 훨씬 더 오래 걸릴 수 있습니다. 수동이고 AMS 검토가 필요한 CTs 목록은 콘솔의 **개발자 리소스** 페이지에서 사용할 수 있는 변경 유형 CSV 파일을 참조하세요. **YouTube 동영상**: [ AMS RFCs 하나요?](https://www.youtube.com/watch?v=sOzDuCCOduI&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=2&t=1s) AMS 콘솔에서 CT의 **실행 모드를** 찾으려면 **변경 유형 찾아보기** 검색 옵션을 사용해야 합니다. 결과는 일치하는 변경 유형 또는 변경 유형의 실행 모드를 보여줍니다. AMS CLI를 사용하여 특정 변경 유형에 `AutomationStatus` 대한를 찾으려면 다음 명령을 실행합니다. ``` aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{AutomationStatus:AutomationStatus.Name}" ``` 모든 [AMS 변경 유형에 대한 정보를 제공하는 AMS 변경 유형 참조](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html)에서 변경 유형을 조회할 수도 있습니다. **참고** AMS API/CLI는 현재 AWS API/CLI의 일부가 아닙니다. AMS API/CLI에 액세스하려면 AMS 콘솔을 통해 AMS SDK를 다운로드합니다. # CT 승인 요구 사항 AMS CTs에는 항상 **AwsApprovalId**와 **CustomerApprovalId**라는 두 가지 승인 조건이 있습니다.이 조건은 RFC에서 실행을 승인하기 위해 AMS 또는 사용자 또는 다른 사람이 필요한지 여부를 나타냅니다. 승인 조건은 실행 모드와 다소 관련이 있습니다. 자세한 내용은 섹션을 참조하세요[자동 및 수동 CTs](ug-automated-or-manual.md). CT의 승인 조건을 확인하려면 [AMS 변경 유형 참조](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html)에서 확인하거나 [GetChangeTypeVersion](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetChangeTypeVersion.html)을 실행합니다. 둘 다 CT `AutomationStatusId` 또는 **실행 모드**도 제공합니다. AMS 콘솔을 사용하거나 다음 명령을 사용하여 RFCs를 승인할 수 있습니다. ``` aws amscm approve-rfc --rfc-id RFC_ID ``` **CT 승인 조건** | CT 승인 조건이 인 경우 | 의 승인이 필요합니다. | 및 | | --- | --- | --- | | `AwsApprovalId: Required` | AMS 변경 유형 시스템 | 아무 조치도 필요하지 않습니다. 이 조건은 자동 CTs의 경우 일반적입니다. | | `AwsApprovalId: NotRequiredIfSubmitter` | 제출된 RFC가 제출된 계정에 대한 경우 AMS 변경 유형 시스템이며 다른 사람은 없습니다. | 아무 조치도 필요하지 않습니다. 이 조건은 AMS 운영자가 항상 검토하므로 수동 CTs의 경우 일반적입니다. | | `CustomerApprovalId: NotRequired` | AMS 변경 유형 시스템 | RFC가 구문 및 파라미터 검사를 통과하면 자동으로 승인됩니다. | | `CustomerApprovalId: Required` | AMS 변경 유형 시스템 및 사용자, | 알림이 전송되므로 알림에 응답하거나 [ApproveRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ApproveRfc.html) 작업을 실행하여 RFC를 명시적으로 승인해야 합니다. | | `CustomerApprovalId: NotRequiredIfSubmitter` | RFC를 제출한 경우 AMS 변경 유형 시스템이며 다른 사람은 없습니다. | RFC가 구문 및 파라미터 검사를 통과하면 자동으로 승인됩니다. | | 긴급 보안 인시던트 또는 패치 | AMS | 자동 승인되고 구현됩니다. | # 유형 버전 변경 변경 유형은 버전이 지정되고 변경 유형에 대한 주요 업데이트가 수행되면 버전이 변경됩니다. AMS 콘솔을 사용하여 변경 유형을 선택한 후 **추가 구성** 영역을 열고 변경 유형 버전을 선택할 수 있습니다. API/CLI 명령줄에서 변경 유형 버전을 지정할 수도 있습니다. 다음과 같은 다양한 이유로이 작업을 수행할 수 있습니다. + 원하는 **업데이트** 변경 유형의 버전은 현재 업데이트하려는 리소스를 생성하는 데 사용한 변경 **생성** 유형의 버전과 일치해야 합니다. 예를 들어 ELB 변경 유형 버전 1 생성을 사용하여 생성한 Elastic Load Balancer(ELB) 인스턴스가 있을 수 있습니다. 업데이트하려면 ELB 업데이트 버전 1을 선택합니다. + 최신 변경 유형과 다른 옵션이 있는 변경 유형 버전을 사용하려고 합니다. AMS 업데이트는 주로 보안상의 이유로 유형을 변경하므로 권장하지 않으며 항상 최신 버전을 선택하는 것이 좋습니다. # 변경 유형 생성 변경 유형 생성은 version-to-version 변경 유형 업데이트와 일치합니다. 즉, 리소스를 프로비저닝하는 데 사용하는 변경 유형 버전은 나중에 해당 리소스를 수정하는 데 사용할 업데이트 변경 유형 버전과 일치해야 합니다. 예를 들어 S3 버킷 변경 유형 생성 버전 2.0으로 S3 버킷을 생성하고 나중에 RFC를 제출하여 해당 S3 버킷을 수정하려는 경우 버전 S3.0으로 S3 버킷 업데이트 변경 유형이 있더라도 S3 버킷 업데이트 변경 유형 버전 2.0도 사용해야 합니다. 나중에 변경 유형 업데이트를 사용하여 수정하려는 경우 변경 유형 생성으로 리소스를 프로비저닝할 때 사용하는 변경 유형 ID 및 버전에 대한 레코드를 보관하는 것이 좋습니다. # 변경 유형 업데이트 AMS는 변경 유형 생성을 사용하여 생성된 리소스를 업데이트하는 업데이트 변경 유형을 제공합니다. 업데이트 변경 유형은 원래 리소스를 프로비저닝하는 데 사용된 변경 생성 유형과 version-to-version이 일치해야 합니다. 리소스를 쉽게 업데이트할 수 있도록 리소스를 프로비저닝할 때 사용하는 변경 유형 ID 및 버전을 기록해 두는 것이 좋습니다. **YouTube 동영상**: [ 업데이트 CTs 사용하여 AWS Managed Services(AMS) 계정의 리소스를 변경하려면 어떻게 해야 하나요?](https://www.youtube.com/watch?v=dqb31yaAXhc&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=8&t=30s) # 내부 전용 변경 유형 내부 전용 변경 유형을 볼 수 있습니다. 따라서 AMS가 수행할 수 있거나 수행할 수 있는 작업을 알 수 있습니다. 사용하려는 내부 전용 변경 유형이 있는 경우 서비스 요청을 제출합니다. 예를 들어 관리 \$1 모니터링 및 알림 \$1 CloudWatch 경보 억제 \$1 내부 전용 CT 업데이트가 있습니다. AMS는 이를 사용하여 인프라 업데이트(패칭 등)를 배포하고 업데이트가 잘못 트리거될 수 있는 경보 알림을 끕니다. 이 CT가 제출되면 RFC 목록에 CT의 RFC가 표시됩니다. RFC에 배포된 모든 내부 전용 CT는 RFC 목록에 표시됩니다. # 변경 유형 스키마 모든 변경 유형은 리소스의 생성, 수정 또는 액세스 시 입력에 대한 JSON 스키마를 제공합니다. 스키마는 변경 요청(RFC)을 생성할 수 있도록 파라미터와 설명을 제공합니다. RFC를 성공적으로 실행하면 실행 출력이 생성됩니다. RFCs 프로비저닝의 경우 실행 출력에는 CloudFormation의 스택을 나타내며 CloudFormation 콘솔에서 검색할 수 있는 "stack\$1id"가 포함됩니다. 실행 출력에는 생성된 인스턴스의 ID 출력이 포함되고 해당 ID를 사용하여 해당 AWS 콘솔에서 인스턴스를 검색할 수 있습니다. 예를 들어 ELB CT 실행 생성 출력에는 CloudFormation에서 검색할 수 있는 "stack\$1id"가 포함되며 Amazon EC2 콘솔에서 Elastic Load Balancing에 대해 검색할 수 있는 키=ELB 값=가 출력됩니다. CT 스키마를 살펴보겠습니다. 이것은 상당히 작은 스키마인 CodeDeploy Application Create의 스키마입니다. 일부 스키마에는 매우 큰 `Parameter` 영역이 있습니다. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/ct-schemas.html) **참고** 이 스키마는 최대 7개의 태그를 허용하지만 EC2, EFS, RDS 및 다중 계층 생성 스키마는 최대 50개의 태그를 허용합니다. # 변경 유형에 대한 권한 관리 사용자 지정 정책을 사용하여 다른 그룹 또는 사용자가 사용할 수 있는 변경 유형(CTs)을 제한할 수 있습니다. 이에 대한 자세한 내용은 AMS 사용 설명서의 [권한 설정을 참조하세요](https://docs.aws.amazon.com/managedservices/latest/userguide/setting-permissions.html). # 변경 유형에서 민감한 정보 수정 AMS 변경 유형 스키마`"metadata":"ams:sensitive":"true"`는 암호와 같은 민감한 정보를 포함하는 파라미터에 사용되는 파라미터 속성을 제공합니다. 이 속성을 설정하면 제공된 입력이 가려집니다. 이 파라미터 속성은 설정할 수 없지만 AMS를 사용하여 변경 유형을 생성하고 입력 시 가려야 하는 파라미터가 있는 경우 이를 요청할 수 있습니다. # 쿼리 옵션을 사용하여 변경 유형 찾기 이 예제에서는 AMS 콘솔을 사용하여 제출하려는 RFC에 적합한 변경 유형을 찾는 방법을 보여줍니다. 콘솔 또는 API/CLI를 사용하여 변경 유형 ID(CT) 또는 버전을 찾을 수 있습니다. 검색 또는 분류 선택이라는 두 가지 방법이 있습니다. 두 선택 유형 모두 **가장 자주 사용**, **가장 최근에 사용** 또는 **알파벳순을 선택하여 검색을 정렬할 수 있습니다**. **YouTube 동영상**: [ AWS Managed Services CLI를 사용하여 RFC를 생성하려면 어떻게 해야 하고 CT 스키마는 어디에서 찾을 수 있습니까?](https://www.youtube.com/watch?v=IluDFwnJJFU&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=3&t=150s) AMS 콘솔의 **RFCs** **** + **변경 유형별 찾아보**기(기본값)를 선택한 상태에서 다음 중 하나를 수행합니다. + **빠른 생성** 영역을 사용하여 AMS의 가장 인기 CTs 중에서 선택합니다. 레이블을 클릭하면 **제목** 옵션이 자동으로 채워진 **RFC 실행** 페이지가 열립니다. 필요에 따라 나머지 옵션을 완료하고 **실행**을 클릭하여 RFC를 제출합니다. + 또는 **모든 변경 유형** 영역까지 아래로 스크롤하여 옵션 상자에 CT 이름을 입력하기 시작합니다. 정확한 변경 유형 이름이나 전체 변경 유형 이름을 가질 필요는 없습니다. 관련 단어를 입력하여 변경 유형 ID, 분류 또는 실행 모드(자동 또는 수동)별로 CT를 검색할 수도 있습니다. 기본 **카드** 보기를 선택하면 입력 시 일치하는 CT 카드가 나타나고 카드를 선택한 다음 **RFC 생성을** 클릭합니다. **테이블** 보기를 선택한 상태에서 관련 CT를 선택하고 **RFC 생성을** 클릭합니다. 두 방법 모두 **RFC 실행** 페이지를 엽니다. + 또는 변경 유형 선택을 탐색하려면 페이지 상단의 **범주별 선택을** 클릭하여 일련의 드롭다운 옵션 상자를 엽니다. + **범주**, **하위 범주**, **항목** 및 **작업을** 선택합니다. 해당 변경 유형에 대한 정보 상자가 페이지 하단에 패널이 나타납니다. + 준비가 되면 **Enter** 키를 누르면 일치하는 변경 유형 목록이 나타납니다. + 목록에서 변경 유형을 선택합니다. 해당 변경 유형에 대한 정보 상자가 페이지 하단에 나타납니다. + 올바른 변경 유형을 지정한 후 **RFC 생성을** 선택합니다. **참고** 이러한 명령이 작동하려면 AMS CLI가 설치되어 있어야 합니다. AMS API 또는 CLI를 설치하려면 AMS 콘솔 **개발자 리소스** 페이지로 이동합니다. AMS CM API 또는 AMS SKMS API에 대한 참조 자료는 사용 설명서의 AMS 정보 리소스 섹션을 참조하세요. 인증 `--profile` 옵션을 추가해야 할 수 있습니다. 예: `aws amsskms ams-cli-command --profile SAML`. 와 같이 모든 AMS 명령이 us-east-1에서 부족하므로 `--region` 옵션을 추가해야 할 수도 있습니다`aws amscm ams-cli-command --region=us-east-1`. **참고** AMS API/CLI(amscm 및 amsskms) 엔드포인트는 AWS 버지니아 북부 리전에 있습니다`us-east-1`. 인증 설정 방식과 계정 및 리소스가 있는 AWS 리전에 따라 명령을 실행할 `--region us-east-1` 때를 추가해야 할 수 있습니다. 인증 방법인 `--profile saml`경우를 추가해야 할 수도 있습니다. AMS CM API([ListChangeTypeClassificationSummaries](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListChangeTypeClassificationSummaries.html) 참조) 또는 CLI를 사용하여 변경 유형을 검색하려면 필터 또는 쿼리를 사용하여 검색할 수 있습니다. ListChangeTypeClassificationSummaries 작업에는 `Category`, `Subcategory``Item`, 및에 대한 [필터](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListChangeTypeClassificationSummaries.html#amscm-ListChangeTypeClassificationSummaries-request-Filters) 옵션이 `Operation`있지만 값은 기존 값과 정확히 일치해야 합니다. CLI를 사용할 때 보다 유연한 결과를 얻으려면 `--query` 옵션을 사용할 수 있습니다. **AMS CM API/CLI를 사용한 유형 필터링 변경** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/ug-find-ct-ex-section.html) 1. 다음은 변경 유형 분류를 나열하는 몇 가지 예입니다. 다음 명령은 모든 변경 유형 범주를 나열합니다. ``` aws amscm list-change-type-categories ``` 다음 명령은 지정된 범주에 속하는 하위 범주를 나열합니다. ``` aws amscm list-change-type-subcategories --category CATEGORY ``` 다음 명령은 지정된 범주 및 하위 범주에 속하는 항목을 나열합니다. ``` aws amscm list-change-type-items --category CATEGORY --subcategory SUBCATEGORY ``` 1. 다음은 CLI 쿼리를 사용하여 변경 유형을 검색하는 몇 가지 예입니다. 다음 명령은 항목 이름에 "S3"가 포함된 CT 분류 요약을 검색하고 범주, 하위 범주, 항목, 작업 및 변경 유형 ID의 출력을 테이블 형식으로 생성합니다. ``` aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries [?contains(Item, 'S3')].[Category,Subcategory,Item,Operation,ChangeTypeId]" --output table ``` ``` +---------------------------------------------------------------+ | ListChangeTypeClassificationSummaries | +----------+-------------------------+--+------+----------------+ |Deployment|Advanced Stack Components|S3|Create|ct-1a68ck03fn98r| +----------+-------------------------+--+------+----------------+ ``` 1. 그런 다음 변경 유형 ID를 사용하여 CT 스키마를 가져오고 파라미터를 검사할 수 있습니다. 다음 명령은 스키마를 CreateS3Params.schema.json. ``` aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3Params.schema.json ``` CLI 쿼리 사용에 대한 자세한 내용은 [--query 옵션을 사용하여 출력을 필터링하는 방법](https://docs.aws.amazon.com/cli/latest/userguide/controlling-output.html#controlling-output-filter) 및 쿼리 언어 참조인 [JMESPath 사양을](http://jmespath.org/specification.html) 참조하세요. 1. 변경 유형 ID가 있으면 변경 유형의 버전을 확인하여 최신 버전인지 확인하는 것이 좋습니다. 이 명령을 사용하여 지정된 변경 유형의 버전을 찾습니다. ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CHANGE_TYPE_ID ``` 특정 변경 유형에 `AutomationStatus` 대한를 찾으려면 다음 명령을 실행합니다. ``` aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{AutomationStatus:AutomationStatus.Name}" ``` 특정 변경 유형에 `ExpectedExecutionDurationInMinutes` 대한를 찾으려면 다음 명령을 실행합니다. ``` aws amscm --profile saml get-change-type-version --change-type-id ct-14027q0sjyt1h --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}" ``` # AMS의 RFC 오류 문제 해결 CloudFormation 설명서를 통해 많은 AMS 프로비저닝 RFC 실패를 조사할 수 있습니다. [ AWS CloudFormation 문제 해결: 오류 문제 해결을 참조하세요](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors). 추가 문제 해결 제안은 다음 섹션에 나와 있습니다. ## AMS의 “관리” RFC 오류 AMS "관리" 범주 변경 유형(CTs)을 사용하면 리소스에 대한 액세스를 요청하고 기존 리소스를 관리할 수 있습니다. 이 섹션에서는 몇 가지 일반적인 문제를 설명합니다. ### RFC 액세스 오류 + RFC에 지정한 사용자 이름과 FQDN이 올바르고 도메인에 존재하는지 확인합니다. FQDN을 찾는 데 도움이 필요하면 [FQDN 찾기를 참조하세요](https://docs.aws.amazon.com/managedservices/latest/userguide/find-FQDN.html). + 액세스를 위해 지정한 스택 ID가 EC2-related 스택인지 확인합니다. ELB 및 Amazon Simple Storage Service(S3)와 같은 스택은 액세스 RFCs의 대상이 아니며, 대신 읽기 전용 액세스 역할을 사용하여 이러한 스택 리소스에 액세스합니다. 스택 ID 찾기에 대한 도움말은 [스택 IDs](https://docs.aws.amazon.com/managedservices/latest/userguide/find-stack.html). + 제공한 스택 ID가 올바르고 관련 계정에 속하는지 확인합니다. 다른 액세스 RFC 실패에 대한 도움말은 [액세스 관리를](https://docs.aws.amazon.com/managedservices/latest/userguide/access-mgmt.html) 참조하세요. **YouTube 동영상**: [ 거부 및 실패를 방지하기 위해 변경 요청(RFC)을 올바르게 제기하려면 어떻게 해야 하나요?](https://www.youtube.com/watch?v=IFOn4Q-5Cas&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=5&t=242s) ### RFC(수동) CT 예약 오류 대부분의 변경 유형은 ExecutionMode=Automated이지만 일부는 ExecutionMode=Manual이며 RFC 실패를 방지하기 위해 변경 유형을 예약하는 방법에 영향을 미칩니다. ExecutionMode=ManualRFCs는 AMS 콘솔을 사용하여 RFC를 생성하는 경우 향후 최소 24시간 동안 실행되도록 설정해야 합니다. AMS는 8시간 이내에 수동 CT에 응답하는 것을 목표로 하며 가능한 한 빨리 대응하지만 RFC가 실제로 실행되는 데 훨씬 더 오래 걸릴 수 있습니다. ### 수동 업데이트 CTsRFCs 사용 업데이트하려는 스택 유형에 대한 업데이트 변경 유형이 있는 경우 AMS 작업은 스택 업데이트에 대한 관리 \$1 기타 \$1 기타 RFCs를 거부합니다. ### RFC 스택 삭제 오류 RFC 스택 삭제 실패: 관리 \$1 표준 스택 \$1 스택 \$1 CT 삭제를 사용하는 경우 AMS 스택 이름과 함께 스택에 대한 자세한 이벤트가 CloudFormation 콘솔에 표시됩니다. AMS 콘솔에 있는 이름과 비교하여 스택을 식별할 수 있습니다. CloudFormation 콘솔은 장애 원인에 대한 자세한 내용을 제공합니다. 스택을 삭제하기 전에 스택이 생성된 방법을 고려해야 합니다. AMS CT를 사용하여 스택을 생성하고 스택 리소스를 추가하거나 편집하지 않은 경우 문제 없이 스택을 삭제할 수 있습니다. 그러나 스택에 대해 스택 삭제 RFC를 제출하기 전에 스택에서 수동으로 추가된 리소스를 제거하는 것이 좋습니다. 예를 들어 전체 스택 CT(HA 2 티어)를 사용하여 스택을 생성하는 경우 보안 그룹 - SG1이 포함됩니다. 그런 다음 AMS를 사용하여 다른 보안 그룹인 SG2를 생성하고 전체 스택의 일부로 생성된 SG1의 새 SG2를 참조한 다음 스택 삭제 CT를 사용하여 스택을 삭제하면 SG2에서 참조하므로 SG1이 삭제되지 않습니다. SG1 SG2 **중요** 스택을 삭제하면 원치 않고 예상치 못한 결과가 발생할 수 있습니다. AMS는 이러한 이유로 고객을 대신하여 스택 또는 스택 리소스를 삭제\$1하지 않는 것을 선호합니다. 참고로 AMS는 삭제할 적절한 자동 변경 유형을 사용하여 삭제할 수 없는 사용자 대신(제출된 관리 \$1 기타 \$1 기타 \$1 변경 유형 업데이트) 리소스만 삭제합니다. 추가 고려 사항: 리소스가 '삭제 방지'에 대해 활성화된 경우 AMS는 관리 \$1 기타 \$1 기타 \$1 변경 유형 업데이트를 제출하고 삭제 방지가 제거된 후 자동 CT를 사용하여 해당 리소스를 삭제할 경우 이를 차단 해제하는 데 도움이 될 수 있습니다. 스택에 리소스가 여러 개 있고 스택 리소스의 하위 집합만 삭제하려는 경우 CloudFormation 업데이트 변경 유형을 사용합니다([CloudFormation 수집 스택: 업데이트](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-cfn-ingest-update-col.html) 참조). 관리 \$1 기타 \$1 기타 \$1 변경 유형 업데이트 및 필요한 경우 AMS 엔지니어가 변경 세트를 만드는 데 도움을 줄 수도 있습니다. 드리프트로 인해 CloudFormation Update CT를 사용하는 데 문제가 있는 경우 AMS는 Management \$1 Other \$1 Other \$1 Update를 제출하여 드리프트를 해결하고(AWS CloudFormation Service에서 지원하는 범위까지) 자동 CT, Management/Custom Stack/Stack From CloudFormation Template/Approve Changeset and Update를 사용하여 검증하고 실행할 수 있는 ChangeSet를 제공하는 경우에 도움이 될 수 있습니다. CloudFormation AMS는 예상치 못하거나 예상치 못한 리소스 삭제가 없도록 위의 제한을 유지합니다. 자세한 내용은 [ AWS CloudFormation 문제 해결: 스택 삭제 실패를 참조하세요](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-delete-stack-fails). ### RFC 업데이트 DNS 오류 DNS 호스팅 영역을 업데이트하는 여러 RFCs가 실패할 수 있으며, 일부 RFC는 이유 없이 실패할 수 있습니다. DNS 호스팅 영역(프라이빗 또는 퍼블릭)을 업데이트하기 위해 여러 RFCs를 동시에 생성하면 동일한 스택을 동시에 업데이트하려고 하기 때문에 일부 RFCs가 실패할 수 있습니다. AMS 변경 관리는 스택이 이미 다른 RFCs에 의해 업데이트되고 있기 때문에 스택을 업데이트할 수 없는 RFC를 거부하거나 실패합니다. AMS에서는 한 번에 하나의 RFC를 생성하고 RFC가 성공할 때까지 기다린 후 동일한 스택에 대해 새 RFC를 생성하는 것이 좋습니다. ### RFC IAM 엔터티 오류 AMS는 요구 사항에 맞게 설계된 AMS 계정에 여러 기본 IAM 역할 및 프로필을 프로비저닝합니다. 그러나 가끔 추가 IAM 리소스를 요청해야 할 수 있습니다. 사용자 지정 IAM 리소스를 요청하는 RFCs를 제출하는 프로세스는 수동 RFCs에 대한 표준 워크플로를 따르지만 승인 프로세스에는 적절한 보안 제어가 마련되어 있는지 확인하기 위한 보안 검토도 포함됩니다. 따라서 프로세스는 일반적으로 다른 수동 RFCs보다 오래 걸립니다. 이러한 RFCs의 주기 시간을 줄이려면 다음 지침을 따르세요. IAM 검토의 의미와 기술 표준 및 위험 수락 프로세스에 매핑되는 방법에 대한 자세한 내용은 섹션을 참조하세요[RFC 보안 검토 이해](rfc-security.md). 일반적인 IAM 리소스 요청: + CloudEndure와 같은 주요 클라우드 호환 애플리케이션과 관련된 정책을 요청하는 경우 AMS 사전 승인된 IAM CloudEndure 정책: [WIGs Cloud Endure Landing Zone 예제](samples/wigs-ce-lz-examples.zip) 파일의 압축을 풀고 `customer_cloud_endure_policy.json` **참고** 보다 허용적인 정책을 원하는 경우 CloudArchitect/CSDM과 요구 사항에 대해 논의하고 필요한 경우 정책을 구현하는 RFC를 제출하기 전에 AMS 보안 검토 및 승인을 받습니다. + 기본적으로 계정의 AMS에서 배포한 리소스를 수정하려면 기존 리소스를 변경하는 대신 해당 리소스의 수정된 사본을 요청하는 것이 좋습니다. + 인간 사용자에 대한 권한을 요청하는 경우(사용자에게 권한을 연결하는 대신) 역할에 권한을 연결한 다음 사용자에게 해당 역할을 수임할 수 있는 권한을 부여합니다. 이에 대한 자세한 내용은 [임시 AMS 고급 콘솔 액세스를](https://docs.aws.amazon.com/managedservices/latest/userguide/access-console-temp.html) 참조하세요. + 임시 마이그레이션 또는 워크플로에 대한 예외적인 권한이 필요한 경우 요청에서 해당 권한의 종료 날짜를 제공합니다. + 보안 팀과 요청의 주체에 대해 이미 논의한 경우 CSDM에 최대한 자세히 승인 증거를 제공합니다. AMS가 IAM RFC를 거부하는 경우 거부에 대한 명확한 이유를 제공합니다. 예를 들어 IAM 정책 생성 요청을 거부하고 정책에 대한 부적절한 내용을 설명할 수 있습니다. 이 경우 식별된 변경을 수행하고 요청을 다시 제출할 수 있습니다. 요청 상태에 대한 추가 설명이 필요한 경우 서비스 요청을 제출하거나 CSDM에 문의하십시오. 다음 목록은 IAM RFCs를 검토할 때 AMS가 완화하려고 하는 일반적인 위험을 설명합니다. IAM RFC에 이러한 위험이 있는 경우 RFC가 거부될 수 있습니다. 예외가 필요한 경우 AMS는 보안 팀에 승인을 요청합니다. 이러한 예외를 찾으려면 CSDM과 조정하십시오. **참고** AMS는 어떤 이유로든 계정 내 IAM 리소스에 대한 변경을 거부할 수 있습니다. RFC 거부와 관련된 우려 사항은 서비스 요청을 통해 AMS Operations에 문의하거나 CSDM에 문의하십시오. + 자체 권한을 수정하거나 계정 내 다른 리소스의 권한을 수정할 수 있는 권한과 같은 권한 에스컬레이션. 예시: + 더 많은 권한을 가진 다른 역할과 `iam:PassRole` 함께를 사용합니다. + 역할 또는 사용자로부터 IAM 정책을 연결/분리할 수 있는 권한. + 계정의 IAM 정책 수정. + 관리 인프라의 맥락에서 API를 호출하는 기능입니다. + AMS 서비스를 제공하는 데 필요한 리소스 또는 애플리케이션을 수정할 수 있는 권한. 예시: + 접속, 관리 호스트 또는 EPS 인프라와 같은 AMS 인프라 수정. + 로그 관리 AWS Lambda 함수 또는 로그 스트림 삭제. + 기본 CloudTrail 모니터링 애플리케이션의 삭제 또는 수정입니다. + 디렉터리 서비스 Active Directory(AD)의 수정입니다. + CloudWatch(CW) 경보 비활성화. + 랜딩 존의 일부로 계정에 배포된 보안 주체, 정책 및 네임스페이스의 수정입니다. + 정보 보안을 위태롭게 하는 상태에서 인프라를 생성할 수 있는 권한과 같은 모범 사례를 벗어나는 인프라 배포. 예시: + 퍼블릭 또는 암호화되지 않은 S3 버킷 생성 또는 EBS 볼륨의 퍼블릭 공유. + 퍼블릭 IP 주소의 프로비저닝입니다. + 광범위한 액세스를 허용하도록 보안 그룹을 수정했습니다. + 인프라 및 계정 내 애플리케이션에 대한 데이터 손실, 무결성 손실, 부적절한 구성 또는 서비스 중단을 초래할 수 있는 권한과 같이 애플리케이션에 영향을 미칠 수 있는 권한이 지나치게 광범위합니다. 예시: + `ModifyNetworkInterfaceAttribute` 또는와 같은 APIs를 통해 네트워크 트래픽을 비활성화하거나 리디렉션합니다`UpdateRouteTable`. + 관리형 호스트에서 볼륨을 분리하여 관리형 인프라를 비활성화합니다. + AMS 서비스 설명의 일부가 아니며 AMS에서 지원하지 않는 서비스에 대한 권한. AMS 서비스 설명에 나열되지 않은 서비스는 AMS 계정에서 사용할 수 없습니다. 기능 또는 서비스에 대한 지원을 요청하려면 CSDM에 문의하십시오. + 너무 관대하거나 보수적이거나 잘못된 리소스에 적용되므로 명시된 목표를 충족하지 않는 권한. 예시: + 관련 키에 대한 `s3:PutObject` 권한 없이 필수 KMS 암호화가 있는 S3 버킷에 대한 `KMS:Encrypt` 권한 요청입니다. + 계정에 없는 리소스와 관련된 권한입니다. + RFCs의 설명이 요청과 일치하지 않는 것으로 보이는 IAM RFC입니다. ## “배포” RFC 오류 AMS "배포" 범주 변경 유형(CTs)을 사용하면 다양한 AMS 지원 리소스를 계정에 추가하도록 요청할 수 있습니다. 리소스를 생성하는 대부분의 AMS CTs는 CloudFormation 템플릿을 기반으로 합니다. 고객은 CloudFormation 콘솔을 사용하여 CloudFormation 스택 설명을 기반으로 스택을 나타내는 스택을 빠르게 식별할 CloudFormation수 있습니다. 실패한 스택은 DELETE\$1COMPLETE 상태일 수 있습니다. CloudFormation 스택을 식별하면 이벤트에 생성에 실패한 특정 리소스와 그 이유가 표시됩니다. ### CloudFormation 설명서를 사용하여 문제 해결 대부분의 AMS 프로비저닝 RFCs는 CloudFormation 템플릿을 사용하며이 설명서는 문제 해결에 유용할 수 있습니다. 해당 CloudFormation 템플릿에 대한 설명서를 참조하세요. + 애플리케이션 로드 밸런서 생성 실패: [ AWS::ElasticLoadBalancingV2::LoadBalancer(Application Load Balancer)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-loadbalancer.html) + Auto Scaling 그룹 생성: [ AWS::AutoScaling::AutoScalingGroup(Auto Scaling 그룹)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html) + memcached 캐시 생성: [ AWS::ElastiCache::CacheCluster(캐시 클러스터)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html) + Redis 캐시 생성: [ AWS::ElastiCache::CacheCluster(캐시 클러스터)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html) + DNS 호스팅 영역 생성(DNS 프라이빗/퍼블릭 생성과 함께 사용): [ AWS::Route53::HostedZone(R53 호스팅 영역)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-route53-hostedzone.html) + DNS 레코드 세트 생성(DNS 프라이빗/퍼블릭 생성과 함께 사용): [ AWS::Route53::RecordSet(리소스 레코드 세트)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-route53-recordset.html) + EC2 스택 생성: [ AWS::EC2::Instance(Elastic Compute Cloud)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html) + EFS(Elastic File System): [ AWS::EFS::FileSystem(Elastic File System)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-efs-filesystem.html) + 로드 밸런서 생성: [ AWS::ElasticLoadBalancing::LoadBalancer(Elastic Load Balancer)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-elb.html) + RDS DB 생성: [ AWS::RDS::DBInstance(관계형 데이터베이스)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html) + Amazon S3 생성: [ AWS::S3::Bucket(Simple Storage Service)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html) + 대기열 생성: [ AWS::SQS::Queue(단순 대기열 서비스)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sqs-queues.html) ### RFC 생성 AMIs 오류 Amazon Machine Image(AMI)는 소프트웨어 구성이 기재된 템플릿입니다(예: 운영 체제, 애플리케이션 서버, 애플리케이션). AMI에서 인스턴스를 바로 시작하실 수 있는데, 이 인스턴스는 AMI의 사본으로, 클라우드에서 실행되는 가상 서버입니다. AMIs는 매우 유용하며 EC2 인스턴스 또는 Auto Scaling 그룹을 생성하는 데 필요하지만 몇 가지 요구 사항을 준수해야 합니다. + RFC가 성공하려면에 대해 지정하는 인스턴스가 중지 상태여야 `Ec2InstanceId` 합니다. ASG가 중지된 인스턴스를 종료하므로이 파라미터에 Auto Scaling 그룹(ASG) 인스턴스를 사용하지 마십시오. + AMS Amazon Machine Image(AMI)를 생성하려면 AMS 인스턴스로 시작해야 합니다. 인스턴스를 사용하여 AMI를 생성하려면 먼저 인스턴스가 중지되고 도메인에서 조인 해제되었는지 확인하여 인스턴스를 준비해야 합니다. 자세한 내용은 [ Sysprep을 사용하여 표준 Amazon Machine Image 생성을](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html#23ami-create-standard) 참조하세요. + 새 AMI에 지정하는 이름은 계정 내에서 고유해야 합니다. 그렇지 않으면 RFC가 실패합니다. 이 작업을 수행하는 방법은 [AMI \$1 생성](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html)에 설명되어 있으며, 자세한 내용은 및 [AWS AMI 설계를](https://aws.amazon.com/answers/configuration-management/aws-ami-design/) 참조하세요. **참고** AMI 생성 준비에 대한 자세한 내용은 [AMI \$1 생성을](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html) 참조하세요. ### EC2s 또는 ASGs 오류를 생성하는 RFCs 제한 시간이 있는 EC2 또는 ASG 실패의 경우 AMS는 사용된 AMI가 사용자 지정되었는지 확인할 것을 권장합니다. 그렇다면이 가이드에 포함된 AMI 생성 단계([AMI \$1 생성](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html) 참조)를 참조하여 AMI가 올바르게 생성되었는지 확인하세요. 사용자 지정 AMI를 생성할 때 흔히 발생하는 실수는 가이드의 단계를 따라 Sysprep의 이름을 바꾸거나 호출하는 것이 아닙니다. ### RDS 오류를 생성하는 RFCs Amazon Relational Database Service(RDS) 장애는 RDS를 생성할 때 다양한 엔진을 사용할 수 있으며 각 엔진에는 고유한 요구 사항과 제한이 있기 때문에 여러 가지 이유로 발생할 수 있습니다. AMS RDS 스택을 생성하기 전에 AWS RDS 파라미터 값을 주의 깊게 검토하세요. [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)를 참조하세요. 크기 권장 사항을 포함하여 일반적으로 Amazon RDS에 대한 자세한 내용은 [Amazon Relational Database Service 설명서를](https://aws.amazon.com/documentation/rds/) 참조하세요. ### Amazon S3s 오류를 생성하는 RFCs S3 스토리지 버킷을 생성할 때 발생하는 한 가지 일반적인 오류는 버킷에 고유한 이름을 사용하지 않는 것입니다. 이전에 제출한 것과 동일한 이름의 S3 버킷 CT 생성을 제출한 경우 해당 BucketName에 S3 버킷이 이미 존재하기 때문에 실패합니다. 이는 CloudFormation 스택 이벤트에서 버킷 이름이 이미 사용 중임을 보여주는 콘솔에 자세히 설명되어 있습니다. ## RFC 검증과 실행 오류 비교 RFC 실패 및 관련 메시지는 선택한 RFC에 대한 AMS 콘솔 RFC 세부 정보 페이지의 출력 메시지에서 다릅니다. + 검증 실패 이유는 상태 필드에서만 사용할 수 있습니다. + 실행 실패 이유는 실행 출력 및 상태 필드에서 확인할 수 있습니다. ![\[Request for change details showing rejected status due to no domain trust found.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/rfcReason.png) ## RFC 오류 메시지 나열된 변경 유형(CTs)에 대해 다음 오류가 발생하면 이러한 솔루션을 사용하여 문제의 원인을 찾고 수정할 수 있습니다. `{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}` 다음 문제 해결 옵션을 참조한 후 추가 지원이 필요한 경우 RFC 서신을 통해 AMS를 참여시킵니다. 자세한 내용은 [RFC 서신 및 첨부 파일(콘솔)을 참조하세요](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-gui.html#ex-rfc-correspondence). ### 워크로드 수집(WIGS) 오류 **참고** Windows 및 Linux용 검증 도구를 다운로드하여 온프레미스 서버와 AWS의 EC2 인스턴스에서 직접 실행할 수 있습니다. 이는 *AMS Advanced Application Developer's Guide* [Migrating workloads: Linux pre-ingestion validation](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-linux-validation.html) and [Migrating workloads: Windows pre-ingestion validation](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-win-validation.html)을 통해 찾을 수 있습니다. + EC2 인스턴스가 대상 AMS 계정에 있는지 확인합니다. 예를 들어 AMI를 비 AMS 계정에서 AMS 계정으로 공유한 경우 워크로드 수집 RFC를 제출하기 전에 공유 AMI를 사용하여 AMS 계정에 EC2 인스턴스를 생성해야 합니다. + 인스턴스에 연결된 보안 그룹에 송신 트래픽이 허용되는지 확인합니다. SSM 에이전트는 퍼블릭 엔드포인트에 연결할 수 있어야 합니다. + 인스턴스에 SSM 에이전트와 연결할 수 있는 적절한 권한이 있는지 확인합니다. 이러한 권한은와 함께 제공되며 EC2 콘솔에서 이를 확인할 `customer-mc-ec2-instance-profile`수 있습니다. ![\[EC2 instance details showing IAM role set to customer-mc-ec2-instance-profile.\]](http://docs.aws.amazon.com/ko_kr/managedservices/latest/onboardingguide/images/ec2ConsoleWCircle.png) ### EC2 인스턴스 스택 중지 오류 + 인스턴스가 이미 중지되거나 종료된 상태인지 확인합니다. + EC2 인스턴스가 온라인 상태이고 `InternalError` 오류가 표시되면 AMS가 조사할 서비스 요청을 제출합니다. + 변경 유형 관리 \$1 고급 스택 구성 요소 \$1 EC2 인스턴스 스택 \$1 중지 ct-3mvt2zkyveqj를 사용하여 Auto Scaling 그룹(ASG) 인스턴스를 중지할 수 없습니다. ASG 인스턴스를 중지해야 하는 경우 서비스 요청을 제출합니다. ### EC2 인스턴스 스택 생성 오류 메시지는 CREATION\$1FAILED 상태 이유인 CloudFormation에서 보낸 `InternalError` 것입니다. 다음 단계에 따라 CloudWatch 스택 이벤트의 스택 실패에 대한 세부 정보를 찾을 수 있습니다. + AWS Management 콘솔에서 스택이 생성, 업데이트 또는 삭제되는 동안 스택 이벤트 목록을 볼 수 있습니다. 이 목록에서 실패 이벤트를 찾은 다음 해당 이벤트에 대한 상태 사유를 확인할 수 있습니다. 상태 이유에는 문제를 이해하는 데 도움이 될 수 있는 AWS CloudFormation 또는 특정 서비스의 오류 메시지가 포함될 수 있습니다. + 스택 이벤트 보기에 대한 자세한 내용은 [ AWS Management Console에서 AWS CloudFormation 스택 데이터 및 리소스 보기를 참조하세요](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html). ### EC2 인스턴스 볼륨 복원 오류 AMS는 EC2 인스턴스 볼륨 복원에 실패할 때 내부 문제 해결 RFC를 생성합니다. 이는 EC2 인스턴스 볼륨 복원이 재해 복구(DR)의 중요한 부분이며 AMS가이 내부 문제 해결 RFC를 자동으로 생성하기 때문입니다. 내부 문제 해결 RFC가 생성되면 RFC에 대한 링크를 제공하는 배너가 표시됩니다. 이 내부 문제 해결 RFC는에 RFC 장애에 대한 더 많은 가시성을 제공하며, 동일한 오류로 이어지는 재시도 RFCs를 제출하거나이 장애에 대해 AMS에 수동으로 연락하는 대신 변경 사항을 추적하고 AMS에서 장애를 처리하고 있음을 알 수 있습니다. 또한 AMS 연산자가 요청을 기다리는 대신 RFC 장애에 대해 사전에 작업하므로 변경 사항에 대한 time-to-recovery(TTR) 지표가 줄어듭니다. ## RFC에 대한 도움을 받는 방법 AMS에 문의하여 장애의 근본 원인을 식별할 수 있습니다. AMS 업무 시간은 하루 24시간, 주 7일, 1년 365일입니다. AMS는 도움을 요청할 수 있는 몇 가지 방법을 제공합니다. + 열린 RFC 또는 완료되었지만 잘못된 RFC에 대한 지원이 필요한 경우 RFC 양방향 통신문을 통해 AMS를 참여시킵니다. 자세한 내용은 [RFC 서신 및 첨부 파일(콘솔)을 참조하세요](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-gui.html#ex-rfc-correspondence). + 관리형 환경에 영향을 미치는 AWS 또는 AMS 서비스 성능 문제를 보고하려면 AMS 콘솔을 사용하여 인시던트 보고서를 제출합니다. 자세한 내용은 [인시던트 보고를 참조하세요](https://docs.aws.amazon.com/managedservices/latest/userguide/gui-ex-report-incident.html). AMS 인시던트 관리에 대한 일반적인 정보는 [인시던트 대응](https://docs.aws.amazon.com/managedservices/latest/userguide/sec-incident-response.html)을 참조하세요. + 사용자 또는 리소스 또는 애플리케이션이 AMS로 작업하는 방식에 대한 구체적인 질문이 있거나 인시던트를 에스컬레이션하려면 다음 중 하나 이상을 이메일로 보내십시오. 1. 먼저 서비스 요청 또는 인시던트 보고서 응답이 만족스럽지 않은 경우 CSDM에 ams-csdm@amazon.com으로 이메일을 보냅니다. 1. 다음으로 에스컬레이션이 필요한 경우 AMS Operations Manager에 이메일을 보낼 수 있습니다(하지만 CSDM에서이 작업을 수행할 수 있음). ams-opsmanager@amazon.com 1. 추가 에스컬레이션은 AMS Director에게: ams-director@amazon.com 1. 마지막으로 언제든지 AMS VP: ams-vp@amazon.com에 연결할 수 있습니다.