기업용 Azure Landing Zone은 어떻게 설계해야 하는가

Azure Landing Zone은 미리 만들어진 Network도, Azure Policy 정의 모음도, 한 번 실행하고 끝나는 배포 Template도 아니다. 기업이 Azure에 Workload를 반복해서 올리면서 Identity, Governance, Connectivity, Security, Operations, Cost를 일관되게 통제할 수 있도록 만드는 운영 기반이다.

이 차이를 이해하는 것이 중요하다. Hub Network를 정교하게 구성했더라도 Subscription 발급, 소유자 지정, 임시 Privileged Access, 예외 처리, Platform 복구 절차가 없다면 지속 가능한 Landing Zone이라고 보기 어렵다. 반대로 의사결정과 경계, 자동화 방식을 명확히 정의한 Landing Zone은 작은 규모에서 시작해 요구사항에 맞춰 확장할 수 있다.

이 글은 On-premises Active Directory Domain Services(AD DS), 여러 Region, 규제 데이터, 다수 Application Team을 보유한 가상의 글로벌 제조 기업을 대상으로 참조 아키텍처를 구성한다. 실제 고객, 회사, Tenant, Subscription, IP Address Space, Production 설정과는 관련 없는 합성 시나리오다. 의사결정 프레임워크로 활용하되, 실제 도입 전에는 조직의 요구사항과 최신 Microsoft Cloud Adoption Framework Azure Landing Zone 가이드를 기준으로 모든 선택을 다시 검증해야 한다.

1. 올바른 관점에서 시작한다

Microsoft는 Azure Landing Zone을 대규모 Azure 환경을 준비하는 표준화된 권장 접근 방식으로 설명한다. 개념 아키텍처에는 서로 연결된 두 종류의 Landing Zone이 있다.

• Platform Landing Zone은 Identity Connectivity, Network Connectivity, Management, Security Operations 같은 공통 기능을 제공한다.
• Application Landing Zone은 실제 Workload를 수용한다. 일반적으로 Application Environment, 소유권, 위험, 수명주기에 따라 나눈 Subscription 형태다.

따라서 Platform은 공통으로 보이는 모든 Resource를 모아 두는 장소가 아니다. Workload Subscription을 안전하게 사용할 수 있도록 제공하는 관리형 서비스다. Application Team에는 빈 Subscription과 아키텍처 그림이 아니라, Identity 경계, Network 연결, Policy 기준선, Logging 경로, Budget, Support 창구가 준비된 Subscription이 전달되어야 한다.

Resource 제어 계층과 Identity 계층도 구분해야 한다.

Microsoft Entra tenant
  └─ 사용자, Application, Managed Identity를 인증

Azure Resource Manager tenant scope
  └─ Management Group
       └─ Subscription
            └─ Resource Group
                 └─ Resource

두 계층은 상호작용하지만 서로 대체할 수 없다. Microsoft Entra Role은 Directory 기능을 관리하고, Azure Role-Based Access Control(RBAC)은 Azure Resource 작업을 인가한다. Subscription은 Billing, Quota, Deployment, Management 경계지만 유일한 보안 경계로 간주해서는 안 된다. Network Segmentation, Identity Permission, Data-plane Authorization, Policy, Workload Control이 함께 작동해야 한다.

초기 설계 오류를 줄이려면 다음 세 개념을 정확히 구분해야 한다.

개념	목적	이것은 아님
AD DS	Kerberos, NTLM, LDAP, Group Policy, Domain Join을 제공하는 전통적 Domain Service	Azure Resource Control Plane
Microsoft Entra ID	사용자, Application, Device, Service를 위한 Cloud Identity와 Access	모든 AD DS 기능의 직접 대체재
Azure Resource Manager	Resource 배포와 Governance에 사용하는 일관된 Azure Control Plane	Identity Directory 또는 Workload Data Plane

Microsoft Entra Domain Services는 Domain Join, LDAP, Kerberos, NTLM 호환 기능이 필요한 Workload를 위한 Managed Domain Service 선택지다. 기존 Enterprise Forest를 확장할 때 항상 적용하는 기본 답안은 아니며, 모든 Legacy Identity 의사결정을 없애 주지도 않는다.

2. Landing Zone 프로그램이 필요한지 판단한다

모든 Azure 환경에는 기본 Governance가 필요하지만, 모든 환경에 같은 규모의 Platform 조직이 필요한 것은 아니다. 격리된 소규모 실험이라면 Subscription 하나, 소수의 Audit Policy, Budget, 명시된 Owner로 충분할 수 있다. 다음 요구가 실제로 존재하고 여러 팀이 반복 가능한 환경을 필요로 할 때 Landing Zone 프로그램의 가치가 커진다.

• Hybrid Connectivity와 Name Resolution
• 중앙 Identity 및 Privileged Access 통제
• 여러 Workload Environment 또는 Business Unit
• 규제 분리 또는 Data Residency
• 중앙 Logging과 Incident Response
• 재사용 가능한 Policy, Security, Cost Guardrail
• Subscription 수명주기 자동화
• 인수·분할 또는 복잡한 기존 Azure 환경

단순 Resource 수보다 더 중요한 신호는 Platform이 다뤄야 할 소유권 경계, Compliance Profile, Connectivity Path, 수명주기 Event의 개수다.

Landing Zone은 고객, Owner, Roadmap, Feedback Loop를 가진 Product로 운영해야 한다. Platform Product는 지원 Pattern을 공개하고, Adoption을 측정하며, 요구사항 변화에 맞춰 안전한 표준 경로인 Paved Road를 개선할 수 있다.

3. Module을 고르기 전에 Architecture Design Session을 진행한다

Architecture Design Session의 목적은 Business와 기술 제약을 실제 의사결정으로 바꾸는 것이다. Portal Accelerator, Bicep Module, Terraform Module, Network Appliance를 선택하기 전에 진행해야 한다.

