Microsoft AZ-900: Azure 아키텍처 및 글로벌 인프라 — 학습 가이드

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft Azure AZ-900 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

Azure의 글로벌 아키텍처는 탄력적이고 성능이 뛰어나며 규정을 준수하는 클라우드 서비스를 대규모로 제공하도록 설계되었습니다. 지역(geography), 리전(region), 가용성 영역(availability zone)의 물리적 레이아웃과 관리 그룹, 구독, 리소스 그룹, 리소스의 논리적 계층 구조를 이해하는 것은 안정적인 설계와 거버넌스의 기초가 됩니다. Azure Resource Manager가 제공하는 컨트롤 플레인은 선언적 템플릿과 결합하여 조직의 정책 및 보안 요구 사항에 부합하는 일관되고 반복 가능한 배포를 가능하게 합니다. 이 영역의 설계 결정은 가용성 목표, 데이터 상주 의무, 전 세계 사용자 경험에 직접적인 영향을 미칩니다. 올바른 중복성 모델 선택, 복합 SLA 계산, Azure Front Door, Traffic Manager, Azure CDN과 같은 글로벌 라우팅 서비스 선택은 비즈니스 연속성, 규정 준수, 성능 목표를 달성하는 데 핵심적입니다.

지역, 리전, 가용성 영역 및 리전 쌍

Azure 지역(geography)은 데이터 상주 및 규정 준수 경계를 보존하는 정의된 리전 집합입니다. 예시로는 미국, 유럽, 영국, 호주, 캐나다 등이 있으며, 별도의 규정 준수 및 연결 모델을 갖춘 소버린 클라우드도 포함됩니다. 특정 관할권 내에 유지되어야 하는 워크로드는 규제 준수 및 데이터 상주를 보장하기 위해 대상 지역(geography)에 속한 리전에 배포해야 합니다. 리전(region)은 대기 시간으로 정의된 경계 내에 배포되고 전용 저지연 네트워크를 통해 연결된 데이터 센터 집합입니다. 모든 서비스나 기능이 모든 리전에서 제공되는 것은 아니므로, 계획 초기 단계에서 용량과 기능 가용성을 확인해야 합니다. 가용성 영역(Availability Zones)을 지원하는 리전은 독립적인 전원, 냉각, 네트워킹을 갖춘 3개 이상의 물리적으로 분리된 데이터 센터 영역을 제공합니다. 영역 중복 서비스(ZRS)와 여러 영역에 걸친 아키텍처 설계는 리전 내에서 저지연 액세스를 유지하면서 데이터 센터 수준의 장애로부터 보호합니다. 모든 Azure 리전은 동일한 지역(geography) 내의 다른 리전과 쌍을 이루어 리전 쌍(예: 북유럽과 서유럽, 미국 동부와 미국 서부)을 형성합니다. 리전 쌍은 광범위한 중단 발생 시 우선적인 복구, 단계적인 플랫폼 업데이트, 특정 서비스의 데이터 복제를 가능하게 합니다. Azure Storage의 지역 중복 옵션(GRS/GZRS)은 쌍을 이루는 리전으로 데이터를 비동기적으로 복제합니다. 보조 리전에 대한 읽기 액세스가 필요한 경우, RA-GRS 또는 RA-GZRS를 사용하여 중단 또는 계획된 장애 조치 중에 보조 엔드포인트에서 읽기를 허용할 수 있습니다. 리전 내 고가용성과 리전 간 재해 복구가 모두 필요한 미션 크리티컬 워크로드의 경우, 영역 중복성과 리전 쌍 복제를 결합하십시오. 대기 시간, 복원력, 규정 준수 간의 균형을 맞추면 일반적인 패턴이 나옵니다. 즉, 주 리전의 여러 영역에 걸쳐 활성 워크로드를 배포하고, 쌍을 이루는 리전으로 데이터를 복제하고 장애 조치 경로를 제공하여 리전 재해로부터 보호하는 것입니다. 복구 목표가 충족되도록 장애 조치 런북과 DNS 또는 프런트엔드 라우팅 동작을 정기적으로 검증하십시오.

