[Cloud] AWS vs Azure 비교 완벽 가이드

1. 비교 관점 및 전제

AWS와 Azure는 모두 글로벌 리더급 하이퍼스케일 클라우드이지만, 설계 철학·조직 모델·서비스 포트폴리오에서 차이가 존재한다. 이 문서는 다음 관점에서 두 플랫폼을 비교한다.

• 글로벌 인프라 구조(Region, AZ, Region Pair 등)
• 계정/구독 및 리소스 계층 구조
• 네트워크·컴퓨팅·스토리지·데이터베이스·보안·모니터링
• 비용 모델 및 할인 전략(RI, Savings Plans, Reservations 등)
• 설계 패턴 및 마이그레이션 관점

이 문서는 AWS 경험이 있는 엔지니어가 Azure를 이해하거나, Azure 엔지니어가 AWS 구조를 비교하며 설계를 검토할 수 있도록 하는 것을 목표로 한다.

(서비스 매핑은 Microsoft의 “AWS 전문가를 위한 Azure” 문서 시리즈를 기반으로 정리하였다.) Microsoft Learn+1

---

2. 글로벌 인프라 및 고가용성 모델

2.1 Region & Availability Zone

AWS

• 전 세계 38개 리전, 120개 AZ 제공(추가 리전·AZ 예정). Amazon Web Services, Inc.
• AZ = 하나 이상의 데이터센터 묶음(전용 전력·냉각·네트워크를 가진 독립 장애 도메인). DEV Community
• 대부분의 고가용성 권장 아키텍처는 3AZ 이상 분산을 기본 전제로 한다.

Azure

• 여러 지역에 리전(Region)을 보유하며, 많은 리전이 Availability Zone 지원. Microsoft Learn+1
• AZ 역시 독립 전력·냉각·네트워크를 가진 데이터센터 묶음이며, 사용 가능한 리전에서는 최소 3개의 Zone을 제공. Tutorials Dojo
• Azure는 추가로 Region Pair 개념을 도입하여 DR, 업그레이드 순번, 메타데이터 복제를 설계한다. Microsoft Learn+1

설계 시 차이

• AWS: “Region + N개의 AZ” 위에 VPC를 설계하는 패턴이 직관적이다.
• Azure: “Region + AZ + Region Pair”의 3층 구조를 고려해야 하며, DR 설계 시 Pair를 명시적으로 활용하는 것이 권장된다.

---

3. 계정·구독·리소스 계층 구조

3.1 계정/테넌트 구조

구분 AWS Azure

최상위	AWS Account	Azure AD Tenant (Entra ID)
청구 단위	Account 또는 Consolidated Billing	Subscription
논리 그룹	OU(Organization Unit)	Management Group

• AWS Organization: 여러 Account를 OU로 묶고 SCP(Service Control Policy)로 거버넌스를 적용.
• Azure: 하나의 Tenant 안에 다수 Subscription, 그 위에 Management Group 계층을 구성하고 Azure Policy로 거버넌스를 적용. Microsoft Learn

3.2 리소스 계층 구조

구분 AWS Azure

리소스 그룹화	태그 중심(필수 그룹 객체 없음)	Resource Group(1단계 논리 그룹)
배포 단위	CloudFormation Stack, Terraform Workspace 등	리소스 그룹 단위 ARM/Bicep 배포

Azure는 Resource Group이 관리·배포의 기본 단위이므로, 설계 단계에서 리소스 그룹 경계를 명확히 잡는 것이 중요하다(프로덕션/스테이징/워크로드·도메인 단위 등).

---

4. 네트워크: VPC vs VNet

4.1 기본 개념

항목 AWS VPC Azure VNet

주소 공간	CIDR 기반	CIDR 기반
서브넷	AZ 단위 Subnet (1 Subnet = 1 AZ)	Subnet는 Region 내 논리 구역, AZ에 종속X
라우팅	Route Table per Subnet	Route Table(UDR) per Subnet
NAT	NAT Gateway	NAT Gateway
전역 네트워크	AWS Global Accelerator/VPC Peering/Transit Gateway	VNet Peering/Virtual WAN/ExpressRoute

