AMS의 RFC 오류 문제 해결 - AMS 고급 사용 설명서
“관리” RFC 오류“배포” RFC 오류RFC 검증과 실행 오류 비교RFC 오류 메시지RFC에 대한 도움을 받는 방법

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

AMS의 RFC 오류 문제 해결

CloudFormation 설명서를 통해 많은 AMS 프로비저닝 RFC 실패를 조사할 수 있습니다. AWS CloudFormation 문제 해결: 오류 문제 해결을 참조하세요.

추가 문제 해결 제안은 다음 섹션에 나와 있습니다.

AMS의 “관리” RFC 오류

AMS "관리" 범주 변경 유형(CTs)을 사용하면 리소스에 대한 액세스를 요청하고 기존 리소스를 관리할 수 있습니다. 이 섹션에서는 몇 가지 일반적인 문제를 설명합니다.

RFC 액세스 오류

  • RFC에 지정한 사용자 이름과 FQDN이 올바르고 도메인에 존재하는지 확인합니다. FQDN을 찾는 데 도움이 필요하면 FQDN 찾기를 참조하세요.

  • 액세스를 위해 지정한 스택 ID가 EC2-related 스택인지 확인합니다. ELB 및 Amazon Simple Storage Service(S3)와 같은 스택은 액세스 RFCs의 대상이 아니며, 대신 읽기 전용 액세스 역할을 사용하여 이러한 스택 리소스에 액세스합니다. 스택 ID 찾기에 대한 도움말은 스택 IDs.

  • 제공한 스택 ID가 올바르고 관련 계정에 속하는지 확인합니다.

다른 액세스 RFC 실패에 대한 도움말은 액세스 관리를 참조하세요.

YouTube 동영상: 거부 및 실패를 방지하기 위해 변경 요청(RFC)을 올바르게 제기하려면 어떻게 해야 합니까?

RFC(수동) CT 예약 오류

대부분의 변경 유형은 ExecutionMode=Automated이지만 일부는 ExecutionMode=Manual이며 RFC 실패를 방지하기 위해 변경 유형을 예약하는 방법에 영향을 미칩니다.

ExecutionMode=ManualRFCs는 AMS 콘솔을 사용하여 RFC를 생성하는 경우 향후 최소 24시간 동안 실행되도록 설정해야 합니다. 이 주의 사항은 AMS API/CLI에는 적용되지 않지만 최소 8시간 전에 수동 RFCs를 예약하는 것이 중요합니다.

AMS는 4시간 이내에 수동 CT에 응답하는 것을 목표로 하며 가능한 한 빨리 대응하지만 RFC가 실제로 실행되는 데 훨씬 더 오래 걸릴 수 있습니다.

수동 업데이트 CTsRFCs 사용

업데이트하려는 스택 유형에 대한 업데이트 변경 유형이 있는 경우 AMS 작업은 스택 업데이트에 대한 관리 | 기타 | 기타 RFCs를 거부합니다.

RFC 스택 삭제 오류

RFC 스택 삭제 실패: 관리 | 표준 스택 | 스택 | CT 삭제를 사용하는 경우 AMS 스택 이름을 사용하여 스택에 대한 자세한 이벤트가 CloudFormation 콘솔에 표시됩니다. AMS 콘솔에 있는 이름과 비교하여 스택을 식별할 수 있습니다. CloudFormation 콘솔은 장애 원인에 대한 자세한 내용을 제공합니다.

스택을 삭제하기 전에 스택이 생성된 방법을 고려해야 합니다. AMS CT를 사용하여 스택을 생성하고 스택 리소스를 추가하거나 편집하지 않은 경우 문제 없이 스택을 삭제할 수 있습니다. 그러나 스택에 대해 스택 RFC 삭제를 제출하기 전에 스택에서 수동으로 추가된 리소스를 제거하는 것이 좋습니다. 예를 들어 전체 스택 CT(HA 2 티어)를 사용하여 스택을 생성하는 경우 보안 그룹 - SG1이 포함됩니다. 그런 다음 AMS를 사용하여 다른 보안 그룹 SG2를 생성하고 전체 스택의 일부로 생성된 SG1에서 새 SG2를 참조한 다음 스택 삭제 CT를 사용하여 스택을 삭제하면 SG2에서 참조하므로 SG1이 삭제되지 않습니다. SG2