• Geography (지역)
  • 범위: 다중 리전 경계
  • 주요 이점: 데이터 상주 및 규정 준수
  • 일반적인 사용 사례: 규제 준수(예: EU 데이터)
• Region (리전)
  • 범위: 단일 대도시권
  • 주요 이점: 서비스에 대한 저지연 액세스
  • 일반적인 사용 사례: 기본 배포 위치
• Availability Zone (가용성 영역)
  • 범위: 리전 내의 개별 데이터 센터
  • 주요 이점: 데이터 센터 수준의 장애 격리
  • 일반적인 사용 사례: 리전 내 고가용성
• Region Pair (리전 쌍)
  • 범위: 동일한 지역(geography) 내의 두 리전
  • 주요 이점: 조정된 복구 및 업데이트
  • 일반적인 사용 사례: 리전 간 재해 복구

리소스 조직화 및 거버넌스: 관리 그룹, 구독, 리소스 그룹 및 리소스

Azure의 관리 계층 구조를 통해 대규모 정책, 액세스 및 비용 제어를 수행할 수 있습니다. 관리 그룹은 구독 위에 위치하며, Azure Policy와 역할 기반 액세스 제어(RBAC)를 중앙에서 적용할 수 있게 해줍니다. 이 설정은 하위 관리 그룹과 구독으로 상속됩니다. 이는 균일한 가드레일을 유지하면서 회사 부서, 환경 계층(프로덕션, 비프로덕션) 또는 규제 경계별로 분할하는 데 적합한 구조입니다. 구독은 관리, 청구 및 할당량의 경계입니다. 비즈니스 단위, 환경 또는 애플리케이션의 비용과 액세스를 격리하는 데 매우 적합합니다. 일관된 구독 설계를 사용하여 프로덕션과 비프로덕션을 분리하고 제한 및 예산을 적용하십시오. 여러 부서와 분산된 관리를 사용하는 조직의 경우, 각 부서에 하나 이상의 구독을 할당하고 이를 부서별 관리 그룹 아래에 배치하여 깔끔한 정책 및 RBAC 상속을 구현하십시오. 리소스 그룹은 라이프사이클을 공유하는 리소스들을 담는 논리적 컨테이너입니다. 이를 통해 원자적 배포, 일관된 태깅, 삭제 또는 잠금과 같은 라이프사이클 작업을 수행할 수 있습니다. 웹 계층과 그 모니터링 구성 요소처럼 함께 배포, 업데이트, 폐기되는 리소스들을 그룹화하십시오. 태그를 사용하여 리소스와 그룹 전반에 걸쳐 차지백/쇼백, 소유권, 환경 및 규정 준수 속성을 관리하십시오. 잠금(ReadOnly, CanNotDelete)은 리소스 또는 그룹 범위에서 실수로 인한 삭제를 방지하는 보호 기능을 추가합니다. 리소스는 배포된 서비스 인스턴스(VM, App Service 계획, 스토리지 계정)입니다. RBAC 범위(관리 그룹, 구독, 리소스 그룹, 리소스)를 통해 필요한 곳에 정확하게 최소 권한 액세스를 부여할 수 있습니다. 다중 부서 배포의 경우, 여러 테넌트에 대한 강력한 규정 준수 또는 자율성 요구 사항이 없는 한 단일 Microsoft Entra ID 테넌트를 유지하십시오. 일반적으로 구독과 관리 그룹은 훨씬 적은 관리 오버헤드로 충분한 분리를 제공합니다.

• Management Group
  • 주 목적: 조직 전반의 거버넌스
  • 적용되는 제어: RBAC, Policy, Blueprints (Policy + 템플릿을 통해)
  • 일반적인 패턴: 부서/규제별 분할
