다음을 통해 공유

Azure의 SaaS 워크로드에 대한 네트워킹

  • 아티클

네트워크는 고객이 SaaS 애플리케이션에 액세스하는 방법에 대한 백본을 제공하며 솔루션 구성 요소 간의 통신을 가능하게 합니다. 네트워크를 디자인하는 방식은 솔루션의 보안, 운영, 비용, 성능 및 안정성에 직접적인 영향을 줍니다. 클라우드 환경이 성장함에 따라 네트워킹 전략에 대한 구조화된 접근 방식이 더욱 중요해집니다.

네트워크 배포 전략 및 토폴로지 결정

SaaS 솔루션에는 고유한 네트워킹 요구 사항이 있습니다. 더 많은 고객을 온보딩하고 사용량이 증가함에 따라 네트워킹 요구 사항이 변경됩니다. IP 주소 범위와 같은 제한된 리소스로 인해 증가 처리가 어려울 수 있습니다. 네트워크 디자인은 보안 및 고객 격리에 영향을 줍니다. 네트워크 전략을 계획하면 성장을 관리하고 보안을 개선하며 운영 복잡성을 줄이는 데 도움이 됩니다.

디자인 고려 사항

  • 테넌시 모델을 기반으로 네트워크 배포 전략을 계획합니다. 네트워크 리소스를 고객 간에 공유할지, 단일 고객 전용인지 또는 조합으로 공유할지 결정합니다. 이 선택은 애플리케이션의 기능, 보안 및 고객 격리에 영향을 줍니다.

    여러 고객 간에 가상 네트워크 및 Azure Front Door 프로필과 같은 네트워킹 리소스를 공유하는 것이 일반적입니다. 이 방법은 비용 및 운영 오버헤드를 줄입니다. 또한 연결을 간소화합니다. 공유 스토리지 계정 또는 컨트롤 플레인과 같은 공유 리소스와 고객의 리소스를 쉽게 연결할 수 있습니다.

    그러나 높은 보안 및 규정 준수를 설정하려면 각 고객에 대한 전용 네트워킹 리소스가 필요할 수 있습니다. 예를 들어 고객 간에 높은 수준의 네트워크 구분을 지원하려면 가상 네트워크를 경계로 사용합니다. 모든 고객의 네트워크 리소스 수가 단일 공유 네트워크의 용량을 초과하는 경우 전용 리소스가 필요할 수 있습니다.

    즉시 및 향후 요구 사항을 고려하여 각 고객에게 필요한 네트워크 리소스 수를 계획합니다. 고객 요구 사항 및 Azure 리소스 제한으로 인해 특정 결과가 발생할 수 있습니다. 고객 소유 Azure 가상 네트워크와의 가상 네트워크 피어링에 별도의 네트워크를 사용하는 것과 같이 리소스에 따라 다른 배포 전략이 필요할 수 있습니다.

    SaaS 솔루션에서 리소스를 공유하는 방법에 대한 자세한 내용은 SaaS 워크로드에 대한 리소스 조직을 참조 하세요.

  • 네트워크 토폴로지 이해 네트워크 토폴로지의 경우 일반적으로 다음 세 가지 범주로 분류됩니다.

    • 플랫 네트워크: 분할을 위한 서브넷이 있는 격리된 단일 네트워크입니다. 간단한 네트워크 레이아웃을 사용하는 단일 다중 테넌트 애플리케이션이 있는 경우에 적합합니다. 플랫 네트워크는 리소스 한도에 도달할 수 있으며 규모에 따라 더 많은 네트워크가 필요하므로 오버헤드와 비용이 증가할 수 있습니다. 여러 애플리케이션을 호스트하거나 동일한 가상 네트워크 내에서 전용 배포 스탬프를 사용하려는 경우 복잡한 네트워크 레이아웃이 필요할 수 있습니다.

    • 허브 및 스포크: 격리된 스포크 네트워크에 대한 피어링이 있는 중앙 집중식 허브 네트워크입니다. 각 고객 또는 애플리케이션에는 허브와만 통신하는 자체 스포크가 있으므로 높은 확장성 및 고객 격리에 적합합니다. 허브의 리소스를 모든 스포크에서 사용할 수 있도록 필요에 따라 더 많은 스포크 배포를 신속하게 수행할 수 있습니다. 허브를 통한 전이적 또는 스포크 간 통신은 기본적으로 비활성화되어 SaaS 솔루션에서 고객 격리를 유지하는 데 도움이 됩니다.

    • 네트워크 없음: 가상 네트워크를 배포하지 않고 복잡한 워크로드를 호스트할 수 있는 Azure PaaS 서비스에 사용됩니다. 예를 들어 Azure 앱 Service를 사용하면 Azure 백본 네트워크를 통해 다른 PaaS 서비스와 직접 통합할 수 있습니다. 이 방법은 관리를 간소화하지만 보안 컨트롤을 배포하는 유연성과 성능을 최적화하는 기능을 제한합니다. 이 방법은 클라우드 네이티브 애플리케이션에 적합할 수 있습니다. 솔루션이 발전함에 따라 시간이 지남에 따라 허브 및 스포크 토폴로지로 전환해야 합니다.

      절충: 복잡성 및 보안. 정의된 네트워크 경계 없이 시작하면 보안 그룹, IP 주소 공간 및 방화벽과 같은 네트워크 구성 요소를 관리하는 운영 부담을 줄일 수 있습니다. 그러나 네트워크 경계는 대부분의 워크로드에 필수적입니다. 네트워크 보안 제어가 없는 경우 강력한 ID 및 액세스 관리를 사용하여 악의적인 트래픽으로부터 워크로드를 보호합니다.

  • 다중 지역 아키텍처가 네트워크 토폴로지에 미치는 영향을 이해합니다. 가상 네트워크를 사용하는 다중 지역 아키텍처에서는 방화벽, 가상 네트워크 게이트웨이 및 네트워크 보안 그룹을 지역 간에 공유할 수 없으므로 대부분의 네트워킹 리소스가 각 지역에 개별적으로 배포됩니다.

