다중 VPC에서 중앙 AWS 서비스 엔드포인트에 비공개로 액세스 - 권장 가이드

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

다중 VPC에서 중앙 AWS 서비스 엔드포인트에 비공개로 액세스

작성자: 마틴 귄트너(AWS)와 사무엘 고든(AWS)

코드 리포지토리: VPC 엔드포인트 공유

환경: 프로덕션

기술: 네트워킹, 인프라

AWS 서비스: AWS RAM, 아마존 Route 53, 아마존 SNS, AWS Transit Gateway, 아마존 VPC

요약

사용자 환경의 보안 및 규정 준수 요구 사항에는 Amazon Web Services(AWS) 서비스 또는 엔드포인트로 향하는 트래픽이 퍼블릭 인터넷을 통과해서는 안 된다고 명시되어 있을 수도 있습니다. 이 패턴은 중앙 허브 VPC가 여러 분산 스포크 VPC에 연결되는 hub-and-spoke토폴로지에 맞게 설계된 솔루션입니다. 이 솔루션에서는 PrivateLink AWS를 사용하여 허브 계정에서 AWS 서비스에 대한 인터페이스 VPC 엔드포인트를 생성합니다. 그런 다음 전송 게이트웨이와 분산 도메인 이름 시스템(DNS) 규칙을 사용하여 연결된 VPC에 걸쳐 엔드포인트의 프라이빗 IP 주소에 대한 요청을 해결합니다.

이 패턴은 연결된 VPC의 리소스에서 DNS 쿼리를 해결하기 위해 AWS Transit Gateway, 인바운드 Amazon Route 53 Resolver 엔드포인트, 공유된 Route 53 전달 규칙을 사용하는 방법을 설명합니다. 허브 계정에서 엔드포인트, 전송 게이트웨이, Resolver 및 전달 규칙을 생성합니다. 그런 다음 AWS Resource Access Manager(AWS RAM)를 사용하여 전송 게이트웨이 및 전달 규칙을 스포크 VPC와 공유합니다. 제공된 AWS CloudFormation 템플릿은 허브 VPC 및 스포크 VPC에서 리소스를 배포하고 구성하는 데 도움이 됩니다.

사전 조건 및 제한 사항

사전 조건 

  • AWS Organizations의 동일한 조직에서 관리되는 허브 계정과 하나 이상의 스포크 계정입니다. 자세한 내용은 조직 생성 및 관리를 참조하세요.

  • AWS Resource Access Manager(AWS RAM)는 AWS Organizations에서 신뢰할 수 있는 서비스로 구성되어 있습니다. 자세한 내용은 기타 AWS 서비스와 AWS Organizations 사용을 참조하세요.

  • 허브 및 스포크 VPC에서 DNS 확인을 활성화해야 합니다. 자세한 내용은 VPC의 DNS 속성(Amazon Virtual Private Cloud 설명서)를 참조하세요.

제한 사항

  • 이 패턴은 동일한 AWS 리전의 허브 계정과 스포크 계정을 연결합니다. 다중 리전 배포의 경우 각 리전에 대해 이 패턴을 반복해야 합니다.

  • AWS 서비스는 인터페이스 VPC PrivateLink 엔드포인트로 통합되어야 합니다. 전체 목록은 AWS와 통합되는 AWS 서비스 PrivateLink (PrivateLink 설명서) 를 참조하십시오.

  • 가용 영역 친화성은 보장되지 않습니다. 예를 들어 가용 영역 A의 쿼리는 가용 영역 B의 IP 주소로 응답할 수 있습니다.

  • VPC 엔드포인트와 연결된 Elastic Network 인터페이스의 쿼리는 초당 10,000개로 제한됩니다.

아키텍처

대상 기술 스택

  • 허브 AWS 계정의 허브 VPC

  • 스포크 AWS 계정에 있는 하나 이상의 스포크 VPC

  • 허브 계정에 있는 하나 이상의 인터페이스 VPC 엔드포인트

  • 허브 계정의 인바운드 및 아웃바운드 Route 53 Resolver

  • 허브 계정에 배포되고 스포크 계정과 공유되는 Route 53 Resolver 전달 규칙

  • 허브 계정에 배포되고 스포크 계정과 공유되는 전송 게이트웨이

  • 허브와 스포크 VPC를 연결하는 AWS Transit Gateway

