API Gateway와 EC2 연결하기.

API Gateway를 활용하여, EC2 인스턴스에 프록시로서 연결하는 방법에 대해 알아보겠다.

보통 AWS Lambda의 API를 만들때 API Gateway를 활용하곤 한다.

그런데, 몇몇 경우에는 EC2에 Proxy를 만들어서 사용해야하는 경우가 있다.

EC2 인스턴스에 FastAPI 서버 하나를 돌리고 있으니, “http://x.x.x.x:5000/“ 라는 서버에 API Gateway를 연결해보도록 하겠다.

API Gateway - 제공 API 유형

API Gateway에서 제공하는 API는 대표적으로 3종류가 있다.

• HTTP API : API 프록시 기능정도만 필요할 때 적합. 단순 / 저렴하고 빠르다.
• REST API : API 관리 기능, 요청/응답에 대한 제어가 필요할 경우 적합, 복잡 / 비싸고 느리다.
• WebSocket API : 웹소켓 용도. 실시간 애플리케이션에서 주로 사용한다.

출처: https://inpa.tistory.com/entry/AWS-📚-API-Gateway-개념-기본-사용법-정리#rest_api [Inpa Dev 👨‍💻:티스토리]

HTTP API

• HTTP를 통신 방식으로 사용하는 API를 HTTP API라고 한다.
• HTTP API는 Endpoint를 API gateway로 활용하여 HTTP 요청을 통해서 서버에 접근할 수 있도록 만들어준다.
• HTTP API는 데이터만 주고 받고 UI 화면이 필요하면 클라이언트가 별도로 처리한다. 대게 앱/웹/서버 to 서버에서 사용된다.
• 대부분의 Web API가 HTTP API로 이루어지고 있다.

REST API

• REST API는 HTTP API에 여러가지 제약 조건이 추가된 형태이다.

• 자원의 식별

• 메시지를 통한 리소스 조작

• 자기서술적 메세지

• 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

• REST는 웹 서비스의 구조를 만드는데 활용되는 패턴이며 위의 4가지 제약조건을 만족해야 RESTFUL 하다라고 말할 수 있다.

• 대표적으로 CRUD 메서드 동작을 일컫는다. CREATE(post), READ(get), UPDATE(put), DELETE(delete)

• 그런데 이런 부분을 완벽하게 지키면서 개발하는 것은 현실적으로 어렵고, 또 추가 개발 비용대비 효과가 있는 것도 아니어서, 이미 많은 사람들이 해당 조건을 지키지 않아도 REST API라고 하기 때문에, HTTP API나 REST API를 거의 같은 의미로 사용하고 있는 현실이다. (물론 엄격하게는 다르다)

WEBSOCKET API

• 요청을 받고 응답하는 REST API와 달리 WebSocket API는 클라이언트 앱과 백엔드 간의 양방향 통신을 지원한다.
• 웹 소켓은 사용자의 브라우저와 서버 사이의 인터액티브 통신 세션을 설정할 수 있게 하는 고급 기술 이다.
• 채팅 앱 및 스트리밍 대시보드와 같은 실시간 양방향 통신 애플리케이션을 구축하여 백엔드 서비스와 클라이언트 간의 메시지 전송을 처리하기위해 지속적인 연결을 유지한다.

API Gateway

API Gateway는 람다와 같이 서버리스 서비스이며, 수신한 API 호출에 대해서만 지불한다.
다만 HTTP API / REST API / WEBSOCKET API 각각 모두 요금대가 다르다.

API Gateway 중 REST API 사용

REST API 게이트웨이 생성

API Gateway 콘솔에서 API 생성 > REST API 생성을 클릭한다.

API 세부정보

• 새 API
• 엔드포인트 유형 - 지역

엔드포인트 유형

• 지역 : 특정 리전 안에서 사용
• 최적화된 에지 : CloudFront 사용(일반적인 인터넷 상)
• 프라이빗 : AWS내 VPC에서만 접근 가능

REST API 게이트웨이 경로 설정

API를 생성하면 HTTP API와는 달리 REST API는 구성 화면이 약간 복잡하게 되어있다. (HTTP API보다 제공 기능이 많아서 그렇다)

리소스 메뉴를 눌러 리소스 생성을 한다. 리소스는 실제 api를 호출하는 api url을 정의한다라고 보면 된다.

리소스 이름과 리소스 경로를 설정해준다.

리소스 경로 쪽에 {userid}와 같이 중괄호로 묶어주면 경로 파라미터로서 사용할수 있다.

경로 파라미터란, 예를들어 아래 URL 경로와 같이