최소한 Cloud Platform, Security, Identity, Network, Operations, Finance, Compliance, Application Delivery 담당자가 참여해야 한다. 다음 질문에 추측이 아닌 근거로 답한다.

1. Business와 Geography: 사용자, 공장, 지사, 고객은 어디에 있는가? 중요 Workload와 Recovery Objective는 무엇인가?
2. Identity: 어떤 Forest와 Tenant가 존재하는가? 사용자는 어떻게 동기화되는가? LDAP, Kerberos, Legacy Service Account에 의존하는 Application은 무엇인가?
3. Network: 어떤 Address Space가 할당되어 있는가? 어떤 Site가 Azure에 연결되는가? DNS, Ingress, Egress, Inspection은 어디서 통제하는가?
4. Governance: 적용 규정, Data Classification, 허용 Region, Tagging Rule, Ownership Standard는 무엇인가?
5. Operations: 누가 Platform을 상시 Monitoring하는가? Ticketing, Incident, Backup, Change Process는 어떻게 구성되어 있는가?
6. Delivery: 승인된 Source Control과 CI/CD System은 무엇인가? 누가 Platform 변경을 Review하고 Release하는가?
7. Commercial Constraint: Billing Agreement, Quota, License, Cost Allocation 요구사항은 무엇인가?

Session의 결과가 Slide Deck 하나로 끝나서는 안 된다. Target Architecture, Scope Hierarchy, Identity와 Connectivity 결정, Policy와 Logging Baseline, Responsibility Model, Exception Process, Automation 방식, Migration 순서, Decision Log가 최소 산출물이다.

환경 유형도 솔직하게 구분해야 한다. Greenfield는 Workload 유입 전에 계층과 자동화를 만들 수 있다. Brownfield는 기존 Subscription, Role Assignment, Policy, Route, Diagnostic Setting, Identity Dependency, Production Owner를 먼저 찾아야 한다. Brownfield에서 종속성 분석 없이 목표 계층부터 강제하면 Policy 상속, Connectivity, 운영 소유권이 끊길 수 있다.

4. 여덟 개 설계 영역을 빠짐없이 다룬다

Cloud Adoption Framework 설계 영역은 아키텍처가 Network 또는 Policy 한쪽에만 치우치지 않도록 돕는다.

설계 영역	반드시 명시할 결정
Billing and tenant	계약, Tenant 소유권, Subscription 생성, Quota, Chargeback
Identity and access	인증, 동기화, RBAC, PIM, Emergency Access, Workload Identity
Resource organization	Management Group, Subscription 목적, Naming, Tag, 수명주기
Network topology and connectivity	Hub Model, Routing, DNS, Ingress, Egress, Private Access, Hybrid Link
Security	Posture Management, Workload Protection, Data Protection, Incident 소유권
Management	Inventory, Monitoring, Logging, Backup, Patching, Recovery, Support
Governance	Policy 계층, Compliance Evidence, Exemption, Remediation
Platform automation and DevOps	Repository, Module, Pipeline, State, Approval, Test, Drift

또한 Microsoft의 Azure Landing Zone 설계 원칙에 제시된 다섯 가지 원칙을 기준으로 판단한다.

1. Subscription Democratization: Guardrail 안에서 Subscription을 확장과 자율 운영의 기본 단위로 제공한다.
2. Policy-driven Governance: 사람의 점검표보다 Azure Policy를 통해 기준을 감사하고 배포하며 적용한다.
3. Single Control and Management Plane: Azure Resource Manager라는 공통 Control Plane을 사용한다.
4. Application-centric Service Model: 개별 Server보다 Application과 전체 수명주기를 중심으로 Platform Service를 구성한다.
5. Azure-native Alignment: 명확한 요구사항이 다른 선택을 정당화하지 않는 한 Azure 기본 기능과 Roadmap에 맞춘다.

이 원칙은 모든 상황에 적용하는 구호가 아니라 기본 방향이다. 원칙에서 벗어난다면 요구사항, 비용, 운영 영향, 예외를 종료할 조건까지 Decision Record에 남긴다.

5. 목표 운영 모델을 정의한다

이 참조 기업은 중앙 Guardrail과 분산된 Workload Delivery를 결합한다.

Corporate Microsoft Entra tenant
│
├─ Platform management groups
│  ├─ Identity subscription
│  ├─ Connectivity subscription
│  └─ Management/Security subscription
│
└─ Landing Zones management groups
   ├─ Corp       -> Corporate 또는 Hybrid Connectivity가 필요한 Workload
   ├─ Online     -> Internet-facing 또는 Cloud-native Workload
   ├─ Regulated  -> 추가 승인 Control Profile이 적용되는 Workload
   ├─ Sandbox    -> 제약된 실험 환경
   └─ Decommissioned -> 종료 전 격리된 Subscription

Platform Team은 계층, Shared Service, Subscription Vending Product, Platform Code를 소유한다. Security Team은 Security Standard와 Detection 요구사항을 소유하되 구현은 관련 팀과 협업한다. Identity와 Network Team은 각 Domain을 맡는다. Workload Team은 Subscription 안의 Application Resource, Data, Remediation, Availability를 책임진다. Finance는 비용 배부와 Reporting 기준을 정의하고, Compliance는 Control이 의무사항을 충족하는지 검증한다.

6. 기본값은 하나의 Corporate Tenant로 둔다

대부분 기업에는 하나의 Corporate Microsoft Entra Tenant가 가장 합리적인 출발점이다. 여러 Azure Subscription에 일관된 Identity Policy, Collaboration, Administrative Governance, Visibility를 적용할 수 있기 때문이다. Microsoft의 Multi-tenant 가이드도 기존 Tenant에서 충족할 수 없는 요구가 있을 때만 추가 Tenant를 검토하도록 권장한다.

