Azure 랜딩 존의 Azure Virtual Machines 기준 아키텍처

이 문서의 아키텍처는 VM(가상 머신) 기준 아키텍처를 확장하여 Azure 랜딩 존에 배포할 때 변경 내용과 기대치를 해결합니다.

이 문서의 예제에서 조직은 VM 기반 워크로드가 플랫폼 팀이 중앙에서 관리하는 페더레이션된 리소스를 사용하려고 합니다. 이러한 리소스에는 프레미스 간 연결, ID 액세스 관리 및 정책을 위한 네트워킹 리소스가 포함됩니다. 이 예제에서는 조직이 여러 워크로드에서 일관된 거버넌스 및 비용 효율성을 적용하기 위해 Azure 랜딩 존을 채택한다고 가정합니다.

워크로드 소유자는 공유 리소스 관리를 중앙 팀에 오프로드할 수 있으므로 워크로드 개발 작업에 집중할 수 있습니다. 이 문서에서는 워크로드 팀의 관점을 제공합니다. 플랫폼 팀에 대한 권장 사항 지정됩니다.

아티클 레이아웃

아키텍처	디자인 결정	Azure 잘 설계된 프레임워크 접근 방식
▪ 아키텍처 다이어그램 ▪ 워크로드 리소스 ▪ 페더레이션된 리소스	▪ 구독 설정 ▪ 네트워킹 요구 사항 ▪ 기준선의 네트워크 디자인 변경 내용 ▪ 모니터링 ▪ 패치 준수 ▪ 조직 거버넌스 ▪ 변경 관리	▪ 신뢰성 ▪ 보안 ▪ 비용 최적화

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

구성 요소

모든 Azure 랜딩 존 아키텍처는 플랫폼 팀과 워크로드 팀 간에 소유권을 분리합니다. 애플리케이션 설계자와 DevOps 팀은 직접적인 영향 또는 제어의 내용과 그렇지 않은 것을 이해하기 위해 이 책임 분할에 대해 강력하게 이해해야 합니다.

워크로드 팀 소유 리소스

다음 리소스는 기본 대부분 기준 아키텍처에서 변경되지 않습니다.

• Azure Virtual Machines 는 애플리케이션 플랫폼입니다. 컴퓨팅 리소스는 가용성 영역에 분산됩니다.

• Azure Load Balancer 는 프런트 엔드 VM에서 백 엔드 VM으로 트래픽을 개인적으로 부하 분산하는 데 사용됩니다. 부하 분산 장치는 영역 간에 VM에 트래픽을 분산합니다.

• Azure 애플리케이션 게이트웨이는 사용자 요청을 프런트 엔드 VM으로 라우팅하는 역방향 프록시로 사용됩니다. 선택한 SKU는 잠재적으로 악의적인 트래픽으로부터 프런트 엔드 VM을 보호하기 위해 Azure 웹 애플리케이션 방화벽을 호스트하는 데도 사용됩니다.

• Azure Key Vault 는 애플리케이션 비밀 및 인증서를 저장하는 데 사용됩니다.

• Azure Monitor, Log Analytics 및 Application Insights 는 관찰 가능성 데이터를 수집, 저장 및 시각화하는 데 사용됩니다.

• Azure Policy 는 워크로드와 관련된 정책을 적용하는 데 사용됩니다.

워크로드 팀은 다음 리소스와 책임을 기본 파악하고 이행합니다.

• 스포크 가상 네트워크 서브넷 및 해당 서브넷에 배치된 NSG(네트워크 보안 그룹)는 세분화 및 제어 트래픽 흐름을 기본.

• PaaS(Platform as a Service) 솔루션 및 해당 엔드포인트에 필요한 프라이빗 DNS 영역에 대한 보안 연결을 위한 프라이빗 엔드포인트입니다.

• Azure Managed Disks는 백 엔드 서버에 로그 파일을 저장하며 VM이 다시 부팅되는 경우에도 데이터가 유지됩니다. 프런트 엔드 서버에는 상태 비정상 애플리케이션을 배포하는 데 사용할 수 있는 디스크가 연결되어 있습니다.

플랫폼 팀 소유 리소스

플랫폼 팀은 이러한 중앙 집중식 리소스를 소유하고 기본. 이 아키텍처는 이러한 리소스가 미리 프로비전되었다고 가정하고 종속성으로 간주합니다.

• 허브 네트워크의 Azure Firewall은 송신 트래픽을 검사하고 제한하는 데 사용됩니다. 이 구성 요소는 인터넷으로의 아웃바운드 트래픽에 대한 제한을 제공하지 않는 기준 아키텍처의 표준 부하 분산 장치를 대체합니다.

• 허브 네트워크의 Azure Bastion은 워크로드 VM에 대한 안전한 운영 액세스를 제공합니다. 기준 아키텍처에서 워크로드 팀은 이 구성 요소를 소유합니다.

• 스포크 가상 네트워크는 워크로드가 배포되는 위치입니다.

• UDR(사용자 정의 경로 )은 허브 네트워크에 터널링을 강제하는 데 사용됩니다.

• Azure Policy 기반 거버넌스 제약 조건 및 DeployIfNotExists (DINE) 정책은 워크로드 구독의 일부입니다.

구독 설정

랜딩 존 컨텍스트에서 워크로드 팀은 플랫폼 팀에 특정 요구 사항을 알려야 합니다.

