일반

Q: Amazon Elastic Container Service란 무엇입니까?

Amazon Elastic Container Service(ECS)는 Docker 컨테이너를 지원하는 확장성과 성능이 뛰어난 컨테이너 관리 서비스로서, 이 서비스를 사용하여 Amazon EC2 인스턴스의 관리형 클러스터에서 애플리케이션을 손쉽게 실행할 수 있습니다. Amazon ECS를 사용하면 자체 클러스터 관리 인프라를 설치, 운영 및 확장할 필요가 없습니다. 간단한 API 호출로 컨테이너가 활성화된 애플리케이션을 실행 및 중지하고, 클러스터의 전체 상태를 쿼리하며, 보안 그룹, Elastic Load Balancing, EBS 볼륨, IAM 역할과 같이 여러 친숙한 기능에 액세스할 수 있습니다. 리소스 필요 사항과 가용성 요구 사항에 따라 클러스터 전체에 컨테이너를 배치할 일정을 수립하는 데에도 Amazon ECS를 사용할 수 있습니다. 또는 비즈니스나 애플리케이션의 특정 요구 사항에 맞도록 자체 스케줄러나 타사 스케줄러를 통합할 수 있습니다.

Q: Amazon ECS를 사용해야 하는 이유는 무엇입니까?

Amazon ECS를 사용하면 자체 클러스터 관리 인프라를 설치, 운영, 조정할 필요 없이, 간편하게 컨테이너를 애플리케이션의 빌딩 블록으로 사용할 수 있습니다. Amazon ECS는 Docker 컨테이너를 사용하여 장기 실행 애플리케이션, 서비스 및 배치 프로세스를 예약할 수 있게 해줍니다. Amazon ECS을 사용하면 애플리케이션 가용성을 유지 관리하고 애플리케이션 용량 요구 사항에 따라 컨테이너 규모를 확장하거나 축소할 수 있습니다. Amazon ECS는 Elastic Load Balancing, EBS 볼륨, VPC, IAM과 같은 친숙한 기능과 통합되어 있습니다. 간단한 API로 자체 스케줄러와 통합하여 사용하거나 Amazon ECS를 기존의 소프트웨어 전송 프로세스에 연결할 수 있습니다.

Q: Amazon ECS의 요금은 어떻게 됩니까?

Amazon ECS 사용에 따르는 추가 요금은 없습니다. 애플리케이션을 저장하고 실행하기 위해 생성한 AWS 리소스(예: EC2 인스턴스 또는 EBS 볼륨)에 대한 비용만 지불하면 됩니다. 사용하면서 사용한 만큼만 비용을 지불하고 최소 요금 및 사전 약정은 없습니다.

Q: Amazon ECS는 AWS Elastic Beanstalk와 어떻게 다릅니까?

AWS Elastic Beanstalk는 애플리케이션 관리 플랫폼으로 고객이 쉽게 웹 애플리케이션과 서비스를 배포하고 조정할 수 있도록 해줍니다. 빌딩 블록 프로비저닝(예: EC2, RDS, Elastic Load Balancing, Auto Scaling, CloudWatch), 애플리케이션 배포, 상태 모니터링 등에 신경 쓸 필요가 없어 사용자가 코드 작성에만 집중할 수 있습니다. 배포할 컨테이너 이미지, CPU와 메모리 요구 사항, 포트 매핑, 컨테이너 링크만 지정하면 됩니다.

Elastic Beanstalk이 Amazon ECS 클러스터, 로드 밸런싱, Auto Scaling, 모니터링, 클러스터 전체에 컨테이너 배치와 같은 모든 세부 사항을 자동으로 처리합니다. 컨테이너의 장점을 활용하고 싶지만 컨테이너 이미지 업로드를 통해 개발에서 운영까지 애플리케이션 배포만 간단히 하고 싶다면 Elastic Beanstalk이 최적의 선택입니다. 사용자 지정 애플리케이션 아키텍처를 좀더 미세하게 조정하고 싶다면 Amazon ECS에서 직접 작업하면 됩니다.

