Amazon ECS Gateway 공개: 컨테이너 인그레스를 플랫폼 표준으로 바꾸는 방법

컨테이너 서비스를 하나 배포할 때마다 애플리케이션 코드보다 네트워크 부속 자원을 더 오래 만지는 팀이 많습니다. Application Load Balancer(ALB), 인증서, 리스너 규칙, 대상 그룹, 보안 그룹, DNS를 따로 만들고 연결한 뒤, 서비스가 늘어날 때마다 설정이 서로 어긋나지 않는지 확인해야 하기 때문입니다. 이 반복 작업은 단순히 번거로운 수준을 넘어, 플랫폼팀과 애플리케이션팀 사이에 “누가 어떤 네트워크 설정을 소유하는가”라는 운영 경계를 만듭니다.

AWS는 2026년 10월 20일 이 문제를 겨냥한 계정 수준 리소스인 Amazon ECS Gateway를 발표했습니다. 플랫폼팀이 한 번 정한 서브넷, 보안 그룹, TLS 인증서, 리스너, WAF 정책을 게이트웨이에 저장하면, 애플리케이션팀은 ECS 서비스 정의에 게이트웨이 연결 정보만 추가할 수 있습니다. ECS가 서비스별 인증서와 DNS 호스트명, 리스너 규칙, 대상 그룹, ALB에서만 들어오는 서비스 보안 그룹을 계정 안에서 자동으로 만들고 회수합니다.

이 글은 AWS의 공식 발표, ECS의 로드 밸런싱 문서, ECS 인바운드 네트워크 모범 사례, ECS 요금 안내를 교차 확인해 작성했습니다. 발표 당일의 기능과 한도는 빠르게 바뀔 수 있으므로 실제 도입 전에는 리전별 문서를 다시 확인해야 합니다.

1. 이번 발표의 핵심은 “새 로드 밸런서”가 아니다

ECS Gateway가 기존 ALB를 대체하는 새로운 데이터 플레인이라고 이해하면 기능을 잘못 사용할 수 있습니다. 실제로 트래픽을 처리하는 것은 여전히 ALB입니다. Gateway는 플랫폼팀이 관리하는 인그레스 정책과 ECS 서비스 배포를 연결하는 제어 계층에 가깝습니다.

운영 흐름은 다음과 같습니다.

플랫폼팀이 게이트웨이를 만들고 인터넷 공개형 또는 VPC 내부형 스킴, 서브넷, IP 주소 유형, 리스너 포트와 프로토콜, WAF 웹 ACL, 인프라 IAM 역할을 지정합니다.
게이트웨이를 하나 이상의 ECS 클러스터에 연결합니다. 하나의 게이트웨이는 최대 10,000개 클러스터와 연결할 수 있고, 클러스터 하나는 최대 5개 게이트웨이를 연결할 수 있습니다.
애플리케이션팀은 ECS 서비스 생성·수정 시 gateway connector를 추가합니다.
ECS가 클러스터에 연결된 게이트웨이 중 접근 유형, VPC, 가용 영역이 호환되는 것을 선택합니다.
기존 ALB에 여유가 있으면 호스트 기반 라우팅 규칙을 추가하고, 없으면 새 ALB를 만들며, 서비스가 삭제되면 관련 리소스를 정리합니다.

따라서 Gateway의 가치는 “ALB를 더 빠르게 만드는 것”이 아니라 ALB를 서비스팀이 직접 조립하지 않아도 되게 만드는 표준화에 있습니다. AWS는 하나의 ALB에 최대 25개 서비스를 공유할 수 있도록 설계해, 서비스 수가 많은 ECS 계정에서 로드 밸런서 단위 비용과 설정 편차를 줄일 수 있다고 설명합니다.

2. 플랫폼팀과 애플리케이션팀의 책임을 분리한다

