AWS가 ECS 서비스의 인그레스 구성을 관리하는 Amazon ECS Gateway를 공개했습니다. 인그레스는 외부 요청이 서비스로 들어오는 경로입니다. 플랫폼팀이 기준을 정하고 애플리케이션팀이 서비스를 연결하면 필요한 네트워크 리소스를 관리하는 방식입니다. AWS 공식 발표
ECS Gateway는 계정 안에 ALB와 서비스별 연결 리소스를 구성하며, 기반 리소스의 비용은 별도로 발생합니다. 관리 기능에 추가 요금이 없다는 설명을 전체 네트워크가 무료라는 뜻으로 해석하면 안 됩니다.
이 글의 목차
서비스 앞에는 요청을 연결하는 여러 부품이 있습니다
사용자가 주소를 입력하면 DNS로 목적지를 찾고 TLS로 연결한 뒤 로드 밸런서를 거쳐 애플리케이션에 도착합니다. 로드 밸런서는 요청을 받을 서비스와 정상 인스턴스를 선택합니다. 컨테이너를 배포하는 것과 이 진입 경로를 구성하는 것은 서로 연결되지만 다른 작업이에요. 서비스마다 같은 설정을 반복하면 인증서나 상태 검사 기준이 제각각이 되기 쉽습니다.
관리형 인그레스는 이런 구성을 정해진 기준에 맞춰 연결하는 접근입니다. 애플리케이션팀은 노출할 서비스를 정하고 플랫폼팀은 공통 네트워크 정책과 경계를 관리할 수 있습니다. 자동화가 맡는 범위와 사용자가 직접 관리해야 하는 DNS·접근 정책·관측 설정을 나눠 보면, 장애가 생겼을 때 어느 계층부터 확인할지 분명해집니다.
공유 인그레스에서는 영향 범위를 먼저 정합니다
여러 서비스를 하나의 진입 계층에서 연결하면 공통 구성을 줄일 수 있지만 변경의 영향도 공유하게 됩니다. 특정 서비스의 경로 규칙이 다른 서비스와 겹치거나 공통 인증서·정책 변경에 문제가 생길 수 있어요. 외부 공개 서비스와 내부 관리 서비스가 같은 신뢰 경계에 들어가도 되는지부터 검토해야 합니다.
상태 검사도 애플리케이션의 의미와 맞춰야 합니다. 프로세스가 실행 중이라는 사실과 요청을 처리할 준비가 됐다는 사실은 다를 수 있습니다. 데이터베이스 연결 준비가 끝나기 전에 정상으로 표시하면 배포 직후 오류가 늘어날 수 있어요. 반대로 잠깐의 지연에 지나치게 민감하면 정상 인스턴스를 반복해서 제외할 수 있습니다.
기존 경로에서 전환할 때 비교할 흐름
가상의 전환 작업이라면 먼저 새 경로에서 시험용 호스트 이름으로 TLS와 라우팅을 확인합니다. 로그인과 업로드, 긴 응답처럼 앱의 실제 기능을 점검한 뒤 운영 요청 일부를 새 경로로 보냅니다. 단순한 첫 화면 응답만으로 준비 상태를 판정하지 않습니다. 되돌릴 때 어떤 DNS나 라우팅 설정을 복원해야 하는지도 함께 남깁니다.
관측 자료에는 서비스별 요청 수, 오류율, 지연과 기반 로드 밸런서의 지표를 같이 둡니다. 전체 오류율이 낮아도 특정 경로만 실패할 수 있기 때문입니다. 비용도 관리 기능과 실제 ALB 등 기반 리소스를 나누어 계산합니다. 자동 생성된 리소스의 소유자와 삭제 순서를 정해 두면 서비스 종료 후 남는 구성도 정리하기 쉽습니다.
기존 서비스에서 옮길 때
- 서비스의 네트워크 모드와 게이트웨이의 VPC·가용 영역 조건을 확인합니다.
- 기존 인그레스를 유지한 채 새 경로의 상태 검사와 TLS를 시험합니다.
- ALB 수용량, 한도와 서비스별 관측 지표를 준비합니다.
자동 생성된 리소스도 운영 대상입니다. 변경 이력과 정리 절차를 추적하면서 서비스별로 전환합니다.
발표문 기준일: 2026-10-20 · 확인일: 2026-10-24
