private subnet에 ECS 배포 이유
-
퍼블릭 인터넷 위협에 대한 노출 감소(보안 강화): 프라이빗 서브넷에서 ECS를 실행하면 DDoS 공격 또는 자동 스캐닝과 같은 퍼블릭 인터넷에서 발생하는 공격의 위험을 줄일 수 있습니다. 이러한 격리는 일반적인 위협으로부터 컨테이너화된 애플리케이션과 인프라를 보호하는 데 도움이 됩니다.
-
향상된 네트워크 성능: 프라이빗 서브넷에서 ECS를 실행하면 프라이빗 IP 주소 지정을 활용할 수 있으므로 네트워크 성능이 향상되고 대기 시간이 단축될 수 있습니다. 프라이빗 서브넷 내의 컨테이너와 기타 리소스 간의 통신은 퍼블릭 네트워크를 통과하지 않고도 보다 효율적으로 발생할 수 있습니다.
-
프라이빗 리소스에 대한 액세스: 프라이빗 서브넷을 사용하면 ECS 컨테이너를 Virtual Private Cloud(VPC) 내의 다른 리소스에 안전하게 연결할 수 있습니다. 이를 통해 공용 네트워크에 노출하지 않고 개인 서브넷에서 실행되는 데이터베이스, 캐시 및 기타 백엔드 서비스와 직접 통신할 수 있습니다.
-
향상된 애플리케이션 아키텍처: 프라이빗 서브넷은 종종 확장 가능하고 내결함성 애플리케이션 아키텍처를 구축하기 위해 다른 AWS 서비스와 함께 사용됩니다. 예를 들어 프라이빗 서브넷에 ECS 클러스터를 배포하고 퍼블릭 서브넷에 로드 밸런서를 배치하여 들어오는 트래픽을 처리할 수 있습니다. 이 디자인 패턴은 추가 보안 계층을 추가하고 트래픽을 효율적으로 분산하는 데 도움이 됩니다.
전반적으로 프라이빗 서브넷에 ECS를 배포하면 컨테이너화된 애플리케이션에 대해 보다 안전한 환경을 제공하고 향상된 네트워크 성능을 얻을 수 있습니다.
VPC Endpoint 사용
VPC Endpoint VS Nat gateway
Nat gateway
NAT를 이용하는 이유는 대개 사설 네트워크에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위함이다.
Internet 접속이 가능한 Public Subnet에 NAT Gateway를 생성해두고, Private Subnet이 외부 인터넷으로 나아갈 경우에만 사용하도록 라우팅을 추가해주는 것이다.
public 서브넷과 private 서브넷은 같은 VPC안에 있으면 서로 통신할수있다는 점을 이용하여, NAT 게이트웨이를 생성해주면 마치 대리기사 역할처럼 public 서브넷이 외부 인터넷 데이터를 private 서브넷에게 대신 전달해주게 된다.
NAT Gateway는 내부에서 외부로의 접속만 가능하며 외부에서 NAT Gateway를 이용하여 접속하는 것은 불가능하다는 특징을 가지고 있다. 따라서 NAT Gateway를 이용하면 외부 인터넷 연결에 의한 보안 문제도 일석이조로 해결할 수 있게 된다.
VPC Endpoint
다음은 이전에 정리한 VPC Endpoint 내용이다
VPC Endpoint
VPC Endpoint 실습
VPC Endpoint(PrivateLink) 요금
- 1TB : 48 USD
- 1PB : 10277 USD
NAT Gateway 요금
- 1TB : 103 USD
- 1PB : 60459 USD
AWS에서 서비스 운영시 Private 환경의 인스턴스가 VPC 외부의 AWS 서비스를 이용하고자 할때는 VPC 엔드포인트 사용을 고려하여 비용을 줄일 수 있다.
VPC 엔드포인트 생성
위의 AWS 공식문서를 들어가보면 private subnet에 배포되어있는 ECS가 ECR에 있는 이미지를 가져오기 위해서 생성 해야할 엔드포인트들을 소개한다.
-
Linux 플랫폼 버전
1.4.0이상을 사용하여 Fargate에서 호스팅되는 Amazon ECS 태스크를 수행하려는 경우, com.amazonaws.region.ecr.dkr 및 com.amazonaws.region.ecr.api Amazon ECR VPC 엔드포인트뿐만 아니라 Amazon S3 게이트웨이 엔드포인트까지 사용해야 이 기능을 활용할 수 있습니다. -
awslogs로그 드라이버를 사용하여 로그 정보를 CloudWatch Logs로 보내느 Amazon ECR에서 컨테이너 이미지를 가져오는 Fargate에서 호스팅되는 Amazon ECS 작업은 CloudWatch Logs VPC 엔드포인트를 필요로 합니다. 자세한 내용은 CloudWatch Logs 엔드포인트 생성 섹션을 참조하세요. -
VPC 엔드포인트는 현재 Amazon ECR 퍼블릭 리포지토리를 지원하지 않습니다. 풀스루 캐시 규칙을 사용하여 VPC 엔드포인트와 동일한 리전의 프라이빗 리포지토리에서 퍼블릭 이미지를 호스팅하는 것을 고려해 보세요. 자세한 내용은 풀스루 캐시 규칙 사용 섹션을 참조하세요.
-
VPC 엔드포인트는 교차 리전 요청을 현재 지원하지 않습니다. API 호출을 Amazon ECR로 발행할 계획인 동일 리전에 VPC 엔드포인트를 생성해야 합니다.
위의 내용에 따르면 endpoint는 아래의 사진과 같이 4개가 생성되어야 한다.
또한 ECR은 private repository여야 하고 리전이 동일한 곳에 ECS를 배포해야 한다.
- 엔드포인트가 4개나 ip를 할당받는다고 생각하면 VPC의 CIDR을 조정해서 넉넉하게 IP 여유 개수를 확보해야한다.
로드밸런서 설정
ECS는 private subnet에 두었지만 로드 밸런서는 public에 둠으로써 외부에서 들어오는 요청을 private subnet안의 ECS로 전달 할 수있게 설정이 필요합니다.
ECS 서비스 생성창에서 로드밸런서를 만들시 원하는대로 지정할 수 없으니 따로 만들어서 기존 로드밸런서 선택으로 연결해야 합니다.
로드밸런서 생성
-
ALB를 사용하였다.
-
인터넷 경계를 체크해야한다 private subnet에 연결할 것이라고 내부를 선택하면 안된다.
-
가장 중요한 부분이다 네트워크 매핑을 public subnet으로 지정한다.
네트워크 매핑으로 지정한 부분이 로드밸런서가 위치하는 곳이다.
위와 같이 로드밸런서를 생성해서 ECS에 연결해준다.
참조
https://velog.io/@xgro/VPC-Endpoint
https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-NAT-Gateway-NAT-Instance-%EB%8C%80%EC%B2%B4%ED%95%B4%EC%84%9C-%EB%B9%84%EC%9A%A9-%EC%A0%88%EC%95%BD