워크로드 팀은 플랫폼 팀이 필요한 리소스를 할당할 수 있도록 워크로드에 필요한 네트워킹 공간에 대한 자세한 정보를 포함해야 합니다. 팀은 요구 사항을 결정하고 플랫폼 팀은 가상 네트워크 내에서 할당할 IP 주소와 구독이 할당된 관리 그룹을 결정합니다.

플랫폼 팀은 워크로드가 인터넷에 노출되는 경우와 같이 워크로드의 비즈니스 중요도 및 기술 요구 사항에 따라 적절한 관리 그룹을 할당합니다. 조직은 이러한 관리 그룹의 구성을 결정하고 플랫폼 팀에서 이를 구현합니다.

예를 들어 기준 아키텍처에 대한 애플리케이션 시나리오의 관리 그룹은 다음과 같이 간주됩니다.

• 내부 LOB(기간 업무) 애플리케이션 또는 상용 COTS(상용) 솔루션과 같은 프라이빗 애플리케이션은 종종 Azure 랜딩 존의 Corp 관리 그룹 아래에 있습니다.

• 인터넷 연결 애플리케이션과 마찬가지로 공용 애플리케이션은 종종 Corp 또는 Online 관리 그룹에 포함됩니다.

또한 플랫폼 팀은 워크로드 배포에 대한 구독 또는 구독 그룹을 설정할 책임이 있습니다.

다음 섹션에서는 초기 구독 설정에 대한 지침을 제공합니다. 그러나 플랫폼 팀은 일반적으로 누락되거나 변경된 요구 사항을 해결하기 위해 중앙 집중식 서비스를 변경합니다. 플랫폼 변경은 모든 워크로드 팀에 더 광범위한 영향을 미칩니다.

따라서 플랫폼 팀은 모든 VM 워크로드가 변경에 대해 준비되었는지 확인해야 하며 VM 기반 솔루션의 수명 주기 및 테스트 주기를 알고 있어야 합니다. 자세한 내용은 시간에 따른 변경 내용 관리를 참조하세요.

워크로드 요구 사항 및 처리

워크로드 팀과 플랫폼 팀은 관리 그룹 할당 및 네트워킹 설정이라는 두 가지 기본 책임을 공유합니다. 이 아키텍처의 경우 플랫폼 팀과 통신해야 하는 다음과 같은 네트워킹 요구 사항을 고려합니다. 유사한 아키텍처를 구현할 때 두 팀 간의 토론과 협상을 이해하기 위한 예제로 이러한 점을 사용합니다.

• 스포크 가상 네트워크 수: 이 아키텍처에서는 전용 스포크 하나만 필요합니다. 배포된 리소스는 여러 네트워크에 걸쳐 있지 않아도 되며 단일 가상 네트워크 내에 공동 배치됩니다.

• 스포크 네트워크의 크기: 운영 요구 사항 및 예상되는 워크로드 증가를 고려합니다. 예를 들어 파란색/녹색 또는 카나리아 업데이트를 구현하려는 경우 병렬 배포에 필요한 공간을 최대 크기로 고려해야 합니다.

  향후 변경 내용에는 더 많은 IP 공간이 필요할 수 있으며, 현재 할당과 잘못 정렬될 수 있습니다. 이러한 공간의 통합으로 인해 복잡성이 더 많이 발생할 수 있습니다. 사전에 대처하고 할당된 공간이 향후 확장을 수용할 수 있도록 충분한 네트워크 리소스를 미리 요청합니다.

• 배포 지역: 워크로드가 배포될 지역을 지정하는 것이 중요합니다. 플랫폼 팀은 이 정보를 사용하여 스포크 및 허브 가상 네트워크가 동일한 지역에 프로비전되도록 할 수 있습니다. 여러 지역의 네트워크는 지역 경계를 넘는 트래픽으로 인해 대기 시간 문제가 발생할 수 있으며 추가 대역폭 비용이 발생할 수도 있습니다.

• 워크로드 특성 및 디자인 선택 사항: 디자인 선택 사항, 구성 요소 및 특성을 플랫폼 팀에 전달합니다. 예를 들어 워크로드가 인터넷에 대한 많은 수의 동시 연결(번잡함)을 생성할 것으로 예상하는 경우 플랫폼 팀은 고갈을 방지하기 위해 사용 가능한 충분한 포트가 있는지 확인해야 합니다. 중앙 방화벽에 IP 주소를 추가하여 트래픽을 지원하거나 NAT(네트워크 주소 변환) 게이트웨이를 설정하여 대체 경로를 통해 트래픽을 라우팅할 수 있습니다.

  반대로 워크로드가 최소한의 네트워크 트래픽(백그라운드 노이즈)을 생성할 것으로 예상하는 경우 플랫폼 팀은 조직 전체에서 리소스를 효율적으로 사용해야 합니다.

  플랫폼 팀은 모든 종속성을 명확하게 이해해야 합니다. 예를 들어 워크로드가 다른 팀이 소유한 데이터베이스에 액세스해야 하거나 워크로드에 크로스-프레미스 트래픽이 있을 수 있습니다. 워크로드에 Azure 외부의 종속성이 있나요? 이러한 정보는 플랫폼 팀이 알아야 할 중요한 정보입니다.