• Subscription
  • 주 목적: 청구 및 할당량 경계
  • 적용되는 제어: 예산, RBAC, Policy
  • 일반적인 패턴: BU별 또는 환경별 격리
• Resource Group
  • 주 목적: 라이프사이클 경계
  • 적용되는 제어: 잠금, 태그, RBAC
  • 일반적인 패턴: 애플리케이션 또는 워크로드 단위별
• Resource
  • 주 목적: 서비스 인스턴스
  • 적용되는 제어: 인스턴스 수준 RBAC, 태그
  • 일반적인 패턴: 개별 서비스 구성 요소

Azure Resource Manager와 템플릿

Azure Resource Manager(ARM)는 일관된 API와 역할 기반 모델을 통해 Azure 리소스를 배포, 업데이트 및 삭제하기 위한 컨트롤 플레인입니다. ARM은 멱등성 작업, 종속성 관리, 태깅 및 배포 시 정책 강제 적용을 제공하여 플랫폼 거버넌스가 모든 변경 사항에 내재되도록 합니다. 선언적 ARM 템플릿은 JSON 형식으로 환경의 원하는 상태를 설명하며, 매개변수, 변수, 조건 및 모듈식 연결 템플릿을 지원합니다. 이를 통해 환경과 구독 전반에 걸쳐 반복 가능하고 버전 제어가 되는 배포를 수행할 수 있습니다. 간소화된 작성 환경을 위해 Bicep은 동일한 배포 엔진과 이점을 유지하면서 ARM 템플릿으로 변환되는 간결한 구문을 제공합니다. 템플릿을 소스 제어에 저장하고, 공유를 위해 템플릿 사양(template specs)으로 패키징하며, CI/CD 파이프라인에 통합하여 드리프트가 없고 감사 가능한 인프라 변경을 보장하십시오. 관리자 암호나 연결 문자열과 같은 민감한 값은 템플릿에 절대 포함해서는 안 됩니다. Key Vault 참조와 함께 secureString/secureObject 매개변수를 사용하여 ARM이 배포 시점에 로그에 노출하지 않고 비밀을 검색하도록 하십시오. 템플릿을 관리 ID와 결합하여 자동화에서 하드코딩된 자격 증명을 제거하십시오. 이 접근 방식은 대규모 다중 구독 배포를 위한 완전한 자동화를 유지하면서 위험을 줄여줍니다.

• 멱등성 배포
  • ARM/템플릿 지원: 예
  • 결과: 안전하고 반복 가능한 변경
• 배포 시 정책 강제 적용
  • ARM/템플릿 지원: 예
  • 결과: 파이프라인에 내장된 가드레일
• 모듈식 구성
  • ARM/템플릿 지원: 연결된 모듈 / Bicep 모듈
  • 결과: 재사용성 및 표준화
• 비밀 처리
  • ARM/템플릿 지원: Key Vault 참조
  • 결과: 코드나 로그에 비밀 없음

가용성, SLA, 복합 SLA 및 서비스 수명 주기