• AWS는 Subnet이 AZ에 종속되는 반면, Azure는 Subnet이 Region 내 논리 네트워크로 AZ와 느슨하게 연관되어 있다(Zone은 NIC 레벨에서 선택).
• 대규모 허브-스포크 설계 시
  • AWS: Transit Gateway
  • Azure: Virtual WAN + Hub VNet 패턴이 일반적이다. Microsoft Learn

4.2 하이브리드 연결

구분 AWS Azure

Site-to-Site VPN	VPN Gateway	VPN Gateway
전용 회선	Direct Connect	ExpressRoute

두 플랫폼 모두 하이브리드 구성이 가능하나, ExpressRoute와 Direct Connect의 SLA, QoS, 회선 공급자 옵션에서 지역별 차이가 있으므로 실제 통신사와의 계약 구조까지 고려해야 한다.

---

5. 컴퓨팅: EC2/ECS/EKS vs VM/AKS/컨테이너

5.1 가상 머신

항목 AWS Azure

기본 서비스	EC2	Azure Virtual Machines
오토스케일	Auto Scaling Group	Virtual Machine Scale Sets
이미지	AMI	Managed Image, Shared Image Gallery

두 플랫폼 모두 VM 스케일링·가용성 모델은 유사하지만,

Azure는 Scale Set 및 Availability Set, Zone을 조합해야 고가용성 구성이 완성된다.

5.2 컨테이너

워크로드 타입 AWS Azure

Container Orchestration	Amazon ECS, Amazon EKS	Azure Kubernetes Service (AKS)
서버리스 컨테이너	AWS Fargate (ECS/EKS 전용)	Azure Container Apps, AKS Virtual Nodes(과거), Container Instances

• AWS: ECS(Fargate)로 비교적 단순한 컨테이너 운영이 가능하며, EKS는 순수 Kubernetes 중심.
• Azure: AKS가 중심이며, 관리형 Ingress, Application Gateway for Containers(Gateway API 지원) 등과의 통합이 강조된다. Microsoft Learn+1

5.3 서버리스

구분 AWS Azure

FaaS	AWS Lambda	Azure Functions
Eventing	EventBridge, SNS, SQS	Event Grid, Service Bus, Storage Queue

Lambda와 Functions 모두 이벤트 기반 컴퓨팅을 제공하지만, Azure는 Event Grid + Logic Apps + Functions를 조합한 이벤트 드리븐 아키텍처가 흔하다.

---

6. 스토리지·CDN

6.1 객체·블록·파일

스토리지 유형 AWS Azure

객체	Amazon S3	Azure Blob Storage
블록	EBS	Managed Disks
파일 공유	EFS	Azure Files

• S3와 Blob은 둘 다 버전 관리, 수명 주기, 티어링(Hot/Warm/Archive)을 제공한다.
• 파일 스토리지에서
  • AWS EFS: NFS 기반 managed 파일 시스템
  • Azure Files: SMB/NFS 지원, Azure AD 인증·Private Endpoint 등과 통합.

6.2 CDN

항목 AWS Azure

CDN

Amazon CloudFront

Azure Front Door, Azure CDN

Azure는 Front Door를 애플리케이션 레벨 글로벌 엔드포인트로 활용하는 경우가 많으며, WAF·TLS·로드밸런싱을 동시에 처리한다.

---

7. 데이터베이스 & 분석

7.1 RDBMS

엔진 AWS(Amazon RDS) Azure

SQL Server	RDS for SQL Server	Azure SQL Database / SQL Managed Instance
MySQL	RDS for MySQL	Azure Database for MySQL
PostgreSQL	RDS for PostgreSQL, Aurora PostgreSQL	Azure Database for PostgreSQL

Microsoft는 Azure SQL Database, Managed Instance를 통해 PaaS 형태의 SQL Server를 제공하며, 이는 AWS의 RDS for SQL Server와 유사한 목적을 가진다. Microsoft Learn

7.2 NoSQL & 분석

종류 AWS Azure

Key-Value	DynamoDB	Cosmos DB (Table API 등)
Document	DynamoDB	Cosmos DB (Core/SQL API)
Data Warehouse	Redshift	Azure Synapse Analytics, Fabric SQL

Cosmos DB는 글로벌 분산·멀티 모델을 제공하여, DynamoDB + Global Tables와 유사한 시나리오를 커버한다.