법적 격리, Sovereign 또는 National Cloud 요구, 기업 분할 경계, 아직 통합할 수 없는 인수 기업은 유효한 예외가 될 수 있다. 하지만 “Business Unit이 독립을 원한다”는 이유만으로는 충분하지 않다. Tenant가 하나 늘어날 때마다 Privileged Role, Emergency Account, Application Registration, Policy Surface, License, Log, Cross-tenant Access, Incident Response Path가 함께 늘어난다.

추가 Tenant를 제안할 때는 기존 Tenant로 충족하지 못하는 요구, Identity와 Collaboration Experience, Cross-tenant Administration, Incident Response, 비용, 예상 존속 기간, 통합 또는 분할 계획을 기록한다.

Tenant 통합이 광범위한 권한 부여를 뜻하지는 않는다. Administrative Unit, Group, PIM Eligible Role, Access Review, Conditional Access, Azure RBAC Scope로 책임을 위임한다. Directory Administration과 Azure Resource Administration을 분리하고, 가장 강력한 Role에는 독립적인 승인을 요구한다.

7. Management Group 계층은 얕고 Policy 중심으로 만든다

Management Group은 Subscription 위의 Governance Scope다. 조직도에 상자가 있기 때문이 아니라, 여러 Subscription에 공통 Policy 또는 Access를 적용해야 할 때 만들어야 한다. Microsoft의 Management Group 가이드는 Azure의 기술적 최대 깊이와 별개로 대부분 환경에서 3~4단계의 얕은 계층을 권장한다.

이 참조 기업에는 다음 계층이 적합하다.

Tenant root
├─ Platform
│  ├─ Identity
│  ├─ Connectivity
│  └─ Management
├─ Landing Zones
│  ├─ Corp
│  ├─ Online
│  └─ Regulated
├─ Sandbox
└─ Decommissioned

상위에는 허용 Identity Model, Activity Log Export, 필수 Security Contact, 전역 금지 설정처럼 넓고 보편적인 Control을 할당한다. 하위에는 Corp의 Hybrid DNS 요구, Online의 Public Ingress 제한, Regulated의 추가 Encryption과 Logging Profile처럼 Archetype별 Control을 배치한다.

현재 Microsoft 참조 계층에는 Azure Local Workload를 위한 Local Archetype도 포함된다. 이 합성 시나리오에서 Local을 생략한 이유는 Azure Local을 사용하지 않기 때문이며, 일반적으로 해당 Archetype이 불필요하다는 의미가 아니다.

부서, Application, Cost Center마다 Management Group을 만들지 않는다. 비용 Reporting에는 Tag와 Billing Data가 더 적합하고, Workload 수명주기 경계에는 Subscription이 더 적합하다. Subscription 이동은 상속 Policy와 RBAC를 바꿀 수 있으므로 영향 분석과 Review를 거친 변경으로 취급한다.

일반 Workload를 Tenant Root 또는 Platform Branch 아래 두지 않는다. 새 Subscription이 관리되지 않는 기본 위치에 장기간 남지 않도록 자동 배치 또는 격리 절차도 정의한다.

8. Subscription을 Workload 확장의 단위로 사용한다

Application Landing Zone은 일반적으로 Workload Environment를 Subscription에 대응시킨다. Access, Change, Quota, Cost, Incident 요구가 다르다면 Production과 Non-production을 분리한다. 엄격한 규제 데이터, 고위험 Internet Exposure, 큰 Region 차이도 Subscription 추가 분리를 정당화할 수 있다. 그림의 대칭을 맞추기 위한 분리는 피한다.

AI Workload라는 이유만으로 별도의 Management Group 계층이나 독립된 “AI Landing Zone”을 기본 생성하지 않는다. 기존 Corp, Online, Regulated Archetype으로 필요한 Guardrail을 표현할 수 있는지 먼저 확인한다. Model Access, Data Boundary, GPU Quota, Content Safety, AI Monitoring처럼 실질적으로 다른 Control과 운영 수명주기가 반복된다면 그때 별도 Platform Product 또는 Archetype을 만들고, 차이를 Policy와 Responsibility Model로 명시한다.

Subscription Record에는 다음 정보가 필요하다.

항목	의미
Workload와 Environment	Service 소유권과 수명주기 식별
Business Owner와 Technical Owner	책임과 Escalation 경로 확립
Management Group Archetype	상속할 Guardrail 집합 선택
Data Classification	추가 Control과 Evidence 결정
Region과 Connectivity Class	Address, DNS, Route, Hub 연결 선택
Cost Center와 Budget	비용 배부와 Alert 수신 경로 설정
Recovery Tier	Platform Dependency와 Workload RTO/RPO 연결
만료일 또는 Review Date	방치된 Sandbox와 임시 환경 방지

표시 이름만 System of Record로 쓰지 말고 안정적인 내부 Subscription Identifier 또는 Alias를 사용한다. 이름은 사람이 읽기 쉽게 만들되 바뀔 수 있는 모든 속성을 인코딩하지 않는다. Resource Tag는 Operations와 Finance를 지원하지만 Network 또는 Access 격리를 강제하지는 않는다. Policy와 Permission으로 제한하지 않으면 수정될 수도 있다.

Subscription Vending은 신청서가 아니라 서비스다

Subscription Vending은 통제된 Subscription을 Programmatic하게 발급하고 설정하는 과정이다. 요청을 검증하고, 위험에 맞는 승인을 거쳐, 올바른 Billing Scope에 Subscription을 생성하고, 적절한 Management Group에 배치한 뒤, 기본 구성을 완료해서 인계해야 한다.

Workload request
  -> Schema와 Ownership 검증
  -> 위험 기반 승인
  -> Subscription 생성과 배치
  -> 기본 RBAC, Budget, Tag, Logging, Network, Policy 구성
  -> 자동 검증
  -> 문서와 Support 경로를 포함해 인계

