이 가이드에서는 Azure AWS(Amazon Web Services), Google Cloud에 연결하거나 다른 클라우드 공급자에서 워크로드를 마이그레이션하는 고객을 위한 Azure 네트워킹 디자인 가이드를 통해 시퀀싱된 읽기 경로를 제공합니다. 번호가 매겨진 단계를 따라 Azure와 기존 클라우드 인프라 간에 안전하고 모니터링되는 연결을 설계하세요.
발견이 먼저인 이유
클라우드 간 네트워킹은 하나 이상의 외부 클라우드 환경에 Azure 연결합니다. AZURE 서비스에 대한 프라이빗 연결이 필요한 AWS 또는 Google Cloud에서 워크로드를 실행하거나, 뒤에 남아 있는 애플리케이션에 대한 연결을 유지하면서 다른 클라우드에서 Azure 애플리케이션을 마이그레이션할 수 있습니다. 어느 쪽이든 Azure 네트워크는 다른 쪽에서 완전히 제어하지 않는 인프라와 통합되어야 합니다.
이 학습 경로는 Azure 인프라 설계가 아니라 탐색부터 시작합니다. Azure 쪽을 디자인하기 전에 기존 다중 클라우드 토폴로지를 먼저 매핑합니다(실행되는 위치, 연결 방법 및 클라우드 간에 흐르는 트래픽 이해). 이 검색 우선 접근 방식은 재작업을 방지합니다. AWS 또는 Google Cloud 토폴로지를 이해하지 않고 Azure 네트워킹을 설계하는 경우 IP 주소 충돌, 연결 격차 및 보안 사각지대가 발생할 위험이 있습니다.
대상 아키텍처는 AZURE WAN(Virtual Wide Area Network)을 AWS Virtual Private Gateway 및 Google Cloud VPN에 대한 IPSec VPN 터널과 함께 전송 허브(AWS Transit Gateway와 동등한 Azure)로 사용합니다. 보안 가상 허브의 Azure Firewall 모든 클라우드 간 및 분기 트래픽을 검사합니다. DNS는 마이그레이션 중 클라우드 간에 이름 확인이 계속 작동하도록 신중한 컷오버 계획이 필요합니다.
사전 요구 사항
- 사용 가능한 Azure 네트워킹 서비스에 대한 방향에 대한 Azure 네트워킹 계획 및 디자인 개요를 읽어보십시오.
- AWS 및 Google 클라우드 환경의 토폴로지 검색 완료:
- AWS: AWS에서 AWS 마이그레이션 허브 또는 워크로드 검색을 실행하여 VPC(가상 프라이빗 클라우드), 전송 게이트웨이 및 VPC 간 연결을 인벤토리로 만듭니다.
- Google Cloud: 네트워크 인텔리전스 센터를 사용하여 VPC 네트워크, 클라우드 상호 연결 첨부 파일 및 방화벽 규칙을 매핑합니다.
- 클라우드 간 트래픽 흐름을 문서화합니다. 클라우드 간에 통신하는 애플리케이션, 필요한 대역폭, 대기 시간 민감도 및 암호화 요구 사항.
- 겹침을 식별하기 위해 세 클라우드 모두에 IP 주소 범위의 인벤토리를 만듭니다.
읽기 경로
다음 단계에서는 클라우드 간 네트워크 디자인을 순서대로 안내합니다.
1단계: 검색
탐색부터 시작하세요. Azure 인프라를 디자인하기 전에 다중 클라우드 환경을 이해합니다.
이 문서는 설계 의사결정을 위한 핵심 기준점입니다. 다중 클라우드 토폴로지 매핑: Azure 연결이 필요한 AWS VPC 및 Google Cloud VPC, 클라우드 간의 트래픽 흐름 및 규모에 맞는 아키텍처 패턴. 클라우드 공급자 간 서비스 매핑(Transit Gateway를 Virtual WAN으로, Security Groups를 Network Security Groups로, VPC 피어링을 VNet 피어링으로)을 사용하여 기존 설계를 Azure 용어로 변환하세요.
여러 개의 VPC, 지사, 리전 또는 클라우드 에지가 있는 경우 Virtual WAN이 권장되는 트랜짓 모델입니다. Virtual WAN은 자동화된 라우팅, 중앙 집중식 보안, 멀티브랜치/멀티리전 확장성을 제공하는 Azure의 AWS Transit Gateway 대응 서비스입니다. 여러 클라우드에 걸친 환경에서 Virtual WAN 도입이 타당한지, 아니면 VPN Gateway를 사용하는 더 간단한 허브 앤 스포크 구성이면 충분한지 평가합니다.
2단계: 기초
Azure VNet을 마이그레이션되거나 연결된 워크로드의 랜딩 존으로 디자인합니다. AWS VPC 및 Google Cloud VPC 개념에서 매핑: VPC 서브넷은 Azure 서브넷이 되고, 가용성 영역은 Azure 가용성 영역에 매핑되고, 경로 테이블은 유사한 패턴을 따릅니다. Azure 있는 워크로드의 서브넷 크기 조정에 집중합니다.
4. IP 주소 계획
세 클라우드에서 겹치지 않는 주소 공간을 계획합니다. 이 단계는 클라우드 간 연결에 중요합니다. Azure VNet 범위가 AWS VPC 범위 또는 Google Cloud VPC 범위와 겹치는 경우 VPN 터널을 설정할 수 없습니다. Azure 주소 공간을 할당하기 전에 모든 환경에서 사용 중인 모든 CIDR 블록을 문서화합니다.
AWS 보안 그룹 및 Google 클라우드 방화벽 규칙을 Azure NSG(네트워크 보안 그룹)로 미러링합니다. 기존 허용 및 거부 규칙을 NSG 형식으로 변환합니다. ASG(애플리케이션 보안 그룹)를 사용하여 AWS 보안 그룹 참조가 제공하는 태그 기반 그룹을 복제합니다.
3단계: 연결
6. 하이브리드 연결
암호화된 클라우드 간 전송을 위해 Azure AWS 또는 Google Cloud 간에 IPSec VPN 터널을 설정합니다. AWS Virtual Private Gateway 및 Google Cloud VPN에 Azure VPN Gateway(또는 Virtual WAN VPN 연결)를 연결합니다. 클라우드 간 트래픽 요구 사항에 따라 터널 대역폭을 선택합니다. 단일 실패 지점을 방지하기 위해 중복 터널을 계획합니다.
4단계: 보안
워크로드를 마이그레이션하기 전에 DNS 중단 전략을 계획합니다. AWS 또는 Google Cloud의 애플리케이션은 마이그레이션 후 Azure를 가리켜야 할 수 있는 호스트 이름을 확인합니다. 클라우드 간 이름 확인을 위해 아웃바운드 엔드포인트를 사용하여 Azure DNS Private Resolver를 구성합니다. 단계별 마이그레이션 지침은 이 문서의 뒷부분에 있는 DNS 컷오버 검사 목록을 참조하세요.
보안 가상 허브에 Azure Firewall 배포하여 모든 클라우드 간 및 분기 트래픽을 검사합니다. Azure AWS 또는 Google Cloud 간에 트래버스하는 모든 패킷은 로깅 및 정책 적용을 위해 방화벽을 통과합니다. 클라우드 간 트래픽 패턴 및 위협 인텔리전스 필터링에 대한 네트워크 규칙을 사용하여 알려진 악성 대상을 차단합니다.
5단계: 작업
모든 연결의 양쪽 끝을 모두 제어할 수 없기 때문에 멀티클라우드 환경에서는 문제를 진단하고 해결하기가 더 어렵습니다. 연결 테스트, VPN 터널 진단 및 패킷 캡처에 Azure Network Watcher 사용하도록 설정합니다. 용량 요구 사항에 따라 터널 가동 시간, 클라우드 간 대기 시간 및 처리량을 모니터링합니다. 클라우드 간 애플리케이션 가용성에 영향을 주는 터널 연결 끊김에 대한 경고를 설정합니다.
조건부 문서
특정 요구 사항에 따라 다음 문서를 포함합니다.
| 상태 | 조항 | 포함 시기 |
|---|---|---|
| 공용 애플리케이션 | 인터넷 인그레스 | 마이그레이션된 애플리케이션이 인터넷 연결(직접 공용 액세스 필요)입니다. |
| HTTP/HTTPS 애플리케이션 | 웹 애플리케이션 방화벽 | 공용 웹 애플리케이션에 계층 7 WAF 필요 |
| 계층 7 배포 필요 | 애플리케이션 제공 및 성능 | 마이그레이션 후 전역 또는 지역 트래픽 분산이 필요합니다. |
| 공용 엔드포인트 | DDoS 보호 | 공용 서비스에 대한 가동 시간 요구 사항이 있습니다. |
| 허브 앤드 스포크 선호 | 허브 및 스포크 토폴로지 | 멀티클라우드 환경의 규모가 작아 Virtual WAN을 도입할 정도는 아닙니다. |
| Azure 다중 지역 | 다중 지역 네트워킹 | Azure 대상은 클라우드 간 연결을 넘어 여러 지역에 걸쳐 있습니다. |
| VM 관리자 액세스 | 개발자 및 관리자 액세스 | Azure 호스팅 VM에 대한 보안 RDP/SSH 액세스가 필요합니다. |
| 중앙 집중식 송신 | 아웃바운드 인터넷 액세스 | 중앙 집중식 인터넷 아웃바운드 정책은 대상 설계의 일부입니다. |
| 대규모 VNet 환경 | 중앙 집중식 네트워크 관리 | Azure 측은 거버넌스가 적용된 다중 구독 환경으로 발전합니다. |
| PaaS 프라이빗 엔드포인트 | PaaS 프라이빗 액세스 | 대상 아키텍처에는 프라이빗 엔드포인트가 있는 Azure PaaS 서비스가 포함됩니다. |
클라우드 간 검색 검사 목록
Azure 네트워킹을 설계하기 전에 기존 클라우드 서비스를 Azure의 해당 서비스에 매핑하세요. 이 매핑은 디자인 결정을 가속화하고 일치하지 않는 기대를 방지합니다.
AWS에서 Azure 서비스 매핑
| AWS 서비스 | Azure에 해당 | Notes |
|---|---|---|
| 전송 게이트웨이 | Azure 가상 WAN | 멀티 VPC, 멀티 리전, 멀티 클라우드를 위한 중앙 집중식 라우팅 허브 |
| VPC | Azure 가상 네트워크 | 서브넷 및 경로 테이블을 사용하여 격리된 네트워크 경계 |
| VPC 피어링 | VNet 피어링 | 두 가상 네트워크 간의 직접 연결 |
| Security Groups(보안 그룹) | NSG(네트워크 보안 그룹) | 서브넷 또는 네트워크 인터페이스 수준에서 상태 저장 트래픽 필터링 |
| 네트워크 ACL | NSG(서브넷 수준) | Azure NSG는 보안 그룹과 NACL 함수를 결합합니다. |
| 가상 프라이빗 게이트웨이 | VPN 게이트웨이 | IPSec VPN 종료 지점 |
| 직접 연결 | Azure ExpressRoute | 전용 프라이빗 연결(공용 인터넷이 아님) |
| Route 53 프라이빗 호스팅 영역 | Azure 프라이빗 DNS 영역 | 가상 네트워크 내의 프라이빗 DNS 이름 확인 |
| 경로 테이블 | 사용자 정의 경로 (UDR) | Azure 시스템 경로 또는 AWS 내재 경로를 재정의하는 사용자 지정 라우팅 |
| Elastic Load Balancer(ALB/NLB) | Azure Load Balancer/Application Gateway | L4 및 L7 부하 분산; Application Gateway는 AWS WAF를 사용하여 AWS ALB와 유사한 WAF 기능을 제공합니다. |
| AWS WAF | Azure 웹 애플리케이션 방화벽 | 계층 7 HTTP/HTTPS 보호 |
| 네트워크 방화벽 | Azure Firewall | 위협 인텔리전스 기반 상태 저장 네트워크 방화벽 |
Google Cloud에서 Azure 서비스 매핑
| Google Cloud 서비스 | Azure에 해당 | Notes |
|---|---|---|
| VPC 네트워크 | Azure 가상 네트워크 | Google Cloud에서는 전역 리소스이고, Azure에서는 지역별 리소스입니다(지역 간에는 VNet 피어링 사용). |
| 클라우드 상호 연결 | Azure ExpressRoute | 전용 프라이빗 연결 |
| 클라우드 VPN | VPN 게이트웨이 | IPSec VPN 터널 |
| 클라우드 NAT | Azure NAT 게이트웨이 | 프라이빗 리소스에 대한 아웃바운드 인터넷 액세스 |
| 클라우드 라우터 | 애저 라우트 서버 (Azure Route Server) | 네트워크 가상 어플라이언스와 동적 BGP 경로 교환 |
| 클라우드 아머 | Azure 웹 애플리케이션 방화벽 | 계층 7 DDoS 및 애플리케이션 보호 |
| 방화벽 규칙 | 네트워크 보안 그룹 | 트래픽 필터링 (Google Cloud 규칙은 전역이고 Azure NSG는 서브넷별 또는 NIC별로 적용됩니다) |
| 클라우드 DNS 프라이빗 영역 | Azure 프라이빗 DNS 영역 | 네트워크 내의 개인 이름 확인 |
| 네트워크 인텔리전스 센터 | Azure Network Watcher | 네트워크 모니터링, 진단 및 토폴로지 시각화 |
DNS 컷오버 검사 목록
DNS 중단은 클라우드 간 마이그레이션에서 가장 위험 수준이 높은 단계입니다. 전환 중에 해결 실패를 최소화하려면 이 검사 목록에 따릅니다.
마이그레이션 전
- 변경되는 모든 DNS 레코드에서 TTL(Time to Live) 값을 낮추세요. TTL을 컷오버 최소 48시간 전에 60~300초로 설정합니다. 이 단계에서는 레코드를 업데이트할 때 캐시가 빠르게 만료되도록 합니다.
- 마이그레이션하는 인프라를 가리키는 모든 DNS 레코드를 문서화합니다. 서버 레코드, 서비스에 대한 CNAME 레코드, 메일용 MX 레코드 및 서비스 검색을 위한 SRV 레코드입니다.
- Azure VNet에서 아웃바운드 엔드포인트를 사용하여 Azure DNS Private Resolver를 구성합니다. 이 확인자는 공존 기간 동안 AWS/Google 클라우드 호스팅 영역에 대한 쿼리를 적절한 업스트림 DNS 서버로 전달합니다.
- 워크로드를 마이그레이션하기 전에 Azure VNet에서 AWS/Google 클라우드 호스팅 이름으로 전달 및 역방향 확인을 테스트합니다.
마이그레이션 진행 중
- Azure 이동하는 서비스에 대한 CNAME 레코드를 업데이트합니다. 각 서비스가 마이그레이션됨에 따라 CNAME이 Azure Front Door, Azure Traffic Manager 또는 Azure Application Gateway 엔드포인트를 가리키도록 설정합니다.
- 마이그레이션하는 개별 서버에 대한 호스트 A 레코드를 업데이트합니다. AWS 또는 Google Cloud IP 주소를 DNS 영역의 Azure 개인 IP 주소로 바꿉니다.
- 마이그레이션하지 않은 영역의 이름이 원래 클라우드의 DNS 서버를 통해 계속 확인되도록 조건부 전달을 활성 상태로 유지합니다.
마이그레이션 후
- 모든 위치에서 확인 검증: 온프레미스 클라이언트, Azure VNet, 그리고 남아 있는 AWS 또는 Google Cloud 워크로드 모두에서 마이그레이션된 이름을 올바르게 확인할 수 있어야 합니다.
- 안정적인 해상도를 확인한 후 TTL 값을 프로덕션 수준(3,600초 이상)으로 다시 올립니다.
- Azure DNS 완전히 마이그레이션되는 영역에 대한 조건부 전달자를 제거합니다. AWS 또는 Google Cloud에 남아 있는 영역에 대해서만 전달자를 유지합니다.
제작한 결과물
이 읽기 경로를 따라 암호화된 전송, 중앙 집중식 방화벽 검사 및 모니터링된 연결을 사용하여 기존 AWS 또는 Google Cloud 환경에 Azure 연결했습니다. 디자인에는 다음이 포함됩니다.
- 다중 클라우드 토폴로지 검색 및 서비스 매핑
- Virtual WAN 또는 허브-앤-스포크 트랜짓 아키텍처
- AWS 및 Google Cloud에 대한 IPSec VPN 터널
- 클라우드 간 트래픽 검사를 위한 Azure Firewall
- 클라우드 간 이름 확인을 위한 Private Resolver를 사용하는 DNS 컷오버
- 터널 상태 및 성능에 대한 Network Watcher 모니터링
다음 단계
- 리프트 앤 시프트 네트워킹 경로: 온-프레미스 워크로드가 Azure IaaS로 직접 마이그레이션하는 경우
- 네트워킹 경로 마이그레이션 및 현대화: Azure 배포에서 PaaS 서비스 및 컨테이너를 채택하는 경우
- 디자인 단계 한눈에 보기: Azure 네트워크 디자인의 일반적인 단계 기반 요약
- Azure 네트워킹 계획 및 디자인 개요: 사용 가능한 모든 서비스의 기능 기반 탐색