• 방화벽 구성: 플랫폼 팀은 스포크 네트워크를 벗어나 허브 네트워크로 터널링되는 트래픽을 알고 있어야 합니다. 허브의 방화벽은 해당 트래픽을 차단할 수 없습니다.

  예를 들어 워크로드가 패치를 유지하기 위해 Windows 업데이트에 액세스해야 하는 경우 방화벽이 이러한 업데이트를 차단해서는 안 됩니다. 마찬가지로 특정 엔드포인트에 액세스하는 모니터 에이전트가 있는 경우 방화벽은 워크로드에 대한 모니터링 데이터를 방해할 수 있으므로 해당 트래픽을 차단해서는 안 됩니다. 애플리케이션에서 타사 엔드포인트에 액세스해야 할 수 있습니다. 관계없이 중앙 집중식 방화벽을 사용하여 예상 트래픽과 부당한 트래픽을 구분합니다.

• 운영자 액세스: 운영자가 Azure Bastion을 통해 VM에 액세스하는 데 사용하는 Microsoft Entra ID 보안 그룹이 있는 경우 플랫폼 팀에 알릴 수 있습니다. Azure Bastion은 일반적으로 중앙 리소스입니다. 보안 그룹 및 VM이 보안 프로토콜을 지원하는지 확인하는 것이 중요합니다.

  또한 VM을 포함하는 IP 범위에 대해 플랫폼 팀에 알릴 수 있습니다. 이 정보는 허브 네트워크에서 Azure Bastion을 중심으로 NSG를 구성하는 데 필요합니다.

• 공용 IP: 예상되는 공용 IP 주소를 포함하여 수신 트래픽 프로필에 대해 플랫폼 팀에 알릴 수 있습니다. 이 아키텍처에서는 인터넷 소스 트래픽만 Application Gateway의 공용 IP를 대상으로 합니다. 플랫폼 팀은 이러한 IP가 Azure DDoS Protection 계획에 따라 있거나 워크로드 팀의 책임인 경우 워크로드 팀에 알려야 합니다.

  이 아키텍처에는 Azure Bastion을 통한 운영 액세스를 위한 또 다른 공용 IP가 있습니다. 플랫폼 팀은 이 공용 IP를 소유하고 있으며 플랫폼 팀이 관리하는 DDoS Protection과 같은 서비스에 등록됩니다.

VM 디자인 선택

VM SKU 및 디스크 선택은 기준 아키텍처와 기본 동일합니다.

조직은 특정 VM 이미지의 사용을 의무화하는 워크로드 팀에 규정 준수 요구 사항을 적용할 수 있습니다. 이러한 요구 사항을 감안할 때 플랫폼 팀은 조직 전체에서 사용하기 위해 만들어지는 골든 이미지라고 도 하는 표준화된 이미지 집합을 관리할 수 있습니다.

플랫폼 팀은 Azure Compute 갤러리 또는 프라이빗 리포지토리와 같은 관리되는 제품을 사용하여 승인된 OS 이미지 또는 워크로드 아티팩트를 저장할 수 있습니다. VM에 대한 OS 이미지를 선택하는 경우 플랫폼 팀에 이미지 원본, 업데이트 빈도 및 사용량 기대치에 대해 문의하세요. 또한 이미지가 워크로드가 충족하는 데 필요한 비즈니스 요구 사항을 충족할 수 있는지 확인합니다.

네트워킹

기준 아키텍처에서 워크로드는 단일 가상 네트워크에 프로비전됩니다. 워크로드 팀은 가상 네트워크를 관리합니다.

이 아키텍처에서 플랫폼 팀은 네트워크 토폴로지를 결정합니다. 이 아키텍처에서는 허브 스포크 토폴로지를 사용하는 것으로 가정합니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

• 허브 가상 네트워크: 지역 허브에는 동일한 지역의 워크로드 리소스와 통신하는 중앙 집중식 서비스가 포함되어 있습니다. 자세한 내용은 플랫폼 팀 소유 리소스를 참조 하세요. 연결 구독에 허브를 배치하는 것이 좋습니다.

• 스포크 가상 네트워크: 이 아키텍처에서 기준 아키텍처의 단일 가상 네트워크는 스포크 네트워크입니다. 중앙 집중식 서비스를 포함하는 허브 네트워크에 피어됩니다. 플랫폼 팀은 이 스포크 네트워크를 소유하고 관리합니다. 이 네트워크에는 워크로드 리소스가 포함되어 있습니다. 워크로드 팀은 서브넷을 포함하여 이 네트워크의 리소스를 소유합니다.

워크로드 요구 사항을 플랫폼 팀에 전달하고 주기적으로 검토해야 합니다.

가상 네트워크 서브넷

스포크 가상 네트워크에서 워크로드 팀은 서브넷을 만들고 할당합니다. 서브넷 내/외부의 트래픽을 제한하는 컨트롤을 배치하면 구분을 제공하는 데 도움이 됩니다. 이 아키텍처는 Application Gateway, 프런트 엔드 VM, 부하 분산 장치, 백 엔드 VM 및 프라이빗 엔드포인트에 대한 전용 서브넷이 있는 기준 아키텍처와 동일한 서브넷 토폴로지를 사용합니다.

Azure 랜딩 존에 워크로드를 배포하는 경우에도 네트워크 컨트롤을 구현해야 합니다. 조직은 데이터 반출을 방지하고 SOC(중앙 보안 운영 센터) 및 IT 네트워크 팀의 가시성을 보장하기 위해 제한을 적용할 수 있습니다.