Vending은 생성뿐 아니라 변경과 종료도 지원해야 한다. Workload Team이 Quota, Network, Policy Exemption, Owner 변경, 신규 Environment를 요청할 수 있어야 한다. 종료 시에는 Access 회수, 필수 기록 보존, Connectivity 해제, Resource 정리, Billing 확인을 거쳐 Subscription을 닫는다.

9. Hybrid Identity를 사후 작업이 아닌 선행 종속성으로 설계한다

이 참조 기업은 일부 Application이 Kerberos, LDAP, Group Policy, Domain Join에 의존하므로 AD DS를 유지한다. Azure 내 복원력이 필요하다면 지원되는 새 Domain Controller를 Azure에 구축해 Domain을 확장하는 것이 안전한 Pattern이다. 실행 중인 On-premises Domain Controller VM을 일반 Server Image처럼 복사하거나 Lift하지 않는다.

Azure Domain Controller는 전용 Identity Subscription과 Subnet에 두고, 관리 Access를 제한하며, AD Sites and Services에 통합한다. DNS도 명시적으로 설계한다. Time Synchronization, Backup과 Recovery 절차, Replication Path, Monitoring, 운영 Owner를 확인한다. Domain Controller를 범용 Management Host로 사용해서는 안 된다.

Microsoft Entra Synchronization은 실제 Feature 요구사항에 맞춰 선택한다. Microsoft Entra Cloud Sync는 Lightweight Agent와 Cloud-managed Configuration을 사용하며 많은 Hybrid Scenario에서 Microsoft가 제시하는 전략적 방향이다. 반면 Cloud Sync가 충족하지 못할 수 있는 요구는 Microsoft Entra Connect Sync가 계속 지원한다. 어느 한쪽을 보편적으로 우월하다고 단정하지 말고 최신 기능 비교 및 의사결정 가이드를 확인한다.

Password Hash Synchronization은 복원력 있는 인증 선택지가 될 수 있지만, 규제 요구, Federation Dependency, Passwordless 계획, 비상 운영까지 고려해야 한다. 정상 경로만 확인하지 말고 On-premises Connectivity와 Agent가 각각 손실되는 상황을 시험한다.

10. Privileged Access와 Workload Access를 통제한다

관리자는 조직 설계에 따라 전용 Privileged Identity를 사용하고, 지원되는 곳에서는 Phishing-resistant Authentication을 적용한다. 구성과 License가 지원하는 범위에서 Privileged Identity Management(PIM)로 시간 제한 Activation을 사용한다. Directory Role과 Azure RBAC Role을 구분한다. VM 운영자에게 Global Administrator가 필요한 경우는 드물고, Identity 관리자에게 Subscription Owner가 필요한 경우도 드물다.

Role은 Group에 할당하고 Scope를 좁게 유지하며 영구 Owner 할당을 피한다. Management Group Scope의 단일 할당이 여러 Subscription에 영향을 줄 수 있으므로 상속 Access를 Review한다. Role Assignment, Policy Exemption, Managed Identity, Credential, Network 변경 권한도 Privileged Action으로 보호한다.

Microsoft의 최신 지침에 따라 Monitoring되는 Emergency Access Account를 두 개 이상 유지한다. Cloud-only 계정으로 만들고, 전체 Lockout을 유발할 수 있는 Control에서만 제한적으로 제외하며, 강력한 인증 수단으로 보호하고 문서화된 절차에 따라 시험한다. Emergency Account는 편의용 관리자 계정이 아니다.

Application에는 저장된 Client Secret보다 Managed Identity와 Workload Identity Federation을 우선한다. Deployment Identity는 Environment와 Trust Boundary별로 분리한다. Development 배포 Pipeline이 Production 또는 Platform 계층까지 자동으로 변경할 수 있어서는 안 된다. 과도한 Permission은 Credential Rotation만으로 보완되지 않는다.

11. 운영 요구사항을 기준으로 Network Topology를 선택한다

Hub-and-spoke와 Azure Virtual WAN은 모두 유효한 Pattern이다. 선호하는 그림이 아니라 Connectivity 규모, Routing 요구, Appliance 통합, Global Operations, Automation 성숙도, 비용을 기준으로 선택한다.

Hub-and-spoke

고객이 관리하는 Hub Virtual Network는 Routing, Firewall, Gateway, DNS, Shared Service를 명시적으로 통제할 수 있다. 그 대신 Peering, Route, High Availability, Region 확장을 자동화하고 운영할 책임도 커진다.

Azure Virtual WAN

Virtual WAN은 Branch, VPN, ExpressRoute, Security 기능이 통합된 Managed Global Transit Architecture를 제공한다. Custom Routing 작업을 줄일 수 있지만 Route Intent, Inspection, DNS, Resilience, Cost는 여전히 세심하게 설계해야 한다.

어느 Pattern을 선택하든 Provisioning 전에 다음 질문에 답한다.

• Global IP Address Management는 누가 소유하며 중복을 어떻게 방지하는가?
• 어떤 Traffic이 반드시 Inspection을 거쳐야 하고 어떤 예외가 정당한가?
• Internet Ingress, Outbound Egress, TLS Termination은 어디에서 이루어지는가?
• Private Endpoint는 Azure, On-premises, Developer Network에서 각각 어떻게 이름을 해석하는가?
• Subscription 생성과 종료에 맞춰 Route와 DNS Record를 어떻게 추가하고 제거하는가?
• Hub, Circuit, DNS Resolver, Firewall, Region이 실패하면 무엇이 계속 동작하는가?

