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

온프레미스에서 운영하는 서비스 소비자

이 섹션에서는의 AWS 클라우드 SaaS 워크로드와 온프레미스 데이터 센터 간의 연결 옵션에 대해 설명합니다. 온프레미스 요구 사항이 있는 많은 소비자, 특히 엔터프라이즈 수준에서는 클라우드를 물리적 네트워크의 확장으로 보고 아키텍처에 이를 반영하려고 합니다. 즉, 논리적 터널을 통해 또는 프라이빗 물리적 연결을 통해 클라우드의 SaaS 제품에 대한 프라이빗 연결을 의미합니다. 다른 소비자는 퍼블릭 인터넷을 통한 연결을 수락하며,이 단원에서도 설명합니다.

다음 네트워킹 값 맵은 각 평가 지표에 대해 이러한 각 옵션의 점수를 요약합니다. 평가 지표에 대한 자세한 내용은이 가이드의 평가 지표를 참조하세요. 맵에서 5는 최저 TCO, 최상의 네트워크 격리 또는 최저 복구 시간과 같은 최고 점수를 나타냅니다. 이 레이더 차트를 읽는 방법에 대한 자세한 내용은이 가이드네트워킹 값 맵의 섹션을 참조하세요.

레이더 차트는 다음 값을 보여줍니다.

에 연결 AWS Site-to-Site VPN

AWS Site-to-Site VPN 가상 프라이빗 게이트웨이 또는 전송 게이트웨이에서 연결이 종료될 수 있습니다. 가상 프라이빗 게이트웨이는 단일 VPC에 연결할 수 있는 Site-to-Site VPN 연결 AWS 측의 VPN 엔드포인트입니다. 전송 게이트웨이는 여러 VPCs와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 전송 허브입니다. Site-to-Site VPN 연결 측 AWS 의 VPN 엔드포인트로도 사용할 수 있습니다. 이 섹션에서는 두 옵션에 대해 설명합니다.

가상 프라이빗 게이트웨이를 통한 연결

가상 프라이빗 게이트웨이를 생성한 후 SaaS 제품이 포함된 VPC에 연결합니다. 그런 다음 경로 전파를 활성화하여 VPN 경로를 VPC 라우팅 테이블에 전파합니다. 이러한 경로는 정적 또는 BGP 광고 동적 경로일 수 있습니다.

고가용성을 위해 Site-to-Site VPN 연결에는 AWS 측면의 두 가용 영역에서 종료되는 두 개의 VPN 터널이 있습니다. 하나를 사용할 수 없게 되면 두 번째 터널이 인계될 수 있습니다. 단일 터널은 최대 1.25 Gbps의 대역폭을 허용합니다. 가상 프라이빗 게이트웨이는 등가 다중 경로 라우팅(ECMP)을 지원하지 않으므로 한 번에 하나의 터널만 사용할 수 있습니다.

내결함성을 높이기 위해 두 번째 물리적 고객 게이트웨이에 대한 두 번째 VPN 연결을 설정할 수 있습니다. 연결이 설정되면 소비자는 SaaS 공급자의 VPC에 있는 리소스에 연결할 수 있습니다.

다음 다이어그램은이 아키텍처를 보여줍니다.

이 접근 방식은 다음과 같은 이점이 있습니다.

다음은이 접근 방식의 단점입니다.

전송 게이트웨이를 통한 연결

전송 게이트웨이를 통한 연결은 가상 게이트웨이와 유사합니다. 하지만 염두에 두어야 할 몇 가지 차이점이 있습니다.

먼저 VPN 연결의 경로는 전송 게이트웨이 라우팅 테이블 내에서 자동으로 전파될 수 있지만 연결된 VPCs에 경로를 수동으로 추가해야 합니다.

가상 게이트웨이와 비교하여 Transit Gateway는 ECMP를 지원합니다. 고객 게이트웨이가 ECMP를 지원하는 경우 두 터널을 모두 사용하여 총 최대 처리량 2.5 Gbps를 달성할 수 있습니다. 동일한 온프레미스 네트워크와 전송 게이트웨이 간에 여러 연결을 설정할 수 있습니다. 이 접근 방식을 사용하면 최대 대역폭을 연결당 최대 2.5 Gbps까지 늘릴 수 있습니다.

다음 다이어그램은이 아키텍처를 보여줍니다.