중요

스택을 삭제하면 원치 않고 예상치 못한 결과가 발생할 수 있습니다. AMS는 이러한 이유로 고객을 대신하여 스택 또는 스택 리소스를 삭제*하지 않는 것을 선호합니다. AMS는 삭제하려는 적절한 자동 변경 유형을 사용하여 삭제할 수 없는 사용자 대신(제출된 관리 | 기타 | 기타 | 변경 유형 업데이트) 리소스만 삭제합니다. 추가 고려 사항:

  • 리소스가 '삭제 방지'에 대해 활성화된 경우 AMS는 관리 | 기타 | 기타 | 변경 유형 업데이트를 제출하고 삭제 방지가 제거된 후 자동 CT를 사용하여 해당 리소스를 삭제할 경우 이를 차단 해제하는 데 도움이 될 수 있습니다.

  • 스택에 여러 리소스가 있고 스택 리소스의 하위 집합만 삭제하려는 경우 CloudFormation 업데이트 변경 유형을 사용합니다(CloudFormation 수집 스택: 업데이트 참조). 관리 | 기타 | 기타 | 변경 유형 업데이트도 제출할 수 있으며 필요한 경우 AMS 엔지니어가 변경 세트를 만드는 데 도움을 줄 수 있습니다.

  • 드리프트로 인해 CloudFormation Update CT를 사용하는 데 문제가 있는 경우 관리 | 기타 | 기타 | 업데이트를 제출하여 드리프트를 해결하고(AWS CloudFormation Service에서 지원하는 범위까지) 자동 CT, CloudFormation 템플릿에서 관리/사용자 지정 스택/스택/변경 세트 승인 및 업데이트를 사용하여 검증하고 실행할 수 있는 ChangeSet를 제공하면 AMS가 도움이 될 수 있습니다. CloudFormation

AMS는 예상치 못하거나 예상치 못한 리소스 삭제가 없도록 위의 제한을 유지합니다.

자세한 내용은 AWS CloudFormation 문제 해결: 스택 삭제 실패를 참조하세요.

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 보안 검토 이해.

일반적인 IAM 리소스 요청:

  • CloudEndure와 같은 주요 클라우드 호환 애플리케이션과 관련된 정책을 요청하는 경우 AMS 사전 승인된 IAM CloudEndure 정책: WIGs Cloud Endure Landing Zone 예제 파일의 압축을 풀고 customer_cloud_endure_policy.json

    참고

    보다 허용적인 정책을 원하는 경우 CloudArchitect/CSDM과 요구 사항에 대해 논의하고 필요한 경우 정책을 구현하는 RFC를 제출하기 전에 AMS 보안 검토 및 승인을 받습니다.

  • 기본적으로 계정의 AMS에서 배포한 리소스를 수정하려면 기존 리소스를 변경하는 대신 해당 리소스의 수정된 사본을 요청하는 것이 좋습니다.

  • 인간 사용자에 대한 권한을 요청하는 경우(사용자에게 권한을 연결하는 대신) 역할에 권한을 연결한 다음 사용자에게 해당 역할을 수임할 수 있는 권한을 부여합니다. 이에 대한 자세한 내용은 임시 AMS 고급 콘솔 액세스를 참조하세요.

  • 임시 마이그레이션 또는 워크플로에 대한 예외적인 권한이 필요한 경우 요청에서 해당 권한의 종료 날짜를 제공합니다.

  • 요청의 주체에 대해 보안 팀과 이미 논의한 경우 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_COMPLETE 상태일 수 있습니다. CloudFormation 스택을 식별하면 이벤트에 생성에 실패한 특정 리소스와 이유가 표시됩니다.