Address Space는 Enterprise IPAM Process를 통해 할당하고 성장과 인수를 위한 공간을 남긴다. 중복 Network는 Peering, Hybrid Routing, Private Endpoint, Disaster Recovery를 복잡하게 하며 뒤늦은 Renumbering은 비용이 크다.

Private Access에는 DNS Engineering이 필요하다

Private Endpoint는 Platform Service에 Private Network Interface를 할당하지만, 올바른 Name Resolution까지 자동으로 보장하지는 않는다. Private DNS Zone, Link, Forwarding, Record 수명주기, Split-horizon 동작, On-premises Resolution을 하나의 System으로 설계한다. 관련 Resolver Path마다 Service의 Public Name을 조회해 의도한 Private Address로 해석되는지 확인한다.

ExpressRoute 역시 Private Connectivity이지 완전한 Encryption 또는 Security Architecture는 아니다. Confidentiality 요구, Route Filtering, Inspection, DDoS Protection, Service별 Control을 별도로 평가한다.

12. Azure Policy를 Code로 관리하고 단계적으로 적용한다

Azure Policy는 Platform의 의도를 대규모로 시험할 수 있게 한다. Resource 상태를 평가하고 Effect에 따라 Audit, Modify, 지원 설정 배포, Deny를 수행한다. Secure Application Code, Network Design, RBAC를 대체하는 수단은 아니다.

DeployIfNotExists와 Modify Assignment가 Resource를 변경하려면 Managed Identity와 필요한 Role이 있어야 한다. 기존 Non-compliant Resource에는 명시적인 Remediation Task도 필요하다. Policy Assignment만 생성했다고 과거 Drift가 자동으로 복구되는 것은 아니다. Deny는 적용 대상인 신규 또는 변경 요청을 차단하지만 기존 Resource를 소급해 다시 쓰지 않는다.

서로 무관한 정의 수백 개를 모으기보다 결과 중심의 Initiative를 구성한다.

• 허용 Region과 Resource Type
• 필수 Ownership 및 Data Classification Metadata
• 지원 Resource의 Diagnostic Export
• Workload Archetype별 Private Access와 Public Network 제한
• Encryption과 Key Management 요구
• Security Baseline에 필요한 Defender for Cloud 구성

적용 순서는 통제한다.

Definition과 Unit Test
  -> 대표 Scope에서 Audit
  -> False Positive와 기존 Non-compliance 평가
  -> Effect가 지원하는 범위에서 Remediation
  -> 신규 배포에 Deny Pilot
  -> Monitoring과 Rollback을 포함해 적용 범위 확대

영향 분석 없이 Tenant Root에 광범위한 Deny Assignment를 켜지 않는다. 기존 Resource, Deployment Tooling, Region별 Feature Availability, Managed Service 동작 때문에 단순해 보이는 Policy도 장애를 일으킬 수 있다.

Exemption은 구두 합의가 아니라 Governance 대상 Object다. Business Owner, Technical Owner, 사유, Risk Acceptance, Compensating Control, 영향 Scope, 승인, 만료일, Review Evidence를 기록한다. 만료된 Exemption은 Alert를 발생시키고 자동으로 재검토 상태로 돌아가야 한다.

13. Data Protection과 Key Management를 아키텍처로 다룬다

Control을 선택하기 전에 Data를 분류한다. Workload마다 Confidentiality, Integrity, Retention, Residency, Recovery, Deletion 요구를 확인하고 Encryption, Key Ownership, Access, Backup, Logging을 결정한다.

Azure Key Vault는 Control Plane과 Data Plane Permission이 분리되어 있다. Vault Resource를 관리하는 권한이 모든 Secret과 Key에 접근하는 권한을 자동으로 의미해서는 안 된다. Service와 조직 모델에 맞는 경우 Azure RBAC를 우선하고, Managed Identity를 사용하며, 필요에 따라 Network Access를 제한하고, 적절한 Recovery Protection과 민감 작업 Monitoring을 설정한다.

새 Vault에는 Soft Delete가 기본 활성화되며 한 번 활성화하면 끌 수 없다. Purge Protection은 별도 결정이다. Service Default가 조직의 삭제와 복구 Control을 충족한다고 가정하지 말고 두 설정, Retention 영향, Recovery 절차를 확인한다.

Customer-managed Key는 추가 책임을 만든다. Control 요구를 충족할 수 있지만 Key Permission, Rotation, Availability, Recovery, 종속 Service 동작을 조직이 운영해야 한다. Incident 중 Key에 접근하지 못하면 Availability 장애가 될 수 있다. Key를 비활성화하거나 삭제할 수 있는 사람, 비상 복구 방법, 종속 Workload 시험 방법을 문서화한다.

Storage Protection은 Encryption at Rest뿐 아니라 Data-plane Authorization과 Exfiltration Path까지 포함해야 한다. 지원되는 경우 Shared Key보다 Identity-based Access를 우선하고, Public Exposure를 제한하며, 요구사항에 따라 Lifecycle과 Immutability 기능을 사용하고, Restore를 시험한다. Backup 성공 메시지만으로 Application이 목표 시간 안에 복구된다는 사실은 증명되지 않는다.

14. Posture Management, Logging, Detection을 연결한다

Microsoft Defender for Cloud는 Cloud Security Posture Management를 제공하고, 관련 Plan이 활성화된 경우 지원 Resource에 Workload Protection을 제공할 수 있다. Recommendation과 Secure Score는 우선순위 판단 자료로 사용한다. Score가 높다고 Environment가 안전하다고 증명되는 것은 아니며, Score가 낮다고 모든 Recommendation의 위험이 같다는 뜻도 아니다.

Exploitability, Exposure, Asset Value, Attack Path, Compensating Control, Remediation Effort를 함께 고려해 Finding의 우선순위를 정한다. 소유권도 명확히 한다. 누락된 Platform Diagnostic Setting은 Platform Team이 처리할 수 있지만 취약한 Container Image는 Workload Team의 책임이다.

