비 워크로드 서브넷을 위한 다중 계정 VPC 설계에서 라우팅 가능한 IP 공간 보존 - AWS 권장 가이드
요약사전 조건 및 제한 사항아키텍처도구모범 사례에픽관련 리소스추가 정보

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

비 워크로드 서브넷을 위한 다중 계정 VPC 설계에서 라우팅 가능한 IP 공간 보존

작성자: Adam Spicer(AWS)

코드 리포지토리: 라우팅이 불가능한 보조 CIDR 패턴

환경: 프로덕션

기술: 인프라; 관리 및 거버넌스 DevOps; 네트워킹

AWS 서비스: AWS Transit Gateway, Amazon VPC, Elastic Load Balancing(ELB)

요약

Amazon Web Services(AWS)는 Transit Gateway Attachment와 Gateway Load Balancer 엔드포인트(AWS Network Firewall 또는 타사 어플라이언스 지원) 모두에 대해 Virtual Private Cloud(VPC)에서 전용 서브넷 사용을 권장하는 모범 사례를 발표했습니다. 이러한 서브넷은 이러한 서비스를 위한 엘라스틱 네트워크 인터페이스를 포함하는 데 사용됩니다. AWS Transit Gateway와 Gateway Load Balancer를 모두 사용하는 경우 VPC의 각 가용 영역에 서브넷 2개가 생성됩니다. VPC의 설계 방식 때문에 이러한 추가 서브넷은 /28 마스크보다 작을 수 없으며 라우팅 가능한 워크로드에 사용할 수 있는 귀중한 라우팅 가능한 IP 공간을 차지할 수 있습니다. 이 패턴은 이러한 전용 서브넷에 대해 라우팅이 불가능한 보조 Classless Inter-Domain Routing(CIDR) 범위를 사용하여 라우팅 가능한 IP 공간을 보존하는 방법을 보여줍니다.

사전 조건 및 제한 사항

사전 조건

아키텍처

대상 아키텍처·

이 패턴에는 두 개의 참조 아키텍처가 포함됩니다. 한 아키텍처에는 Transit Gateway(TGW) 연결 및 Gateway Load Balancer 엔드포인트(GWLBe)를 위한 서브넷이 있고, 다른 아키텍쳐에는 TGW 연결 전용 서브넷이 있습니다.

아키텍처 1 ‒ 어플라이언스에 대한 수신 라우팅을 지원하는 TGW 연결 VPC

다음 다이어그램은 두 개의 가용 영역에 걸친 VPC의 참조 아키텍처를 나타냅니다. 인그레스 시 VPC는 인그레스 라우팅 패턴을 사용하여 퍼블릭 서브넷으로 향하는 트래픽을 방화벽 검사를 위해 어플라이언스로 전달합니다. bump-in-the-wire TGW 연결은 프라이빗 서브넷에서 별도의 VPC로의 송신을 지원합니다.

이 패턴은 TGW 연결 서브넷과 GWlBe 서브넷에 대해 라우팅할 수 없는 CIDR 범위를 사용합니다. TGW 라우팅 테이블에서 이 라우팅 불가능한 CIDR은 보다 구체적인 일련의 경로를 사용하여 블랙홀 (정적) 경로로 구성됩니다. 경로가 TGW 라우팅 테이블로 전파되는 경우 이러한 보다 구체적인 블랙홀 경로가 적용됩니다.

이 예시에서는 /23 라우팅 가능한 CIDR이 분할되어 라우팅 가능한 서브넷에 완전히 할당됩니다.

어플라이언스로의 인그레스 라우팅이 있는 TGW 연결 VPC

아키텍처 2 - TGW 연결 VPC

다음 다이어그램은 두 개의 가용 영역에 걸친 VPC의 또 다른 참조 아키텍처를 나타냅니다. TGW 연결은 프라이빗 서브넷에서 별도의 VPC로의 아웃바운드 트래픽(송신)을 지원합니다. TGW 연결 서브넷에만 라우팅할 수 없는 CIDR 범위를 사용합니다. TGW 라우팅 테이블에서 이 라우팅 불가능한 CIDR은 보다 구체적인 일련의 경로를 사용하여 블랙홀 경로로 구성됩니다. 경로가 TGW 라우팅 테이블로 전파되는 경우 이러한 보다 구체적인 블랙홀 경로가 적용됩니다.

이 예시에서는 /23 라우팅 가능한 CIDR이 분할되어 라우팅 가능한 서브넷에 완전히 할당됩니다.

VPC는 프라이빗 서브넷에서 별도의 VPC로의 송신을 위해 TGW가 연결된 2개의 가용 영역에 걸쳐 있습니다.

도구

