[reinvent 2024] PrivateLink와 VPC Lattice를 통한 VPC 간 리소스 접근 단순화

Summary

AWS PrivateLink와 Amazon VPC Lattice의 새로운 혁신이 리소스 엔드포인트와 서비스 네트워크를 사용하여 네트워크 경계를 넘어 데이터베이스와 클러스터 같은 VPC 리소스에 대한 프라이빗 액세스를 지원하는 방법을 알아보세요. 이 세션에서는 PrivateLink와 VPC Lattice를 사용하여 대규모 서비스 및 데이터 리소스에 대한 프라이빗 연결을 단순화하는 새로운 기능들을 알아봅니다. VPC 간, 계정 경계 간, 그리고 온프레미스 환경에서 이전에는 클라우드에서 불가능했던 리소스 공유와 접근을 활성화하는 방법을 발견하세요. 또한 대규모 기업 네트워크, ISV 파트너와의 연결, AWS 서비스 등을 포함한 사용 사례들을 함께 살펴봅니다.


리인벤트 2024 테크 블로그의 더 많은 글이 보고 싶다면?

Tech Blog

AWS re:Invent 2024 Tech Blog written by MegazoneCloud

Overview

  • Title: Simplify cross-VPC resource access with PrivateLink and VPC Lattice
  • Date: 2024년 12월 3일(화)
  • Venue: Mandalay Bay | Level 3 South | South Seas A
  • Speaker:
  • Ashish Kumar(Senior Product Manager Tech, AWS)
  • Erik Fuller(Sr Principal Engineer, AWS)
  • Jamie Wenzel(Principal Solutions Architect, Amazon Web Services)
  • Industry: Financial Services

들어가며

이번 칼럼에서는 VPC 연결관련 기술을 주제로 한 세션을 듣고, 여러분께 신규 기술 및 업데이트 된 정보를 공유드리도록 하겠습니다. 이번 세션에서 주목할 내용은 VPC Lattice 및 PrivateLink 입니다.

2023년 11월달에 출시한 VPC Lattice 에 대한 소개를 고객의 요청이 들어온 것과 같은 상황을 만들어 세션발표를 이어갔습니다. 네트워크 인프라를 담당하던 저로서도 흥미를 가질만한 세션이었습니다. VPC 연결인 만큼 발표내용을 어려웠지만 이해한 선에서 최대한 설명드리도록 하겠습니다.

먼저 우리가 익히 알고 있는 Transit Gateway와 VPC Peering을 비교하였습니다.

Transit Gateway는 모든 VPC를 연결하는 중앙 허브로, 최대 5000개의 VPC까지 확장 가능합니다. Direct Connect나 VPN을 중앙집중화하여 직접 연결할 수도 있습니다. 하지만, 단점도 있습니다. 대규모로 확장할 경우 라우팅이 대부분 정적이 될 것입니다. 라우팅이 정적이기 때문에, 서비스를 관리할 때 이를 고려해야 합니다.

또한 워크로드 설정 방식에 따라 비용이 많이 들 수 있습니다. Transit Gateway를 통해 트래픽을 계속 주고받으면 워크로드 데이터 요금이 발생합니다. 따라서 트래픽 흐름을 잘 알아야 합니다.

VPC Peering은 TGW에 비해 매우 빠릅니다. 한 라우트에서 다른 라우트로 매우 단순하게 연결되며 리전 간 연결도 가능합니다. Transit Gateway도 리전 간 연결이 가능하지만 추가 설정이 필요하죠. 대신 VPC Peering은 활성 연결이 최대 125개로 제한됩니다. 대규모로 확장할 경우 라우팅이 복잡해질 수 있습니다. 모든 제어가 VPC에서 이루어지기 때문입니다.

위 인프라에서 VPC1과 VPC2 사이에 Transit Gateway를 사용하고, 2와 3 사이에는 Peering을 사용할 수 있습니다. 1은 2에 있는 필요한 시스템과 서비스만 통신하면 되므로 3과 직접 통신할 필요가 없습니다.

위 구성을 예시로 하여 이제부턴 고객사의 추가요구에 따른 설계변화를 설명하기 시작합니다.

모든 것이 잘 작동하고 있는데, 상사가 와서 새로운 요구사항을 말합니다. AWS를 통해 파트너와 연결해야 하고, 그들이 우리 서비스를 사용하길 원한다고 합니다. 많은 비용을 들이지 않고 복잡한 인프라를 구축하지 않으면서 안전한 방식으로 연결해야 한다는 조건도 이야기 합니다.

