Amazon ECS 애플리케이션을 인터넷에 연결하기

대부분의 컨테이너화된 애플리케이션에는 적어도 일부 구성 요소가 인터넷으로의 아웃바운드 접근이 필요해요. 예를 들어 모바일 앱의 백엔드는 푸시 알림을 위해 아웃바운드 접근이 필요합니다. Amazon Virtual Private Cloud에는 VPC와 인터넷 간 통신을 촉진하는 두 가지 주요 방법이 있습니다.

출처: 문서

본문

대부분의 컨테이너화된 애플리케이션에는 최소한 몇몇 구성 요소가 인터넷으로의 아웃바운드 접근을 필요로 합니다. 예를 들어 모바일 앱의 백엔드는 푸시 알림을 위해 아웃바운드 접근이 필요해요. Amazon Virtual Private Cloud는 VPC와 인터넷 사이의 통신을 촉진하는 두 가지 주요 방법이 있습니다.

공용 서브넷과 인터넷 게이트웨이

인터넷 게이트웨이로의 경로가 있는 공용 서브넷(public subnet)을 사용하면, 컨테이너화된 애플리케이션을 VPC 안 공용 서브넷의 호스트에서 실행할 수 있습니다. 컨테이너를 실행하는 호스트에는 공용 IP 주소가 할당됩니다. 이 공용 IP 주소는 인터넷에서 라우팅 가능합니다. 자세한 내용은 Amazon VPC User Guide의 "Internet gateways"를 참고하세요.

이 네트워크 아키텍처는 애플리케이션을 실행하는 호스트와 인터넷의 다른 호스트 사이의 직접 통신을 촉진하며, 통신은 양방향입니다. 즉 인터넷의 다른 호스트로 아웃바운드 연결을 설정할 수 있을 뿐 아니라, 인터넷의 다른 호스트가 호스트에 연결을 시도할 수도 있습니다. 따라서 보안 그룹(security group)과 방화벽 규칙에 세심한 주의를 기울여야 해요. 그래야 인터넷의 다른 호스트가 열어 두고 싶지 않은 연결을 열 수 없습니다.

예를 들어 애플리케이션이 Amazon EC2에서 실행된다면, SSH 접근용 포트 22가 열려 있지 않은지 확인하세요. 그렇지 않으면 인스턴스가 인터넷의 악성 봇으로부터 계속 SSH 연결 시도를 받을 수 있습니다. 이 봇들은 공용 IP 주소를 탐색하며, 열린 SSH 포트를 찾으면 인스턴스에 접근하기 위해 암호를 무차별(brute-force) 대입합니다. 이런 이유로 많은 조직이 공용 서브넷 사용을 제한하고, 대부분(전부는 아니더라도)의 리소스를 프라이빗 서브넷 안에 두는 것을 선호합니다.

공용 서브넷을 네트워킹에 사용하는 것은 많은 대역폭이나 최소 지연 시간이 필요한 공용 애플리케이션에 적합합니다. 적용 가능한 사용 사례로는 비디오 스트리밍과 게임 서비스가 있습니다.

이 네트워킹 방식을 Amazon EC2의 Amazon ECS와 AWS Fargate의 Amazon ECS에서 모두 지원합니다.

Amazon EC2 — 공용 서브넷에서 EC2 인스턴스를 시작할 수 있습니다. Amazon ECS는 이 EC2 인스턴스를 클러스터 용량으로 사용하며, 인스턴스에서 실행되는 컨테이너는 아웃바운드 네트워킹에 호스트의 기본 공용 IP 주소를 사용할 수 있습니다. 이는 호스트(host)와 브리지(bridge) 네트워크 모드 모두에 적용됩니다. 그러나 awsvpc 네트워크 모드는 태스크 ENI에 공용 IP 주소를 제공하지 않으므로, 인터넷 게이트웨이를 직접 사용할 수 없습니다.
Fargate — Amazon ECS 서비스를 만들 때 서비스 네트워킹 구성에 공용 서브넷을 지정하고 Assign public IP address 옵션을 사용하세요. 각 Fargate 태스크는 공용 서브넷에서 네트워킹되고, 인터넷과 직접 통신할 수 있는 자체 공용 IP 주소를 가집니다.

프라이빗 서브넷과 NAT 게이트웨이

프라이빗 서브넷(private subnet)과 NAT 게이트웨이를 사용하면, 컨테이너화된 애플리케이션을 프라이빗 서브넷 안의 호스트에서 실행할 수 있습니다. 따라서 이 호스트는 VPC 안에서 라우팅 가능하지만 인터넷에서는 라우팅할 수 없는 프라이빗 IP 주소를 가집니다. 즉 VPC 안의 다른 호스트는 프라이빗 IP 주소로 이 호스트에 연결할 수 있지만, 인터넷의 다른 호스트는 이 호스트로 인바운드 통신을 할 수 없습니다.

프라이빗 서브넷에서는 NAT(Network Address Translation) 게이트웨이를 사용해 프라이빗 서브넷 안의 호스트가 인터넷에 연결되도록 허용할 수 있습니다. 인터넷의 호스트는 공용 서브넷 안에 있는 NAT 게이트웨이의 공용 IP 주소에서 오는 것처럼 보이는 인바운드 연결을 받습니다. NAT 게이트웨이는 인터넷과 프라이빗 서브넷 사이의 브리지 역할을 합니다. 이 구성은 VPC가 인터넷 공격자의 직접 접근으로부터 보호된다는 점에서 보안상 자주 선호됩니다. 자세한 내용은 Amazon VPC User Guide의 "NAT gateways"를 참고하세요.

이 프라이빗 네트워킹 방식은 컨테이너를 직접적인 외부 접근으로부터 보호하려는 시나리오에 적합합니다. 적용 가능한 시나리오로는 결제 처리 시스템이나 사용자 데이터·비밀번호를 저장하는 컨테이너가 있습니다.

계정에서 NAT 게이트웨이를 만들고 사용하는 데 비용이 청구되며, NAT 게이트웨이 시간당 사용료와 데이터 처리 요율도 적용됩니다.
중복성(redundancy)을 위해 각 Availability Zone에 NAT 게이트웨이를 두는 것이 좋습니다. 이렇게 하면 단일 Availability Zone의 가용성 손실이 아웃바운드 연결을 손상시키지 않습니다.
이러한 이유로 작은 워크로드라면 프라이빗 서브넷과 NAT 게이트웨이를 사용하는 것이 더 비용 효율적일 수 있습니다.

이 네트워킹 방식은 Amazon EC2의 Amazon ECS와 AWS Fargate의 Amazon ECS 모두에서 지원합니다.

Amazon EC2 — 프라이빗 서브넷에서 EC2 인스턴스를 시작할 수 있습니다. 이 EC2 호스트에서 실행되는 컨테이너는 기본 호스트의 네트워킹을 사용하며, 아웃바운드 요청은 NAT 게이트웨이를 통과합니다.
Fargate — Amazon ECS 서비스를 만들 때 서비스 네트워킹 구성에 프라이빗 서브넷을 지정하고 Assign public IP address 옵션을 사용하지 않습니다. 각 Fargate 태스크는 프라이빗 서브넷에서 호스팅되며, 아웃바운드 트래픽은 해당 프라이빗 서브넷에 연결된 NAT 게이트웨이를 통해 라우팅됩니다.

더 알아보기 (Learn more)

Amazon VPC 네트워킹에 대한 자세한 내용은 AWS 공식 문서를 참고해 주세요.