Azure는 정식 출시(GA)된 서비스에 대해 재정적으로 보장되는 서비스 수준 계약(SLA)을 게시합니다. 가상 머신의 경우 가용성은 배포 토폴로지에 따라 달라집니다. Premium SSD 스토리지를 사용하는 단일 VM은 99.9% SLA를, 가용성 집합에 있는 2개 이상의 VM은 99.95% SLA를, 가용성 영역에 걸쳐 배포된 2개 이상의 VM은 99.99% SLA를 가집니다. 플랫폼 서비스(예: Azure SQL Database 또는 App Service)는 자체 SLA를 가지며, 이는 계층이나 중복성 옵션에 따라 다를 수 있습니다. 적절한 중복성 모델과 서비스 계층을 선택하여 아키텍처를 목표 SLA에 맞춰야 합니다. 솔루션이 여러 서비스에 의존하는 경우, 앱이 작동하는 데 모든 구성 요소가 필요하다면 복합 SLA는 개별 SLA의 곱이 됩니다. 예를 들어, 웹 앱(99.95%)이 데이터베이스(99.99%)에 의존하는 경우 복합 가용성은 약 0.9995 × 0.9999 = 99.94%입니다. 영역 간 배포, 부하 분산 장치 뒤에 여러 인스턴스 추가, 지역 중복 데이터 저장소 사용 등 어떤 계층에서든 중복성을 높이면 유효 가용성이 향상됩니다. 반대로, 직렬 종속성을 추가하면 복합 SLA가 낮아지므로 명확한 기능적 가치로 정당화되어야 합니다. 서비스 수명 주기 상태는 안정성 보증에 영향을 미칩니다. 공개 미리 보기 기능은 피드백을 수집하기 위해 제공되며 특정 지역으로 제한되거나 기능 격차가 있을 수 있습니다. 일반적으로 SLA가 적용되지 않으며 프로덕션의 중요 경로에는 권장되지 않습니다. GA(정식 출시) 기능은 프로덕션에 사용할 준비가 되었으며 SLA가 적용됩니다. 특히 규정 준수가 중요한 환경에서 프로덕션 설계 시 미리 보기 기능에 의도치 않게 의존하는 것을 피하려면 로드맵과 지역 출시 일정을 추적해야 합니다. RPO 및 RTO와 같은 재해 복구 목표는 SLA를 보완하며, 영역 간 또는 지역 간 복제, 백업 빈도, 장애 조치 오케스트레이션과 같은 설계 선택을 안내합니다. 장애 조치 절차를 정기적으로 검증하여 측정된 복구 성능이 비즈니스 목표와 일치하는지, 그리고 DNS, 인증서, ID 종속성도 예상대로 복구되는지 확인해야 합니다.

• 단일 VM (Premium SSD)
  • 지표 SLA: 99.9%
  • 참고: 중요하지 않은 워크로드 또는 내결함성 있는 앱에 사용
• 가용성 집합 내 2개 이상의 VM
  • 지표 SLA: 99.95%
  • 참고: 랙/장애 도메인 장애로부터 보호
• 가용성 영역에 걸친 2개 이상의 VM
  • 지표 SLA: 99.99%
  • 참고: 데이터센터 수준 장애로부터 보호
• 공개 미리 보기 기능
  • 지표 SLA: 재정적 SLA 없음
  • 참고: 평가용, 중요 경로에는 사용 지양
• GA 기능 (서비스 계층에 따라 다름)
  • 지표 SLA: SLA 보장
  • 참고: 계층 및 지역별 SLA 확인

글로벌 라우팅 및 콘텐츠 전송: Azure Front Door, Traffic Manager, Azure CDN

글로벌 사용자 경험은 지능형 라우팅, 콘텐츠 근접성, 신속한 장애 조치에 달려 있습니다. Azure Front Door는 웹 애플리케이션 방화벽(WAF), TLS 종료, URL/경로 기반 라우팅, 세션 선호도, 에지에서의 상태 프로브 기능을 갖춘 글로벌 애니캐스트 Layer 7 역방향 프록시입니다. split-TCP 및 프로토콜 최적화를 통해 동적 콘텐츠를 가속화하고 오리진 간에 거의 즉각적인 장애 조치를 제공합니다. Front Door는 에지에서 성능과 중앙 집중식 보안이 모두 필요한 활성-활성 또는 활성-수동 다중 지역 웹 애플리케이션 및 API에 이상적입니다. Azure Traffic Manager는 우선순위, 가중치, 성능(대기 시간), 지역, 서브넷 또는 다중값과 같은 정책을 사용하여 클라이언트를 최적의 엔드포인트로 안내하는 DNS 기반 트래픽 분산 서비스입니다. DNS 수준에서 작동하므로 비-HTTP 엔드포인트(예: TCP 서비스)와 하이브리드 시나리오를 지원하지만, 장애 조치 속도는 DNS TTL 및 클라이언트 캐싱에 의해 제한됩니다. Traffic Manager는 트래픽을 프록시하거나 콘텐츠를 가속화하지 않고, 단지 선택된 엔드포인트로 DNS에 응답할 뿐입니다. Azure CDN은 에지 PoP(Point of Presence)에 정적 콘텐츠를 캐시하여 대기 시간을 줄이고 오리진의 부하를 덜어줍니다. 이미지, 비디오, 스크립트, 다운로드 파일과 같은 대용량 정적 자산에 매우 적합합니다. CDN은 캐시 가능한 콘텐츠에 대한 왕복 시간을 줄여주지만, 동적 오리진을 위한 상태 인식 글로벌 부하 분산 장치는 아닙니다. 다중 오리진 장애 조치나 동적 라우팅 로직을 위해서는 Front Door 또는 Traffic Manager와 결합하여 사용해야 합니다. 많은 아키텍처에서 동일한 애플리케이션 앞에 정적 자산 캐싱을 위해 CDN을, 동적 트래픽 및 보안을 위해 Front Door를 배치합니다.