디자인 권장 사항

추천 장점
공유되는 네트워크 구성 요소와 고객 전용 구성 요소를 결정합니다.

Azure Firewall, Azure Bastion 및 Azure Front Door와 같이 인스턴스당 요금이 청구되는 리소스를 공유합니다.		 비용과 운영 부담을 줄이면서 보안 및 격리 요구 사항 간에 균형 잡힌 지원을 경험하세요.
플랫 토폴로지 또는 네트워크 접근 방식 없이 시작합니다.

이러한 접근 방식은 제한된 격리 및 트래픽 제어를 제공하므로 항상 보안 요구 사항을 먼저 검토합니다.		 더 간단한 네트워크 토폴로지를 사용하여 솔루션의 복잡성과 비용을 줄일 수 있습니다.
복잡한 요구 사항 또는 고객당 전용 가상 네트워크를 배포할 때 허브 및 스포크 토폴로지 고려 허브를 사용하여 고객 네트워크에서 공유 네트워크 리소스를 호스트합니다. 허브 네트워크를 통해 리소스를 공유하여 더 쉽게 확장하고 비용 효율성을 향상시킬 수 있습니다.

보안 네트워크 경계 디자인

네트워크 경계는 애플리케이션과 인터넷을 포함한 다른 네트워크 간에 보안 경계를 설정합니다. 네트워크 경계를 문서화하여 다양한 유형의 트래픽 흐름을 구분할 수 있습니다.

  • 외부 원본에서 네트워크에 도착하는 수신 트래픽입니다.
  • 네트워크 내의 구성 요소 간에 진행되는 내부 트래픽입니다.
  • 네트워크를 벗어나는 송신 트래픽입니다.

각 흐름에는 다양한 위험 및 제어가 포함됩니다. 예를 들어 수신 트래픽을 검사하고 처리하기 위해 여러 보안 컨트롤이 필요합니다.

Important