Telemetry Architecture를 구성한다

Data Source와 Routing Mechanism을 구분한다.

• Azure Activity Log는 Subscription Level Control-plane Event를 기록한다.
• Resource Log와 Metric은 지원되고 활성화된 Service별 Event를 제공한다.
• Diagnostic Setting은 지원되는 Platform Data를 Log Analytics, Storage, Event Hubs 같은 Destination으로 보낸다.
• Data Collection Rule은 Azure Monitor Agent와 Custom Log 등 지원 Source의 Collection Pipeline을 정의한다.
• Microsoft Sentinel은 연결된 Data를 기반으로 Analytics, Hunting, Incident, Automation을 제공한다.

현재 신규 구현에서는 Microsoft Defender Portal을 Microsoft Sentinel의 기본 Experience로 사용해야 한다. Microsoft는 Azure Portal의 Sentinel 지원이 2027년 3월 31일 종료된다고 안내한다. 따라서 운영 Runbook은 쉽게 바뀌는 Portal 클릭 순서보다 기능과 API를 중심으로 작성한다. 최신 내용은 Microsoft Sentinel Defender Portal 전환 가이드에서 확인할 수 있다.

Identity, Control-plane, Network, Workload Signal
  -> 문서화된 수집과 변환
  -> Workspace 또는 Streaming/Archive Destination
  -> Detection과 Correlation
  -> Incident 소유권과 대응
  -> 보존된 Evidence와 개선 사항

Centralization이 모든 Byte를 하나의 Workspace로 전송한다는 뜻은 아니다. Residency, Access, Retention, Query, Incident, Cost 요구를 기준으로 Workspace Topology를 설계한다. 합성 Event를 사용해 Ingestion부터 Incident 종료까지 전체 경로의 Detection을 시험한다.

15. Platform 종속성을 포함해 Operations와 Recovery를 설계한다

Landing Zone Availability는 VM 이중화만으로 만들어지지 않는다. Workload는 Entra Authentication, DNS, Hub Routing, Firewall, Private DNS Zone, Secret, Deployment Pipeline, Monitoring, Platform Support에 의존할 수 있다. 이 종속성을 Workload Recovery Objective와 연결한다.

Operations Baseline에는 다음 항목이 필요하다.

• Inventory와 Configuration Visibility
• Service Health와 Resource Health Routing
• Platform 및 Workload Alert 소유권
• Patching과 Vulnerability Remediation
• Backup Policy와 Restore Test
• Capacity, Quota, Certificate, Secret, Key 만료 Monitoring
• Identity, Network, Policy, Logging Failure Runbook
• Escalation과 Vendor Support 절차

Availability Zone과 Multi-region은 Business Objective가 복잡성과 비용을 정당화할 때만 사용한다. Secondary Region이 있어도 Identity, Data Replication, Network, DNS, Secret, Deployment Artifact, 운영 절차가 정렬되고 시험되지 않았다면 Recovery Solution이 아니다.

안전한 Scope에서 Failure Exercise를 실행한다. DNS Forwarder 장애, Private Endpoint Resolution 실패, Hybrid Connectivity 손실, Deployment Credential 만료, 긴급 배포를 막는 Deny Policy, Logging Destination 장애 등을 시험할 수 있다. Detection, 판단, 복구, Communication에 걸린 시간을 각각 기록한다.

16. FinOps와 책임을 Platform에 포함한다

Cost Management는 Subscription 발급 시점부터 시작한다. Cost Center, Owner, Environment, Budget, 예상 수명을 필수로 받는다. Budget Alert는 행동할 수 있는 사람에게 보내야 하며, Budget은 일반적으로 알림 수단이지 지출을 강제 중단하는 상한선이 아니라는 점을 기억한다.

팀에 Actual Cost, Forecast, Anomaly, Commitment, Idle Resource를 정기적으로 제공한다. Hub Firewall, ExpressRoute, Shared Monitoring, Defender Plan, Data Retention 같은 Platform Cost에는 명시적 배부 모델이 필요하다. 그렇지 않으면 소비자에게 Shared Platform은 무료처럼 보이고 소유 팀에는 예상치 못한 비용으로 남는다.

간결한 책임 모델은 다음과 같이 구성할 수 있다.

Capability	Accountable Owner	주요 협업자
Tenant Identity와 Privileged Role	Identity	Security, Platform, Audit
Management Group과 Subscription Vending	Platform	Finance, Security, Workload Team
Hybrid 및 Cloud Network	Network	Platform, Security, Application Owner
Policy와 Control Standard	Security/GRC	Platform, Identity, Network
Security Monitoring과 Incident Response	Security Operations	Platform, Workload Team
Application Reliability와 Data	Workload Owner	Platform, Security, Business Owner
Cost Allocation과 Optimization	Finance/FinOps	Platform, Workload Owner

조직에 따라 RACI는 달라질 수 있지만 모든 Control에는 최종 책임자와 운영자가 있어야 한다.

17. Infrastructure as Code로 Landing Zone을 구현한다

Portal 기반 배포는 개념을 익히거나 초기 Demonstration을 만드는 데 유용하다. 하지만 Enterprise Platform에는 반복 가능성, Review, Test, 추적 가능한 변경이 필요하다. Microsoft의 구현 옵션은 Azure Landing Zone IaC Accelerator와 Bicep 또는 Terraform용 Azure Verified Modules를 지원되는 출발점으로 권장한다.

Bicep과 Terraform 중 무엇을 선택할지는 운영 기술, 승인 Tooling, State Management 요구, 전체 Portfolio를 기준으로 판단한다. 둘 다 좋은 Platform을 만들 수 있지만, 어느 쪽도 불명확한 아키텍처를 대신 해결하지는 못한다.

Repository는 관심사를 분리한다.

