NLB + ALB + EC2 그리고 WAF 적용까지

---

고정IP덕에 NLB를 굳이 써야하고.. WAF 적용을 하고싶은? 곳에 유용할 것 같다.

test는 일단은 NLB에 ALB를 넣는 것과 걱정인 IP변동에 대해서..

그리고 Lambda를 이용하여 바뀌는 IP에 대해 NLB 대상그룹을 자동으로 변경해준다.

 

사전 요구 사항

•  내부 또는 외부(인터넷) NLB를 준비한다.

•  내부 ALB를 준비합니다. 여기에서 HTTPS 처리 또는 라우팅처리를 할 수 있다. 여기에서 서버가 트래픽을 받아서 처리하게 된다.

•  내부 ALB와 NLB는 같은 가용영역에 있어야 한다.

•  IP 주소 기반 대상그룹을 NLB에 만든다. 대상그룹의 프로토콜은 TCP. AWS Lamdba 함수가 이 대상그룹에 ALB의 주소를 등록시킴

•  ALB의 IP주소 등의 정보가 담길 Amazon S3 버킷 준비

• AWS Lambda가 필요한 리소스들을 만들 수 있는 IAM 정책을 가지고 있는 IAM 역할을 준비

 

 

아키텍처는 아래와 같다.

 

 

---

NLB + ALB + EC2

---

 

test를 위해 NLB와 ALB 그리고 EC2(WEB SVR)를 생성해 놓는다.

 

 

 

 

 

 

 

 

먼저 ALB 대상그룹에 EC2(WEB SVR) 넣기

 

NLB Target Group에 ALB 넣기

NLB 대상 그룹은 ALB를 넣기위해 IP기반 Target Group으로 한다.

 

Targets은 내부IP로 할당 해야하므로 NLB가 아닌, 생성한 ALB에 할당된 내부IP를 할당해줘봤다.

잠시 후 healthy 상태로 변경 된다.

현재 10.0.2.19 (ap-northeast-2c)에 EC2(WEB SVR)이 존재한다.

 

LoadBalancer 특성상 많은 부하로 인해 Scale in/out이 되면 외부 IP뿐만아니라 내부 IP도 변경된다.

내부 IP도 실제로 바뀌는지 테스트해봤다.

 

LB부하를 주기위해 만들어 놓은 EC2(WEB SVR)에 접속 후 Apache Bench를 설치

yum install httpd-tools

 

ab -c 1000 -n 1000 -t 20 "주소"

1000명이 1000번 동시에 접속하여 부하를 줄 수 있게해준다.

열심히 열심히 부하를 줘서 LB의 IP가 바뀌는지 본다.

 

 

원래는 a,c 영역 2개의 IP가 존재햇는데 부하를 주다보니 LB의 노드수가 늘어났다.

NLB에 준 IP는 10.0.2.19 / 10.0.1.148

근데 문제는 쉽게 줄어들지 않아서 확인하기 좀 오래걸린다.

차라리 ALB subnet을 바꾸는 형식으로 바뀌게 했으면 나앗을거같다

 

하루 이틀 다른일 하느라 이제 봤는데 노드 수가 2개로 줄어있다.

기존에 2개였는데 그때 동일한 2개가 남아있다.. 우연인지는 모르겠다

 

ALB의 IP주소가 바뀌기 때문에 NLB의 대상그룹에서는 바꿔줘야한다.

이를 자동화 시키기 위해서 Lambda를 이용하여 ALB를 Check 후 NLB 대상그룹에 추가 시켜주는 함수 실행시킨다.

 

단계별 Lambda 함수 작업

1. ALB에서 쓰이는 IP 주소들을 DNS 쿼리로 알아온 뒤 S3 버킷에 결과(NEW IP LIST)를 업로드

2. describe-target-health API 액션으로 현재 NLB에 등록된 IP 주소들의 리스트(REGISTERED LIST)를 가져옴.

3. 이전의 IP 주소 리스트(OLD LIST)를 다운로드함. 만약에 이번이 첫 Lambda 함수의 실행이라면 IP 주소 리스트는 비어있음.

4. NEW LIST를 Lambda 함수의 CloudWatch Logs 로그스트림에 출력함. 이는 ALB에서 쓰이던 IP 주소들을 찾는데 쓰일 수 있음.

5. 첫 실행에서 만들어졌던 내부 ALB IP주소들의 갯수를 추적하는 CloudWatch 지표를 업데이트 함. 이 지표는 얼마나 많은 IP주소들이 그 동안 변경되었는지 보여줌. CW_METRIC_FLAG_IP_COUNT를 ‘false’로 설정하여 비활성화 시킬 수 있음. 여기에 ALB의 IP주소가 20개에서 24개, 그 다음에는 28개로 변하는 것을 보여주는 CloudWatch 지표의 예제가 있음.

