다음을 통해 공유


Integration Services 랜딩 존 가속기를 위한 네트워크 토폴로지 및 연결 고려 사항

이 문서에서는 AIS(Azure Integration Services) 랜딩 존 가속기를 사용할 때 적용할 수 있는 네트워크 토폴로지 및 연결에 대한 디자인 고려 사항 및 권장 사항을 제공합니다. 네트워킹은 랜딩 존의 거의 모든 항목의 중심입니다.

이 아키텍처에 대한 네트워크 토폴로지 및 연결 고려 사항은 워크로드의 요구 사항과 조직의 보안 및 규정 준수 요구 사항에 따라 달라집니다.

디자인 고려 사항

조직인 경우 Virtual WAN 을 기반으로 네트워크 토폴로지를 사용합니다.

  • 여러 Azure 지역에 리소스를 배포할 계획이며 이러한 Azure 지역의 VNet(Virtual Network )과 여러 온-프레미스 위치 간에 글로벌 연결이 필요합니다.

  • 소프트웨어 정의 WAN(SD-WAN) 배포를 통해 대규모 분기 네트워크를 Azure에 직접 통합하거나 네이티브 IPsec 종료를 위해 30개 이상의 분기 사이트가 필요합니다.

  • VPN과 ExpressRoute 간의 전이적 라우팅은 사이트 간 VPN을 통해 연결된 원격 지사나 사이트 간 VPN을 통해 연결된 원격 사용자가 Azure를 통해 ExpressRoute에 연결된 DC에 연결할 필요가 있는 경우 필요합니다.

조직은 Virtual WAN을 사용하여 대규모 상호 연결 요구 사항을 충족합니다. Microsoft는 전체 네트워크 복잡성을 줄이고 조직의 네트워크를 현대화하는 데 도움이 되는 이 서비스를 관리합니다.

귀하의 조직이 허브 및 스포크 아키텍처를 중심으로 한 기존 Azure 네트워크 토폴로지를 사용하는 경우, 사용하십시오.

  • 선택한 Azure 지역에서만 리소스를 배포할 계획입니다.

  • 상호 연결된 글로벌 네트워크가 필요하지 않습니다.

  • 지역당 원격 또는 분기 위치가 거의 없으며 30개 미만의 IP 보안(IPsec) 터널이 필요합니다.

  • 구성을 완전히 제어해야 하거나 Azure 네트워크의 수동 사용자 지정 구성이 필요합니다.

참조 네트워크 토폴로지

다음 아키텍처 다이어그램은 AIS 엔터프라이즈 배포에 대한 참조 아키텍처를 보여 줍니다.

Azure Integration Services 랜딩 존 가속기 아키텍처를 보여 주는 다이어그램.

ASE(App Service Environment)를 사용하여 Logic Apps 및 Function Apps를 호스트하는 AIS 엔터프라이즈 배포는 유사하지만 2개 서비스에 대한 별도의 서브넷 대신 모든 Logic Apps 및 Function Apps를 포함하는 ASE에 대한 단일 서브넷이 있습니다.

IP 주소 지정 계획

AIS의 엔터프라이즈 배포에는 프라이빗 엔드포인트 및 VNet의 사용이 포함되어야 합니다. IP 주소 지정을 계획할 때는 다음 디자인 고려 사항을 고려해야 합니다.

  • 대부분의 PaaS(Platform-as-a-Service) 서비스에 대한 프라이빗 네트워크 수신을 사용하도록 설정하려면 프라이빗 엔드포인트가 필요합니다. 프라이빗 인그레스 기능을 활성화하면 이러한 서비스에서 공용 네트워크 액세스를 제거할 수 있습니다.

  • 일부 AIS 서비스에는 프라이빗 네트워킹을 활성화하기 위해 전용 서브넷이 필요합니다(수신의 경우에는 때로만, 송신용에는 항상).

    • API Management

    • 논리 앱

    • 지정된 서브넷을 지정된 서비스에 지정하여 서브넷 내에서 해당 서비스의 인스턴스를 만들 수 있습니다. 예를 들어 시간이 지남에 따라 더 많은 앱을 추가할 수 있도록 App Service 계획에 서브넷을 지정할 수 있습니다.

    • Azure VPN Gateway는 NAT(네트워크 주소 변환) 기능을 통해 겹치는 IP 주소 공간과 겹치는 온-프레미스 사이트를 연결할 수 있습니다.

