# EC2에 대한 Amazon ECS 태스크 네트워킹 옵션
Amazon EC2 인스턴스에서 호스팅되는 Amazon ECS 태스크의 네트워킹 동작은 태스크 정의에 정의된 *네트워크 모드*에 따라 다릅니다. 다른 네트워크 모드를 사용해야 할 특별한 필요가 있지 않는 한 `awsvpc` 네트워크 모드를 사용하는 것이 좋습니다.
사용 가능한 네트워크 모드는 다음과 같습니다.
| 네트워크 모드 | EC2에서의 Linux 컨테이너 | EC2에서의 Windows 컨테이너 | 설명 |
| --- | --- | --- | --- |
| `awsvpc` | 예 | 예 | 태스크에 고유한 탄력적 네트워크 인터페이스(ENI)와 기본 프라이빗 IPv4 또는 IPv6 주소가 할당됩니다. 이렇게 하면 태스크에 Amazon EC2 인스턴스와 동일한 네트워킹 속성이 적용됩니다. |
| `bridge` | 예 | 아니요 | 태스크는 태스크를 호스팅하는 각 Amazon EC2 인스턴스 내부에서 실행되는 Docker의 기본 가상 네트워크를 이용합니다. Linux의 기본 가상 네트워크는 `bridge` Docker 네트워크 드라이버를 사용합니다. 이는 작업 정의에 네트워크 모드가 지정되지 않았을 때의 Linux의 기본 네트워크 모드입니다. |
| `host` | 예 | 아니요 | 태스크는 해당 태스크를 호스팅하는 Amazon EC2 인스턴스의 ENI에 컨테이너 포트를 직접 매핑하여 Docker의 기본 가상 네트워크를 우회하는 호스트 네트워크를 사용합니다. 이 네트워크 모드에서는 동적 포트 매핑을 사용할 수 없습니다. 이 모드를 사용하는 작업 정의의 컨테이너는 특정`hostPort` 숫자를 지정해야 합니다. 호스트의 포트 번호는 여러 작업에서 사용할 수 없습니다. 따라서 단일 Amazon EC2 인스턴스에서 같은 태스크 정의를 가진 여러 태스크를 실행할 수 없습니다. |
| `none` | 예 | 아니요 | 태스크에 외부 네트워크 연결이 없습니다. |
| `default` | 아니요 | 예 | 태스크는 태스크를 호스팅하는 각 Amazon EC2 인스턴스 내부에서 실행되는 Windows에서의 Docker 기본 가상 네트워크를 이용합니다. Windows의 기본 가상 네트워크는`nat` Docker 네트워크 드라이버를 사용합니다. 이는 작업 정의에서 네트워크 모드가 지정되지 않았을 때의 Windows의 기본 네트워크 모드입니다. |
Linux에서의 Docker 네트워킹에 대한 자세한 내용은 *Docker 설명서*의 [Networking overview](https://docs.docker.com/engine/network/)를 참조하세요.
Windows에서의 Docker 네트워킹에 대한 자세한 내용은 Microsoft *Containers on Windows 설명서*의 [Windows container networking](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture)을 참조하세요.
## IPv6 전용 모드에서 VPC 사용
IPv6 전용 구성에서 Amazon ECS 태스크는 IPv6에서만 통신합니다. IPv6 전용 구성에 대해 VPC 및 서브넷을 설정하려면 VPC에 IPv6 CIDR 블록을 추가하고 IPv6 CIDR 블록만 포함하는 새 서브넷을 생성해야 합니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [VPC에 대한 IPv6 지원 추가](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) 및 [서브넷 생성](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)을 참조하세요.
또한 IPv6 대상으로 라우팅 테이블을 업데이트하고 IPv6 규칙으로 보안 그룹을 구성해야 합니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [라우팅 테이블 구성](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) 및 [보안 그룹 규칙 구성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)을 참조하세요.
다음 사항을 고려하세요.
+ IPv6 전용 서브넷을 사용하도록 서비스를 직접 업데이트하거나 병렬 IPv6 전용 서비스를 생성하고 Amazon ECS 블루/그린 배포를 사용해 트래픽을 새 서비스로 이전하여 IPv4 전용 또는 듀얼 스택 Amazon ECS 서비스를 IPv6 전용 구성으로 업데이트할 수 있습니다. Amazon ECS 블루/그린 배포에 대한 자세한 내용은 [Amazon ECS 블루/그린 배포](deployment-type-blue-green.md) 섹션을 참조하세요.
+ IPv6 전용 Amazon ECS 서비스는 IPv6 대상 그룹과 함께 듀얼 스택 로드 밸런서를 사용해야 합니다. Application Load Balancer 또는 Network Load Balancer를 사용하는 기존 Amazon ECS 서비스를 마이그레이션하는 경우 새 듀얼 스택 로드 밸런서를 생성하고 이전 로드 밸런서에서 트래픽을 이전하거나 기존 로드 밸런서의 IP 주소 유형을 업데이트할 수 있습니다.
Network Load Balancer에 대한 자세한 내용은 *Network Load Balancer 사용 설명서*의 [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) 및 [Update the IP address types for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html)를 참조하세요. Application Load Balancer에 대한 자세한 내용은 *Application Load Balancers 사용 설명서*의 [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) 및 [Update the IP address types for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html)를 참조하세요.
+ IPv6 전용 구성은 Windows에서 지원되지 않습니다. IPv6 전용 구성에서 태스크를 실행하려면 Amazon ECS 최적화 Linux AMI를 사용해야 합니다. Amazon ECS 최적화 Linux AMI에 대한 자세한 내용은 [Amazon ECS 최적화 Linux AMI](ecs-optimized_AMI.md) 섹션을 참조하세요.
+ IPv6 전용 구성에서 태스크를 실행하기 위해 컨테이너 인스턴스를 시작할 경우 `--enable-primary-ipv6` EC2 파라미터를 사용하여 인스턴스의 기본 IPv6 주소를 설정해야 합니다.
**참고**
기본 IPv6 주소가 없으면 호스트 또는 브리지 네트워크 모드의 컨테이너 인스턴스에서 실행되는 태스크가 로드 밸런서 또는 AWS Cloud Map에 등록되지 않습니다.
Amazon EC2 인스턴스 실행을 위한 `--enable-primary-ipv6`에 대한 자세한 내용은 *AWS CLI 명령 참조*의 [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html)를 참조하세요.
AWS Management Console을 사용하는 컨테이너 인스턴스 시작에 대한 자세한 내용은 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md) 섹션을 참조하세요.
+ 기본적으로 Amazon ECS 컨테이너 에이전트는 인스턴스의 기본 IPv4 및 IPv6 경로를 보고 IPv6 전용 구성에 대한 컨테이너 인스턴스의 호환성을 감지하려고 시도합니다. 이 동작을 재정의하려면 인스턴스 `/etc/ecs/ecs.config` 파일에서 ` ECS_INSTANCE_IP_COMPATIBILITY` 파라미터를 `ipv4` 또는 `ipv6`으로 설정할 수 있습니다.
+ 태스크는 버전 `1.99.1` 이상의 컨테이너 에이전트를 사용해야 합니다. 인스턴스에서 사용 중인 에이전트 버전을 확인하고 필요한 경우 업데이트하는 방법에 대한 자세한 내용은 [Amazon ECS 컨테이너 에이전트 업데이트](ecs-agent-update.md) 섹션을 참조하세요.
+ IPv6 전용 구성의 Amazon ECS 태스크가 IPv4 전용 엔드포인트와 통신하도록 하려면 IPv6에서 IPv4로의 네트워크 주소 변환을 위해 DNS64 및 NAT64를 설정할 수 있습니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [DNS64 및 NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html)를 참조하세요.
+ IPv6 전용 구성의 Amazon ECS 워크로드는 Amazon ECR에서 이미지를 가져올 때 Amazon ECR 듀얼 스택 이미지 URI 엔드포인트를 사용해야 합니다. 자세한 내용은 *Amazon Elastic Container Registry 사용 설명서*의 [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started)을 참조하세요.
**참고**
Amazon ECR은 IPv6 전용 구성의 태스크가 사용할 수 있는 듀얼 스택 인터페이스 VPC 엔드포인트를 지원하지 않습니다. 자세한 내용은 *Amazon Elastic Container Registry 사용 설명서*의 [Getting started with making requests over IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started)을 참조하세요.
+ Amazon ECS Exec는 IPv6 전용 구성에서 지원되지 않습니다.
### Amazon ECS에 대한 IPv6 전용 모드를 지원하는 AWS 리전
Amazon ECS를 사용할 수 있는 다음 AWS 리전에서 IPv6 전용 구성으로 태스크를 실행할 수 있습니다.
+ 미국 동부(오하이오)
+ 미국 동부(버지니아 북부)
+ 미국 서부(캘리포니아 북부)
+ 미국 서부(오리건)
+ 아프리카(케이프타운)
+ 아시아 태평양(홍콩)
+ 아시아 태평양(하이데라바드)
+ 아시아 태평양(자카르타)
+ 아시아 태평양(멜버른)
+ 아시아 태평양(뭄바이)
+ 아시아 태평양(오사카)
+ 아시아 태평양(서울)
+ 아시아 태평양(싱가포르)
+ 아시아 태평양(시드니)
+ 아시아 태평양(도쿄)
+ 캐나다(중부)
+ 캐나다 서부(캘거리)
+ 중국(베이징)
+ 중국(닝샤)
+ 유럽(프랑크푸르트)
+ 유럽(런던)
+ 유럽(밀라노)
+ 유럽(파리)
+ 유럽(스페인)
+ 이스라엘(텔아비브)
+ 중동(바레인)
+ 중동(UAE)
+ 남아메리카(상파울루)
+ AWS GovCloud(미국 동부)
+ AWS GovCloud(미국 서부)
# Amazon ECS 작업에 대한 네트워크 인터페이스 할당
`awsvpc` 네트워크 모드에서 제공하는 태스크 네트워킹 기능은 Amazon ECS 태스크에 Amazon EC2 인스턴스와 동일한 네트워킹 속성을 제공합니다. `awsvpc` 네트워크 모드를 사용하면 컨테이너 네트워킹을 간소화합니다. 애플리케이션이 서로 통신하는 방식과 VPC 내 다른 서비스와 통신하는 방식을 더 세부적으로 제어할 수 있기 때문입니다. 또한 `awsvpc` 네트워크 모드는 태스크 내에서 더 세부적으로 보안 그룹 및 네트워크 모니터링 도구를 사용 가능하게 만들어 컨테이너의 보안을 강화합니다. VPC 흐름 로그와 같은 기타 Amazon EC2 네트워킹 기능을 이용하여 작업에서 주고받는 트래픽을 모니터링할 수도 있습니다. 또한 같은 태스크에 속한 컨테이너는 `localhost` 인터페이스로 통신할 수 있습니다.
작업 탄력적 네트워크 인터페이스(ENI)는 Amazon ECS의 완전관리형 기능입니다. Amazon ECS는 ENI를 생성하고 지정된 보안 그룹이 있는 호스트 Amazon EC2 인스턴스에 이를 연결합니다. 태스크는 Amazon EC2 인스턴스가 기본 네트워크 인터페이스에서 하는 것과 동일한 방식으로 ENI에서 네트워크 트래픽을 보내고 받습니다. 각 태스크 ENI는 기본적으로 프라이빗 IPv4 주소가 할당됩니다. VPC가 듀얼 스택 모드를 사용하도록 설정되어 있고 IPv6 CIDR 블록과 함께 서브넷을 사용하는 경우 태스크 ENI도 IPv6 주소를 수신합니다. 각 태스크는 ENI를 하나만 가질 수 있습니다.
이 ENI는 계정의 Amazon EC2 콘솔에서 볼 수 있습니다. 계정은 ENI를 분리하거나 수정할 수 없습니다. 이는 실행 중인 태스크와 연결된 ENI가 우발적으로 삭제되는 일을 방지하기 위한 것입니다. Amazon ECS 콘솔 또는 [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) API 태스크를 통해 태스크에 대한 ENI 연결 정보를 볼 수 있습니다. 태스크가 중지되거나 서비스의 규모가 작아진 경우에는 태스크 ENI가 분리되고 삭제됩니다.
ENI 밀도를 높여야 하는 경우 `awsvpcTrunking` 계정 설정을 사용합니다. 또한 Amazon ECS는 컨테이너 인스턴스에 대한 '트렁크' 네트워크 인터페이스를 생성하고 연결합니다. 트렁크 네트워크는 Amazon ECS에서 완전히 관리됩니다. 트렁크 ENI는 Amazon ECS 클러스터에서 컨테이너 인스턴스를 종료하거나 등록 취소할 때 삭제됩니다. `awsvpcTrunking` 계정 설정에 대한 자세한 내용은 [사전 조건](container-instance-eni.md#eni-trunking-launching) 섹션을 참조하세요.
작업 정의의 `networkMode` 파라미터에서 `awsvpc`를 지정합니다. 자세한 내용은 [네트워크 모드](task_definition_parameters.md#network_mode) 섹션을 참조하세요.
그 다음에 작업을 실행하거나 서비스를 생성할 때 작업을 배치할 하나 이상의 서브넷과 ENI에 연결할 하나 이상의 보안 그룹이 포함된 `networkConfiguration` 파라미터를 사용합니다. 자세한 내용은 [네트워크 구성](service_definition_parameters.md#sd-networkconfiguration) 섹션을 참조하세요. 이 태스크는 해당 서브넷과 동일한 가용 영역에서 호환되는 Amazon EC2 인스턴스에 배치되고 지정된 보안 그룹은 이 태스크에 대해 프로비저닝된 ENI와 연결됩니다.
## Linux 고려 사항
Linux 운영 체제를 사용할 때는 다음 사항을 고려하세요.
+ `awsvpc` 모드에서 p5.48xlarge 인스턴스를 사용하는 경우 인스턴스에서 1개를 초과하는 태스크를 실행할 수 없습니다.
+ `awsvpc` 네트워크 모드를 사용하는 태스크 및 서비스는 사용자를 대신하여 Amazon ECS에 다른 Amazon ECS 서비스를 호출할 권한을 부여하는 AWS 서비스 연결 역할이 필요합니다. 이 역할은 클러스터를 생성하거나 AWS Management Console에서 서비스를 생성 또는 업데이트할 때 자동으로 생성됩니다. 자세한 정보는 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md)을 참조하세요. 다음 AWS CLI 명령을 사용하여 서비스 연결 역할을 생성할 수도 있습니다.
```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
```
+ Amazon EC2 Linux 인스턴스는 `awsvpc` 네트워크 모드를 사용하는 태스크를 실행하기 위해 버전 `1.15.0` 이상의 컨테이너 에이전트가 필요합니다. Amazon ECS 최적화 AMI를 사용하는 경우 해당 인스턴스에는 `1.15.0-4` 이상 버전의 `ecs-init` 패키지가 필요합니다.
+ Amazon ECS는 `enableDnsHostnames` 및 `enableDnsSupport` 옵션이 모두 VPC에서 활성화된 경우 Amazon에서 제공한 (내부) DNS 호스트 이름을 함께 사용하여 태스크의 호스트 이름을 채웁니다. 이러한 옵션이 사용 설정되지 않으면 태스크의 DNS 호스트 이름이 임의의 호스트 이름이 설정됩니다. VPC DNS 설정에 대한 자세한 정보는 *Amazon VPC 사용 설명서*의 [VPC와 함께 DNS 사용](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)을 참조하세요.
+ `awsvpc` 네트워크 모드를 사용하는 각 Amazon ECS 태스크는 고유한 탄력적 네트워크 인터페이스(ENI)를 받습니다. 이 ENI는 이를 호스팅하는 Amazon EC2 인스턴스에 연결되어 있습니다. Amazon EC2 Linux 인스턴스에 연결할 수 있는 네트워크 인터페이스 수에 대한 기본 할당량이 있습니다. 기본 네트워크 인터페이스는 해당 할당량에 대해 하나로 계산됩니다. 예를 들어 기본적으로 `c5.large` 인스턴스에는 ENI를 3개까지만 연결할 수 있습니다. 인스턴스에 대한 기본 네트워크 인터페이스는 한 개로 계산됩니다. 인스턴스에 ENI를 2개 더 연결할 수 있습니다. `awsvpc` 네트워크 모드를 사용하는 각 태스크에는 ENI가 필요하므로 대개 이 인스턴스 유형에서는 이러한 태스크를 2개까지만 실행할 수 있습니다. 각 인스턴스 유형의 기본 ENI 제한에 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 유형별 네트워크 인터페이스당 IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)를 참조하세요.
+ Amazon ECS에서는 지원되는 인스턴스 유형을 사용하여 늘어난 ENI 밀도와 함께 Amazon EC2 Linux 인스턴스를 시작할 수 있습니다. `awsvpcTrunking` 계정 설정에 옵트인하고 이러한 인스턴스 유형을 사용하여 Amazon EC2 Linux 인스턴스를 클러스터에 등록하는 경우 이러한 인스턴스의 ENI 할당량이 더 높습니다. 이러한 인스턴스를 이 정도 높은 할당량으로 사용하면 각 Amazon EC2 Linux 인스턴스에 더 많은 태스크를 배치할 수 있습니다. 트렁킹 기능과 함께 늘어난 ENI 밀도를 활용하려면 Amazon EC2 인스턴스에 버전 `1.28.1` 이상의 컨테이너 에이전트가 필요합니다. Amazon ECS 최적화 AMI를 사용하는 경우 해당 인스턴스에는 `1.28.1-2` 이상 버전의 `ecs-init` 패키지가 필요합니다. `awsvpcTrunking` 계정 설정 옵트인에 대한 자세한 정보는 [계정 설정을 사용하여 Amazon ECS 기능에 액세스](ecs-account-settings.md) 섹션을 참조하세요. ENI 트렁킹에 대한 자세한 정보는 [Amazon ECS Linux 컨테이너 인스턴스 네트워크 인터페이스 증가](container-instance-eni.md) 섹션을 참조하세요.
+ Amazon EC2 Linux 인스턴스에서 `awsvpc` 네트워크 모드를 사용하는 태스크를 호스팅할 때 작업 ENI에 퍼블릭 IP 주소가 부여되지 않습니다. 인터넷에 액세스하려면 NAT 게이트웨이를 사용하도록 구성된 프라이빗 서브넷에서 시작되어야 합니다. 자세한 정보는 *Amazon VPC 사용 설명서*의 [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 섹션을 참조하세요. 인바운드 네트워크 액세스는 프라이빗 IP 주소를 사용하는 VPC에서 시도하거나 VPC 내에서 로드 밸런서를 통해 라우팅되어야 합니다. 퍼블릭 서브넷 내에서 시작된 태스크는 인터넷에 액세스할 수 없습니다.
+ Amazon ECS는 Amazon EC2 Linux 인스턴스에 연결된 ENI만 인식합니다. 인스턴스에 ENI를 수동으로 연결한 경우, Amazon ECS는 네트워크 어댑터가 충분하지 않은 인스턴스에 태스크를 추가하려고 시도할 수 있습니다. 이로 인해 태스크 시간이 초과되고 프로비저닝 해제 상태가 된 다음 중지 상태가 될 수 있습니다. 따라서 ENI를 인스턴스에 수동으로 연결하지 않는 것이 좋습니다.
+ Amazon EC2 Linux 인스턴스는 `awsvpc` 네트워크 모드로 태스크를 배치하는 것을 감안하여 `ecs.capability.task-eni` 용량으로 등록해야 합니다. `1.15.0-4` 이상 버전의 `ecs-init`을 실행 중인 인스턴스는 이 속성으로 자동 등록됩니다.
+ Amazon EC2 Linux 인스턴스에서 생성 및 연결하는 ENI는 계정을 통해 수동으로 분리하거나 수정할 수 없습니다. 이는 실행 중인 태스크와 연결된 ENI가 우발적으로 삭제되는 일을 방지하기 위한 것입니다. 태스크에 대한 ENI를 해제하려면 태스크를 중지합니다.
+ `awsVpcConfiguration` 네트워크 모드를 사용하는 태스크를 실행하거나 서비스를 생성할 때 `awsvpc`에서 서브넷 16개와 보안 그룹 5개만 지정할 수 있다는 제한이 있습니다. 자세한 정보는 *Amazon Elastic Container Service API 참조*의 [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)을 참조하세요.
+ `awsvpc` 네트워크 모드에서 태스크가 시작되면 Amazon ECS 컨테이너 에이전트는 태스크 정의에 있는 컨테이너를 시작하기 전에 각 태스크에 대한 추가 `pause` 컨테이너를 생성합니다. 그런 다음 [amazon-ecs-cni-plugins ](https://github.com/aws/amazon-ecs-cni-plugins) CNI 플러그인을 실행하여 `pause` 컨테이너의 네트워크 네임스페이스를 구성합니다. 그런 다음 에이전트는 태스크의 나머지 컨테이너를 시작하며 이러한 컨테이너는 `pause` 컨테이너의 네트워크 스택을 공유합니다. 따라서 태스크의 모든 컨테이너가 ENI의 IP 주소로 주소를 지정할 수 있으며 `localhost` 인터페이스를 통해 서로 통신할 수 있습니다.
+ `awsvpc` 네트워크 모드만을 사용하는 태스크가 포함된 서비스는 Application Load Balancer 및 Network Load Balancer를 지원합니다. 이러한 서비스에 대한 대상 그룹을 생성할 때 대상 유형을 `ip`로 선택해야 합니다. `instance`는 사용하지 않습니다. 이는 `awsvpc` 네트워크 모드를 사용하는 태스크가 Amazon EC2 Linux 인스턴스가 아닌 ENI와 연결되기 때문입니다. 자세한 정보는 [로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산](service-load-balancing.md)을 참조하세요.
+ VPC가 사용하는 DHCP 옵션 세트를 변경하도록 업데이트된 경우, 이러한 변경 사항을 기존 작업에 적용할 수 없습니다. 이러한 변경 사항이 적용된 새 작업을 시작하고 올바르게 작동하는지 확인한 다음 기존 작업을 중지하여 네트워크 구성을 안전하게 변경합니다.
## Windows 고려 사항
Windows 운영 체제를 사용할 때 고려할 사항을 다음과 같습니다.
+ Amazon ECS 최적화 Windows 서버 2016 AMI를 사용하는 컨테이너 인스턴스는 `awsvpc` 네트워크 모드를 사용하는 태스크를 호스팅할 수 없습니다. Amazon ECS 최적화 Windows Server 2016 AMI와 `awsvpc` 네트워크 모드를 지원하는 Windows AMI가 포함된 클러스터가 있는 경우, `awsvpc` 네트워크 모드를 사용하는 태스크는 Windows 2016 Server 인스턴스에서 시작되지 않습니다. 대신, 지원하는 `awsvpc`네트워크 모드 인스턴스에서 시작됩니다.
+ `awsvpc` 네트워크 모드를 사용하는 Windows 컨테이너에 CloudWatch 지표를 사용하려면 Amazon EC2 Windows 인스턴스에 버전 `1.57.1` 이상의 컨테이너 에이전트가 필요합니다.
+ `awsvpc` 네트워크 모드를 사용하는 태스크 및 서비스는 사용자를 대신하여 Amazon ECS에 다른 Amazon ECS 서비스를 호출할 권한을 부여하는 AWS 서비스 연결 역할이 필요합니다. 이 역할은 클러스터를 생성하거나 AWS Management Console에서 서비스를 생성 또는 업데이트할 때 자동으로 생성됩니다. 자세한 정보는 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md)을 참조하세요. 다음 AWS CLI 명령을 사용하여 서비스 연결 역할을 생성할 수도 있습니다.
```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
```
+ Amazon EC2 Windows 인스턴스는 `awsvpc` 네트워크 모드를 사용하는 태스크를 실행하기 위해 버전 `1.54.0` 이상의 컨테이너 에이전트가 필요합니다. 인스턴스를 부트스트랩할 때 `awsvpc` 네트워크 모드에 필요한 옵션을 구성해야 합니다. 자세한 정보는 [데이터 전달을 위한 Amazon ECS Windows 컨테이너 인스턴스 부트스트래핑](bootstrap_windows_container_instance.md)을 참조하세요.
+ Amazon ECS는 `enableDnsHostnames` 및 `enableDnsSupport` 옵션이 모두 VPC에서 사용 설정된 경우 Amazon에서 제공한 (내부) DNS 호스트 이름을 함께 사용하여 태스크의 호스트 이름을 채웁니다. 이러한 옵션이 사용 설정되지 않으면 태스크의 DNS 호스트 이름이 임의의 호스트 이름입니다. VPC DNS 설정에 대한 자세한 정보는 *Amazon VPC 사용 설명서*의 [VPC와 함께 DNS 사용](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)을 참조하세요.
+ `awsvpc` 네트워크 모드를 사용하는 각 Amazon ECS 태스크는 고유한 탄력적 네트워크 인터페이스(ENI)를 받습니다. 이 ENI는 이를 호스팅하는 Amazon EC2 Windows 인스턴스에 연결되어 있습니다. Amazon EC2 Windows 인스턴스에 연결할 수 있는 네트워크 인터페이스 수에 대한 기본 할당량이 있습니다. 기본 네트워크 인터페이스는 해당 할당량에 대해 하나로 계산됩니다. 예를 들어 기본적으로 `c5.large` 인스턴스에는 ENI를 3개까지만 연결할 수 있습니다. 인스턴스에 대한 기본 네트워크 인터페이스는 그 중 한 개로 계산됩니다. 인스턴스에 ENI를 2개 더 연결할 수 있습니다. `awsvpc` 네트워크 모드를 사용하는 각 태스크에는 ENI가 필요하므로 대개 이 인스턴스 유형에서는 이러한 태스크를 2개까지만 실행할 수 있습니다. 각 인스턴스 유형의 기본 ENI 제한에 자세한 내용은 **Amazon EC2 사용 설명서의 [인스턴스 유형별 네트워크 인터페이스당 IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI)를 참조하세요.
+ Amazon EC2 Windows 인스턴스에서 `awsvpc` 네트워크 모드를 사용하는 태스크를 호스팅할 때 태스크 ENI에 퍼블릭 IP 주소가 부여되지 않습니다. 인터넷에 액세스하려면 NAT 게이트웨이를 사용하도록 구성된 프라이빗 서브넷에서 태스크를 시작합니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 섹션을 참조하세요. 인바운드 네트워크 액세스는 프라이빗 IP 주소를 사용하는 VPC에서 시도하거나 VPC 내에서 로드 밸런서를 통해 라우팅되어야 합니다. 퍼블릭 서브넷 내에서 시작된 태스크는 인터넷에 액세스할 수 없습니다.
+ Amazon ECS는 Amazon EC2 Windows 인스턴스에 연결된 ENI만 인식합니다. 인스턴스에 ENI를 수동으로 연결한 경우, Amazon ECS는 네트워크 어댑터가 충분하지 않은 인스턴스에 태스크를 추가하려고 시도할 수 있습니다. 이로 인해 태스크 시간이 초과되고 프로비저닝 해제 상태가 된 다음 중지 상태가 될 수 있습니다. 따라서 ENI를 인스턴스에 수동으로 연결하지 않는 것이 좋습니다.
+ Amazon EC2 Windows 인스턴스는 `awsvpc` 네트워크 모드로 태스크를 배치하는 것을 감안하여 `ecs.capability.task-eni` 용량으로 등록해야 합니다.
+ Amazon EC2 Windows 인스턴스에서 생성 및 연결하는 ENI는 수동으로 분리하거나 수정할 수 없습니다. 이는 실행 중인 태스크와 연결된 ENI가 우발적으로 삭제되는 일을 방지하기 위한 것입니다. 태스크에 대한 ENI를 해제하려면 태스크를 중지합니다.
+ 태스크를 실행하거나 `awsvpc` 네트워크 모드를 사용하는 서비스를 생성할 때, `awsVpcConfiguration`에는 최대 16개의 서브넷과 5개의 보안 그룹만 지정할 수 있습니다. 자세한 정보는 *Amazon Elastic Container Service API 참조*의 [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)을 참조하세요.
+ `awsvpc` 네트워크 모드에서 태스크가 시작되면 Amazon ECS 컨테이너 에이전트는 태스크 정의에 있는 컨테이너를 시작하기 전에 각 태스크에 대한 추가 `pause` 컨테이너를 생성합니다. 그런 다음 [amazon-ecs-cni-plugins ](https://github.com/aws/amazon-ecs-cni-plugins) CNI 플러그인을 실행하여 `pause` 컨테이너의 네트워크 네임스페이스를 구성합니다. 그런 다음 에이전트는 태스크의 나머지 컨테이너를 시작하며 이러한 컨테이너는 `pause` 컨테이너의 네트워크 스택을 공유합니다. 따라서 태스크의 모든 컨테이너가 ENI의 IP 주소로 주소를 지정할 수 있으며 `localhost` 인터페이스를 통해 서로 통신할 수 있습니다.
+ `awsvpc` 네트워크 모드만을 사용하는 태스크가 포함된 서비스는 Application Load Balancer 및 Network Load Balancer를 지원합니다. 이러한 서비스에 대한 대상 그룹을 생성할 때 대상 유형을 `instance`가 아닌 `ip`로 선택해야 합니다. 이는 `awsvpc` 네트워크 모드를 사용하는 태스크가 Amazon EC2 Windows 인스턴스가 아닌 ENI와 연결되기 때문입니다. 자세한 정보는 [로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산](service-load-balancing.md)을 참조하세요.
+ VPC가 사용하는 DHCP 옵션 세트를 변경하도록 업데이트된 경우, 이러한 변경 사항을 기존 작업에 적용할 수 없습니다. 이러한 변경 사항이 적용된 새 작업을 시작하고 올바르게 작동하는지 확인한 다음 기존 작업을 중지하여 네트워크 구성을 안전하게 변경합니다.
+ 다음은 EC2 Windows 구성에서 `awsvpc` 네트워크 모드를 사용할 때 지원되지 않는 항목입니다.
+ 듀얼 스택 구성
+ IPv6
+ ENI 트렁킹
## 듀얼 스택 모드로 VPC 사용하기
VPC를 듀얼 스택 모드로 사용하는 경우 작업은 IPv4, IPv6 또는 둘 다를 통해 통신할 수 있습니다. IPv4 및 IPv6 주소는 서로 독립적입니다. 따라서 IPv4 및 IPv6에 대해 별도로 VPC에서 라우팅 및 보안을 구성해야 합니다. VPC를 듀얼 스택 모드로 구성하는 방법에 대한 자세한 정보는 *Amazon VPC 사용 설명서*의 [IPv6로 마이그레이션하기](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html)를 참조하세요.
인터넷 게이트웨이 또는 아웃바운드 전용 인터넷 게이트웨이로 VPC를 구성한 경우, VPC 듀얼 스택 모드로 사용할 수 있습니다. 이렇게 하면 IPv6 주소에 할당되는 태스크가 인터넷 게이트웨이 또는 송신 전용 인터넷 게이트웨이를 통해 인터넷에 액세스할 수 있습니다. NAT 게이트웨이는 선택 사항입니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [인터넷 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) 및 [송신 전용 인터넷 게이트](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html)를 참조하세요.
다음 조건이 충족되면 Amazon ECS 태스크에 IPv6 주소가 할당됩니다.
+ 태스크를 호스팅하는 Amazon EC2 Linux 인스턴스가 버전 `1.45.0` 이상의 컨테이너 에이전트를 사용하고 있습니다. 인스턴스에서 사용 중인 에이전트 버전을 확인하고 필요한 경우 업데이트하는 방법에 대한 자세한 정보는 [Amazon ECS 컨테이너 에이전트 업데이트](ecs-agent-update.md) 섹션을 참조하세요.
+ `dualStackIPv6` 계정 설정이 활성화되어 있습니다. 자세한 정보는 [계정 설정을 사용하여 Amazon ECS 기능에 액세스](ecs-account-settings.md) 섹션을 참조하세요.
+ 태스크가 `awsvpc` 네트워크 모드를 사용하고 있습니다.
+ VPC 및 서브넷은 IPv6으로 구성됩니다. 구성에는 지정된 서브넷에서 생성된 네트워크 인터페이스가 포함됩니다. 이중 스택 모드용 VPC 구성 방법에 대한 자세한 정보는 *Amazon VPC 사용 설명서*의 [IPv6로 마이그레이션하기](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html)와 [서브넷의 IPv6 주소 지정 속성 수정](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6)을 참조하세요.
# EC2 인스턴스 네트워크 인터페이스에 Amazon ECS 컨테이너 포트 매핑
`host` 네트워크 모드는 Amazon EC2 인스턴스에서 호스팅되는 Amazon ECS 작업에만 지원됩니다. Fargate 기반 Amazon ECS를 사용하는 경우 지원되지 않습니다.
`host` 네트워크 모드는 Amazon ECS에서 지원되는 가장 기본적인 네트워크 모드입니다. 호스트 모드를 사용하면 컨테이너의 네트워킹이 컨테이너를 실행 중인 기본 호스트에 직접 연결됩니다.
![\[호스트 네트워크 모드를 사용하는 컨테이너가 있는 네트워크의 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/networkmode-host.png)
위 다이어그램에 표시된 것과 비슷한 포트 `3000`에서 수신 대기하는 Express 애플리케이션을 사용하여 Node.js 컨테이너를 실행한다고 가정해 보겠습니다. `host` 네트워크 모드를 사용하는 경우 컨테이너는 기본 호스트 Amazon EC2 인스턴스의 IP 주소를 사용하여 포트 3000에서 트래픽을 수신합니다. 이 모드 사용은 권장하지 않습니다.
이 네트워크 모드를 사용하는 데에는 상당한 단점이 있습니다. 각 호스트에서 작업의 인스턴스화를 두 번 이상 실행할 수 없습니다. 첫 번째 작업만 Amazon EC2 인스턴스의 필요한 포트에 바인딩할 수 있기 때문입니다. `host` 네트워크 모드를 사용할 때는 컨테이너 포트를 다시 매핑할 방법도 없습니다. 예를 들어 애플리케이션이 특정 포트 번호를 수신해야 하는 경우 포트 번호를 직접 다시 매핑할 수 없습니다. 대신 애플리케이션 구성을 변경하여 모든 포트 충돌을 관리해야 합니다.
`host` 네트워크 모드를 사용할 경우 보안에도 영향을 미칠 수 있습니다. 이 모드를 사용하면 컨테이너가 호스트를 가장하고 호스트의 프라이빗 루프백 네트워크 서비스에 연결할 수 있습니다.
# Amazon ECS Linux 태스크에 대해 Docker의 가상 네트워크 사용
`bridge` 네트워크 모드는 Amazon EC2 인스턴스에서 호스팅되는 Amazon ECS 작업에만 지원됩니다.
`bridge` 모드를 사용하면 가상 네트워크 브리지를 사용하여 호스트와 컨테이너 네트워킹 사이에 계층을 생성합니다. 이렇게 하면 호스트 포트를 컨테이너 포트에 다시 매핑하는 포트 매핑을 생성할 수 있습니다. 매핑은 정적이거나 동적일 수 있습니다.
![\[정적 포트 매핑이 있는 브리지 네트워크 모드를 사용하는 네트워크 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/networkmode-bridge.png)
정적 포트 매핑을 사용하면 컨테이너 포트에 매핑하려는 호스트 포트를 명시적으로 정의할 수 있습니다. 위 예제를 사용하면 호스트의 포트 `80`가 컨테이너의 포트 `3000`에 매핑됩니다. 컨테이너화된 애플리케이션과 통신하려면 Amazon EC2 인스턴스의 IP 주소로 포트 `80`을 통해 트래픽을 전송합니다. 컨테이너화된 애플리케이션의 관점에서 보면 인바운드 트래픽이 포트 `3000`을 통해 전달된다고 볼 수 있습니다.
트래픽 포트만 변경하려는 경우에는 정적 포트 매핑이 적합합니다. 하지만 여전히 `host` 네트워크 모드를 사용할 때와 같은 단점이 있습니다. 각 호스트에서 작업의 인스턴스화를 두 번 이상 실행할 수 없습니다. 정적 포트 매핑에서는 단일 컨테이너만 포트 80에 매핑할 수 있기 때문입니다.
이 문제를 해결하려면 다음 다이어그램과 같은 동적 포트 매핑과 함께 `bridge` 네트워크 모드를 사용하는 것이 좋습니다.
![\[동적 포트 매핑이 있는 브리지 네트워크 모드를 사용하는 네트워크 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/networkmode-bridge-dynamic.png)
포트 매핑에서 호스트 포트를 지정하지 않고 Docker에서 임시 포트 범위에서 사용되지 않는 임의의 포트를 선택하여 컨테이너의 공용 호스트 포트로 할당하도록 할 수 있습니다. 예를 들어 컨테이너의 포트 `3000`에서 수신 대기하는 Node.js 애플리케이션에는 Amazon EC2 호스트의 `47760`과 같이 높은 번호의 임의 포트가 할당될 수 있습니다. 이렇게 하면 호스트에서 해당 컨테이너의 여러 복사본을 실행할 수 있습니다. 또한 호스트에서 각 컨테이너에 자체 포트를 할당할 수 있습니다. 컨테이너의 각 복사본은 포트 `3000`에서 트래픽을 수신합니다. 하지만 이러한 컨테이너로 트래픽을 보내는 클라이언트는 임의로 할당된 호스트 포트를 사용합니다.
Amazon ECS를 사용하면 각 작업에 임의로 할당된 포트를 추적할 수 있습니다. 이렇게 하려면 작업 IP 주소 및 포트 목록을 포함하도록 로드 밸런서 대상 그룹 및 AWS Cloud Map 서비스 검색을 자동으로 업데이트합니다. 따라서 동적 포트가 있는 `bridge` 모드를 사용하여 운영되는 서비스를 더 쉽게 사용할 수 있습니다.
그러나 `bridge` 네트워크 모드를 사용할 때의 한 가지 단점은 서비스 간 통신을 차단하기가 어렵다는 것입니다. 서비스는 사용되지 않는 임의의 포트에 할당될 수 있으므로 호스트 간에 넓은 포트 범위를 열어야 합니다. 하지만 특정 서비스가 다른 특정 서비스 하나와만 통신할 수 있도록 특정 규칙을 만드는 것은 쉽지 않습니다. 서비스에는 보안 그룹 네트워킹 규칙에 사용할 특정 포트가 없습니다.
## IPv6 전용 워크로드에 대한 브리지 네트워킹 모드 구성
IPv6에서의 통신을 위해 `bridge` 모드를 구성하려면 Docker 대몬 설정을 업데이트해야 합니다. 다음으로 `/etc/docker/daemon.json`을 업데이트합니다.
```
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64",
"ip6tables": true,
"experimental": true
}
```
Docker 대몬 설정을 업데이트한 후 대몬을 다시 시작해야 합니다.
**참고**
대몬을 업데이트하고 다시 시작하면 Docker는 인스턴스에서 IPv6 전달을 활성화합니다. 이 경우 Amazon Linux 2 AMI를 사용하는 인스턴스에서 기본 경로가 손실될 수 있습니다. 이를 방지하려면 다음 명령을 사용하여 서브넷의 IPv6 게이트웨이를 통해 기본 경로를 추가합니다.
```
ip route add default via FE80:EC2::1 dev eth0 metric 100
```