platform-live/        # Environment 조합과 승인 Parameter
platform-modules/     # 재사용 가능한 Versioned Module
policy-library/       # Definition, Initiative, Test, Exemption
subscription-vending/ # Request Schema와 Lifecycle Automation
validation/           # Static Check, Policy Test, Deployment Test
runbooks/             # Recovery와 운영 절차

Repository 개수 자체보다 Ownership과 Release Boundary가 명확한지가 중요하다. Module Version을 고정하고 Upstream 변경을 Review하며, 대표 Non-production Scope에서 검증한 Release만 Production으로 승격한다.

Terraform Remote State는 Encryption, 좁은 Data-plane Access, Versioning 또는 Recovery Control, Locking으로 보호한다. Blast Radius를 제한하도록 State Boundary를 나눈다. Bicep에서는 Deployment Identity와 Deployment History를 보호하고 Module Registry와 Versioning을 의도적으로 설계한다. 두 방식 모두 Secret이 Parameter, Plan, State, Pipeline Log, Artifact에 노출되지 않게 한다.

Enterprise Pipeline에는 다음 단계가 필요하다.

1. Formatting, Linting, Schema Validation
2. Static Security와 Policy Check
3. Module과 Dependency Provenance Check
4. Plan 또는 What-if 생성
5. Privileged 또는 Production 변경에 대한 Human Review
6. Scope가 좁은 Workload Identity로 배포
7. Post-deployment Test와 Evidence Capture
8. Drift Detection과 소유자가 있는 Remediation 경로

일상적인 Portal 변경이 보이지 않는 두 번째 Source of Truth가 되지 않게 한다. Emergency Change는 Break-glass Process를 거치고 이후 반드시 Code에 반영한다.

18. 비용을 통제한 Proof of Concept를 구성한다

좋은 PoC는 Production인 척하지 않고 운영 모델을 검증한다. 완전히 구현한 Control과 Demonstration만 한 Control을 구분해 명시한다.

최소 PoC 범위

• 얕은 Management Group 계층과 분리된 Platform/Application Scope
• 자동 Validation이 있는 Subscription Vending Request Schema 하나
• 소규모 Audit-mode Policy Initiative와 Group-based RBAC
• Activity Log Routing과 선택된 Diagnostic Setting
• 대표 Network와 Private DNS Path
• Budget Alert, Ownership Metadata, 기한이 있는 Exemption
• Plan, Approval, Deployment, Validation, Redacted Evidence를 포함한 CI/CD 경로

화면 캡처를 위해 모든 유료 Security Plan을 켜거나, 대량 Log를 무기한 보관하거나, Multi-region Transit을 배포하지 않는다. 배포 전에 반복 비용을 산정하고 Alert와 Lab 만료일을 설정하며, 생성에 사용한 동일한 Automation으로 Resource를 제거한다.

PoC는 핵심 설계 위험에 답할 때 성공한다. 새 Subscription이 의도한 Guardrail을 상속하는가? Application Owner가 그 안에서 배포할 수 있는가? Private DNS가 End-to-end로 동작하는가? 차단된 변경을 관찰할 수 있는가? 승인된 예외가 만료되는가? Platform을 재생성하고 안전하게 제거할 수 있는가?

19. 통제된 Wave로 Migration한다

Brownfield Landing Zone 도입은 즉시 재배치하기보다 Discovery와 Containment에서 시작해야 한다.

Wave 0: Discover

Tenant, Subscription, Management Group, Role Assignment, Policy, Connectivity, DNS, Log, Security Tooling, Cost, Owner, Quota, 중요 Dependency를 Inventory한다. 소유권 미확인은 빈 Spreadsheet Cell이 아니라 Risk로 표시한다.

Wave 1: Platform Minimum 확립

Target Hierarchy, Platform Ownership, Identity Control, Policy Library, Log Routing Baseline, Network Foundation, Subscription Vending Path, Exception Process를 만든다. 처음에는 영향이 적은 Control로 배포하고 운영 준비 상태를 검증한다.

Wave 2: Pilot Workload

대표성이 있으면서 복구 가능한 Workload를 선택한다. 해당 Pattern이 존재한다면 Hybrid Workload, Cloud-native Workload, 더 엄격한 Data 요구를 가진 Workload를 최소 하나씩 포함한다. 불필요한 마찰을 측정하고 Paved Road를 개선한다.

Wave 3: Archetype별 Migration

Network, Identity, Regulation, Operating Pattern이 유사한 Workload를 묶는다. Subscription 이동 또는 Deny 적용 전에 Dependency를 Remediate한다. Wave마다 Rollback, Support, Communication Plan을 명시한다.

Wave 4: Enforce and Optimize

Compliance Evidence를 확보한 뒤 Deny Control을 확대하고, Drift를 해결하며, Standing Privilege를 줄인다. Telemetry를 조정하고 Lifecycle Operation을 자동화하며 기존 경로를 종료한다.

각 Wave에는 Exit Criteria가 필요하다. Named Owner, 검증된 Access, 확인된 DNS와 Route, 성공적인 Log Ingestion, Policy Compliance 또는 승인된 Exemption, Cost Allocation, 필요 시 Backup Restore Evidence, Deployment Path Validation, 승인된 Recovery Plan을 기준으로 사용할 수 있다.

20. Resource 존재 여부가 아니라 품질 속성을 검증한다

Deployment가 succeeded를 반환했다고 운영 가능한 것은 아니다. 다음 품질 속성으로 아키텍처를 시험한다.