이 접근 방식은 다음과 같은 이점이 있습니다.

다음은이 접근 방식의 단점입니다.

에 연결 AWS Direct Connect

AWS Direct Connect는 표준 이더넷 광섬유 케이블을 통해 내부 네트워크를 Direct Connect 위치에 연결합니다. 다른 아키텍처 옵션과 달리 몇 분 내에 전용 연결을 설정할 수 없습니다. 대신 모든 요구 사항이 충족되면이 프로세스에 최대 며칠이 걸릴 수 있습니다. 그렇지 않으면 시간이 더 걸릴 수 있습니다. 따라서 AWS 계정 팀에 문의하거나이 접근 방식에 AWS Support 도움을 요청하는 것이 좋습니다. 선택적으로 AWS 파트너가 제공하고 다른 고객과 공유하는 호스팅 연결을 선택할 수 있습니다. 아키텍처는에 관계없이 동일합니다. 지연 시간을 줄이거나, 대역폭을 개선하거나, 규제 요구 사항을 준수하기 때문에 선택할 Direct Connect 수 있습니다.

Direct Connect 연결을 사용하려면 소비자가 퍼블릭, 프라이빗 또는 전송 가상 인터페이스를 생성해야 합니다. 다양한 아키텍처 옵션을 사용할 수 있습니다. 여러 온프레미스 위치를에 연결하는 가장 유연한 방법은 Direct Connect 게이트웨이에 연결된 AWS 클라우드 전송 가상 인터페이스입니다. Direct Connect 게이트웨이는 서비스 공급자가 최대 6개의 전송 게이트웨이를 연결할 수 있는 글로벌 논리적 구성 요소입니다. 또한 게이트웨이에 최대 30개의 가상 인터페이스를 연결할 수 있습니다. 확장을 위해 추가 Direct Connect 게이트웨이를 생성할 수 있습니다. SaaS 공급자 계정에서 전송 게이트웨이는 앞서 설명한 대로 VPCs에 연결됩니다.

소비자는 원하는 복원력 수준에 따라 총 1개 또는 2개의 Direct Connect 위치에서 1~4개의 Direct Connect 연결을 사용하여 연결할 수 있습니다. 자세한 내용은 최대 복원력을 Direct Connect 위한 구성을 참조하세요. 인터넷을 통한 AWS Site-to-Site VPN 연결은 Direct Connect 연결을 위한 저렴한 백업 경로 역할을 할 수도 있습니다. 지원되는 Direct Connect 전용 연결은 MACsec을 사용하여 Direct Connect 위치와 데이터 센터 간에 계층 2의 링크를 암호화할 수 있습니다. 데이터의 추가 기밀성을 위해 Site-to-Site VPN 연결을 사용하는 것이 일반적입니다. Site-to-Site VPN 연결은 일반 VPN 연결을 사용하여 전송 게이트웨이에서 종료할 수 있습니다. 다음 다이어그램은이 아키텍처를 보여줍니다.

이 접근 방식은 다음과 같은 이점이 있습니다.

다음은이 접근 방식의 단점입니다.

전송 VPC 아키텍처에 연결

Transit VPC는 소비자에게 연결 방법에 대한 유연성을 제공하는 아키텍처 옵션으로 AWS, SaaS 공급자는 이를 통해 서비스에 대한 통합 액세스를 활용할 수 있습니다 AWS PrivateLink. 소비자는 온프레미스에서 진입점(예: 가상 프라이빗 게이트웨이)과 AWS PrivateLink 리소스인 인터페이스 VPC 엔드포인트만 포함하는 전송 VPC에 연결합니다. 전송 VPCs는 SaaS 공급자 또는 소비자가 소유해야 합니다. 이 섹션에서는 두 옵션에 대해 설명합니다.

온프레미스 데이터 센터와 호환되는 CIDR 범위를 사용하여 전송 VPC 및 서브넷을 생성할 수 있습니다. 프라이빗 연결이 필요한 경우 소비자는 AWS Direct Connect 또는를 통해 해당 VPC에 연결할 수 있습니다 AWS Site-to-Site VPN. VPC 엔드포인트를 가리키는 Application Load Balancer 또는 Network Load Balancer를 사용하여 퍼블릭 인터넷에서 전송 계정에 대한 액세스를 구성할 수도 있습니다.

소비자 관리형 전송 VPC