수동 구성에서는 서비스 담당자가 ALB를 직접 만들면서 인터넷 노출 범위, 인증서 선택, 보안 그룹, WAF 적용 여부를 모두 결정하게 됩니다. 빠른 시작에는 유리하지만 조직이 커지면 각 팀의 판단이 달라지고, 보안팀은 배포 후에야 문제를 발견합니다.

ECS Gateway는 이 책임을 두 층으로 분리합니다.

주체	맡는 일	설계상 의미
플랫폼팀	게이트웨이, 서브넷, TLS, WAF, 리스너, 인프라 역할, 클러스터 연결	조직의 기본 네트워크 정책을 코드와 계정 경계에 고정
애플리케이션팀	서비스 포트, 헬스 체크, 접근 유형 필터, 배포	제품 개발 속도를 유지하면서 네트워크 정책을 소비
ECS 제어 플레인	인증서·DNS·리스너 규칙·대상 그룹·서비스 보안 그룹의 생성·정리	리소스 누락과 설정 드리프트를 줄임

이 구조는 “개발자가 아무것도 몰라도 된다”는 뜻이 아닙니다. 서비스팀은 여전히 공개 서비스인지 내부 서비스인지, 어느 가용 영역에 태스크를 배치하는지, 헬스 체크가 무엇인지 결정해야 합니다. 다만 보안 경계를 매번 새로 설계하지 않고 플랫폼팀이 제공하는 선택지 안에서 배포하게 됩니다.

특히 인프라 역할은 중요합니다. ECS가 ALB, ACM, EC2 보안 그룹과 같은 리소스를 계정 안에서 관리하려면 위임된 IAM 역할이 필요합니다. 이 역할에 광범위한 관리자 권한을 주면 자동화가 늘어나는 만큼 영향 범위도 커집니다. 역할을 별도 계정·클러스터·태그 조건으로 제한하고, CloudTrail에서 역할의 생성·변경·삭제 이벤트를 추적해야 합니다.

3. 기존 ECS 인그레스와 무엇이 다른가

ECS는 원래도 ALB를 서비스에 연결할 수 있고, ALB는 경로 기반·호스트 기반 라우팅으로 여러 서비스를 공유할 수 있습니다. 따라서 ECS Gateway가 모든 환경에 필요한 것은 아닙니다.

수동 ALB 구성이 적합한 경우는 다음과 같습니다.

하나의 서비스가 여러 리스너와 복잡한 인증 흐름을 직접 제어해야 하는 경우
ALB를 애플리케이션용 Terraform 상태에서 명시적으로 관리해야 하는 경우
비표준 리스너 규칙, 다중 대상 그룹, 서비스 메시와의 세밀한 연동이 필요한 경우
TCP·UDP가 중심이어서 ALB가 아닌 NLB가 필요한 경우

반대로 Gateway는 다음 조직에 잘 맞습니다.

여러 팀이 동일한 ECS 클러스터에 웹 서비스와 API를 계속 추가하는 경우
모든 외부 엔드포인트에 동일한 TLS·WAF·서브넷 기준을 강제해야 하는 경우
플랫폼팀은 네트워크를 관리하고 개발팀은 서비스 배포에 집중하려는 경우
서비스 삭제 때 대상 그룹과 보안 그룹이 남아 비용·보안 부채가 되는 경우

Gateway는 ECS Service Connect와도 역할이 다릅니다. Service Connect는 ECS 내부 서비스 간 이름 해석, 프록시 기반 연결, 서비스 간 관찰성을 위한 기능입니다. Gateway는 인터넷 또는 VPC 외부 클라이언트가 ECS 서비스로 들어오는 북-남 방향 인그레스를 다룹니다. 내부 호출은 Service Connect, 외부 진입은 Gateway라는 식으로 조합할 수 있지만, 두 기능을 하나의 API 게이트웨이로 오해하면 안 됩니다.

4. 새 서비스가 실제로 연결되는 조건

