Azure VNets 와 AWS VPC 간의 유사점과 차이점

클라우드 컴퓨팅은 소프트웨어 설계 및 데이터 센터의 역할 / 기능에 대해 우리가 알고있는 것을 변화 시켰습니다. 클라우드로의 여행은 클라우드 제공 업체를 선택하고 사설망을 프로비저닝하거나 사내 네트워크를 확장하는 것으로 시작됩니다. 클라우드에서 리소스를 프로비저닝하려는 고객은 다양한 클라우드 공급자가 제공하는 다양한 사설 네트워크 중에서 선택할 수 있습니다. 가장 많이 배치 된 사설망은 가상 네트워크 (VNet) 및 가상 사설 클라우드 (VPC)마이크로 소프트와 아마존으로부터 각각. 이 블로그는 잠재적 인 고객에게 두 개의 사설망을 차별화 할 수있는 정보를 제공하고 작업 부하에 적합한 결정을 내리는 데 도움이되는 두 가지 사설 네트워크 제품의 유사점과 차이점을 살펴 봅니다. 이 시리즈의 첫 번째 블로그에서는 모든 클라우드 네트워크의 기본 구성 요소를 다룰 것입니다. 이 현재 블로그는 복잡성 때문에 가격을 비교하지 않을 것이며 향후 게시물에서 다루어 질 것입니다.

개념적으로 Azure VNet과 AWS VPC는 ​​모두 클라우드에서 자원과 서비스를 프로비저닝하기위한 기반을 제공합니다. 두 네트워크 모두 동일한 빌딩 블록을 제공하지만 구현의 정도에는 차이가 있습니다. 다음은 이러한 빌딩 블록 중 일부에 대한 요약입니다.

