기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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**
+ [RFCs란 무엇입니까?](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)
# RFCs란 무엇입니까?
변경 요청 또는 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만 지정해야 합니다.
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 Management Console을 통해 직접 변경된 파라미터가 있는 경우 해당 리소스의 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 계속 사용하여 리소스에 대한 업데이트를 수행할 수 있습니까?
사용 가능한 자동 CTs 업데이트를 사용하여 스택 리소스에 대한 업데이트를 항상 수행하는 것이 좋습니다. 사용 가능한 CT 업데이트가 사용 사례를 지원하지 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` 옵션을 제거합니다.
제출 후 30일 이내에 승인되지 않은 경우 **ASAP** "검토 필요" RFCs가 자동으로 거부됩니다.
이 **변경 사항을 예약합니다.**
+ 콘솔: **이 변경 예약** 라디오 버튼을 선택합니다. **시작 시간** 영역이 열립니다. 수동으로 날짜를 입력하거나 일정 위젯을 사용하여 날짜를 선택합니다. 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` 도 도 `RequestedEndTime`아닙니다. 이러한 값은 null로 유지되며 RFC는 ASAP RFC로 처리됩니다.
**참고**
예약된 모든 RFCs 대해 지정되지 않은 종료 시간은 지정된의 시간과 제출된 변경 유형의 `RequestedStartTime` `ExpectedExecutionDurationInMinutes` 속성으로 기록됩니다. 예를 들어 `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: Create EC2 and Create 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
```
**참고**
`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 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)