ECS 네트워크모드

모드 선택은 총 5개

default, 호스트, 브릿지, awsvpc, 없음

 

default

<default>을(를) 선택할 경우 ECS는 Docker의 기본 네트워킹 모드를 사용하여 컨테이너를 시작합니다. Docker의 기본 네트워킹 모드는 Linux는 브리지(Bridge) 그리고 Windows는 NAT 입니다. <default>은(는) Windows에서 유일하게 지원되는 모드입니다.

(aws에서 번역된거 보면 이상하게 되어있음 

 Docker의 기본 네트워킹 모드는 Windows의 Linux 브리지(Bridge) 및 NAT 브리지(Bridge)입니다.

이런식으로 되어있다.)

 

 

호스트

 

호스트 모드를 사용하면 컨테이너의 네트워킹이 컨테이너를 실행하는 기본 호스트에 직접 연결됩니다.

네트워크 모드를 사용 하면 host컨테이너는 기본 호스트 Amazon EC2 인스턴스의 IP 주소를 사용하여 포트 3000에서 트래픽을 수신합니다.

 

이 네트워크 모드를 사용하는 데는 상당한 단점이 있습니다. 각 호스트에서 작업 인스턴스화를 하나만 실행할 수 있습니다. 이는 첫 번째 작업만 Amazon EC2 인스턴스의 필수 포트에 바인딩할 수 있기 때문입니다. host네트워크 모드 를 사용할 때 컨테이너 포트를 다시 매핑할 방법도 없습니다 . 예를 들어 애플리케이션이 특정 포트 번호를 수신해야 하는 경우 포트 번호를 직접 다시 매핑할 수 없습니다. 대신 애플리케이션 구성을 변경하여 포트 충돌을 관리해야 합니다.

 

host네트워크 모드 를 사용할 때도 보안에 영향을 미칩니다 . 이 모드를 사용하면 컨테이너가 호스트를 가장할 수 있고 컨테이너가 호스트의 개인 루프백 네트워크 서비스에 연결할 수 있습니다.

 

네트워크 모드 는 hostAmazon EC2 인스턴스에서 호스팅되는 Amazon ECS 작업에만 지원됩니다. Fargate에서 Amazon ECS를 사용할 때는 지원되지 않습니다.

 

 

 

브릿지

 

가상 네트워크 브리지를 사용하여 호스트와 컨테이너의 네트워킹 사이에 계층을 만듭니다

 

가상 네트워크 브리지를 사용하여 호스트와 컨테이너의 네트워킹 사이에 계층을 만듭니다

 

정적 포트 매핑을 사용하면 컨테이너 포트에 매핑할 호스트 포트를 명시적으로 정의할 수 있습니다. 위의 예를 사용하여 호스트의 포트 80이 컨테이너의 포트3000 에 매핑됩니다. 컨테이너화된 애플리케이션과 통신하려면 포트80 로 트래픽을 Amazon EC2 인스턴스의 IP 주소로 보냅니다. 컨테이너화된 애플리케이션의 관점에서 보면 포트 3000의 인바운드 트래픽이 표시됩니다.

트래픽 포트만 변경하려는 경우 정적 포트 매핑이 적합합니다. 그러나 이것은 여전히 ​​host네트워크 모드 를 사용하는 것과 동일한 단점이 있습니다. 각 호스트에서 태스크 인스턴스화를 하나만 실행할 수 있습니다. 이는 정적 포트 매핑을 사용하면 단일 컨테이너만 포트 80에 매핑할 수 있기 때문입니다.

이 문제를 해결하려면 다음 다이어그램과 같이 동적 포트 매핑과 함께 bridge네트워크 모드를 사용하는 것이 좋습니다

 

포트 매핑에서 호스트 포트를 지정하지 않으면 Docker가 임시 포트 범위에서 사용하지 않는 임의의 포트를 선택하고 이를 컨테이너의 공용 호스트 포트로 할당하도록 할 수 있습니다. 

예를 들어 컨테이너의 3000포트에서 수신 대기하는 Node.js 애플리케이션 에는 Amazon EC2 호스트 47760와 같은 임의의 높은 번호 포트가 할당될 수 있습니다 . 이렇게 하면 호스트에서 해당 컨테이너의 여러 복사본을 실행할 수 있습니다. 또한 각 컨테이너는 호스트에서 자체 포트를 할당할 수 있습니다. 컨테이너의 각 복사본은 3000포트에서 트래픽을 수신합니다 . 그러나 이러한 컨테이너로 트래픽을 보내는 클라이언트는 임의로 할당된 호스트 포트를 사용합니다.

 