이 접근 방식에서 SaaS 공급자는 전송 VPCs 맡깁니다. 기술적 관점에서 SaaS 공급자의 아키텍처는를 통해 소비자 AWS 클라우드 에 연결할 때와 동일합니다 AWS PrivateLink. 판매 및 제품 관점에서 볼 때 일부 소비자는 AWS 계정 아직 하지 않기 때문에 추가 노력이 필요합니다. 계정을 열고 운영하는 것을 주저할 수 있습니다. SaaS 공급자는 소비자에게 온프레미스 데이터 센터를 생성하고 AWS 계정 연결하는 방법에 대한 지침을 제공해야 합니다. 다음 다이어그램은 소비자가 전송 VPCs를 소유하는 퍼블릭 액세스와 프라이빗 액세스의 조합을 보여줍니다.

이 접근 방식은 다음과 같은 이점이 있습니다.

다음은이 접근 방식의 단점입니다.

공급자 관리형 전송 VPC

이 접근 방식은 동일한 기술을 사용하지만 계정 경계와 책임은 변경됩니다. 여기서 SaaS 공급자는 전송 VPCs, 가급적이면 SaaS 제품과 별도의 계정에서 소유합니다. 이렇게 분리하면 비용이 절감되고, 위험이 줄어들며, 전송 계정을 독립적으로 확장할 수 있습니다. 높은 수준의 격리가 필요한 환경의 경우 서브넷을 사용하거나 각 소비자에 대해 별도의 전송 VPC를 생성하여 테넌트 간에 추가 분리를 생성할 수 있습니다. 그런 다음 소비자는 전송 VPC에 연결하는 방법을 선택할 수 있습니다. 이 접근 방식은 총 주소 지정 가능 시장을 확장할 수 있는 더 많은 옵션을 제공하지만 추가 아키텍처 구성 요소를 운영하고 모니터링해야 하기 때문에 SaaS 공급자의 TCO가 더 높습니다.

이 접근 방식은 다음과 같은 이점이 있습니다.

다음은이 접근 방식의 단점입니다.

퍼블릭 인터넷을 통해 연결

퍼블릭 인터넷 액세스는 SaaS 제품에 대한 액세스를 제공하기 위한 유효한 옵션이기도 하지만, 기존 방식으로는 프라이빗 연결을 제공하지 않습니다. 일부 소비자는 자신과 SaaS 공급자 간에 추가 네트워킹 인프라가 필요하지 않기 때문에 여전히 퍼블릭 액세스 접근 방식을 선호할 수 있습니다. 공격 표면 증가에 대한 대가로 복잡성, 비용 및 통합 시간을 줄입니다. 강력한 인증 및 권한 부여 메커니즘은 증가된 위협 수준을 완화하는 데 도움이 될 수 있으며 항상 트래픽을 암호화해야 합니다. 이 시나리오에서는를 사용하는 등 추가 보안 계층을 사용하는 것이 좋습니다AWS WAF.

이 시나리오의 아키텍처는 간단합니다. 소비자는 인터넷을 통해 퍼블릭 호스트(SaaS 공급자)에 연결합니다. 애플리케이션은 탄력적 IP 주소를 사용하여 퍼블릭 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 직접 호스팅할 수 있습니다. 기본 옵션은 Application Load Balancer 또는 유사한 서비스 뒤에 호스팅하는 것입니다. 성능 향상 및 정적 자산 캐싱을 위해 Amazon CloudFront와 같은 콘텐츠 전송 네트워크를 사용할 수 있습니다. 두 개의 글로벌 정적 애니캐스트 IP 주소를 통해 최소 지연 시간으로 애플리케이션을 제공하려면 Amazon EC2 인스턴스, Network Load Balancer 또는 Application Load Balancer 앞에 AWS Global Accelerator를 배치할 수 있습니다. 또한 CloudFront, Application Load Balancer AWS AppSync및 Amazon API Gateway는 모두와 통합됩니다 AWS WAF. 다음 다이어그램은 퍼블릭 인터넷 액세스 연결 옵션의 개요를 제공합니다.

다음 표에서는이 시나리오에서 지원되는 프로토콜 및 통합에 대해 설명합니다.

이 접근 방식은 다음과 같은 이점이 있습니다.

다음은이 접근 방식의 단점입니다.

선택한 서비스에 따라 다른 이점과 단점이 적용됩니다.