이 방법을 사용하면 플랫폼 팀은 조직 전체의 각 워크로드에 중복 보안 제어를 배포하는 대신 중앙 집중식 서비스를 사용하여 전체 조직 지출을 최적화할 수 있습니다. 이 아키텍처에서 Azure Firewall은 중앙 서비스의 예입니다. 각 워크로드 팀이 자체 방화벽 인스턴스를 관리하는 것은 비용 효과적이거나 실용적이지 않습니다. 방화벽 관리에 대한 중앙 집중식 접근 방식을 권장합니다.

수신 트래픽

수신 트래픽 흐름은 기준 아키텍처와 동일하게 기본.

워크로드 소유자는 워크로드에 대한 공용 인터넷 수신과 관련된 모든 리소스를 담당합니다. 예를 들어 이 아키텍처에서 Application Gateway 및 공용 IP는 허브 네트워크가 아닌 스포크 네트워크에 배치됩니다. 일부 조직에서는 중앙 집중식 비무장화(DMZ) 구현을 사용하여 연결 구독에 수신 트래픽이 있는 리소스를 배치할 수 있습니다. 해당 특정 토폴로지와의 통합은 이 문서의 범위를 벗어납니다.

송신 트래픽

기준 아키텍처에서 워크로드 가상 머신 확장 집합은 Azure Load Balancer를 통해 공용 인터넷에 액세스하지만 트래픽은 제한되지 않습니다.

이러한 디자인은 이 아키텍처에서 다릅니다. 스포크 가상 네트워크를 벗어나는 모든 트래픽은 송신 방화벽을 통해 피어된 허브 네트워크를 통해 라우팅됩니다. 경로는 로컬 가상 네트워크(0.0.0.0/0)에서 찾을 수 없는 IP에 대한 모든 트래픽을 허브의 Azure Firewall로 전송하는 스포크 네트워크의 가능한 모든 서브넷에 연결됩니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

Key Vault 액세스를 위한 프라이빗 엔드포인트에 대한 워크로드 통신은 기준 아키텍처와 동일하게 기본. 간결성을 위해 이전 다이어그램에서 해당 경로를 생략합니다.

워크로드 팀은 인프라 및 워크로드 작업에 필요한 모든 아웃바운드 트래픽 흐름을 식별, 문서화 및 통신해야 합니다. 플랫폼 팀은 필요한 트래픽을 허용하고, 모든 통신되지 않은 송신 트래픽이 거부될 수 있습니다.

송신 트래픽을 제어하는 것은 단순히 예상 트래픽이 허용되는지 확인하는 것 이상입니다. 또한 예상 트래픽만 허용되도록 하는 것입니다. 통신되지 않은 송신 트래픽은 기본적으로 거부될 수 있지만 트래픽이 제대로 라우팅되도록 하는 것이 워크로드의 가장 좋은 보안 관심사입니다.

고유한 송신 트래픽 요구 사항을 플랫폼 팀에 전달합니다. 예를 들어 워크로드가 외부 네트워크 엔드포인트에 대한 수많은 동시 연결을 설정하는 경우 플랫폼 팀에 알릴 수 있습니다. 그런 다음 플랫폼 팀은 적절한 Azure NAT 게이트웨이 구현을 프로비전하거나 완화를 위해 지역 방화벽에 공용 IP를 더 추가할 수 있습니다.

조직에는 송신을 위해 워크로드 소유 공용 IP를 사용하는 아키텍처 패턴을 사용하지 않는 요구 사항이 있을 수 있습니다. 이 경우 Azure Policy를 사용하여 잘 알려진 수신 지점 이외의 VM NIC(네트워크 인터페이스 카드) 및 기타 공용 IP에서 공용 IP를 거부할 수 있습니다.

프라이빗 DNS 영역

프라이빗 엔드포인트를 사용하는 아키텍처는 DNS 공급자와 함께 작동하려면 프라이빗 DNS 영역이 필요합니다. 워크로드 팀은 플랫폼 팀이 제공하는 구독에서 프라이빗 DNS 영역의 요구 사항 및 관리를 명확하게 이해해야 합니다. 프라이빗 DNS 영역은 일반적으로 DINE 정책을 사용하여 대규모로 관리되며, 이를 통해 Azure Firewall은 신뢰할 수 있는 DNS 프록시로 작동하고 FQDN(정규화된 do기본 이름) 네트워크 규칙을 지원할 수 있습니다.

이 아키텍처에서 플랫폼 팀은 프라이빗 링크 엔드포인트에 대한 신뢰할 수 있는 프라이빗 DNS 확인을 보장합니다. 플랫폼 팀과 협업하여 기대치를 이해합니다.

커넥트성 테스트

VM 기반 아키텍처의 경우 네트워크 가시선, 라우팅 및 DNS 문제를 확인하는 데 도움이 되는 몇 가지 테스트 도구가 있습니다. 기존 문제 해결 도구(예: netstat, nslookup또는 tcping.)를 사용할 수 있습니다. 또한 네트워크 어댑터의 DHCP(동적 호스트 구성 프로토콜) 및 DNS 설정을 검사할 수 있습니다. NIC가 있는 경우 Azure Network Watcher를 사용하여 연결 검사 수행할 수 있는 더 많은 문제 해결 기능이 있습니다.

운영자 액세스

기준 아키텍처와 마찬가지로 Azure Bastion을 통한 운영 액세스는 이 아키텍처에서 지원됩니다.

