Amazon API Gateway

모바일 앱, 웹, 파트너 호출이 모두 같은 백엔드로 들어오는데 인증, 요청 제한, 버전별 라우팅을 각 서비스에 따로 넣으면 규칙이 쉽게 어긋납니다. API 앞단에서 공통 정책을 한 번에 걸지 못하면 변경할 때마다 여러 앱을 동시에 손봐야 합니다.

서비스가 적을 때는 각 서비스가 자체적으로 인증 검사, 요청 검증, 레이트 리밋을 구현해도 크게 문제가 없었습니다. 서비스가 늘어나면서 실무적인 고통이 커졌습니다. 서비스 A는 JWT 검증 로직을 업데이트했는데 서비스 B는 빠뜨려서 인증 규칙 불일치로 보안 사고가 날 뻔한 일이 생겼습니다. 레이트 리밋도 서비스마다 제각각이라 한쪽은 초당 100건을 허용하고 다른 쪽은 제한이 없어서, 트래픽이 몰리면 제한 없는 서비스가 과부하로 무너지고 그 여파가 다른 서비스로 번졌습니다. 정책 하나를 바꾸려면 서비스 저장소를 하나씩 돌며 같은 수정을 반복해야 했고, 빠진 곳이 있는지 확인하는 것 자체가 운영 부담이었습니다. 이 중복과 불일치를 없애기 위해, 모든 외부 요청이 거치는 단일 프런트도어에서 인증·스로틀링·라우팅 정책을 한 번에 적용하는 API Gateway 모델이 필요해졌습니다.

외부 요청이 들어오면 API Gateway는 먼저 토큰이나 API 키로 인증·인가를 확인하고, 설정된 스로틀링 한도를 초과했는지 체크합니다. 두 단계를 통과한 요청만 경로와 메서드 규칙에 따라 Lambda·EC2·ECS 같은 백엔드로 라우팅됩니다. 이 흐름이 하나의 프런트도어에서 일어나기 때문에, 각 백엔드에 인증이나 제한 로직을 따로 심지 않아도 됩니다. 스테이지와 배포 단위를 분리하면 동일한 API를 버전별로 독립적으로 운영할 수 있습니다.

API Gateway와 EventBridge는 둘 다 흐름의 시작점이 될 수 있지만 입력 성격이 다릅니다. API Gateway는 외부 요청을 받아 인증·스로틀링·정책을 적용하는 동기식 프런트도어이고, EventBridge는 이미 발생한 이벤트를 규칙으로 비동기 라우팅하는 버스입니다. 외부 클라이언트 API를 열어야 하면 API Gateway를 보고, 서비스 사이 사건 전달을 느슨하게 연결해야 하면 EventBridge를 보면 됩니다.

모바일·웹용 공개 API, 웹훅 수신, 서버리스 백엔드, 파트너용 인터페이스처럼 HTTP 진입점을 제품처럼 운영해야 할 때 적합합니다. 인증·스로틀링 없이 단순히 트래픽을 여러 서버로 나누는 것만 필요하면 맞지 않습니다.