Q: Amazon ECS는 AWS Lambda와 어떻게 다릅니까?

Amazon ECS는 확장성이 뛰어난 Docker 컨테이너 관리 서비스로서 이 서비스를 사용하여 Docker 컨테이너에서 실행되는 분산 애플리케이션을 실행하고 관리할 수 있습니다. AWS Lambda는 이벤트 중심의 작업 컴퓨팅 서비스로서 데이터 변경, 웹 사이트 클릭, 다른 AWS 서비스에서 수신되는 메시지 등의 '이벤트'에 대한 응답으로 코드를 실행하므로, 사용자가 컴퓨팅 인프라를 관리할 필요가 없습니다.

Amazon ECS 사용하기

Q: Amazon ECS를 시작하려면 어떻게 해야 합니까?

ECS 사용을 시작하는 방법을 자세히 알아보려면 시작하기 페이지를 참조하십시오.

Q: Amazon ECS는 그 외 다른 컨테이너 유형을 지원합니까?

아니요. Docker는 현재 Amazon ECS에서 지원하는 유일한 컨테이너 플랫폼입니다.

Q: 컨테이너를 시작하려고 하는데, 작업을 시작해야 하는 이유는 무엇입니까?

Docker에서는 애플리케이션을 개별 구성 요소로 분리하도록 권장하는데 Elastic Container Service는 이러한 패턴에 최적화되어 있습니다. 작업에서는 함께 배치하려는 컨테이너 집합(또는 동일한 배치 결정의 일부), 해당 속성 및 연결되는 방식을 정의할 수 있습니다. 작업에는 Amazon ECS가 배치를 결정하는 데 필요한 모든 정보가 포함되어 있습니다. 단일 컨테이너를 시작하려면 작업 정의에 단 한 개의 컨테이너 정의만 포함해야 합니다.

Q: Amazon ECS는 애플리케이션과 서비스를 지원합니까?

예. Amazon ECS 서비스 스케줄러에서 장기 실행 애플리케이션과 서비스를 관리할 수 있습니다. 서비스 스케줄러를 사용하면 애플리케이션 가용성 유지 관리가 가능하여 애플리케이션 용량 요구 사항에 따라 컨테이너 규모를 확장하거나 축소할 수 있습니다. 서비스 스케줄러는 Elastic Load Balancing을 사용하여 트래픽을 컨테이너 전체에 배포할 수 있게 해줍니다. Amazon ECS가 연결된 로드 밸런서에서 컨테이너를 자동으로 등록하거나 등록 해제합니다.

또한, 서비스 스케줄러는 비정상이 된 컨테이너(ELB 상태 검사에 불합격)를 자동으로 복구하거나 실행을 중단하여 애플리케이션을 지원하는 정상 컨테이너를 원하는 수만큼 유지할 수 있습니다.

서비스에서 실행시킬 컨테이너의 수를 변경하여 애플리케이션을 확장하거나 축소할 수 있습니다. 정의를 변경하거나 새로운 이미지를 사용하여 애플리케이션을 업데이트할 수 있습니다. 스케줄러가 신규 정의를 사용하여 자동으로 새로운 컨테이너를 시작하고 이전 버전의 컨테이너는 중지시킵니다(ELB 사용의 경우, ELB 연결이 해제될 때까지 기다립니다).

Q: Amazon ECS에서는 동적 포트 매핑을 지원합니까?

예. Amazon ECS의 서비스를 Elastic Load Balancing(ELB) 서비스의 Application Load Balancer(ALB)와 연결할 수 있습니다. ALB는 인스턴스 포트 세트가 포함된 대상 그룹을 지원합니다. ECS 작업 정의에 동적 포트를 지정할 수 있으며 이를 통해 컨테이너가 EC2 인스턴스에 예약된 경우 미사용 포트를 컨테이너에 제공할 수 있습니다. ECS 스케줄러는 이 포트를 사용하는 Application Load Balancer의 대상 그룹에 작업을 자동으로 추가합니다.

