1nfratech1nfra Tech

[Azure] Private DNS Zone과 DNS Private Resolver 정리

Azure 안의 이름 해석은 VNet에 링크한 Private DNS Zone이 맡고, 온프레미스와 주고받는 이름 해석은 DNS Private Resolver가 맡습니다. 온프레미스에서 Azure 이름을 물을 때는 인바운드 엔드포인트로, Azure에서 온프레미스 이름을 물을 때는 아웃바운드 엔드포인트와 전달 규칙 집합으로 보냅니다. 두 서비스를 함께 쓰면 DNS 서버 VM을 따로 두지 않고도 하이브리드 DNS를 구성할 수 있습니다.1. Azure DNS의 기본 동작VNet의 VM은 따로 설정하지 않으면 Azure 제공 DNS인 168.63.129.16으로 질의합니다. 이 주소는 VNet 안에서만 쓸 수 있는 가상 IP라서 온프레미스에서는 직접 질의할 수 없습니다. 하이브리드 환경에서 DNS가 막히는 이유가..

[Azure] Virtual Machine Scale Sets 정리

VMSS(Virtual Machine Scale Sets)는 같은 구성의 VM을 한 모델로 묶어 부하에 따라 대수를 늘리고 줄이며, 여러 가용성 영역에 나눠 배치하는 서비스입니다. 지금 새로 만든다면 Flexible 오케스트레이션이 기본이고, 이때는 기본 아웃바운드가 없어 NAT Gateway 같은 아웃바운드 경로를 따로 준비해야 합니다. 운영에서는 자동 크기 조정, 스케일 인 정책, Rolling 업그레이드, 자동 인스턴스 복구를 함께 설정합니다.1. VMSS가 필요한 이유웹 서버 VM 몇 대를 직접 만들어 Load Balancer 뒤에 두면 처음에는 문제가 없습니다. 하지만 트래픽이 늘 때 VM을 추가하고, 이미지와 설정을 맞추고, 장애가 난 VM을 교체하는 일이 모두 수작업이 됩니다. VMSS는 이..

[Azure] Azure 부하 분산 서비스 비교

Azure의 부하 분산 서비스 네 가지는 계층(L4·DNS인지 L7인지)과 범위(한 리전인지 전 세계인지) 두 기준으로 나누면 헷갈리지 않습니다. 리전 L4는 Load Balancer, 리전 L7은 Application Gateway, 글로벌 L7은 Front Door, 글로벌 DNS는 Traffic Manager입니다. 실무에서는 하나만 쓰기보다 Front Door + Application Gateway처럼 글로벌과 리전 서비스를 겹쳐 쓰는 경우가 많습니다.1. 두 가지 기준지금까지 Load Balancer, Application Gateway, Front Door, Traffic Manager를 하나씩 정리했습니다. 이름만 보면 비슷하지만, 요청의 어디까지 보는지와 어디에서 동작하는지를 기준으로 놓으..

[Azure] Front Door와 Application Gateway 연동 정리

Front Door와 Application Gateway를 함께 쓰면 Front Door가 글로벌 분산, 캐시, 엣지 WAF를 맡고 Application Gateway가 리전 안 경로 라우팅과 VNet 백엔드 연결을 맡습니다. 연동에서 가장 중요한 것은 두 가지로, Application Gateway를 Front Door만 들어올 수 있게 잠그는 것과 원래 호스트 이름(Host 헤더)을 끝까지 유지하는 것입니다. 원본 잠금은 Premium의 Private Link가 가장 깔끔하고, Standard라면 서비스 태그와 X-Azure-FDID 헤더 검사를 함께 씁니다.1. 왜 함께 쓰나Front Door만으로도 여러 리전의 App Service 같은 PaaS 원본은 충분히 연결할 수 있습니다. 하지만 백엔드가..

[Azure] Azure WAF 정책과 규칙 정리

Azure WAF는 Application Gateway와 Front Door에 정책으로 붙어 SQL 인젝션, XSS 같은 웹 공격을 막습니다. 요청이 들어오면 사용자 지정 규칙을 먼저 평가하고, 다음으로 관리 규칙(DRS 2.2)이 이상 점수를 매겨 5점 이상이면 차단합니다. 처음에는 감지 모드로 로그를 보며 오탐을 제외한 뒤 방지 모드로 바꾸는 순서가 가장 안전합니다.1. Azure WAF가 붙는 곳Azure Firewall, NSG, WAF 역할 정리에서 WAF가 L7에서 요청 내용을 검사한다는 큰 그림을 봤습니다. 이번 글은 그 WAF를 실제로 어떻게 설정하고 운영하는지에 집중합니다. Azure WAF는 독립 리소스가 아니라 WAF 정책으로 만들어 Application Gateway나 Front D..

