이 문서는 인터넷에서 애플리케이션에 연결할 수 있도록 올바른 Azure 서비스를 선택하는 데 도움이 됩니다. 공용 IP 주소, Azure Load Balancer, Application Gateway, Azure Front Door 및 Azure Traffic Manager 비교합니다. 워크로드의 프로토콜, 크기 조정 및 보안 요구 사항에 맞는 옵션을 선택합니다.
이 문서에서 다루는 내용
외부 사용자에게 서비스를 제공하는 모든 Azure 워크로드에는 인터넷 트래픽이 애플리케이션에 안전하고 안정적으로 도달하는 방법인 수신 경로가 필요합니다. 잘못된 인그레스 서비스를 선택하면 과도한 프로비저닝, 보안 취약점 또는 불필요한 복잡성이 초래됩니다. 이 문서는 외부 사용자의 인바운드 연결을 허용하는 7개의 Azure 서비스를 평가하고 해당 연결을 가상 네트워크 내의 백 엔드 리소스로 라우팅하는 데 도움이 됩니다. 프로토콜, 크기 조정, 지리 및 보안 상태와 일치하는 조합을 선택할 수 있습니다.
메모
이 문서에서는 트래픽이 인터넷에서 Azure 네트워크로 들어오는 방법에 중점을 둡니다. 애플리케이션 백 엔드에서 해당 트래픽의 균형을 맞추고 전달하는 방법(Azure Load Balancer, Application Gateway 및 Azure Front Door 대한 자세한 비교 포함)은 애플리케이션 배달 및 성능을 참조하세요.
이 문서가 필요한 사람
다음 조건 중 하나 이상이 적용되는 경우 이 문서를 참조하세요.
- 애플리케이션은 인터넷의 사용자 또는 시스템에서 인바운드 연결을 허용해야 합니다.
- 프로토콜 및 범위에 따라 공용 IP, Load Balancer, Application Gateway, Front Door 또는 Traffic Manager 중에서 선택해야 합니다.
- 웹, API 또는 TCP/UDP 워크로드에 대한 보안 공용 진입점을 디자인해야 합니다.
- 인터넷 노출을 WAF, DDoS 보호, TLS 종료 또는 지역 및 글로벌 트래픽 분산과 결합해야 합니다.
팁 (조언)
시나리오 경로를 따라가시겠습니까? 페이지 맨 위에서 시나리오를 선택하여 맞춤형 지침을 확인합니다. 다음 핵심 지침은 모든 판독기에게 적용됩니다.
리프트 앤 시프트 포커스: 마이그레이션된 앱은 인터넷에서 연결할 수 있어야 합니다. Application Gateway, Front Door 또는 더 간단한 공용 IP 접근 방식이 필요한지 평가합니다. 대부분의 리프트 앤 시프트 워크로드는 내부 전용이므로 마이그레이션된 앱이 외부 사용자에게 서비스를 제공하지 않는 경우 이 문서를 완전히 건너뛸 수 있습니다.
다음과 같은 경우 이 문서를 읽어보세요.
- 온-프레미스 웹 애플리케이션을 Azure 마이그레이션하고 있으며 공개적으로 노출하는 방법을 결정해야 합니다.
- 마이그레이션된 워크로드에 애초에 인터넷 인바운드 연결이 필요한지 여부를 평가해야 합니다.
- 마이그레이션된 애플리케이션에 대해 프로덕션 환경에서 사용할 수 있는 가장 간단한 인그레스 옵션을 이해하고 싶으신가요?
현대화 포커스: 고객 연결 트래픽 패턴은 아키텍처의 외부 모양을 결정합니다. Front Door는 웹앱을 처리하고 Traffic Manager는 모바일 및 API 앱을 처리합니다. 현대화된 PaaS 워크로드(App Service, AKS)에는 허브-스포크 보안 모델과 통합되는 잘 정의된 수신 경로가 필요합니다.
다음과 같은 경우 이 문서를 읽어보세요.
- 외부 사용자가 인터넷을 통해 액세스하는 공용 애플리케이션을 배포합니다.
- 웹 애플리케이션용 Azure Front Door와 모바일 또는 API 워크로드용 Traffic Manager 중에서 선택해야 합니다.
- 인그레스가 DNAT 대상으로서 허브 방화벽과 어떻게 통합되는지 이해하고 싶으신가요?
- WAF(웹 애플리케이션 방화벽) 또는 DDoS 보호를 사용하여 인터넷 연결 엔드포인트를 보호해야 합니다.
크로스 클라우드 관점: 마이그레이션된 앱이 외부에 공개된 경우에만 인터넷 인바운드 트래픽을 포함하세요. 많은 클라우드 간 애플리케이션은 프라이빗 전송 경로를 통해 클라우드 간에 통신하는 내부 전용 애플리케이션입니다. 워크로드가 공용인 경우(예: 다른 클라우드에서 마이그레이션된 고객 연결 웹앱) Azure 수신 경로가 필요합니다.
다음과 같은 경우 이 문서를 읽어보세요.
- 공용 애플리케이션을 AWS 또는 Google Cloud에서 Azure 마이그레이션하고 있습니다.
- 마이그레이션된 워크로드를 위해 스포크 VNet에 WAF가 있는 Application Gateway가 필요합니다.
- 클라우드 간 마이그레이션 중에 VM에 대한 직접 공용 IP 할당을 방지하려고 합니다.
Azure 서비스 및 기능
Azure는 인터넷 인바운드 트래픽을 위한 여러 서비스를 제공합니다. 각 서비스는 네트워킹 스택의 다른 계층에서 작동하며 다른 사용 사례를 제공합니다.
| 서비스 | 레이어 | Scope | 제공하는 내용 | 사용 시기 |
|---|---|---|---|---|
| 공용 IP 주소(표준 SKU) | 3 | 지역 | 직접 할당된 라우팅 가능한 IPv4 또는 IPv6 주소입니다. 기본으로서의 중복 영역. | 간단하고 트래픽이 적은 시나리오입니다. 부하 분산 장치가 없는 프로덕션에는 권장되지 않습니다. |
| Azure Load Balancer(표준, 공용) | 4(TCP/UDP) | 지역 | 백 엔드 VM에 인바운드 TCP/UDP 트래픽을 분산합니다. 영역 중복 프런트엔드. 상태 프로브는 비정상 인스턴스를 제거합니다. | 고가용성이 필요한 비 HTTP/S 워크로드. 게임 서버, IoT 엔드포인트 또는 기타 TCP/UDP 서비스. |
| Azure Load Balancer (표준, 내부) | 4(TCP/UDP) | 지역 | 가상 네트워크 내에서 계층 4 부하 분산 공용 IP가 없습니다. 내부 계층 간에 트래픽을 라우팅합니다. | 공용 프런트 엔드가 백 엔드 VM에 배포하는 다중 계층 앱. 허브-앤-스포크 동서 간 트래픽. 인터넷에 직접 노출되지는 않지만 일반적으로 퍼블릭 인그레스 서비스와 함께 사용됩니다. |
| Azure Application Gateway | 7(HTTP/S) | 지역 | URL 기반 라우팅, SSL/TLS 종료, 세션 선호도 및 자동 크기 조정을 사용한 HTTP/S 부하 분산 | 경로 기반 라우팅, 쿠키 기반 선호도 또는 SSL 오프로드가 필요한 단일 지역 HTTP/S 앱입니다. |
| Application Gateway + WAF | 7(HTTP/S) | 지역 | Web Application Firewall이 포함된 애플리케이션 게이트웨이 Microsoft 위협 인텔리전스 규칙을 포함하여 DRS(기본 규칙 집합)를 사용하여 OWASP 상위 10개 공격으로부터 보호합니다. | 단일 지역에서 계층 7 부하 분산 및 WAF 보호가 필요한 공용 웹앱 |
| Azure Front Door | 7(HTTP/S) | 전역 | 통합 CDN, WAF 및 트래픽 라우팅을 사용하는 글로벌 HTTP/S 부하 분산 장치입니다. 분할 TCP 가속을 사용하여 사용자 근처의 에지 PoP에서 TCP/TLS를 종료합니다. | 전역 사용자 기반이 있는 다중 지역 앱 CDN 캐싱, 전역 WAF 및 자동 장애 조치(failover)가 필요한 워크로드. |
| Azure 트래픽 관리자 | DNS | 전역 | DNS 기반 트래픽 라우팅. 가장 가깝거나 가장 건강한 지역 엔드포인트에 대한 CNAME을 반환합니다. 클라이언트는 직접 연결합니다. Traffic Manager는 애플리케이션 트래픽을 볼 수 없습니다. | 다중 지역 DNS 수준 장애 조치. Front Door가 적용되지 않는 비 HTTP/S 프로토콜입니다. 지리, 성능 또는 우선 순위별 라우팅 |
메모
기본 SKU 공용 IP는 사용 중지됩니다(2025년 9월). 기존 기본 IP는 계속 작동하지만 SLA 없이 지원되지 않습니다. 모든 새 배포에 표준 SKU를 사용합니다.
각 서비스의 작동 방식
각 서비스의 내부 아키텍처를 이해하면 성능을 예측하고, 문제를 해결하고, 서브넷 크기 조정을 계획할 수 있습니다.
공용 IP 주소
표준 SKU 공용 IP는 라우팅 가능한 IPv4 또는 IPv6 주소를 네트워크 인터페이스, 부하 분산 장치 프런트 엔드 또는 게이트웨이에 직접 매핑하는 소프트웨어 정의 리소스입니다. 주소는 지원되는 지역에서는 기본적으로 영역 중복 구성으로 제공되며, 즉 사용자가 별도로 변경할 필요 없이 플랫폼이 가용성 영역 간 장애 조치를 처리합니다. 공용 IP에는 트래픽 처리가 없습니다. 패킷은 상태 검사 또는 배포 논리 없이 연결된 리소스로 직접 흐릅니다.
Azure Load Balancer(표준, 공용)
표준 Load Balancer 5개의 튜플 흐름(원본 IP, 원본 포트, 대상 IP, 대상 포트, 프로토콜)에서 해시 기반 배포 알고리즘을 사용합니다. 계층 4의 데이터 경로에서 전적으로 작동하므로 연결을 종료하거나 페이로드를 검사하지 않습니다. 상태 프로브(TCP, HTTP 또는 HTTPS)는 백 엔드 인스턴스를 지속적으로 폴링하고 몇 초 내에 회전에서 비정상 인스턴스를 제거합니다. Load Balancer 자동으로 조정됩니다. 용량 계획 또는 인스턴스 크기 조정이 없습니다.
Azure Load Balancer (표준, 내부)
내부 Load Balancer 공용과 동일하게 작동하지만 가상 네트워크 서브넷의 프라이빗 프런트 엔드 IP를 사용합니다. 중간 계층 API 클러스터로 트래픽을 보내는 웹 계층과 같은 내부 계층 간에 트래픽을 분산합니다. 공용 IP가 없으므로 인터넷에 보이지 않습니다. 외부 경계 처리를 담당하는 Front Door, Application Gateway 또는 공용 Load Balancer와 같은 공용 인그레스 서비스와 함께 사용하세요.
Azure Application Gateway
Application Gateway는 가상 네트워크 서브넷에 배포된 전용 가상 어플라이언스입니다. 게이트웨이에서 TLS 연결을 종료하고, HTTP 헤더 및 URL을 검사하고, 경로 규칙, 호스트 헤더 또는 사용자 지정 상태 프로브에 따라 백 엔드 풀로 요청을 라우팅합니다. v2 SKU는 자동 크기 조정(0~125개 인스턴스) 및 영역 중복성을 지원합니다. VNet 상주이기 때문에 해당 백 엔드에서 공용 IP를 요구하지 않고도 프라이빗 백 엔드에 연결할 수 있습니다.
WAF가 포함된 애플리케이션 게이트웨이
WAF 계층을 추가하면 Application Gateway 처리 파이프라인에서 직접 OWASP 핵심 규칙 집합과 Microsoft 위협 인텔리전스 규칙을 사용하도록 설정할 수 있습니다. 모든 HTTP 요청은 라우팅 규칙에 도달하기 전에 WAF 엔진을 통과합니다. WAF는 사이트별 정책을 지원하므로 동일한 게이트웨이에서 다른 수신기 또는 호스트 조합에 대해 서로 다른 규칙 구성을 가질 수 있습니다. WAF는 검색(로그 전용) 또는 방지(블록 및 로그) 모드에서 작동합니다.
Azure Front Door
Front Door는 Microsoft 글로벌 에지 네트워크(190개 이상의 PoP(접속 지점))를 기반으로 운영됩니다. 사용자가 연결되면 TCP 핸드셰이크 및 TLS 협상은 분할 TCP를 사용하여 가장 가까운 현재 위치에서 발생합니다. PoP(접속 지점)은 오리진 서버에 대한 지속적으로 예열된 연결을 유지하므로, 사용자가 오리진에 직접 연결할 경우 겪게 되는 콜드 스타트 지연 시간을 없앱니다. Front Door는 Microsoft 백본 네트워크를 통해 가장 가까운 정상 원본으로 요청을 전달하기 전에 에지에서 계층 7 라우팅, WAF 검사, 캐싱 및 압축을 수행합니다.
Azure 트래픽 관리자
Traffic Manager는 데이터 경로에 관여하지 않는 DNS 기반 서비스입니다. 클라이언트가 Traffic Manager 호스트 이름을 확인하면 라우팅 방법(우선 순위, 가중치, 성능, 지리적, 다중값 또는 서브넷)에 따라 가장 건강하거나 가장 가까운 엔드포인트를 가리키는 CNAME을 반환합니다. Traffic Manager는 엔드포인트 상태를 지속적으로 검색하고 그에 따라 DNS 응답을 업데이트합니다. 애플리케이션 트래픽을 볼 수 없으므로 HTTP, TCP, UDP 또는 독점 프로토콜과 같은 모든 프로토콜에서 작동합니다.
비용 모델 비교
각 인그레스 서비스는 서로 다른 요금 청구 모델을 따릅니다. 이 표를 사용하여 예상 트래픽 볼륨에서 비용을 예측합니다.
| 서비스 | 청구 모델 | 주요 비용 동인 | 무료 계층 또는 포함된 기능 |
|---|---|---|---|
| 공용 IP 주소 | 시간당(연결 시) + GB당 송신 데이터 | 연결된 시간 수; 데이터 반출 요금 | 매월 처음 100GB 아웃바운드 무료(전역) |
| 표준 부하 분산 장치 (표준 Load Balancer) | 규칙별 시간당 + 처리된 GB당 | 부하 분산 규칙의 수; LB를 통해 처리된 데이터 | 없음 |
| 응용 프로그램 게이트웨이 | 인스턴스당 시간당 + 사용된 용량 단위 | 인스턴스 시간; 컴퓨팅, 연결 및 처리량 용량 단위 | 없음 |
| Application Gateway + WAF | 인스턴스당 시간당(WAF 계층 가격 책정) + 용량 단위 | Application Gateway와 동일하지만 WAF 계층 시간당 요금이 있음 | 없음 |
| Azure Front Door | 요청당 + GB당 전송량 + WAF 요청 | 라우팅 요청, 에지에서 클라이언트로 데이터 전송, WAF 규칙 평가 | 표준 계층에는 일부 기본 라우팅이 포함됩니다. |
| Azure 트래픽 관리자 | 백만 개당 DNS 쿼리 + 상태별 검사 엔드포인트 | DNS 쿼리의 볼륨; 모니터링되는 엔드포인트 수 | 처음 10억 개의 쿼리에는 계층화된 가격 책정이 있습니다. |
팁 (조언)
트래픽이 적은 워크로드(매월 100만 개 미만)의 경우 Front Door의 요청당 모델은 Application Gateway의 시간당 고정 비용보다 더 경제적일 수 있습니다. 트래픽이 증가함에 따라 시간당 모델이 더 예측 가능해집니다. 예상 처리량을 사용하여 Azure 가격 계산기를 실행하여 비교합니다.
선택 방법
다음 의사 결정 테이블을 사용하여 워크로드에 적합한 인그레스 서비스를 선택하세요. 상위 수준 의사 결정 테이블로 시작한 다음, 자세한 비교를 사용하여 선택을 확인합니다.
Application Gateway와 Front Door 및 Traffic Manager 비교
이 표에서는 가장 일반적인 세 가지 HTTP 및 HTTPS 수신 서비스 중에서 선택할 수 있습니다.
| 귀하의 필요사항 | 권장 서비스 | 이유 |
|---|---|---|
| HTTP/S 트래픽, 단일 지역, WAF 보호 | WAF가 포함된 애플리케이션 게이트웨이 | 경로 기반 라우팅 및 WAF를 사용하는 지역 계층 7 서비스입니다. 가상 네트워크 내에서 실행됩니다. |
| HTTP/S 트래픽, 다중 지역, 글로벌 사용자, CDN + WAF | Azure Front Door | 에지 POP에서 종료되는 전역 계층 7 서비스입니다. 기본 제공 CDN, WAF 및 자동 장애 조치. |
| 비 HTTP/S 프로토콜에 대한 다중 지역 라우팅 또는 DNS 수준 라우팅만 | Azure 트래픽 관리자 | 모든 프로토콜에서 작동하는 DNS 기반 라우팅입니다. 연결 종료가 없습니다. |
| 지역 VNet 바인딩 처리 요구 사항이 있는 다중 지역 HTTP/S | Application Gateway + Traffic Manager | 지역 WAF 검사를 사용하여 심층 VNet 통합 또는 지역 데이터 주권이 필요한 워크로드에 유효합니다. 대부분의 다중 지역 HTTP/S 시나리오의 경우 Front Door를 선호합니다. |
팁 (조언)
대부분의 다중Region HTTP 및 HTTPS 워크로드의 경우 Front Door는 Traffic Manager와 결합된 Application Gateway보다 선호하는 선택입니다. Front Door는 여러 지역 Application Gateway 인스턴스를 관리할 필요 없이 기본 제공 WAF, CDN 및 자동 장애 조치(failover)를 제공합니다. Application Gateway + Traffic Manager 조합은 지역 VNet 바인딩 처리가 필요한 워크로드, VNet 내에서만 액세스할 수 있는 원본 Private Link 또는 지역 데이터 주권을 의무화하는 규정 요구 사항에 대해 유효합니다.
Ingress 서비스 비교
각 서비스의 기능을 이해해야 하는 경우 이 자세한 비교를 사용합니다.
| 서비스 | 레이어 | 전역 또는 지역 | 연결 종료 | WAF 사용 가능 | 상태 확인 프로브 | 적합한 대상 |
|---|---|---|---|---|---|---|
| 공용 IP 주소 | 3 | 지역 | 아니요(VM으로 직접 연결) | No | No | HA 요구 사항 없이 개발/테스트, 단일 인스턴스 워크로드 |
| 표준 Load Balancer (공용) | 4 | 지역 | 아니요(패스스루) | No | 예(TCP, HTTP, HTTPS) | 비 HTTP 워크로드: 게임, IoT, 사용자 지정 TCP/UDP |
| 표준 부하 분산 장치(내부) | 4 | 지역 | 아니요 (패스스루) | No | 예(TCP, HTTP, HTTPS) | 공용 수신 서비스 이면의 내부 계층 |
| 응용 프로그램 게이트웨이 | 7 | 지역 | 예(TLS 종료) | 아니요(WAF 계층 추가) | 예(HTTP/S 사용자 지정) | 경로 라우팅이 있는 단일 지역 HTTP/S |
| Application Gateway + WAF | 7 | 지역 | 예(TLS 종료) | 예( DRS 규칙 세트) | 예(HTTP/S 사용자 지정) | WAF가 필요한 단일 지역 웹앱 |
| Azure Front Door | 7 | 전역 | 예(PoP에서 TCP 분할) | 예(기본 제공) | 예(HTTP/S) | 전역 가속을 사용하는 다중 지역 HTTP/S |
| Azure 트래픽 관리자 | DNS | 전역 | 아니요(DNS만 해당) | No | 예(HTTP/S, TCP) | 다중 지역 DNS 수준 페일오버, 모든 프로토콜 |
인터넷 인바운드 아키텍처
다음 다이어그램에서는 Azure 워크로드에 대한 인바운드 트래픽에 대한 일반적인 서비스 체인 패턴을 보여 줍니다. 각 패턴은 계층 7 및 계층 4 서비스를 결합하여 특정 프로토콜, 지역 범위 및 보안 태세와 일치합니다.
일반적인 인그레스 패턴
다음 패턴은 완전한 인그레스 아키텍처를 구성하기 위해 여러 서비스를 결합합니다. 프로토콜 요구 사항, 지역 범위 및 보안 상태와 일치하는 패턴을 선택합니다.
패턴 1: 에지 보안을 갖춘 글로벌 웹 애플리케이션
서비스: Front Door → Application Gateway(WAF 포함) → VM/컨테이너
시나리오: 북미, 유럽 및 아시아의 고객에게 서비스를 제공하는 SaaS 애플리케이션에는 글로벌 가속, 에지의 DDoS 보호 및 다양한 마이크로 서비스에 대한 지역 경로 기반 라우팅이 필요합니다.
Front Door는 PoP(가장 가까운 지점)에서 사용자 연결을 종료하고, 전역 WAF 규칙을 적용하고, 정적 콘텐츠를 캐시합니다. 트래픽은 Microsoft 백본을 통해 지역 Application Gateway로 라우팅되며, 이 Gateway는 URL 기반 라우팅(예: /api/*는 API 풀로, /static/*는 스토리지 백엔드로)을 수행합니다. 이 패턴은 WAF 검사 계층을 두 개 포함합니다. 하나는 에지에 있고, 다른 하나는 리전에 있습니다.
패턴 2: DNS 페일오버를 포함하는 다중 지역 비 HTTP
서비스: Traffic Manager → 표준 Load Balancer(지역별) → VM
시나리오: 한 게임 회사는 세 지역에 걸쳐 UDP 포트 7777에서 전용 게임 서버를 실행합니다. 플레이어는 가장 가까운 정상 상태의 리전에 자동으로 연결됩니다.
Traffic Manager는 성능 라우팅 방법을 사용하여 대기 시간이 가장 짧은 지역에 대한 DNS 레코드를 반환합니다. 각 지역에는 Virtual Machine Scale Set 간에 UDP 트래픽을 분산하는 표준 Load Balancer 있습니다. 상태 프로브가 지역 오류를 감지하면 Traffic Manager는 DNS를 업데이트하여 플레이어를 다음으로 가까운 지역으로 라우팅합니다.
패턴 3: WAF를 사용한 간단한 지역 웹앱
서비스: APPLICATION Gateway(WAF 포함) → VM
시나리오: 외부 파트너에게 공개되는 내부 기간계 애플리케이션. 트래픽이 보통인 단일 지역에는 OWASP 보호 및 TLS 종료가 필요합니다.
Application Gateway는 가상 네트워크 내의 단일 지역 리소스에서 경로 기반 라우팅, 세션 관리에 대한 쿠키 선호도 및 WAF 보호를 제공합니다. 이 패턴은 트래픽이 지리적으로 집중될 때 글로벌 서비스의 복잡성과 비용을 방지합니다.
패턴 4: 접근이 엄격히 제한된 프라이빗 원본 서버가 있는 Front Door
서비스: Front Door Premium → Private Link → 내부 부하 분산 장치 → 가상 머신
시나리오: 원본에 공용 IP 노출이 없어야 하는 엄격한 요구 사항이 있는 금융 서비스 애플리케이션입니다. 모든 트래픽은 공용 인터넷 구간 없이 Microsoft 백본 네트워크를 통과해야 합니다.
Front Door Premium은 Private Link 엔드포인트를 통해 원본에 연결합니다. 원본 백 엔드에는 공용 IP 주소가 없고 인터넷에 노출되지 않습니다. 이 패턴은 Front Door의 글로벌 에지 네트워크의 성능 이점과 결합된 완전 프라이빗 원본의 보안을 제공합니다.
Front Door를 사용한 다중 지역 수신
다음 다이어그램은 Azure Front Door가 전역 진입점으로 작동하여 사용자를 자동 장애 조치와 함께 가장 가까운 정상 상태의 지역 원본으로 라우팅하는 모습을 보여줍니다.
사전 요구 사항
애플리케이션을 인터넷에 노출하기 전에 다음 구성 요소가 있는지 확인합니다.
- 배포된 가상 네트워크: 백 엔드 리소스는 적절한 크기의 서브넷이 있는 Azure 가상 네트워크 내에서 실행되어야 합니다. 서브넷 계획 지침은 가상 네트워크 및 서브넷 설계를 참조하세요.
- 실행 중인 워크로드: 트래픽을 처리할 준비가 된 백 엔드 리소스(가상 머신, 컨테이너 또는 플랫폼 서비스)가 하나 이상 필요합니다.
- DNS 이름: 외부 사용자가 애플리케이션에 도달하는 데 사용하는 공용 DNS 이름입니다. Azure DNS 또는 타사 DNS 공급자를 사용할 수 있습니다.
- 인그레스 서비스용 서브넷 계획: Application Gateway에는 전용 서브넷이 필요합니다(프로덕션 환경에서는 최소 /24 권장). 표준 Load Balancer 백 엔드 인스턴스는 서브넷을 다른 리소스와 공유할 수 있습니다.
디자인 고려 사항
마이그레이션된 워크로드에 인터넷 인그레스가 필요한지 평가하세요. 많은 온-프레미스 애플리케이션은 내부 전용이며 마이그레이션 후에도 계속 유지됩니다. 인그레스가 필요한 경우 아키텍처를 단순하게 유지하세요:
- WAF가 포함된 Application Gateway는 TLS 종료 및 OWASP 보호를 제공하는 단일 리전 7계층 인그레스를 제공합니다. 이 방법은 이전에 온-프레미스 역방향 프록시 뒤에 있던 해제된 웹앱에 가장 일반적입니다.
- NSG를 사용하는 공용 IP 는 트래픽이 적은 비 HTTP 워크로드(예: 파트너가 연결하는 TCP 서비스)에 허용됩니다. NSG를 알려진 원본 IP로 제한합니다.
- 공용 IP를 VM에 직접 할당하지 않습니다. 인터넷과 백 엔드 사이에 부하 분산 장치 또는 Application Gateway를 배치합니다.
해제된 애플리케이션이 외부 사용자에게 서비스를 제공하지 않는 경우 이 문서를 건너뛰고 아웃바운드 인터넷 액세스를 계속합니다.
현대화된 워크로드는 애플리케이션 유형에 따라 각기 다른 인그레스 패턴을 갖습니다.
- 고객 대상 웹 애플리케이션(예: ContosoBiz)을 위한 Azure Front Door. Front Door는 여러 지역에 걸쳐 전역 가속, 기본 제공 WAF, CDN 캐싱 및 자동 장애 조치를 제공합니다. 활성-활성 배포에 가중 라우팅을 사용합니다.
- 모바일 및 API 애플리케이션(예: ContosoCare)에 대한 Azure Traffic Manager. Traffic Manager는 비 HTTP 프로토콜 또는 클라이언트에 직접 지역 연결이 필요한 경우 DNS 기반 라우팅을 제공합니다.
- DNAT 대상으로 허브 방화벽: 모든 수신 트래픽은 애플리케이션 계층에 도달하기 전에 허브 Azure Firewall 통과합니다. 방화벽은 DNAT(대상 NAT)를 수행하여 삭제된 트래픽을 올바른 스포크로 라우팅합니다. 이 패턴은 크러빙되지 않은 인터넷 트래픽이 중앙 집중식 보안 제어를 우회하지 않도록 합니다.
2계층 WAF 검사를 위해 각 리전에서 Front Door와 Application Gateway를 함께 사용합니다. 하나는 전역 에지에서, 다른 하나는 리전 경계에서 수행됩니다.
AWS 또는 Google Cloud에서 마이그레이션된 공용 애플리케이션의 경우 워크로드가 있는 스포크 VNet에 WAF를 사용하여 Application Gateway를 배포합니다.
- 스포크 VNet의 Application Gateway + WAF: 방지 모드에서 WAF를 사용하도록 설정된 지역 Application Gateway를 배포합니다. 이 접근 방식은 HTTP 검사를 위해 트래픽이 허브를 통과할 필요 없이 인그레스를 워크로드 가까이에 유지합니다.
- VM에 직접 공용 IP가 없습니다. 마이그레이션된 VM에 공용 IP를 직접 할당하지 마세요. 모든 인터넷 연결 트래픽은 Application Gateway를 통해 입력됩니다.
- 오리진 액세스 제한: 애플리케이션이 이전에 AWS Application Load Balancer(ALB) 또는 Google Cloud Load Balancing 뒤에서 실행되었다면, 해당 인그레스 패턴을 지역 워크로드에는 Application Gateway로, 전역 워크로드에는 Front Door로 매핑합니다.
클라우드 간 워크로드가 내부 전용인 경우(프라이빗 전송을 통해 클라우드 간 통신) 이 문서를 건너뛰고 Azure Firewall 트래픽 검사를 계속합니다.
보안 고려 사항
인터넷 인그레스는 애플리케이션으로 들어오는 관문입니다. 신뢰할 수 없는 인터넷 트래픽이 Azure 환경에 들어가는 경계입니다. 인그레스 경로를 보호하려면 다음 모범 사례를 따르세요.
공용 IP를 사용하여 VM을 직접 노출하지 마세요.
포트 80 또는 443에서 애플리케이션 트래픽을 처리하기 위해 가상 머신의 네트워크 인터페이스에 공용 IP 주소를 직접 할당하지 마세요. 대신 인터넷과 VM 간에 부하 분산 장치 또는 Application Gateway를 배치합니다. 이 방법은 다음을 제공합니다.
- 회전에서 실패한 인스턴스를 제거하는 상태 프로브
- SSL 또는 TLS 종료에 대한 단일 지점
- WAF 규칙 및 속도 제한을 적용하는 위치
- 모든 인바운드 트래픽의 중앙 집중식 로깅
Caution
VM의 공용 IP는 열려 있는 모든 포트를 인터넷에 노출합니다. VM의 네트워크 보안 그룹에 잘못 구성된 규칙이 있는 경우 공격자는 운영 체제에 직접 액세스합니다.
방지 모드에서 WAF 사용
WAF를 사용하여 Application Gateway를 배포하거나 WAF를 사용하여 Azure Front Door 경우 프로덕션 워크로드에 대한 WAF를 방지 모드로 설정합니다. 방지 모드는 애플리케이션에 도달하기 전에 악의적인 요청을 차단합니다. 검색 모드는 위협을 차단하지 않고만 기록합니다. 규칙을 조정하고 오탐을 식별하기 위해 탐지 모드는 초기 테스트 중에만 사용하세요.
WAF DRS(기본 규칙 집합)는 SQL 삽입, 사이트 간 스크립팅 및 원격 코드 실행을 포함하여 OWASP 상위 10개 공격으로부터 보호합니다. DRS에는 알려진 악성 IP 및 페이로드를 감지하는 Microsoft 위협 인텔리전스 규칙도 포함되어 있습니다.
DDoS Protection 사용
공용 리소스가 있는 모든 가상 네트워크에는 DDoS 보호가 사용하도록 설정되어 있어야 합니다. Azure DDoS 네트워크 보호는 공용 IP에 대한 적응형 튜닝, 공격 원격 분석 및 비용 보호를 제공합니다. DDoS 보호가 없으면 볼륨 공격이 수신 대역폭을 포화시키고 애플리케이션에 연결할 수 없게 만들 수 있습니다.
자세한 내용은 네트워크에 대한 DDoS 보호를 참조하세요.
심층 방어를 위해 NSG 사용
부하 분산 장치 또는 Application Gateway를 사용하는 경우에도 백 엔드 서브넷에서 네트워크 보안 그룹 규칙을 구성하여 VM에 연결할 수 있는 트래픽 원본을 제한합니다. 올바르게 구성된 NSG:
- 부하 분산 장치의 서브넷 또는 서비스 태그에서만 트래픽 허용
- 인터넷에서 백 엔드 VM으로의 직접 인바운드 트래픽 거부
- 보안 모니터링을 위해 거부된 트래픽을 기록합니다.
NSG 계획은 네트워크 보안 그룹 및 애플리케이션 보안 그룹을 참조하세요.
TLS 1.2 이상 적용
TLS 1.2 또는 TLS 1.3만 허용하도록 모든 수신 서비스를 구성합니다. 알려진 취약성이 있는 TLS 1.0 및 1.1을 사용하지 않도록 설정합니다. Application Gateway와 Front Door는 모두 TLS 정책 설정을 통해 최소 TLS 버전 구성을 지원합니다. 특정 규정 준수 요구 사항이 없는 한 사용자 지정 암호 구성 대신 Application Gateway와 같은 AppGwSslPolicy20220101 미리 정의된 정책을 사용합니다.
Front Door의 원본 서버 잠그기
Azure Front Door 사용하는 경우 Front Door에서만 트래픽을 허용하도록 원본 서버를 제한합니다. 원본 서버가 모든 소스의 트래픽을 허용하면 악의적인 행위자가 원본 서버 IP에 직접 연결하여 Front Door의 WAF를 우회할 수 있으므로, 전체 WAF 투자가 완전히 무력화될 수 있습니다.
원본 잠금은 두 가지 독립적인 확인 메커니즘을 사용합니다. 심층 방어를 위해 다음을 모두 적용합니다.
서비스 태그 제한(네트워크 계층)
서비스 태그에서만 AzureFrontDoor.Backend 인바운드 HTTP/HTTPS 트래픽을 허용하도록 원본의 NSG 또는 Azure Firewall 구성합니다. 이 서비스 태그에는 Front Door에서 원본에 연결하는 데 사용하는 모든 IP 범위가 포함됩니다. 원본이 있는 서브넷 또는 NIC에 다음 규칙을 적용합니다.
-
NSG 규칙: 우선 순위 100, 원본 = 서비스 태그
AzureFrontDoor.Backend, 대상 = 백 엔드 서브넷, 포트 = 80, 443, 작업 = 허용. - 기본 거부: 인터넷의 포트 80/443에서 인바운드 트래픽을 허용하는 다른 규칙이 없는지 확인합니다. 더 광범위한 허용 규칙을 추가하지 않는 한 NSG의 기본 DenyAllInbound 규칙은 이를 처리합니다.
모든 Azure 고객의 모든 Front Door 인스턴스가 동일한 서비스 태그 IP 범위를 공유하기 때문에 서비스 태그만으로는 충분하지 않습니다. 악의적인 행위자가 자신의 Front Door 프로필을 만들고 WAF 규칙을 우회하여 원본 IP로 라우팅할 수 있습니다.
XAzure-FDID 헤더 유효성 검사(애플리케이션 계층)
Front Door의 모든 요청에는 요청을 보낸 Front Door 인스턴스의 GUID(고유 식별자)가 포함된 헤더가 포함됩니다 X-Azure-FDID . 애플리케이션 또는 역방향 프록시에서 이 헤더를 검증하여 요청이 악의적 행위자가 아닌 사용자의 Front Door 프로필에서 전송되었는지 확인합니다.
- Front Door 프로필의 개요 페이지("Front Door ID" 필드)의 Azure 포털에서 Front Door ID를 찾습니다.
- 애플리케이션 코드 또는 웹 서버 구성에서 예상 GUID와 일치하지 않는 요청을
X-Azure-FDID거부합니다. - 헤더 값이 없거나 잘못된 요청에 대해 HTTP 403을 반환합니다.
서비스 태그(네트워크에서 Front Door가 아닌 트래픽 차단)와 헤더 유효성 검사(애플리케이션에서 다른 고객의 Front Door 트래픽 차단)를 결합하면 Front Door 인스턴스만 원본에 도달할 수 있습니다.
Private Link 원본(가장 강력한 잠금)
가장 높은 수준의 원본 격리가 필요한 워크로드의 경우 Front Door Premium은 Private Link 원본을 지원합니다. 원본에는 공용 IP 주소가 필요하지 않습니다. Front Door는 Microsoft 백본 네트워크를 통해 프라이빗 엔드포인트에 연결됩니다. 이 방법을 사용하면 원본을 공용 인터넷에서 완전히 연결할 수 없으므로 서비스 태그 규칙 또는 헤더 유효성 검사가 필요하지 않습니다.
관련된 문서
- 가상 네트워크 및 서브넷 디자인: Application Gateway 및 Load Balancer 백 엔드에 대한 서브넷 크기 조정
- 네트워크 보안 그룹 및 애플리케이션 보안 그룹: 수신 후 백 엔드 액세스를 제한하는 NSG 규칙
- 애플리케이션 전송 및 성능: 인그레스 경로가 설정된 후의 성능 튜닝
- 아웃바운드 인터넷 액세스: 수신에 대응하는 아웃바운드 측면인 송신 제어
- 보안 관리 액세스: 애플리케이션 사용자에 대한 인터넷 수신과는 별개인 관리자 액세스 패턴
- 웹 애플리케이션 방화벽: 자세한 WAF 구성 및 규칙 튜닝
- 네트워크에 대한 DDoS 보호: 모든 공용 리소스에 대한 DDoS 보호 계획
자세히 알아보기
- Azure Load Balancer는 무엇인가요?
- Azure Application Gateway는 무엇인가요?
- Azure Front Door는 무엇인가요?
- Azure Traffic Manager란?
- Azure의 공용 IP 주소
- Application Gateway의 Azure Web Application Firewall
- Azure DDoS 네트워크 보호 개요
다음 단계
팁 (조언)
직접 탐색하시겠습니까? 개요 탐색기로 돌아가서 기능별로 다음 문서를 찾습니다.
리프트 앤 시프트 과정의 다음 단계:
애플리케이션 배달 및 성능: 마이그레이션된 워크로드에 대해 계층 7 부하 분산 및 전역 배달을 추가합니다.
마이그레이션된 워크로드에 7계층 부하 분산이 필요하지 않다면 아웃바운드 인터넷 액세스로 이동하세요.
현대화 과정의 다음 단계:
애플리케이션 배달 및 성능: 고객 관련 PaaS 워크로드에 대한 글로벌 배달 및 성능을 최적화합니다.
멀티클라우드 여정의 다음 단계:
Web Application Firewall: 클라우드 자산 전반의 HTTP 계층 공격으로부터 공용 애플리케이션을 보호합니다.
워크로드에서 HTTP/HTTPS를 사용하지 않는 경우 Azure Firewall 및 트래픽 검사로 건너뜁니다.