AWS API Gateway 안에서 HTTP API와 REST API를 고를 때는 WAF 연동, 고객별 사용량 계획, 비공개 API 엔드포인트가 필요한지 먼저 확인하세요. 이 요구가 있으면 REST API를 우선 검토합니다. 단순한 공개 HTTP 백엔드 연결과 JWT 인증이 중심이라면 HTTP API가 후보지만, 낮은 단가만 보고 필요한 기능을 빼면 안 됩니다.
혼동의 원인: 제품 이름과 API 설계 방식을 섞는다
HTTP API도 RESTful API를 제공할 수 있습니다. 여기서 REST API는 AWS 상품 유형 이름입니다. REST 방식으로 설계했다는 이유만으로 반드시 REST API 상품을 골라야 한다는 뜻은 아닙니다. 팀의 요구사항을 인증, 접속 경로, 고객별 제어로 나눠 보면 선택이 쉬워집니다.
| 요구 | 우선 검토 | 혼동 주의 |
| WAF 연동 | REST API | 정책 적용 위치 |
| 고객별 사용량 계획 | REST API | API 키는 인증 아님 |
| 비공개 API 엔드포인트 | REST API | 비공개 통합과 다름 |
| JWT 중심 공개 API | HTTP API | 필수 기능부터 대조 |
1. 고객별 한도와 인증을 따로 적는다
예를 들어 거래처별 호출량을 구분하고 사용량 계획을 적용해야 한다면 REST API의 기능을 검토합니다. API 키는 사용량 식별 수단이며 사용자 인증·권한 검사를 대신하지 않습니다. 사용량 계획의 제한도 엄격한 비용 상한을 보장하는 장치로 생각하지 마세요. 업무 권한과 비용 통제는 별도 설계가 필요합니다.
반면 이미 JWT를 발급하는 인증 체계가 있고 API마다 그 토큰을 검사하면 되는 서비스라면 HTTP API의 JWT authorizer를 검토할 수 있습니다. 토큰이 있다는 사실만으로 통과 처리하지 말고 발급자·대상·유효기간과 필요한 scope가 요구에 맞는지 시험합니다. 인증 실패와 권한 부족 응답도 성공 응답만큼 중요합니다.
2. 비공개 백엔드와 비공개 API 주소를 구분한다
백엔드가 VPC 안에 있다는 요구와 API 자체가 비공개 엔드포인트여야 한다는 요구는 다릅니다. HTTP API도 비공개 통합을 지원하지만 그것을 비공개 API 엔드포인트 지원으로 해석하면 안 됩니다. 설계도에 호출자가 어디에서 접근하고 어느 구간이 외부에 노출되는지 표시하세요.
WAF가 필수인 경우도 같은 방식으로 경계를 정합니다. 보안 정책이 요구하는 적용 지점에서 지원되는지 확인해야 하며, 다른 계층의 방어가 있다는 이유만으로 API 요구를 충족했다고 기록하지 않습니다. 보안 기능을 없애서 저렴한 유형에 맞추는 것은 비용 비교가 아닙니다.
3. 같은 요청 조건으로 견적과 변경 비용을 비교한다
월 요청량, 응답 크기, 리전, 백엔드 호출, 접근 로그 보존을 같은 조건으로 적고 해당 유형의 공식 요금을 확인합니다. 이 글은 숫자 단가나 절감률을 제시하지 않습니다. 기능을 애플리케이션에서 직접 구현해야 한다면 개발·운영 비용도 함께 비교해야 합니다.
기존 API를 바꾸는 경우에는 인증 방식뿐 아니라 요청·응답 형식, 오류 응답, 배포 방식과 통합 설정을 목록화하세요. 이름이 비슷하다고 설정을 그대로 옮길 수 있다고 가정하지 않습니다. 도메인 전환은 새 경로의 기능 검증이 끝난 뒤 별도 승인된 변경으로 다룹니다.
확인 방법: 세 가지 실패 요청을 먼저 준비한다
시험 환경에서 정상 요청, 만료되거나 잘못된 토큰, 권한 없는 요청, 과도한 요청을 같은 클라이언트로 보냅니다. 기대한 상태 코드와 백엔드 도달 여부, 로그에 남는 추적 정보를 비교합니다. 시험 트래픽의 양과 비용 한도를 먼저 정하고 운영 API에 부하를 주지 마세요.
되돌림을 위해 기존 API와 도메인 설정을 보존합니다. 새 경로가 정상이라는 증거가 생기기 전 기존 경로를 삭제하지 않습니다. 이 글은 문서 검토를 바탕으로 한 선택 절차이며 실제 API 생성이나 부하 시험 결과가 아닙니다.
FAQ
API 키를 로그인 토큰으로 써도 되나요? 사용량 식별과 인증은 별도입니다. 적절한 인증·권한 검사를 구성해야 합니다.
백엔드가 VPC 안이면 REST API만 가능한가요? 비공개 통합과 API 엔드포인트 공개 범위를 나눠 확인해야 합니다.
HTTP API가 언제나 더 경제적인가요? 필요한 기능의 추가 구현과 운영까지 같은 범위로 비교해야 합니다.
공식 출처와 관련 글
자료 확인일: 2026년 10월 18일. 공식 문서 기반 설명이며 실제 서비스·명령 실행 시험은 수행하지 않았습니다. 설치 버전과 리전·지원 범위는 적용 전에 확인하세요.
관련 글: AWS API Gateway와 Kong의 운영 책임 비교
적용 전 원본 설정을 보존하고 승인된 시험 범위에서 결과를 확인하세요.
'소프트웨어개발' 카테고리의 다른 글
| Aurora Serverless v2와 프로비저닝 비교: 최소 ACU·유휴 시간·지연 조건 (0) | 2026.10.19 |
|---|---|
| systemd start-limit-hit 해결: 최초 실패를 고친 뒤 reset-failed로 복구 (0) | 2026.10.18 |
| Docker invalid reference format 해결: 이미지 이름과 셸 인수를 구분해 점검 (0) | 2026.10.18 |