http://localhost/hello/12
http://localhost/hello/667
http://localhost/hello/55

서비스 특성상 뒤의 경로가 고정되어있지 않고, 여러개의 경로값을 사용할경우 이들을 묶는 일종의 변수 역할이라고 보면 된다.

두개의 경로를 설정해줬으니 이제 요청할 메서드 설정을 해준다.

통합 유형으로 HTTP를 선택하고, 엔드포인트 URL에는 요청보낼 목적지를 설정한다.

https://api.github.com/users/{userid}

위 url은 깃헙에서 무료로 제공하는 api로서, {userid} 부분에 깃헙 프로필 닉네임을 적고 요청하면 해당 깃헙 프로필 정보를 json으로 반환해준다.

• 메서드 유형 : HTTP
• 엔드포인트 URL :
• 콘텐츠 처리 : 패스스루

REST API 게이트웨이 테스트 및 배포

메서드 등록이 완료되면, 메서드 실행 환경으로 접근된다.

{useri} 경로 파라미터에 닉네임 아무거나 적어서 테스트를 한다.

테스트까지 완료되면 완성된 REST API를 API Gateway에 정식 배포한다.

작업 > API 배포를 선택하여 API를 스테이지에 등록한다.

EC2의 네트워크 이슈

위 방법대로 api gateway를 배포했는데 504 에러가 난다.

ec2 끼리 ping 테스트도 안되는것을 보니 네트워크 문제가 있는듯하다.

1. 보안 그룹 설정 확인
   인바운드 규칙: 두 인스턴스의 보안 그룹에서 ICMP 프로토콜(핑 요청)을 허용하고 있는지 확인하세요. ICMP를 허용하려면:
   AWS 콘솔에서 보안 그룹으로 이동하여 두 인스턴스에 적용된 보안 그룹을 선택합니다.
   인바운드 규칙에서 Custom ICMP(사용자 지정 ICMP - IPv4) - Echo Request(에코 응답) 유형을 추가하고, 소스에 허용할 IP 범위(예: 0.0.0.0/0 또는 특정 CIDR 블록, Anywhere-IPv4)를 지정합니다.

또는 HTTP를 허용해줘야 한다.

아웃바운드 규칙: 대부분의 경우 기본적으로 모든 아웃바운드 트래픽이 허용되지만, 이를 확인하여 ICMP 프로토콜이 아웃바운드 트래픽에서도 허용되는지 점검합니다.

2. 네트워크 ACL 설정 확인
   네트워크 ACL: 인스턴스가 위치한 서브넷의 네트워크 ACL이 ICMP 트래픽을 허용하는지 확인합니다.
   네트워크 ACL에서 인바운드 및 아웃바운드 트래픽 모두에 대해 ICMP(코드 0, 유형 8) 규칙이 설정되어 있는지 확인합니다.
   네트워크 ACL은 상태 비저장(Stateless)이므로, 인바운드와 아웃바운드 규칙이 모두 필요합니다.

위의 내용들을 참고하여 설정해주면 같은 서브넷 내의 EC2 인스턴스끼리는 통신이 된다. (private IP로)

그런데 API Gateway에서는 EC2 호출이 되지 않고, 2번 EC2에서 1번 EC2 호출 시 public IP로는 실패한다.

하지만 퍼블릭 IPv4 DNS로 접근하면 된다… 아마 퍼블릭 IPv4 주소의 문제이지 않을까 싶다.

EC2끼리 통신은 해결했으니 이제 API Gateway -> EC2 통신이 잘 되도록 해결해야한다.

서브넷의 라우팅테이블 확인

EC2가 속해있는 VPC 서브넷의 라우팅 테이블이 0.0.0.0/0 -> IGW가 아니라 0.0.0.0/0 -> Transit Gateway 인것으로 보아

해당 서브넷이 퍼블릭 서브넷이 아님을 의미하며, 모든 트래픽이 Transit Gateway를 통해 라우팅된다는 것을 나타낸다.

Transit Gateway가 대상일 때의 의미:

• Transit Gateway 사용: Transit Gateway는 여러 VPC, 온프레미스 데이터 센터, 그리고 AWS의 다른 리전 간의 네트워크 연결을 중앙집중식으로 관리하는 서비스입니다. 이 설정은 모든 트래픽(특히 인터넷 트래픽이 아닌 트래픽)이 Transit Gateway를 통해 라우팅되어 다른 네트워크로 전달된다는 것을 의미합니다.