사용자 지정 DNS

대부분의 AIS 서비스를 사용하면 고객이 자신의 DNS 서버를 사용하거나 Azure DNS 제품을 통해 퍼블릭 엔드포인트에 고유한 DNS 이름을 사용할 수 있습니다. 구성은 리소스별로 수행됩니다.

Private DNS

Azure 프라이빗 DNS 는 가상 네트워크에 대한 안정적이고 안전한 DNS 서비스를 제공합니다. Azure Private DNS는 사용자 지정 DNS 솔루션을 구성할 필요 없이 가상 네트워크의 도메인 이름을 관리하고 확인합니다.

가상 네트워크에서 프라이빗 DNS 영역의 레코드를 확인하려면 가상 네트워크를 영역과 연결해야 합니다. 연결된 가상 네트워크에는 모든 액세스 권한이 있으며 프라이빗 영역에 게시된 모든 DNS 레코드를 확인할 수 있습니다.

디자인 고려 사항

  • 프라이빗 엔드포인트 IP 주소를 리소스의 FQDN(정규화된 도메인 이름)으로 확인하도록 DNS 설정을 올바르게 구성하는 것이 중요합니다.

  • 기존 Microsoft Azure 서비스에는 공용 엔드포인트에 대한 DNS 구성이 이미 있을 수 있습니다. 이 구성은 프라이빗 엔드포인트를 사용하여 연결하도록 재정의해야 합니다.

암호화 및 인증서 인증

네트워크 디자인에 전송 중인 트래픽 및/또는 인증서 기반 인증의 암호화가 필요한 경우 이 암호화/인증이 수행되는 위치와 방법을 고려해야 할 수 있습니다. 예를 들어 TLS 종료를 수행하는 서비스를 식별해야 합니다.

디자인 고려 사항

  • 디자인에서 Azure 서비스 간의 트래픽을 암호화해야 합니까? Azure Front Door 또는 Application Gateway에서 암호화를 종료한 다음 Azure 백본을 트래버스하는 동안 또는 vNet 내에서 암호화되지 않을 수 있나요?

  • 여러 위치에서 암호화를 종료해야 합니까?

  • 여러 위치에서 인증을 처리해야 합니까, 아니면 외부 요청에 대해 한 번 수행할 수 있나요?

디자인 권장 사항

  • 엔터프라이즈 허브 및 스포크 디자인을 사용하는 경우 인터넷 기반 요청의 진입점으로 Azure Front Door를 사용하는 것이 좋습니다.

  • 인증서 인증 및/또는 SSL 종료를 위해 외부 TLS 기반 요청 또는 API Management에 대한 종료 지점으로 Azure Application Gateway를 사용하는 것이 좋습니다.

온-프레미스 리소스에 연결

많은 엔터프라이즈 통합 시나리오에서는 온-프레미스 시스템을 Azure에 연결해야 합니다. 이 연결을 제공하기 위해 권장되는 모델을 고려하는 것이 중요합니다.

디자인 고려 사항

  • Azure ExpressRoute 는 온-프레미스 위치에서 Azure IaaS(Infrastructure as a Service) 및 PaaS(Platform as a Service) 리소스에 대한 전용 프라이빗 연결을 제공합니다.

  • Azure VPN Gateway 는 공용 인터넷을 통해 온-프레미스 위치에서 Azure IaaS(Infrastructure as a Service) 가상 네트워크 리소스에 대한 S2S(사이트 간) 공유 연결을 제공합니다.

  • Azure ExpressRoute 및 Azure VPN Gateway에는 다양한 기능, 비용 및 성능이 있습니다.

  • ExpressRoute 또는 VPN Gateway가 실용적이지 않은 경우 온 -프레미스 OPDG(데이터 게이트웨이) 또는 Azure 하이브리드 연결을 사용할 수 있습니다. OPDG 및 하이브리드 연결은 모두 릴레이 서비스의 예입니다. 외부 방화벽/네트워크에서 포트를 열지 않고도 온-프레미스 네트워크에서 Azure Service Bus로 아웃바운드로 연결하여 Azure에서 요청을 받습니다.

    • OPDG는 지원하는 분당 요청 수(제한 제한)로 제한되며 특정 데이터 크기 제한이 있으며 제한된 Azure 리소스(Logic Apps, Power BI, Power Apps, Power Automate, Analysis Services)에서만 작동합니다.

    • 하이브리드 연결은 App Services(Function Apps 또는 Web Apps)에서 작동하며 자체 제한 및 크기 조정 제한이 있습니다.

    • Azure Relay 하이브리드 연결은 App Services 또는 OPDG 외부에서 릴레이를 허용하는 Service Bus의 핵심 부분입니다.