AWS 발표에서 강조한 호환 조건은 운영 중 장애를 줄이는 데 중요합니다.

서비스와 게이트웨이는 같은 VPC에 있어야 합니다.
게이트웨이가 포함하는 가용 영역이 서비스의 가용 영역을 모두 덮어야 합니다.
서비스의 gateway connector 필터와 게이트웨이의 공개형·내부형 접근 유형이 일치해야 합니다.
서비스는 awsvpc 네트워크 모드를 사용해야 합니다.
EC2, Fargate, ECS Managed Instances 등 지원되는 모든 ECS 시작 유형에서 사용할 수 있습니다.

예를 들어 서비스 태스크가 세 개의 가용 영역에 배치되는데 Gateway ALB가 두 영역에만 서브넷을 가지고 있으면, 라우트가 활성화되지 않거나 배포가 실패할 수 있습니다. 플랫폼팀이 게이트웨이를 만들 때 서비스가 사용할 영역과 동일한 서브넷 집합을 선택하고, 배포 파이프라인에서 영역 불일치를 사전 검사하는 것이 안전합니다.

Gateway는 ALB가 처리할 수 있는 용량에 따라 서비스들을 배치합니다. 사용 가능한 ALB가 없으면 새 ALB를 만들지만, maxAlbCount 한도에 도달했는데도 용량이 없으면 배포가 실패합니다. 공식 발표의 기본 한도는 10개입니다. “서비스가 늘어나면 ALB도 무한히 늘어난다”가 아니라, 예상 서비스 수와 리스너 규칙·대상 그룹·가용 영역을 계산해 한도를 설계해야 합니다.

5. 비용과 운영 편의의 교환

ECS Gateway 자체에는 별도 사용료가 없다고 AWS는 설명합니다. 그렇다고 무료 인그레스가 되는 것은 아닙니다. 서비스가 연결될 때 계정 안에 실제 ALB, 인증서, CloudWatch 로그·메트릭, 데이터 전송 자원이 생기고, 그 사용량에 대한 비용을 지불합니다.

특히 다음 상황에서 비용이 예상보다 커질 수 있습니다.

트래픽이 거의 없는데도 여러 공개형 ALB가 항상 켜져 있는 경우
가용 영역을 넓혀 ALB를 여러 개 만들고, 서비스 수가 급증하는 경우
WAF·로그·데이터 전송량이 서비스팀의 예상보다 큰 경우
삭제된 서비스가 아닌 다른 경로가 남아 ALB가 계속 유지되는 경우

Gateway가 ALB를 공유해 주는 것은 비용 절감의 기회이지 보장된 할인은 아닙니다. 플랫폼팀은 게이트웨이별 태그와 비용 할당 기준을 정하고, 서비스별 ALB 시간·요청량·WAF 처리량을 CloudWatch와 비용 탐색기에서 연결해야 합니다. 비용이 중요한 단기 테스트 환경이라면 API Gateway나 내부 로드 밸런서가 더 적합할 수도 있습니다.

운영 편의성도 공짜가 아닙니다. ECS가 리소스를 자동으로 만들면 Terraform이나 CloudFormation 상태에 모든 하위 리소스를 직접 기록하지 않아도 되지만, 팀은 “누가 만든 리소스인지”를 태그와 ECS Gateway ARN으로 찾아야 합니다. 자동 생성 리소스를 수동으로 바꾸기 시작하면 다음 배포 때 ECS가 덮어쓰거나 정리할 수 있습니다. 자동 관리 영역과 사람이 직접 관리할 영역을 문서로 구분해야 합니다.

6. 관찰성과 장애 대응

ECS Gateway를 도입할 때 가장 먼저 준비해야 할 것은 알림 대시보드입니다. AWS는 공유 ALB의 전체 트래픽은 LoadBalancer 차원으로, 서비스별 트래픽은 TargetGroup 차원으로 관찰할 수 있다고 안내합니다.