그러나 기준 아키텍처는 워크로드의 일부로 Azure Bastion을 배포합니다. Azure 랜딩 존을 채택하는 일반적인 조직의 경우 각 지역의 중앙 리소스로 Azure Bastion을 배포합니다. 플랫폼 팀은 Azure Bastion을 소유하고 기본 조직의 모든 워크로드가 공유합니다. 이 아키텍처의 사용 사례를 보여주기 위해 Azure Bastion은 연결 구독의 허브 네트워크에 있습니다.

연산자 ID

이 아키텍처는 기준 아키텍처와 동일한 인증 확장을 사용합니다.

항상 장기 액세스 대신 작업에 대한 최소 권한 및 세분화된 액세스 원칙으로 시작합니다. 랜딩 존 컨텍스트에서 플랫폼 팀이 관리하는 JIT(Just-In-Time) 지원을 활용합니다.

패치 규정 준수 및 OS 업그레이드

기준 아키텍처는 패치 및 업그레이드에 대한 자율적인 접근 방식을 설명합니다. 워크로드가 랜딩 존과 통합되면 해당 접근 방식이 변경될 수 있습니다. 플랫폼 팀은 모든 워크로드가 조직의 요구 사항을 준수할 수 있도록 패치 작업을 지시할 수 있습니다.

패치 프로세스에 아키텍처에 추가하는 모든 구성 요소가 포함되어 있는지 확인합니다. 예를 들어 애플리케이션의 배포, 크기 조정 및 관리를 자동화하기 위해 빌드 에이전트 VM을 추가하도록 선택하는 경우 해당 VM은 플랫폼 요구 사항을 준수해야 합니다.

모니터링

Azure 랜딩 존 플랫폼은 관리 구독의 일부로 공유 관찰성 리소스를 제공합니다. 그러나 워크로드의 소유권 책임을 용이하게 하기 위해 자체 모니터링 리소스를 프로비전하는 것이 좋습니다. 이 방법은 기준 아키텍처와 일치합니다.

워크로드 팀은 다음을 포함하는 모니터링 리소스를 프로비전합니다.

• 워크로드 팀을 위한 APM(애플리케이션 성능 모니터링) 서비스로서의 Application Insights.

• Log Analytics 작업 영역은 워크로드 소유 Azure 리소스 및 애플리케이션 코드에서 수집되는 모든 로그 및 메트릭에 대한 통합 싱크입니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

기준과 마찬가지로 모든 리소스는 워크로드 팀이 리소스의 IaC(인프라) 배포의 일부로 프로비전하는 Log Analytics 작업 영역에 Azure Diagnostics 로그를 보내도록 구성됩니다. 중앙 Log Analytics 작업 영역으로 로그를 보내야 할 수도 있습니다. Azure 랜딩 존에서 해당 작업 영역은 관리 구독에 있습니다.

플랫폼 팀에는 중앙 집중식 관리 구독으로 로그를 보내도록 진단을 구성하는 데 사용할 수 있는 DINE 정책이 있을 수도 있습니다. 구현에서 추가 로그 흐름을 제한하지 않도록 하는 것이 중요합니다.

여러 싱크의 데이터 상관 관계

워크로드의 로그 및 메트릭 및 인프라 구성 요소는 워크로드의 Log Analytics 작업 영역에 저장됩니다. 그러나 Azure Firewall, Microsoft Entra ID 및 Azure Bastion과 같은 중앙 집중식 서비스가 생성하는 로그 및 메트릭은 중앙 Log Analytics 작업 영역에 저장됩니다. 여러 싱크에서 데이터를 상호 연결하는 작업은 복잡한 작업일 수 있습니다.

상관 관계가 있는 데이터는 인시던트 대응 중에 자주 사용됩니다. 여러 싱크의 데이터를 상호 연결하는 데 문제가 있는 경우 이 아키텍처의 심사 Runbook에서 문제를 해결하고 문제가 워크로드 리소스 이상으로 확장되는 경우 조직의 연락 지점을 포함해야 합니다. 워크로드 관리자는 엔터프라이즈 네트워킹, 보안 또는 기타 플랫폼 서비스의 로그 항목을 상호 연결하기 위해 플랫폼 관리자의 도움이 필요할 수 있습니다.

Azure Policy

플랫폼 팀은 워크로드 배포에 영향을 주는 정책을 적용할 가능성이 높습니다. 종종 DINE 정책을 적용하여 애플리케이션 랜딩 존 구독에 자동화된 배포를 처리합니다. DINE 정책은 워크로드 리소스를 수정하거나 배포에 리소스를 추가할 수 있으므로 워크로드 템플릿을 통해 선언적으로 배포되는 리소스와 처리 요청이 실제로 사용하는 리소스 간에 불일치가 발생할 수 있습니다. 일반적인 해결 방법은 이상적인 방법이 아닌 명령적 접근 방식을 사용하여 이러한 변경 내용을 수정하는 것입니다.

이러한 불일치를 방지하려면 플랫폼 시작 변경 내용을 IaC 템플릿에 선제적으로 통합하고 테스트합니다. 플랫폼 팀이 애플리케이션의 요구 사항과 충돌하는 Azure 정책을 사용하는 경우 플랫폼 팀과 해결을 협상할 수 있습니다.

시간에 따른 변경 내용 관리