Q: Amazon ECS에서 배치 작업을 지원합니까?

예. Amazon ECS Run 작업을 사용하여 하나 이상의 작업을 동시에 실행할 수 있습니다. Run 작업은 CPU, 메모리, 포트를 비롯하여 작업 요구 사항에 맞는 인스턴스의 작업을 실행시킵니다.

Q: Amazon ECS에서 자체 스케줄러를 사용할 수 있습니까?

ECS에서는 컨테이너 관리 및 오케스트레이션용 오픈 소스 프로젝트 모음인 Blox를 제공합니다. Blox를 사용하면 Amazon ECS의 이벤트를 간편하게 사용하고, 클러스터 상태를 로컬에 저장하며, API를 통해 로컬 데이터 스토어를 쿼리할 수 있습니다. 또한, Blox에는 클러스터 상태 서버를 사용하는 방법을 참조할 수 있는 데몬 스케줄러가 포함되어 있습니다. 자세한 내용은 Blox GitHub 페이지를 참조하십시오.

Q: 자체 AMI를 사용할 수 있습니까?

예. Amazon ECS AMI 사양을 충족시키는 모든 AMI를 사용할 수 있습니다. Amazon ECS가 활성화된 Amazon Linux AMI에서 시작하는 것을 권장합니다. Amazon ECS와 호환 가능한 파트너 AMI도 사용할 수 있습니다. 설명서에 나와 있는 Amazon ECS AMI 사양을 확인하시기 바랍니다.

Q: Amazon Elastic Container Registry에서 끌어오도록 내 컨테이너 인스턴스를 구성하려면 어떻게 해야 합니까?

Amazon ECR은 Amazon ECS와 통합되어 Amazon ECS에서 실행되는 애플리케이션에 대한 컨테이너 이미지를 손쉽게 저장, 실행 및 관리할 수 있습니다. 작업 정의에 Amazon ECR 리포지토리를 지정하고 AmazonEC2ContainerServiceforEC2Role을 인스턴스에 연결하기만 하면 됩니다. 그러면 Amazon ECS에서 애플리케이션에 적합한 이미지를 가져옵니다.

Q: AWS Fargate는 Amazon ECS와 어떻게 연동됩니까?

Fargate에서는 서버 프로비저닝, 클러스터 관리, 오케스트레이션이라는 개념이 모두 필요 없습니다. Amazon ECS는 Fargate에서 프로비저닝한 컨테이너를 사용하여 자동으로 컨테이너를 확장하고, 로드 밸런싱하며, 일정을 관리하여 가용성을 확보함으로써 컨테이너식 애플리케이션을 좀 더 쉽게 구축하고 운영하는 방법을 제공합니다.

Q: Amazon ECS만 사용할지 AWS Fargate와 함께 사용할지 어떻게 선택해야 합니까?

Amazon ECS에서는 Fargate 기술을 지원하며 고객은 AWS Fargate를 사용하여 EC2 인스턴스를 프로비저닝하거나 관리할 필요 없이 컨테이너를 시작하도록 선택할 수 있습니다. AWS Fargate는 AWS에서 컨테이너를 시작 및 실행하는 가장 쉬운 방법입니다. 규정 준수 및 거버넌스 요구 사항을 준수하거나 좀 더 폭넓은 사용자 지정 옵션을 지원하기 위해 EC2 인스턴스에 대한 제어를 강화해야 하는 고객은 Fargate 없이 ECS로 EC2 인스턴스를 시작하도록 선택할 수 있습니다.

보안 및 규정 준수

Q: Amazon ECS는 다른 고객에게 속한 컨테이너를 어떻게 격리합니까?