Amazon ECS를 사용하면 각 작업에 대해 무작위로 할당된 포트를 추적할 수 있습니다. 작업 IP 주소 및 포트 목록을 갖도록 로드 밸런서 대상 그룹 및 AWS Cloud Map 서비스 검색을 자동으로 업데이트하여 이를 수행합니다. 이렇게 하면 동적 포트가 있는 bridge모드를 사용하여 작동하는 서비스를 더 쉽게 사용할 수 있습니다 .

 

그러나 bridge네트워크 모드를 사용할 때의 한 가지 단점은 서비스 통신에 대한 서비스를 잠그기가 어렵다는 것입니다. 서비스는 사용하지 않는 임의의 포트에 할당될 수 있으므로 호스트 간에 광범위한 포트 범위를 열어야 합니다. 그러나 특정 서비스가 다른 특정 서비스와만 통신할 수 있도록 특정 규칙을 만드는 것은 쉽지 않습니다. 서비스에는 보안 그룹 네트워킹 규칙에 사용할 특정 포트가 없습니다.

 

bridge 네트워크 모드 는 Amazon EC2 인스턴스에서 호스팅되는 Amazon ECS 작업에만 지원됩니다. Amazon ECS에서  Fargate를 사용할 때는 지원되지 않습니다.

 

 

awsvpc

awsvpc네트워크 모드에서 Amazon ECS 는 각 작업에 대한 ENI(탄력적 네트워크 인터페이스)를 생성 및 관리하고 각 작업은 VPC 내에서 자체 프라이빗 IP 주소를 받습니다. 이 ENI는 기본 호스트 ENI와 별개입니다. Amazon EC2 인스턴스가 여러 작업을 실행하는 경우 각 작업의 ENI도 분리됩니다.

앞의 예에서 Amazon EC2 인스턴스는 ENI에 할당됩니다. ENI는 호스트 수준에서 네트워크 통신에 사용되는 EC2 인스턴스의 IP 주소를 나타냅니다. 각 작업에는 해당 ENI와 개인 IP 주소도 있습니다. 각 ENI가 분리되어 있기 때문에 각 컨테이너는 80태스크 ENI의 포트에 바인딩할 수 있습니다. 따라서 포트 번호를 추적할 필요가 없습니다. 80대신 작업 ENI의 IP 주소에 있는 포트로 트래픽을 보낼 수 있습니다 .

네트워크 모드 사용의 장점은 awsvpc각 작업에 트래픽을 허용하거나 거부하는 별도의 보안 그룹이 있다는 것입니다. 즉, 보다 세분화된 수준에서 작업과 서비스 간의 통신을 보다 유연하게 제어할 수 있습니다. 동일한 호스트에 있는 다른 작업에서 들어오는 트래픽을 거부하도록 작업을 구성할 수도 있습니다.

네트워크 모드 는 awsvpcAmazon EC2와 Fargate에서 호스팅되는 Amazon ECS 작업에 대해 지원됩니다. Fargate를 사용할 때는 awsvpc 네트워크 모드가 필요합니다.

네트워크 모드 를 사용할 때 awsvpc염두에 두어야 할 몇 가지 문제가 있습니다.

 

ENI Trunking으로 작업 밀도 증가

Amazon EC2 인스턴스에서 호스팅되는 작업과 함께 awsvpc네트워크 모드 를 사용할 때의 가장 큰 단점은 EC2 인스턴스에 연결할 수 있는 ENI 수가 제한된다는 것입니다. 이는 각 인스턴스에 배치할 수 있는 작업의 수를 제한합니다. Amazon ECS는 더 많은 작업 밀도를 달성하기 위해 사용 가능한 ENI 수를 늘리는 ENI 트렁킹 기능을 제공합니다.

ENI 트렁킹을 사용할 때 기본적으로 두 개의 ENI 첨부 파일이 사용됩니다. 첫 번째는 모든 호스트 수준 프로세스에 사용되는 인스턴스의 기본 ENI입니다. 두 번째는 Amazon ECS가 생성하는 트렁크 ENI입니다. 이 기능은 특정 Amazon EC2 인스턴스 유형에서만 지원됩니다.

 

이 예를 고려하십시오. ENI 트렁킹이 없으면 c5.large두 개의 vCPU가 있는 인스턴스는 두 개의 작업만 호스팅할 수 있습니다. 그러나 ENI 트렁킹을 사용하면 c5.large2개의 vCPU가 있는 인스턴스가 최대 10개의 작업을 호스팅할 수 있습니다. 각 작업에는 서로 다른 IP 주소와 보안 그룹이 있습니다. 사용 가능한 인스턴스 유형 및 밀도에 대한 자세한 내용은 Amazon Elastic Container Service 개발자 안내서 의 지원되는 Amazon EC2 인스턴스 유형 을 참조하십시오 .

 