최소한 다음 지표를 서비스별로 수집하는 것이 좋습니다.

HealthyHostCount: 실제 요청을 받을 수 있는 태스크 수
TargetResponseTime: 서비스 지연이 ALB 계층에서 어떻게 보이는지
HTTPCode_Target_5XX_Count: 애플리케이션 오류와 인그레스 오류를 구분할 단서
ALB의 신규 연결·활성 연결 수와 처리 바이트
게이트웨이 라우트 상태가 ACTIVE가 되었는지
인증서 발급·갱신과 WAF 차단 이벤트

공유 ALB에서는 한 서비스의 급격한 트래픽이 다른 서비스의 지연으로 이어질 수 있습니다. 따라서 ALB 전체 지표만 보고 “정상”이라고 판단하면 안 됩니다. TargetGroup별 SLO와 경보를 만들고, 라우트가 ACTIVE가 되지 않았을 때 배포를 자동 중지하는 것이 좋습니다.

기존 서비스에서 Gateway로 이전할 때는 한 번에 ALB를 삭제하지 않는 편이 안전합니다. AWS는 기존 로드 밸런서 구성을 유지한 채 Gateway connector를 추가할 수 있도록 안내합니다. 새 DNS 호스트명으로 헬스 체크와 실제 요청을 검증한 뒤, 트래픽을 점진적으로 이동하고 문제가 없을 때 기존 ALB를 제거하는 단계적 전환이 적합합니다.

7. 플랫폼 엔지니어링 관점의 도입 순서

1단계: 표준 프로파일 정의

공개형·내부형 게이트웨이를 분리하고, 허용된 서브넷·보안 그룹·리스너 포트·TLS 정책·WAF 규칙을 플랫폼 표준으로 정의합니다. 개발팀이 임의로 인터넷 공개형 게이트웨이를 만들 수 없도록 IAM과 클러스터 연결 권한을 분리합니다.

2단계: 최소 서비스로 검증

무상태 HTTP 서비스 하나를 선택해 합성 트래픽으로 검증합니다. 헬스 체크 실패, 가용 영역 불일치, 인증서 지연, ALB 용량 부족, WAF 차단이 각각 어떻게 보이는지 기록합니다.

3단계: 비용·관찰성 기준 추가

게이트웨이와 자동 생성 하위 리소스에 공통 태그를 붙이고, TargetGroup별 비용·오류율·지연 대시보드를 제공합니다. 비용 상한에 도달하면 배포 파이프라인이 경고하도록 합니다.

4단계: 기존 서비스의 점진적 이전

기존 ALB를 유지한 채 Gateway 라우트를 추가하고, 내부 사용자·테스트 도메인·일부 트래픽부터 전환합니다. 롤백은 기존 ALB로 DNS를 되돌리는 한 단계로 설계해야 합니다.

5단계: 정책을 제품으로 제공

최종적으로 플랫폼팀은 “ALB를 만드는 방법”이 아니라 “내부 API”, “공개 웹”, “파트너 전용 API”와 같은 서비스 프로파일을 제공합니다. 각 프로파일이 어느 게이트웨이, WAF, TLS 정책, 로그 보존 기준을 사용하는지 카탈로그로 공개하면 개발팀이 네트워크 전문 지식 없이도 안전한 기본값을 선택할 수 있습니다.

8. 한계와 주의할 점

첫째, Gateway는 HTTP·HTTPS 인그레스의 반복 구성을 줄이는 기능이지, 애플리케이션 인증·인가를 대신하지 않습니다. ALB와 WAF가 있어도 서비스 내부의 사용자 권한 검사는 별도로 필요합니다.

둘째, 자동 생성된 인증서와 DNS 호스트명은 편리하지만 조직의 도메인·인증서 수명주기 정책과 충돌할 수 있습니다. 규제 환경에서는 어떤 인증서를 누가 승인했는지, DNS 변경이 어떤 감사 기록을 남기는지 확인해야 합니다.