CloudFormation 설명서를 사용하여 문제 해결

대부분의 AMS 프로비저닝 RFCs는 CloudFormation 템플릿을 사용하며이 설명서는 문제 해결에 유용할 수 있습니다. 해당 CloudFormation 템플릿에 대한 설명서를 참조하세요.

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 생성을 참조하세요.

  • 새 AMI에 지정하는 이름은 계정 내에서 고유해야 합니다. 그렇지 않으면 RFC가 실패합니다. 이 작업을 수행하는 방법은 AMI | 생성에 설명되어 있으며, 자세한 내용은 및 AWS AMI 설계를 참조하세요.

참고

AMI 생성 준비에 대한 자세한 내용은 AMI | 생성을 참조하세요.

EC2s 또는 ASGs 오류를 생성하는 RFCs

제한 시간이 있는 EC2 또는 ASG 실패의 경우 AMS는 사용된 AMI가 사용자 지정되었는지 확인할 것을 권장합니다. 그렇다면이 가이드에 포함된 AMI 생성 단계(AMI | 생성 참조)를 참조하여 AMI가 올바르게 생성되었는지 확인하세요. 사용자 지정 AMI를 생성할 때 흔히 발생하는 실수는 가이드의 단계를 따라 Sysprep의 이름을 바꾸거나 호출하는 것이 아닙니다.

RDS 오류를 생성하는 RFCs

Amazon Relational Database Service(RDS) 장애는 RDS를 생성할 때 다양한 엔진을 사용할 수 있으며 각 엔진에는 고유한 요구 사항과 제한이 있기 때문에 여러 가지 이유로 발생할 수 있습니다. AMS RDS 스택을 생성하기 전에 AWS RDS 파라미터 값을 주의 깊게 검토하세요. CreateDBInstance를 참조하세요.

크기 권장 사항을 포함하여 일반적으로 Amazon RDS에 대한 자세한 내용은 Amazon Relational Database Service 설명서를 참조하세요.

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.

RFC 오류 메시지

나열된 변경 유형(CTs)에 대해 다음 오류가 발생하면 이러한 솔루션을 사용하여 문제의 원인을 찾고 수정할 수 있습니다.

{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}

다음 문제 해결 옵션을 참조한 후 추가 지원이 필요한 경우 RFC 서신을 통해 AMS를 참여시키거나 서비스 요청을 생성합니다. 자세한 내용은 RFC 서신 및 연결(콘솔) 및 AMS에서 서비스 요청 생성을 참조하세요.

워크로드 수집(WIGS) 오류

참고

Windows 및 Linux용 검증 도구를 다운로드하여 온프레미스 서버와 AWS의 EC2 인스턴스에서 직접 실행할 수 있습니다. AMS 고급 애플리케이션 개발자 안내서 워크로드 마이그레이션: Linux 사전 수집 검증 및 워크로드 마이그레이션: Windows 사전 수집 검증을 통해 확인할 수 있습니다.

  • EC2 인스턴스가 대상 AMS 계정에 있는지 확인합니다. 예를 들어 비 AMS 계정에서 AMS 계정으로 AMI를 공유한 경우 워크로드 수집 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.

EC2 인스턴스 스택 중지 오류

  • 인스턴스가 이미 중지되거나 종료된 상태인지 확인합니다.

  • EC2 인스턴스가 온라인 상태이고 InternalError 오류가 표시되면 AMS가 조사할 서비스 요청을 제출합니다.

  • 변경 유형 관리 | 고급 스택 구성 요소 | EC2 인스턴스 스택 | ct-3mvt2zkyveqj 중지를 사용하여 Auto Scaling 그룹(ASG) 인스턴스를 중지할 수 없습니다. ASG 인스턴스를 중지해야 하는 경우 서비스 요청을 제출합니다.

EC2 인스턴스 스택 생성 오류