---

8. Identity, Access, Security

8.1 IAM / Entra ID + RBAC

관점 AWS Azure

ID 시스템	IAM(User/Role), SSO	Entra ID(Azure AD)
리소스 권한	IAM Policy	Azure RBAC(Role Assignment)
조직 단위 거버넌스	SCP	Azure Policy + Management Group

• AWS: 하나의 계정 내부에서 IAM으로 권한을 제어하고, 다계정 구조는 Organization+SCP로 제어.
• Azure: 테넌트=ID, Subscription=청구/리소스 경계이며, Azure AD 그룹 + Role Assignment로 권한 위임을 수행.

8.2 보안 서비스

범주 AWS Azure

보안 posture	Security Hub	Microsoft Defender for Cloud
워크로드 보호	GuardDuty, Inspector	Defender for Cloud(서버, DB, 컨테이너 등 플랜)
Key Management	KMS	Key Vault

양쪽 모두 CSPM/워크로드 보호 기능을 제공하므로, 조직 정책을 어디에서 중앙 관리할지(SCP vs Azure Policy+Defender)를 결정하는 것이 중요하다. Microsoft Learn

---

9. 모니터링·로깅·운영

9.1 모니터링

영역 AWS Azure

Metric & Logs	CloudWatch	Azure Monitor(Metrics, Logs)
로그 수집	CloudWatch Logs, Kinesis Firehose	Log Analytics Workspace
분산 추적	X-Ray	Application Insights

Azure Monitor는 Metric·Log·Alert·Application Insights를 통합 서비스로 제공하며, 모든 로그는 Log Analytics Workspace에서 KQL 기반으로 조회·분석한다.

9.2 감사 로그

항목 AWS Azure

제어 평면 로그	CloudTrail	Activity Log
구성 변경 추적	Config	Azure Policy / Change Analysis 등

멀티클라우드 환경에서는 CloudTrail + Activity Log를 모두 중앙 SIEM(Splunk, Sentinel 등)으로 수집하는 구조가 일반적이다.

---

10. 비용 모델·RI·Savings Plan vs Reservations

10.1 AWS

• 온디맨드, Spot, Reserved Instances(RI), Savings Plans 조합.
• Savings Plans: 시간당 $ 단위로 Compute 사용량을 약정하여 할인(Compute Savings Plans, EC2 Instance Savings Plans). AWS Documentation+1
• Standard RI는 최대 ~75% 수준, Savings Plans는 ~60~70% 수준의 할인 가능(조건에 따라 상이). Finout+1

10.2 Azure

• Pay-as-you-go, Spot, Azure Reservations, Azure Savings Plan for Compute 등 제공.
• Azure Reservations: VM, DB, Synapse 등 특정 리소스에 대해 1년/3년 약정을 통해 비용 절감.
• Azure Savings Plan for Compute: AWS Savings Plans와 유사하게 Compute 사용량 기반 약정으로 할인 제공.

10.3 전략적 차이

• AWS는 계정 단위 청구 + Savings Plans 조합이 강점.
• Azure는 Subscription/Management Group + Reservations + Savings Plan + Hybrid Benefit(라이선스 BYOL) 조합에 강점.

실무에서는 아래와 같은 접근이 일반적이다.

1. 베이스라인 워크로드: 3년 Reservation/RI 중심 설계
2. 변동성 높은 워크로드: Savings Plan/Pay-as-you-go + 자동 스케일링
3. 초기 PoC·테스트: Spot + 짧은 Reservation/Pay-as-you-go

---

11. 서비스 매핑(핵심만 요약)

Microsoft 공식 매핑 문서를 기반으로 한 주요 서비스 대응 표. Microsoft Learn+2Microsoft Learn+2

카테고리 AWS Azure

Compute	EC2	Virtual Machines
Container Orchestration	EKS, ECS	AKS
Serverless	Lambda	Functions
Object Storage	S3	Blob Storage
File Storage	EFS	Azure Files
RDB PaaS	RDS	Azure SQL / DB for MySQL/PostgreSQL
NoSQL	DynamoDB	Cosmos DB
CDN/Global LB	CloudFront, Global Accelerator	Front Door, Azure CDN
IAM	IAM	Entra ID + Azure RBAC
Monitoring	CloudWatch, X-Ray	Azure Monitor, App Insights
Security Posture	Security Hub, GuardDuty	Defender for Cloud