플랫폼 제공 서비스 및 작업은 이 아키텍처에서 외부 종속성으로 간주됩니다. 플랫폼 팀은 계속해서 변경 내용을 적용하고, 사용자를 온보딩하고, 비용 제어를 적용합니다. 조직에 서비스를 제공하는 플랫폼 팀은 개별 워크로드의 우선 순위를 지정하지 않을 수 있습니다. 골든 이미지 변경, 방화벽 수정, 자동화된 패치 또는 규칙 변경 등과 같은 종속성을 변경하면 여러 워크로드에 영향을 줄 수 있습니다.

따라서 워크로드 및 플랫폼 팀은 모든 외부 종속성을 관리하기 위해 효율적이고 시기 적절하게 통신해야 합니다. 변경 내용을 테스트하는 것이 중요하므로 워크로드에 부정적인 영향을 주지 않습니다.

워크로드에 영향을 주는 플랫폼 변경 내용

이 아키텍처에서 플랫폼 팀은 다음 리소스를 관리합니다. 이러한 리소스를 변경하면 워크로드의 안정성, 보안, 작업 및 성능 목표에 영향을 줄 수 있습니다. 플랫폼 팀이 적용하기 전에 이러한 변경 내용을 평가하여 워크로드에 미치는 영향을 결정하는 것이 중요합니다.

• Azure 정책: Azure 정책을 변경하면 워크로드 리소스 및 해당 종속성에 영향을 줄 수 있습니다. 예를 들어 방문 영역을 새 관리 그룹 계층 구조로 직접 변경하거나 이동할 수 있습니다. 이러한 변경 내용은 새 배포가 있을 때까지 눈에 띄지 않을 수 있으므로 철저히 테스트하는 것이 중요합니다.

• 방화벽 규칙: 방화벽 규칙을 수정하면 워크로드의 가상 네트워크 또는 모든 트래픽에 광범위하게 적용되는 규칙에 영향을 줄 수 있습니다. 이러한 수정으로 인해 트래픽이 차단되고 OS 패치의 애플리케이션 실패와 같은 자동 프로세스 오류도 발생할 수 있습니다. 이러한 잠재적인 문제는 송신 Azure 방화벽 및 Azure Virtual Network Manager 적용 NSG 규칙에 모두 적용됩니다.

• 공유 리소스: SKU 또는 공유 리소스의 기능을 변경하면 워크로드에 영향을 줄 수 있습니다.

• 허브 네트워크의 라우팅: 허브에서 라우팅의 전이적 특성이 변경되면 워크로드가 다른 가상 네트워크로의 라우팅에 의존하는 경우 워크로드 기능에 영향을 줄 수 있습니다.

• Azure Bastion 호스트: Azure Bastion 호스트 가용성 또는 구성을 변경하면 워크로드 작업에 영향을 줄 수 있습니다. 점프 박스 액세스 패턴 변경에 효과적인 루틴, 임시 및 응급 액세스가 있는지 확인합니다.

• 소유권 변경: 워크로드의 관리 및 지원 요청에 영향을 줄 수 있으므로 소유권 및 연락 지점의 변경 내용을 워크로드 팀에 전달합니다.

플랫폼에 영향을 주는 워크로드 변경

다음 예제는 플랫폼 팀과 통신해야 하는 이 아키텍처의 워크로드 변경 내용입니다. 플랫폼 팀이 새로운 워크로드 팀 변경 내용에 대해 플랫폼 서비스의 안정성, 보안, 운영 및 성능 목표의 유효성을 검사한 후 적용하는 것이 중요합니다.

• 네트워크 송신: 네트워크 송신의 상당한 증가를 모니터링하여 워크로드가 네트워크 디바이스에서 시끄러운 인접 항목이 되는 것을 방지합니다. 이 문제는 잠재적으로 다른 워크로드의 성능 또는 안정성 목표에 영향을 줄 수 있습니다.

• 공용 액세스: 워크로드 구성 요소에 대한 공용 액세스를 변경하려면 추가 테스트가 필요할 수 있습니다. 플랫폼 팀은 워크로드를 다른 관리 그룹으로 재배치할 수 있습니다.

• 비즈니스 중요도 등급: 워크로드의 SLA(서비스 수준 계약)가 변경된 경우 플랫폼과 워크로드 팀 간에 새로운 공동 작업 접근 방식이 필요할 수 있습니다.

• 소유권 변경: 소유권 및 연락 지점의 변경 내용을 플랫폼 팀에 전달합니다.

워크로드 비즈니스 요구 사항 변경

워크로드의 SLO(서비스 수준 목표)를 기본 위해 플랫폼 팀은 워크로드 아키텍처 변경에 참여해야 할 수 있습니다. 이러한 변경 내용에는 플랫폼 팀의 변경 관리 또는 기존 거버넌스에서 변경된 요구 사항을 지원하는 유효성 검사가 필요할 수 있습니다.

예를 들어 플랫폼 팀이 방화벽, Virtual Network Manager 또는 기타 구성 요소에 해당 흐름을 추가하여 필요한 트래픽을 지원할 수 있도록 이전에 허용되지 않은 송신 흐름에 변경 내용을 전달합니다. 반대로 이전에 허용된 송신 흐름이 더 이상 필요하지 않은 경우 플랫폼 팀은 워크로드의 보안을 기본 위해 해당 흐름을 차단해야 합니다. 또한 다른 가상 네트워크 또는 크로스-프레미스 엔드포인트 또는 아키텍처 구성 요소에 대한 변경 내용에 대한 라우팅 변경 내용을 전달합니다. 각 리소스에는 정책 및 잠재적으로 송신 방화벽 제어가 적용됩니다.