일반적인 모범 사례로 항상 제로 트러스트 접근 방식을 따릅니다. 내부 트래픽을 포함하여 모든 트래픽을 제어하고 검사해야 합니다.

고객은 아키텍처에 영향을 주는 특정 규정 준수 요구 사항이 있을 수도 있습니다. 예를 들어 SOC 2 규정 준수가 필요한 경우 보안 요구 사항을 충족하려면 방화벽, 웹 애플리케이션 방화벽 및 네트워크 보안 그룹을 비롯한 다양한 네트워크 제어를 구현해야 합니다. 즉시 준수할 필요가 없더라도 아키텍처를 디자인할 때 이러한 확장성 요소를 고려합니다.

네트워킹 및 연결에 대한 SE:06 권장 사항 참조

디자인 고려 사항

  • 수신 트래픽을 보호하고 관리합니다. 들어오는 위협에 대해 이 트래픽을 검사합니다.

    방화벽을 사용하면 악의적인 IP를 차단하고 고급 분석을 완료하여 침입 시도로부터 보호할 수 있습니다. 그러나 방화벽은 비용이 많이 들 수 있습니다. 보안 요구 사항을 평가하여 방화벽이 필요한지 여부를 확인합니다.

    웹 애플리케이션은 SQL 삽입, 사이트 간 스크립팅 및 기타 OWASP 상위 10개 취약성과 같은 일반적인 공격에 취약합니다. Azure Web Application Firewall은 이러한 공격으로부터 보호하고 Application Gateway 및 Azure Front Door와 통합됩니다. 이러한 서비스에 대한 계층을 검토하여 어떤 WAF 기능이 어떤 제품에 있는지 이해합니다.

    DDoS 공격은 인터넷 연결 애플리케이션에 대한 위험입니다. Azure는 기본 수준의 보호를 비용 없이 제공합니다. Azure DDoS Protection 은 트래픽 패턴을 학습하고 그에 따라 보호를 조정하여 고급 보호를 제공합니다. Front Door를 사용하는 경우 기본 제공 DDoS 기능을 활용합니다.

    보안 외에도 캐싱 및 부하 분산을 사용하여 수신 트래픽을 조작하여 애플리케이션의 성능을 향상시킬 수도 있습니다.

    글로벌 HTTP(S) 트래픽 관리를 위해 Azure Front Door와 같은 역방향 프록시 서비스를 사용하는 것이 좋습니다. 또는 인바운드 트래픽 제어에 Application Gateway 또는 기타 Azure 서비스를 사용합니다. Azure의 부하 분산 옵션에 대한 자세한 내용은 부하 분산 옵션을 참조 하세요.

  • 내부 트래픽을 보호합니다. 악의적인 액세스를 방지하기 위해 애플리케이션과 해당 구성 요소 간의 트래픽이 안전한지 확인합니다. 인터넷을 통해 라우팅하는 대신 내부 트래픽을 사용하여 이러한 리소스를 보호하고 성능을 향상시킵니다. Azure Private Link는 일반적으로 네트워크 내의 내부 IP 주소를 통해 Azure 리소스에 연결하는 데 사용됩니다. 일부 리소스 유형의 경우 서비스 엔드포인트가 보다 비용 효율적인 대안이 될 수 있습니다. 리소스에 공용 인터넷 연결을 사용하도록 설정하는 경우 관리 ID와 같은 IP 주소 및 애플리케이션 ID를 사용하여 트래픽을 제한하는 방법을 이해합니다.

  • 송신 트래픽을 보호합니다. 일부 솔루션에서는 특히 규정 준수 및 엔터프라이즈 고객을 위해 아웃바운드 트래픽을 검사하여 데이터 반출을 방지합니다. 방화벽을 사용하여 송신 트래픽을 관리하고 검토하여 권한이 없는 위치에 대한 연결을 차단합니다.

  • 아웃바운드 연결 및 SNAT를 확장하는 방법을 계획합니다. SNAT(원본 네트워크 주소 변환) 포트 고갈은 다중 테넌트 애플리케이션에 영향을 줄 수 있습니다. 이러한 애플리케이션은 종종 각 테넌트에 대해 고유한 네트워크 연결이 필요하며 고객 간에 리소스를 공유하면 고객 기반이 증가함에 따라 SNAT 소모 위험이 증가합니다. Azure NAT 게이트웨이, Azure Firewall과 같은 방화벽 또는 두 가지 방법의 조합을 사용하여 SNAT 고갈을 완화할 수 있습니다.