대상 아키텍처

다음 이미지는 이 솔루션의 샘플 아키텍처를 보여줍니다. 이 아키텍처에서 허브 계정의 Route 53 Resolver 전달 규칙은 다른 아키텍처 구성 요소와 다음과 같은 관계를 갖습니다.

  1. 전달 규칙은 AWS RAM을 사용하여 스포크 VPC와 공유됩니다.

  2. 전달 규칙은 허브 VPC의 아웃바운드 Resolver와 연결됩니다.

  3. 전달 규칙은 허브 VPC의 인바운드 Resolver를 대상으로 합니다.

스포크 및 허브 계정의 리소스를 보여주는 아키텍처 다이어그램.

다음 이미지는 샘플 아키텍처를 통한 트래픽 흐름을 보여줍니다.

  1. 스포크 VPC에 있는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 같은 리소스가 <service>.<region>.amazonaws.com으(로) DNS 요청을 보냅니다. 요청은 Amazon DNS Resolver에 의해 수신됩니다.

  2. 허브 계정에서 공유되고 스포크 VPC와 연결된 Route 53 전달 규칙이 요청을 가로챕니다.

  3. 허브 VPC에서 아웃바운드 Resolver는 전달 규칙을 사용하여 요청을 인바운드 Resolver로 전달합니다.

  4. 인바운드 Resolver는 허브 VPC Amazon DNS Resolver를 사용하여 VPC 엔드포인트의 프라이빗 IP 주소로 <service>.<region>.amazonaws.com의 IP 주소를 확인합니다. VPC 엔드포인트가 없는 경우 퍼블릭 IP 주소로 확인합니다.

스포크 VPC의 리소스에서 허브 VPC의 서비스 엔드포인트로의 트래픽 흐름입니다.

도구

AWS 도구 및 서비스

  • AWS는 AWS CloudFormation 리소스를 설정하고, 빠르고 일관되게 프로비저닝하고, AWS 계정 및 지역 전반의 수명 주기 전반에 걸쳐 리소스를 관리할 수 있도록 지원합니다.

  • Amazon Elastic Compute Cloud(Amazon EC2)는 AWS 클라우드에서 규모를 조정할 수 있는 컴퓨팅 용량을 제공합니다. 필요한 만큼 많은 가상 서버를 시작하고 빠르게 규모를 확장 또는 축소할 수 있습니다.

  • AWS Identity and Access Management(IAM)를 사용하면 AWS 리소스를 사용하도록 인증받고 권한이 부여된 사용자를 통제함으로써 AWS 리소스에 대한 액세스를 안전하게 관리할 수 있습니다.

  • AWS Resource Access Manager(AWS RAM)는 AWS 계정에 걸쳐 리소스를 안전하게 공유하여 운영 오버헤드를 줄이고 가시성과 감사 가능성을 제공하도록 도와줍니다.

  • Amazon Route 53는 가용성과 확장성이 뛰어난 DNS(도메인 이름 시스템) 웹 서비스입니다.

  • AWS Systems Manager는 AWS 클라우드에서 실행되는 애플리케이션과 인프라를 관리하는 데 도움이 됩니다. 애플리케이션 및 리소스 관리를 간소화하고, 운영 문제의 감지 및 해결 시간을 단축하며, AWS 리소스를 규모에 따라 안전하게 관리하는 데 도움이 됩니다.

  • AWS Transit Gateway는 VPC와 온프레미스 네트워크를 연결하는 중앙 허브입니다.

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

기타 도구 및 서비스

  • nslookup은 DNS 레코드를 쿼리하는 데 사용되는 명령줄 도구입니다. 이 패턴에서는 이 도구를 사용하여 솔루션을 테스트합니다.

코드 리포지토리