디자인 권장 사항

  • 온-프레미스 네트워크를 Azure에 연결하기 위한 기본 연결 채널로 Azure ExpressRoute 를 사용합니다.

  • 대역폭 및 성능 요구 사항에 따라 ExpressRoute 및/또는 VPN Gateway에 적합한 SKU를 사용하고 있는지 확인합니다.

  • Azure VPN Gateway 를 사용하여 분기 또는 원격 위치를 Azure에 연결합니다.

  • ExpressRoute 또는 VPN Gateway를 사용할 수 없고 처리량 제한이 문제가 되지 않으며 지원 Azure 리소스(예: Logic Apps, Function Apps)를 사용하는 경우 OPDG 및/또는 하이브리드 연결을 사용합니다.

AIS PaaS 서비스에 연결

Azure AIS PaaS 서비스는 일반적으로 퍼블릭 엔드포인트를 통해 액세스됩니다. Azure 플랫폼은 이러한 엔드포인트를 보호하거나 완전히 비공개로 만드는 기능을 제공합니다.

프라이빗 엔드포인트를 사용하여 이러한 엔드포인트를 보호합니다.

  • 대상 리소스에 대한 모든 인터넷 트래픽을 차단하려면 프라이빗 엔드포인트를 사용합니다.

  • VNet 리소스에 대한 특정 하위 리소스를 보호하려면 프라이빗 엔드포인트를 사용합니다.

  • VNet 리소스에 대한 특정 스토리지 계정을 보호하려는 경우 프라이빗 엔드포인트를 사용할 수 있습니다.

Azure Private Link 를 사용하면 가상 네트워크의 프라이빗 엔드포인트를 통해 Azure AIS Services (예: Service Bus 및 API Management) 및 Azure 호스팅 고객 소유/파트너 서비스에 액세스할 수 있습니다.

Private Link를 사용하는 경우 가상 네트워크와 서비스 간의 트래픽이 Microsoft 백본 네트워크를 트래버스하므로 더 이상 공용 인터넷에 서비스를 노출할 필요가 없습니다. 가상 네트워크에 자체 프라이빗 링크 서비스를 만들어서 고객에게 제공할 수도 있습니다. Azure Private Link를 사용한 설정 및 사용은 Azure PaaS, 고객 소유 및 공유 파트너 서비스에서 일관됩니다.

디자인 고려 사항

  • 가상 네트워크 주입은 지원되는 서비스에 대한 전용 프라이빗 배포를 제공합니다. 관리 영역 트래픽은 여전히 공용 IP 주소를 통해 흐릅니다.

  • Azure Private Link는 Azure PaaS 인스턴스에 대한 개인 IP 주소 또는 Azure Load Balancer 표준 계층 뒤에 있는 사용자 지정 서비스를 사용하여 전용 액세스를 제공합니다.

  • 기업 고객은 적절하게 완화해야 하는 PaaS 서비스의 퍼블릭 엔드포인트에 대한 우려가 있는 경우가 많습니다.

디자인 권장 사항

  • 지원되는 Azure 서비스에 가상 네트워크 주입을 사용하여 가상 네트워크 내에서 사용할 수 있도록 합니다.

  • 가상 네트워크에 삽입된 Azure PaaS 서비스는 서비스 특정 공용 IP 주소를 사용하여 관리 평면 작업을 계속 수행합니다. 서비스가 올바르게 작동하려면 연결을 보장해야 합니다.

  • 프라이빗 피어링을 사용하여 ExpressRoute를 통해 온-프레미스에서 Azure PaaS 서비스에 액세스합니다. 전용 Azure 서비스에 가상 네트워크 주입을 사용하거나 사용 가능한 공유 Azure 서비스에 Azure Private Link를 사용합니다.

  • 가상 네트워크 삽입 또는 Private Link를 사용할 수 없는 경우 온-프레미스에서 Azure PaaS 서비스에 액세스하려면 공용 인터넷을 트래버스하지 않도록 하는 Microsoft 피어링과 함께 ExpressRoute를 사용합니다.

  • Microsoft 피어링을 사용하여 ExpressRoute를 통해 온-프레미스에서 Azure PaaS 서비스에 액세스해도 PaaS 서비스의 퍼블릭 엔드포인트에 액세스할 수 없습니다. 필요에 따라 별도로 구성하고 제한해야 합니다.

  • 모든 서브넷에서 기본적으로 가상 네트워크 서비스 엔드포인트를 사용하도록 설정하지 마세요.

  • AIS PaaS 서비스에 대한 공용 액세스를 사용하지 않도록 설정합니다.