디자인 권장 사항

추천 장점
인터넷에 노출되는 네트워크 엔드포인트의 카탈로그를 유지 관리합니다. IP 주소(정적 경우), 호스트 이름, 포트, 사용된 프로토콜 및 연결에 대한 근거와 같은 세부 정보를 캡처합니다.

각 엔드포인트를 보호하는 방법을 문서화합니다.		 이 목록은 경계 정의의 기초를 형성하므로 솔루션을 통해 트래픽 관리에 대한 명시적 결정을 내릴 수 있습니다.
액세스를 제한하고 보호를 강화하는 Azure 서비스 기능을 이해합니다.

예를 들어 고객에게 스토리지 계정 엔드포인트를 노출하려면 공유 액세스 서명, 스토리지 계정 방화벽과 같은 추가 제어가 필요하며 내부 및 외부 사용을 위해 별도의 스토리지 계정을 사용해야 합니다.		 보안, 비용 및 성능 요구 사항을 충족하는 컨트롤을 선택할 수 있습니다.
HTTP(S) 기반 애플리케이션의 경우 Azure Front Door 또는 Application Gateway와 같은 역방향 프록시를 사용합니다. 역방향 프록시는 성능 향상, 복원력, 보안 및 운영 복잡성을 줄이기 위한 광범위한 기능을 제공합니다.
웹 애플리케이션 방화벽을 사용하여 수신 트래픽을 검사합니다.

App Service 또는 AKS(Azure Kubernetes Service)와 같은 웹 기반 리소스를 인터넷에 직접 노출하지 마세요.		 일반적인 위협으로부터 웹 애플리케이션을 보다 효과적으로 보호하고 솔루션의 전반적인 노출을 줄일 수 있습니다.
DDoS 공격으로부터 애플리케이션을 보호합니다.

퍼블릭 엔드포인트에서 사용하는 프로토콜에 따라 Azure Front Door 또는 Azure DDoS Protection을 사용합니다.		 일반적인 유형의 공격으로부터 솔루션을 보호합니다.
애플리케이션에 대규모 송신 연결이 필요한 경우 NAT 게이트웨이 또는 방화벽을 사용하여 추가 SNAT 포트를 제공합니다. 더 높은 수준의 규모를 지원할 수 있습니다.

네트워크 간 연결

일부 시나리오에서는 고객의 프라이빗 네트워크 내 데이터 또는 다중 클라우드 설정의 다른 클라우드 공급자에 있는 자산과 같이 Azure 외부의 리소스에 연결해야 할 수 있습니다. 이러한 요구 사항은 네트워크 디자인을 복잡하게 만들 수 있으며, 특정 요구 사항에 따라 네트워크 간 연결을 구현하기 위한 다양한 접근 방식이 필요합니다.