너무나도 고객사 같은 마인드로 예시를 들어 놀라는 것도 잠시 아래와 같은 방식으로 연결을 제안했습니다.

아키텍처를 살펴보면, VPC4가 있고 4는 1과 통신해야 합니다. 1은 Layer 4로 2와 통신하고, 2는 Layer 4로 3과 통신하며, 이제 1은 Layer 4로 4와 통신해야 합니다. PrivateLink를 사용하여 4와 통신하도록 합니다. PrivateLink는 TCP와 UDP 모두 지원하여 좋습니다. 또한 멀티 계정을 지원합니다. 서로 다른 사업부가 있거나 파트너가 있는 경우에도 연결할 수 있습니다. 하이브리드 연결도 가능합니다.

주된 이유는 엔드포인트가 로컬 서브넷에서 IP 주소를 가져오고, 이것이 Direct Connect나 VPN을 통해 갈 수 있기 때문입니다. 그리고 물론 보안적으로도 한 방향으로만 갈 수 있기에 좋습니다.

여기에 NLB를 추가합니다. PrivateLink가 있고 단방향으로 실행되며, NLB를 통과하여 리소스에 접근하고 필요한 것을 가져옵니다. 

힘들게 구성이 완료되었지만 이어서 또 다른 요청이 들어옵니다.

“우리는 현대화가 필요해요! 사용하던 EC2 인스턴스들을 모두 변경하고 새로운 것을 도입할 겁니다. Lambda와 컨테이너로 가려고 합니다. 클라우드의 잠재력을 최대한 활용할거에요!”

앞이 막막했지만 발표자분은 쿨하게 구성을 수정하기 시작합니다.

기존 EC2를 제거하고 Lambda, 컨테이너 Auto Scaling 그룹으로 교체했습니다. 생각보다 요청에 비해 많은 변화는 주지 않았네요.

하지만 욕심이 많은 고객사는 또 다시 요구하기 시작하는데…

“백엔드를 분할하고 각 VPC에 새로운 연결을 만들어야 합니다. 새로운 VPC를 추가하고 서비스 네트워크를 고려하고 있으니 추천사항을 제시해주세요.”

VPC 5를 생성했지만 어떤 연결방식을 사용해야 할지 고민됩니다. 이때 VPC Lattice를 언급하며 VPC Lattice를 선택한 이유를 설명하기 시작합니다.

  1. 중앙 집중화된 네트워크 관리
    • 여러 VPC에 분산된 서비스들을 하나의 중앙 지점에서 관리할 수 있습니다.
    • VPC 피어링이나 Transit Gateway와 같은 복잡한 네트워크 구성을 줄일 수 있습니다.

  2. 서비스 디스커버리 단순화
    • 각 VPC의 서비스들이 VPC Lattice를 통해 서로를 쉽게 찾고 통신할 수 있습니다.
    • DNS 기반의 서비스 디스커버리를 자동으로 제공합니다.

  3. 트래픽 관리 용이성
    • 서비스 간의 트래픽을 중앙에서 제어하고 모니터링할 수 있습니다.
    • 로드 밸런싱, 라우팅 규칙 등을 쉽게 설정할 수 있습니다.

  4. 보안 강화
    • 중앙화된 보안 정책 적용이 가능합니다.
    • 서비스 간 통신에 대한 세밀한 접근 제어가 가능합니다.

여러 VPC들이 VPC Lattice를 통해 연결되어 있어, 복잡한 네트워크 구성 없이도 효율적인 서비스 간 통신이 가능하다는 것을 설명했습니다.

결론

오늘 소개해 드린 VPC Lattice는 서비스 네트워크를 위한 강력한 솔루션을 제공하는 것을 이번 발표를 통해 알게 되었습니다. 새로운 VPC 연결 기술이 늘어날수록 이를 통해 기업은 보다 안전하고 효율적인 서비스 간 통신을 구현할 수 있을 것이며 그만큼 AWS에 대한 의존성도 높아져 고객유치에 큰 역할을 할 수 있을 것으로 기대됩니다. 이상으로 세션리포트를 마치겠습니다.

감사합니다.
글 │메가존클라우드, MSC, Finance Team, 안영건

게시물 주소가 복사되었습니다.