Amazon ECS는 고객이 제어하는 Amazon EC2 인스턴스에서 실행되도록 컨테이너를 예약하거나 AWS Fargate를 통해 실행하고 EC2 고객에게 적용되는 것과 동일한 격리 제어와 규정 준수에 따라 구축합니다. 컴퓨팅 인스턴스는 지정된 IP 범위에 따라 Virtual Private Cloud(VPC)에 위치합니다. 사용자가 인터넷에 공개할 인스턴스와 비공개할 인스턴스를 지정할 수 있습니다.

  • 고객의 EC2 인스턴스는 ECS 서비스에 액세스하기 위해 IAM 역할을 사용합니다.
  • 고객의 ECS 작업은 서비스와 리소스에 액세스하기 위해 IAM 역할을 사용합니다.
  • 보안 그룹 및 네트워크 ACL을 통해 인스턴스에 대한 인바운드 및 아웃바운드 네트워크 액세스를 통제할 수 있습니다.
  • 업계 표준 암호화된 IPsec VPN 연결을 통해 기존 IT 인프라를 VPC 리소스에 연결할 수 있습니다.
  • EC2 리소스를 전용 인스턴스로 프로비저닝할 수 있습니다. 전용 인스턴스는 격리 기능을 강화하기 위해 단일 고객에게 배정된 전용 하드웨어에서 실행되는 Amazon EC2 인스턴스입니다.

Q: 내 컨테이너 인스턴스에 추가적인 보안 구성과 격리 프레임워크를 적용할 수 있습니까?

예. Amazon EC2 고객은 컨테이너 인스턴스의 운영 체제에 대한 루트 액세스 권한이 있으므로 모니터링, 패치 관리, 로그 관리, 호스트 침입 탐지와 같은 보안 역량 강화를 위한 소프트웨어 구성 요소를 추가로 로드 및 구성할 수 있을 뿐 아니라 운영 체제의 보안 설정에 대한 소유권도 가지고 있습니다.

Q: 다른 보안 설정으로 컨테이너 인스턴스를 실행하거나 다른 환경의 다른 작업을 분리할 수 있습니까?

예. 원하는 도구를 사용하여 다른 컨테이너 인스턴스를 구성할 수 있습니다. Amazon ECS를 사용하면 클러스터와 대상 지정 실행을 생성하여 다른 컨테이너 인스턴스에 작업을 배치할 수 있습니다.

Q: Amazon ECS는 프라이빗 소스 또는 내부 소스에서 Docker 이미지를 검색하는 기능을 지원합니까?

예. 고객은 VPC 내 프라이빗 Docker 이미지 레지스트리에 액세스하거나 Amazon ECR과 같이 VPC 외부에서 액세스할 수 있는 레지스트리에 액세스하도록 컨테이너 인스턴스를 구성할 수 있습니다.

Q: ECS 작업에 대한 IAM 역할을 구성하려면 어떻게 해야 합니까?

먼저 'Amazon EC2 Container Service Task Role’ 서비스 역할을 사용해 정책에 필요한 권한을 추가하여 작업에 사용할 IAM 역할을 생성해야 합니다. 새로운 작업 정의 파일 또는 작업 정의 수정 파일을 생성하였으면, 이제 [Task Role] 드롭다운 메뉴에서 선택하거나 JSON 형식의 'taskRoleArn'을 사용하여 역할을 지정할 수 있습니다.

Q: Amazon ECS가 준수하는 규정 준수 프로그램은 무엇입니까?

Amazon ECS는 PCI DSS 레벨 1, ISO 9001, ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3 및 HIPAA 적격 서비스를 위한 표준을 충족합니다.

자세한 내용은 AWS 규정 준수 페이지를 참조하십시오.

Q: Amazon ECS를 PHI(개인 건강 정보) 및 기타 HIPAA 규제 대상 워크로드에 사용할 수 있습니까?

예. Amazon ECS는 HIPAA 적격 서비스입니다. AWS와 BAA(Business Associate Addendum)를 이행한 경우 AWS Fargate 시작 유형 또는 Amazon EC2 컴퓨팅 인스턴스에 배포된 Docker 컨테이너에서 Amazon ECS를 사용하여 암호화된 PHI(개인 건강 정보)를 처리할 수 있습니다.