이 패턴의 코드는 vpc-endpoint-sharing리포지토리에서 GitHub 사용할 수 있습니다. 이 패턴은 두 개의 AWS CloudFormation 템플릿을 제공합니다.

  • 허브 계정에 다음 리소스를 배포하기 위한 템플릿:

    • rSecurityGroupEndpoints - VPC 엔드포인트에 대한 액세스를 제어하는 보안 그룹입니다.

    • rSecurityGroupResolvers - Route 53 Resolver에 대한 액세스를 제어하는 보안 그룹입니다.

    • rKMSEndpoint, rSSMMessagesEndpoint, rSSMEndpointrEC2MessagesEndpoint - 허브 계정의 인터페이스 VPC 엔드포인트 예제입니다. 사용 사례에 맞게 이러한 엔드포인트를 사용자 지정합니다.

    • rInboundResolver - 허브 Amazon DNS Resolver에 대한 DNS 쿼리를 확인하는 Route 53 Resolver입니다.

    • rOutboundResolver - 쿼리를 인바운드 Resolver로 전달하는 아웃바운드 Route 53 Resolver입니다.

    • rAWSApiResolverRule - 모든 스포크 VPC와 공유되는 Route 53 Resolver 전달 규칙입니다.

    • rRamShareAWSResolverRule - 스포크 VPC가 rAWSApiResolverRule 전달 규칙을 사용하도록 허용하는 AWS RAM 공유입니다.

    • *rVPC - 공유 서비스를 모델링하는 데 사용되는 허브 VPC입니다.

    • *rSubnet1 - 허브 리소스를 보관하는 데 사용되는 프라이빗 서브넷입니다.

    • *rRouteTable1 - 허브 VPC의 라우팅 테이블입니다.

    • *rRouteTableAssociation1 - 허브 VPC의 rRouteTable1 라우팅 테이블의 경우, 프라이빗 서브넷에 대한 연결입니다.

    • *rRouteSpoke - 허브 VPC에서 스포크 VPC로의 경로입니다.

    • *rTgw - 모든 스포크 VPC와 공유되는 전송 게이트웨이입니다.

    • *rTgwAttach - 허브 VPC가 트래픽을 rTgw 전송 게이트웨이로 라우팅할 수 있도록 하는 연결입니다.

    • *rTgwShare - 스포크 계정이 rTgw 전송 게이트웨이를 사용할 수 있도록 허용하는 AWS RAM 공유입니다.

  • 스포크 계정에 다음 리소스를 배포하기 위한 템플릿:

    • rAWSApiResolverRuleAssociation - 스포크 VPC가 허브 계정의 공유 전달 규칙을 사용할 수 있도록 하는 연결입니다.

    • *rVPC - 스포크 VPC입니다.

    • *rSubnet1, rSubnet2, rSubnet3 - 스포크 프라이빗 리소스를 수용하는 데 사용되는 각 가용 영역의 서브넷입니다.

    • *rTgwAttach - 스포크 VPC가 트래픽을 rTgw 전송 게이트웨이로 라우팅할 수 있도록 하는 연결입니다.

    • *rRouteTable1 - 스포크 VPC의 라우팅 테이블입니다.

    • *rRouteEndpoints - 스포크 VPC의 리소스에서 전송 게이트웨이까지의 경로입니다.

    • *rRouteTableAssociation1/2/3 - 스포크 VPC의 rRouteTable1 라우팅 테이블의 경우 프라이빗 서브넷에 대한 연결입니다.

    • *rInstanceRole - 솔루션을 테스트하는 데 사용되는 IAM 역할입니다.

    • *rInstancePolicy - 솔루션 테스트에 사용되는 IAM 정책입니다.

    • *rInstanceSg - 솔루션을 테스트하는 데 사용되는 보안 그룹입니다.

    • *rInstanceProfile - 솔루션을 테스트하는 데 사용되는 IAM 인스턴스 프로파일입니다.

    • *rInstance - AWS Systems Manager를 통해 액세스할 수 있도록 사전 구성된 EC2 인스턴스입니다. 이 인스턴스를 사용하여 솔루션을 테스트합니다.