품질	시험 예시
Security	Developer가 Privileged Role을 할당하거나 필수 Ingress Control을 우회할 수 없다
Reliability	DNS 또는 Network Component 손실 시 문서화된 Recovery Path가 동작한다
Operability	On-call Engineer가 Alert의 Owner와 관련 Signal을 찾을 수 있다
Scalability	여러 Subscription Request를 Manual Drift 없이 일관되게 처리한다
Maintainability	Module 또는 Policy Version을 단계적 Scope를 거쳐 Upgrade한다
Cost efficiency	Owner가 실행 가능한 Budget 정보를 받고 방치 Resource를 식별한다
Compliance	민감 정보가 포함된 Screenshot 없이 필수 Evidence를 재현한다

가능한 검증은 자동화한다. Effective Policy와 Role을 Query하고, Route와 DNS를 시험하며, Diagnostic Destination과 Deployment Identity Permission을 확인하고, Alert Delivery를 검증한다. Evidence에는 Timestamp, Scope, Method, Expected/Actual Result, Reviewer, Redaction 상태를 함께 저장한다.

21. 흔한 Anti-pattern을 피한다

조직도를 Management Group으로 복제한다. 조직은 자주 바뀐다. 계층은 Governance 요구를 기준으로 만들어야 한다.

거대한 Production Subscription 하나를 사용한다. 무관한 Workload의 Quota, Access, Billing, Deployment, Incident Blast Radius가 결합된다.

Resource Group마다 Subscription을 만든다. 요구사항이 뒷받침하지 않는 과도한 분리는 운영 부담만 늘린다.

Shared Service를 한곳에 쌓아 둔다. Platform Subscription에는 명확한 Owner가 있는 Platform Capability만 두어야 한다.

첫날부터 Root-level Deny를 적용한다. Audit와 Remediation 전에 광범위하게 차단하면 Deployment와 Managed Service가 중단될 수 있다.

Owner와 Global Administrator를 영구 부여한다. 상시 광범위 권한은 Credential 탈취와 실수의 영향을 키운다.

DNS 소유권 없이 Private Endpoint를 만든다. Endpoint는 존재하지만 Client가 Public Address를 해석하거나 예측 불가능하게 실패한다.

Use Case 없이 모든 Log를 중앙 수집한다. Ingestion은 늘지만 Detection, Retention, Access, Incident Ownership은 정의되지 않는다.

Secure Score를 인증서처럼 취급한다. Posture Management Input이지 Security 또는 Compliance의 증명은 아니다.

Manual Portal을 Production Source of Truth로 삼는다. Environment를 일관되게 Review, Reproduce, Recover할 수 없다.

Budget을 지출 한도로 부른다. Alert는 Resource를 자동으로 중지하지 않으며 무분별한 자동 종료는 Reliability Risk를 만든다.

On-premises Domain Controller를 Azure로 복사한다. 지원되는 새 Domain Controller를 만들고 Replication과 Recovery를 검증해야 한다.

22. 프로젝트보다 오래 남을 결정을 기록한다

되돌리기 어렵거나 장기 비용이 큰 선택은 Architecture Decision Record(ADR)로 남긴다. 각 Record에는 Context, 검토 Option, Decision, Rationale, Consequence, Owner, Review Date, 연결된 Evidence가 포함되어야 한다.

최소한 다음 결정을 기록한다.

• Single-tenant 기본값과 승인된 Multi-tenant 예외
• Management Group 계층과 Archetype 정의
• Subscription Boundary와 Vending Lifecycle
• Hybrid Identity Synchronization과 Authentication Model
• Hub-and-spoke 또는 Virtual WAN 선택
• DNS와 Private Endpoint Architecture
• Ingress, Egress, Inspection, Hybrid Connectivity 선택
• Policy Rollout, Exemption, Remediation Process
• Workspace, Retention, Archive, Sentinel 설계
• Key Ownership과 Recovery Model
• IaC Tool, Module Strategy, Pipeline, State Boundary
• Platform/Workload Responsibility와 Cost Allocation Model

Decision Record가 있으면 담당자, 규정, Service, 조직 구조가 바뀌어도 아키텍처의 이유를 설명할 수 있다. 기억에 의존하지 않고 당시 가정을 기준으로 결정을 다시 검토할 수도 있다.

23. 마무리

좋은 Enterprise Landing Zone은 Subscription, Policy, Security Product, Architecture Box가 가장 많은 환경이 아니다. 조직의 의도를 반복 가능한 서비스로 바꾸는 환경이다. Workload Team이 환경을 요청하면 안전한 기본값을 받고, 자신의 책임을 이해하며, 불필요한 지연 없이 배포하고, 장애가 생겼을 때 지원을 받을 수 있어야 한다.

Tenant, Ownership, Hierarchy, Subscription, Connectivity 결정부터 시작한다. Identity와 DNS를 일급 Dependency로 다루고, Evidence를 통해 Policy를 단계적으로 적용한다. Telemetry를 Detection과 담당자에게 연결한다. Platform은 Code로 만들되 아키텍처 결정은 구현 Tool 밖에도 남긴다. 그다음 명확한 Exit Criteria를 가진 Wave로 Migration한다.

Azure Service와 Cloud Adoption Framework 가이드는 계속 바뀐다. Production 도입 전에는 Product Capability, Limit, License, Implementation Module을 다시 확인해야 한다. 지속 가능한 자산은 고정된 Template이 아니라 Platform 결정을 내리고, 자동화하고, 시험하고, 다시 검토할 수 있는 조직의 역량이다.

공식 참고 문서

• Azure Landing Zone이란?
• Azure Landing Zone 설계 영역
• Azure Landing Zone 설계 원칙
• Management Group과 Subscription 구성
• Subscription Vending 가이드
• Azure Landing Zone 구현 옵션
• Multi-tenant Azure Landing Zone 고려사항
• Microsoft Entra Cloud Sync란?
• Cloud Sync와 Connect Sync 선택
• Azure Policy DeployIfNotExists Effect
• Azure Key Vault Soft Delete 개요
• Microsoft Defender Portal의 Microsoft Sentinel