디자인 고려 사항

  • 애플리케이션에 연결이 필요한 엔드포인트를 식별합니다. 애플리케이션은 스토리지 서비스 및 데이터베이스와 같은 다른 서비스와 통신해야 할 수 있습니다. 소유자, 위치 및 연결 유형을 문서화합니다. 그런 다음 적절한 방법을 선택하여 이러한 엔드포인트에 연결할 수 있습니다. 일반적인 방법은 다음과 같습니다.

    리소스 위치 담당자 고려할 연결 옵션
    Azure 고객
    • 프라이빗 엔드포인트(Microsoft Entra ID 테넌트 간)
    • 가상 네트워크 피어링(Microsoft Entra ID 테넌트 간)
    • 서비스 엔드포인트(Microsoft Entra ID 테넌트 간)
    기타 클라우드 공급자 ISV 또는 고객
    • 사이트 간 VPN
    • ExpressRoute
    • 인터넷
    온-프레미스 ISV 또는 고객
    • 사이트 간 VPN
    • ExpressRoute
    • 인터넷

    • Private Link 및 프라이빗 엔드포인트. 가상 머신에 대한 내부 부하 분산 장치를 포함하여 다양한 Azure 리소스에 대한 보안 연결을 제공합니다. 비용을 고려해도 고객을 위해 SaaS 솔루션에 대한 프라이빗 액세스를 사용할 수 있습니다.

      절충: 보안 및 비용. 프라이빗 링크는 트래픽이 프라이빗 네트워크 내에 유지되도록 하며 Microsoft Entra 테넌트 간 네트워크 연결에 권장됩니다. 그러나 각 프라이빗 엔드포인트에는 보안 요구 사항에 따라 추가될 수 있는 비용이 발생합니다. 서비스 엔드포인트는 일정 수준의 프라이빗 연결을 제공하면서 Microsoft 백본 네트워크에서 트래픽을 유지하는 비용 효율적인 대안이 될 수 있습니다.

    • 서비스 엔드포인트입니다. Microsoft의 백본 네트워크를 통해 PaaS 리소스로 트래픽을 라우팅하여 서비스 간 통신을 보호합니다. 높은 대역폭 애플리케이션에 대해 비용 효율적일 수 있지만 보안을 위해 액세스 제어 목록을 구성하고 유지 관리해야 합니다. Microsoft Entra ID 테넌트에서 서비스 엔드포인트에 대한 지원은 Azure 서비스에 따라 다릅니다. 사용하는 각 서비스에 대한 제품 설명서를 확인합니다.

    • 가상 네트워크 피어링 이 두 개의 가상 네트워크를 연결하여 한 네트워크의 리소스가 다른 네트워크의 IP 주소에 액세스할 수 있도록 합니다. Azure 가상 네트워크의 프라이빗 리소스에 쉽게 연결할 수 있습니다. 네트워크 보안 그룹을 사용하여 액세스를 관리할 수 있지만 격리를 적용하는 것은 어려울 수 있습니다. 따라서 특정 고객 요구에 따라 네트워크 토폴로지 계획을 세우는 것이 중요합니다.

    • VPN(가상 사설망) 은 클라우드 공급자 및 온-프레미스 위치를 포함하여 두 네트워크 간에 인터넷을 통해 보안 터널을 만듭니다. 사이트간 VPN은 구성을 위해 각 네트워크의 네트워크 어플라이언스를 사용합니다. 저렴한 연결 옵션을 제공하지만 설정이 필요하며 예측 가능한 처리량을 보장하지는 않습니다.

    • ExpressRoute 는 Azure와 다른 클라우드 공급자 또는 온-프레미스 네트워크 간의 전용 고성능 프라이빗 연결을 제공합니다. 예측 가능한 성능을 보장하고 인터넷 트래픽을 방지하지만 비용이 더 많이 들고 더 복잡한 구성이 필요합니다.

  • 대상에 따라 계획합니다. 특히 대상 리소스가 고객의 Azure 구독에 있는 경우 다른 Microsoft Entra ID 테넌트의 리소스에 연결해야 할 수 있습니다. 프라이빗 엔드포인트, 사이트 간 VPN 또는 가상 네트워크를 피어링하여 사용하는 것이 좋습니다. 자세한 내용은 다른 Microsoft Entra ID 테넌트에 있는 피어링 가상 네트워크를 참조하세요.

    다른 클라우드 공급자에서 호스트되는 리소스에 연결하려면 공용 인터넷 연결, 사이트 간 VPN 또는 ExpressRoute를 사용하는 것이 일반적입니다. 자세한 내용은 다른 클라우드 공급자에 연결을 참조하세요.

  • 연결이 네트워크 토폴로지에서 미치는 영향을 이해합니다. Azure 가상 네트워크에는 사이트간 VPN 또는 ExpressRoute를 통해 여러 위치에 연결할 수 있는 하나의 가상 네트워크 게이트웨이만 있을 수 있습니다. 그러나 게이트웨이를 통한 연결 수에는 제한이 있으며 고객 트래픽을 격리하는 것은 어려울 수 있습니다. 여러 위치에 대한 여러 연결의 경우 각 고객에 대해 별도의 가상 네트워크를 배포하여 그에 따라 네트워크 토폴로지 계획을 세워야 합니다.

  • IP 주소 계획에 대한 의미를 이해합니다. 일부 연결 방법은 NAT(네트워크 주소 변환)를 자동으로 제공하여 IP 주소가 겹치는 문제를 방지합니다. 그러나 가상 네트워크 피어링 및 ExpressRoute는 NAT를 수행하지 않습니다. 이러한 방법을 사용하는 경우 겹치는 IP 주소 범위를 방지하고 향후 성장을 보장하기 위해 네트워크 리소스 및 IP 주소 할당을 신중하게 계획합니다. IP 주소 계획은 복잡할 수 있으며, 특히 고객과 같은 타사에 연결하는 경우 IP 범위와의 잠재적 충돌을 고려하세요.

  • 네트워크 송신 청구를 이해합니다. 일반적으로 Azure는 Microsoft 네트워크를 벗어나거나 Azure 지역 간에 이동할 때 아웃바운드 네트워크 트래픽에 대한 요금을 청구합니다. 다중 지역 또는 다중 클라우드 솔루션을 디자인할 때 비용 영향을 이해하는 것이 중요합니다. Azure Front Door 또는 ExpressRoute 사용과 같은 아키텍처 선택은 네트워크 트래픽에 대한 요금이 청구되는 방식에 영향을 줄 수 있습니다.

