클라우드 개발자 앙몬드

인프라를 담당하시는 AWS Cloud Architect 분에게서 들어왔던 요청이 있었습니다.

EC2의 네트워크 Outbound 정책에 대하여, 나가는 대역을 애니오픈 0.0.0.0/0 에서 제한을 두자는 말이었죠.

사실 이에 대해서는 여러가지 고민해볼 필요가 있습니다.

EC2에서 실제 사용하는 서비스들에 대하여 VPC 엔드포인트를 모두 파악 / 구축해 아웃바운드를 둘 것인가.

혹은 AWS 에서 각 국가별로 사용하는 전체 AZ에 대한 Public IP를 찾아내 제어할 것인가.

* VPC 엔드포인트를 이용해 막아볼까?

  (1) 일반적으로, 프로젝트 초기 설계부터 빡세게 이를 알았다면 위 요건에 대한 문제는 쉽게 풀립니다.

  (2) VPC 엔드포인트는 외부망을 타지 않고, 나의 VPC 사설망에서 통신할 수 있게, 엔드포인트를 제공해주는 서비스입니다.

  (3) VPC EP 게이트웨이 (S3 & DynamoDB) / EP 엔드포인트 2가지로 나뉩니다.

  (4) 따라서, 프라이빗 엔드포인트가 생성될 시, 혹은 Public 게이트웨이 엔드포인트가 생성될 시, 이에 대하여 아웃바운드를 제어하면 만사 OK죠.

  (5) AWS 백서 참조 : docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-endpoints.html

이슈는 지금 구축 단계가 아니라, 현재 운영중인 엔터프라이즈 어플리케이션들에 대해서 이를 어떻게 네트워크를 틀어 막을 것인가 입니다.

아무리 처음부터 히스토리를 알고 있다고 하여도, 각 서버에서 무엇으로 통신하는지를 정확히 100% 파악해 틀어막을 수는 없습니다. 그러기엔 너무 위험부담도 크고, 또한 네트워크 블록킹 시 중요한 전문이나 오픈 API, Batch 작업이 돌아가지 않을 경우, 이에 대한 책임을 감당할 순 없을 겁니다.

그래서 생각한 나 (클라우드 개발자 앙몬드) 의 생각.

"어차피 물리적으로 아마존의 데이터센터가 한국에 위치해있다면, 그들이 사용하는 Public IP 또한 대역이 존재할 것 아닌가?"

"이를 통쨰로 파악하여 틀어막아보자."

하지만 한계도 있었죠. AWS의 Public IP들은 고정된 것이 아니라, 도약을 하기 때문에, 파악한 Public IP가 영원할 것이란 보장은 없었습니다.

흠.. 정답이 없을까.. 진짜 VPC 엔드포인트를 모두 위험을 감수하고서 SG 작업을 해야할까?

하지만 운좋게 2019년. AWS에서 멋진 기능을 제공해주기 시작했죠!

바로, AWS IP 대역 변경에 대해서, 이를 알려주는 서비스입니다.

aws.amazon.com/ko/blogs/korea/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/

잠깐 요약을 하면, 특정 SNS 토픽에 대하여 구독 (Subscription) 을 생성하면, 그 메서드로 알림/트리거가 간다는 내용입니다.

보시면, SNS 토픽 ARN이 아예 고정되어 있습니다.

주의 사항도 있어요!

이 SNS는 us-east-1 (North Virginia) 에서 생성을 해야합니다. 저 ARN을 리전과 내 AWS 어카운트 12자리로 바꾸어도, 인식하지 않습니다.

(다시 말하면 뭐다? 저 806199016981 은 AWS의 고유 계정이다.. 라는 건데 나한텐 전혀 쓰잘데기 없는 거..)

SNS 서브스크립션 없이도, 오픈 API를 제공해줍니다. 하기와 같으며, 지금 한번 호출해 result json 파일을 뜯어보았습니다.

ip-ranges.amazonaws.com/ip-ranges.json

하지만, 앙몬드는 저걸 일일이 계속 호출하기 싫으니, SNS 구독을 받아 람다를 호출하는 형태의 Fan-out 람다를 만들어 보기로하였습니다.

(1) SNS 구독을 위 AWS IP 대역 변경에 대하여, 서울리전의 람다를 설정시킨다.

(2) IP대역 변경이 있을 시, 람다가 이를 실행한다. (SNS를 이용한 Fan-Out 패턴 살짝 변형)

(3) 람다는 SNS 이벤트에서, 대역 변경에 대한 정보 중, 서울리전의 Public IP 대역을 EC2 SG 아웃바운드 룰에 설정한다.

오늘은 앙몬드 또한, 이에 대하여 1번과 2번을 해보았지, 아직 3번에 대한 것을 해보진 않았습니다.

사실 그래봤자, 런타임에 따른 람다 SDK를 사용하는 것일 뿐이기에 큰 이슈는 없을 것으로 생각되네요.

(오히려 저 SNS 토픽 찾는게 더 힘들었음...)

만들게 되면, 3번에 대한 코드는 같이 포스팅하는 것으로 약속하죠 :)

* Fan-Out 에 대한 AWS 화이트페이퍼 레퍼런스 : aws.amazon.com/ko/getting-started/hands-on/send-fanout-event-notifications/

* 아마존이 설명하는 팬아웃은 SNS & SQS 조합이지만, 람다 조합도 팬아웃 패턴으로 인식해도 문제가 없다고 개인적인 판단이네요.. 근데 왜 SQS만 넣었는지는 조금 의문이긴 합니다..

[정리]

1. SNS -> SQS 를 이용한 조합을 AWS 팬아웃 아키텍처라고 합니다.

2. AWS AZ, 데이터센터 또한 명백히 사용하는 Public IP 대역이 있습니다.

3. 2번에 해당하는 Public IP는 고정이 아니지만, 바뀔 경우, SNS 혹은 API를 통해 인지할 수 있습니다.