안정성

이 아키텍처는 기준 아키텍처의 안정성 보장과 일치합니다.

안정성 대상

송신 네트워크 제어와 같은 구성 요소로 인해 가능한 최대 복합 SLO 가 기준 복합 SLO 보다 낮습니다. 랜딩 존 환경에서 공통적으로 사용되는 이러한 구성 요소는 이 아키텍처에서 고유하지 않습니다. 워크로드 팀이 이러한 Azure 서비스를 직접 제어하는 경우 SLO도 마찬가지로 줄어듭니다.

가능한 최대 SLO가 낮음에도 불구하고 주요 안정성 측면은 기능 팀 간에 워크로드 구성 요소의 분할입니다. 이 방법을 사용하면 워크로드 팀은 이 워크로드 및 기타 워크로드에서 사용하는 중요한 인프라를 운영하는 데 중점을 둔 전문 팀의 이점을 누릴 수 있습니다.

자세한 내용은 안정성 대상 정의에 대한 권장 사항 참조하세요.

중요 종속성

워크로드가 플랫폼 및 애플리케이션 랜딩 존에서 수행하는 모든 기능을 종속성으로 봅니다. 인시던트 대응 계획을 사용하려면 워크로드 팀이 이러한 종속성에 대한 연락처 정보의 지점 및 방법을 알고 있어야 합니다. 또한 워크로드의 FMA(오류 모드 분석)에 이러한 종속성을 포함합니다.

이 아키텍처의 경우 다음 종속성을 고려합니다.

• 송신 방화벽: 여러 워크로드에서 공유하는 중앙 집중식 송신 방화벽은 워크로드와 관련이 없는 변경 내용을 거칩니다.

• 네트워크 포트 고갈: 네트워크 디바이스를 공유하는 모든 워크로드의 사용량이 급증하면 송신 방화벽에서 네트워크 포화 또는 포트 소모가 발생할 수 있습니다.

• DINE 정책: Azure DNS 프라이빗 DNS 영역(또는 다른 플랫폼 제공 종속성)에 대한 DINE 정책은 실행에 대한 SLA 없이 최선의 노력입니다. DNS 구성이 지연되면 애플리케이션이 트래픽을 처리할 준비가 지연될 수 있습니다.

• 관리 그룹 정책: 환경 간의 일관된 정책은 안정성의 핵심입니다. 사전 프로덕션 환경이 프로덕션 환경과 유사하여 정확한 테스트를 제공하고 배포 또는 규모를 차단할 수 있는 환경별 편차를 방지해야 합니다. 자세한 내용은 Azure 랜딩 존에서 애플리케이션 개발 환경 관리를 참조 하세요.

이러한 고려 사항 중 상당수는 Azure 랜딩 존 없이 존재할 수 있지만 워크로드 및 플랫폼 팀은 이러한 문제를 공동으로 해결하여 요구 사항을 충족해야 합니다.

자세한 내용은 실패 모드 분석을 수행하기 위한 권장 사항 참조하세요.

보안

이 아키텍처에 대한 보안 고려 사항은 기준 아키텍처에서 이월됩니다. 다음 섹션의 권장 사항은 잘 설계된 프레임워크의 보안 디자인 검토 검사 목록을 기반으로 합니다.

네트워크 제어

워크로드가 안전한지 확인하기 위해 네트워크 컨트롤을 올바르게 구성합니다.

수신 트래픽

서브넷의 NSG 또는 지역 허브의 비전도적 특성 또는 컨트롤을 통해 조직 내의 다른 워크로드 스포크에서 워크로드를 격리할 수 있습니다. 애플리케이션 및 해당 인프라의 인바운드 네트워크 요구 사항만 허용하는 포괄적인 NSG를 생성합니다. 보안을 위해 허브 네트워크의 비전도적 특성에만 의존하지 않는 것이 좋습니다.

플랫폼 팀은 Azure 정책을 구현하여 Application Gateway에 웹 애플리케이션 방화벽이 거부 모드로 설정되어 있는지 확인하고, 구독 및 기타 검사 사용할 수 있는 공용 IP 수를 제한할 수 있습니다. 이러한 정책 외에도 워크로드 팀은 수신 보안 태세를 강화하는 워크로드 중심 정책을 배포할 책임이 있어야 합니다.

다음 표에서는 이 아키텍처의 수신 컨트롤 예제를 보여 줍니다.

원본	목적	워크로드 제어	플랫폼 제어
인터넷	사용자 트래픽 흐름	공용 트래픽이 프런트 엔드 VM에 진입하는 프라이빗 트래픽으로 전환되도록 허용하기 전에 NSG, 웹 애플리케이션 방화벽 및 라우팅 규칙을 통해 모든 요청을 깔때기합니다.	없음
Azure Bastion	VM에 대한 운영자 액세스	플랫폼의 지정된 Azure Bastion 서브넷에서 공급되지 않는 한 원격 액세스 포트에 대한 모든 트래픽을 차단하는 VM 서브넷의 NSG	없음
기타 스포크	없음	NSG 규칙을 통해 차단됨	Azure Virtual WAN 보안 허브의 경우 비전송 라우팅 또는 Azure Firewall 규칙

송신 트래픽