ENI 트렁킹은 대기 시간이나 대역폭 측면에서 런타임 성능에 영향을 미치지 않습니다. 그러나 작업 시작 시간이 늘어납니다. ENI 트렁킹을 사용하는 경우 작업 시작 시간에 의존하는 자동 크기 조정 규칙 및 기타 워크로드가 여전히 예상대로 작동하는지 확인해야 합니다.

 

자세한 내용 은 Amazon Elastic Container Service 개발자 안내서 의 탄력적 네트워크 인터페이스 트렁킹 을 참조하십시오 .

 

IP 주소 소진 방지

각 작업에 별도의 IP 주소를 할당하면 전체 인프라를 단순화하고 높은 수준의 보안을 제공하는 보안 그룹을 유지할 수 있습니다. 그러나 이 구성은 IP 고갈로 이어질 수 있습니다.

 

AWS 계정의 기본 VPC에는 CIDR 범위 /20가 있는 사전 프로비저닝된 서브넷이 있습니다 . 이는 각 서브넷에 4,091개의 사용 가능한 IP 주소가 있음을 의미합니다. 범위 /20 내의 여러 IP 주소는 AWS 특정 용도로 예약되어 있습니다. 이 예를 고려하십시오. 고가용성을 위해 3개의 가용 영역에 있는 3개의 서브넷에 애플리케이션을 배포합니다. 이 경우 3개의 서브넷에서 약 12,000개의 IP 주소를 사용할 수 있습니다.

 

ENI 트렁킹을 사용하여 시작하는 각 Amazon EC2 인스턴스에는 두 개의 IP 주소가 필요합니다. 하나의 IP 주소는 기본 ENI에 사용되고 다른 IP 주소는 트렁크 ENI에 사용됩니다. 인스턴스의 각 Amazon ECS 작업에는 하나의 IP 주소가 필요합니다. 매우 큰 워크로드를 시작하는 경우 사용 가능한 IP 주소가 부족할 수 있습니다. 이로 인해 Amazon EC2 시작 실패 또는 작업 시작 실패가 발생할 수 있습니다. 이러한 오류는 사용 가능한 IP 주소가 없는 경우 ENI가 VPC 내부에 IP 주소를 추가할 수 없기 때문에 발생합니다.

awsvpc 네트워크 모드 를 사용할 때는 IP 주소 요구 사항을 평가하고 서브넷 CIDR 범위가 요구 사항을 충족하는지 확인해야 합니다. 작은 서브넷이 있는 VPC를 이미 사용하기 시작했고 주소 공간이 부족해지기 시작했다면 보조 서브넷을 추가할 수 있습니다.

ENI 트렁킹을 사용하면 호스트와 다른 IP 주소 공간에서 ENI를 사용하도록 Amazon VPC CNI를 구성할 수 있습니다. 이렇게 하면 Amazon EC2 호스트와 작업에 겹치지 않는 다른 IP 주소 범위를 부여할 수 있습니다. 예제 다이어그램에서 EC2 호스트 IP 주소는 172.31.16.0/20 범위가 있는 서브넷에 있습니다. 그러나 호스트에서 실행 중인 작업에는 해당 100.64.0.0/19범위의 IP 주소가 할당됩니다. 두 개의 독립적인 IP 범위를 사용하면 너무 많은 IP 주소를 사용하고 인스턴스에 충분한 IP 주소를 남기지 않는 작업에 대해 걱정할 필요가 없습니다.

 

IPv6 듀얼 스택 모드 사용

awsvpc 네트워크 모드 는 IPv6 듀얼 스택 모드용으로 구성된 VPC와 호환됩니다. 듀얼 스택 모드를 사용하는 VPC는 ​​IPv4, IPv6 또는 둘 다를 통해 통신할 수 있습니다. VPC의 각 서브넷은 IPv4 CIDR 범위와 IPv6 CIDR 범위를 모두 가질 수 있습니다. 자세한 내용 은 Amazon VPC 사용 설명서 에서 VPC의 IP 주소 지정을 참조하십시오 .

IPv4 고갈 문제를 해결하기 위해 VPC 및 서브넷에 대한 IPv4 지원을 비활성화할 수 없습니다. 그러나 IPv6 지원을 통해 몇 가지 새로운 기능, 특히 송신 전용 인터넷 게이트웨이를 사용할 수 있습니다. 송신 전용 인터넷 게이트웨이를 사용하면 작업에서 공개적으로 라우팅 가능한 IPv6 주소를 사용하여 인터넷에 대한 아웃바운드 연결을 시작할 수 있습니다. 그러나 외부 전용 인터넷 게이트웨이는 인터넷 연결을 허용하지 않습니다. 자세한 내용 은 Amazon VPC 사용 설명서의 송신 전용 인터넷 게이트웨이 를 참조하십시오 .

 

 

없음

포트 매핑 불가, 외부와 연결 안됨

 

 

https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/networking-networkmode.html

Choosing a network mode - Amazon Elastic Container Service