따라서 2025년 9월 30일 이후에는 새로 만든 Azure VM에서 기본 인터넷 액세스가 작동하지 않습니다. 영향을 알고 있는 고객은 이미 워크로드를 위해 인터넷에 접속하기 위해 명시적 아웃바운드 방식으로 전환하기 시작했습니다. 이 변경 사항의 내용, 영향 및 사용할 수 있는 솔루션에 대해 여전히 확신이 서지 않는다면 이 블로그가 도움이 될 것입니다.
시나리오: VNET에서 실행되는 VM이 여러 개 있습니다. 서브넷에 할당된 사용자 정의 경로가 없고 인터넷으로 0.0.0.0/0 트래픽을 보내는 경로도 없습니다. 이 시나리오에서 VM이 인터넷에 연결하려고 하면 여전히 가능합니다. (NSG에 인터넷 바운드 차단 규칙이 없는 경우) VM의 인터넷은 Azure에서 제공하는 동적 IP를 사용합니다. 이는 새로 만든 VM에 대해 2025년 9월 30일에 작동이 중단되며 기존 VM에는 영향을 미치지 않습니다.
저는 IP를 제어하지 않고 기본적으로 인터넷 아웃바운드를 하는 것은 어차피 위험한 시나리오라고 생각합니다. 따라서 아웃바운드 인터넷 연결에 대한 일관된 동작을 위해 아래 접근 방식을 사용하는 것이 좋습니다.
해결 방법: Azure에서 제공하는 동적 공용 IP에 의존하는 대신 아래 옵션을 사용하여 명시적 아웃바운드 인터넷 통신으로 전환할 수 있습니다.
NAT 게이트웨이
Azure 방화벽 / NGFW
인스턴스 레벨 공용 IP
로드 밸런서 - 아웃바운드 규칙
Azure NAT 게이트웨이
이것은 Microsoft에서 가장 간단하고 권장하는 옵션입니다. 이 프로세스는 NAT 게이트웨이를 배포하는 것입니다. NAT GW에는 VNET이 필요하지 않습니다. 이를 최소한 하나의 서브넷에 연결하여 해당 서브넷의 아웃바운드 트래픽이 NAT 게이트웨이 서비스를 통해 이동하도록 해야 합니다. NAT 게이트웨이는 사용자가 제어하는 정적 공용 IP 또는 정적 공용 IP 접두사를 갖습니다.
Azure 방화벽 / NGFW
또 다른 선호되는 옵션은 허브 앤 스포크 아키텍처 패턴을 사용하는 것입니다. 여기서 허브 네트워크에 Azure Firewall을 배포합니다. 그리고 모든 스포크는 스포크로 작동하는 워크로드 VNET이 됩니다. 워크로드 VNET에 사용자 정의 경로가 있어 인터넷 트래픽(0.0.0.0/0)을 Azure Firewall로 가리킵니다. 최적화된 비용을 위해 비용 효율성을 제공하는 Azure Firewall의 기본 SKU 또는 표준 SKU를 배포할 수 있습니다.
다음은 Microsoft 문서에서 발췌한 허브 앤 스포크 아키텍처의 예입니다.
마찬가지로 Palo Alto, Fotigate, checkpoint 등과 같은 타사 NGFW 장치를 Hub 가상 네트워크에 둘 수 있습니다. 이러한 장치는 방화벽을 수용하고 모든 인터넷 아웃바운드 트래픽을 방화벽으로 향하게 합니다.
인스턴스 수준 공용 IP 주소
VM에 직접 공용 IP 주소를 할당할 수 있습니다. 이 접근 방식은 인스턴스 수준 공용 IP 주소로 알려져 있으며, 명시적 인터넷 아웃바운드 연결을 제공합니다. 이는 주로 Azure에서 NVA 및 NGFW 배포에 사용됩니다. 또는 DMZ 워크로드에 사용할 수 있습니다. NIC로 이동한 다음 ipconfig, -> 공용 IP 주소 할당으로 이동합니다. 이 옵션은 가장 선호되지 않는 접근 방식이며 환경에 공용 IP가 너무 많으면 노출 위험이 증가하므로 일반 워크로드에는 권장되지 않습니다.
로드 밸런서 - 아웃바운드 규칙
이 상황을 처리하는 또 다른 방법은 표준 로드 밸런서를 만든 다음 아웃바운드 규칙을 만드는 것입니다. 아웃바운드 규칙 없이 인바운드 공용 IP로만 표준 로드 밸런서를 만들면 인터넷이 작동하지 않습니다. 아웃바운드 규칙을 명시적으로 만들고 인터넷 액세스가 작동하도록 프로토콜과 SNAT 포트 수를 지정해야 합니다.
모든 작업 부하에 로드 밸런서를 사용할 수는 없지만 표준 LB와 이미 연결된 DMZ에 웹 서버가 있는 경우 아웃바운드 규칙 방식을 사용할 수 있습니다.
위의 접근 방식이 Azure에서 네트워크 아키텍처에 대한 정보에 입각한 결정을 내리고 2025년 9월 마감일 전에 필요한 조정을 수행하여 중단을 방지하는 데 도움이 되기를 바랍니다.
이 블로그에서는 Traffic Manager와 Application Gateway를 사용하여 단일 FQDN이지만 다른 포트를 사용하여 여러 SAP 애플리케이션에 액세스하는 방법을 보여드리겠습니다. 이는 프록시 역할을 하는 웹 디스패처 뒤에 여러 SAP 서버가 있는 SAP 고객에게 일반적인 시나리오입니다. Traffic Manager와 Application Gateway를 사용하면 SAP 애플리케이션에 대한 고가용성, 부하 분산 및 URL 라우팅을 달성할 수 있습니다. 또한 다른 포트에서 다른 SAP 애플리케이션에 액세스하는 데 동일한 FQDN을 사용하여 최종 사용자 경험을 간소화할 수 있습니다. 또한 재해나 DR Drill이 발생하는 경우 수동 개입 없이 사용자가 DR 지역으로 원활하게 리디렉션되어야 합니다.
이 시나리오를 설명하기 위해 Windows Server 2019와 IIS를 실행하는 Azure VM을 백엔드 서버로 사용하겠습니다(웹 디스패처라고 가정).한 VM은 포트 8443에서 S4 애플리케이션을 호스팅하고 동일한 VM은 포트 4443에서 EWM 애플리케이션을 호스팅합니다.두 웹사이트 모두 DNS에 등록된 동일한 호스트 이름 webdisp.azurequreshi.com에서 접속할 수 있습니다.또한 각 지역에 하나씩 두 개의 Application Gateway를 사용합니다.마지막으로 Traffic Manager 프로필을 사용하여 우선 순위 라우팅 방법에 따라 두 Application Gateway에 트래픽을 분산합니다.따라서 요청은 DC에만 도달합니다.DR Application Gateway에 대한 요청은 DC Application Gateway 상태 프로브가 다운된 후에만 전송됩니다.
따라서 이 시나리오에서 최종 사용자는 s4.azurequreshi.com:8443 또는 ewm.azurequreshi.com:4443과 같은 개별 URL을 사용하여 앱을 열지 않습니다. webdisp.azurequreshi.com:8443을 사용하면 S4 앱이 열립니다. 마찬가지로 webdisp.azurequreshi.com:4443을 사용하면 EWM 앱이 열립니다.
이 글에서는 위의 시나리오를 달성하는 데 도움이 되는 트래픽 관리자와 애플리케이션 게이트웨이의 설정을 공유하겠습니다. 저는 제 웹사이트를 호스팅한 더미 IIS 서버를 사용하고 있지만, 설정에서 이것을 SAP 웹 디스패처로 대체하고 애플리케이션 게이트웨이 뒤에 웹 디스패처를 호스팅할 수 있습니다.
다음 다이어그램은 아키텍처의 개요를 보여줍니다.
그럼, 웹사이트를 호스팅하는 실제 서버부터 시작해 봅시다. 아래는 IIS의 바인딩입니다. 이것은 단지 웹사이트의 데모 설정일 뿐입니다. 실제 SAP 앱은 다를 것입니다. 여기서의 의도는 s4.azurequreshi.com이라는 호스트 이름에서 4443에 호스팅된 웹사이트를 강조하는 것입니다.
마찬가지로, 아래 스크린샷은 다른 웹사이트를 보여줍니다. 동일한 것을 별도의 웹서버에 호스팅할 수도 있습니다.
애플리케이션 게이트웨이 설정:
애플리케이션 게이트웨이의 프런트엔드 IP를 확인해 보겠습니다.
이제 리스너 설정을 살펴보겠습니다.
두 웹사이트를 위한 애플리케이션 게이트웨이의 간단한 멀티 사이트 리스너. 두 리스너의 차이점은 포트입니다. 8443과 4443.
이제 백엔드 설정
유일한 변경 사항은 백엔드에서 내 웹사이트가 s4.azurequreshi.com에 호스팅되기 때문에 호스트 이름만 webdisp.azurequreshi.com 대신 s4.azurequreshi.com으로 변환한다는 것입니다.
2번째 http 설정에서도 동일한 설정을 볼 수 있습니다.
건강 탐침은 이렇게 생겼습니다.
이제 규칙 구성입니다. 아주 간단한 기본 규칙은 조정하지 않습니다.
그리고 백엔드 설정.
지금까지는 단일 IP만 유지했지만, 두 개의 다른 웹사이트에 대해 두 개의 백엔드 풀을 가질 수 있습니다. 하나는 S4용이고 다른 하나는 EWM용입니다. 또한, 애플리케이션 게이트웨이에서 백엔드 풀을 해당 규칙과 연결할 수 있습니다.
여기까지 따라왔다면, 애플리케이션 게이트웨이 URL로 웹사이트를 열 수 있고, 데스크톱에서 호스트 이름을 입력하면 해당 웹사이트로 리디렉션됩니다. 테스트를 위해 호스트 이름 webdisp.azurequreshi.com을 애플리케이션 게이트웨이 IP로 지정합니다.
남인도의 애플리케이션 게이트웨이 설정과 웹사이트 구성을 복제해야 합니다. 웹 서버를 종료하거나 Azure Site Recovery를 통해 복제할 수 있습니다.
위의 설정이 완료되면 Traffic Manager 구성을 진행할 수 있습니다.
트래픽 관리자
이는 능동/수동 DR이므로 트래픽 관리자에서 우선순위 기반 라우팅을 구성해야 합니다.
교통 관리자의 건강 상태를 살펴보세요.
이 설정으로 트래픽 관리자는 트래픽을 DC(인도 중부)로만 보냅니다. 엔드포인트가 저하되면 트래픽 관리자가 클라이언트에 DR IP 주소를 제공합니다.
마지막 단계는 URL의 CNAME을 트래픽 관리자로 설정하는 것입니다. nslookup을 실행하면 다음을 찾을 수 있습니다.
결과
웹사이트가 열리는 방식은 다음과 같습니다. 이는 SAP S4와 EWM의 구체적인 스크린샷은 아니지만 이 앱 게이트웨이와 트래픽 관리자 설정은 동일합니다.
작업을 검토하고 이 블로그 게시물을 쓰는 데 영감을 준 요구 사항을 공유해 주신 Nishant Roy에게 감사드립니다.
합병 및 인수는 흔하지만, 저는 아키텍트, 영업 및 계정 팀이 두 조직이 모두 Azure를 사용할 때 Azure 구독의 이동이 어떻게 이루어지는지에 대한 질문을 받을 때 어려움을 겪는 것을 보았습니다. 이는 동일한 Azure AD 테넌트 내에서 또는 Azure AD 테넌트 이동 간에 발생할 수 있습니다. 왜냐하면 구독이 이미 적용된 후에 우리 중 몇몇이 때때로 관련되기 때문입니다.
다양한 유형의 마이그레이션을 살펴보기 전에 Microsoft Enterprise Agreement 계층 구조를 간략히 살펴보겠습니다.
조직이 EA를 구매하면 구독을 만들고 Azure 리소스 배포를 시작할 수 있습니다. 고객은 파트너를 통해 CSP를 구매할 수 있는데, 이는 고객과 파트너 간의 관계이며 CSP가 리소스를 제어하고 배포 및 모든 기술적 문제에 대해 지원합니다. CSP 파트너는 고객을 대신하여 티켓을 만듭니다.
아래 계층 구조는 Enterprise Agreement입니다. 첫 번째 수준은 등록이고, 그 아래에서 고객은 배포를 분리하기 위해 여러 부서를 만들 수 있습니다. 부서는 하나일 수도 있고 여러 개일 수도 있습니다. 부서 아래에서 계정을 만듭니다. 계정은 모든 구독이 생성되는 컨테이너입니다. 기본적으로 계정 생성 프로세스에서 이메일 주소를 지정할 수 있습니다. 이 사람이 계정을 소유합니다. 계정을 만들 때마다 고유한 이메일 주소를 제공해야 합니다. 동일한 소유자가 있는 두 개의 EA 계정을 가질 수 없습니다.
모범 사례는 Microsoft 계정보다는 직장 및 학교 계정을 제공하는 것입니다. 사람이 조직을 떠날 때를 생각해보세요.😊
아래의 모든 시나리오를 고려해 볼 때, 마이그레이션은 두 가지 주요 유형으로 분류될 수 있습니다.
비기술적 마이그레이션: 구독에 있는 리소스에 영향을 주지 않고 백엔드에서 발생하며 다운타임이 발생하지 않습니다.
기술적 마이그레이션: 구독에 있는 전체 리소스를 평가하고 리소스를 다른 구독으로 이동하는 것이 가능한지 확인하는 작업이 포함됩니다. 각 리소스를 개별적으로 평가하고 한 리소스의 다른 리소스에 대한 종속성을 확인합니다.
이 시나리오에서 고객은 활성 EA 등록을 보유하고 있으며, 이 고객은 활성 EA 등록이 있는 Azure에 있는 다른 엔터티 B를 인수했습니다. 둘 다 Azure에 있으므로 고객 A는 엔터티 B의 Azure 배포를 인수하고 싶어할 것입니다. 고객은 Microsoft에 단일 파트너를 통해서만 지불하고 싶어할 것입니다. 따라서 이러한 이동 필요성이 발생합니다. 또한 두 번째 필요성은 여러 Azure AD 테넌트와 리소스가 단일 Azure AD 테넌트로 병합되어 고객이 단일 랜딩 존을 통해 리소스를 관리할 수 있기 때문일 수 있습니다.
제 생각에는 합병을 두 단계로 나누는 것이 좋습니다. 첫 번째는 구독(청구 전용)의 이동이고 두 번째 단계는 테넌트의 리소스 합병입니다.
1a.첫 번째 단계:
(유형: 비기술적 마이그레이션)한 등록에서 다른 등록으로 구독을 이동하는 것은 백엔드에서 발생할 수 있습니다. 이 백엔드 이동은 구독 리소스에 다운타임을 발생시키지 않습니다. 소스 구독이 이동할 대상 EA 계정을 손쉽게 사용할 수 있어야 합니다. 고객은 MS 구독 관리 팀에 지원 사례를 제기하고 이메일을 통해 필요한 승인을 제공해야 합니다. 테넌트가 동일하게 유지될 것이라고 지원 엔지니어에게 알려야 합니다.
참고: 계정 소유자에 사용되는 이메일 주소는 구독이 연결된 테넌트였습니다. 예를 들어, 이메일이 Aquib.qureshi@contoso.com인 경우 이 계정에서 생성되는 모든 구독은 contoso.com Azure AD 테넌트에 매핑됩니다.
따라서 대상 Azure AD 테넌트에서 리소스를 이동하지 않으려는 경우 지원 팀에 알려야 합니다. 이는 중요한 이유인데, 구독의 Azure AD 테넌트가 RBAC를 변경하면 구독의 Azure AD 앱 등록 및 많은 Azure AD 종속 서비스가 영향을 받을 수 있기 때문입니다.
하나의 Azure EA Enrollment에 두 개 이상의 Azure AD 테넌트가 있을 수 있다고 생각하십니까? 답은 '예'입니다. Enrollment에는 테넌트와 관련된 제한이 없습니다. 하나의 Enrollment에 여러 EA 계정이 있을 수 있으며 각 계정에는 자체 Azure AD 테넌트가 있을 수 있습니다. (다만 여러 디렉터리를 관리하기 쉽지 않으므로 선호되지는 않습니다.) 우리 시나리오에서 Entity B에는 자체 Azure AD 테넌트가 있고 Company A에도 Azure AD 테넌트가 있으며 이동 후 둘 다 단일 Azure AD Enrollment에 있습니다.
테넌트 외에 염두에 두어야 할 또 다른 사항은 소스 등록에서 구매한 예약 인스턴스입니다. 통화 A를 사용하는 RI가 있는 구독을 이전하고 대상 EA 등록이 다른 통화 B로 구매된 경우 대상 EA 등록은 동시에 여러 통화로 청구될 수 없으므로 RI가 자동으로 취소됩니다.
1b.두 번째 단계:
(유형:technicalMigration)단일 Azure AD 테넌트에서 리소스 병합. 이 단계는 청구가 마이그레이션되면 실행됩니다. 언급했듯이, 이것은 각 리소스를 평가해야 하는 기술적 마이그레이션입니다. 테넌트 변경은 여러 가지 다른 방법으로 처리할 수 있습니다. 3번 항목에서 자세히 설명하겠습니다.
2. 동일한 EA 등록 내 EA 계정 간 구독 이동:
(유형: 비기술 마이그레이션)이 시나리오는 한 EA 계정 소유자가 사임하고 모든 구독을 인수하여 다른 EA 계정으로 이동하려는 경우 발생할 수 있습니다. 이 단계는 쉽고 Azure Portal을 통해 수행할 수 있으며 MS에 지원 사례를 제기할 필요가 없습니다.
포털에 표시되는 대상 Azure AD 테넌트 확인 표시와 동일하며, 대상 Azure AD로 구독을 전송하지 않으려면 해당 표시를 선택 취소할 수 있습니다.
3. 한 테넌트에서 다른 테넌트로 Azure 구독 이동:
(유형:TechnicalMigration)테넌트를 변경해야 하는 이유는 여러 가지가 있는데, 첫째, 고객이 방화벽, WAF 및 네트워크 연결과 함께 랜딩 존을 배포했고, 고객 A Azure 배포에서 BU를 다른 관리 그룹으로 분리하여 Azure Policy를 구성했기 때문입니다. 엔터티 B가 병합됨에 따라 고객 A의 IT 팀은 현재 Azure 배포를 관리하는 것과 비슷한 방식으로 엔터티의 Azure 리소스를 관리하고자 합니다. 하지만 리소스를 단일 Azure AD 테넌트로 바로 병합해서는 안 됩니다. 테넌트를 공존시키고 더 나은 운영을 활용할 수 있는 여러 가지 방법이 있기 때문입니다. 아래에서 몇 가지 방법을 강조하겠습니다.
Azure AD 테넌트가 두 개 있다는 것은 두 개의 다른 사용자 리포지토리를 의미합니다. 고객 A 사용자가 엔터티 B의 Azure 구독을 관리하고자 할 때마다 사용자를 게스트로 초대한 다음 해당 게스트 사용자를 기여자 또는 관련 역할로 제공하여 Azure 리소스를 관리할 수 있습니다. 최근에 두 Azure AD 테넌트 간의 사용자 동기화가 출시되어 사용자를 수동으로 초대할 필요가 없고 이를 자동화할 수 있습니다.
Azure Lighthouse를 사용하면 두 개의 다른 Azure Tenant에서 Azure 배포를 운영적으로 관리할 수 있습니다. 이 주제에 대한 블로그를 작성했습니다.
엔티티 B가 허브 앤 스포크 배포 모델을 사용하는 경우 vnet 피어링을 수행하고 방화벽, WAF 등이 있는 고객 A의 허브 네트워크를 활용할 수 있습니다.
Azure AD 테넌트를 병합하고 테넌트와 리소스를 공존시키지 말아야 하는 몇 가지 이유는 다음과 같습니다. 모든 서비스가 멀티 테넌트를 지원하지는 않지만 Entity B의 Azure 배포 환경과 Azure에서 사용하는 서비스에 따라 달라지며 테넌트를 병합해야 할 필요가 있는 경우 계속 진행할 수 있습니다.
한 테넌트에서 다른 테넌트로 리소스를 이동하기로 결정했다고 가정해 보겠습니다.
이전에 언급했듯이 이 단계는 여러 가지 방법으로 실행할 수 있습니다. 리소스의 중요도에 따라 어떤 것을 선택할지 결정하게 하겠습니다.
3a.접근 방식 1(디렉토리 변경):
구독을 클릭한 다음 "디렉토리 변경"을 클릭할 수 있습니다. 이전에 언급한 대로 실행하기 전에 RBAC가 재설정되고 관리 ID 지원이 있는 리소스가 영향을 받으며 앱 등록에 Azure AD를 사용하는 서비스가 영향을 받습니다. 따라서 이 단계를 수행하기 전에 모든 유형의 리소스를 하나씩 평가한 다음 실행하세요. 실행하기 전에 영향을 받는 모든 리소스에 대한 솔루션이 있어야 합니다.
아래 Microsoft 문서에서는 영향을 받는 몇 가지 리소스를 간략하게 설명하지만 모든 리소스를 다루고 있지는 않습니다.
모든 구독 유형에서 이 디렉토리 변경 버튼이 활성화되어 있는 것은 아닙니다. CSP 구독을 사용하는 경우 이 옵션은 회색으로 표시됩니다.
고객이 가상 구독을 만든 다음 테스트하려는 리소스 유형을 배포한 다음 디렉터리 변경을 클릭하여 리소스가 작동하는지 또는 실패하는지 확인하는 것을 본 적이 있습니다.
3b.접근 방식 2(재생성):
이 옵션은 고객이 가동 중지 시간을 제어하고자 할 때 사용됩니다. 이전 방식과 마찬가지로 더미 구독에서 리소스를 평가하고 때로는 만들어야 하지만 여전히 확신이 부족하고 마이그레이션 중에 문제가 발생하는 경우가 많으며 이동 중에 문제 해결이 필요합니다. 따라서 이러한 상황을 피하기 위해 대상 Azure AD 테넌트에 바인딩된 대상 구독에서 리소스를 병렬로 다시 만든 다음 DR을 수행하는 것처럼 장애 조치를 수행할 수 있습니다. 장애 복구를 수행할 가능성이 높습니다.
3c.접근 방식 3(ASR):
이 접근 방식은 많은 사람이 이 방법을 알지 못하기 때문에 덜 채택되고 있으며, 많은 수의 VM 워크로드가 있는 경우에만 사용할 수 있습니다. ASR은 두 개의 다른 테넌트 간에 복제하는 데 사용할 수 있습니다. 소스 구독을 물리적 서버 배포로 간주하고 VNET에 어플라이언스를 배포한 다음 Entity B의 구독에 호스팅된 VM에 에이전트를 푸시합니다. VM을 고객 A의 구독으로 복제할 수 있습니다. 이는 Azure 대 Azure 시나리오의 ASR과 동일하지 않지만 해결 방법입니다.
4. CSP에서 EA로 구독 이동:
(유형:TechnicalMigration)MS 지원은 백엔드에서 구독을 옮길 수 없습니다. 일반적으로 CSP 구독은 CSP 파트너가 만든 다른 테넌트에 있으며 CSP에서 테넌트를 변경할 수 없으므로 유일한 옵션은 리소스를 다시 만들어서 이동하거나 ASR 방식 3을 사용하는 것입니다.
5. PAYG 구독을 EA로 이동:
(유형: 비기술적 마이그레이션)고객이 신용 카드로 구매한 PAYG 구독. 이 구독은 다운타임 없이 백엔드의 EA 청구에서 가져올 수 있습니다. 하지만 테넌트를 변경하려면 이전 섹션에 언급된 단계를 따라야 합니다.
6. MCA-Enterprise 구독을 EA로 이동:
(유형: 비기술 마이그레이션)MCA가 미래이기 때문에 이 접근 방식은 흔하지 않습니다. 하지만 MS 거버넌스 팀에 요청을 제기하면 MCA-Enterprise에서 EA 등록으로 이동할 수 있습니다. MS 거버넌스 팀에 연결하려면 계정 팀에 연락해야 합니다. 거버넌스 지원 팀에 정당성을 제공해야 하며 그러면 이 이동을 실행할 수 있습니다. 이것은 다운타임 없이 완전히 백엔드 이동입니다.
이것들은 주요 구독 유형이며, 인도에서 흔한 대부분의 유형을 다루었습니다. 위의 내용이 유용하고 원활한 마이그레이션에 도움이 되기를 바랍니다.