솔루션의 필요한 아웃바운드 연결 요구 사항을 표현하고 다른 모든 것을 거부하는 NSG 규칙을 적용합니다. 허브 네트워크 컨트롤에만 의존하지 마세요. 워크로드 운영자는 원치 않는 송신 트래픽을 가능한 한 원본에 가깝게 중지해야 합니다.

가상 네트워크 내에서 서브넷을 소유하는 동안 플랫폼 팀은 캡처된 요구 사항을 구독 자동 판매 프로세스의 일부로 구체적으로 나타내는 방화벽 규칙을 만들었을 가능성이 높습니다. 아키텍처 수명 동안 서브넷 및 리소스 배치의 변경 내용이 원래 요청과 호환되는지 확인합니다. 또는 네트워크 팀과 협력하여 최소 액세스 송신 제어의 연속성을 보장할 수 있습니다.

다음 표에서는 이 아키텍처의 송신 예제를 보여 줍니다.

엔드포인트	목적	워크로드(NSG) 제어	플랫폼(허브) 컨트롤
ntp.ubuntu.com	Linux VM용 NTP(네트워크 시간 프로토콜)	프런트 엔드 VM 서브넷의 인터넷으로 UDP/123 (송신 방화벽이 이 광범위한 개방 범위를 좁힐 수 있음)	워크로드 제어와 동일한 방화벽 네트워크 규칙 허용
엔드포인트 Windows 업데이트	Microsoft 서버의 Windows 업데이트 기능	백 엔드 VM 서브넷의 인터넷에 대한 TCP/443 및 TCP/80 (송신 방화벽은 이 광범위한 개방 범위를 좁혀줍니다.)	FQDN 태그가 있는 방화벽 허용 규칙 WindowsUpdate
에이전트 엔드포인트 모니터링	VM의 모니터 확장에 필요한 트래픽	두 VM 서브넷의 인터넷에 대한 TCP/443 (송신 방화벽은 이 광범위한 개방 범위를 좁혀줍니다.)	TCP/443의 모든 특정 FQDN에 필요한 방화벽 애플리케이션 규칙 허용
nginx.org	공급업체에서 직접 Nginx(예제 애플리케이션 구성 요소)를 설치하려면	프런트 엔드 VM 서브넷의 인터넷에 대한 TCP/443 (송신 방화벽은 이 광범위한 개방 범위를 좁혀줍니다.)	TCP/443에서 nginx.org 필요한 방화벽 애플리케이션 규칙 허용
Key Vault	Application Gateway 및 VM에서 TLS 인증서를 가져오려면(전송 계층 보안)	- 두 VM 서브넷에서 프라이빗 엔드포인트 서브넷으로의 프라이빗 엔드포인트 서브넷에 대한 TCP/443 - Application Gateway 서브넷에서 프라이빗 엔드포인트 서브넷으로 TCP/443 - 필수 ASG(애플리케이션 보안 그룹) 지정 및 Application Gateway 서브넷으로 태그가 지정된 VM의 TCP/443	없음

DDoS Protection

솔루션의 모든 공용 IP를 포함하는 DDoS Protection 계획을 적용할 책임이 있는 사용자를 결정합니다. 플랫폼 팀은 IP 보호 계획을 사용하거나 Azure Policy를 사용하여 가상 네트워크 보호 계획을 적용할 수도 있습니다. 이 아키텍처는 인터넷에서 수신하기 위한 공용 IP를 포함하므로 적용 범위가 있어야 합니다.

자세한 내용은 네트워킹 및 연결에 대한 권장 사항 참조하세요.

비밀 관리

비밀 관리의 경우 이 아키텍처는 기준 아키텍처를 따릅니다.

워크로드 팀으로서 Key Vault 인스턴스에서 비밀을 계속 유지합니다. 애플리케이션 및 인프라 작업을 지원하기 위해 필요에 따라 더 많은 인스턴스를 배포합니다.

자세한 내용은 애플리케이션 비밀 보호에 대한 권장 사항 참조하세요.

비용 최적화

워크로드 리소스의 경우 기준 아키텍처의 비용 최적화 전략도 이 아키텍처에 적용됩니다.

이 아키텍처는 Azure 랜딩 존 플랫폼 리소스의 이점을 크게 활용합니다. 차지백 모델을 통해 해당 리소스를 사용하는 경우에도 추가된 보안 및 프레미스 간 연결은 해당 리소스를 자체 관리하는 것보다 비용 효율적입니다.

플랫폼 팀은 이 아키텍처에서 다음 리소스를 관리합니다. 이러한 리소스는 종종 사용량 기반(차지백)이거나 워크로드 팀에 무료로 제공됩니다.

• Azure Firewall
• SIEM(보안 정보 및 이벤트 관리)
• Azure Bastion 호스트
• ExpressRoute와 같은 프레미스 간 연결

플랫폼 팀의 다른 중앙 집중식 제품을 활용하여 SLO, RTO(복구 시간 목표) 또는 RPO(복구 지점 목표)를 손상시키지 않고 워크로드로 이러한 혜택을 확장합니다.

자세한 내용은 비용 데이터 수집 및 검토에 대한 권장 사항 참조하세요.

시나리오 배포

이 참조 아키텍처에 대한 배포는 GitHub에서 사용할 수 있습니다.

다음 단계

워크로드 팀과 플랫폼 팀 간에 공유되는 공동 작업 및 기술 세부 정보를 검토합니다.

구독 자동 판매