AWS 서비스 및 리소스

  • Amazon Virtual Private Cloud(VPC)를 이용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 사용자의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사하며 AWS의 확장 가능한 인프라를 사용한다는 이점이 있습니다. 이 패턴에서 VPC 보조 CIDR은 워크로드 CIDR에서 라우팅 가능한 IP 공간을 보존하는 데 사용됩니다.

  • 인터넷 게이트웨이 수신 라우팅(엣지 연결)을 라우팅이 불가능한 전용 서브넷의 Gateway Load Balancer 엔드포인트와 함께 사용할 수 있습니다.

  • AWS Transit Gateway는 VPC와 온프레미스 네트워크를 연결하는 중앙 허브입니다. 이 패턴에서 VPC는 전송 게이트웨이에 중앙에서 연결되고 Transit Gateway Attachment는 라우팅이 불가능한 전용 서브넷에 있습니다.

  • Gateway Load Balancer를 사용하면 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 조정 및 관리할 수 있습니다. 게이트웨이는 모든 트래픽의 단일 출입 지점 역할을 합니다. 이 패턴에서 Gateway Load Balancer의 엔드포인트는 라우팅이 불가능한 전용 서브넷에서 사용할 수 있습니다.

  • AWS Network Firewall은 AWS Cloud를 위한 상태 저장형, 관리형 네트워크 방화벽이자, 침입 탐지 및 방지 서비스입니다. 이 패턴에서 방화벽의 엔드포인트는 라우팅이 불가능한 전용 서브넷에서 사용할 수 있습니다.

코드 리포지토리

이 패턴에 대한 런북과 AWS CloudFormation 템플릿은 GitHub 라우팅이 불가능한 보조 CIDR 패턴 리포지토리에서 제공됩니다. 샘플 파일을 사용하여 사용자 환경에 작업실을 설정할 수 있습니다.

모범 사례

AWS Transit Gateway

  • 각 Transit Gateway VPC 첨부 파일에 대해 별도의 서브넷을 사용합니다.

  • 라우팅이 불가능한 보조 CIDR 범위의 /28 서브넷을 Transit Gateway Attachment 서브넷에 할당합니다.

  • 각 전송 게이트웨이 라우팅 테이블에 라우팅이 불가능한 CIDR 범위에 대한 보다 구체적인 정적 경로를 블랙홀로 추가합니다.

Gateway Load Balancer 및 수신 라우팅

  • 수신 라우팅을 사용하여 인터넷에서 Gateway Load Balancer 엔드포인트로 트래픽을 전달합니다.

  • 각 Gateway Load Balancer 엔드포인트에 대해 별도의 서브넷을 사용합니다.

  • Gateway Load Balancer 엔드포인트 서브넷에 라우팅할 수 없는 보조 CIDR 범위에서 /28 서브넷을 할당합니다.

에픽

작업설명필요한 기술

라우팅할 수 없는 CIDR 범위를 결정합니다.

Transit Gateway Attachment 서브넷 및 (선택 사항) 모든 Gateway Load Balancer 또는 Network Firewall 엔드포인트 서브넷에 사용할 라우팅 불가능한 CIDR 범위를 결정합니다. 이 CIDR 범위는 VPC의 보조 CIDR로 사용됩니다. VPC의 기본 CIDR 범위 또는 대규모 네트워크에서 라우팅할 수 없어야 합니다.

클라우드 아키텍트

VPC의 라우팅 가능한 CIDR 범위를 결정합니다.

VPC에 사용할 라우팅 가능한 CIDR 범위 세트를 결정합니다. 이 CIDR 범위는 VPC의 기본 CIDR로 사용됩니다.

클라우드 아키텍트

VPC를 생성합니다.

VPC를 생성하고 전송 게이트웨이에 연결합니다. 각 VPC에는 이전 두 단계에서 결정한 범위를 바탕으로 라우팅할 수 있는 기본 CIDR 범위와 라우팅할 수 없는 보조 CIDR 범위가 있어야 합니다.

클라우드 아키텍트
작업설명필요한 기술

라우팅이 불가능한 보다 구체적인 CIDR을 블랙홀로 생성합니다.

각 전송 게이트웨이 라우팅 테이블에는 라우팅할 수 없는 CIDR에 대해 생성된 일련의 블랙홀 경로가 있어야 합니다. 이는 보조 VPC CIDR의 모든 트래픽이 라우팅되지 않고 대규모 네트워크로 누출되지 않도록 구성되어 있습니다. 이러한 경로는 VPC에서 보조 CIDR로 설정된 라우팅 불가능한 CIDR보다 더 구체적이어야 합니다. 예를 들어, 라우팅이 불가능한 보조 CIDR이 100.64.0.0/26인 경우 전송 게이트웨이 라우팅 테이블의 블랙홀 경로는 100.64.0.0/27 및 100.64.0.32/27이어야 합니다.

클라우드 아키텍트

관련 리소스

추가 정보

라우팅이 불가능한 보조 CIDR 범위는 대규모 IP 주소 집합이 필요한 대규모 컨테이너 배포를 작업할 때에도 유용할 수 있습니다. 프라이빗 NAT 게이트웨이와 함께 이 패턴을 사용하여 라우팅 불가능한 서브넷을 사용하여 컨테이너 배포를 호스팅할 수 있습니다. 자세한 내용은 블로그 게시물 How to solve Private IP exhaustion with Private NAT Solution을 참조하세요.