자세한 내용은 HIPAA 규정 준수에 관한 AWS 페이지를 참조하십시오. PHI를 처리, 저장 또는 전송할 계획이지만 AWS와 BAA를 체결하지 않은 경우, AWS로 문의하여 자세한 내용을 확인해 주십시오.

Q: Amazon ECS를 미국 정부 규제 대상 워크로드 또는 민감한 CUI(Controlled Unclassified Information) 처리에 사용할 수 있습니까?

예. AWS GovCloud(US) 리전을 사용하면 Amazon ECS로 관리되는 컨테이너 및 클러스터에서 컨테이너를 통해 중요한 데이터 및 규제 워크로드에 대한 요구 사항을 충족할 수 있습니다.

자세한 내용은 AWS GovCloud에 관한 AWS 페이지를 참조하십시오.

서비스 수준 계약(SLA)

Q: Amazon ECS SLA 보장이란 무엇입니까?

AWS 컴퓨팅 SLA에서는 Amazon ECS에 대해 최소 99.99%의 월간 가동률을 보장합니다.

Q: SLA 서비스 크레딧을 수령할 자격이 있는지 어떻게 알 수 있습니까?

같은 리전 내에서 작업을 실행하고 있는 하나 이상의 가용 영역의 월간 가동률이 월별 청구 주기 동안 99.99%보다 낮은 경우, 컴퓨팅 SLA에 따라 AWS ECS의 SLA 크레딧 지급 대상이 됩니다.

SLA 이용 약관과 요청 제출 방법에 대한 자세한 내용은 컴퓨팅 SLA 세부 정보 페이지를 참조하십시오.

새로운 ARN과 ID 형식으로 전환

Q: 변경 사항은 무엇입니까?

2018년 11월 15일부터 Amazon ECS 리소스는 새로운 Amazon 리소스 이름(ARN) 및 식별자(ID) 형식으로 전환합니다. Amazon 리소스 이름 형식 변경은 ECS 태스크, ECS 컨테이너 인스턴스 및 ECS 서비스에 영향을 주게 됩니다. 식별자 형식 변경은 ECS 태스크와 ECS 컨테이너 인스턴스에 영향을 주게 됩니다. 이러한 변경으로 최근에 출시된 태깅과 비용 할당 기능이 활성화됩니다.

오늘부터 ECS 리소스에서 새로운 태깅 기능을 사용하고 새로운 ARN 및 ID 형식을 도입하도록 옵트인할 수 있습니다. 옵트인하면, 새로운 ARN 및 ID 형식이 새로 생성하는 리소스에 적용됩니다. 기존 리소스에는 영향을 주지 않으며 기존 ARN 및 ID가 유지됩니다. 지침은 이 설명서를 참조하십시오.

Q: 이것이 제게 미치는 영향은 무엇입니까?

대부분의 경우 새로운 형식을 처리하기 위해 시스템 변경을 할 필요가 없습니다. AWS 리소스를 관리할 때 콘솔만을 사용하는 경우에는 영향을 받지 않으며 새로운 ARN 및 ID 형식을 사용하도록 설정을 업데이트해야 합니다. API, SDK 또는 AWS CLI를 통해 AWS 리소스와 상호 작용하는 경우에는, 사용자의 소프트웨어가 리소스 ARN 또는 ID를 확인하거나 유지할 때 ARN 또는 ID 형식을 가정하는지 아닌지에 따라 영향을 받을 수도 있습니다. 이 경우, 새 형식을 처리할 수 있도록 시스템을 업데이트해야 할 수 있습니다.

일부 장애 모드는 다음을 포함할 수 있습니다.

시스템에서 정규식을 사용하여 ARN 또는 ID 형식을 확인하거나 이를 구문 분석하여 정보를 추출하는 경우, 새 형식을 발견하게 되면 오류가 발생할 수 있습니다.