6. OLD LIST나 REGISTERED LIST에 있는 것을 제외한 NEW LIST에 있는 IP 주소들을 NLB에 등록함.

7. OLD LIST 중 NEW LIST에 없는 IP주소들은 등록해지함.

 

• NLB 대상그룹에 ALB를 넣을 수 있는지를 먼저 test 하다보니 외부 ALB를 만들었었다.Cloudformation으로 위 아키텍처를 구성했는데 S3에 ALB IP list가 공인IP만 저장되어있다..사전 요구 사항은 내부 ALB로 되어있긴하다.
• S3와 ALB, Formation 모두 삭제 후 다시 진행
• 

내부 ALB로 다시 생성했다..

 

CloudFormation 진행

 

제공된 CloudFormation의 파라미터 값을 맞게 넣어준다.

주의 : ARN은 NLB ARN이 아닌 NLB의 Target Group에 대한 ARN을 넣어준다.

미리 준비한 리소스는 NLB, 내부ALB, EC2(WEB), S3이다.

 

입력한 값을 확인한다.

 

Cloudformation에서 리소스들을 사용할 수 있음을 Check 해주고 스택 생성

 

NLB 대상그룹에는 이전에 외부 ALB의 내부 IP를 넣었었다. 외부 ALB를 삭제하고 난 후 unhealthy 상태인데 Cloudformation에서 생성된 Lambda가 과연 내부ALB를 check 하여 ip list를 s3에 저장 후 NLB 대상그룹을 바로 잡아주는지 기다려보겠다..

 

현재 생성된 ALB의 IP는 이렇다.

 

일단 S3에는 두가지로 저장된다. (1분에 한번씩 저장)

• 활성화 된 ALB IP list

  

• 등록취소 된 ALB IP list?
  
  
  
  
•  
•  
•  

NLB Target Group 변경 확인

Lambda가 NLB Target Group 기존것들을 drowing 시키고 ALB에 등록된 IP로 변경했다.

주기적으로 Lambda가 IP Check를해서 ALB의 IP를 두개 동시에 바꿔도 음.. web서버 끊김없이 잘 접속된다.

 

내부 ALB에 WAF 적용

 

WAF는 2가지가있다.

• WAF v2 (Version 2)

• Classic WAF

WAF와 WAFv2 차이점

WAF Classic 에서는 하나의 WebACL 에 적용 가능한 Rule 의 갯수가 10개로 제한이 되어 있었다. WAFv2 에서는 Rule 개수의 제한이 사라지고 WAF Capacity Unit(WCU)이라는 개념이 생겼다. WCU을 기준으로 WebACL에 적용가능한 최대 Rule 을 계산한다. ACL 당 1,500 WCU Soft Limit가 있다.

WAF Classic에서는 AWS 보안 파트너사에서 제공하는 Managed rule 만 사용이 가능했다. WAFv2에서는 파트너사에서 제공하는 Managed Rule 이외에 AWS에서 제공하는 Managed Rule 의 사용이 가능하다. AWS Managed Rule은 따로 추가 요금이 발생하지 않는다. Managed Rule마다 다른 WCU를 가지고 있어 추가 rule을 설정할 때는 WCU를 확인해야한다.

 

두가지는 둘다 WAF 서비스이지만 조금 다르다. Classic은 swich to AWS WAF Classic을 눌러 서비스를 구성할 수 있다.

 

현재 test중인 NLB+ALB 구조에는 WAFv2를 적용할 것이다.

 

WAF 이름과 WAF를 적용할 리소스를 선택

 

WAF를 적용할 리소스를 adding 시켜준다.

 

WAF 적용이 잘 되는지 확인하기 위한 IP sets를 만들어준다.

해당 IP를 차단을 잘 시켜주는지 보기위함

 

Add my own rules and rule groups를 눌러서 방금 만든 IP sets를 추가해주었다.

Add managed rule groups은 관리형 rule을 선택할 수 있다.

 

 

IP를 Source/heder 등으로 해봐도 결국 WAF는 NLB의 IP만 받는다.

NLB IP Type 이므로 내부 IP만 찍히기에 Client의 IP를 Deny 시키는 방법은.. ALB의 SG을 활용하여 Allow 해야할 것으로 보인다.

 

 

 

 

 

 

 

 

 

 

 

Uploaded by Notion2Tistory v1.1.0