Aws FarGate 구성 모범 사례

1. 네트워크 구성 : 퍼블릭 서브넷 및 인터넷 게이트웨이 구성

 

 

인터넷 게이트웨이로 향하는 라우팅이 있는 퍼블릭 서브넷을 사용하면 컨테이너식 애플리케이션을 퍼블릭 서브넷의 vpc 내부의 호스트에 실행 할 수 있다.공용 ip (3.221.88.186) 주소는 인터넷에 라우팅 할 수 있다.

 

이 네트워크 아키텍처는 응용 프로그램을 실행하는 호스트와 다른 호스트 간의 직접 통신을 용이 하게 한다.따라서, 보안그룹 및 방화벽 규칙에 세심하게 신경 써야 한다. 인터넷의 다른 호스트가 연결을 열 수 없도록 하기 위한 것 이다.

EX) app이 ec2에서 실행 중인 경우 ssh 포트가 열려 있지 않은지 확인 한다. 봇으로 부터 지속적으로 ssh 연결 시도를 수신할 수 있다. 이러한 봇은 공용 ip 주소를 탐색 한다. 열린 ssh 연결을 하기위해  지속적으로 SSH 연결 시도를 한다. 이러한  이유 때문에 대부분의 조직에서는 공용 서브넷의 사용을 제한하고 사설 서브넷을 사용한다.

 

네트워크 공용 서브넷을 사용하는것 들은 많은 양의 대역폭이나 최소 대기 시간이 필요한 공용 응용프로그램에 적합하다.(비디오 스트리밍 및 게임 서비스가 이에 해당한다.)

 

FarGate 사용 - Amazon ECS 서비스를 생성할 때 서비스의 네트워킹 구성을 위한 퍼블릭 서브넷을 지정하고 퍼블릭 ip 주소는 배정옵션이 활성화 되어 있는지를 확인 해야한다. 각 fargate 작업은 퍼블릭 서브넷에 네트워크로 연결 되며 인터넷과 직접 통신 할 수 있는 자체 퍼블릭 ip 주소가 있다.

2. 프라이빗 서브넷 및 NAT 게이트웨이 사용

프라이빗 서브넷과 NAT 게이트웨이를 사용하면 프라이빗 서브넷에 있는 호스트에서 컨테이너화된 엄플리케이션을 실행할 수 있다.

따라서 이 호스트에는 vpc 내부에서 라우팅할 수 있지만, 인터넷에서 라우팅 할 수 없는 프라이빗 ip가 있다.

즉 , vpc 내부의 다른 호스트는 프라이빗 ip 주소를 사용하여 호스트에 연결 할 수 있지만 인터넷의 다른 호스트는 호스트에 대한 인바운드 통신을 수행할 수 없다. 프라이빗 서브넷의 경우 NAT를 통하여 프라이빗 서브넷 내의 호스트를 인터넷에 연결 하는 한편, 인터넷의 호스트는 퍼블릭 서브넷 내에 NAT 게이트 웨이의 퍼블릭 ip주소에서 들어오는 것으로 보이는 인바운드 연결을 수신한다.

NAT 게이트웨이는 인터넷과 프라이빗 VPC 사이의 다리 역할을 담당한다. 이 구성은 공격자가 직접 공격을 못하도록 보호하므로 보안상의 이유로 선호되는 구성이다. 이러한 네트워킹 접근 방식은 컨테이너를 직접 외부 액세스로부터 보호하려는 시나리오 에서 적합 하다. 이러한 시나리오는 사용자 데이터 및 암호를 저장하는 결제 처리 시스템 또는 컨테이너가 포함 된다.

중복성을 위해 각 가용 영역에 NAT게이트웨이가 있어야 한다. 이렇게 하면 단일 가용 영역의 가용성 손실이 아웃바운드 연결을 손상 시키지 않을 수 있다.

 

Fargate 사용 ECS 서비스를 생성할 때 서비스의 네트워킹 구성을 위한 프라이빗 서브넷을 지정하고 IP 주소 배정옵션을 선택한다.

각 Fargate 작업은 프라이빗 서브넷에 호스팅 된다. 아웃바운드 트래픽의 경우 해당 서브넷과 연결된 NAT 게이트웨이를 통해 라우팅 된다.