# Amazon ECS에 대한 AWS Fargate 아키텍트
AWS Fargate는 Amazon EC2 인스턴스의 서버나 클러스터를 관리할 필요 없이 [컨테이너](https://aws.amazon.com/containers/)를 실행하기 위해 Amazon ECS에 사용할 수 있는 기술입니다. AWS Fargate를 사용하면 더 이상 컨테이너를 실행하기 위해 가상 머신의 클러스터를 프로비저닝, 구성 또는 조정할 필요가 없습니다. 따라서 서버 유형을 선택하거나, 클러스터를 조정할 시점을 결정하거나, 클러스터 패킹을 최적화할 필요가 없습니다.
Fargate에서 태스크와 서비스를 실행할 경우 애플리케이션을 컨테이너에 패키징하고, CPU 및 메모리 요구 사항을 지정한 다음, 네트워킹 및 IAM 정책을 정의하고, 애플리케이션을 시작합니다. 각 Fargate 태스크에는 자체 격리 경계가 있으며 다른 태스크와 기본 커널, CPU 리소스, 메모리 리소스 또는 탄력적 네트워크 인터페이스를 공유하지 않습니다. `requiresCompatibilities` 작업 정의 파라미터를 `FARGATE`로 설정하여 Fargate에 대한 작업 정의를 구성합니다. 자세한 내용은 [Capacity](task_definition_parameters.md#requires_compatibilities) 섹션을 참조하세요.
Fargate는 Amazon Linux 2(플랫폼 버전 1.3.0), Bottlerocket 운영 체제(플랫폼 버전 1.4.0) 및 Microsoft Windows 2019 Server Full and Core 에디션용 플랫폼 버전을 제공합니다. 달리 지정되지 않는 한, 정보는 모든 Fargate 플랫폼에 적용됩니다.
Fargate에서 Linux 컨테이너가 지원되는 리전에 대한 자세한 정보는 [AWS Fargate의 Linux 컨테이너](AWS_Fargate-Regions.md#linux-regions) 섹션을 참조하세요.
Fargate에서 Windows 컨테이너가 지원되는 리전에 대한 자세한 정보는 [AWS Fargate의 Windows 컨테이너](AWS_Fargate-Regions.md#windows-regions) 섹션을 참조하세요.
## 연습
콘솔을 사용하여 시작하는 방법은 다음을 참조하세요.
+ [Fargate에 대한 Amazon ECS Linux 태스크를 생성하는 방법에 대해 알아보기](getting-started-fargate.md)
+ [Fargate에 대한 Amazon ECS Windows 태스크를 생성하는 방법에 대해 알아보기](Windows_fargate-getting_started.md)
AWS CLI를 사용하여 시작하는 방법은 다음을 참조하세요.
+ [AWS CLI를 사용하여 Fargate에 대한 Amazon ECS Linux 태스크 생성](ECS_AWSCLI_Fargate.md)
+ [AWS CLI를 사용하여 Fargate에 대한 Amazon ECS Windows 태스크 생성](ECS_AWSCLI_Fargate_windows.md)
## 용량 공급자
다음과 같은 용량 공급자를 사용할 수 있습니다.
+ Fargate
+ Fargate 스팟 - AWS Fargate 가격 대비 할인된 요금으로 중단 방지 Amazon ECS 작업을 실행합니다. Fargate 스팟은 여분의 컴퓨팅 용량에 대한 태스크를 실행합니다. AWS에 용량이 다시 필요한 경우 2분간 경고한 후에 태스크가 중단됩니다. 자세한 내용은 [Fargate용 Amazon ECS 클러스터](fargate-capacity-providers.md) 섹션을 참조하세요.
## 태스크 정의
Fargate 태스크는 사용 가능한 모든 Amazon ECS 태스크 정의 파라미터를 지원하지는 않습니다. 전혀 지원되지 않는 파라미터도 있고 Fargate 작업에 다르게 작동하는 파라미터도 있습니다. 자세한 내용은 [태스크 CPU 및 메모리](fargate-tasks-services.md#fargate-tasks-size) 섹션을 참조하세요.
## 플랫폼 버전
AWS Fargate 플랫폼 버전은 Fargate 태스크 인프라를 위한 특정 실행 시간 환경을 참조하는 데 사용합니다. 이것은 커널 버전과 컨테이너 실행 시간 버전의 조합입니다. 작업을 실행하거나 여러 개의 동일한 작업을 유지 관리하는 서비스를 생성할 플랫폼 버전을 선택합니다.
플랫폼 버전의 새 개정판은 커널 또는 운영 체제 업데이트, 새로운 기능, 버그 수정 또는 보안 업데이트처럼 런타임 환경이 개선됨에 따라 릴리스됩니다. Fargate 플랫폼 버전은 새 플랫폼 버전 개정판을 통해 업데이트됩니다. 각 작업은 해당 수명 주기 동안 하나의 플랫폼 버전 개정판에서 실행됩니다. 최신 플랫폼 버전 개정판을 사용하려면 새 작업을 시작해야 합니다. Fargate에서 실행되는 새 작업은 항상 플랫폼 버전의 최신 개정판에서 실행되므로 항상 안전하고 패치가 적용된 인프라에서 작업을 시작할 수 있습니다.
기존 플랫폼 버전에 영향을 미치는 보안 문제가 발견되면 AWS는 플랫폼 버전에 패치를 적용한 새 개정판을 만들고 취약한 개정판에서 실행 중인 작업을 중지합니다. 사용자에게 Fargate 작업이 만료 예정이라는 알림이 전송되는 경우도 있습니다. 자세한 내용은 [Amazon ECS에서 AWS Fargate에 대한 태스크 사용 중지 및 유지 관리](task-maintenance.md) 섹션을 참조하세요.
자세한 내용은 [Amazon ECS에 대한 Fargate 플랫폼 버전](platform-fargate.md) 섹션을 참조하세요.
## 서비스 로드 밸런싱
Elastic Load Balancing을 사용하여 서비스의 태스크 간에 트래픽을 고르게 분산하도록 AWS Fargate의 Amazon ECS 서비스를 구성할 수도 있습니다.
AWS Fargate의 Amazon ECS 서비스는 Application Load Balancer, Network Load Balancer 및 Gateway Load Balancer 로드 밸런서 유형을 지원합니다. Application Load Balancer는 HTTP/HTTPS(또는 계층 7) 트래픽을 라우팅하는 데 사용합니다. Network Load Balancer는 TCP 또는 UDP(또는 계층 4) 트래픽을 라우팅하는 데 사용합니다. 자세한 내용은 [로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산](service-load-balancing.md) 섹션을 참조하세요.
이러한 서비스에 대한 대상 그룹을 생성할 때 대상 유형을 `instance`가 아닌 `ip`로 선택해야 합니다. 이는 `awsvpc` 네트워크 모드를 사용하는 작업이 Amazon EC2 인스턴스가 아닌 탄력적 네트워크 인터페이스와 연결되기 때문입니다. 자세한 내용은 [로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산](service-load-balancing.md) 섹션을 참조하세요.
Network Load Balancer를 사용하여 AWS Fargate 태스크의 Amazon ECS로 UDP 트래픽을 라우팅하는 것은 플랫폼 버전 1.4 이상을 사용할 때만 지원됩니다.
## 사용량 지표
CloudWatch 사용량 지표를 사용하여 계정의 리소스 사용량을 확인할 수 있습니다. 이러한 지표를 사용하여 CloudWatch 그래프 및 대시보드에서 현재 서비스 사용량을 시각화합니다.
AWS Fargate 사용량 지표는 AWS 서비스 할당량에 해당합니다. 사용량이 서비스 할당량에 가까워지면 경고하는 경보를 구성할 수 있습니다. AWS Fargate 서비스 할당량에 대한 자세한 내용은 *Amazon Web Services 일반 참조*의 [Amazon ECS 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html)을 참조하세요.
AWS Fargate 사용량 지표에 대한 자세한 내용은 [AWS Fargate사용량 지표](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-fargate-usage.html)를 참조하세요.
# Fargate 사용 시점에 대한 Amazon ECS 보안 고려 사항
엄격한 작업 격리를 원하는 고객은 Fargate를 사용하는 것이 좋습니다. Fargate는 하드웨어 가상화 환경에서 각 작업을 실행합니다. 이러한 컨테이너화된 워크로드는 네트워크 인터페이스, Fargate 임시 스토리지, CPU 또는 메모리를 다른 작업과 공유하지 않습니다. 자세한 내용은 [Security Overview of AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf)를 참조하세요.
# Amazon ECS의 Fargate 보안 모범 사례
AWS Fargate를 사용할 때 다음 모범 사례를 고려하는 것이 좋습니다. 추가 지침은 [Security overview of AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf)를 참조하세요.
## AWS KMS를 사용하여 Fargate를 위한 임시 스토리지 암호화
AWS KMS 또는 고객 관리형 키로 임시 스토리지를 암호화해야 합니다. 기본적으로 플랫폼 버전 `1.4.0` 이상을 사용하여 Fargate에서 호스팅되는 작업은 각각 최소 20GiB 이상의 임시 스토리지를 받습니다. 자세한 내용은 [고객 관리형 키(CMK)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html)를 참조하세요. 임시 스토리지의 총량은 작업 정의에 `ephemeralStorage` 파라미터를 지정하여 최대 200GiB까지 늘릴 수 있습니다. 2020년 5월 28일 이후 시작된 작업의 경우, Fargate에서 관리하는 암호화 키를 사용하는 AES-256 암호화 알고리즘으로 임시 스토리지가 암호화됩니다.
자세한 내용은 [Amazon ECS 작업에 대한 스토리지 옵션](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html)을 참조하세요.
**예: 임시 스토리지 암호화를 사용하여 Fargate 플랫폼 버전 1.4.0에서 작업 시작**
다음 명령은 Fargate 플랫폼 버전 1.4에서 작업을 시작합니다. 이 작업은 클러스터의 일부로 시작되므로 자동으로 암호화되는 20GiB의 임시 스토리지를 사용합니다.
```
aws ecs run-task --cluster clustername \
--task-definition taskdefinition:version \
--count 1
--launch-type "FARGATE" \
--platform-version 1.4.0 \
--network-configuration "awsvpcConfiguration={subnets=[subnetid],securityGroups=[securitygroupid]}" \
--region region
```
## Fargate를 사용한 커널 시스템 호출 추적을 위한 SYS\$1PTRACE 기능
컨테이너에서 추가되거나 삭제되는 Linux 기능의 기본 구성은 Docker에서 제공됩니다.
Fargate에서 시작된 태스크는 `SYS_PTRACE` 커널 기능 추가만 지원합니다.
다음 비디오는 Sysdig [Falco](https://github.com/falcosecurity/falco) 프로젝트를 통해 이 기능을 사용하는 방법을 보여줍니다.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/OYGKjmFeLqI)
앞의 비디오에서 설명한 코드는 [여기](https://github.com/paavan98pm/ecs-fargate-pv1.4-falco) GitHub에서 찾을 수 있습니다.
## Fargate Runtime Monitoring과 함께 Amazon GuardDuty 사용
Amazon GuardDuty는 AWS 환경 내 계정, 컨테이너, 워크로드 및 데이터를 보호하는 데 도움이 되는 위협 감지 서비스입니다. GuardDuty는 기계 학습(ML) 모델, 이상 및 위협 감지 기능을 통해 다양한 로그 소스와 런타임 활동을 지속적으로 모니터링하여 사용자 환경의 잠재적 보안 위험과 악의적 활동을 식별하고 우선순위를 지정합니다.
GuardDuty의 Runtime Monitoring은 AWS 로그 및 네트워킹 활동을 지속적으로 모니터링하여 악의적 동작 또는 무단 동작을 식별함으로써 Fargate에서 실행되는 워크로드를 보호합니다. Runtime Monitoring은 파일 액세스, 프로세스 실행 및 네트워크 연결과 같은 호스트 내 동작을 분석하는 경량의 완전관리형 GuardDuty 보안 에이전트를 사용합니다. 여기에는 권한 에스컬레이션, 노출된 자격 증명 사용 또는 악의적인 IP 주소 및 도메인과의 통신, 그리고 Amazon EC2 인스턴스 및 컨테이너 워크로드에 존재하는 맬웨어 같은 문제가 포함됩니다. 자세한 내용은 **GuardDuty 사용 설명서의 [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)을 참조하세요.
# Amazon ECS에 대한 Fargate 보안 고려 사항
Fargate는 각 워크로드를 격리된 가상 환경에서 실행하므로 작업마다 전용 인프라 용량이 있습니다. Fargate에서 실행되는 워크로드는 네트워크 인터페이스, 임시 스토리지, CPU 또는 메모리를 다른 작업과 공유하지 않습니다. 작업 내에서 애플리케이션 컨테이너와 사이드카 컨테이너 또는 단순히 사이드카를 비롯한 여러 컨테이너를 실행할 수 있습니다. 사이드카는* *Amazon ECS 작업에서 애플리케이션 컨테이너와 함께 실행되는 컨테이너입니다. 애플리케이션 컨테이너는 코어 애플리케이션 코드를 실행하는 반면 사이드카에서 실행되는 프로세스는 애플리케이션을 확대할 수 있습니다. 사이드카를 사용하면 애플리케이션 기능을 전용 컨테이너로 분리하여 애플리케이션의 부분을 더 쉽게 업데이트할 수 있습니다.
동일한 태스크에 속하는 컨테이너는 항상 동일한 호스트에서 실행되고 컴퓨팅 리소스를 공유하므로 Fargate 시작 유형의 리소스를 공유합니다. 이러한 컨테이너는 Fargate에서 제공하는 임시 스토리지도 공유합니다. 작업의 Linux 컨테이너는 IP 주소 및 네트워크 포트를 비롯한 네트워크 네임스페이스를 공유합니다. 작업 내에서 작업에 속한 컨테이너는 로컬 호스트를 통해 상호 통신할 수 있습니다.
Fargate의 런타임 환경에서는 EC2 인스턴스에서 지원되는 특정 컨트롤러 기능을 사용하지 못합니다. Fargate에서 실행되는 워크로드를 설계할 때 다음 사항을 고려하세요.
+ 권한 있는 컨테이너 또는 액세스 없음 - 권한 있는 컨테이너 또는 액세스와 같은 기능은 현재 Fargate에서 사용할 수 없습니다. 이는 Docker에서 Docker 실행과 같은 사용 사례에 영향을 미칩니다.
+ Linux 기능에 대한 제한된 액세스 - 컨테이너가 Fargate에서 실행되는 환경은 잠겨 있습니다. CAP\$1SYS\$1ADMIN 및 CAP\$1NET\$1ADMIN과 같은 추가 Linux 기능은 권한 에스컬레이션을 방지하기 위해 제한됩니다. Fargate는 작업에 [CAP\$1SYS\$1PTRACE](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params) Linux 기능을 추가하여 작업 내에 배포된 관찰성 및 보안 도구에서 컨테이너식 애플리케이션을 모니터링할 수 있도록 지원합니다.
+ 기본 호스트에 액세스할 수 없음 - 고객과 AWS 운영자 모두 고객 워크로드를 실행하는 호스트에 연결할 수 없습니다. ECS exec을 사용하여 명령을 실행하거나 Fargate에서 실행되는 컨테이너로 셸을 가져올 수 있습니다. ECS exec을 사용하여 디버깅을 위한 진단 정보를 수집할 수 있습니다. 또한 Fargate는 컨테이너가 파일 시스템, 디바이스, 네트워킹 및 컨테이너 런타임과 같은 기본 호스트의 리소스에 액세스하지 못하게 합니다.
+ 네트워킹 - 보안 그룹 및 네트워크 ACL을 사용하여 인바운드 및 아웃바운드 트래픽을 제어할 수 있습니다. Fargate 작업은 VPC에 구성된 서브넷에서 IP 주소를 받습니다.
# Amazon ECS에 대한 Fargate 플랫폼 버전
AWS Fargate 플랫폼 버전은 Fargate 태스크 인프라를 위한 특정 실행 시간 환경을 참조하는 데 사용합니다. 이것은 커널 버전과 컨테이너 실행 시간 버전의 조합입니다. 작업을 실행하거나 여러 개의 동일한 작업을 유지 관리하는 서비스를 생성할 플랫폼 버전을 선택합니다.
플랫폼 버전의 새 개정판은 커널 또는 운영 체제 업데이트, 새로운 기능, 버그 수정 또는 보안 업데이트처럼 런타임 환경이 개선됨에 따라 릴리스됩니다. Fargate 플랫폼 버전은 새 플랫폼 버전 개정판을 통해 업데이트됩니다. 각 작업은 해당 수명 주기 동안 하나의 플랫폼 버전 개정판에서 실행됩니다. 최신 플랫폼 버전 개정판을 사용하려면 새 작업을 시작해야 합니다. Fargate에서 실행되는 새 작업은 항상 플랫폼 버전의 최신 개정판에서 실행되므로 항상 안전하고 패치가 적용된 인프라에서 작업을 시작할 수 있습니다.
기존 플랫폼 버전에 영향을 미치는 보안 문제가 발견되면 AWS는 플랫폼 버전에 패치를 적용한 새 개정판을 만들고 취약한 개정판에서 실행 중인 작업을 중지합니다. 사용자에게 Fargate 작업이 만료 예정이라는 알림이 전송되는 경우도 있습니다. 자세한 내용은 [Amazon ECS에서 AWS Fargate에 대한 태스크 사용 중지 및 유지 관리](task-maintenance.md) 섹션을 참조하세요.
태스크 정의를 생성하거나 서비스를 배포할 때 플랫폼 버전을 지정합니다.
플랫폼 버전을 지정할 때 다음 사항을 고려해야 합니다.
+ `1.4.0`, `LATEST` 등과 같은 특정 버전 번호를 지정할 수 있습니다.
**LATEST** Linux 플랫폼 버전은 `1.4.0`입니다.
**LATEST** Windows 플랫폼 버전은 `1.0.0`입니다.
+ 서비스의 플랫폼 버전을 업데이트하려면 배포를 생성하세요. 예를 들어 Linux 플랫폼 버전 `1.3.0`에서 작업을 실행하는 서비스가 있다고 가정합니다. Linux 플랫폼 버전 `1.4.0`에서 작업을 실행하도록 서비스를 변경하려면 서비스를 업데이트하고 새 플랫폼 버전을 지정합니다. 작업은 최신 플랫폼 버전과 최신 플랫폼 버전 개정판으로 재배포됩니다. 배포에 대한 자세한 내용은 [Amazon ECS 서비스](ecs_services.md) 섹션을 참조하세요.
+ 플랫폼 버전을 업데이트하지 않고 서비스를 확장하면 해당 태스크는 서비스의 현재 배포에 지정된 플랫폼 버전을 수신합니다. 예를 들어 Linux 플랫폼 버전 `1.3.0`에서 작업을 실행하는 서비스가 있다고 가정합니다. 원하는 만큼 서비스 수를 늘리면 서비스 스케줄러는 플랫폼 버전 `1.3.0`의 최신 개정판을 사용하여 새 작업을 시작합니다.
+ 새 작업은 항상 플랫폼 버전의 최신 개정판에서 실행됩니다. 따라서 항상 보안이 유지되고 패치가 적용된 인프라에서 작업을 시작할 수 있습니다.
+ Fargate에서 Linux 컨테이너와 Windows 컨테이너의 플랫폼 버전 번호는 독립적입니다. 예를 들어 Fargate의 Windows 컨테이너용 플랫폼 버전 `1.0.0` 및 Fargate의 Linux 컨테이너용 플랫폼 버전 `1.0.0`에서 사용되는 동작, 기능 및 소프트웨어는 서로 비교할 수 없습니다.
+ 다음은 Fargate Windows 플랫폼 버전에 적용됩니다.
Microsoft Windows Server 컨테이너 이미지는 특정 버전의 Windows Server에서 생성되어야 합니다. 작업을 실행하거나 서비스를 생성할 때 `platformFamily`에서 해당 Windows Server 컨테이너 이미지와 일치하는 동일한 버전의 Windows Server를 선택해야 합니다. 또한 작업 정의에 일치하는 `operatingSystemFamily`를 제공하여 작업이 잘못된 Windows 버전에서 실행되지 않도록 할 수 있습니다. 자세한 내용은 Microsoft Learn 웹 사이트에서 [Matching container host version with container image versions](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility#matching-container-host-version-with-container-image-versions)를 참조하세요.
# Amazon ECS에서 Linux 플랫폼 버전 1.4.0으로 마이그레이션
Fargate의 Amazon ECS 태스크를 플랫폼 버전 `1.0.0`, `1.1.0`, `1.2.0` 또는 `1.3.0`에서 플랫폼 버전 `1.4.0`으로 마이그레이션할 때 고려해야 할 사항은 다음과 같습니다. 태스크를 마이그레이션하기 전에 플랫폼 버전 `1.4.0`에서 태스크가 올바르게 작동하는지 확인하는 것이 좋습니다.
+ 태스크를 주고받은 네트워크 트래픽 동작이 업데이트되었습니다. 플랫폼 버전 1.4.0부터 모든 Fargate의 Amazon ECS 태스크는 단일 탄력적 네트워크 인터페이스(태스크 ENI라고 함)를 받고, 모든 네트워크 트래픽은 VPC 내의 해당 ENI를 통해 흐르게 됩니다. 사용자는 VPC 흐름 로그를 통해 이를 볼 수 있습니다. 자세한 내용은 [Fargate에 대한 Amazon ECS 태스크 네트워킹 옵션](fargate-task-networking.md)을 참조하세요.
+ 인터페이스 VPC 엔드포인트를 사용하는 경우 다음을 고려해야 합니다.
+ Amazon ECR로 호스팅되는 컨테이너 이미지의 경우 다음 엔드포인트가 필요합니다. 자세한 정보는 *Amazon Elastic Container Registry 사용 설명서*의 [Amazon ECR 인터페이스 VPC 엔드포인트(AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)를 참조하세요.
+ **com.amazonaws.*region*.ecr.dkr** Amazon ECR VPC 엔드포인트
+ **com.amazonaws.*region*.ecr.api** Amazon ECR VPC 엔드포인트
+ Amazon S3 게이트웨이 엔드포인트
+ 태스크 정의에서 Secret Manager 보안 암호를 참조하여 컨테이너에 대한 중요한 데이터를 검색하는 경우 Secret Manager용 인터페이스 VPC 엔드포인트를 생성해야 합니다. 자세한 내용은 *AWS Secrets Manager 사용 설명서*의 [VPC 엔드포인트와 함께 Secrets Manager 사용](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html)을 참조하세요.
+ 태스크 정의에서 Systems Manager Parameter Store 파라미터를 참조하여 컨테이너에 대한 중요한 데이터를 검색하는 경우, System Manager용 인터페이스 VPC 엔드포인트를 생성해야 합니다. 자세한 내용은 *AWS Systems Manager 사용 설명서*의 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html)을 참조하세요.
+ 태스크와 연결된 탄력적 네트워크 인터페이스(ENI)의 보안 그룹에는 해당 태스크와 VPC 엔드포인트 간의 트래픽을 허용하도록 만들어진 보안 그룹 규칙이 있어야 합니다.
# Fargate Linux 플랫폼 버전 변경 로그
사용 가능한 Linux 플랫폼 버전은 다음과 같습니다. 플랫폼 버전 사용 중단에 대한 자세한 정보는 [AWS Fargate Linux 플랫폼 버전 사용 중단](platform-versions-retired.md) 섹션을 참조하세요.
## 1.4.0
플랫폼 버전 `1.4.0`의 변경 사항은 다음과 같습니다.
+ 2020년 11월 5일부터 플랫폼 버전 `1.4.0`을 사용하여 Fargate에서 시작한 새로운 Amazon ECS 태스크는 다음의 기능을 사용할 수 있습니다.
+ Secrets Manager를 사용하여 민감한 데이터를 저장하는 경우, 특정 JSON 키 또는 특정 암호 버전을 환경 변수로 삽입하거나, 로그 구성에 삽입할 수 있습니다. 자세한 내용은 [Amazon ECS 컨테이너로 민감한 데이터 전달](specifying-sensitive-data.md) 섹션을 참조하세요.
+ `environmentFiles` 컨테이너 정의 파라미터를 사용하여 환경 변수를 일괄 지정합니다. 자세한 정보는 [개별 환경 변수를 Amazon ECS 컨테이너로 전달](taskdef-envfiles.md) 섹션을 참조하세요.
+ VPC에서 실행되는 태스크와 IPv6에 활성화된 서브넷은 프라이빗 IPv4 주소와 IPv6 주소가 모두 할당됩니다. 자세한 내용은 [Fargate에 대한 Amazon ECS 태스크 네트워킹 옵션](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html)을 참조하세요.
+ 태스크 메타데이터 엔드포인트 버전 4는 태스크 시작 유형, 컨테이너의 Amazon 리소스 이름(ARN), 로그 드라이버, 사용한 로그 드라이버 옵션 등을 포함한 태스크와 컨테이너 관련 추가 메타데이터를 제공합니다. `/stats` 엔드포인트를 쿼리하면 컨테이너의 네트워크 속도 통계도 수신합니다. 자세한 내용은 [작업 메타데이터 엔드포인트 버전 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html)를 참조하세요.
+ 2020년 7월 30일부터 플랫폼 버전 `1.4.0`을 사용하여 Fargate에서 시작한 새로운 Amazon ECS 태스크는 Network Load Balancer를 사용하여 Fargate의 Amazon ECS 태스크로 UDP 트래픽을 라우팅할 수 있습니다. 자세한 정보는 [로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산](service-load-balancing.md) 섹션을 참조하세요.
+ 2020년 5월 28일부터 플랫폼 버전 `1.4.0`을 사용하여 Fargate에서 시작되는 새로운 Amazon ECS는 AWS에서 소유한 암호화 키를 사용하여 AES-256 암호화 알고리즘으로 휘발성 스토리지를 암호화합니다. 자세한 내용은 [Amazon ECS에 대한 Fargate 작업 임시 스토리지](fargate-task-storage.md) 및 [Amazon ECS 작업에 대한 스토리지 옵션](using_data_volumes.md)(을)를 참조하세요.
+ 영구 태스크 스토리지를 위한 Amazon EFS 파일 시스템 볼륨 사용에 대한 지원이 추가되었습니다. 자세한 정보는 [Amazon ECS에서 Amazon EFS 볼륨 사용](efs-volumes.md) 섹션을 참조하세요.
+ 각 태스크의 휘발성 태스크 스토리지가 최소 20GB로 증가했습니다. 자세한 내용은 [Amazon ECS에 대한 Fargate 작업 임시 스토리지](fargate-task-storage.md) 섹션을 참조하세요.
+ 태스크를 주고받은 네트워크 트래픽 동작이 업데이트되었습니다. 플랫폼 버전 1.4.0부터 모든 Fargate 태스크는 단일 탄력적 네트워크 인터페이스(태스크 ENI라고 함)를 받고, 모든 네트워크 트래픽은 VPC 내에서 해당 ENI를 통해 흐르게 됩니다. 사용자는 VPC 흐름 로그를 통해 이를 볼 수 있습니다. Amazon EC2 시작 유형의 네트워킹에 대한 자세한 내용은 [EC2에 대한 Amazon ECS 태스크 네트워킹 옵션](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html)을 참조하세요. Fargate의 네트워킹에 대한 자세한 내용은 [Fargate에 대한 Amazon ECS 태스크 네트워킹 옵션](fargate-task-networking.md) 섹션을 참조하세요.
+ 태스크 ENI는 점보 프레임에 대한 지원을 추가합니다. 네트워크 인터페이스는 단일 프레임 내에 맞는 가장 큰 페이로드 크기인 최대 전송 단위(MTU)로 구성됩니다. MTU가 클수록 단일 프레임 내에 더 많은 애플리케이션 페이로드가 들어갈 수 있으므로 프레임당 오버헤드가 줄어들고 효율성이 향상됩니다. 점보 프레임을 지원하면 VPC 내에 남아 있는 모든 트래픽과 같이 태스크와 대상 간의 네트워크 경로가 점보 프레임을 지원할 때 오버헤드가 줄어듭니다.
+ CloudWatch Container Insights가 Fargate 태스크에 대한 네트워크 성능 지표를 포함합니다. 자세한 정보는 [관찰성이 향상된 Container Insights를 사용하여 Amazon ECS 컨테이너 모니터링](cloudwatch-container-insights.md) 섹션을 참조하세요.
+ 태스크에 대한 네트워크 통계 및 태스크를 실행 중인 가용 영역 등 Fargate 태스크에 대한 추가 정보를 제공하는 태스크 메타데이터 엔드포인트 버전 4에 대한 지원이 추가되었습니다. 자세한 내용은 [Amazon ECS 작업 메타데이터 엔드포인트 버전 4](task-metadata-endpoint-v4.md) 및 [Fargate의 작업에 대한 Amazon ECS 작업 메타데이터 엔드포인트 버전 4](task-metadata-endpoint-v4-fargate.md)(을)를 참조하세요.
+ 컨테이너 정의에 `SYS_PTRACE` Linux 파라미터에 대한 지원이 추가되었습니다. 자세한 정보는 [Linux 파라미터](task_definition_parameters.md#container_definition_linuxparameters) 섹션을 참조하세요.
+ Fargate 컨테이너 에이전트가 모든 Fargate 태스크에 대해 Amazon ECS 컨테이너 에이전트의 사용을 대체합니다. 일반적으로 이 변경 사항은 태스크 실행 방식에 영향을 주지 않습니다.
+ 컨테이너 런타임은 이제 Docker 대신 Containerd를 사용합니다. 이 변경 사항은 태스크 실행 방식에 영향을 주지 않을 가능성이 큽니다. 컨테이너 런타임에 시작되는 일부 오류 메시지는 Docker를 언급하는 것에서 보다 일반적인 오류로 변경됩니다. 자세한 내용은 [Amazon ECS 중지된 작업 오류 메시지](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html)를 참조하세요.
+ Amazon Linux 2를 기반으로 합니다.
# AWS Fargate Linux 플랫폼 버전 사용 중단
**중요**
2026년 6월 30일에 Fargate에서 PV 1.3.0에 대한 지원이 종료됩니다. 2026년 6월 15일부터 플랫폼 버전 1.3.0이 사용 중지됩니다. 이 시점에서는 새 태스크를 시작하거나 플랫폼 버전 1.3.0으로 구성된 새 서비스를 생성할 수 없지만 기존 태스크는 계속 실행됩니다. 2026년 6월 30일에 플랫폼 버전 1.3.0으로 구성된 나머지 실행 중인 태스크를 모두 종료합니다.
플랫폼 버전 1.4로 마이그레이션하는 방법에 대한 자세한 내용은 [Amazon ECS에서 Linux 플랫폼 버전 1.4.0으로 마이그레이션](platform-version-migration.md) 섹션을 참조하세요.
다음 테이블에는 AWS Fargate에서 사용 중단하거나 사용 중단 예정인 Linux 플랫폼 버전이 나와 있습니다. 이 플랫폼 버전은 공지된 사용 중단 날짜까지 사용할 수 있습니다.
사용 중단 예정인 각 플랫폼 버전에 *강제 업데이트 날짜*가 제공됩니다. 강제 업데이트 날짜에 사용 중단 예정인 플랫폼 버전을 가리키는 `LATEST` 플랫폼 버전을 사용하는 모든 서비스는 강제 신규 배포 옵션을 사용하여 업데이트됩니다. 강제 신규 배포 옵션을 사용하여 서비스를 업데이트하면 사용 중단 예정인 플랫폼 버전에서 실행되는 모든 태스크가 중단되고 해당 시점에 `LATEST` 태그가 가리키는 플랫폼 버전을 사용하여 새로운 태스크가 시작됩니다. 명시적 플랫폼 버전이 설정된 독립적 태스크나 서비스는 강제 업데이트에 영향을 받지 않습니다.
최신 플랫폼 버전으로 마이그레이션하는 방법에 대한 자세한 내용은 [Amazon ECS에서 Linux 플랫폼 버전 1.4.0으로 마이그레이션](platform-version-migration.md) 섹션을 참조하세요.
플랫폼 버전이 *사용 중단 날짜*에 도달한 이후에는 해당 플랫폼 버전을 새로운 태스크나 서비스에 사용할 수 없게 됩니다. 사용 중단된 플랫폼 버전을 명시적으로 사용하는 독립적 태스크나 서비스는 태스크가 중단될 때까지 해당 플랫폼 버전을 계속 사용합니다. 사용 중단 날짜 이후에는 사용 중단된 플랫폼 버전은 더 이상 보안 업데이트나 버그 수정을 받지 못합니다.
| 플랫폼 버전 | 강제 업데이트 날짜 | 사용 중단 날짜 |
| --- | --- | --- |
| 1.0.0 | 2020년 10월 26일 | 2020년 12월 14일 |
| 1.1.0 | 2020년 10월 26일 | 2020년 12월 14일 |
| 1.2.0 | 2020년 10월 26일 | 2020년 12월 14일 |
| 1.3.0 | | 2026년 6월 15일 |
현재 플랫폼 버전에 대한 자세한 정보는 [Amazon ECS에 대한 Fargate 플랫폼 버전](platform-fargate.md) 섹션을 참조하세요.
## 사용 중단된 Fargate Linux 버전 변경 로그
### 1.3.0
플랫폼 버전 `1.3.0`의 변경 사항은 다음과 같습니다.
+ 2019년 9월 30일부터 시작되는 새로운 Fargate 태스크는 `awsfirelens` 로그 드라이버를 지원합니다. 작업 정의 파라미터를 사용하여 로그를 저장하고 분석하기 위해 로그를 AWS 서비스 또는 AWS 파트너 네트워크(APN)를 대상으로 라우팅하도록 FireLens for Amazon ECS를 구성합니다. 자세한 내용은 [Amazon ECS 로그를 AWS 서비스 또는 AWS Partner로 전송](using_firelens.md) 섹션을 참조하세요.
+ Fargate 태스크의 태스크 재생이 추가되었습니다. 이 기능은 Amazon ECS 서비스에 속하는 태스크를 새로 고치는 프로세스입니다. 자세한 내용은 [Amazon ECS에서AWS Fargate에 대한 태스크 사용 중지 및 유지 관리](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-maintenance.html)를 참조하세요.
+ 2019년 3월 27일부터 새로운 Fargate 태스크는 프록시 구성, 컨테이너 시작 및 종료는 물론, 컨테이너별 시작 및 중지 제한 시간 값에 대한 종속성을 정의하는 데 사용하는 태스크 정의 파라미터를 추가로 출시했습니다. 자세한 정보는 [프록시 구성](task_definition_parameters.md#proxyConfiguration), [컨테이너 종속성](task_definition_parameters.md#container_definition_dependson), [컨테이너 제한 시간](task_definition_parameters.md#container_definition_timeout) 섹션을 참조하세요.
+ 2019년 4월 2일부터 새로운 Fargate 태스크는 AWS Secrets Manager 암호 또는 AWS Systems Manager 파라미터 스토어 파라미터에 중요한 데이터를 저장한 다음 컨테이너 정의에서 참조하여 중요한 데이터를 컨테이너에 주입할 수 있습니다. 자세한 정보는 [Amazon ECS 컨테이너로 민감한 데이터 전달](specifying-sensitive-data.md) 섹션을 참조하세요.
+ 2019년 5월 1일부터 시작되는 새로운 Fargate 태스크는 `secretOptions` 컨테이너 정의 파라미터를 사용하여 컨테이너의 로그 구성에서 민감한 데이터를 참조하는 것을 지원합니다. 자세한 정보는 [Amazon ECS 컨테이너로 민감한 데이터 전달](specifying-sensitive-data.md) 섹션을 참조하세요.
+ 2019년 5월 1일부터 시작되는 새로운 Fargate 태스크는 `awslogs` 로그 드라이버 외에 `splunk` 로그 드라이버도 지원합니다. 자세한 정보는 [스토리지 및 로깅](task_definition_parameters.md#container_definition_storage) 섹션을 참조하세요.
+ 2019년 7월 9일부터 시작되는 모든 새로운 Fargate 태스크는 CloudWatch Container Insights를 지원합니다. 자세한 정보는 [관찰성이 향상된 Container Insights를 사용하여 Amazon ECS 컨테이너 모니터링](cloudwatch-container-insights.md) 섹션을 참조하세요.
+ 2019년 12월 3일부터 Fargate 스팟 용량 공급자가 지원됩니다. 자세한 정보는 [Fargate용 Amazon ECS 클러스터](fargate-capacity-providers.md) 섹션을 참조하세요.
+ Amazon Linux 2를 기반으로 합니다.
### 1.2.0
플랫폼 버전 `1.2.0`의 변경 사항은 다음과 같습니다.
**참고**
플랫폼 버전 `1.2.0`을 더 이상 사용할 수 없습니다. 플랫폼 버전 사용 중단에 대한 자세한 정보는 [AWS Fargate Linux 플랫폼 버전 사용 중단](#platform-versions-retired) 섹션을 참조하세요.
+ AWS Secrets Manager을 사용하는 프라이빗 레지스트리 인증 지원이 추가되었습니다. 자세한 정보는 [Amazon ECS에서 AWS 컨테이너가 아닌 이미지 사용](private-auth.md) 섹션을 참조하세요.
### 1.1.0
플랫폼 버전 `1.1.0`의 변경 사항은 다음과 같습니다.
**참고**
플랫폼 버전 `1.1.0`을 더 이상 사용할 수 없습니다. 플랫폼 버전 사용 중단에 대한 자세한 정보는 [AWS Fargate Linux 플랫폼 버전 사용 중단](#platform-versions-retired) 섹션을 참조하세요.
+ Amazon ECS 태스크 메타데이터 엔드포인트에 대한 지원이 추가되었습니다. 자세한 내용은 [Fargate의 작업에 대해 사용 가능한 Amazon ECS 작업 메타데이터](fargate-metadata.md) 섹션을 참조하세요.
+ 컨테이너 정의에서 Docker 상태 확인에 대한 지원이 추가되었습니다. 자세한 정보는 [상태 확인](task_definition_parameters.md#container_definition_healthcheck) 섹션을 참조하세요.
+ Amazon ECS 서비스 검색에 대한 지원이 추가되었습니다. 자세한 정보는 [서비스 검색을 사용하여 Amazon ECS 서비스를 DNS 이름으로 연결](service-discovery.md) 섹션을 참조하세요.
### 1.0.0
플랫폼 버전 `1.0.0`의 변경 사항은 다음과 같습니다.
**참고**
플랫폼 버전 `1.0.0`을 더 이상 사용할 수 없습니다. 플랫폼 버전 사용 중단에 대한 자세한 정보는 [AWS Fargate Linux 플랫폼 버전 사용 중단](#platform-versions-retired) 섹션을 참조하세요.
+ Amazon Linux 2017.09를 기반으로 합니다.
+ 최초 릴리스입니다.
# Fargate Windows 플랫폼 버전 변경 로그
Windows 컨테이너에 사용 가능한 플랫폼 버전은 다음과 같습니다.
## 1.0.0
플랫폼 버전 `1.0.0`의 변경 사항은 다음과 같습니다.
+ 다음 Microsoft Windows Server 운영 체제 지원을 위한 초기 릴리스:
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
# Amazon ECS에 대한 Fargate의 Windows 컨테이너 고려 사항
다음은 AWS Fargate에서 Windows 컨테이너를 실행할 때 알아야 할 차이점과 고려 사항입니다.
Linux 및 Windows 컨테이너에서 작업을 실행해야 하는 경우 각 운영 체제에 대해 별도의 작업 정의를 생성해야 합니다.
AWS에서 운영 체제 라이선스 관리를 처리하므로 추가 Microsoft Windows Server 라이선스가 필요하지 않습니다.
AWS Fargate의 Windows 컨테이너는 다음 운영 체제를 지원합니다.
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
AWS Fargate의 Windows 컨테이너는 awslogs 드라이버를 지원합니다. 자세한 내용은 [Amazon ECS 로그를 CloudWatch로 전송](using_awslogs.md) 섹션을 참조하세요.
다음 기능은 Fargate의 Windows 컨테이너에서 지원되지 않습니다.
+ Amazon FSx
+ ENI 트렁킹
+ Windows 컨테이너용 gMSA
+ 태스크를 위한 App Mesh 서비스 및 프록시 통합
+ 태스크를 위한 FireLens 로그 라우터 통합
+ EFS 볼륨
+ EBS 볼륨
+ 다음 작업 정의 파라미터:
+ `maxSwap`
+ `swappiness`
+ `environmentFiles`
+ Fargate 스팟 용량 공급자
+ 이미지 볼륨
Dockerfile `volume` 옵션은 무시됩니다. 대신 태스크 정의에서 바인드 탑재를 사용합니다. 자세한 내용은 [Amazon ECS에서 바인드 탑재 사용](bind-mounts.md) 섹션을 참조하세요.
+ Windows 컨테이너에 대해서는 태스크 레벨 CPU와 메모리 파라미터가 무시됩니다. Windows 컨테이너에 대해서는 컨테이너 레벨 리소스를 지정할 것을 권장합니다.
+ 태스크용 메모리
+ 컨테이너의 mermoryReservation
+ 컨테이너에서 정책 다시 시작
+ 서비스의 platformFamily는 업데이트할 수 없습니다.
# Amazon ECS에 대한 Fargate 컨테이너 이미지 가져오기 동작에서 Linux 컨테이너
모든 Fargate 태스크는 자체 일회용 단일 테넌트 인스턴스에서 실행됩니다. Fargate에서 Linux 컨테이너를 실행하면 컨테이너 이미지 또는 컨테이너 이미지 레이어가 인스턴스에 캐싱되지 않습니다. 따라서 태스크에 정의된 각 컨테이너 이미지에 대해 각 Fargate 태스크의 컨테이너 이미지 레지스트리에서 전체 컨테이너 이미지를 가져와야 합니다. 이미지를 가져오는 데 걸리는 시간은 Fargate 태스크를 시작하는 데 걸리는 시간과 직접적인 상관관계가 있습니다.
이미지 가져오기 시간을 최적화하려면 다음 사항을 고려하세요.
**컨테이너 이미지 근접성**
컨테이너 이미지를 다운로드하는 데 걸리는 시간을 줄이려면 데이터를 최대한 컴퓨팅에 가까운 곳에 두세요. 인터넷을 통해 또는 AWS 리전 간에 컨테이너 이미지를 가져오면 다운로드 시간에 영향을 미칠 수 있습니다. 태스크가 실행될 동일한 리전에 컨테이너 이미지를 저장하는 것이 좋습니다. Amazon ECR에 컨테이너 이미지를 저장하는 경우 VPC 인터페이스 엔드포인트를 사용하여 이미지 가져오기 시간을 더욱 단축하세요. 자세한 내용은 *Amazon ECR 사용 설명서*의 [Amazon ECR 인터페이스 VPC 엔드포인트(AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)를 참조하세요.
**컨테이너 이미지 크기 줄이기**
컨테이너 이미지의 크기는 다운로드 시간에 직접적으로 영향을 미칩니다. 컨테이너 이미지의 크기 또는 컨테이너 이미지 레이어 수를 줄이면 이미지를 다운로드하는 데 걸리는 시간을 줄일 수 있습니다. 가벼운 기본 이미지(예: 최소 Amazon Linux 2023 컨테이너 이미지)는 기존 운영 체제 기본 이미지에 기반을 둔 이미지보다 훨씬 작을 수 있습니다. 최소 이미지에 대한 자세한 내용은 *Amazon Linux 2023 사용 설명서*의 [AL2023 최소 컨테이너 이미지](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html)를 참조하세요.
**대체 압축 알고리즘**
컨테이너 이미지 레이어는 컨테이너 이미지 레지스트리로 푸시할 때 압축되는 경우가 많습니다. 컨테이너 이미지 레이어를 압축하면 네트워크를 통해 전송되고 컨테이너 이미지 레지스트리에 저장해야 하는 데이터의 양이 줄어듭니다. 컨테이너 런타임에 의해 컨테이너 이미지 레이어가 인스턴스로 다운로드되면 해당 레이어의 압축이 해제됩니다. 사용된 압축 알고리즘과 런타임에 사용 가능한 vCPU의 양은 컨테이너 이미지 압축을 푸는 데 걸리는 시간에 영향을 미칩니다. Fargate에서는 태스크의 크기를 늘리거나 더 성능이 뛰어난 zstd 압축 알고리즘을 활용하여 압축 해제에 걸리는 시간을 줄일 수 있습니다. 자세한 내용은 GitHub의 [zstd](https://github.com/facebook/zstd)를 참조하세요. Fargate를 위한 이미지를 구현하는 방법에 대한 자세한 내용은 [zstd 압축 컨테이너 이미지를 사용하여 AWS Fargate 시작 시간 단축](https://aws.amazon.com/blogs/containers/reducing-aws-fargate-startup-times-with-zstd-compressed-container-images/)을 참조하세요.
**컨테이너 이미지 지연 로딩**
큰 컨테이너 이미지(> 250mb)의 경우 모든 컨테이너 이미지를 다운로드하는 것보다 컨테이너 이미지를 지연 로드하는 것이 최적일 수 있습니다. Fargate에서는 Seekable OCI(SOCI)를 사용하여 컨테이너 이미지 레지스트리에서 컨테이너 이미지를 지연 로드할 수 있습니다. 자세한 내용은 GitHub의 [soci-snapshotter](https://github.com/awslabs/soci-snapshotter)와 [Seekable OCI(SOCI)를 사용하여 컨테이너 이미지 지연 로딩](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-soci-images)을 참조하세요.
# Amazon ECS에 대한 Fargate 컨테이너 이미지 가져오기 동작에서 Windows 컨테이너
Fargate Windows는 Microsoft에서 제공한 가장 최근 달과 이전 달의 servercore 기본 이미지를 캐싱합니다. 이 이미지는 매주 패치 화요일에 업데이트되는 KB/빌드 번호 패치와 일치합니다. 예를 들면, 2024년 4월 9일에 Microsoft에서 Windows Server 2019용 KB5036896(17763.5696)을 릴리스했습니다. 2024년 3월 12일의 이전 달 KB는 KB5035849(17763.5576)였습니다. 따라서 플랫폼 `WINDOWS_SERVER_2019_CORE` 및 `WINDOWS_SERVER_2019_FULL`의 경우 다음과 같은 컨테이너 이미지가 캐싱됩니다.
+ `mcr.microsoft.com/windows/servercore:ltsc2019`
+ ` mcr.microsoft.com/windows/servercore:10.0.17763.5696`
+ `mcr.microsoft.com/windows/servercore:10.0.17763.5576`
또한 2024년 4월 9일에 Microsoft에서 Windows Server 2022용 KB5036909(20348.2402)를 릴리스했습니다. 2024년 3월 12일의 이전 달 KB는 KB5035857(20348.2340)였습니다. 따라서 플랫폼 `WINDOWS_SERVER_2022_CORE` 및 `WINDOWS_SERVER_2022_FULL`의 경우 다음과 같은 컨테이너 이미지가 캐싱됩니다.
+ `mcr.microsoft.com/windows/servercore:ltsc2022`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2402`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2340`
# Amazon ECS에 대한 Fargate 작업 임시 스토리지
프로비저닝되면 AWS Fargate의 Linux 컨테이너에서 호스팅되는 각 Amazon ECS 태스크는 바인드 탑재를 위해 다음 임시 스토리지를 받게 됩니다. 작업 정의에서 `volumes`, `mountPoints` 및 `volumesFrom` 파라미터를 사용하여 이 볼륨을 탑재하고 컨테이너 간에 공유할 수 있습니다. AWS Fargate의 Windows 컨테이너에서는 지원되지 않습니다.
## Fargate Linux 컨테이너 플랫폼 버전
### 버전 1.4.0 이상
기본적으로 플랫폼 버전 `1.4.0` 이상을 사용하여 Fargate에서 호스팅되는 Amazon ECS 태스크는 최소 20GiB 이상의 임시 스토리지를 받습니다. 임시 스토리지의 총량은 최대 200GiB까지 높일 수 있습니다. 태스크 정의에서 `ephemeralStorage` 파라미터를 지정하여 태스크를 수행할 수 있습니다.
태스크의 풀링, 압축 및 비압축 컨테이너 이미지는 임시 스토리지에 저장됩니다. 태스크가 사용해야 하는 임시 스토리지의 총량을 확인하려면 컨테이너 이미지가 사용하는 스토리지 용량을 태스크에 할당된 임시 스토리지의 총 용량에서 빼세요.
2020년 5월 28일 이후 시작된 플랫폼 버전 `1.4.0` 이상을 사용하는 태스크의 경우, AES-256 암호화 알고리즘으로 임시 스토리지가 암호화됩니다. 이 알고리즘은 AWS에서 소유한 암호화 키를 사용합니다. 고객 관리형 키를 생성할 수도 있습니다. 자세한 내용은 [AWS Fargate 임시 스토리지에 대한 고객 관리형 키](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html)를 참조하세요.
2022년 11월 18일 이후 시작된 플랫폼 버전 `1.4.0` 이상을 사용하는 작업의 경우 작업 메타데이터 엔드포인트를 통해 임시 스토리지 사용량이 보고됩니다. 작업의 애플리케이션은 작업 메타데이터 엔드포인트 버전 4를 쿼리하여 임시 스토리지 예약 크기 및 사용량을 가져올 수 있습니다.
또한 Amazon CloudWatch Container Insights를 켜면 임시 스토리지 예약 크기와 사용된 양이 Amazon CloudWatch Container Insights로 전송됩니다.
**참고**
Fargate는 디스크 스페이스를 예약합니다. Fargate에서만 사용됩니다. 이에 대한 요금은 청구되지 않습니다. 이러한 지표에는 표시되지 않습니다. 그러나 `df` 등의 다른 도구에서는 이 추가 스토리지를 볼 수 있습니다.
### 버전 1.3.0 이하
플랫폼 버전 `1.3.0` 이전 버전을 사용하는 Fargate의 Amazon ECS 태스크는 각각 다음과 같은 임시 스토리지를 받습니다.
+ 10GB의 Docker 계층 스토리지
**참고**
이 용량에는 압축 및 비압축 컨테이너 이미지 아티팩트가 모두 포함됩니다.
+ 볼륨 마운트를 위한 추가 4GB입니다. 작업 정의에서 `volumes`, `mountPoints` 및 `volumesFrom` 파라미터를 사용하여 이 볼륨을 탑재하고 컨테이너 간에 공유할 수 있습니다.
## Fargate Windows 컨테이너 플랫폼 버전
### 버전 1.0.0 이상
기본적으로 플랫폼 버전 `1.0.0` 이상을 사용하여 Fargate에서 호스팅되는 Amazon ECS 태스크는 최소 20GiB 이상의 임시 스토리지를 받습니다. 임시 스토리지의 총량은 최대 200GiB까지 높일 수 있습니다. 태스크 정의에서 `ephemeralStorage` 파라미터를 지정하여 태스크를 수행할 수 있습니다.
태스크의 풀링, 압축 및 비압축 컨테이너 이미지는 임시 스토리지에 저장됩니다. 태스크가 사용해야 하는 임시 스토리지의 총량을 확인하려면 컨테이너 이미지가 사용하는 스토리지 용량을 태스크에 할당된 임시 스토리지의 총 용량에서 빼세요.
자세한 내용은 [Amazon ECS에서 바인드 탑재 사용](bind-mounts.md) 섹션을 참조하세요.
# Amazon ECS용 AWS Fargate 임시 스토리지에 대한 고객 관리형 키
AWS Fargate에서는 임시 스토리지에 저장된 Amazon ECS 작업의 데이터를 암호화하는 데 고객 관리형 키를 지원하므로 규제에 민감한 고객이 내부 보안 정책을 준수할 수 있도록 지원합니다. 고객은 여전히 Fargate의 서버리스 이점을 누리면서 규정 준수 감사자에게 자체 관리형 스토리지 암호화에 대한 향상된 가시성을 제공합니다. Fargate는 기본적으로 Fargate에서 관리하는 임시 스토리지 암호화를 지원하지만 고객은 금융 또는 의료 관련 정보와 같은 민감한 데이터를 암호화할 때 자체 관리형 키를 사용할 수도 있습니다.
자체 키를 AWS KMS에 가져오거나 AWS KMS에서 키를 새로 생성할 수 있습니다. 이러한 자체 관리형 키는 AWS KMS에 저장되며 교체, 비활성화, 삭제와 같은 표준 AWS KMS 수명 주기 작업을 수행합니다. CloudTrail 로그에서 키 액세스 및 사용을 감사할 수 있습니다.
기본적으로 KMS 키는 키당 50,000개의 권한 부여를 지원합니다. Fargate는 고객 관리형 키 작업당 단일 AWS KMS 권한 부여를 사용하므로 키에 대해 최대 50,000개의 동시 작업을 지원합니다. 이 수를 늘리려면 한도 증가를 요청할 수 있으며, 해당 요청은 사례별로 승인됩니다.
Fargate는 고객 관리형 키를 사용하는 데 추가 비용을 청구하지 않습니다. 스토리지 및 API 요청에 AWS KMS 키를 사용하는 경우에만 표준 요금이 청구됩니다.
**Topics**
+ [Amazon ECS용 Fargate 임시 스토리지에 대한 암호화 키 생성](fargate-create-storage-key.md)
+ [Amazon ECS용 Fargate 임시 스토리지에 대한 AWS KMS 키 관리](fargate-managing-kms-key.md)
# Amazon ECS용 Fargate 임시 스토리지에 대한 암호화 키 생성
고객 관리형 키를 생성하여 Fargate 임시 스토리지에 저장된 데이터를 암호화합니다.
**참고**
고객 관리형 키를 사용하는 Fargate 임시 스토리지 암호화는 Windows 작업 클러스터에서 사용할 수 없습니다.
고객 관리형 키를 사용하는 Fargate 임시 스토리지 암호화는 `1.4.0` 이전의 `platformVersions`에서 사용할 수 없습니다.
Fargate는 Fargate에서만 사용하는 임시 스토리지에 공간을 예약하며, 이 공간에 대해서는 요금이 청구되지 않습니다. 할당은 고객 관리형 키가 아닌 경우와 다를 수 있지만, 전체 공간은 동일합니다. `df`와 같은 도구에서 어떻게 다른지 확인할 수 있습니다.
Fargate 임시 스토리지에 대해서는 다중 리전 키가 지원되지 않습니다.
Fargate 임시 스토리지에 대해서는 KMS 키 별칭이 지원되지 않습니다.
AWS KMS에서 Fargate의 임시 스토리지를 암호화하기 위해 고객 관리형 키(CMK)를 생성하려면 다음 단계를 수행합니다.
1. [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms)로 이동합니다.
1. 관련 지침은 [AWS Key Management Service 개발자 안내서](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)의 [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)를 참조하세요.
1. AWS KMS 키를 생성할 때는 키 정책에 Fargate 서비스 관련 AWS KMS 작업 권한을 제공해야 합니다. Amazon ECS 리소스에서 고객 관리형 키를 사용하려면 정책에서 다음 API 작업을 허용해야 합니다.
+ `kms:GenerateDataKeyWithoutPlainText` ‐ 제공된 AWS KMS 키에서 암호화된 데이터 키를 생성하려면 `GenerateDataKeyWithoutPlainText`를 직접 호출합니다.
+ `kms:CreateGrant` - 고객 관리형 키에 권한 부여를 추가합니다. 권한 부여는 지정된 AWS KMS 키에 대한 액세스를 제어하며, 여기서 Amazon ECS Fargate에 필요한 권한 부여 작업에 대한 액세스를 허용합니다. [권한 부여 사용](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)에 대한 자세한 내용은 [AWS Key Management Service 개발자 안내서](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)를 참조하세요. 이를 통해 Amazon ECS Fargate에서 다음을 수행할 수 있습니다.
+ 임시 스토리지 데이터를 복호화하는 데 사용할 암호화 키를 가져오기 위해 AWS KMS로 `Decrypt`를 직접 호출합니다.
+ 서비스가 `RetireGrant`를 사용할 수 있도록 은퇴하는 보안 주체를 설정하세요.
+ `kms:DescribeKey` - Amazon ECS에서 키가 대칭이고 활성화되었는지 확인할 수 있도록 고객 관리형 키 세부 정보를 제공합니다.
다음 예제에서는 암호화를 위해 대상 키에 적용할 AWS KMS 키 정책을 보여줍니다. 다음 예시 정책 명령을 사용하려면 *사용자 입력 자리 표시자*를 실제 정보로 바꿉니다. 항상 그렇듯이 필요한 권한만 구성하되, 오류를 방지하려면 최소한 한 명의 사용자에게 권한이 있는 AWS KMS를 제공해야 합니다.
```
{
"Sid": "Allow generate data key access for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:GenerateDataKeyWithoutPlaintext"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow grant creation permission for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:CreateGrant"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow describe key permission for cluster operator - CreateCluster and UpdateCluster.",
"Effect": "Allow",
"Principal": { "AWS":"arn:aws:iam::customerAccountId:role/customer-chosen-role" },
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
}
```
Fargate 작업은 키를 사용한 암호화 작업에 `aws:ecs:clusterAccount` 및 `aws:ecs:clusterName` 암호화 컨텍스트 키를 사용합니다. 특정 계정 및/또는 클러스터에 대한 액세스를 제한하려면 고객이 이러한 권한을 추가해야 합니다. 클러스터를 지정할 때 ARN이 아닌 클러스터 이름을 사용하세요.
자세한 내용은 [AWS KMS 개발자 가이드](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)에서 [암호화 컨텍스트](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context)를 참조하세요.
클러스터를 생성하거나 업데이트할 때 조건 키 `fargateEphemeralStorageKmsKeyId`를 사용할 수 있습니다. 이 조건 키를 사용하면 고객이 IAM 정책을 보다 세밀하게 제어할 수 있습니다. `fargateEphemeralStorageKmsKeyId` 구성 업데이트는 새 서비스 배포에만 적용됩니다.
다음은 고객이 승인된 특정 AWS KMS 키 집합에만 권한을 부여하도록 허용하는 예제입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ecs:fargate-ephemeral-storage-kms-key": "arn:aws:kms:us-west-2:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
}
}
]
}
```
------
다음은 클러스터와 이미 연결된 AWS KMS 키를 제거하려는 시도를 거부하는 예제입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"Null": {
"ecs:fargate-ephemeral-storage-kms-key": "true"
}
}
}
}
```
------
고객은 AWS CLI `describe-tasks`, `describe-cluster` 또는 `describe-services` 명령을 통해 비관리형 작업이나 서비스 작업이 키를 사용하여 암호화되는지 확인할 수 있습니다.
자세한 내용은 [AWS KMS 개발자 안내서](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)의 [AWS KMS에 사용되는 조건 키](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html)를 참조하세요.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 왼쪽 탐색에서 **클러스터**를 선택하고 오른쪽 상단에서 **클러스터 생성** 선택하거나 기존 클러스터를 선택합니다. 기존 클러스터의 경우 오른쪽 상단에서 **클러스터 업데이트**를 선택합니다.
1. 워크플로의 **암호화** 섹션 아래 **관리형 스토리지** 및 **Fargate 임시 스토리지**에서 AWS KMS 키를 선택할 수 있습니다. 여기에서 **AWS KMS 키 생성**을 선택할 수도 있습니다.
1. 새 클러스터 생성을 완료한 후 **생성**을 선택하거나 기존 클러스터를 업데이트한 경우 **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
다음은 AWS CLI를 사용하여 클러스터를 생성하고 Fargate 임시 스토리지를 구성하는 예제입니다(*빨간색* 값을 자체 값으로 바꿈).
```
aws ecs create-cluster --cluster clusterName \
--configuration '{"managedStorageConfiguration":{"fargateEphemeralStorageKmsKeyId":"arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"}}'
{
"cluster": {
"clusterArn": "arn:aws:ecs:us-west-2:012345678901:cluster/clusterName",
"clusterName": "clusterName",
"configuration": {
"managedStorageConfiguration": {
"fargateEphemeralStorageKmsKeyId": "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
},
"status": "ACTIVE",
"registeredContainerInstancesCount": 0,
"runningTasksCount": 0,
"pendingTasksCount": 0,
"activeServicesCount": 0,
"statistics": [],
"tags": [],
"settings": [],
"capacityProviders": [],
"defaultCapacityProviderStrategy": []
},
"clusterCount": 5
}
```
------
#### [ CloudFormation ]
다음은 CloudFormation를 사용하여 클러스터를 생성하고 Fargate 임시 스토리지를 구성하는 예제 템플릿입니다(*빨간색* 값을 자체 값으로 바꿈).
```
AWSTemplateFormatVersion: 2010-09-09
Resources:
MyCluster:
Type: AWS::ECS::Cluster
Properties:
ClusterName: "clusterName"
Configuration:
ManagedStorageConfiguration:
FargateEphemeralStorageKmsKeyId: "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
------
# Amazon ECS용 Fargate 임시 스토리지에 대한 AWS KMS 키 관리
Fargate 임시 스토리지를 암호화하기 위해 AWS KMS 키를 생성하거나 가져온 후에는 다른 AWS KMS 키와 동일한 방식으로 관리합니다.
**AWS KMS 키 자동 교체**
자동 키 교체를 활성화하거나 수동으로 교체할 수 있습니다. 자동 키 교체는 키에 대한 새로운 암호화 자료를 생성하여 키를 매년 자동으로 교체합니다. 또한 AWS KMS에서는 이전 버전의 모든 암호화 자료를 저장하므로 이전 키 버전을 사용한 모든 데이터를 복호화할 수 있습니다. 교체된 자료는 키를 삭제할 때까지 AWS KMS에서 삭제되지 않습니다.
자동 키 교체는 선택 사항이며, 언제라도 활성화하거나 비활성화할 수 있습니다.
**AWS KMS 키 비활성화 또는 취소**
AWS KMS에서 고객 관리형 키를 비활성화해도 실행 중인 작업에는 영향을 주지 않으며 수명 주기 동안 계속 작동합니다. 새 작업에서 비활성화되거나 취소된 키를 사용하는 경우 키에 액세스할 수 없으므로 작업이 실패합니다. 이미 암호화된 데이터를 복호화하는 데 비활성화된 키가 필요하지 않도록 하려면 CloudWatch 경보 또는 유사한 기능을 설정해야 합니다.
**AWS KMS 키 삭제**
키 삭제는 항상 최후의 수단이어야 하며, 삭제된 키가 다시 필요하지 않다고 확신하는 경우에만 삭제해야 합니다. 삭제된 키를 사용하려는 새 작업의 경우 해당 작업에서 키에 액세스할 수 없기 때문에 작업이 실패합니다. AWS KMS에서는 키를 삭제하는 대신, 키를 활성화할 것을 권장합니다. 키를 삭제해야 한다고 생각되면 먼저 키를 비활성화하고 CloudWatch 경보를 설정하여 키가 필요하지 않은지 확인하는 것이 좋습니다. 키를 삭제한 경우 AWS KMS에서는 설정을 복구할 7일 이상의 유예 기간을 제공합니다.
**AWS KMS 액세스 키 감사**
CloudTrail 로그를 사용하여 AWS KMS 키에 대한 액세스를 감사할 수 있습니다. AWS KMS작업 `CreateGrant`, `GenerateDataKeyWithoutPlaintext` 및 `Decrypt`를 확인할 수 있습니다. 또한 이러한 작업에서는 CloudTrail에서 로그인한 `EncryptionContext`의 일부로 `aws:ecs:clusterAccount` 및 `aws:ecs:clusterName`도 표시합니다.
다음은 `GenerateDataKeyWithoutPlaintext`, `GenerateDataKeyWithoutPlaintext (DryRun)`, `CreateGrant`, `CreateGrant (DryRun)`, `RetireGrant`에 대한 CloudTrail 이벤트 예제입니다(*빨간색* 값을 자체 값으로 바꿈).
------
#### [ GenerateDataKeyWithoutPlaintext ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"numberOfBytes": 64,
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxxxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ GenerateDataKeyWithoutPlaintext (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"dryRun": true,
"numberOfBytes": 64,
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"retiringPrincipal": "ec2.us-west-2.amazonaws.com"
},
"responseElements": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"dryRun": true,
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ RetireGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "AWS Internal"
},
"eventTime": "2024-04-20T18:37:38Z",
"eventSource": "kms.amazonaws.com",
"eventName": "RetireGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": null,
"responseElements": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"additionalEventData": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
# Amazon ECS에서 AWS Fargate에 대한 태스크 사용 중지 및 유지 관리
AWS에서는 AWS Fargate의 기본 인프라를 유지 관리합니다. AWS에서는 플랫폼 버전 개정을 인프라의 새 개정으로 교체해야 하는 시기를 결정합니다. 이를 작업 사용 중지라고 합니다. AWS에서는 플랫폼 버전 개정이 사용 중지되면 작업 사용 중지 알림을 보냅니다. 지원되는 플랫폼 버전을 정기적으로 업데이트하여 Fargate 런타임 소프트웨어 및 운영 체제 및 컨테이너 런타임과 같은 기본 종속성에 대한 업데이트를 포함하는 새 개정을 도입합니다. 최신 개정이 사용 가능해지면 모든 고객 워크로드가 Fargate 플랫폼 버전의 최신 개정에서 실행되도록 하기 위해 이전 개정을 사용 중지합니다. 수정 버전이 사용 중지되면 해당 수정 버전에서 실행 중인 모든 작업은 중지됩니다.
Amazon ECS 작업은 서비스 작업 또는 독립 실행형 작업으로 분류할 수 있습니다. 서비스 작업은 서비스의 일부로 배포되고 Amazon ECS 일정에서 제어합니다. 자세한 내용은 [Amazon ECS 서비스](ecs_services.md) 섹션을 참조하세요. 독립 실행형 작업은 예약된 작업(Amazon EventBridge에서 시작), AWS Batch 또는 AWS Step Functions와 같은 외부 스케줄러에서 시작하거나 직접 Amazon ECS `RunTask` API에서 시작하는 작업입니다. Amazon ECS 스케줄러가 자동으로 태스크를 대체하므로 서비스 태스크에 대한 태스크 사용 중지에 대응하여 어떤 조치도 취할 필요가 없습니다.
독립 실행형 태스크의 경우 태스크 사용 중지에 대응하여 추가적인 처리를 수행해야 할 수도 있습니다. 자세한 내용은 [Amazon ECS에서 독립 실행형 작업을 자동으로 처리할 수 있나요?](#task-retirement-standalone-tasks) 섹션을 참조하세요.
서비스 태스크의 경우 AWS 전에 먼저 이러한 태스크를 대체하지 않는 한, 태스크 사용 중지에 대한 어떤 조치도 취할 필요가 없습니다. Amazon ECS 스케줄러에서 태스크를 중지하는 경우 `maximumPercent`를 사용하며, 원하는 서비스 개수를 유지하기 위해 새 태스크를 시작합니다. 모범 사례를 따라 태스크 사용 중지의 영향을 최소화합니다. REPLICA 서비스 스케줄러를 사용하는 서비스의 기본 `maximumPercent` 값은 200%입니다. 따라서 AWS Fargate가 태스크 사용 중지를 시작하면 Amazon ECS는 먼저 새 태스크를 예약한 다음 해당 태스크가 실행될 때까지 기다렸다가 이전 태스크를 사용 중지합니다. `maximumPercent` 값을 100%로 설정하면 Amazon ECS에서는 태스크를 먼저 중지한 다음에 바꿉니다.
독립 실행형 작업 사용 중지의 경우 AWS에서 작업 사용 중지 날짜 또는 이후에 작업을 중지합니다. Amazon ECS는 태스크가 중지될 때 대체 태스크를 시작하지 않습니다. 이러한 작업을 계속 실행해야 하는 경우 알림에 표시된 시간 이전에 실행 중인 작업을 중지하고 대체 작업을 시작해야 합니다. 따라서 고객은 독립 실행형 작업의 상태를 모니터링하고 필요한 경우 중지된 작업을 대체하는 로직을 구현하는 것이 좋습니다.
어떤 시나리오에서든 작업이 중지되면 `describe-tasks`를 실행할 수 있습니다. 응답의 `stoppedReason`은 `ECS is performing maintenance on the underlying infrastructure hosting the task`입니다.
새 플랫폼 버전 개정을 새 개정으로 교체해야 하는 경우 작업 유지 관리가 적용됩니다. 기본 Fargate 호스트에 문제가 있는 경우 Amazon ECS는 작업 사용 중지 통지 없이 호스트를 교체합니다.
## 태스크 사용 중지 공지 개요
AWS에서 플랫폼 버전 개정을 사용 중지해야 한다고 표시하면 모든 리전에서 해당 플랫폼 버전 개정에서 실행 중인 모든 태스크를 식별합니다.
다음 그림은 새로운 개정 출시부터 플랫폼 개정 사용 중지까지 Fargate 플랫폼 버전 개정의 수명 주기를 보여줍니다.
![\[Fargate 태스크 사용 중지 수명 주기를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/fargate-task-retirement.png)
다음 정보는 세부 사항을 제공합니다.
+ 새 플랫폼 버전 개정이 시작되면 모든 새 태스크는 이 개정에 따라 예약됩니다.
+ 예약되어 실행 중인 기존 태스크는 태스크 기간 동안 원래 적용되었던 개정에 그대로 유지되며 새 개정으로 마이그레이션되지 않습니다.
+ 예를 들어 서비스 업데이트 또는 Fargate 태스크 사용 중지와 같은 새로운 태스크는 출시 시점에 사용 가능한 최신 플랫폼 버전 개정에 따라 배치됩니다.
태스크 사용 중지 알림은 AWS Health 대시보드 및 등록된 이메일 주소로의 이메일을 통해 전송되며, 여기에는 다음 정보가 포함됩니다.
+ 작업 사용 중지 날짜 - 이 날짜 또는 이후에 작업이 중지됩니다.
+ 독립 실행형 작업의 경우 작업의 ID
+ 서비스 작업의 경우 서비스가 실행되는 클러스터의 ID와 서비스의 ID
+ 수행해야 하는 다음 단계
일반적으로 각 AWS 리전에서 서비스 및 독립 실행형 작업에 대해 각각 하나의 알림을 보냅니다. 하지만 경우에 따라 각 작업 유형에 대해 두 개 이상의 이벤트를 수신할 수 있습니다. 예를 들어 사용 중지할 작업이 너무 많아 알림 메커니즘의 한도를 초과하는 경우가 이에 해당합니다.
사용 중지가 예약된 작업은 다음과 같은 방법으로 식별할 수 있습니다.
+ Health Dashboard은
AWS Health 알림은 Amazon Storage Service와 같은 아카이브 스토리지에 대한 Amazon EventBridge, AWS Lambda 함수 실행과 같은 자동화된 작업 수행 또는 Amazon Simple Notification Service와 같은 기타 알림 시스템을 통해 전송될 수 있습니다. 자세한 내용을 알아보려면 [Amazon EventBridge를 사용하여 AWS Health 이벤트 모니터링](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)을 참조하세요. Amazon Chime, Slack 또는 Microsoft Teams에 알림을 보내기 위한 샘플 구성은 GitHub의 [AWS Health Aware](https://github.com/aws-samples/aws-health-aware) 리포지토리를 참조하세요.
다음은 샘플 EventBridge 이벤트입니다.
```
{
"version": "0",
"id": "3c268027-f43c-0171-7425-1d799EXAMPLE",
"detail-type": "AWS Health Event",
"source": "aws.health",
"account": "123456789012",
"time": "2023-08-16T23:18:51Z",
"region": "us-east-1",
"resources": [
"cluster|service",
"cluster|service"
],
"detail": {
"eventArn": "arn:aws:health:us-east-1::event/ECS/AWS_ECS_TASK_PATCHING_RETIREMENT/AWS_ECS_TASK_PATCHING_RETIREMENT_test1",
"service": "ECS",
"eventScopeCode": "ACCOUNT_SPECIFIC",
"communicationId": "7988399e2e6fb0b905ddc88e0e2de1fd17e4c9fa60349577446d95a18EXAMPLE",
"lastUpdatedTime": "Wed, 16 Aug 2023 23:18:52 GMT",
"eventRegion": "us-east-1",
"eventTypeCode": "AWS_ECS_TASK_PATCHING_RETIREMENT",
"eventTypeCategory": "scheduledChange",
"startTime": "Wed, 16 Aug 2023 23:18:51 GMT",
"endTime": "Fri, 18 Aug 2023 23:18:51 GMT",
"eventDescription": [
{
"language": "en_US",
"latestDescription": "\\nA software update has been deployed to Fargate which includes CVE patches or other critical patches. No action is required on your part. All new tasks launched automatically uses the latest software version. For existing tasks, your tasks need to be restarted in order for these updates to apply. Your tasks running as part of the following ECS Services will be automatically updated beginning Wed, 16 Aug 2023 23:18:51 GMT.\\n\\nAfter Wed, 16 Aug 2023 23:18:51 GMT, the ECS scheduler will gradually replace these tasks, respecting the deployment settings for your service. Typically, services should see little to no interruption during the update and no action is required. When AWS stops tasks, AWS uses the minimum healthy percent (1) and launches a new task in an attempt to maintain the desired count for the service. By default, the minimum healthy percent of a service is 100 percent, so a new task is started first before a task is stopped. Service tasks are routinely replaced in the same way when you scale the service or deploy configuration changes or deploy task definition revisions. If you would like to control the timing of this restart you can update the service before Wed, 16 Aug 2023 23:18:51 GMT, by running the update-service command from the ECS command-line interface specifying force-new-deployment for services using Rolling update deployment type. For example:\\n\\n$ aws ecs update-service -service service_name \\\n--cluster cluster_name -force-new-deployment\\n\\nFor services using Blue/Green deployment type with AWS CodeDeploy:\\nPlease refer to create-deployment document (2) and create new deployment using same task definition revision.\\n\\nFor further details on ECS deployment types, please refer to ECS Deployment Developer Guide (1).\\nFor further details on Fargate's update process, please refer to the AWS Fargate User Guide (3).\\nIf you have any questions or concerns, please contact AWS Support (4).\\n\\n(1) https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html\\n(2) https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html\\n(3) https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-maintenance.html\\n(4) https://aws.amazon.com/support\\n\\nA list of your affected resources(s) can be found in the 'Affected resources' tab in the 'Cluster/ Service' format in the AWS Health Dashboard. \\n\\n"
}
],
"affectedEntities": [
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c23333"
},
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c25555"
}
}
]
}
}
```
+ 이메일
AWS 계정 ID에 대해 등록된 이메일로 이메일이 전송됩니다.
태스크 사용 중지를 준비하는 방법에 대한 자세한 내용은 [Amazon ECS에서 AWS Fargate 태스크 사용 중지 준비](prepare-task-retirement.md) 섹션을 참조하세요.
## 태스크 사용 중지를 옵트아웃할 수 있나요?
아니요. AWS 공동 책임 모델의 일부로, AWS는 AWS Fargate의 기본 인프라를 관리하고 유지 보수할 책임이 있습니다. 여기에는 보안과 안정성을 보장하기 위한 주기적인 플랫폼 업데이트 수행이 포함됩니다. 이러한 업데이트는 AWS에 의해 자동으로 적용되며 고객이 옵트아웃할 수 없습니다. 이는 EC2 인스턴스에서 워크로드를 실행할 때와 비교하여 AWS에서 기본 플랫폼 유지 관리를 처리한다는 점에서 AWS Fargate를 사용할 때의 주요 이점입니다. 이 모델을 사용하면 인프라 유지 관리가 아닌 애플리케이션에 집중할 수 있습니다. AWS는 이러한 플랫폼 업데이트를 자동으로 적용함으로써 고객이 별도의 조치를 취하지 않아도 Fargate 환경을 최신 상태로 안전하게 유지할 수 있습니다. 따라서 Fargate에서 워크로드를 실행하기 위한 안정적이고 안전한 컨테이너화된 환경을 제공하는 데 도움이 됩니다.
## 다른 AWS 서비스를 통해 작업 사용 중지 알림을 받을 수 있나요?
AWS에서는 Health Dashboard 및 AWS 계정의 기본 이메일 연락처로 작업 사용 중지 알림을 보냅니다. Health Dashboard에서는 EventBridge를 비롯한 다른 AWS 서비스와의 다양한 통합을 제공합니다. EventBridge를 사용하여 통지 가시성을 자동화할 수 있습니다(예: 메시지를 ChatOps 도구로 전달). 자세한 내용은 [Solution overview: Capturing task retirement notifications](https://aws.amazon.com/blogs/containers/improving-operational-visibility-with-aws-fargate-task-retirement-notifications/)를 참조하세요.
## 태스크 사용 중지가 예약된 이후에 태스크 사용 중지를 변경할 수 있나요?
아니요. 해당 일정은 기본값 7일인 태스크 사용 중지 대기 시간을 기준으로 설정됩니다. 시간이 더 필요한 경우 대기 시간을 14일로 구성할 수 있습니다. 자세한 내용은 [2단계: 태스크 사용 중지 알림을 캡처하여 팀에 알리고 조치 취하기](prepare-task-retirement.md#prepare-task-retirement-capture-task-events) 섹션을 참조하세요.
2025년 12월 18일부터 Amazon ECS에서는 Fargate 작업에 대해 [Amazon EC2 이벤트 기간](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html)을 구성할 수 있습니다. 사용 중지 시간을 정확하게 제어해야 하는 경우, 예를 들어 업무 시간 중 서비스 중단을 피하기 위해 주말에 사용 중지를 예약하고자 할 때, 태스크, 서비스 또는 클러스터에 대해 Amazon EC2 이벤트 기간을 구성할 수 있습니다([1단계: 태스크 대기 시간 설정 또는 Amazon EC2 이벤트 기간 사용](prepare-task-retirement.md#prepare-task-retirement-set-time) 참조). 이 구성의 변경 내용은 향후 예약될 사용 중지에만 적용됩니다. 현재 예약된 사용 중지는 영향을 받지 않습니다. 또한 Fargate 태스크에 대해 Amazon EC2 이벤트 기간을 구성하면, 태스크 사용 중지 대기 시간 설정보다 우선적으로 적용됩니다. 추가 문의 사항이 있는 경우 지원에 문의하세요.
## Amazon ECS는 서비스의 일부인 태스크를 어떻게 처리하나요?
서비스 태스크의 경우 AWS 전에 먼저 이러한 태스크를 대체하지 않는 한, 태스크 사용 중지에 대응하여 어떤 조치도 취할 필요가 없습니다. Amazon ECS 스케줄러에서 태스크를 중지하는 경우 최소 정상 상태 백분율을 사용하며, 원하는 서비스 개수를 유지하기 위해 새 작업을 시작합니다. Fargate 사용 중지의 영향을 최소화하려면 Amazon ECS 모범 사례에 따라 워크로드를 배포해야 합니다. 예를 들어, 상태 비저장 애플리케이션을 웹 또는 API 서버와 같은 Amazon ECS 서비스로 배포하는 경우, 고객은 여러 개의 태스크 복제본을 배포하고 minimumHealthyPercent를 100%로 설정해야 합니다. 기본적으로 서비스의 최소 상태 백분율은 100%입니다. 따라서 Fargate가 태스크 사용 중지를 시작하면 Amazon ECS는 먼저 새 태스크를 예약한 다음 해당 태스크가 실행될 때까지 기다렸다가 이전 태스크를 사용 중지합니다. 태스크 사용 중지의 일환으로 서비스 태스크는 서비스 규모를 조정하거나 구성 변경 내용을 배포하거나 태스크 정의 개정을 배포할 때 동일한 방식으로 정기적으로 대체됩니다. 태스크 사용 중지 프로세스를 준비하려면 [Amazon ECS에서 AWS Fargate 태스크 사용 중지 준비](prepare-task-retirement.md) 섹션을 참조하세요.
## Amazon ECS에서 독립 실행형 작업을 자동으로 처리할 수 있나요?
아니요. AWS에서는 `RunTask`, 예약된 작업(예: EventBridge 스케줄러를 통해), AWS Batch 또는 AWS Step Functions에 의해 시작된 독립 실행형 작업에 대한 대체 작업을 생성할 수 없습니다. Amazon ECS는 서비스의 일부인 작업만 관리합니다.
## 태스크 사용 중지 중 서비스 가용성 문제 해결
Amazon ECS가 태스크 사용 중지 중에 대체 태스크를 시작할 수 없는 경우 서비스 가용성에 영향을 미칠 수 있습니다. 이는 다음과 같은 잘못된 고객 구성으로 인해 발생할 수 있습니다.
+ 누락되었거나 잘못 구성된 IAM 역할
+ 대상 서브넷의 용량 부족
+ 보안 그룹 구성 오류
+ 태스크 정의 오류
Amazon ECS가 대체 태스크를 시작할 수 없는 경우 사용 중지된 태스크가 대체 없이 중지되므로 서비스의 사용 가능한 용량이 줄어들고 잠재적으로 서비스 중단이 발생할 수 있습니다. 서비스의 태스크 수와 Amazon CloudWatch 지표를 모니터링하여 사용 중지 이벤트 중에 대체 태스크가 성공적으로 시작되도록 합니다.
# Amazon ECS에서 AWS Fargate 태스크 사용 중지 준비
태스크 사용 중지를 준비하려면 다음 작업을 수행하세요.
1. 태스크 사용 중지 대기 시간을 설정하거나 Amazon EC2 이벤트 기간을 사용합니다.
1. 태스크 사용 중지 알림을 캡처하여 팀원에게 알릴 수 있습니다.
1. 서비스 업데이트 시 force-deployment 옵션을 사용하여 서비스의 모든 태스크가 최신 플랫폼 개정에서 실행되도록 할 수 있습니다. 이 단계는 선택 사항입니다.
## 1단계: 태스크 대기 시간 설정 또는 Amazon EC2 이벤트 기간 사용
Fargate가 태스크 사용 중지를 시작하는 시간을 구성하는 계정 설정 옵션은 `fargateTaskRetirementWaitPeriod` 및 `fargateEventWindows`입니다.
**fargateTaskRetirementWaitPeriod 계정 설정 사용**
Fargate에서 작업 사용 중지를 시작하는 시간을 구성할 수 있습니다. 기본 대기 기간은7일입니다. 업데이트를 즉시 적용해야 하는 워크로드의 경우 즉시 설정(`0`)을 선택합니다. 시간이 더 필요한 경우 `7` 또는 `14`일 옵션을 구성할 수 있습니다.
최신 플랫폼 수정 버전을 더 빨리 받으려면 짧은 대기 기간을 선택하는 것이 좋습니다.
`put-account-setting-default` 또는 `put-account-setting`을 루트 사용자 또는 관리 사용자로 실행하여 대기 기간을 구성합니다. `name`에는 `fargateTaskRetirementWaitPeriod` 옵션을 사용하고 `value` 옵션을 다음 값 중 하나로 설정합니다.
+ `0` - AWS는 알림을 보내고 영향을 받은 작업을 즉시 사용 중지합니다.
+ `7` - AWS는 알림을 보내고 7일 기다린 후 영향을 받은 작업을 사용 중지합니다. 이 값이 기본값입니다.
+ `14` - AWS는 알림을 보내고 14일 기다린 후 영향을 받은 작업을 사용 중지합니다.
자세한 내용은 *Amazon Elastic Container Service API 참조*의 [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html) 및 [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)을 참조하세요.
**fargateEventWindows 계정 설정 사용**
2025년 12월 18일부터 Amazon ECS에서는 Fargate 작업에 대해 [Amazon EC2 이벤트 기간](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html)을 구성할 수 있습니다. 사용 중지 시간을 정확하게 제어해야 하는 경우, 예를 들어 업무 시간 중 서비스 중단을 피하기 위해 주말에 사용 중지를 예약하고자 할 때, 태스크, 서비스 또는 클러스터에 대해 Amazon EC2 이벤트 기간을 구성할 수 있습니다.
이벤트 기간을 사용하는 경우, Fargate는 사용자 조치로 중지되거나 하드웨어 성능 저하와 같은 치명적인 상태 이벤트가 발생하지 않는 한, 태스크가 다음 사용 가능한 이벤트 기간 내에서 사용 중지되기 전 최소 3일 이상 실행되도록 보장합니다.
`fargateEventWindows` 계정 설정을 `enabled`로 설정합니다. 이 설정은 루트 사용자 또는 관리자 권한이 있는 사용자 계정으로 다음 API 중 하나를 사용하여 구성할 수 있습니다. `put-account-setting-default` 또는 `put-account-setting`.
각 Amazon EC2 이벤트 기간은 주당 최소 4시간 이상 열려 있어야 하며, 각 시간 범위는 최소 2시간이어야 합니다. 대규모 클러스터 및 서비스의 경우, 이벤트 기간을 길게 설정(8시간 이상)하거나 최소 3일마다 한 번씩 발생하는 더 잦은 시간 범위를 구성하는 것을 권장합니다. Amazon EC2 이벤트 기간과 관련된 추가 고려 사항은 [사용 설명서](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html#event-windows-considerations)에서 확인할 수 있습니다. AWS Fargate는 사용자 조치로 중지되거나 하드웨어 성능 저하와 같은 치명적인 상태 이벤트가 발생하지 않는 한, 태스크가 사용 중지되기 전 최소 3일 이상 실행되도록 보장합니다.
**중요**
이벤트 기간 내에 태스크를 교체하는 것이 최선입니다. 이벤트 기간 외에 태스크가 사용 중지되는 것이 관찰되면 이벤트 기간을 늘리거나(8시간 이상) 빈도를 높이는 것(최소 3일마다 한 번)을 고려해야 합니다.
Fargate 태스크 사용 중지에 Amazon EC2 이벤트 기간을 적용하려면:
+ `fargateEventWindows` 계정 설정을 `enabled`로 설정합니다. 이 설정은 루트 사용자 또는 관리자 권한이 있는 사용자 계정으로 다음 API 중 하나를 사용하여 구성할 수 있습니다. `put-account-setting-default` 또는 `put-account-setting`. 이 설정은 Fargate 태스크에서 Amazon EC2 이벤트 기간 기능을 사용하기 위한 기능으로, 한 번만 활성화됩니다.
+ AWS 콘솔 또는 AWS CLI를 통해 Amazon EC2 이벤트 기간을 생성합니다. CLI에서 이벤트 기간을 생성하려면 EC2 `create-instance-event-window` API를 사용하며, 시간 범위 또는 cron 표현식을 지정할 수 있습니다. 응답에서 반환되는 `InstanceEventWindowId`를 기록합니다.
```
aws ec2 create-instance-event-window \
--time-range StartWeekDay=monday,StartHour=2,EndWeekDay=wednesday,EndHour=8 \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
또는 cron 표현식을 사용하여 EC2 이벤트 기간을 생성할 수 있습니다.
```
aws ec2 create-instance-event-window \
--cron-expression "* 21-23 * * 2,3" \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
+ 그런 다음 EC2 `associate-instance-event-window` API를 사용하여 이벤트 기간을 특정 서비스, 클러스터 또는 계정 내 모든 태스크와 연결할 수 있습니다.
+ ECS 서비스 태스크의 경우
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=your-service-arn}]"
```
+ ECS 클러스터의 경우
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=your-cluster-arn}]"
```
+ 이벤트 기간을 계정 내 모든 태스크와 연결하려면
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]"
```
여러 개의 키-값 쌍을 사용하여 여러 서비스 또는 클러스터에 이벤트 기간을 연결할 수 있습니다.
Fargate는 다음 순서로 각 태스크에 대한 이벤트 기간을 선택합니다.
+ 태스크 서비스에 연결된 이벤트 기간이 있으면 사용합니다. 독립형 태스크 또는 비관리형 태스크에는 적용되지 않습니다.
+ 태스크의 클러스터에 연결된 이벤트 기간이 있으면 사용합니다.
+ 모든 Fargate 태스크에 설정된 이벤트 기간이 있으면 사용합니다.
+ 태스크에 해당하는 이벤트 기간이 없으면 `fargateTaskRetirementWaitPeriod` 설정이 적용됩니다.
** Fargate 태스크 유지 관리를 위한 이벤트 기간 구성**
여러 ECS 서비스를 운영하며 서로 다른 가용성 요구 사항이 있는 경우, 정밀한 태스크 사용 중지 제어가 필요합니다. 다음과 같이 여러 이벤트 기간을 구성할 수 있습니다.
+ **모든 Fargate 태스크 기본 유지 관리**: 사용량이 적은 시간대(매일 자정 12시\$1오전 4시)에 루틴 유지 관리용 이벤트 기간을 생성하고, ` aws:ecs:fargateTask` 태그를 사용하여 모든 Fargate 태스크와 연결합니다.
+ **개발 클러스터 주말 전용 유지 관리**: 주말 중단이 허용되는 서비스가 있는 개발 클러스터의 경우, 24시간 주말 기간(토요일\$1일요일, 종일)을 생성하고, 클러스터 ARN과 함께 `aws:ecs:clusterArn` 태그로 클러스터에 연결합니다.
+ **미션 크리티컬 서비스의 제한된 기간**: 평일 높은 가동 시간이 필요한 미션 크리티컬 결제 처리 서비스의 경우, 유지 관리를 주말 이른 아침(토\$1일, 자정 12시\$1오전 4시)으로 제한하고, 서비스 ARN과 함께 `aws:ecs:serviceArn` 태그로 특정 서비스에 연결합니다.
이렇게 구성하면 결제 서비스는 주말 전용 이벤트 기간을 사용하고, 개발 클러스터 서비스 및 태스크는 주말 24시간 기간을 사용하며, 나머지 Fargate 태스크는 기본 일일 유지 관리 기간을 사용합니다.
자세한 내용은 *Amazon Elastic Container Service API 참조*의 [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html) 및 [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)을 참조하세요.
## 2단계: 태스크 사용 중지 알림을 캡처하여 팀에 알리고 조치 취하기
태스크 사용 중지가 예정되어 있으면 AWS는 AWS Health Dashboard와 AWS 계정의 기본 이메일 연락처로 태스크 사용 중지 알림을 보냅니다. AWS Health Dashboard에서는 Amazon EventBridge를 비롯한 다른 AWS 서비스와의 다양한 통합을 제공합니다. EventBridge를 사용하여 태스크 사용 중지 알림에서 자동화를 구축할 수 있습니다. 예를 들어, 메시지를 ChatOps 도구로 전달하여 예정된 사용 중지의 가시성을 높입니다. AWS Health 인식은 AWS Health Dashboard의 기능과 조직 전체에 알림을 배포할 수 있는 방법을 보여주는 리소스입니다. 태스크 사용 중지 알림을 Slack과 같은 채팅 애플리케이션으로 전달할 수 있습니다.
다음 그림은 솔루션 개요를 보여줍니다.
![\[Fargate 태스크 사용 중지 공지를 캡처하기 위한 Fargate 솔루션을 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/fargate-task-retirement-solution.png)
다음 정보는 세부 사항을 제공합니다.
+ Fargate는 AWS Health Dashboard에 태스크 사용 중지 알림을 보냅니다.
+ AWS Health Dashboard는 AWS 계정의 기본 이메일 연락처로 메일을 전송하고 EventBridge에 알립니다.
+ EventBridge에는 사용 중지 알림을 캡처하는 규칙이 있습니다.
이벤트 세부 정보 유형: `"AWS Health Event" and the Event Detail Type Code: "AWS_ECS_TASK_PATCHING_RETIREMENT"`의 이벤트를 찾는 규칙
+ 규칙은 Slack 수신 Webhook를 사용하여 정보를 Slack으로 전달하는 Lambda 함수를 트리거합니다. 자세한 내용은 [수신 웹후크](https://slack.com/marketplace/A0F7XDUAZ-incoming-webhooks)를 참조하세요.
코드 예제는 Github의 [Capturing AWS Fargate Task Retirement Notifications](https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications/tree/main)를 참조하세요.
## 3단계: 태스크 대체 제어
태스크 사용 중지의 정확한 타이밍을 제어할 수는 없지만 대기 시간을 정의할 수는 있습니다. 원하는 일정에 따라 태스크를 대체하는 것을 제어하려면 태스크 사용 중지 공지를 캡처하여 태스크 사용 중지 날짜를 먼저 파악하면 됩니다. 그런 다음 서비스를 다시 배포하여 대체 태스크를 시작하고 독립 실행형 태스크도 마찬가지로 대체할 수 있습니다. 롤링 배포를 사용하는 서비스의 경우 사용 중지 시작 시간 전에 `force-deployment` 옵션과 함께 `update-service`를 사용하여 서비스를 업데이트합니다.
다음 `update-service` 예제에서는 `force-deployment` 옵션을 사용합니다.
```
aws ecs update-service —-service service_name \
--cluster cluster_name \
--force-new-deployment
```
블루/그린 배포를 사용하는 서비스의 경우 AWS CodeDeploy에서 새 배포를 생성해야 합니다. 배포를 생성하는 방법에 대한 자세한 내용은 **AWS Command Line Interface 참조의 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)를 참조하세요.
# AWS Fargate의 Amazon ECS에 대해 지원되는 리전
다음 테이블을 사용하여 AWS Fargate의 Linux 컨테이너 및 AWS Fargate의 Windows 컨테이너에 대한 리전 지원을 확인할 수 있습니다.
## AWS Fargate의 Linux 컨테이너
AWS Fargate의 Amazon ECS Linux 컨테이너는 다음 AWS 리전에서 지원됩니다. 지원되는 가용 영역 ID는 해당되는 경우 명시되어 있습니다.
| 리전 이름 | 리전 |
| --- | --- |
| 미국 동부(오하이오) | us-east-2 |
| 미국 동부(버지니아 북부) | us-east-1 |
| 미국 서부(캘리포니아 북부) | us-west-1(`usw1-az1` 및 `usw1-az3`만 해당) |
| 미국 서부(오레곤) | us-west-2 |
| 캐나다(중부) | ca-central-1 |
| 캐나다 서부(캘거리) | ca-west-1 |
| 멕시코(중부) | mx-central-1 |
| 아프리카(케이프타운) | af-south-1 |
| 아시아 태평양(홍콩) | ap-east-1 |
| 아시아 태평양(뭄바이) | ap-south-1 |
| 아시아 태평양(도쿄) | ap-northeast-1(`apne1-az1`, `apne1-az2`, `apne1-az4`만 해당) |
| 아시아 태평양(서울) | ap-northeast-2 |
| 아시아 태평양(오사카) | ap-northeast-3 |
| 아시아 태평양(하이데라바드) | ap-south-2 |
| 아시아 태평양(싱가포르) | ap-southeast-1 |
| 아시아 태평양(시드니) | ap-southeast-2 |
| 아시아 태평양(태국) | ap-southeast-7 |
| 아시아 태평양(자카르타) | ap-southeast-3 |
| 아시아 태평양(멜버른) | ap-southeast-4 |
| 아시아 태평양(말레이시아) | ap-southeast-5 |
| 캐나다(중부) | ca-central-1 |
| 캐나다 서부(캘거리) | ca-west-1 |
| 중국(베이징) | cn-north-1(`cnn1-az1` 및 `cnn1-az2`만 해당) |
| 중국(닝샤) | cn-northwest-1 |
| 유럽(프랑크푸르트) | eu-central-1 |
| 유럽(취리히) | eu-central-2 |
| 유럽(아일랜드) | eu-west-1 |
| 유럽(런던) | eu-west-2 |
| 유럽(파리) | eu-west-3 |
| 유럽(밀라노) | eu-south-1 |
| 유럽(스페인) | eu-south-2 |
| 유럽(스톡홀름) | eu-north-1 |
| 남아메리카(상파울루) | sa-east-1 |
| 이스라엘(텔아비브) | il-central-1 |
| 중동(바레인) | me-south-1 |
| 중동(UAE) | me-central-1 |
| AWS GovCloud(미국 동부) | us-gov-east-1 |
| AWS GovCloud(미국 서부) | us-gov-west-1 |
## AWS Fargate의 Windows 컨테이너
AWS Fargate의 Amazon ECS Windows 컨테이너는 다음 AWS 리전에서 지원됩니다. 지원되는 가용 영역 ID는 해당되는 경우 명시되어 있습니다.
| 리전 이름 | 리전 |
| --- | --- |
| 미국 동부(오하이오) | us-east-2 |
| 미국 동부(버지니아 북부) | us-east-1(`use1-az1`, `use1-az2`, `use1-az4`, `use1-az5` 및 `use1-az6`만 해당) |
| 미국 서부(캘리포니아 북부) | us-west-1(`usw1-az1` 및 `usw1-az3`만 해당) |
| 미국 서부(오레곤) | us-west-2 |
| 아프리카(케이프타운) | af-south-1 |
| 아시아 태평양(홍콩) | ap-east-1 |
| 아시아 태평양(뭄바이) | ap-south-1 |
| 아시아 태평양(하이데라바드) | ap-south-2 |
| 아시아 태평양(오사카) | ap-northeast-3 |
| 아시아 태평양(서울) | ap-northeast-2 |
| 아시아 태평양(싱가포르) | ap-southeast-1 |
| 아시아 태평양(시드니) | ap-southeast-2 |
| 아시아 태평양(멜버른) | ap-southeast-4 |
| 아시아 태평양(말레이시아) | ap-southeast-5 |
| 아시아 태평양(도쿄) | ap-northeast-1(`apne1-az1`, `apne1-az2`, `apne1-az4`만 해당) |
| 캐나다(중부) | ca-central-1(`cac1-az1` 및 `cac1-az2`만 해당) |
| 캐나다 서부(캘거리) | ca-west-1 |
| 중국(베이징) | cn-north-1(`cnn1-az1` 및 `cnn1-az2`만 해당) |
| 중국(닝샤) | cn-northwest-1 |
| 유럽(프랑크푸르트) | eu-central-1 |
| 유럽(취리히) | eu-central-2 |
| 유럽(아일랜드) | eu-west-1 |
| 유럽(런던) | eu-west-2 |
| 유럽(파리) | eu-west-3 |
| 유럽(밀라노) | eu-south-1 |
| 유럽(스페인) | eu-south-2 |
| 유럽(스톡홀름) | eu-north-1 |
| 남아메리카(상파울루) | sa-east-1 |
| 이스라엘(텔아비브) | il-central-1 |
| 중동(UAE) | me-central-1 |
| 중동(바레인) | me-south-1 |