[Azure] Traffic Manager 정리

Traffic Manager는 DNS 응답으로 트래픽을 나누는 글로벌 부하 분산기입니다. 사용자가 도메인을 질의하면 라우팅 방식과 상태 확인 결과에 맞는 엔드포인트 주소를 돌려주고, 이후 연결은 사용자가 엔드포인트에 직접 맺습니다. 프로토콜과 위치를 가리지 않아 온프레미스까지 묶을 수 있지만, 장애 조치 속도가 DNS TTL과 클라이언트 캐시에 좌우된다는 점을 알고 써야 합니다.1. Traffic Manager란앞에서 정리한 Load Balancer, Application Gateway, Front Door는 모두 트래픽이 실제로 그 서비스를 지나갑니다. Traffic Manager는 트래픽 경로에 서지 않고 DNS 질의에만 답합니다. 온프레미스의 GSLB(Global Server Load Balanci..

[Azure] Azure Front Door 정리

Azure Front Door는 전 세계 Microsoft 엣지에서 HTTP(S) 요청을 받아 가장 가까운 정상 원본으로 보내는 글로벌 L7 부하 분산기이자 CDN입니다. Anycast로 사용자와 가까운 엣지에서 TLS를 종료하고, 캐시와 WAF를 거친 뒤 Microsoft 백본으로 원본까지 전달합니다. 지금은 Standard와 Premium을 쓰며, Private Link 원본과 관리형 WAF 규칙은 Premium에서만 됩니다.1. Front Door란앞 글의 Application Gateway는 한 리전 안에서 동작하는 L7 부하 분산기였습니다. Front Door는 같은 L7이지만 리전 밖, Microsoft 엣지(100개 넘는 도시의 118곳 이상)에서 동작합니다. 사용자는 Anycast로 가장 ..

[Azure] Application Gateway 정리

Application Gateway는 HTTP 요청의 호스트 이름과 URL 경로를 보고 백엔드를 고르는 리전 단위 L7 부하 분산기입니다. TLS 종료, 경로 기반 라우팅, 헤더 재작성, WAF를 한곳에서 처리하고, 전용 서브넷 안에서 v2 SKU로 자동 크기 조정됩니다. v1 SKU는 2026년 4월 28일에 종료되어 지금은 Standard_v2 또는 WAF_v2를 씁니다.1. Application Gateway란앞 글에서 정리한 Azure Load Balancer는 IP와 포트만 보고 패킷을 넘기는 L4 부하 분산기였습니다. Application Gateway는 클라이언트의 HTTP(S) 연결을 직접 받아 요청 내용을 읽은 뒤, 조건에 맞는 백엔드로 새 연결을 맺어 전달하는 리버스 프록시입니다. 온프..

[Azure] Azure Load Balancer 정리

Azure Load Balancer는 TCP·UDP 흐름을 백엔드 VM에 나눠 주는 L4 부하 분산기입니다. 패킷을 그대로 통과시키는 방식이라 지연이 적고, 상태 프로브로 정상 VM에만 트래픽을 보냅니다. Basic SKU는 2025년 9월 30일에 종료되어 지금은 Standard SKU를 쓰며, Standard는 NSG로 허용하지 않으면 인바운드가 막혀 있는 것이 기본입니다.1. Azure Load Balancer란Azure Load Balancer는 OSI 4계층(TCP, UDP)에서 동작하는 부하 분산 서비스입니다. 클라이언트는 Load Balancer의 프런트엔드 IP 하나로 접속하고, Load Balancer는 흐름(flow) 단위로 백엔드 풀의 VM이나 VMSS 인스턴스 중 하나를 골라 전달합..

[Azure] Hub-Spoke와 Virtual WAN 비교

Hub-Spoke는 Hub VNet에 방화벽과 게이트웨이를 직접 두고 VNet Peering과 UDR로 트래픽 경로를 설계하는 방식입니다. Virtual WAN은 Microsoft가 관리하는 가상 허브가 라우팅과 연결을 대신 맡아 여러 리전, 지점, VPN 사용자를 any-to-any로 이어 줍니다. 리전과 지점이 적고 라우팅을 세밀하게 다뤄야 하면 Hub-Spoke, 리전과 지점이 많고 운영 부담을 줄이고 싶으면 Virtual WAN이 맞습니다.1. Hub가 필요한 이유VNet Peering은 두 VNet을 잇는 가장 간단한 방법이지만 전이(transitive)되지 않습니다. Spoke A와 Hub, Hub와 Spoke B를 각각 Peering해도 Spoke A에서 Spoke B로 바로 가지 못합니다...