데이터베이스 스키마에서 예상하는 ARN 또는 ID 길이가 있는 경우, 이를 저장하지 못할 수 있습니다. 특히 새로운 ARN은 더 많은 정보를 포함하므로 더 깁니다. 새로운 ID는 더 짧습니다.

Q: 이것이 기존 리소스에 영향을 미칩니까?

아니요. 새로운 형식으로 옵트인한 후 생성된 리소스만 새로운 형식을 갖습니다. 일단 리소스에 ARN/ID(이전 또는 신규)가 할당되면, 이후에 수행하는 옵트인이나 옵트아웃 작업과 관계없이 수명 주기에 걸쳐 ARN/ID를 유지합니다. 예를 들어 옵트인하기 전에 기존 ECS 서비스가 있다면 해당 ECS 서비스는 사용자가 옵트인하더라도 기존 ARN/ID를 유지합니다. 옵트인한 후에 해당 ECS 서비스에서 시작한 새로운 태스크는 새로운 ARN을 갖게 됩니다.

Q: 어떤 ECS 리소스 ARN이 변경됩니까?

ARN 변경은 ECS 서비스, ECS 태스크 및 ECS 컨테이너 인스턴스라는 3가지 리소스에 영향을 미칩니다.

Q: 새로운 ARN은 어떤 형태입니까?

ECS 컨테이너 인스턴스, 서비스 및 태스크용 새로운 ARN에는 클러스터 이름이 포함되며 아래 표와 같습니다.

image1

Q: Q: 어떤 ECS 리소스 ID가 변경됩니까?

ID 변경은 ECS 태스크와 ECS 컨테이너 인스턴스라는 2가지 리소스에 영향을 미칩니다.

Q: 새로운 ID는 어떤 형태입니까?

새로운 ID는 길이가 더 짧으며(32자) 하이픈을 포함하지 않습니다. 기존 및 새로운 ID의 예는 아래 표를 참조하십시오.

image2

Q: 옵트인을 완료했습니다. 리소스를 태깅할 수 있도록 새로운 형식으로 전환하려면 어떻게 해야 합니까?

연속성을 보장하기 위해 모든 기존 ECS 리소스는 수명 주기에 걸쳐 ARN 및 ID를 유지합니다. 즉, 새로 생성되는 리소스만 새로운 형식을 갖게 됩니다. 서비스에서 실행 중인 기존 태스크를 전환하려면 새로운 서비스 배포를 트리거해야 합니다. ECS 서비스를 전환하려면 기존 ECS 서비스를 삭제하고 다시 생성하면 됩니다. 마지막으로 ECS 컨테이너 인스턴스를 전환하려면 컨테이너 인스턴스를 드레인하고 새로운 컨테이너 인스턴스를 등록해야 합니다.

Q 새로운 형식을 채택할 수 있는 마감일은 언제입니까?

2019년 12월 말까지 API 및 EC2 콘솔을 통해 새로운 ARN/ID를 사용하도록 옵트인할 수 있습니다. 모든 계정에서 테스트를 위해 필요에 따라 옵트인하고 옵트아웃할 수 있습니다. 2020년 1월 1일부터는 형식을 전환하는 옵션이 더는 제공되지 않으며 새로 생성되는 ECS 리소스는 모두 새로운 ARN 및 ID를 받게 됩니다.

Q: 새로운 계정은 자동으로 옵트인됩니까?

2019년 3월 31일까지는 새로 생성되는 모든 AWS 계정에서는 계속해서 현재 형식을 기본 설정으로 사용하게 됩니다. 2019년 4월 1일부터는 새로 생성되는 모든 계정이 자동으로 옵트인되지만, 2019년 12월 31일까지 옵트아웃 옵션이 유지됩니다.

Q: 새로운 ARN/ID를 받기 위해 옵트인 및 옵트아웃하려면 어떻게 해야 합니까?