API Management용 네트워크 디자인

디자인 고려 사항

  • API가 외부에서 액세스할 수 있는지, 내부적으로 액세스할 수 있는지 또는 둘 다의 하이브리드인지 결정합니다.

  • 내부 API Management 게이트웨이 를 기본 엔드포인트로 사용할지 또는 Azure Application Gateway 또는 Azure Front Door와 같은 WAF(웹 애플리케이션 방화벽) 서비스를 사용할지 여부를 결정합니다.

  • 여러 게이트웨이를 배포해야 하는지와 부하 분산 방법을 결정합니다(예: API Management 게이트웨이 앞에서 Application Gateway 사용).

  • 온-프레미스 또는 다중 클라우드 환경에 대한 연결이 필요한지 여부를 결정합니다.

디자인 권장 사항

  • 네트워크의 백 엔드 서비스에 대한 액세스를 허용하도록 VNet 에 API Management 인스턴스를 배포합니다.

  • API Management 인스턴스가 내부 모드에서 VNet에 배포될 때 API Management에 대한 외부 액세스를 위해 Application Gateway 를 사용합니다.

  • API Management 인스턴스에 대한 프라이빗 엔드포인트를 사용하여 프라이빗 네트워크의 클라이언트가 Azure Private Link를 통해 인스턴스에 안전하게 액세스할 수 있도록 합니다.

스토리지 계정에 대한 네트워크 디자인

Azure Storage는 Azure Logic Apps 및 Azure Functions에 대한 스토리지 솔루션으로 사용됩니다.

디자인 권장 사항

  • 최상의 성능을 위해 논리 앱/함수 앱은 동일한 지역의 스토리지 계정을 사용해야 하므로 대기 시간이 줄어듭니다.

  • Azure Storage 계정에 프라이빗 엔드포인트를 사용하여 VNet(가상 네트워크)의 클라이언트가 Private Link를 통해 데이터에 안전하게 액세스할 수 있도록 합니다.

  • 각 테이블, 큐, 파일 및 Blob Storage 서비스에 대해 서로 다른 프라이빗 엔드포인트가 만들어집니다.

  • 프라이빗 엔드포인트를 프라이빗 엔드포인트용으로 예약된 자체 전용 서브넷에 배치합니다.

  • 프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다.

App Service Environment에 대한 네트워크 디자인

ASE( App Service Environment )는 App Services(웹앱), 함수 앱 및 Logic Apps(표준)를 실행하기 위한 격리된 전용 환경입니다. 귀하의 VNet에 배포되며 각 App Service 계획은 App Services, Function Apps 및 Logic Apps를 호스팅하는 데 사용됩니다.

디자인 고려 사항

  • ASE는 VNet 내의 단일 서브넷에 배포됩니다. 외부 연결에서 공용 DNS 레코드에 추가할 수 있는 공개적으로 표시되는 IP 주소를 사용할 수 있도록 하는 VIP(가상 IP 주소)를 사용하여 ASE를 배포할 수 있습니다.

  • ASE 내의 애플리케이션은 네트워크 액세스 규칙에 따라 Virtual Network 내의 다른 모든 리소스에 액세스할 수 있습니다. Virtual Network 피어링을 사용하여 다른 VNet의 리소스에 액세스할 수 있습니다.

  • ASE 내의 애플리케이션은 VNet에 속하도록 구성할 필요가 없습니다. ASE에 배포되므로 VNet 내에 자동으로 포함됩니다. 즉, 리소스별로 네트워크 액세스를 구성하는 대신 ASE 수준에서 한 번 구성할 수 있습니다.

디자인 권장 사항

  • 가능한 경우 ASE v3를 사용하면 ASE 내의 개별 리소스에 필요한 구성을 줄이면서 네트워크 유연성이 극대화됩니다. ASE v3는 영역 중복도 지원합니다.