---

12. 설계 패턴·멀티클라우드 관점

12.1 단일 클라우드 선택 시 고려 사항

AWS가 상대적으로 자연스러운 경우

• 이미 AWS 중심의 DevOps 툴체인(Jenkins + CodePipeline + CodeDeploy + EKS/ECS)을 구축한 경우
• Spot + ASG 기반의 대규모 Batch/AI/빅데이터 워크로드가 핵심인 경우
• AWS SaaS 에코시스템에 강하게 의존하는 제품 사용 중인 경우

Azure가 상대적으로 자연스러운 경우

• 온프레미스가 Windows/AD/SQL Server/SharePoint/Exchange 등 Microsoft 스택 중심인 경우
• Microsoft 365, Entra ID, Defender, Intune 등과의 통합 거버넌스가 중요한 경우
• AKS + Front Door + Application Gateway for Containers 등 Azure 네이티브 PaaS 중심 아키텍처를 추구하는 경우

12.2 멀티클라우드 설계 시 팁

• ID·보안 정책은 최대한 한쪽(예: Entra ID + Conditional Access)으로 통합하고, 다른 쪽은 페더레이션/역할 위임만 수행.
• 네트워크·연결 모델은 온프레미스 ↔ 각 클라우드 허브(VPC/VNet) 구조로 정렬하여 “온프레미스가 중심이 되는 스타형 토폴로지”를 기본으로 한다.
• 모니터링·로그는 SIEM(Azure Sentinel, Splunk 등)을 상단에 두고 두 클라우드의 로그를 모두 수집한다.

---

13. 마이그레이션 관점: AWS ↔ Azure

13.1 공통 체크리스트

1. 네이밍/태깅 전략 재정의
   • AWS Tag → Azure Tag로 변환
   • Resource Group, Subscription 경계 설계
2. 네트워크 재설계
   • VPC CIDR ↔ VNet CIDR 매핑
   • Transit Gateway ↔ Virtual WAN/Hub VNet 구조 변환
3. ID·권한 모델 변환
   • IAM Role → Entra ID 서비스 프린시펄 + Managed Identity
   • IAM Policy → Azure Role Definition/Assignment
4. 서비스 매핑
   • RDS → Azure SQL/DB for MySQL/PostgreSQL
   • S3 → Blob, EFS → Azure Files 등
5. 운영·모니터링
   • CloudWatch Dashboard → Azure Monitor Workbook
   • CloudTrail → Activity Log + Diagnostic Settings

---

14. 결론 및 실무 적용 팁

1. 먼저 조직 구조를 정의해야 한다.
   • AWS: Organization + OU + Account 구조
   • Azure: Tenant + Management Group + Subscription 구조
   • 거버넌스 구조가 정리되지 않으면 이후 보안·비용·운영 설계가 모두 꼬인다.
2. 네트워크와 ID, 로깅은 멀티클라우드를 염두에 둔 공통 패턴으로 정의한다.
   • 하이브리드 연결(ExpressRoute/Direct Connect),
   • 중앙 ID(Entra ID/IdP),
   • 중앙 로그(SIEM) 전략은 플랫폼을 가리지 않는다.
3. 컨테이너·서버리스는 각 클라우드의 강점을 그대로 활용하는 것이 효율적이다.
   • AWS: ECS/Fargate + Lambda
   • Azure: AKS + Functions + Front Door/AGfC
4. 비용 최적화는 할인 모델(RI/Reservations/Savings Plan) + 아키텍처 튜닝을 함께 고려해야 한다.
   • 고정 워크로드: 3년 약정 + Reserved/Reservations
   • 변동 워크로드: Savings Plan/Autoscaling/Spot

이 문서를 기반으로 조직의 현재 상황(AWS 중심인지, Microsoft 스택 중심인지, 멀티클라우드 전략 여부 등)을 점검하고, 각 플랫폼의 강점을 살리는 아키텍처를 설계하는 것이 가장 현실적인 접근이다.

이 가이드를 다시 참고할 가능성이 있다면, 북마크 또는 팀 공유 문서로 저장하는 것을 권장한다.