전환 기간(지금부터 2019년 12월 말까지) 동안 새로운 ECS API 또는 EC2 콘솔을 사용해 새로운 형식을 받도록 옵트인할 수 있습니다. 지침은 이 설명서에 나와 있습니다.

Q: 계정에서 특정 IAM 사용자 또는 IAM 역할만 옵트인할 수 있습니까?

예. 특정 IAM 역할 또는 IAM 사용자를 옵트인할 수 있습니다. IAM 역할 또는 IAM 사용자가 생성한 리소스는 리소스가 생성된 시점에 리소스를 생성한 사용자 또는 역할의 옵트인 상태를 기준으로 ARN/ID 형식을 받게 됩니다. 또한, 루트 사용자를 옵트인 또는 옵트아웃하면, IAM 사용자 또는 역할이 자신의 옵트인 상태를 명시적으로 재정의하지 않는 한 변경 사항이 전체 AWS 계정에 적용됩니다.

Q: 아무런 조치도 취하지 않으면 어떻게 됩니까?

전환 기간에 새로운 형식으로 옵트인하지 않으며, 2020년 1월 1일부터 자동으로 새로운 형식을 받기 시작합니다. 이 방식은 권장하지 않습니다. 전환 기간에 미리 새로운 형식을 테스트하여 잠재적 문제를 파악하고 해결하는 것이 좋습니다.

Q: 2019년 12월 31일 이후에 생성되는 리소스에 기존 ARN/ID를 계속 사용하려면 어떻게 해야 합니까?

안타깝게도 2020년 1월 1일부터 새로 생성되는 모든 리소스는 새로운 ARN 및 ID 형식을 받게 됩니다. 이를 통해 태깅 및 비용 할당과 같은 현재 및 향후 ECS 기능을 활용할 수 있습니다.

Q: 전환 기간 동안 새로운 ARN/ID로 옵트인한 다음 다시 옵트아웃하는 경우 새로운 형식으로 생성한 리소스는 어떻게 됩니까?

일단 리소스에 ARN/ID가 할당되면 해당 ARN/ID는 변경되지 않습니다. 새로운 ARN/ID로 생성된 리소스는 이후의 작업과 관계없이 새로운 ARN/ID를 유지합니다. 새로운 ARN/ID를 제거하는 유일한 방법은 해당 리소스를 삭제 또는 종료하는 것입니다. 이러한 이유로 작업 시 주의를 기울이고, 도구 및 자동화 테스트를 완료할 때까지 새로운 형식으로 주요 리소스를 생성하지 마십시오.

Q: 전환 기간이 종료되기 전까지 내 시스템이 정상적으로 작동하지 않으면 어떻게 해야 합니까?

전환 기간에 시스템이 정상적으로 작동하지 않는 경우, 일시적으로 새로운 형식에서 옵트아웃한 후 시스템을 수정하십시오. 계정 설정과 관계없이 2020년 1월 1일부터 모든 새 리소스는 새로운 ARN 및 ID 형식을 받게 되므로, 전환 기간이 종료되기 전에 새로운 ARN 및 ID 형식으로 시스템을 테스트하는 것이 중요합니다. 좀 더 일찍 테스트하고 옵트인하면 도구와 워크플로를 수정할 충분한 시간을 확보하고 시스템에 미치는 영향을 최소화할 수 있습니다.

Q: 전환 기간에 여러 리전에서 리소스를 시작하는 경우에는 어떤 일이 발생합니까?

리전별로 옵트인할 수 있습니다. 즉, 옵트인 상태가 다른 리전이 혼합되어 있을 수 있습니다. Amazon ECS에서 전환 기간에 새로운 리전을 출시하더라도, 해당 리전은 기존 리전과 마찬가지로 작동합니다. 다시 말해 2019년 12월 31일까지는 새로운 ARN 형식과 기존 ARN 형식 중에 선택할 수 있습니다.

Amazon ECS 시작하기

Amazon ECS 콘솔로 이동하기
시작할 준비가 되셨습니까?
가입하기
추가 질문이 있으십니까?
AWS에 문의하기