App Service 계획에 대한 네트워크 디자인

  • 다중 테넌트 환경의 App Services는 프라이빗 또는 퍼블릭 엔드포인트를 사용하여 배포할 수 있습니다. 프라이빗 엔드포인트를 사용하여 배포하는 경우 App Service의 공개 노출을 제거할 수 있습니다. App Service의 프라이빗 엔드포인트도 인터넷을 통해 연결할 수 있어야 하는 요구 사항이 있는 경우 Application Gateway를 사용하여 앱 서비스를 노출하는 것이 좋습니다.

  • 필요한 IP 주소 수를 고려하여 아웃바운드 VNet 통합을 위해 서브넷을 신중하게 계획합니다. VNet 통합에는 전용 서브넷이 필요합니다. 서브넷 크기를 계획할 때 Azure는 각 서브넷에 5개의 IP 주소를 예약합니다 . 또한 각 계획 인스턴스에 대한 통합 서브넷에서 하나의 주소가 사용됩니다. 앱을 4개의 인스턴스로 확장하면 네 개의 주소가 사용됩니다. 크기를 확장하거나 축소하면 필요한 주소 공간이 짧은 기간 동안 두 배가 됩니다. 이는 서브넷에서 지원되는 실제 인스턴스에 영향을 줍니다.

App Service에서 온-프레미스, 프라이빗 또는 IP 제한 서비스에 연결해야 하는 경우 다음을 고려합니다.

  • 다중 테넌트 환경에서 실행하는 경우 App Service 호출은 광범위한 IP 주소에서 시작될 수 있으며 네트워킹 요구 사항을 충족하기 위해 VNet 통합이 필요할 수 있습니다.

  • API Management(APIM)와 같은 서비스는 네트워킹 경계 간의 호출을 프록시하는 데 사용할 수 있으며 필요한 경우 고정 IP를 제공할 수 있습니다.

디자인 권장 사항

  • 할당 후에는 서브넷 크기를 변경할 수 없으므로 앱이 도달할 수 있는 규모에 맞게 충분히 큰 서브넷을 사용합니다. 서브넷 용량 문제를 방지하려면 VNet 통합에 /26 접미사(64개 주소)를 사용해야 합니다.

ADF(Azure Data Factory)에 대한 네트워크 디자인

디자인 고려 사항

  • Data Factory를 온-프레미스 네트워크에 있는 데이터 원본 또는 특별히 허용되지 않는 한 모든 Azure 서비스의 액세스를 차단하도록 구성된 Azure 서비스에 연결하려면 데이터 팩터리를 대상 데이터 원본에 대한 네트워크 액세스를 제공하는 가상 네트워크와 통합하는 것이 좋습니다.

  • Data Factory는 통합 런타임이라는 별도의 환경을 사용합니다. 기본 Data Factory 런타임인 Azure 통합 런타임은 VNet과 연결되지 않으므로 가장 제한적인 방화벽으로 보호되는 데이터 원본에 연결하는 데 사용할 수 없습니다. 이러한 런타임 중 요구 사항을 가장 잘 충족하는 런타임을 고려합니다.

  • 관리되는 VNet은 시작하는 데 다소 시간이 걸리지만 일반 Azure 런타임은 거의 즉시 사용할 수 있습니다. 파이프라인을 예약하고 디버깅할 때 유의해야 할 사항입니다.

  • VNet 통합 런타임을 사용하는 SSIS 런타임을 시작하는 데 최대 30분이 걸립니다.

  • 자체 호스팅 통합 런타임은 원본에서 다른 원본으로 as-is 데이터 복사를 수행하는 복사 작업만 실행할 수 있습니다. 데이터에 대한 변환을 수행하려는 경우 Data Factory의 데이터 흐름을 사용하여 변환을 수행할 수 없습니다.

  • 관리형 프라이빗 엔드포인트 는 Azure 리소스(일반적으로 ADF의 데이터 원본)에 대한 프라이빗 링크를 설정하는 Azure Data Factory Managed Virtual Network에서 만든 프라이빗 엔드포인트입니다. Azure Data Factory는 사용자를 대신하여 이러한 프라이빗 엔드포인트를 관리합니다.

  • 프라이빗 엔드포인트는 자체 호스팅 통합 런타임에서만 Data Factory에 연결할 수 있습니다.

Logic Apps(표준)용 네트워크 디자인 - VNet 통합 앱

디자인 고려 사항

