이 가이드에서는 PaaS(Platform as a Service) 서비스, 컨테이너 및 관리되는 데이터베이스를 채택하는 고객을 위한 Azure 네트워킹 디자인 가이드를 통해 시퀀싱된 읽기 경로를 제공합니다. 번호가 매겨진 단계에 따라 최신 애플리케이션 아키텍처를 지원하는 다중 계층 보안 계층 네트워크를 빌드합니다.
Overview
가상 머신을 넘어 Azure 네이티브 서비스로 프로젝트 마이그레이션 및 현대화: 컨테이너용 AKS(Azure Kubernetes Service), 웹 애플리케이션용 Azure App Service, Azure SQL Database 및 Azure Cosmos DB 관리되는 데이터 및 글로벌 트래픽 분산을 위한 Azure Front Door. 네트워크는 이러한 PaaS 서비스에 대한 비공개 연결, 다중 리전 활성-활성 배포, 그리고 애플리케이션 계층 간의 엄격한 보안 분리를 지원해야 합니다.
대상 아키텍처는 두 개의 Azure 지역에 걸쳐 있는 이중 허브 토폴로지 사용 IT 관리형 허브 VNet은 Azure Firewall 및 VPN Gateway 같은 공유 서비스를 호스트합니다. 애플리케이션 팀은 자신의 스포크 VNet을 소유하고 PaaS 연결을 위해 자체 Private Link 서브넷을 제어합니다. 트래픽은 Azure Front Door 또는 Azure Traffic Manager 통해 들어오고, 허브 방화벽 검사를 통과하며, 격리된 스포크에서 실행되는 애플리케이션 서비스에 도달합니다.
이 읽기 경로는 5단계로 구성된 14개의 필수 문서를 안내합니다. 최신 아키텍처에는 수신 패턴, 프라이빗 PaaS 연결, 웹 애플리케이션 방화벽 및 IaaS 전용 디자인이 지연할 수 있는 DDoS 보호에 대한 결정이 필요하기 때문에 경로가 리프트 앤 시프트보다 깁니다. 두 가지 중요 시점 검사점은 워크로드에 모든 구성 요소가 필요하지 않은 경우 미리 건너뛸 수 있는 시기를 식별하는 데 도움이 됩니다.
사전 요구 사항
- 사용 가능한 서비스에 대한 방향에 대한 Azure 네트워킹 계획 및 디자인 개요를 읽어보십시오.
- 애플리케이션이 대상으로 하는 PaaS 서비스(AKS, App Service, Azure SQL, Azure Cosmos DB 또는 기타)를 파악합니다.
- 배포가 여러 Azure 지역(활성-활성 또는 활성-수동)에 걸쳐 있는지 여부를 확인합니다.
- 수신 패턴을 식별합니다. 애플리케이션이 공용 웹 트래픽, 모바일 API 트래픽 또는 내부 전용 트래픽을 제공하나요?
읽기 경로
1단계: 기초
AKS 노드 풀, ASE(App Service Environment) 위임된 서브넷 및 Private Link 서브넷에 대한 서브넷 크기를 조정합니다. AKS CNI(컨테이너 네트워킹 인터페이스) 오버레이를 사용하는 경우 Pod IP 주소는 별도의 오버레이 CIDR에서 제공되며 VNet 서브넷 공간을 사용하지 않습니다. 노드 IP만 서브넷 주소가 필요합니다. Pod 규모를 수용하도록 오버레이 CIDR 범위를 계획하고 각 서비스 유형에 전용 서브넷을 할당합니다.
2. IP 주소 계획
활성-활성 배포를 위해 두 지역에 걸쳐 IP 할당을 계획합니다. 기본 및 백업 지역에는 VNet 피어링 및 지역 간 복제를 지원하는 겹치지 않는 주소 공간이 필요합니다. 향후 스포크 추가를 수용할 수 있을 만큼 큰 범위를 할당합니다.
부하 분산 장치 트래픽만 애플리케이션 서브넷에 도달할 수 있도록 엄격한 세분화를 디자인합니다. 애플리케이션 계층에 대한 직접 인터넷 액세스를 차단합니다. ASG(애플리케이션 보안 그룹)를 사용하여 개별 IP 주소 대신 워크로드 역할에 따라 규칙을 적용합니다.
2단계: 토폴로지
멀티리전을 위한 이중 허브 토폴로지를 배포합니다. IT 구독은 허브 VNet을 모두 소유하고 Azure Firewall, VPN Gateway 및 DNS 전달자와 같은 공유 서비스를 관리합니다. 애플리케이션 팀은 스포크 VNet을 소유하고 할당된 주소 공간 내에서 Private Link 서브넷, AKS 클러스터 및 애플리케이션 리소스를 관리합니다.
5. 다중 지역 네트워킹
주 및 백업 지역에서 active-active 배포를 디자인합니다. 허브 간에 지역 간 VNet 피어링을 구성하고 장애 조치(failover) 라우팅을 설정하며 단일 지역 오류에 대한 계획을 수립합니다. 두 지역 모두 대기 시간 및 상태 프로브를 기반으로 요청을 배포하는 Azure Front Door 트래픽을 동시에 제공합니다.
메모
마일스톤: 토폴로지 완료. 고객의 이중 허브 다중 지역 토폴로지가 구성되어 있습니다. 애플리케이션이 인터넷 연결 엔드포인트가 없는 내부 전용인 경우 9단계(아웃바운드 인터넷 액세스)로 건너뛰고 여기에서 계속할 수 있습니다.
건너뛰는 항목: 6~8단계에서는 인터넷 수신, 애플리케이션 배달 및 성능 및 PaaS 프라이빗 액세스를 다룹니다. 워크로드에 공용 엔드포인트가 없고 Private Link 요구 사항이 없는 경우 건너뛰는 것이 안전합니다.
중요: 내부 전용 애플리케이션도 프라이빗 엔드포인트를 통해 Azure SQL, Azure Storage, Azure Key Vault 또는 기타 PaaS 서비스에 연결하는 경우 Private Link(8단계)가 필요한 경우가 많습니다. 애플리케이션에서 이러한 서비스를 사용하는 경우 9단계로 건너뛰기 전에 8단계를 완료합니다.
남은 문서: 건너뛴 경우 6개 문서(9–14단계), 건너뛰지 않은 경우 9개 문서(6–14단계).
3단계: 연결
6. 인터넷 유입
고객 연결 트래픽 패턴은 아키텍처의 외부 모양을 결정합니다. WAF(전역 부하 분산, 캐싱 및 Web Application Firewall)가 필요한 웹 애플리케이션에 Azure Front Door 사용합니다. 상태 프로브를 사용하는 DNS 기반 라우팅으로 충분한 모바일 또는 API 애플리케이션에는 Azure Traffic Manager를 사용하세요.
애플리케이션 유형에 따라 Azure Front Door 및 Azure Traffic Manager 중에서 선택합니다. 웹 애플리케이션은 Front Door의 계층 7 기능인 TLS 오프로드, 캐싱, URL 기반 라우팅 및 통합 WAF의 이점을 활용합니다. 모바일 및 API 백 엔드는 오버헤드가 낮은 DNS 수준 장애 조치(failover)를 위해 Traffic Manager를 사용합니다.
PaaS 서비스 연결을 위해 각 스포크 VNet에 Private Link 서브넷을 만듭니다. 애플리케이션 팀은 자체 프라이빗 엔드포인트를 관리합니다. AKS는 Private Link 통해 컨테이너 이미지를 끌어오고, 웹앱은 프라이빗 엔드포인트를 통해 Azure SQL 연결하며, PaaS 트래픽이 공용 인터넷을 통과하지 않습니다. 각 스포크마다 Private Link 리소스용 서브넷을 전용으로 할당합니다.
메모
중요 시점: 연결이 완료되었습니다. 인그레스 및 프라이빗 PaaS 연결이 구성되었습니다.
나머지 단계: 총 6개 아티클에 대한 아웃바운드 송신(9단계), Azure Firewall(10단계), Web Application Firewall(11단계), DDoS 보호(12단계), DNS 보안(13단계), 네트워크 모니터링(14단계)
모든 배포에 필수: 9~10단계(아웃바운드 송신 및 Azure Firewall)는 모든 현대화 배포에 적용됩니다. 허브 방화벽은 모든 아웃바운드 트래픽을 제어하고 워크로드가 공용 또는 내부 전용인지에 관계없이 중앙 집중식 검사를 제공합니다.
퍼블릭 엔드포인트만: 11~12단계(WAF 및 DDoS 보호)는 애플리케이션이 Azure Front Door, Application Gateway 또는 공용 Load Balancer 통해 공용 엔드포인트를 노출하는 경우에만 적용됩니다. 내부 전용 워크로드는 이러한 두 문서를 건너뛰고 13단계(DNS 보안)로 진행할 수 있습니다.
UDR(User-Defined 경로)을 사용하여 모든 스포크 아웃바운드 트래픽을 허브 방화벽으로 라우팅합니다. 허브 방화벽은 모든 송신에 대한 SNAT(원본 네트워크 주소 변환) 지점 역할을 합니다. IT 팀은 방화벽 규칙을 중앙에서 관리하므로 애플리케이션 팀은 아웃바운드 컨트롤을 바이패스할 수 없습니다.
4단계: 보안
10. Azure Firewall
두 허브 VNet 모두에서 Azure Firewall을 SNAT 및 DNAT(대상 네트워크 주소 변환) 지점으로 구성합니다. 모든 수신 트래픽은 애플리케이션 계층에 도달하기 전에 방화벽을 통과합니다. 방화벽 정책을 사용하여 스포크 간 동서 트래픽과 인터넷으로의 남북 트래픽을 제어합니다.
웹 애플리케이션용 WAF를 Azure Front Door 또는 Azure Application Gateway에 배포합니다. WAF는 OWASP(Open Web Application Security Project) 상위 10개 위협, SQL 삽입, 사이트 간 스크립팅 및 기타 HTTP 계층 공격으로부터 보호합니다. 관리되는 규칙 집합을 사용하고 애플리케이션의 특정 패턴에 대한 사용자 지정 규칙을 추가합니다.
12. DDoS 보호
모든 공용 IP 리소스에 Azure DDoS Protection을 사용하도록 설정합니다. DDoS Protection은 항상 트래픽 모니터링, 자동 공격 완화 및 비용 보호 보장을 제공합니다. 볼륨 및 애플리케이션 계층 공격에 대한 계층화된 방어를 위해 DDoS Protection과 WAF를 결합합니다.
Azure Front Door 또는 Traffic Manager 엔드포인트를 가리키는 CNAME 레코드를 사용하여 고객 연결 도메인에 대한 공용 DNS 영역을 구성합니다. 권한 있는 팀만 레코드를 수정할 수 있도록 DNS 영역에 RBAC(Role-Based Access Control)를 적용합니다. 암호화 유효성 검사가 필요한 영역에 DNSSEC(DNS 보안 확장)를 사용하도록 설정합니다.
5단계: 작업
14. 네트워크 모니터링 및 관찰성
프로덕션 준비 상태의 경우 첫날부터 모니터링해야 합니다. 연결 진단에 Azure Network Watcher, 대기 시간 추적을 위한 네트워크 성능 모니터 및 트래픽 분석을 위한 흐름 로그를 사용하도록 설정합니다. 애플리케이션 팀은 자체 AKS 및 ASE 워크로드를 모니터링합니다. 플랫폼 팀은 허브 인프라 및 지역 간 연결을 모니터링합니다.
조건부 문서
특정 요구 사항에 따라 다음 문서를 포함합니다.
| 상태 | 조항 | 포함 시기 |
|---|---|---|
| 하이브리드 공존 | 하이브리드 연결 | 현대화된 애플리케이션은 전환 기간 동안 온-프레미스 시스템과 공존해야 합니다. |
| VM 관리자 액세스 필요 | 개발자 및 관리자 액세스 | 자산에는 PaaS 워크로드와 함께 보안 RDP/SSH 액세스가 필요한 VM이 포함됩니다. |
| 대규모 관리 부동산 | 중앙 집중식 네트워크 관리 | 중앙 집중식 정책 적용이 필요한 다중 구독 다중 팀 VNet 자산을 관리합니다. |
| 클라우드 간 | 지역 간 및 다중 클라우드 연결 | 아키텍처에는 다중 지역 네트워킹에서 제공하는 것 이상으로 명시적인 지역 간 프라이빗 연결이 필요합니다. |
| 매우 작은 워크로드 | 플랫 네트워크 토폴로지 | 허브 및 스포크 토폴로지의 복잡성을 정당화하지 않는 단일 워크로드가 있습니다. |
요약
이 읽기 경로에 따라 PaaS 워크로드에 대한 다중 리전 보안 계층 네트워크 아키텍처를 설계했습니다. 설계에는 IT에서 관리하는 공유 서비스가 포함된 이중 허브 토폴로지, Azure Front Door 또는 Azure Traffic Manager를 사용하는 액티브-액티브 다중 리전 구성, PaaS 서비스용 Private Link 연결, 모든 트래픽 흐름에 대한 중앙 집중식 방화벽 검사, 공용 엔드포인트용 WAF 및 DDoS 보호, 그리고 RBAC 및 DNSSEC를 사용하는 DNS가 포함됩니다. 이 아키텍처는 중앙 집중식 보안 거버넌스를 유지하면서 최신 애플리케이션 패턴을 지원합니다.
유효성 검사 목록
이 검사 목록을 사용하여 현대화 네트워킹 디자인이 완료되었는지 확인합니다.
- 주 및 백업 지역에 배포된 이중 허브 토폴로지입니다.
- 지역 및 이후 스포크 모두에 할당된 겹치지 않는 주소 공간입니다.
- 워크로드가 퍼블릭으로 노출되는 경우, 전역 인그레스를 위해 구성된 Azure Front Door 또는 Azure Traffic Manager.
- PaaS 종속성을 호스팅하는 각 스포크 VNet에 프로비저닝된 Private Link 서브넷
- 사용자 정의 경로는 스포크의 아웃바운드 트래픽이 허브 방화벽을 통과하도록 라우팅합니다.
- Azure Firewall은 인바운드, 동서 트래픽 및 아웃바운드 검사를 위해 두 허브 VNet 모두에 배포됩니다.
- 공용 웹 엔드포인트에 적용되는 WAF 정책(해당하는 경우).
- 해당되는 경우 공용 IP 리소스에서 DDoS Protection이 사용하도록 설정됩니다.
- 프라이빗 엔드포인트에 대해 구성된 DNS 영역 및 프라이빗 DNS 확인.
- Network Watcher, 흐름 로그 및 지역 간 연결 모니터링을 사용하도록 설정했습니다.
다음 단계
- 리프트 앤 시프트 네트워킹 경로: 더 간단한 마이그레이션 경로가 필요한 IaaS 워크로드도 있는 경우
- 클라우드 간 네트워킹 경로: 환경이 AWS(Amazon Web Services) 또는 Google Cloud에 연결하는 경우
- 디자인 단계 한눈에 보기: Azure 네트워크 디자인의 일반적인 단계 기반 요약
- Azure 네트워킹 계획 및 디자인 개요: 사용 가능한 모든 서비스의 기능 기반 탐색