디자인 권장 사항

추천 장점
보안 우선 순위를 지정하기 위해 네트워크를 통해 연결하기 위한 프라이빗 네트워킹 방법을 선호합니다.

연결된 보안 및 성능 영향을 평가한 후에만 인터넷을 통해 라우팅하는 것이 좋습니다.		 프라이빗 트래픽은 보안 네트워크 경로를 트래버스하므로 다양한 유형의 보안 위험을 줄일 수 있습니다.
Azure 환경에서 호스트되는 고객 리소스에 연결할 때 Private Link, 서비스 엔드포인트 또는 가상 네트워크 피어링을 사용합니다. Microsoft 네트워크에서 트래픽을 유지할 수 있으므로 다른 방법에 비해 비용과 운영 복잡성을 줄일 수 있습니다.
클라우드 공급자 또는 온-프레미스 네트워크에 연결하는 경우 사이트 간 VPN 또는 ExpressRoute를 사용합니다. 이러한 기술은 공급자 간의 보안 연결을 제공합니다.

고객이 소유한 환경에 배포

비즈니스 모델을 사용하려면 고객의 Azure 환경 내에서 애플리케이션 또는 해당 구성 요소를 호스트해야 할 수 있습니다. 고객은 자체 Azure 구독을 관리하고 애플리케이션을 실행하는 데 필요한 리소스 비용을 직접 지불합니다. 솔루션 공급자는 초기 배포, 구성 적용 및 애플리케이션에 업데이트 배포와 같은 솔루션을 관리할 책임이 있습니다.

이러한 상황에서 고객은 종종 자신의 네트워크를 가져와서 정의한 네트워크 공간에 애플리케이션을 배포합니다. Azure Managed Applications는 이 프로세스를 용이하게 하는 기능을 제공합니다. 자세한 내용은 Azure Managed Applications에서 기존 가상 네트워크 사용을 참조 하세요.