• Azure Front Door (Std/Prm)
  • 계층/메커니즘: Layer 7 애니캐스트 프록시
  • 주요 사용 사례: 글로벌 부하 분산, 에지 보안, 가속
  • 라우팅 방법: 우선순위, 가중치, 경로/호스트 기반 규칙
  • 상태 프로브: 에지 POP 프로브
  • 장애 조치 속도: 수 초 (거의 즉시)
  • 동적 가속: 예
  • 정적 캐싱: 예 (규칙 기반)
  • WAF 사용 가능: 예 (통합)
  • 일반적인 패턴: 다중 지역 웹 앱/API 앞에 Front Door 배치
• Azure Traffic Manager
  • 계층/메커니즘: DNS 기반 정책
  • 주요 사용 사례: 지역 간 DNS 라우팅, 비-HTTP 엔드포인트
  • 라우팅 방법: 우선순위, 가중치, 성능, 지역, 서브넷, 다중값
  • 상태 프로브: 글로벌 엔드포인트 프로브
  • 장애 조치 속도: TTL에 따라 제한됨 (수십 초에서 수 분)
  • 동적 가속: 아니요
  • 정적 캐싱: 아니요
  • WAF 사용 가능: 해당 없음
  • 일반적인 패턴: HTTP 및 비-HTTP 서비스를 위한 DNS 스티어링
• Azure CDN
  • 계층/메커니즘: 에지 캐싱 네트워크
  • 주요 사용 사례: 정적 콘텐츠 오프로드 및 대기 시간 감소
  • 라우팅 방법: 해당 없음 (캐시 규칙)
  • 상태 프로브: 해당 없음 (선택적 오리진 그룹 장애 조치)
  • 장애 조치 속도: 해당 없음 (캐시 기반)
  • 동적 가속: 아니요 (캐시 외에는 없음)
  • 정적 캐싱: 예
  • WAF 사용 가능: Front Door Premium 또는 별도 WAF를 통해
  • 일반적인 패턴: 자산을 위한 CDN + 오리진을 위한 Front Door/Traffic Manager

실전 문제: IronPeak Manufacturing을 위한 고가용성, 규정 준수 및 글로벌 성능을 갖춘 웹 플랫폼 설계

시나리오: IronPeak Manufacturing은 유럽과 북미에서 사업을 운영하며, 고객 및 파트너 포털을 Azure로 통합하고 있습니다. 이 플랫폼은 웹 계층에 대해 99.99%의 가용성을 충족해야 하고, EU 고객 데이터는 EU 내에 유지해야 하며, 지역 간 신속한 장애 조치를 제공하고, 전 세계적으로 빠른 페이지 로드를 지원해야 합니다. 팀은 코드나 로그에 평문(plaintext) 비밀 정보가 없는 완전 자동화된 배포를 원합니다.