셋째, ALB 공유는 비용과 리소스 효율을 높이지만 장애 도메인도 공유합니다. 서로 다른 중요도·배포 주기·규제 수준의 서비스가 하나의 ALB에 모이면, 플랫폼팀은 게이트웨이를 분리해 blast radius를 제한해야 합니다.

넷째, Gateway가 “구성 드리프트를 없앤다”고 보장하지는 않습니다. 게이트웨이 설정이 바뀌면 다음 배포에서 서비스 연결 상태가 달라질 수 있고, 클러스터·서브넷·가용 영역 변경이 기존 서비스에 영향을 줄 수 있습니다. 게이트웨이 변경도 애플리케이션 코드와 같은 변경 검토·승인·롤백 절차를 거쳐야 합니다.

다섯째, 발표 시점의 기능과 한도는 초기 버전일 수 있습니다. 모든 상용 리전에서 사용 가능하다고 발표됐지만, 조직의 파티션·규제 리전·서비스 쿼터는 별도 확인이 필요합니다. AWS 문서에서 API, CloudFormation, Terraform 지원 범위를 확인한 뒤 운영 자동화에 편입해야 합니다.

9. 실무 체크리스트

게이트웨이 유형을 공개형과 내부형으로 분리했는가?
게이트웨이와 태스크의 VPC·가용 영역·서브넷이 호환되는가?
인프라 IAM 역할이 ALB·ACM·보안 그룹에 필요한 최소 권한만 가지는가?
서비스팀이 임의로 게이트웨이를 만들거나 다른 클러스터에 연결할 수 없게 했는가?
TLS 인증서·WAF·리스너 설정의 변경 이력이 감사 로그에 남는가?
TargetGroup별 HealthyHostCount, 응답 시간, 5xx 경보가 있는가?
maxAlbCount와 ALB·리스너·대상 그룹 쿼터를 서비스 증가 계획에 반영했는가?
자동 생성 리소스에 비용·소유자·환경 태그가 전파되는가?
기존 ALB를 유지한 점진적 전환과 즉시 롤백 경로가 있는가?
서비스 삭제 후 게이트웨이 라우트와 마지막 ALB가 실제로 정리되는지 확인했는가?
내부 서비스 간 통신은 Service Connect, 외부 인그레스는 Gateway로 책임을 분리했는가?
도메인·인증서·WAF·데이터 보존 기준이 규제 요구와 맞는가?

결론

Amazon ECS Gateway의 기술적 의미는 새로운 로드 밸런싱 알고리즘에 있지 않습니다. 서비스마다 반복되던 인그레스 조립 작업을 계정 수준의 플랫폼 정책으로 올리고, 애플리케이션팀은 서비스 연결 의도만 선언하게 만든 점이 핵심입니다.

도입을 서두르기보다 다음 순서로 접근하는 것이 좋습니다.

공개·내부 게이트웨이의 표준과 IAM 경계를 먼저 정합니다.
동일한 가용 영역과 최소 권한 역할로 작은 서비스 하나를 검증합니다.
TargetGroup 중심 관찰성과 비용 태그를 배포 전에 준비합니다.
기존 ALB와 병행해 점진적으로 이전하고, 실패하면 즉시 되돌립니다.
중요도와 장애 도메인이 다른 서비스는 게이트웨이를 분리합니다.

컨테이너 플랫폼이 성숙할수록 개발팀이 직접 만지는 인프라의 양을 줄이는 것이 목표가 됩니다. 그러나 추상화가 성공하려면 자동화된 기본값의 이유와 한계를 함께 제공해야 합니다. ECS Gateway는 그 방향을 보여주는 기능이며, 조직의 네트워크 정책·비용 모델·운영 책임을 다시 설계할 때 가장 큰 가치를 발휘합니다.