* 이러한 리소스는 샘플 아키텍처를 지원하며 기존 랜딩 존에서 이 패턴을 구현할 때는 필요하지 않을 수 있습니다.

에픽

작업설명필요한 기술

코드 리포지토리를 복제합니다.

  1. 명령줄 인터페이스에서 작업 디렉터리를 샘플 파일을 저장하고자 하는 위치로 변경합니다.

  2. 다음 명령을 입력합니다.

    git clone https://github.com/aws-samples/vpc-endpoint-sharing.git
네트워크 관리자, 클라우드 아키텍트

템플릿을 수정합니다.

  1. 복제된 리포지토리에서 hub.ymlspoke.yml 파일을 엽니다.

  2. 이러한 템플릿으로 생성한 리소스를 검토하고 환경에 맞게 필요한 만큼 템플릿을 조정합니다. 전체 목록은 도구코드 리포지토리 섹션을 참조하세요. 계정에 이러한 리소스 중 일부가 이미 있는 경우 CloudFormation 템플릿에서 해당 리소스를 제거하세요. 자세한 내용은 템플릿 작업 (CloudFormation 문서) 을 참조하십시오.

  3. hub.ymlspoke.yml 파일을 저장하고 닫습니다.

네트워크 관리자, 클라우드 아키텍트
작업설명필요한 기술

허브 리소스를 배포합니다.

hub.yml 템플릿을 사용하여 스택을 생성합니다. CloudFormation 메시지가 표시되면 템플릿에 파라미터 값을 제공합니다. 자세한 내용은 스택 만들기 (문서) 를 참조하십시오. CloudFormation

클라우드 아키텍트, 네트워크 관리자

스포크 리소스를 배포합니다.

spoke.yml 템플릿을 사용하여 스택을 생성합니다. CloudFormation 메시지가 표시되면 템플릿에 파라미터 값을 제공합니다. 자세한 내용은 스택 만들기 (문서) 를 참조하십시오. CloudFormation

클라우드 아키텍트, 네트워크 관리자
작업설명필요한 기술

AWS 서비스에 대한 프라이빗 DNS 쿼리를 테스트합니다.

  1. AWS Systems Manager의 기능인 Session Manager를 사용하여 rInstance EC2 인스턴스에 연결합니다. 자세한 내용은 Session Manager를 사용하여 Linux 인스턴스에 연결(Amazon EC2 설명서)을 참조하세요.

  2. 허브 계정에 VPC 엔드포인트가 있는 AWS 서비스의 경우, nslookup을(를) 사용하여 인바운드 Route 53 Resolver의 프라이빗 IP 주소가 반환되는지 확인합니다.

    다음은 nslookup을(를) 사용하여 Amazon Systems Manager 엔드포인트에 도달하는 예입니다.

    nslookup ssm.<region>.amazonaws.com
  3. AWS Command Line Interface(AWS CLI)에 변경 사항이 서비스 기능에 영향을 미치지 않았는지 확인하는 데 도움이 되는 명령을 입력합니다. 명령 목록은 AWS CLI 명령 참조를 참조하세요.

    예를 들어, 다음 명령은 Amazon Systems Manager 문서 목록을 반환해야 합니다.

    aws ssm list-documents
네트워크 관리자

AWS 서비스에 대한 퍼블릭 DNS 쿼리를 테스트합니다.

  1. 허브 계정에 VPC 엔드포인트가 없는 AWS 서비스의 경우 nslookup을(를) 퍼블릭 IP 주소가 반환되는지 확인하는 데 사용합니다. 다음은 nslookup을(를) 사용하여 Amazon Simple Notification Service(Amazon SNS) 엔드포인트에 도달하는 예입니다.

    nslookup sns.<region>.amazonaws.com
  2. AWS CLI에서 변경 사항이 서비스 기능에 영향을 미치지 않았는지 확인하는 데 도움이 되는 명령을 입력합니다. 명령 목록은 AWS CLI 명령 참조를 참조하세요.

    예를 들어, 허브 계정에 Amazon SNS 주제가 있는 경우 다음 명령은 주제 목록을 반환해야 합니다.

    aws sns list-topics
네트워크 관리자

관련 리소스