디자인 고려 사항

  • IP 주소 범위 및 충돌 고객이 가상 네트워크를 배포하고 관리하는 경우 네트워크 충돌 및 크기 조정을 처리해야 합니다. 그러나 다양한 고객 사용 시나리오를 예상해야 합니다. IP 주소를 효율적으로 사용하여 최소한의 IP 주소 공간이 있는 환경에서 배포를 계획하고, 고객 범위와의 겹침을 방지하기 위해 IP 주소 범위를 하드 코딩하지 않도록 합니다.

    또는 솔루션에 대한 전용 가상 네트워크를 배포합니다. Private Link 또는 가상 네트워크 피어링을 사용하여 고객이 리소스에 연결할 수 있습니다. 이러한 방법은 네트워크 간 연결에 설명되어 있습니다. 수신 및 송신 지점을 정의한 경우 NAT를 IP 주소 겹침으로 인한 문제를 제거하는 방법으로 평가합니다.

  • 관리 목적으로 네트워크 액세스를 제공합니다. 고객 환경에 배포하는 리소스를 검토하고 해당 리소스에 액세스하여 모니터링, 관리 또는 재구성하는 방법을 계획합니다. 개인 IP 주소를 사용하여 고객 소유 환경에 리소스를 배포하는 경우 자체 네트워크에서 연결할 수 있는 네트워크 경로가 있는지 확인합니다. 새 버전의 애플리케이션을 푸시하거나 Azure 리소스 구성을 업데이트하는 등 애플리케이션 및 리소스 변경을 용이하게 하는 방법을 고려합니다.

    일부 솔루션에서는 Just-In-Time 액세스 및 애플리케이션에 대한 업데이트 배포와 같은 Azure Managed Applications에서 제공하는 기능을 사용할 수 있습니다. 더 많은 제어가 필요한 경우 컨트롤 플레인에 연결할 수 있는 고객 네트워크 내에서 엔드포인트를 호스트하여 리소스에 대한 액세스를 제공할 수 있습니다. 이 방법을 사용하려면 보안, 운영 및 성능 요구 사항을 충족하기 위해 추가 Azure 리소스 및 개발이 필요합니다. 이 방법을 구현하는 방법의 예제는 Azure Managed Applications 업데이트 샘플을 참조 하세요.

디자인 권장 사항

추천 장점
Azure Managed Applications를 사용하여 고객이 배포한 리소스를 배포하고 관리합니다. Azure Managed Applications는 고객의 Azure 구독 내에서 리소스를 배포하고 관리할 수 있는 다양한 기능을 제공합니다.
고객의 가상 네트워크 공간 내에서 사용하는 IP 주소 수를 최소화합니다. 고객은 종종 IP 주소 가용성을 제한합니다. 공간을 최소화하고 IP 주소 사용에서 크기 조정을 분리하면 솔루션을 사용할 수 있는 고객 수를 넓히고 더 높은 수준의 성장을 가능하게 할 수 있습니다.
모니터링, 리소스 구성 변경 및 애플리케이션 업데이트를 고려하여 고객 환경에서 리소스를 관리하기 위한 네트워크 액세스 권한을 얻는 방법을 계획합니다. 관리하는 리소스를 직접 구성할 수 있습니다.
전용 가상 네트워크를 배포할지 아니면 고객의 기존 가상 네트워크와 통합할지 결정합니다. 미리 계획하면 격리, 보안 및 다른 시스템과의 통합에 대한 고객의 요구 사항을 충족할 수 있습니다.
기본적으로 Azure 리소스에 대한 공용 액세스를 사용하지 않도록 설정합니다. 가능한 경우 프라이빗 수신을 선호합니다. 사용자와 고객이 보호해야 하는 네트워크 리소스의 범위를 줄입니다.

추가 리소스

다중 테넌시는 SaaS 워크로드를 디자인하기 위한 핵심 비즈니스 방법론입니다. 다음 문서에서는 네트워크 디자인과 관련된 자세한 정보를 제공합니다.

다음 단계

Azure의 SaaS 워크로드에 대한 데이터 무결성 및 성능에 대한 데이터 플랫폼 고려 사항에 대해 알아봅니다.

디자인 영역: Azure의 SaaS 워크로드에 대한 데이터