Service Bus에 대한 네트워크 디자인

디자인 고려 사항

  • 사설 DNS 영역 또는 자체 DNS 서버(DNS 포워딩 포함)를 사용하여 프라이빗 링크 리소스를 확인하도록 설정되어 있습니까?

  • IP 필터링 및 VNet은 Service Bus에 대한 프리미엄 SKU 계층에서만 지원됩니다. 프리미엄 계층이 실용적이지 않은 경우 네임스페이스에 대한 액세스를 잠그는 기본 방법으로 SAS 토큰 을 사용하는 방법을 살펴보세요.

디자인 권장 사항

  • 지원되는 모든 프로토콜(예: AMQP 및 HTTPS)에 적용되는 IP 필터링을 사용하여 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.

  • 이 네임스페이스에 대한 트래픽은 공용 네트워크 액세스를 제한하여(IP 필터링 사용) 프라이빗 엔드포인트 에 대해서만 제한되어야 합니다.

  • 프라이빗 엔드포인트를 프라이빗 엔드포인트용으로 예약된 자체 전용 서브넷에 배치합니다.

  • 프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다. Azure 내에서 신뢰할 수 있는 서비스를 사용하도록 설정하여 네임스페이스에 직접 액세스하여 방화벽을 우회하여 통합 디자인 문제를 방지합니다.

Function Apps에 대한 네트워크 디자인

디자인 고려 사항

디자인 권장 사항

  • 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.

  • Function Apps에 대한 인바운드 트래픽은 프라이빗 엔드포인트를 통해 제공됩니다. Function Apps 네트워킹 디자인을 계획할 때 프라이빗 엔드포인트 설명서를 통해 인바운드 트래픽에 대한 고려 사항을 참조하세요.

  • 프라이빗 엔드포인트를 프라이빗 엔드포인트용으로 예약된 자체 전용 서브넷에 배치합니다.

  • 논리 앱의 아웃바운드 트래픽은 VNet을 통해 흐릅니다. Function Apps 네트워킹 디자인을 계획할 때 가상 네트워크 통합 설명서를 통해 아웃바운드 트래픽에 대한 고려 사항을 참조하세요.

  • 프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다.

  • 간소화된 네트워킹 및 더 많은 크기 조정 옵션을 위해 다중 테넌트 호스팅 대신 ASE(App Service Environment) 호스팅을 고려합니다.

Azure Key Vault에 대한 네트워크 디자인

디자인 권장 사항

  • 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.

  • VNet의 유일한 액세스를 제한하기 위한 프라이빗 엔드포인트를 만듭니다.

  • 프라이빗 엔드포인트를 Key Vault용으로 예약된 전용 서브넷에 배치합니다.

  • 프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다.

Event Grid에 대한 네트워크 디자인

디자인 고려 사항

  • Private DNS 영역 또는 자체 DNS 서버(이 경우 DNS 전달)를 사용하여 PrivateLink 리소스를 해결합니까?

디자인 권장 사항

  • IP 필터링을 사용하여 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.

  • 토픽 및 도메인에 대한 트래픽은 프라이빗 엔드포인트를 통해서만 제한되어야 합니다.

  • 프라이빗 엔드포인트를 프라이빗 엔드포인트용으로 예약된 자체 전용 서브넷에 배치합니다.

  • 프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다.

Event Hubs에 대한 네트워크 디자인

디자인 고려 사항

  • 네트워크 액세스 제한은 Event Hubs의 기본 SKU 계층에서 작동하지 않습니다.

디자인 권장 사항

  • IP 필터링을 사용하여 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.

  • 서비스 엔드포인트를 사용하여 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다. VNet에서 Virtual Network 서비스 엔드포인트를 만들고 가상 네트워크 규칙을 사용하여 Event Hubs 네임스페이스에 바인딩합니다.

  • Azure 리소스를 선택하여 네임스페이스에 액세스할 수 있도록 신뢰할 수 있는 서비스 옵션을 사용하도록 설정합니다.

  • 네임스페이스로의 트래픽은 프라이빗 엔드포인트를 통해서만 제한되어야 합니다.

  • 프라이빗 엔드포인트를 프라이빗 엔드포인트용으로 예약된 자체 전용 서브넷에 배치합니다.

  • 프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다.

다음 단계

중요한 디자인 영역을 검토하여 아키텍처에 대한 전체 고려 사항 및 권장 사항을 확인합니다.