이전의 글대로 따라왔는데도, 정상적으로 동작이 되지않는다면, EC2의 보안그룹을 0.0.0.0으로 다열어보면 동작하는것을 확인할수 있다.
하지만 0.0.0.0으로 보안그룹을 설정한다면, 많은 공격을 당할수 있기 때문에, VPC link를 사용한 방법을 시도해보겠다.
기존에는 도메인 -> API Gateway -> 서버(IP:port) -> 동작 이런 방식이였다면,
Vpc link를 사용하여 도메인 -> Api Gateway -> NLB(Vpc link) -> Target Group -> 서버 의 동작의 형태로 변경할 예정이다.
기존에 x-api-key를 사용한 규칙은 그대로이니, 혹시 테스트할때 x-api-key를 꼭 사용해서 테스트를 진행하도록 하자
VPC link 연결 셋팅 순서
1. Target Group 생성
2. NLB 생성 및 Target Group 연결(리스너 연결)
3. EC2 보안 그룹 변경
4. Api Gateway 에 VPC Link로 NLB 연결
5. 배포 및 테스트1.Target Group 생성
- 나는 Target Group 에 Ec2를 연결할 예정이기때문에 instances를 선택했지만,
endpoint에 서버IP,lambda, ALB를 연결하고싶다면, 변경해도 된다.
나는 EC2를 연결하려고 하기때문에 instance를 선택했다. - protocol은 TCP로 받아내고 port=20000을 했다. 내가 이전글에서 만들어놓은 dummy서버가 20000port로 동작하기 때문.
- AWS를 사용하고 있다면, 당연히 VPC도 개별적으로 구축해서 만들었다고 생각하고 진행하겠다.
Default외에 자신이 구축한 신규 VPC 가 있다면 거기에 연결해도 된다.
단! VPC 내부의 IP가 어떤건지는 정확히 알고 있어야 한다. 또한 생성한 EC2도 같은 VPC내부에 있어야 한다.
나는 내가 구축한 VPC로 연결하겠다. IP는 내부라서 추후에 같이 볼 수 있도록 하겠다.
개인 적으로 사용하는 서버 및 회사의 서버도 있기 때문에 가린것은 양해를 구합니다.
생성한 EC2를 선택하고 Target Group에서 보낼 port를 적은후 pending하여 아래에 포함하고, 생성을 누르자.
아직 NLB에 연결이 되어있지 않기 때문에 health check 가 되지 않는다, 무시하고 NLB랑 연결을 진행하도록 하자
2.NLB 생성 및 Target Group 연결(리스너 연결)
내가 생성한 VPC를 선택하자
내가 가용하는 VPC 내부 영역은 [ap-northeast-2a, ap-northeast-2c] 두가지다 public으로 구현 하도록 하겠다.
연결할 리스너를 Target Group에 맞춰서 protocol 과 port를 설정하는것이 중요하다.
리스너를 추가로 생성하여 여러가지의 라우팅리스너를 만들고 싶다면 Add listener를 여러개 해도 무방하다.
만약 내가 생성한 Target Group이 나오지않는다면 새로고침을 눌러 다시 확인을 해보자.
summart를 확인하여 내가 만든 설정값이 맞는지 확인하고 생성을 눌러주자
3. EC2 보안 그룹 변경
EC2 콘솔로 들어와 다음과 같이 확인해보자
내가 생성한 dummy 서버의 보안그룹은 0.0.0.0 으로 모든 방화벽이 열려있다. 이걸
내가 생성한 VPC에 맞게 변경할 예정이다. 변경 하고 나면 Gateway랑 연결하기 전까지 통신은 불가능하다.
보안그룹을 VPC내부 IP에 맞게 변경해주자
1. 나의 VPC 내부 IP이다 가용영역에 따라 다르기 때문에 IP를 신경써서 변경해주도록 하자
2. 나의개인 로컬 IP이다.
4. Api Gateway 에 VPC Link로 NLB 연결
이전에 만들었던 Api gateway로 콘솔로 들어가보자.
Target NLB에 내가 생성한 NLB를 선택한다. 선택 리스트에는 이름으로 나오지만 선택이 되면
해당 NLB의 DNS로 나오기 때문에 걱정하지 말자.
가용 영역내의 NLB추가하는데에는 시간이 걸릴수도 있으니 조금만 기다려보자
여기 까지 했으면 여태동안 연결한 것들이 정상적으로 동작하고 있는지 확인해 보면서 기다려보자.
- NLB에서 Target Group으로의 protocol 및 연결 상태 확인
- Target Group의 health status 확인
NLB의 DNS를 꼭 기억할것!!!!!!!!
Jinho-VPC-NLB-ed6403bdde7604fd.elb.ap-northeast-2.amazonaws.com
위처럼 healthy로 동작되는지 확인해보자.
만약 healthy가 아니라연결이 안된다면, 서버에 flask가 해당포트로 동작하지 않을수도 있으니 확인하고,
pending한다음에 다시 재연결 해보자
Vpc link 탭에 위 사진처럼 pending이 없어졌다면, 이제 Gateway안에 연결할 Method 쪽으로 들어가자
1. 연결타입에 VPC link를 선택하고, 동일하게 proxy를 사용하니 체크하도록하자
2. VPC link 에는 내가 생성한 VPC link를 선택하자
3. Endpoint URl에는 꼭 http 와 포트 , proxy를 작성하도록 하자
5. 배포 및 테스트
배포의 방법은 이전과 똑같다. 새로운 배포탭을 만들어도 되고, stage만 변경해도된다.
나는 동작 방식이 바뀌었으니, 새로운 Stage를 만들도록 하겠다.
정상적으로 배포가 되었으면 도메인에 연결된 API 매핑을 변경해줘야한다.
위처럼 stage를 변경하고 저장하도록 하자
배포 끝났으니 테스트를 해보자.
정상적으로 통신이 되는것을 확인할수있다. 성공~
AWS Gateway[1,2,3]을 구축하면서 빙빙돌아 실수했던부분을 정리해보자
1. Auth 인증 Lambda를 만들때 코드 및 API Keys를 정확하게 사용하자.
2. 테스트를 중간중간 진행하면서, 구축하자. 그냥 되겠지하고 만들다가 나중에가서 막히면 어디서 문제가 발생했는지, 찾기가 너무 힘들다.
3. API Gateway 의 콘솔에 Endpoint를 정확하게 http,https:// 부터 맨뒤의 port, url까지 정확하게 쓰자
4. VPC link에 NLB DNS를 정확하게 쓰기
5. EC2의 보안 그룹(VPC IP로 변경) 신경쓰자 NLB부터 통신이 안되서 뭐가 문제였는지 찾는데 한세월...
6. Target Group 포함 시킨 EC2 안에 서버가 정상적으로 가동되고있는지 확인하자[포트도 확인]
7. API gateway를 배포할때 Stage를 변경하였다면, 꼭 Custom Domain에 stage 매핑을 변경하도록하자두번째 포스팅하는건데 캡쳐하고 박스하고 이런것들, 또 내가 개인적으로 사용하는 IP, DNS, VPC 가용영역,, 혹시 몰라서 검정박스로 쳤는데, 너무 지저분한거같다..
다음 포스팅은 더 깔끔하고 두서있게 정리할 수 있도록 노력해야겠다.
!!수고하셨씁니다!!