메시지는 CREATION_FAILED 상태 이유인 CloudFormation에서 보낸 InternalError 것입니다. 다음 단계에 따라 CloudWatch 스택 이벤트의 스택 실패에 대한 세부 정보를 찾을 수 있습니다.

  • AWS Management 콘솔에서 스택이 생성, 업데이트 또는 삭제되는 동안 스택 이벤트 목록을 볼 수 있습니다. 이 목록에서 실패 이벤트를 찾은 다음 해당 이벤트에 대한 상태 사유를 확인할 수 있습니다.

    상태 이유에는 문제를 이해하는 데 도움이 될 수 있는 AWS CloudFormation 또는 특정 서비스의 오류 메시지가 포함될 수 있습니다.

  • 스택 이벤트 보기에 대한 자세한 내용은 AWS Management Console에서 AWS CloudFormation 스택 데이터 및 리소스 보기를 참조하세요.

EC2 인스턴스 볼륨 복원 오류

AMS는 EC2 인스턴스 볼륨 복원에 실패할 때 내부 문제 해결 RFC를 생성합니다. 이는 EC2 인스턴스 볼륨 복원이 재해 복구(DR)의 중요한 부분이며 AMS가이 내부 문제 해결 RFC를 자동으로 생성하기 때문입니다.

내부 문제 해결 RFC가 생성되면 RFC에 대한 링크를 제공하는 배너가 표시됩니다. 이 내부 문제 해결 RFC는에 RFC 장애에 대한 더 많은 가시성을 제공하며, 동일한 오류로 이어지는 재시도 RFCs를 제출하거나이 장애에 대해 AMS에 수동으로 연락하는 대신 변경 사항을 추적하고 AMS에서 장애를 처리하고 있음을 알 수 있습니다. 또한 AMS 운영자가 요청을 기다리는 대신 RFC 장애에 대해 사전에 작업하므로 변경 사항에 대한 TTR(time-to-recovery) 지표가 줄어듭니다.

RFC에 대한 도움을 받는 방법

AMS에 문의하여 실패의 근본 원인을 식별할 수 있습니다. AMS 업무 시간은 하루 24시간, 주 7일, 1년 365일입니다.

AMS는 도움을 요청하거나 서비스 요청을 할 수 있는 몇 가지 방법을 제공합니다.

  • 정보나 조언을 요청하거나 AMS 관리형 IT 서비스에 액세스하거나 AMS에서 추가 서비스를 요청하려면 AMS 콘솔을 사용하여 서비스 요청을 제출합니다. 자세한 내용은 서비스 요청 생성을 참조하세요. AMS 서비스 요청에 대한 일반 정보는 서비스 요청 관리를 참조하세요.

  • 관리형 환경에 영향을 미치는 AWS 또는 AMS 서비스 성능 문제를 보고하려면 AMS 콘솔을 사용하여 인시던트 보고서를 제출합니다. 자세한 내용은 인시던트 보고를 참조하세요. AMS 인시던트 관리에 대한 일반적인 정보는 인시던트 대응을 참조하세요.

  • 사용자 또는 리소스 또는 애플리케이션이 AMS로 작업하는 방식에 대한 구체적인 질문이 있거나 인시던트를 에스컬레이션하려면 다음 중 하나 이상을 이메일로 보내십시오.

    1. 먼저 서비스 요청 또는 인시던트 보고서 응답이 만족스럽지 않은 경우 CSDM에 ams-csdm@amazon.com으로 이메일을 보냅니다.

    2. 다음으로 에스컬레이션이 필요한 경우 AMS Operations Manager에 이메일을 보낼 수 있습니다(하지만 CSDM에서이 작업을 수행할 수 있음). ams-opsmanager@amazon.com

    3. 추가 에스컬레이션은 AMS Director에게: ams-director@amazon.com

    4. 마지막으로 언제든지 AMS VP: ams-vp@amazon.com에 연결할 수 있습니다.