• 서브넷 - Azure VNet과 AWS VPC는 ​​클라우드에 배치 된 자원을 효과적으로 설계하고 제어하기 위해 네트워크를 서브넷과 분리합니다. AWS VPC는 ​​해당 지역의 모든 가용 영역 (AZ)에 걸쳐 있으므로 AWS VPC의 서브넷은 가용 영역 (AZ)에 매핑됩니다. 서브넷은 하나의 AZ에만 속해야하며 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에 연결된 리소스는 기본적으로 인터넷에 액세스 할 수 있습니다.
• IP 주소 - AWS VPC와 Azure VNET 모두 RFC 1918에 명시된대로 개인 IPv4 주소 범위의 전역 적으로 라우팅 할 수없는 CIDR을 사용합니다.이 RFC의 주소는 전 세계적으로 라우팅 할 수 없지만 고객은 다른 공용 IP 주소를 계속 사용할 수 있습니다. Azure VNet은 지정된 CIDR 블록의 개인 IP 주소에 VNet에 연결되어 배포 된 리소스를 할당합니다. Azure VNet에서 지원되는 가장 작은 서브넷은 / 29이고 가장 큰 서브넷은 / 8입니다. 또한 AWS는 동일한 RFC 1918 또는 공개적으로 라우팅 가능한 IP 블록의 IP 주소를 허용합니다. 현재 AWS는 공개적으로 라우팅 가능한 IP 블록에서 인터넷에 직접 액세스 할 수 없으므로 인터넷 게이트웨이 (IGW)를 통해서도 인터넷에 연결할 수 없습니다. 가상 사설망을 통해서만 접근 할 수 있습니다. 이 때문에 Windows 인스턴스를 범위가 224.0.0.0~ 인 VPC에 시작하면 Windows 인스턴스를 올바르게 부팅 할 수 없습니다.255.255.255.255(클래스 D 및 클래스 E IP 주소 범위). 서브넷의 경우 AWS는 / 28의 최소 주소 블록과 / 16의 최대 주소 블록을 권장합니다. 이 블로그를 작성할 때 Microsoft Azure VNet의 IPv6 지원은 제한적이지만 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 주소 는 초기 설계 후에 변경할 수 있습니다. 그러나 현재 서브넷의 리소스는 현재 서브넷에서 마이그레이션해야합니다.
• 라우팅 테이블 - AWS는 경로 테이블을 사용하여 서브넷의 아웃 바운드 트래픽에 허용되는 경로를 지정합니다. VPC에서 생성 된 모든 서브넷은 자동으로 기본 라우팅 테이블과 연결되므로 VPC의 모든 서브넷은 보안 규칙에 의해 명시 적으로 거부되지 않는 한 다른 서브넷의 트래픽을 허용 할 수 있습니다. Azure VNet에서 VNet의 모든 리소스는 시스템 경로를 사용하여 트래픽 흐름을 허용합니다. 기본적으로 Azure VNet은 서브넷, VNets 및 사내 구축 형 네트워크 간의 라우팅을 제공하므로 경로를 구성하고 관리 할 필요가 없습니다. 시스템 경로를 사용하면 트래픽이 자동으로 원활하게 처리되지만 가상 어플라이언스를 통해 패킷 라우팅을 제어하려는 경우가 있습니다. Azure VNet은 시스템 경로 테이블을 사용하여 모든 VNet의 서브넷에 연결된 리소스가 기본적으로 서로 통신하는지 확인합니다. 하나, 기본 경로를 재정의하려는 경우가 있습니다. 이러한 시나리오의 경우 사용자 정의 라우트 (UDR)를 구현할 수 있습니다. 트래픽이 각 서브넷에 라우팅되는 위치 및 / 또는 BGP 라우트 (Azure VPN 게이트웨이 또는 ExpressRoute 연결을 사용하여 VNet을 사내 구축 형 네트워크로) 제어 할 수 있습니다. UDR은 서브넷에서 나가는 트래픽에만 적용되며 UDR의 목표가 일종의 검사 NVA 등으로 트래픽을 보내는 것이라면 Azure VNet 배포에 보안 계층을 제공 할 수 있습니다. UDR을 사용하면 다른 서브넷에서 하나의 서브넷으로 전송 된 패킷을 일련의 라우트에서 네트워크 가상 어플라이언스를 통과하도록 강제 설정할 수 있습니다. 하이브리드 설정에서 Azure VNet은 UDR, BGP (ExpressRoute가 사용되는 경우) 및 시스템 라우팅 테이블의 세 가지 경로 테이블 중 하나를 사용할 수 있습니다. Azure VNet에서, 서브넷은 라우트 테이블이 명시 적으로 서브넷과 연관 될 때까지 트래픽에 대한 시스템 라우트에 의존합니다. 연결이 설정되면, 즉 UDR 및 / 또는 BGP 라우트가 존재하면 가장 긴 접두사 일치 (LPM)를 기반으로 라우팅이 수행됩니다. 프리픽스 길이가 동일한 경로가 두 개 이상인 경우 경로는 사용자 정의 경로, BGP 경로 (ExpressRoute 사용시) 및 시스템 경로 순으로 해당 출발지를 기준으로 선택됩니다. 반면 AWS VPC에서 라우팅 테이블은 둘 이상일 수 있지만 동일한 유형입니다. BGP 경로 (ExpressRoute 사용시)와 시스템 경로. 반면 AWS VPC에서 라우팅 테이블은 둘 이상일 수 있지만 동일한 유형입니다. BGP 경로 (ExpressRoute 사용시)와 시스템 경로. 반면 AWS VPC에서 라우팅 테이블은 둘 이상일 수 있지만 동일한 유형입니다.
• 보안 - AWS VPC는 ​​네트워크에 배포 된 리소스에 대해 두 가지 수준의 보안을 제공합니다. 첫 번째 보안 그룹 (SG)이라고합니다. 보안 그룹은 EC2 인스턴스 수준에서 적용되는 상태 저장 개체입니다. 기술적으로이 규칙은 ENI (Elastic Network Interface) 수준에서 적용됩니다. 응답 트래픽은 트래픽이 허용되면 자동으로 허용됩니다. 두 번째 보안 메커니즘은 네트워크 액세스 제어 (NACL)라고합니다. NACL은 서브넷 수준에서 적용되며 서브넷에 배포 된 모든 리소스에 적용되는 상태 비 저장 필터링 규칙입니다. 진입 트래픽이 허용되면 응답은 서브넷에 대한 규칙에서 명시 적으로 허용되지 않는 한 자동으로 허용되지 않기 때문에 무 상태입니다. NACL은 서브넷에 들어가고 나가는 트래픽을 검사하여 서브넷 수준에서 작동합니다. NACL을 사용하여 허용 및 거부 규칙을 설정할 수 있습니다. NACL을 여러 서브넷과 연결할 수 있습니다. 그러나 서브넷은 한 번에 하나의 NACL 만 연결할 수 있습니다. NACL 규칙은 번호가 매겨져 가장 낮은 번호의 규칙부터 순서대로 평가되어 네트워크 ACL과 연결된 서브넷 안팎으로 트래픽이 허용되는지 여부를 결정합니다. 규칙에 사용할 수있는 가장 높은 번호는 32766입니다. 번호가 매겨진 마지막 규칙은 항상 별표이며, 서브넷에 대한 트래픽을 거부합니다. NACL 목록의 규칙이 트래픽과 일치하지 않는 경우에만이 규칙에 도달합니다. Azure VNet은 NSG (Network Security Groups)를 제공하며 AWS SG 및 NACL의 기능을 결합합니다. NSG는 상태 기반이며 서브넷 또는 NIC 수준에서 적용될 수 있습니다. 하나의 NSG 만 NIC에 적용 할 수 있습니다.
• 게이트웨이 - VNet과 VPC 모두 서로 다른 연결 목적을 위해 다른 게이트웨이를 제공합니다. AWS VPC는 ​​NAT 게이트웨이를 추가하는 경우 주로 세 개의 게이트웨이 (네 개)를 사용합니다. AWS를 사용하면 하나의 인터넷 게이트웨이 (IGW)가 IPv4를 통해 인터넷 연결을 제공하고 IPv6 만 사용하는 인터넷 연결을 위해 송신 전용 인터넷 게이트웨이를 제공 할 수 있습니다. AWS에서 IGW가없는 서브넷은 사설 서브넷으로 간주되며 NAT 게이트웨이 또는 NAT 인스턴스가없는 인터넷 연결이 없습니다 (AWS는 고 가용성 및 확장 성을 위해 NAT 게이트웨이를 권장합니다). 또 다른 AWS 게이트웨이 인 VPG (Virtual Private Gateway)를 통해 AWS는 VPN 또는 Direct Connect를 통해 AWS에서 다른 네트워크로 연결을 제공 할 수 있습니다. 비 AWS 네트워크에서 AWS는 AWS VPC에 연결하기 위해 고객 측의 고객 게이트웨이 (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가 필요합니다. 게이트웨이 서브넷에는 가상 네트워크 게이트웨이 서비스가 사용하는 IP 주소가 들어 있습니다. Azure VNET to VNET은 VPN을 통해 기본적으로 연결할 수 있지만 AWS에서는 VPC와 VPC가 서로 다른 지역에있는 경우 VPC와 타사 NVA가 필요합니다. 게이트웨이 서브넷에는 가상 네트워크 게이트웨이 서비스가 사용하는 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 전용 회로 가용성을 보장하므로 예측 가능한 네트워크 성능을 보장합니다.

원문: https://devblogs.microsoft.com/premier-developer/differentiating-between-azure-virtual-network-vnet-and-aws-virtual-private-cloud-vpc/