[비교분석] 아마존 AWS VPC와 애저 Virtual Network의 근본적 차이점 분석(번역)
비교분석
작성자
Roronoa
작성일
2018-08-10 11:01
조회
19082
Comparison of Cloud Virtual Nework (Amazon VPC VS Microsoft Azure VNet)
클라우드에서 AWS와 Azure는 표면적으로는 같은 서비스처럼 보이지만 내부적으로는 매우 다른 알고리즘으로 구성되어 있습니다. 클라우드에서 특징들과 기능은 끊임없이 변화하는 상태이며 오늘 다르고 내일 또 업데이트 되는 탄력적 진화 시스템입니다. 심지어 지금 이순간도 클라우드 기술이 변하고 있으며 그 단위가 일주일 이하도 있습니다. 세부적인 기능은 언제 바뀌었는지 조차도 어려울정도로 지속적으로 테스트하고 연구하지 않으면 점점 뒷쳐지며 심지어 엔지니어로서, 개발자로서 자신의 영역을 줄 여야만 하는 시대에 살고 있습니다. 자 이 글은 Azure 입장에 쓰는 마케팅 블로그가 아니며 실전 사용자가 이러한 서비스의 유사점과 차이점을 잘 이해를 돕기 위한 의도로 쓴 글을 번역한 글입니다. 물론 이 글에 대한 다른 의견은 있을수 있으며 이 글은 단순히 AWS와 Azure에 관한 우위를 판단하는 글이 아닙니다. 현재는 Azure 와 AWS를 동시에 사용하는 아키텍트로써 클라우드에 가장 중요한 코어인 가상네트워트의 차이점에 대해 비교 분석 글을 번역 해보겠습니다. 이 번역에는 제 개인적인 생각이 포함되어 있으므로 저자의 의도와 다를수 있습니다. 또한 빠른 업데이트가 모두 적용된 글은 아니며 차이점에 포커스를 둔 글입니다.
우선 가상네트워크는 온프레미스의 네트워크에서 부터 왔으며 이것을 소프트웨어적으로 풀어서 가상으로 만들었기때문에 “가상”이란 이름을 붙였습니다. 실제적으로 가상네트워크라는 이름을 붙일수 있는 클라우드는 몇개 되지 않습니다. 이름뿐인 가상네트워크를 가진 클라우드가 많으며 현재까지는 AWS의 VPC와 Azure의 Virtual Network가 가장 온프레미스에 대부분의 기능을 전부 구현한 가상네트워크 입니다. 클라우드에서 가장 중요한 부분은 가상네트워크라고 생각되어집니다. 단순 가상머신이나 스토리지보다 가장 기술적으로 안정성과 보안성을 필요로 하기때문에 저는 가상네트워크가 가장 중요하다고 생각합니다. 일단 가상머신 10대 이하에서는 가상네트워크가 있으면 좋지만 AWS와 Azure의 경우는 VM이나 EC2를 만들어 쓰는데 그냥 딸려오는 꽁짜로 주어지는 것처럼 인식하는 라이트 유저도 있지만 이 기술이 정말 코어 기술이며 가상머신이 많아지고 다양한 아키텍쳐 및 가상네트워크 간에 VPN과 Peering 을 넘어 “Global Peering” 과 같은 데이터 센터간의 가상네트워크의 연결은 어설픈 클라우드 벤더는 시도 조차 할수 없습니다.
자 Microsoft와 가상 네트워크 (VNet)와 AWS의 가상 사설 클라우드 (VPC) 가 있습니다. 적합한 결정을 내리는 데 도움이될수 있는 두 가지 사설 네트워크 제품의 유사점과 차이점을 살펴 봅시다.
개념적으로 Azure VNet과 AWS VPC는 양쪽 모두 클라우드에서 프로비저닝 리소스와 서비스를 제공합니다. 양쪽 네트워크에서 모두 동일한 빌딩 블록(제품군)을 제공하지만 구현 방식에 차이가 있습니다. 다음은 이러한 빌딩 블록 (제품군) 중 일부에 대한 요약입니다.
서브넷
Azure VNet과 AWS VPC는 클라우드에 배치 된 자원을 효과적으로 설계하고 제어하기 위해 네트워크를 서브넷과 분리합니다. AWS의 VPC는 해당 지역의 모든 가용 영역 (Availability Zone)에 걸쳐 있고 VPC의 서브넷은 가용 영역 (AZ)에 매핑됩니다. 서브넷은 하나의 AZ에만 속해야하며 모든 AZ를 걸쳐있을 수 없습니다. (*물리적으로 불가능 하며 Azure 의 AZ도 마찬가지 임). Azure VNet 서브넷은 할당 된 IP 주소 블록에 의해 정의됩니다. AWS VPC의 모든 서브넷 간의 통신은 AWS 백본(*백본을 이용하므로 빠름)을 통해 이루어지며 기본적으로 허용됩니다. AWS VPC 서브넷은 개인(*개인 망) 또는 공개(*외부접속 가능) 중 하나 일 수 있습니다. 인터넷 게이트웨이 (IGW)가 연결된 서브넷은 공용입니다. AWS는 VPC 당 하나의 IGW 만 허용하며 공용 서브넷은 배포 된 리소스가 인터넷 액세스를 허용합니다. AWS는 각 지역에 대한 기본 VPC 및 서브넷을 만듭니다. 이 기본 VPC에는 VPC가 상주하는 각 지역에 대한 서브넷이 있으며 이 VPC에 배포 된 모든 이미지 (EC2 인스턴스)에는 공용 IP 주소가 할당되므로 인터넷 연결이 가능합니다. Azure VNet은 기본 VNet을 제공하지 않으며 AWS VPC와 같이 개인 또는 공용 서브넷을 갖지 않습니다. VNet에 연결된 리소스는 기본적으로 인터넷에 액세스 할 수 있습니다. (*개인과 공용 서브넷을 AWS와 비슷하게 구성은 가능함)
IP 주소
AWS VPC 와 Azure VNET 모두 RFC 1918에 명시된 비공개 IPv4 주소 범위의 비 전역 적으로 라우팅 가능한 CIDR을 사용합니다. 이 RFC의 주소는 전역 적으로 라우팅 할 수 없지만 고객은 다른 공용 IP 주소를 계속 사용할 수 있습니다. (*이 말은 내부 네트워크처럼 사용 가능하면서 외부 네트워크로 나가는 방법을 공용IP를 사용할수 있다는 말입니다. 예를들어 10.0.0.1이라는 주소를 내부에서는 사용가능하며 이 주소가 공용IP와 연결되어 사용할수 있다는 말입니다.) Azure VNet은 지정된 CIDR 블록의 개인 IP 주소에 VNet에 연결되어 배포 된 리소스를 할당합니다. Azure VNet에서 지원되는 가장 작은 서브넷은 / 29이고 가장 큰 서브넷은 / 8입니다. 또한 AWS는 동일한 RFC 1918 또는 공개적으로 라우팅 가능한 IP 블록의 IP 주소를 허용합니다. 현재 AWS는 공개적으로 라우팅 가능한 IP 블록에서 인터넷에 대한 직접 액세스를 지원하지 않으므로 인터넷 게이트웨이 (IGW)를 통해서도 인터넷에 연결할 수 없습니다. 가상 사설망(VPN) 을 통해서만 접근 할 수 있습니다. 이 때문에 224.0.0.0에서 255.255.255.255 (클래스 D 및 클래스 E IP 주소 범위) 범위의 VPC로 실행하면 Windows 인스턴스를 올바르게 부팅 할 수 없습니다. 서브넷의 경우 AWS는 / 28의 최소 주소 블록과 / 16의 최대 주소 블록을 권장합니다. 이 블로그를 작성할 때 IPv6 용 Microsoft Azure VNet 지원은 제한적이지만 AWS VPC는 2017 년 1 월 현재 중국을 제외한 모든 지역에 대해 IPv6을 지원합니다. IPv6의 경우 VPC는 고정 크기 인 / 56 (CIDR 표기법)이며, 서브넷 크기는 / 64로 고정됩니다. IPv6에서는 모든 주소가 인터넷 라우팅이 가능하며 기본적으로 인터넷에 연결할 수 있습니다. AWS VPC는 사설 서브넷의 리소스에 Egress-Only Internet Gateway (EGW)를 제공합니다. 아웃 바운드 트래픽을 허용하면서 들어오는 트래픽을 차단합니다. AWS에서는 기존 자원에 IPv6을 사용하도록 설정하고 인터넷에 액세스해야하는 사설 서브넷의 자원에 대해 전용 인터넷 게이트웨이를 제공 할 수 있습니다. 발신 전용 인터넷 게이트웨이는 인터넷에 액세스 할 수 있지만 들어오는 트래픽은 차단합니다. 이러한 CIDR 블록에서 IP 주소를 할당하는 방법을 이해하게 된다면 AWS VPC 네트워크를 설계하는 것이 중요합니다. 설계 후 배포 이후 서브넷 IP 주소를 변경하는 것이 쉽지 않기 때문입니다. Azure VNet은 이 영역에서 더 많은 유연성을 제공합니다. 서브넷의 IP 주소는 초기 설계 후에 변경 될 수 있습니다. 그러나 현재 서브넷의 리소스는 현재 서브넷에서 마이그레이션해야합니다. (*추가적으로 Azure에서는 AWS의 EIP(Elastic IP) 처럼 쉽게 IP관리 되지 않습니다).
게이트웨이
VNet과 VPC 모두 서로 다른 연결 목적을 위해 다른 게이트웨이를 제공합니다. AWS VPC에는 3종의 Gateway가 있으며(사용하며), NAT Gateway를 포함하면 4종입니다. AWS를 사용하면 하나의 인터넷 게이트웨이 (IGW)가 IPv4를 통해 인터넷 연결을 제공하고 IPv6 만 사용하는 인터넷 연결을 위해 송신 전용 인터넷 게이트웨이를 제공 할 수 있습니다. AWS에서 IGW가없는 서브넷은 개인 서브넷으로 간주되며, NAT 게이트웨이 또는 NAT 인스턴스가 없는 인터넷 연결은 없습니다 .(AWS는 고 가용성 및 확장 성을 위해 NAT 게이트웨이를 권장하며 *실제 사용시 NAT 인스턴스가 훨씬 좋지 않음). 또 다른 AWS 게이트웨이 인 VPG (Virtual Private Gateway)를 통해 AWS는 VPN 또는 Direct Connect를 통해 AWS에서 다른 네트워크로 연결을 제공 할 수 있습니다. 비 AWS 네트워크에서 AWS는 AWS VPC에 연결하기 위해 고객 측의 고객 게이트웨이 (Customer Gateway, CGW)를 요구합니다.
Azure VNet은 VPN 게이트웨이와 ExpressRoute 게이트웨이의 두 가지 유형의 게이트웨이를 제공합니다. VPN 게이트웨이는 VNet에서 VNet으로의 암호화 된 트래픽을 VNet 또는 VNet VPN의 경우 공용 연결을 통해 또는 Microsoft의 백본에서 온 - 프레미스 위치로 암호화 할 수 있습니다. 그러나 ExpressRoute 및 VPN 게이트웨이에는 게이트웨이 서브넷이 필요합니다. 게이트웨이 서브넷에는 가상 네트워크 게이트웨이 서비스가 사용하는 IP 주소가 들어 있습니다. Azure VNET to VNET은 VPN을 통해 기본적으로 연결할 수 있지만 AWS에서는 VPC와 VPC가 서로 다른 지역에있는 경우 VPC와 타사 NVA가 필요합니다.
하이브리드 연결성
AWS VPC와 Azure VNet은 각각 VPN 및 또는 Direct Connect와 ExpressRoute를 사용하여 하이브리드 연결을 허용합니다. Direct Connect 또는 ExpressRoute를 사용하면 최대 10Gbps의 연결을 사용할 수 있습니다. AWS DC 연결은 라우터의 포트와 Amazon 라우터 간의 단일 전용 연결로 구성됩니다. 하나의 DC 연결을 사용하면 공용 AWS 서비스 (예 : Amazon S3) 또는 Amazon VPC에 직접 가상 인터페이스를 만들 수 있습니다. AWS DC를 사용하기 전에 가상 인터페이스를 만들어야합니다. AWS는 AWS Direct Connect 연결 당 50 개의 가상 인터페이스를 허용하며 이는 AWS에 문의하여 증가시킬 수 있습니다.
이중화가 필요한 경우 AWS DC 연결은 중복되지 않으며 두 번째 연결이 필요합니다.(*한개 더 연결해야함). AWS VPN은 AWS VPC와 사내 구축 형 네트워크 사이에 두 개의 터널을 생성합니다. Direct Connect에 내결함성을 제공하기 위해 AWS는 터널 중 하나를 사용하여 VPN 및 BGP를 통해 사내 구축 형 데이터 네트워크에 연결할 것을 권장합니다. Azure ExpressRoute는 또한 연결 용으로 두 개의 링크와 SLA를 제공합니다. Azure는 최소 99.95 % ExpressRoute 전용 회로 가용성을 보장하므로 예측 가능한 네트워크 성능을 보장합니다.
가장 큰 차이점을 이해 하려면 Nat gateway와 VPN에 대해 어느정도 지식이 있는 상태에서 읽어보시는것을 추천드립니다.
원본글 : https://blogs.msdn.microsoft.com/premier_developer/2017/09/17/differentiating-between-azure-virtual-network-vnet-and-aws-virtual-private-cloud-vpc/
클라우드에서 AWS와 Azure는 표면적으로는 같은 서비스처럼 보이지만 내부적으로는 매우 다른 알고리즘으로 구성되어 있습니다. 클라우드에서 특징들과 기능은 끊임없이 변화하는 상태이며 오늘 다르고 내일 또 업데이트 되는 탄력적 진화 시스템입니다. 심지어 지금 이순간도 클라우드 기술이 변하고 있으며 그 단위가 일주일 이하도 있습니다. 세부적인 기능은 언제 바뀌었는지 조차도 어려울정도로 지속적으로 테스트하고 연구하지 않으면 점점 뒷쳐지며 심지어 엔지니어로서, 개발자로서 자신의 영역을 줄 여야만 하는 시대에 살고 있습니다. 자 이 글은 Azure 입장에 쓰는 마케팅 블로그가 아니며 실전 사용자가 이러한 서비스의 유사점과 차이점을 잘 이해를 돕기 위한 의도로 쓴 글을 번역한 글입니다. 물론 이 글에 대한 다른 의견은 있을수 있으며 이 글은 단순히 AWS와 Azure에 관한 우위를 판단하는 글이 아닙니다. 현재는 Azure 와 AWS를 동시에 사용하는 아키텍트로써 클라우드에 가장 중요한 코어인 가상네트워트의 차이점에 대해 비교 분석 글을 번역 해보겠습니다. 이 번역에는 제 개인적인 생각이 포함되어 있으므로 저자의 의도와 다를수 있습니다. 또한 빠른 업데이트가 모두 적용된 글은 아니며 차이점에 포커스를 둔 글입니다.
우선 가상네트워크는 온프레미스의 네트워크에서 부터 왔으며 이것을 소프트웨어적으로 풀어서 가상으로 만들었기때문에 “가상”이란 이름을 붙였습니다. 실제적으로 가상네트워크라는 이름을 붙일수 있는 클라우드는 몇개 되지 않습니다. 이름뿐인 가상네트워크를 가진 클라우드가 많으며 현재까지는 AWS의 VPC와 Azure의 Virtual Network가 가장 온프레미스에 대부분의 기능을 전부 구현한 가상네트워크 입니다. 클라우드에서 가장 중요한 부분은 가상네트워크라고 생각되어집니다. 단순 가상머신이나 스토리지보다 가장 기술적으로 안정성과 보안성을 필요로 하기때문에 저는 가상네트워크가 가장 중요하다고 생각합니다. 일단 가상머신 10대 이하에서는 가상네트워크가 있으면 좋지만 AWS와 Azure의 경우는 VM이나 EC2를 만들어 쓰는데 그냥 딸려오는 꽁짜로 주어지는 것처럼 인식하는 라이트 유저도 있지만 이 기술이 정말 코어 기술이며 가상머신이 많아지고 다양한 아키텍쳐 및 가상네트워크 간에 VPN과 Peering 을 넘어 “Global Peering” 과 같은 데이터 센터간의 가상네트워크의 연결은 어설픈 클라우드 벤더는 시도 조차 할수 없습니다.
자 Microsoft와 가상 네트워크 (VNet)와 AWS의 가상 사설 클라우드 (VPC) 가 있습니다. 적합한 결정을 내리는 데 도움이될수 있는 두 가지 사설 네트워크 제품의 유사점과 차이점을 살펴 봅시다.
개념적으로 Azure VNet과 AWS VPC는 양쪽 모두 클라우드에서 프로비저닝 리소스와 서비스를 제공합니다. 양쪽 네트워크에서 모두 동일한 빌딩 블록(제품군)을 제공하지만 구현 방식에 차이가 있습니다. 다음은 이러한 빌딩 블록 (제품군) 중 일부에 대한 요약입니다.
서브넷
Azure VNet과 AWS VPC는 클라우드에 배치 된 자원을 효과적으로 설계하고 제어하기 위해 네트워크를 서브넷과 분리합니다. AWS의 VPC는 해당 지역의 모든 가용 영역 (Availability Zone)에 걸쳐 있고 VPC의 서브넷은 가용 영역 (AZ)에 매핑됩니다. 서브넷은 하나의 AZ에만 속해야하며 모든 AZ를 걸쳐있을 수 없습니다. (*물리적으로 불가능 하며 Azure 의 AZ도 마찬가지 임). Azure VNet 서브넷은 할당 된 IP 주소 블록에 의해 정의됩니다. AWS VPC의 모든 서브넷 간의 통신은 AWS 백본(*백본을 이용하므로 빠름)을 통해 이루어지며 기본적으로 허용됩니다. AWS VPC 서브넷은 개인(*개인 망) 또는 공개(*외부접속 가능) 중 하나 일 수 있습니다. 인터넷 게이트웨이 (IGW)가 연결된 서브넷은 공용입니다. AWS는 VPC 당 하나의 IGW 만 허용하며 공용 서브넷은 배포 된 리소스가 인터넷 액세스를 허용합니다. AWS는 각 지역에 대한 기본 VPC 및 서브넷을 만듭니다. 이 기본 VPC에는 VPC가 상주하는 각 지역에 대한 서브넷이 있으며 이 VPC에 배포 된 모든 이미지 (EC2 인스턴스)에는 공용 IP 주소가 할당되므로 인터넷 연결이 가능합니다. Azure VNet은 기본 VNet을 제공하지 않으며 AWS VPC와 같이 개인 또는 공용 서브넷을 갖지 않습니다. VNet에 연결된 리소스는 기본적으로 인터넷에 액세스 할 수 있습니다. (*개인과 공용 서브넷을 AWS와 비슷하게 구성은 가능함)
IP 주소
AWS VPC 와 Azure VNET 모두 RFC 1918에 명시된 비공개 IPv4 주소 범위의 비 전역 적으로 라우팅 가능한 CIDR을 사용합니다. 이 RFC의 주소는 전역 적으로 라우팅 할 수 없지만 고객은 다른 공용 IP 주소를 계속 사용할 수 있습니다. (*이 말은 내부 네트워크처럼 사용 가능하면서 외부 네트워크로 나가는 방법을 공용IP를 사용할수 있다는 말입니다. 예를들어 10.0.0.1이라는 주소를 내부에서는 사용가능하며 이 주소가 공용IP와 연결되어 사용할수 있다는 말입니다.) Azure VNet은 지정된 CIDR 블록의 개인 IP 주소에 VNet에 연결되어 배포 된 리소스를 할당합니다. Azure VNet에서 지원되는 가장 작은 서브넷은 / 29이고 가장 큰 서브넷은 / 8입니다. 또한 AWS는 동일한 RFC 1918 또는 공개적으로 라우팅 가능한 IP 블록의 IP 주소를 허용합니다. 현재 AWS는 공개적으로 라우팅 가능한 IP 블록에서 인터넷에 대한 직접 액세스를 지원하지 않으므로 인터넷 게이트웨이 (IGW)를 통해서도 인터넷에 연결할 수 없습니다. 가상 사설망(VPN) 을 통해서만 접근 할 수 있습니다. 이 때문에 224.0.0.0에서 255.255.255.255 (클래스 D 및 클래스 E IP 주소 범위) 범위의 VPC로 실행하면 Windows 인스턴스를 올바르게 부팅 할 수 없습니다. 서브넷의 경우 AWS는 / 28의 최소 주소 블록과 / 16의 최대 주소 블록을 권장합니다. 이 블로그를 작성할 때 IPv6 용 Microsoft Azure VNet 지원은 제한적이지만 AWS VPC는 2017 년 1 월 현재 중국을 제외한 모든 지역에 대해 IPv6을 지원합니다. IPv6의 경우 VPC는 고정 크기 인 / 56 (CIDR 표기법)이며, 서브넷 크기는 / 64로 고정됩니다. IPv6에서는 모든 주소가 인터넷 라우팅이 가능하며 기본적으로 인터넷에 연결할 수 있습니다. AWS VPC는 사설 서브넷의 리소스에 Egress-Only Internet Gateway (EGW)를 제공합니다. 아웃 바운드 트래픽을 허용하면서 들어오는 트래픽을 차단합니다. AWS에서는 기존 자원에 IPv6을 사용하도록 설정하고 인터넷에 액세스해야하는 사설 서브넷의 자원에 대해 전용 인터넷 게이트웨이를 제공 할 수 있습니다. 발신 전용 인터넷 게이트웨이는 인터넷에 액세스 할 수 있지만 들어오는 트래픽은 차단합니다. 이러한 CIDR 블록에서 IP 주소를 할당하는 방법을 이해하게 된다면 AWS VPC 네트워크를 설계하는 것이 중요합니다. 설계 후 배포 이후 서브넷 IP 주소를 변경하는 것이 쉽지 않기 때문입니다. Azure VNet은 이 영역에서 더 많은 유연성을 제공합니다. 서브넷의 IP 주소는 초기 설계 후에 변경 될 수 있습니다. 그러나 현재 서브넷의 리소스는 현재 서브넷에서 마이그레이션해야합니다. (*추가적으로 Azure에서는 AWS의 EIP(Elastic IP) 처럼 쉽게 IP관리 되지 않습니다).
게이트웨이
VNet과 VPC 모두 서로 다른 연결 목적을 위해 다른 게이트웨이를 제공합니다. AWS VPC에는 3종의 Gateway가 있으며(사용하며), NAT Gateway를 포함하면 4종입니다. AWS를 사용하면 하나의 인터넷 게이트웨이 (IGW)가 IPv4를 통해 인터넷 연결을 제공하고 IPv6 만 사용하는 인터넷 연결을 위해 송신 전용 인터넷 게이트웨이를 제공 할 수 있습니다. AWS에서 IGW가없는 서브넷은 개인 서브넷으로 간주되며, NAT 게이트웨이 또는 NAT 인스턴스가 없는 인터넷 연결은 없습니다 .(AWS는 고 가용성 및 확장 성을 위해 NAT 게이트웨이를 권장하며 *실제 사용시 NAT 인스턴스가 훨씬 좋지 않음). 또 다른 AWS 게이트웨이 인 VPG (Virtual Private Gateway)를 통해 AWS는 VPN 또는 Direct Connect를 통해 AWS에서 다른 네트워크로 연결을 제공 할 수 있습니다. 비 AWS 네트워크에서 AWS는 AWS VPC에 연결하기 위해 고객 측의 고객 게이트웨이 (Customer Gateway, CGW)를 요구합니다.
Azure VNet은 VPN 게이트웨이와 ExpressRoute 게이트웨이의 두 가지 유형의 게이트웨이를 제공합니다. VPN 게이트웨이는 VNet에서 VNet으로의 암호화 된 트래픽을 VNet 또는 VNet VPN의 경우 공용 연결을 통해 또는 Microsoft의 백본에서 온 - 프레미스 위치로 암호화 할 수 있습니다. 그러나 ExpressRoute 및 VPN 게이트웨이에는 게이트웨이 서브넷이 필요합니다. 게이트웨이 서브넷에는 가상 네트워크 게이트웨이 서비스가 사용하는 IP 주소가 들어 있습니다. Azure VNET to VNET은 VPN을 통해 기본적으로 연결할 수 있지만 AWS에서는 VPC와 VPC가 서로 다른 지역에있는 경우 VPC와 타사 NVA가 필요합니다.
하이브리드 연결성
AWS VPC와 Azure VNet은 각각 VPN 및 또는 Direct Connect와 ExpressRoute를 사용하여 하이브리드 연결을 허용합니다. Direct Connect 또는 ExpressRoute를 사용하면 최대 10Gbps의 연결을 사용할 수 있습니다. AWS DC 연결은 라우터의 포트와 Amazon 라우터 간의 단일 전용 연결로 구성됩니다. 하나의 DC 연결을 사용하면 공용 AWS 서비스 (예 : Amazon S3) 또는 Amazon VPC에 직접 가상 인터페이스를 만들 수 있습니다. AWS DC를 사용하기 전에 가상 인터페이스를 만들어야합니다. AWS는 AWS Direct Connect 연결 당 50 개의 가상 인터페이스를 허용하며 이는 AWS에 문의하여 증가시킬 수 있습니다.
이중화가 필요한 경우 AWS DC 연결은 중복되지 않으며 두 번째 연결이 필요합니다.(*한개 더 연결해야함). AWS VPN은 AWS VPC와 사내 구축 형 네트워크 사이에 두 개의 터널을 생성합니다. Direct Connect에 내결함성을 제공하기 위해 AWS는 터널 중 하나를 사용하여 VPN 및 BGP를 통해 사내 구축 형 데이터 네트워크에 연결할 것을 권장합니다. Azure ExpressRoute는 또한 연결 용으로 두 개의 링크와 SLA를 제공합니다. Azure는 최소 99.95 % ExpressRoute 전용 회로 가용성을 보장하므로 예측 가능한 네트워크 성능을 보장합니다.
가장 큰 차이점을 이해 하려면 Nat gateway와 VPN에 대해 어느정도 지식이 있는 상태에서 읽어보시는것을 추천드립니다.
원본글 : https://blogs.msdn.microsoft.com/premier_developer/2017/09/17/differentiating-between-azure-virtual-network-vnet-and-aws-virtual-private-cloud-vpc/