과제: EU 내 데이터 상주 요건을 충족하면서 리전 내 고가용성 및 지역 간 재해 복구를 달성하고, 동적 트래픽에 대한 글로벌 가속 및 장애 조치를 제공하며, 여러 구독에 걸쳐 반복 가능하고 안전한 배포를 구현해야 합니다.

권장 접근 방식:

1. 유럽 지역(geography)을 선택하고, 가용성 영역(Availability Zones)이 있는 리전(예: West Europe)에 기본 워크로드를 배포합니다. 이때 두 개 이상의 VM 확장 집합 인스턴스 또는 App Service 인스턴스를 여러 영역에 걸쳐 분산시킵니다.
2. 서비스의 네이티브 복제 기능을 사용하여 쌍을 이루는 리전(paired region, North Europe)으로 지역 간 재해 복구를 활성화합니다. Storage에는 RA-GZRS를 사용하고, 데이터베이스에는 가능한 경우 지역 복제(geo-replication)를 사용하며, 자동화된 장애 조치 런북을 구성합니다.
3. 애플리케이션의 프런트엔드로 Azure Front Door Standard/Premium을 사용하여 글로벌 HTTPS 종료, WAF, 에지 상태 프로브, West Europe(기본)과 North Europe(보조) 간의 우선순위 기반 장애 조치, 경로 기반 라우팅 규칙을 설정합니다.
4. 정적 자산(이미지, 스크립트, 다운로드 파일)은 동일한 원본과 통합된 Azure CDN을 사용하여 캐시하여 지연 시간을 줄이고 트래픽을 오프로드합니다. 캐시 규칙과 TTL을 검증합니다.
5. EU 및 NA 사업부를 위한 관리 그룹을 정의하고, 각 그룹 아래에 프로덕션 및 비프로덕션 구독을 배치합니다. 데이터 상주, 태깅, 허용된 위치에 대한 Azure Policy를 적용합니다.
6. 소스 제어에 저장된 ARM/Bicep 템플릿을 구현하고 템플릿 사양(template specs)으로 게시합니다. 리전, SKU, 스케일링 설정을 매개변수화하고, 배포 시 관리 ID를 사용하여 Azure Key Vault의 비밀 정보를 참조합니다.
7. SLA를 설정하고 복합 가용성을 테스트합니다. Front Door 뒤에 영역 분산된 두 개의 인스턴스를 배치하여 앱 계층에 대해 99.99% 가용성을 목표로 합니다. 분기별로 엔드투엔드 장애 조치 훈련, DNS, 인증서, ID 종속성을 검증합니다.
8. Application Insights와 Azure Monitor로 플랫폼을 계측합니다. Front Door 상태 프로브와 경고를 구성하고, 원격 분석(telemetry) 데이터를 기반으로 자동 스케일링 및 캐싱 정책을 조정합니다.

Azure 설계 근거: 이 설계는 가용성 영역(Availability Zones)을 통해 리전 내 장애 격리를 제공하고, 쌍을 이루는 리전으로 지역 간 재해 복구를 지원하면서 EU 데이터를 유럽 지역(geography) 내에 유지합니다. Azure Front Door는 동적 트래픽에 대한 글로벌 가속 및 상태 인식 장애 조치를 제공하며, Azure CDN은 정적 콘텐츠를 오프로드하여 성능을 향상시킵니다. Key Vault 참조를 사용하는 ARM/Bicep 템플릿은 여러 구독과 리전에 걸쳐 반복 가능하고 안전한 배포를 가능하게 합니다. 선택된 토폴로지는 게시된 SLA와 일치하여 웹 계층의 99.99% 목표를 충족하며, 관리 그룹 및 구독 수준의 정책은 최소한의 운영 오버헤드로 거버넌스를 강화합니다.

← 클라우드 개념 · 모든 도메인 · 컴퓨팅 및 앱 서비스 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Microsoft 찾아보기 →