• 퍼블릭 서브넷이 아님: 인터넷 게이트웨이(Internet Gateway)가 대상이 아니기 때문에, 이 서브넷은 퍼블릭 서브넷이 아닙니다. 즉, 이 서브넷의 인스턴스들은 직접적으로 인터넷에 접근할 수 없습니다. 대신, 트래픽은 Transit Gateway를 통해 다른 네트워크(예: 다른 VPC, 온프레미스 네트워크)로 전달됩니다.

• 프라이빗 서브넷의 특성: 이 설정은 주로 프라이빗 서브넷에서 사용되며, 특정 리소스(예: 데이터베이스 서버, 내부 서비스 등)가 외부 인터넷이 아닌, 내부 네트워크나 다른 VPC로만 접근이 필요할 때 유용합니다.

실질적인 사용 사례:

• 기업 네트워크 통합: 여러 VPC나 온프레미스 네트워크를 AWS Transit Gateway를 통해 연결하고, 중앙집중식으로 네트워크를 관리하고자 할 때.
• 보안 강화: 인터넷에 직접 노출되지 않도록 하고, 모든 트래픽을 보안 정책이 적용된 내부 네트워크로만 전달하고자 할 때.

결론:

해당 서브넷은 퍼블릭 서브넷이 아니며, 외부 인터넷과의 통신은 불가능합니다. 모든 트래픽은 Transit Gateway를 통해 다른 VPC나 온프레미스 네트워크로 전달됩니다. 따라서, 인터넷을 통해 외부와 직접 통신하기 위해서는 별도의 퍼블릭 서브넷과 인터넷 게이트웨이를 사용하는 것이 필요합니다.

API Gateway가 VPC 리소스(EC2 인스턴스)와 상호작용하도록 VPC Link 설정하기

API Gateway는 일반적으로 AWS의 전역 서비스로 동작하며, 특정 VPC에 속하지 않습니다. 대신, API Gateway가 VPC 리소스(예: EC2 인스턴스)와 상호작용하도록 설정할 수 있는 방법이 있습니다. 이 설정은 **VPC 링크(VPC Link)**를 통해 이루어지며, 이 경우 API Gateway는 특정 VPC와 연결됩니다.

API Gateway를 통해 VPC 내의 리소스(예: EC2, NLB, ECS)와 통신해야 하는 경우, VPC 링크를 사용하여 안전하게 연결할 수 있습니다.
VPC 링크는 API Gateway와 VPC 내의 리소스 간의 프라이빗 통신을 가능하게 합니다.

API Gateway가 VPC 링크를 사용하지 않고 설정되어 있다면, API Gateway는 AWS의 관리형 인프라에서 실행되며, 특정 VPC에 속하지 않습니다.
API Gateway와 VPC 리소스 간의 연결이 필요하지 않은 경우에는 VPC 링크를 사용하지 않아도 됩니다.

VPC 링크 생성하기

먼저, VPC 링크를 생성합니다.

1. API Gateway 콘솔에 로그인:

• AWS 관리 콘솔에서 API Gateway로 이동합니다.

2. VPC 링크 생성:

• 왼쪽 메뉴에서 VPC Links를 선택한 후 Create 버튼을 클릭합니다.
• VPC 링크 이름을 지정하고, 연결할 네트워크 로드 밸런서(NLB)를 선택합니다.
• 필요한 경우, 태그를 추가합니다.
• Create 버튼을 눌러 VPC 링크를 생성합니다.

API Gateway에 VPC 링크 설정하기

이제, VPC 링크를 API Gateway의 특정 API 엔드포인트에 설정합니다.

1. API 선택:

• API Gateway 콘솔에서 VPC 링크를 설정할 API를 선택합니다.

2. 리소스 및 메서드 선택:

• 설정할 리소스 및 메서드를 선택합니다. 예를 들어, /plugin/test 리소스의 GET 메서드를 선택합니다.

3. 통합 유형 선택:

• Integration Request 섹션으로 이동합니다.
• **통합 유형(Integration type)**에서 VPC Link를 선택합니다.

4. VPC 링크 및 로드 밸런서 선택:

• 이전 단계에서 생성한 VPC 링크를 선택합니다.
• Endpoint URL 필드에 연결할 VPC 리소스의 URL을 입력합니다. 이 URL은 네트워크 로드 밸런서(NLB)의 DNS 이름과 해당 포트를 포함해야 합니다.
• 예시: http://:/

5. 저장 및 배포:

설정을 저장하고 API를 배포합니다.

참고

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-API-Gateway-%EA%B0%9C%EB%85%90-%EA%B8%B0%EB%B3%B8-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%A0%95%EB%A6%AC#rest_api